Live data from Hacker News

Proof-Of-Work is a Decentralized Clock

grisha.org

11–20 of 130 posts

Re: Proof-Of-Work is a Decentralized Clock

#11
post #2

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…

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.

Re: Proof-Of-Work is a Decentralized Clock

#12
post #2

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…

Yes (as sly010 pointed out), here is an example:

https://blockchain.info/tx/cffa18e3d519c31c8624fc2c3e498c0d9...

https://blockchain.info/tx/f24eaa493071e96f5bdf931204b893098...

Both transactions are in the same block (203732), the f24eaa tx is spending an output of cffa18.

Re: Proof-Of-Work is a Decentralized Clock

#13
post #2

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…

[deleted]

Re: Proof-Of-Work is a Decentralized Clock

#14
post #2

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…

[deleted]

Re: Proof-Of-Work is a Decentralized Clock

#15
post #10
post #7

But it isn’t a clock because it doesn’t tell us how much time has passed. PoW allows for the creation of an ordering. I’m not sure these metaphors are helpful.

I believe the reference is to a vector clock [0] [0] https://en.wikipedia.org/wiki/Vector_clock

That makes a lot more sense, thanks.

Re: Proof-Of-Work is a Decentralized Clock

#16
post #2

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…

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

None of the addresses in your examples are the same.

Re: Proof-Of-Work is a Decentralized Clock

#17
post #16

Earlier quoted context omitted.

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

None of the addresses in your examples are the same.

>None of the addresses in your examples are the same.

Check again: the first TX pays to 12Pws7qasVjt7uKfT6woQptx1MLNj2mo44, the second spends from it.

Re: Proof-Of-Work is a Decentralized Clock

#19
> The Bitcoin Difficulty adjusts dynamically so that a proper hash is found on average once every ten minutes.

So here, the bitcoin network needs to defer to the actual time. The difficulty is adjusted every 2016 blocks. Then, the time it took to create those blocks is determined by looking at actual time stamps of the blocks. That is, time stamps that purport to be the time in UTC when the block was created.

I never understood how these time stamps are trusted and reliable. If I recall correctly, a block with a creation time that is 'too far of' is supposed to be rejected by well behaving nodes. Yet, getting accurate time-stamps is the problem bitcoin is trying to solve.

I suppose that for almost anyone, it is feasible to get time accurate down to 60s and that might be enough that the difficulty calculations aren't affect as much. Especially due to the averaging over 2016 blocks.

edit:

I found this link en.bitcoin.it/wiki/Block_timestamp it states that:

> A timestamp is accepted as valid if it is greater than the median timestamp of previous 11 blocks, and less than the network-adjusted time + 2 hours. "Network-adjusted time" is the median of the timestamps returned by all nodes connected to you.

So the limits are quite loose.

(An interesting footnote from memory)

The difficulty calculation contains a bug where it calculates the average block time ignoring either the first or last block. Thus, the block time is slightly wrong. However, changing this would be a hard-fork because 'the running concensus code is the spec'. That is, if you fix this bug everyone has to fix it at the same time.

Re: Proof-Of-Work is a Decentralized Clock

#20
post #19

> The Bitcoin Difficulty adjusts dynamically so that a proper hash is found on average once every ten minutes. So here, the bitcoin network needs to defer to the actual time. The difficulty is adjusted every 2016 blocks. Then, the time it took to create those blocks is determined by looking at actual time stamps of the blocks. That is, time stamps that purport to be the time in UTC when the block was created. I never…

If you choose a time in the future, other nodes could reject you.

If you choose a time obscenely short (say, 1 second after the last block), presumably the difficulty is an average of many created blocks, and it would take a lot of malicious actors to make this valid.

Plus, if Block A is found at 10:00, and I find Block B at 10:10 but say it was 10:01... and then Block C is found at 10:20, the average of these three is ~10 minutes still.

Post reply on HN