Bitcoin Forum
May 13, 2024, 06:18:07 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Multi-pass block validation  (Read 600 times)
TierNolan (OP)
Legendary
*
Offline Offline

Activity: 1232
Merit: 1083


View Profile
June 25, 2015, 05:07:37 PM
 #1

Proof of publication systems require much less complex validation by miners.  Miners just need to check the merkle tree and the POW.  Invalid transactions don't invalidate the block.

This allows stream validation of blocks.  You can start forwarding the block to your peers even before receiving the complete block.  Miners should not build on a block until it is fully received though.

Even SPV nodes could help with proof of publication block forwarding (if the smartphone was charging overnight and had a wireless link).

Proof of publication assumes that >50% of miners are 'honest'.  In this context, it means that they will not build on a block that they have not seen in its entirety and also that they will make the blocks available publicly.

This gives an ordering of transactions (including invalid ones).  A full node would scan all the transactions, in order, and simply discard any invalid ones.

With this system, SPV nodes can't assume that the transactions in the block are valid.  Proving a transaction exists doesn't mean that the transaction is valid.

With a multi-pass system, SPV clients can get some of the benefits restored and historical blocks wouldn't need to store invalid transactions.

This could be implemented as a soft fork.

Each bitcoin block would store the hash of the proof of publication block that is 16 blocks ahead of it.

The bitcoin block can be pre-computed and the hash added to its coinbase.  If you know the publication chain, you can work out the bitcoin block.

Miners just mine the proof of publication chain and naturally produce standard bitcoin blocks that are consistent with the proof of publication chain.  Miners have over 2.5 hours to work out what transactions are in the proof of publication block.

The tail of the bitcoin chain would be 2.5 hours behind the publication chain.  If your transaction gets into the publication chain, then you know it will end up in the bitcoin chain.  Legacy clients would have to wait 2.5 hours though.

The proof of publication blocks would only need to be held for a short time, so they could have a higher size limit.  This would allow miners to include more transactions than are necessary into the block and repeats would be automatically discarded as part of generating the bitcoin block.

For transactions that are more than 2.5 hours old, SPV nodes can check the bitcoin chain.  For newer transactions, they have to trust their peers not to give them invalid information.

If they checked with 8 peers for an outpoint, then at least one of them would probably send the first time that output was spent.  This gives them some double spend protection. 

The proof of publication chain could be arranged to run faster than the bitcoin chain.  Hitting the lower difficulty target advances the proof of publication chain, while hitting the standard bitcoin difficulty advances the bitcoin height and the proof of publication chain height).  Something like the Nimblecoin system could be used to drop the block rate to a few seconds.

If miner fees are out of channel (like a payment channel), miners don't even need to check if the transaction is valid.  Block space is auctioned, which protects against a DoS attack.

Normal fees still work though and even with mini-blocks, the calculated bitcoin block could share the mint fee between all miners on the publication chain.

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
1715624287
Hero Member
*
Offline Offline

Posts: 1715624287

View Profile Personal Message (Offline)

Ignore
1715624287
Reply with quote  #2

1715624287
Report to moderator
1715624287
Hero Member
*
Offline Offline

Posts: 1715624287

View Profile Personal Message (Offline)

Ignore
1715624287
Reply with quote  #2

1715624287
Report to moderator
1715624287
Hero Member
*
Offline Offline

Posts: 1715624287

View Profile Personal Message (Offline)

Ignore
1715624287
Reply with quote  #2

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

Posts: 1715624287

View Profile Personal Message (Offline)

Ignore
1715624287
Reply with quote  #2

1715624287
Report to moderator
1715624287
Hero Member
*
Offline Offline

Posts: 1715624287

View Profile Personal Message (Offline)

Ignore
1715624287
Reply with quote  #2

1715624287
Report to moderator
1715624287
Hero Member
*
Offline Offline

Posts: 1715624287

View Profile Personal Message (Offline)

Ignore
1715624287
Reply with quote  #2

1715624287
Report to moderator
jl2012
Legendary
*
Offline Offline

Activity: 1792
Merit: 1097


View Profile
June 25, 2015, 06:05:42 PM
 #2



The proof of publication blocks would only need to be held for a short time, so they could have a higher size limit.  This would allow miners to include more transactions than are necessary into the block and repeats would be automatically discarded as part of generating the bitcoin block.



What happens if there are too many valid txs and are unable to fit in a bitcoin block?

Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3 (Bitcoin ONLY)
LRDGENPLYrcTRssGoZrsCT1hngaH3BVkM4 (LTC)
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
TierNolan (OP)
Legendary
*
Offline Offline

Activity: 1232
Merit: 1083


View Profile
June 25, 2015, 06:08:54 PM
 #3

What happens if there are too many valid txs and are unable to fit in a bitcoin block?

The excess would just be discarded.  The principle is that once transaction ordering has been established, the system doesn't need to rush working out the final/compacted block.

This means that miners can add transactions into blocks, even if they aren't sure if they have been spent yet. 

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!