Podcast #128: We chat with Kent C Dodds about why he loves React and discuss what life was like in the dark days before Git. Listen now.
6

In this point, if Bob make a fraud transaction with Segwit, legacy node will accept, but it is not accepted in terms of fresh node. so, some group(legacy nodes) accept, other some groups(fresh nodes) doesn't accept. it means that proportion of fresh node should be bigger than proportion of legacy node. I think that this is really critical issue but ...


5

Yes, miners can censor transactions. A mining pool (or solo miner) can choose to not add a transaction to any blocks that they create. And, of course, this can be done dynamically so that transactions that match whatever arbitrary rules they want can be disallowed. However this only effects one mining pool or miner. Other miners will not necessarily follow ...


4

it means that proportion of fresh node should be bigger than proportion of legacy node. The requirement for segwit's activation was that the majority of the hashrate signaled readiness for activation. Although this process was frequently misconstrued as a "vote of miners", the activation proposal actually requests that miners judge whether the majority of ...


3

The main difference is that Bitcoin in lightning network channels are in 2of2 multisig wallets. You own a key and your channel peer owns the second key. Your funds are "safe" because you have pre-signed transactions that spend from that multisig wallet (similar to an offline signing of a transaction). As soon as you keep those pre-signed transactions, your ...


3

Do full-nodes process all txs before broadcasting the new blockheader? It depends. For nodes having protocol version 70015 and higher, the peer will announce the compact block even before full validation of the transactions contained in the block. However, the header has to be conform with the difficulty requirement. For nodes using protocol version 70015 ...


2

There are a few reasons why a user can lose funds in the lightning network. But to understand why that happens let us look at some of the basic constructs of Lightning Network. Lightning Basics When two parties open a channel in Lightning Network what they essentially do is send some bitcoins to a 2-of-2 multi-sig that they both control (in current specs ...


2

You wouldn't need to do something specific for USDT. Your best bet would be to sign a message proving ownership of each address you hold USDT in. Once you prove you control the addresses, you can prove that you control the USDT balance at any given block height for those addresses using the signed messages and a node that can calculate the balances.


2

The transaction has more than enough confirmation, so if it doesn't show up, it's probably because your node hasn't catch up with the network yet. Watch out though, looking at the numbers in your comment up there, the block height is the mainnet one, testnet figures would be a lot higher. Your transaction has been mined on block 1,584,207. If this is so, ...


2

There is only way way to acquire Bitcoin without a previous utxo associated with them: Mine them. You could pay a miner to mine directly to an address that you control, if you don't have the hashpower yourself. If you pay someone else who transfers such coins to you, you've already destroyed the value as the act of transferring them will move then from the ...


1

How legacy node can verify them without the witness? An example of a SegWit output is: scriptPubKey: 0 ab68025513c3dbd2f7b92a94e0581f5d50f654e7. For legacy nodes, this output looks like an anyone can spend output as there are no opcodes or verification. Such outputs do not require any signatures to spend. Thus when a legacy node sees a transaction spending ...


1

What you are describing is essentially a majority attack. A miner (or group of colluding miners) with a majority of hashpower can censor arbitrary transactions, and blocks that include them. This question has more info about what an attacker can do. Crucially: a majority of hashpower can create blocks at a faster rate (on average) than the minority. So if ...


1

Assuming you double checked that you sent the coins to the right BTC adddress: The wallet of the receiver should be connected to a full Bitcoin-node, either his own node or another node. This node could be down or not updated to current block height. So you might ask the receiver if (s)he used the same wallet already successfully for other transactions ...


1

The signature signs the spending transaction(*). Modifying it in any way will invalidate the signatures in it. (*) Not actually, as it's obviously impossible for the signature to sign itself. There are also means for a signature to indicate it explicitly does not sign certain parts of the transaction, permitting those to be modified after the fact.


1

There is no explicit marker that identifies a hash as being related to a transaction/block, but as mentioned by OP, there is an implicit assumption that can be made, due to the difficulty target for blocks that is imposed by the network’s nodes. Pragmatically, this means that a hash with an improbably low value could be assumed to be a potential block hash....


1

This is not possible, both are sha256 hashes, and contain no markers as to their origin.


1

1.Sign the Raw_Transaction above with private key1. The output would be ...


1

Yes, bitcoin is divisible to the 0.00000001 bitcoin, we call this small amount the "Satoshi" for example so even if you got less than 1 bitcoin you have a pretty wide margin on what amount you want to transfer it could be 200.0099 or 0.0005123 be careful of the fees though For the transfer part I suggest you to use electrum You will find more useful ...


1

This would be possible with the cooperation of miners. Miners decide which transactions to include in their blocks, and which to ignore. Currently, this is largely done based on the feerate. If you have the support of all miners, you could effectively operate a whitelist-only network. If even one miner rejects your proposal, they will continue mining blocks ...


1

There are, broadly, three types of addresses in use at the moment: P2PKH - Pay to public key hash addresses start with a 1, and should be accepted by essentially any service in the Bitcoin ecosystem P2SH - Pay to script hash addresses are commonly used for multisig, but as of the segwit activation, they are also used for wrapped segwit addresses. These ...


1

I get their purpose and that they need a strong password, etc. But what I don't understand in particular is how they relate to transactions and wallets. The purpose of the private key is to decrypt. An example in asymmetric cryptography a.k.a. public key cryptography, you have a shared(public) key, and the private key that can decrypt some scrambled data, ...


1

But what I don't understand in particular is how they relate to transactions and wallets. This requires a long answer. Here's a nice intro which should answer this. I am actually not sure what the point is for adding the key to the wallet. Does it somehow relate to transactions? Why do I need to add a private key to my wallet? If you read the above ...


1

Or is there a big gap in my logic? Your logic is right, it is just that no decent service will accept a payment unless 1, 3 or even 6 block confirmation. How common are such race attacks Not common at all, but if the services or the person is forced to accept unconfirmed block, here is a link with information about how to better perform and how to ...


1

Nothing prevents you to send bitcoins to one of your own addresses. I guess I'd just create a new address on my node with bitcoin-cli getnewaddress, and then create a transaction with 2 outputs : one to the address I just got with my whole input amount (minus mining fees) another to a "dummy" address (can be one you generated with the same method, you can't ...


1

Yes, you can consume multiple UTXOs in a single transaction but upto a certain limit.Also transaction fees will increase as the size of input increases using multiple UTXOs. I used Transaction Builder of bitcoinjs-lib, for transaction. Hence, using tx.addInput(txId, vOut) (txId and Vout of respective UTXO to be used) multiple times, multiple UTXOs can be ...


Only top voted, non community-wiki answers of a minimum length are eligible