4 stars based on
Proof proof of burn bitcoin stocks burn is a method for distributed consensus and an alternative to Proof of Work and Proof of Stake. It can also be used for bootstrapping one cryptocurrency off of another. The idea is that miners should show proof that they burned some coins - that is, sent them to a verifiably unspendable address.
This is expensive from their individual point of view, just like proof of work; but it consumes no resources other than the burned underlying asset. To date, all proof of burn cryptocurrencies work by burning proof-of-work-mined cryptocurrencies, so the ultimate source of scarcity proof of burn bitcoin stocks the proof-of-work-mined "fuel". There are likely many possible variants of proof of burn.
This page currently describes Iain Stewart 's version. Other people can add variant versions that still belong to the broad proof of burn idea. Iain Stewart's version of proof of burn is an attempt at a protocol which could be used within one cryptocurrency for ongoing generation of its blockchain i. For the much simpler task of burning one currency to create another, any reasonable algorithm for creating units of the second currency upon detection of fresh burns of the first will suffice.
The subtleties of this version - in particular, the simulation of mining rigs, and the reliance on low-bit-rate external randomness - will not be necessary. The key idea of proof-of-burn this would proof of burn bitcoin stocks apply to proof-of-stake, by the way is that when choosing the thing which is to qualify as a "difficulty", i. It doesn't need to be the case that real resources are consumed in the real economy. With proof-of-work, it so happens that real resources are indeed consumed - mining rigs are produced, with human labour and materials as input, electricity is used, and proof of burn bitcoin stocks these things have to be bid away from their real-economy best alternative uses.
Or, if they're produced in addition to what would have been produced, the total of leisure time is less than it could have been. Something real is grabbed as input. And while a cryptocurrency is being set up i. And I'm not proposing one. But once a cryptocurrency is up and running, with its initial distribution close to completed, new possibilities arise, for tasks to "feel expensive" to a miner but not actually "be expensive" from a god-like whole-economy perspective.
Proof-of-stake of the "Cunicula proof of burn bitcoin stocks, I mean is proof of burn bitcoin stocks fact arguably already an example of such a task. It feels awfully expensive, to a miner, to save up a lot of bitcoins and become a big stakeholder; but from a whole-economy viewpoint, this is a swapping of assets' ownership labels around, it's not a burning of electricity or the like. However, I thought it would be interesting to invent a task that is absolutely, nakedly, unambiguously an example of the contrast between the two viewpoints.
And yes, there is one: By "burning" a tranche of bitcoins I just mean sending them to an address which is unspendable. The precise technical details of this will vary from cryptocurrency to cryptocurrency. So, the script should do a "deliberately silly" thing - instead of things like "check such-and-such signature, and put the validity result on the stack", it should do something like "add 2 and 2, and now check if what's on top of the stack is equal to 5".
Or just "push 4, and check if it's equal to 5". Anything of that sort. There are thus an unbounded number of such scripts, with entropy saturating RIPEMD since you can choose big numbers to taste. So, bitcoins sent to such a txout can never be redeemed on a future txin. If that happens, the cryptocurrency is proof of burn bitcoin stocks big trouble anyway!
With this definition of burning, it's not obvious to blockchain-watchers that some bitcoins have been burnt, at the time of burning. They've been sent to an address which doesn't stand out from any other.
It's only later, when a miner who burned them earlier now wants to exhibit proof that "yes, these coins are burnt", that blockchain-watchers get their proof of burn bitcoin stocks.
Which basically consists of exhibiting the script that manifestly always evaluates to false, and hashes to the address. If it's thought desirable that the act of burning should be obvious right away, rather than later, then this can be achieved: So, miners are creating candidate winning blocks by saying to the listening world, not "Look!
I've done this many trillion hashes! Two months ago I burned this many bitcoins! In both cases, "this many" means an adjustable difficulty parameter, which the network adjusts from time to time fortnightly, in today's Bitcoin to squeeze out marginal miners and keep more-efficient-than-marginal ones in profit to just the extent needed to regulate block creation to a preferred pace one per 10 minutes, in today's Bitcoin.
Why that phrase "Two months ago"? The broad principle is as follows. A miner mustn't be able to just burn some bitcoins right now and say "OK, I've burned them! Now let me have all those latest juicy transaction fees that have arrived in the past few minutes! That would constitute a breakdown in the analogy of burning with proof-of-work hashing.
A trillion proof-of-work hashes on a pre-reorg block are of no value on the post-reorg chain. And having decided to focus on one, a miner should incur a risk of lost expense if their choice turns out to be "the wrong one" in network consensus terms. The above point makes it clear why the act of burning should be a decent interval earlier than the act of exhibiting proof. Two months may be overdoing it, but the protocol should require it to be sufficiently far back that there's no practical possibility of it being undone.
There are in fact some further issues, to do with making sure it's not cheap for a miner to re-exhibit their proof of having performed a suitably substantial burn a suitably long time ago on multiple competing chains. How much burning will actually happen, under this protocol?
The answer is straightforward enough, though its implications are quite broad and in some ways surprising. Miners will burn bitcoins at an average rate very close to the average rate that ordinary proof of burn bitcoin stocks are sending them fees and any coin-minting still going on too of courseminus the miners' true real-resource costs i.
This follows by the same sort of "approach to equilibrium" reasoning that tells us that miners will expend real resources on proof-of-work to roughly that extent - if they didn't, mining would be supra-normally profitable, and new entrants would be attracted into the trade.
If burning coins, rather than buying a lot of kit from a mining rig supplier, is the expense incurred by a miner to compete for the revenue stream, the same economic principles apply. In this subsection I give a provisional technical sketch of the operational details of the proof-of-burn protocol I've currently settled on.
It can be summed up in the following pithy slogan:. What that slogan means will become clear as I go on. Proof of burn bitcoin stocks, proof-of-work is so elegant, in so many different ways, excepting its high real-resource cost, that I decided my attempt at an alternative to it, avoiding its real-resource cost, should mimic it as faithfully as possible in every other aspect.
Well, only readers can judge whether I've succeeded! The key is to use a stream of true randomness - see below for where that comes from! Now, obviously we don't want to "simulate" every actual hash!
A "simulation" of proof-of-work at that level proof of burn bitcoin stocks detail would just be proof-of-work! Chop up time into units considerably shorter than the intended inter-block time, proof of burn bitcoin stocks with no need to go much finer than general network latency.
Seconds will do, I think. For each second, t, we need a uniform random number between 0 and 1 assigned to it, RAND t. This sounds as if we need some awful dependency on a fragile central source - some high-powered laser at NASA pouring out quantum noise every second, or something - with all the trust and failure issues that would imply.
Fortunately, for simulating mining rigs, we don't need anything like that. All that matters is that, to someone "buying a simulated mining rig" burning some bitcoins, that is!
See introductory motivating section above. It's basically just a generous waiting period to make sure a burnt coin is truly definitely burnt, and won't have any chance of being "unburnt" in a chain reorg, by the time it comes into use in mining. And we don't mind if the stream is known a "short" time into the future - e. Such a lesser goal can, I believe, be achieved with just a few tens of bits of true randomness per week. Quality is what matters, not quantity!
I suggest tapping into the world's most highly-audited source of low-bit-rate true randomness: These the big reputable ones anyway are already subject to elaborate inspection of the machinery that tosses the balls around and draws some of them out. And the results are publicised so widely, in so many newspapers, TV channels, websites etc, as to make it impossible for anyone to lie about them. Roughly weekly, a config-file lottery-results.
There is no hurry about this, it doesn't need to be exactly every week, or even the same lottery every time, it just needs several tens of bits of fresh lottery data added roughly weekly. I believe there would be no trouble propagating this to all nodes, by out-of-band means if necessary. The format should be utterly simple and transparent, a 1-line plain text description of the results and the timestamp t in RAND t from which they are to be paid attention to, onwards.
Obviously the meta-level words proof of burn bitcoin stocks use from Each line is added in a leisurely, proof of burn bitcoin stocks fashion, at some time it doesn't matter when between the draw and the intended start-paying-attention-to-it date.
Some time between and This gives plenty of time for people to add it themselves, from their favourite news source, and check by out-of-band means that they've added what everybody else has added, right down to spelling and punctuation. Which in practice probably means copying it from somewhere. The point is, the "somewhere" doesn't need to be trusted - a lie, or an unexpected variation in format or spelling or punctuation, would be called out well within the leisurely timescale.
RAND t is then HASH config-file [excluding any lines that are "for use from time later than t onwards" of course], plus t itself [in some standard format, e. Thus RAND t is a bit integer, which we regard conceptually as a real number between 0 and 1 by putting a binary point in front.
I'm aware that people on the forums are coming up with randomness protocols for proof-of-stake, proof-of-activity and the like which don't involve external true randomness like lotteries - they just hash the last hundred blocks' hashes together, or something like that. I don't think this is good enough. However, if I'm wrong about this, and hashing the last hundred blocks is in fact fine, then good! We can drop the lottery rigmarole!
Anyway, for the rest of this description, I'll simply assume that RAND t becomes available for all t, but remains unknown until a week or two before t, and in particular, RAND 2 months or more from now is "massively unknown" right now - unknown with many tens to hundreds proof of burn bitcoin stocks bits of unknowable future entropy.
That's all that matters for turning burnt coins into simulated mining rigs. What do we do with this RAND t stream? We simulate the capricious behaviour of a true proof-of-work mining rig! Now, what does it actually mean for proof of burn bitcoin stocks rig to perform h hashes during 1 second?
It means you're producing h uniform random numbers between 0 and proof of burn bitcoin stocks.