Bitcoin Forum
November 23, 2017, 06:05:06 AM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 [2]  All
  Print  
Author Topic: Inflation-proofing via fraud notices  (Read 4839 times)
TierNolan
Legendary
*
Offline Offline

Activity: 1120


View Profile
August 02, 2013, 10:28:13 AM
 #21

This could be done with a soft-fork: create a fee merkle hash and put it to the coinbase.

True.

As I said in the other thread on the header, it is probably worth reserving 32 bytes in the coinbase as hash of the auxiliary header.

The auxiliary header can then include any extra info needed at any time in the future, rather than chipping away at the extra nonce.

It is a pity to have 2 merkle trees to calculate.  It would be better to change the merkle tree to a fee tree, but that wouldn't be backwards compatible.

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
1511417106
Hero Member
*
Offline Offline

Posts: 1511417106

View Profile Personal Message (Offline)

Ignore
1511417106
Reply with quote  #2

1511417106
Report to moderator
Join ICO Now A blockchain platform for effective freelancing
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1511417106
Hero Member
*
Offline Offline

Posts: 1511417106

View Profile Personal Message (Offline)

Ignore
1511417106
Reply with quote  #2

1511417106
Report to moderator
1511417106
Hero Member
*
Offline Offline

Posts: 1511417106

View Profile Personal Message (Offline)

Ignore
1511417106
Reply with quote  #2

1511417106
Report to moderator
1511417106
Hero Member
*
Offline Offline

Posts: 1511417106

View Profile Personal Message (Offline)

Ignore
1511417106
Reply with quote  #2

1511417106
Report to moderator
TierNolan
Legendary
*
Offline Offline

Activity: 1120


View Profile
August 02, 2013, 12:42:31 PM
 #22

The list by Mike Hearn for what needs to be checked is:

    This TX (data, branch) has an non-existent input outpoint. Response: client asks any peers it can find to provide the (TX, branch) pair for the connected tx. If one is provide then the error message is invalid.
    This TX has a connected input that doesn't satisfy the outputs script. Response: client checks both transactions are included and then runs the script for itself.
    This TX creates more value than its inputs gather (input transactions are provided along with branches). Response: verify all the data. Not hard.
    This TX double spends. Response: verify that both transactions were included on the same chain (not crossing between forks).
    The coinbase of this block creates more value than allowed. Download the whole block (or do it with your approach of a change to the merkle tree format).

I think the 2 hard ones are the non-existent input and the inflation one.

The inflation one can be solved with the sum-tree.

However, non-existent inputs are harder to prove.  Just because a peer doesn't have a transaction doesn't prove that it doesn't exist.

If we are talking hard forks, then extra info could be added to the merkle-sum tree.

Leaves would be

Hash(path_in1, path_in2, ..., transaction, fee)

For each input, you need to include a path.  With a 20 deep merkle tree, the path is 640 bytes per input.  That is a little expensive, even if blocks were being increased anyway.

A more compact form, would be
<block hash>, <path in bits>

A one would mean right child and a zero would be left child.  I think this is already supported for bloom filtering (or something similar anyway)?

Full nodes don't currently allow random transaction access.  With proper indexing, providing a transaction from (block hash, path) would be much less of a problem.

With pruning, they may simply not have the older transactions.  How does pruning work at the moment?  I assume it doesn't delete the block chain from the disk?

Maybe there could be different levels?

Storage_Node
- serial block download

Pruned_Node
- serial block header download
- new transactions (and notification)
- new blocks (and notification)

Fast_Header_Node
- random access block header download (by height)

Transaction_Node
- random access transaction download

Network_Node
- provides Pruned_Node | Storage_Node

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
Pages: « 1 [2]  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!