Andy Parkins [ARCHIVE] on Nostr: 📅 Original date posted:2011-11-23 🗒️ Summary of this message: A proposal to ...
📅 Original date posted:2011-11-23
🗒️ Summary of this message: A proposal to create a "hardest chain" by forking the blockchain and creating simpler blocks on top of an old block, which could allow the revocation of all transactions and claim all the mined coins since the forked block. The difficulty of invalidating a chain is not reduced with a time window approach, as hashes are hashes, and a higher difficulty beats a lower difficulty, making the chain more secure.
📝 Original message:On 2011 November 23 Wednesday, Christian Decker wrote:
> Just brainstorming here, no idea if this would work:
>
> - Pick any old block
> - Create a chain fork by creating simpler blocks on top of your chosen
> one
> - The chain will not be accepted by others
> - At some point you might find an incredibly hard block that makes your
> forked chain the hardest one in the network
> - Suddenly all your blocks are valid and you force people to switch to
> your forked chain
>
> If this is possible it would allow you to revoke all transactions and claim
> all the mined coins since you forked. My point is that the notion of
> hardest chain is not so simple.
The above is a problem in either system (mine or current). If I can make a
"hardest chain", then I have indeed reverted all the existing transactions.
Look at CBlock::AddToBlockIndex(),
if (pindexNew->bnChainWork > bnBestChainWork)
if (!SetBestChain(txdb, pindexNew))
return false;
If the received block has higher total chain work than the current best chain
work; then the new block becomes the head of the best chain. The chain work
being calculated like this (I've abbreviated for the email):
pindexNew->bnChainWork = pprev->bnChainWork + pindexNew->GetBlockWork()
I'm not entirely convinced that this method of totalling chain work is the
best (it's a sum of exponentials I think); but that's a different issue.
> The difficulty of invalidating a chain is dramatically reduced with your
> time window approach, by not requiring a given difficulty, and relying on
> synchronized time windows.
I don't see that it is reduced; it is the same. Hashes are hashes. A given
difficulty isn't required, but a higher difficulty beats a lower difficulty.
So whatever the hashing power of the network at that moment, it's used. That
makes the chain more secure, not less.
Andy
--
Dr Andy Parkins
andyparkins at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111123/270594a5/attachment.sig>;
🗒️ Summary of this message: A proposal to create a "hardest chain" by forking the blockchain and creating simpler blocks on top of an old block, which could allow the revocation of all transactions and claim all the mined coins since the forked block. The difficulty of invalidating a chain is not reduced with a time window approach, as hashes are hashes, and a higher difficulty beats a lower difficulty, making the chain more secure.
📝 Original message:On 2011 November 23 Wednesday, Christian Decker wrote:
> Just brainstorming here, no idea if this would work:
>
> - Pick any old block
> - Create a chain fork by creating simpler blocks on top of your chosen
> one
> - The chain will not be accepted by others
> - At some point you might find an incredibly hard block that makes your
> forked chain the hardest one in the network
> - Suddenly all your blocks are valid and you force people to switch to
> your forked chain
>
> If this is possible it would allow you to revoke all transactions and claim
> all the mined coins since you forked. My point is that the notion of
> hardest chain is not so simple.
The above is a problem in either system (mine or current). If I can make a
"hardest chain", then I have indeed reverted all the existing transactions.
Look at CBlock::AddToBlockIndex(),
if (pindexNew->bnChainWork > bnBestChainWork)
if (!SetBestChain(txdb, pindexNew))
return false;
If the received block has higher total chain work than the current best chain
work; then the new block becomes the head of the best chain. The chain work
being calculated like this (I've abbreviated for the email):
pindexNew->bnChainWork = pprev->bnChainWork + pindexNew->GetBlockWork()
I'm not entirely convinced that this method of totalling chain work is the
best (it's a sum of exponentials I think); but that's a different issue.
> The difficulty of invalidating a chain is dramatically reduced with your
> time window approach, by not requiring a given difficulty, and relying on
> synchronized time windows.
I don't see that it is reduced; it is the same. Hashes are hashes. A given
difficulty isn't required, but a higher difficulty beats a lower difficulty.
So whatever the hashing power of the network at that moment, it's used. That
makes the chain more secure, not less.
Andy
--
Dr Andy Parkins
andyparkins at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111123/270594a5/attachment.sig>;