Bitcoin Forum
April 18, 2024, 08:32:21 PM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Limited use proof of burn system  (Read 1274 times)
TierNolan (OP)
Legendary
*
Offline Offline

Activity: 1232
Merit: 1083


View Profile
July 01, 2013, 01:15:58 PM
 #1

This would be a modified version of the proof of burn system.

Each mining "rig" would generate a stream of hashes, one per second.

Hash(id + timestamp) / burn

The id would be hash(hash of the burning tx + blocks headers for the 100 blocks (including at least 1 POW block) after the coins were burnt)

This means that the hash sequence is fully deterministic (after it has been generated). 

Ignoring difficulty changes, each miner would get a set of timestamps where they win a block.  Ties could be broken by the lowest hash (but 2 wins in the same second are low probability).

Virtual miners can claim a block by signing the block header, including the timestamp and hash of the previous header.

However, miners would only be allowed to sign a block once for each "win".

The miner's rig would be destroyed if they sign two blocks with the same timestamp.  A "proof of cheating" block header could be included into the chain if a rig signs twice for the same second.  This sets the POW equivalent for all blocks with the same second to zero and also cancels coinbase/tx fee payout of any blocks that haven't reached coinbase maturity signed by that rig.

If a miner adds a block to a chain and then it is orphaned, then the miner has effectively wasted his low hash value.  This creates an incentive to make sure you only sign the chain that will remain as the main chain.

You need to make sure that the total (real/non-virtual) POW for system is always much higher than the total value of all the coins.  The value can be estimated based on POW difficulty = (total coins) * (hashes per block) / (block reward).  The virtual mining rig target would be set to keep one block per 10 mins, but the POW target could be set to keep sufficient total POW value.  However, using difficulty as an input into calculating difficulty could cause positive feedback.

One issue, in general, is that while the coin's value stays constant, then there is a threshold difficulty.  If the difficulty is to low, you get lots of hashing (since the coin has the best ROI).  OTOH, if it is to high, then you get zero.

Bitcoin doesn't have the issue, since it is the main market for hashing (if its difficulty increases, then demand drops, and that has an effect on market price for hashing).  Small alt-coins are closer to pure-competition for hashing, so they can cross a sudden threshold and go from lots of hashing to almost none.

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
1713472341
Hero Member
*
Offline Offline

Posts: 1713472341

View Profile Personal Message (Offline)

Ignore
1713472341
Reply with quote  #2

1713472341
Report to moderator
Even in the event that an attacker gains more than 50% of the network's computational power, only transactions sent by the attacker could be reversed or double-spent. The network would not be destroyed.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
Remember remember the 5th of November
Legendary
*
Offline Offline

Activity: 1862
Merit: 1011

Reverse engineer from time to time


View Profile
July 01, 2013, 01:23:52 PM
 #2

This proof of burn system sounds a lot like the "Proof of Bitcoins Destroyed" idea I had a few months ago.

BTC:1AiCRMxgf1ptVQwx6hDuKMu4f7F27QmJC2
TierNolan (OP)
Legendary
*
Offline Offline

Activity: 1232
Merit: 1083


View Profile
July 01, 2013, 03:01:30 PM
 #3

This proof of burn system sounds a lot like the "Proof of Bitcoins Destroyed" idea I had a few months ago.

The original wasn't my idea, I was just suggesting making it deterministic. 

If you make the "rigs" generate random hashes (by constantly scrambling the seeds), then a rig can mine on 2 branches of the fork.  A "real" miner has to pick a single fork.  The idea here is to force miners to pick one branch, at the cost of losing the ability of create a block on the other fork.

Do you have a link to your thread?

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!