6 ms·

Can someone who knows the technical details of bitcoin answer the following questions? Suppose initially A owns 1BTC and B owns 0BTC. Suppose A publishes a sign

by xamuel 9y ago

Can someone who knows the technical details of bitcoin answer the following questions? Suppose initially A owns 1BTC and B owns 0BTC. Suppose A publishes a signed transaction that would give 1BTC to B, and simultaneously B publishes a signed transaction that would give 1BTC to C. If a miner includes both transactions in a block, is the block valid? Does it depend on the order of the transactions within the block (A's transfer to B preceding B's transfer to C)?

sly010 9y ago
The block is valid only if the transactions are in the correct order, but the miner is incentivized to figure out the right order (specifically incentivized to include as many transactions as possible). Edit: You are always spending a specific input, so to broadcast B->C, B would have to wait for A->B and specifically name that transaction. The miner _could_ receive these transactions out of order, but that should not be an issue.
SilasX 9y ago
The protocol says to only accept valid blocks. Part of being a valid block is "only spend BTC you have". B-to-A-first violates that. Other miners would reject such a block as invalid and refuse to propagate it. Even if some did, the vast majority would not consider it valid, and the next published block (new transactions + proof of work) would extend from a block that didn't have that transaction in it.
Terr_ 9y ago
A side topic you might find interesting, "Miners are not your friends" [0] which focuses on ways that miners have a mechanism and incentive to subtly exploit some badly-made interactions. [0] https://blog.keep.network/miners-arent-your-friends-cde9b6e0e9ac https://blog.keep.network/miners-arent-your-friends-cde9b6e0...
nordsieck 9y ago
No. In bitcoin, you don't spend from an account. You spend "unspent transaction output" or UTXO. There is no unspent transaction that B owns, so any transaction B creates to send money to C is invalid.
- tylersmith 9y ago
  They can't actually do it simultaneously but after A sends to B, B can create a transaction spending that output to C and both transactions can occur in the same block.
gtrubetskoy 9y ago
Yes (as sly010 pointed out), here is an example: https://blockchain.info/tx/cffa18e3d519c31c8624fc2c3e498c0d9bfc64d009b23c3b076a50faa0048240 https://blockchain.info/tx/cffa18e3d519c31c8624fc2c3e498c0d9... https://blockchain.info/tx/f24eaa493071e96f5bdf931204b8930989f1563505ac28f7237d74bab7ee143f https://blockchain.info/tx/f24eaa493071e96f5bdf931204b893098... Both transactions are in the same block (203732), the f24eaa tx is spending an output of cffa18.
- joeblau 9y ago
  None of the addresses in your examples are the same.
  - gtrubetskoy 9y ago
    >None of the addresses in your examples are the same. Check again: the first TX pays to 12Pws7qasVjt7uKfT6woQptx1MLNj2mo44, the second spends from it.
deleted 9y ago
[deleted]
deleted 9y ago
[deleted]
drdrey 9y ago
B would need to refer to a transaction output that has at least 1 BTC to be able to sign a transaction sending 1 BTC to B. Until A's transaction is included in a block, B can not do that.
- rpearl 9y ago
  > Until A's transaction is included in a block, B can not do that. This is just not true at all? for B to refer to A, it needs to know the transaction id. Transaction ids are sha256(sha256(raw_transaction)) and a raw transaction consists of inputs and outputs. All this is known before the transaction gets put in a block--and has nothing to do with blocks. Blocks and mining mitigate against double spending (...by burning an insanely huge amount of energy to do so, inefficiently. But that's a separate issue, at least right here)
  - drdrey 9y ago
    But is it valid to refer to a transaction hash that only exists in the mempool? The transaction you refer to has to exist in history, which means it has to live on the longest chain, no?
rocqua 9y ago
Yes, and this actually has a use. You can use this to increase the fee of a transaction after the fact. So, suppose A has a fee of 0.001 in the first transaction, and the current fee needs to be 0.01 . Then, B has this transaction, but no-one will put it into a block, so B hasn't really received his money yet. A could sign another transaction with a higher fee that would send the money back to A. This could happen until the original transaction was actually deep enough in the chain. But using your situation, B can do the same thing as A. B can create a transaction sending his own 0.999 BTC to another address of his, and include a fee here of 0.019 . In this fee, there is 0.01 to fund this transaction, and another 0.009 to fund the fee A forgot to include. Miners will see this, and include both transactions, and B is guaranteed he has his money.
- discussedbefore 9y ago
  > increase the fee of a transaction after the fact Someone should have volunteered to help the Pineapple Fund do this instead of switching to Bitcoin Cash (or maybe this is what "Child-Pays-For-Parent" is, and it cost too much). https://news.ycombinator.com/item?id=15995391 https://news.ycombinator.com/item?id=15995391 >> Since this created a series of unconfirmed transactions, we had to do something drastic: use Child-Pays-For-Parent with a very significant fee.
  - rocqua 9y ago
    > maybe this is what "Child-Pays-For-Parent" is Yep, this is what that means. The downside is that the 'child' transaction doesn't just pay for the 'parent' transaction, but also for the 'child' transaction itself. If you make the child transaction a really complex one that draws from many parents, that transaction becomes larger (in terms of bytes) and thus becomes more expensive.
xilis 9y ago
I believe the exact scenario you propose is not possible. It cannot happen simultaneously (so A broadcasting his tx - txA and B broadcasting his tx - txB at the same time). However, B can broadcast txB after receiving txA (txB essentially needs to know txA in order to "use" it). The way this works is txA essentially says "send 1BTC I received from some tx to B". txB says "send 1BTC I received from txA to C". So, when creating the txB, B needs txA in order to use it. Keep in mind this has nothing to do with txA or txB being included in blocks. txB can use txA if txA is not yet confirmed (so not in a block), however txB can only be included in a block (so confirmed) if txA is already confirmed in a previous block, or if both transactions are in the same block (this is where the part of a miner "ordering" the transactions from some other replies comes in play).

by xamuel 9y ago

sly010 9y ago

The block is valid only if the transactions are in the correct order, but the miner is incentivized to figure out the right order (specifically incentivized to include as many transactions as possible). Edit: You are always spending a specific input, so to broadcast B->C, B would have to wait for A->B and specifically name that transaction. The miner _could_ receive these transactions out of order, but that should not be an issue.

SilasX 9y ago

The protocol says to only accept valid blocks. Part of being a valid block is "only spend BTC you have". B-to-A-first violates that. Other miners would reject such a block as invalid and refuse to propagate it. Even if some did, the vast majority would not consider it valid, and the next published block (new transactions + proof of work) would extend from a block that didn't have that transaction in it.

Terr_ 9y ago

A side topic you might find interesting, "Miners are not your friends" [0] which focuses on ways that miners have a mechanism and incentive to subtly exploit some badly-made interactions. [0] https://blog.keep.network/miners-arent-your-friends-cde9b6e0e9ac https://blog.keep.network/miners-arent-your-friends-cde9b6e0...

nordsieck 9y ago

No. In bitcoin, you don't spend from an account. You spend "unspent transaction output" or UTXO. There is no unspent transaction that B owns, so any transaction B creates to send money to C is invalid.

tylersmith 9y ago
They can't actually do it simultaneously but after A sends to B, B can create a transaction spending that output to C and both transactions can occur in the same block.

gtrubetskoy 9y ago

Yes (as sly010 pointed out), here is an example: https://blockchain.info/tx/cffa18e3d519c31c8624fc2c3e498c0d9bfc64d009b23c3b076a50faa0048240 https://blockchain.info/tx/cffa18e3d519c31c8624fc2c3e498c0d9... https://blockchain.info/tx/f24eaa493071e96f5bdf931204b8930989f1563505ac28f7237d74bab7ee143f https://blockchain.info/tx/f24eaa493071e96f5bdf931204b893098... Both transactions are in the same block (203732), the f24eaa tx is spending an output of cffa18.

joeblau 9y ago
None of the addresses in your examples are the same.
- gtrubetskoy 9y ago
  >None of the addresses in your examples are the same. Check again: the first TX pays to 12Pws7qasVjt7uKfT6woQptx1MLNj2mo44, the second spends from it.

deleted 9y ago

[deleted]

deleted 9y ago

[deleted]

drdrey 9y ago

B would need to refer to a transaction output that has at least 1 BTC to be able to sign a transaction sending 1 BTC to B. Until A's transaction is included in a block, B can not do that.

rpearl 9y ago
> Until A's transaction is included in a block, B can not do that. This is just not true at all? for B to refer to A, it needs to know the transaction id. Transaction ids are sha256(sha256(raw_transaction)) and a raw transaction consists of inputs and outputs. All this is known before the transaction gets put in a block--and has nothing to do with blocks. Blocks and mining mitigate against double spending (...by burning an insanely huge amount of energy to do so, inefficiently. But that's a separate issue, at least right here)
- drdrey 9y ago
  But is it valid to refer to a transaction hash that only exists in the mempool? The transaction you refer to has to exist in history, which means it has to live on the longest chain, no?

rocqua 9y ago

Yes, and this actually has a use. You can use this to increase the fee of a transaction after the fact. So, suppose A has a fee of 0.001 in the first transaction, and the current fee needs to be 0.01 . Then, B has this transaction, but no-one will put it into a block, so B hasn't really received his money yet. A could sign another transaction with a higher fee that would send the money back to A. This could happen until the original transaction was actually deep enough in the chain. But using your situation, B can do the same thing as A. B can create a transaction sending his own 0.999 BTC to another address of his, and include a fee here of 0.019 . In this fee, there is 0.01 to fund this transaction, and another 0.009 to fund the fee A forgot to include. Miners will see this, and include both transactions, and B is guaranteed he has his money.

discussedbefore 9y ago
> increase the fee of a transaction after the fact Someone should have volunteered to help the Pineapple Fund do this instead of switching to Bitcoin Cash (or maybe this is what "Child-Pays-For-Parent" is, and it cost too much). https://news.ycombinator.com/item?id=15995391 https://news.ycombinator.com/item?id=15995391 >> Since this created a series of unconfirmed transactions, we had to do something drastic: use Child-Pays-For-Parent with a very significant fee.
- rocqua 9y ago
  > maybe this is what "Child-Pays-For-Parent" is Yep, this is what that means. The downside is that the 'child' transaction doesn't just pay for the 'parent' transaction, but also for the 'child' transaction itself. If you make the child transaction a really complex one that draws from many parents, that transaction becomes larger (in terms of bytes) and thus becomes more expensive.

xilis 9y ago

I believe the exact scenario you propose is not possible. It cannot happen simultaneously (so A broadcasting his tx - txA and B broadcasting his tx - txB at the same time). However, B can broadcast txB after receiving txA (txB essentially needs to know txA in order to "use" it). The way this works is txA essentially says "send 1BTC I received from some tx to B". txB says "send 1BTC I received from txA to C". So, when creating the txB, B needs txA in order to use it. Keep in mind this has nothing to do with txA or txB being included in blocks. txB can use txA if txA is not yet confirmed (so not in a block), however txB can only be included in a block (so confirmed) if txA is already confirmed in a previous block, or if both transactions are in the same block (this is where the part of a miner "ordering" the transactions from some other replies comes in play).