Bitcoin Forum
June 25, 2017, 09:14:29 AM *
News: Latest stable version of Bitcoin Core: 0.14.2  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 [3]  All
  Print  
Author Topic: Auxiliary block: Increasing max block size with softfork  (Read 11686 times)
jl2012
Legendary
*
Offline Offline

Activity: 1624


View Profile
September 17, 2013, 07:58:32 AM
 #41

jl2012: What's interesting about SPV nodes is that because they don't really verify anything, there are cases where a hard-fork for a full node is a soft-fork for a SPV node. One such example is the merkle tree itself - and SPV node wouldn't know the difference if we, say, moved the coinbase transaction to the top of the tree.

Many "simple" hard-forks are transparent to SPV, such as the BIP50 bug fix and increasing MAX_BLOCK_SIZE.

For your example of moving the coinbase transaction to the top of the tree, new full nodes need to somehow cheat the old SPV nodes to make it works. 

More complicated changes, e.g. merkle sum tree, will break SPV nodes

Donation address: 1CxPk7mhhe2uCDosQraSMeCdgvwWHfLSQx
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
Bitcoin Wizards Wiki: https://8333.info/
1498382069
Hero Member
*
Offline Offline

Posts: 1498382069

View Profile Personal Message (Offline)

Ignore
1498382069
Reply with quote  #2

1498382069
Report to moderator
1498382069
Hero Member
*
Offline Offline

Posts: 1498382069

View Profile Personal Message (Offline)

Ignore
1498382069
Reply with quote  #2

1498382069
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1498382069
Hero Member
*
Offline Offline

Posts: 1498382069

View Profile Personal Message (Offline)

Ignore
1498382069
Reply with quote  #2

1498382069
Report to moderator
1498382069
Hero Member
*
Offline Offline

Posts: 1498382069

View Profile Personal Message (Offline)

Ignore
1498382069
Reply with quote  #2

1498382069
Report to moderator
jgarzik
Legendary
*
qt
Offline Offline

Activity: 1470


View Profile
September 17, 2013, 01:23:53 PM
 #42

IMO, even a soft fork is unneeded.

Just make BTC2, which transits upon, and wholly depends upon, BTC.  Have the BTC2 proof-of-work depend on information in the BTC chain, and timestamp BTC2 blocks inside the BTC chain.


Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
Peter Todd
Legendary
*
expert
Offline Offline

Activity: 1078


View Profile
September 17, 2013, 04:13:25 PM
 #43

jl2012: What's interesting about SPV nodes is that because they don't really verify anything, there are cases where a hard-fork for a full node is a soft-fork for a SPV node. One such example is the merkle tree itself - and SPV node wouldn't know the difference if we, say, moved the coinbase transaction to the top of the tree.

Many "simple" hard-forks are transparent to SPV, such as the BIP50 bug fix and increasing MAX_BLOCK_SIZE.

For your example of moving the coinbase transaction to the top of the tree, new full nodes need to somehow cheat the old SPV nodes to make it works.  

More complicated changes, e.g. merkle sum tree, will break SPV nodes

You're not thinking deviously enough.

Lets suppose I define a new merkle-sum-product-christmas-tree which sums all the transaction values up and even distributes presents to the homeless; we'll call the top level digest of that tree D2, and the top level digest of the old merkle tree D1.

Now ask yourself, can a SPV node know if rather than setting hashMerkleRoot to D1 as before, we've set it to Hash(D1 | D2)? A full node certainly can - they have a full list of transactions and will immediately see that something isn't adding up - but what about a SPV node?

Also, it'd be interesting to know if any SPV clients out there would even notice if they were given two transactions, ostensibly from the same block, whose merkle paths back to the block header were of different lengths.

Maged
Legendary
*
Offline Offline

Activity: 1260


View Profile
September 17, 2013, 06:19:45 PM
 #44

IMO, even a soft fork is unneeded.

Just make BTC2, which transits upon, and wholly depends upon, BTC.  Have the BTC2 proof-of-work depend on information in the BTC chain, and timestamp BTC2 blocks inside the BTC chain.
That's essentially what this is. The main (only?) reason that this would require a softfork is that it allows someone to send a transaction from BTC2 back to BTC1. Other than that, it's basically a merged-mined chain.

jl2012
Legendary
*
Offline Offline

Activity: 1624


View Profile
September 18, 2013, 04:28:13 AM
 #45

jl2012: What's interesting about SPV nodes is that because they don't really verify anything, there are cases where a hard-fork for a full node is a soft-fork for a SPV node. One such example is the merkle tree itself - and SPV node wouldn't know the difference if we, say, moved the coinbase transaction to the top of the tree.

Many "simple" hard-forks are transparent to SPV, such as the BIP50 bug fix and increasing MAX_BLOCK_SIZE.

For your example of moving the coinbase transaction to the top of the tree, new full nodes need to somehow cheat the old SPV nodes to make it works.  

More complicated changes, e.g. merkle sum tree, will break SPV nodes

You're not thinking deviously enough.

Lets suppose I define a new merkle-sum-product-christmas-tree which sums all the transaction values up and even distributes presents to the homeless; we'll call the top level digest of that tree D2, and the top level digest of the old merkle tree D1.

Now ask yourself, can a SPV node know if rather than setting hashMerkleRoot to D1 as before, we've set it to Hash(D1 | D2)? A full node certainly can - they have a full list of transactions and will immediately see that something isn't adding up - but what about a SPV node?

Also, it'd be interesting to know if any SPV clients out there would even notice if they were given two transactions, ostensibly from the same block, whose merkle paths back to the block header were of different lengths.

So we have at least 4 levels of hardforks:

Level I hardfork: a hardfork that is completely transparent to SPV nodes, such as the BIP50 bug fix, increasing MAX_BLOCK_SIZE, increasing block reward (too bad!!!)

Level II hardfork: a hardfork that adds new functions while all existing functions are still supported, such as SIGHASH_WITHINPUTVALUE (https://bitcointalk.org/index.php?topic=181734.0) . Old SPV nodes can still function as usual, just not supporting the new function.

Level III hardfork: a hardfork that will partially break SPV nodes, such as fixing the OP_CHECKMULTISIG bug. SPV nodes can still receive bitcoin from bug-fixed OP_CHECKMULTISIG but cannot send with it properly

Level IV hardfork: a hardfork that will completely break SPV nodes, usually something fundamentally change block or transaction format, such as increasing coin divisibility, 64bit block timestamp.

However, this pretty depends on how an SPV node exactly works. With the examples here I assume that SPV will only 1) make sure blocks have adequate PoW; 2) find the chain with highest PoW; 3) look for related transaction outputs in the chain. It would not check the validity of the signature (otherwise SIGHASH_WITHINPUTVALUE signatures of bug-fixed OP_CHECKMULTISIG would look invalid).

Please feel free to add more levels to the list (both softfork and hardfork).

Donation address: 1CxPk7mhhe2uCDosQraSMeCdgvwWHfLSQx
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
Bitcoin Wizards Wiki: https://8333.info/
Pages: « 1 2 [3]  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!