Bitcoin Wiki - User contributions [en]

User:Ids

2018-06-24T22:18:37Z

Ids: contact details meta-notes

'''(real name: Iain Stewart)'''

I worked as a computing lab assistant at Imperial College, London, U.K. from 1991-2011.

I am especially interested in helping to improve Bitcoin's usability from a non-tech-savvy user's perspective. By this I don't just mean GUI improvements and the like - plenty of people far more talented than me are working on that - but changes to the network protocol itself that will help with responsiveness from a merchant's or customer's point of view, while not compromising cryptographic security, decentralization, or the strength of the blockchain.

I have a provisional proposal, which I call [[Adaptive_difficulty|adaptive difficulty]], which I believe will help with this. Comments and feedback welcome. ''['''EDIT 2012-11-22:''' [https://bitcointalk.org/index.php?topic=79837.0 Meni Rosenfeld's adaptive difficulty proposal] effectively contains and subsumes mine. Please give comments and feedback there.]''

You might also be interested in a proof-of-stake-based system which I at least provisionally believe can be made extraordinarily robust! I call it "[[Proof_of_blockchain_fair_sharing|proof of blockchain fair sharing]]". (That page is currently just a teaser description, sketching the idea and why it doesn't contradict an "obvious" theorem on >50% attacks; followed by a forum post where I speculate on possible broader approaches to the >50% attack problem.)

I've just begun development of [[Splash]] - a fork of [https://ripple.com/ Ripple] where the built-in currency is mined by proof of work a la Bitcoin, rather than just magicked into RippleLabs's ownership by software fiat at the start. Forum announcement to follow shortly I hope.

Last but, I hope, not least: I offer [[Proof_of_burn|proof of burn]] as an alternative to both proof of work and proof of stake (though perhaps closer in spirit to the latter), with many interesting properties and economic consequences, the exploration of which has barely begun.

I can be contacted at iain dot david dot stewart at gmail dot com.

''[To H...4 on localbitcoins: I haven't forgotten you said you wanted to see some titbits of research in progress... if you contact me at the above, I can reply with things you may find interesting... (you could of course use a throwaway e-mail address, if you don't want me to know your "real" e-mail address!)]''

''[To, uh, everyone I suppose: yes, I know the above stuff is now very out of date. And, in fact, my opinions have changed about some of it. I'll try to update it all real soon now. (Famous last words!)]''

Proof of burn

2014-10-19T10:24:37Z

Ids: /* Introduction and motivation */ added preamble distinguishing the usage case of this version of proof of burn from situations where much simpler algorithms will suffice

'''Proof of burn''' is method 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 remains the proof-of-work-mined "fuel".

There are likely many possible variants of proof of burn. This page currently describes [[User:Ids|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 ==

''('''Note:''' 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.e. mining). 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.)''

=== Introduction and motivation ===

The key idea of proof-of-burn (this would also apply to proof-of-stake, by the way) is that when choosing the thing which is to qualify as a "difficulty", i.e. to require miners to exhibit proof that they've "done something that's tough to do", all that matters is that ''an individual miner'' finds the task expensive. (Well... it also matters that everyone else should find it cheap to verify that it has been done.) 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 all 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.e. [the fast early phase of] its initial distribution) - or, more precisely, while ''the first'' cryptocurrency is being set up; more on this distinction later! - no good alternative has been proposed. (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 variety", I mean) is in 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: burning the currency!

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. With Bitcoin, any address which is [the RIPEMD160/SHA256 hash of] a script that evaluates to false will do. 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 RIPEMD160 since you can choose big numbers to taste. So, bitcoins sent to such a txout can never be redeemed on a future txin. (Barring the cracking of RIPEMD160 and the finding of an alternative matching script, that is. If ''that'' happens, the cryptocurrency is in 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. (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: burning merely needs to be defined as sending to some ''fixed'' unspendable address, with no variation - e.g. we could settle on the hash of "push 4, and check if it's equal to 5".

So, miners are creating candidate winning blocks by saying to the listening world, not "Look! I've done this many trillion hashes! [or struck lucky with fewer: you, the listening world, wouldn't know the difference... but this doesn't matter...]", but rather "Look! 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! Thanks!" That extremely recent act of burning could be undone in a block chain reorganisation; and then the same miner would be able to "re-burn" those same coins in an attempt to grab a block afresh, post-reorganisation. 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. A proof-of-work miner must simply shrug and say "Oh well, that's those expenses [electricity, mining rig rental / imputed rental,...] lost and gone... time to try again!" And that's the way things should be, for security - it '''should not''' be as cheap to extend the height of two or more competing chains as it is to focus on one. (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. Details to follow.

Now then! 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 users are sending them fees (and any coin-minting still going on too of course), minus the miners' true real-resource costs (i.e. the hardware and electricity and the like for handling transactions and blocks and burn proofs - these costs will be far lower than the hashing costs incurred under proof-of-work, but of course still non-zero). 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.

=== Technical sketch of proof of burn: "Burnt coins are mining rigs!" ===

''Iain Stewart writes:'' 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:

'''''"Burnt coins are mining rigs!"'''''

What that slogan means will become clear as I go on. Basically, 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! - to simulate the generating of random hashes that a real proof-of-work mining rig would produce. Now, obviously we don't want to "simulate" every actual hash! A "simulation" of proof-of-work at ''that'' level of detail would just ''be'' proof-of-work! Rather, we want to mimic the statistical properties of a mining rig's stream of hashes, to just the level of detail required to give the same sort of pattern of meeting / not meeting a moving difficulty target, and all the rest of it, that we get with the real thing.

So: first of all, what exactly is my "stream of true randomness"? Chop up time into units considerably shorter than the intended inter-block time, but 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!) at time t, they can't predict the value of RAND(any t' 2 months or more to the future of t). [Where "2 months" means the dead time a burnt coin must wait before it becomes a simulated active mining rig. 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.] We do '''not''' need fresh statistical independence of RAND(t) w.r.t. all of RAND(t-1), RAND(t-2), RAND(t-3), etc. (And we don't mind if the stream is known a "short" time into the future - e.g. a week or two; at any rate a small portion of the waiting period.)

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: lotteries. 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.dat or whatever) should get "the latest lottery results" appended to it. 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. Like this:

.
.
.
for use from 2013-06-24 00:00:00 onwards: UK national lottery 2013-06-12: 4 9 20 22 37 42, bonus ball 19
for use from 2013-07-01 00:00:00 onwards: UK national lottery 2013-06-19: 7 12 14 19 33 41, bonus ball 28

(Obviously the meta-level words "for use from... onwards" aren't really needed - I just put them in for clarity.) Each line is added in a leisurely, unhurried fashion, at some time (it doesn't matter when) between the draw and the intended start-paying-attention-to-it date. (Some time between 2013-06-19 and 2013-07-01 00:00:00, in the case of the example last line above.) 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.g. 2013-07-02 23:14:05, or just the Unix numeric time] as a final line). - Or if you like, HASH(HASH(config-file) ++ t), for efficiency. (Where "++" means "append together in some standard fashion".) "HASH()" is your favourite hash function, e.g. SHA256(SHA256()). Thus RAND(t) is a 256-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. [For their application or for mine!] Someone producing the latest block, given the previous 99, can privately produce billions of cheap variations on it, by varying the order the transactions are listed etc, until they find, and publish, the one that "games" the randomness in their favour. 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 of bits of unknowable future entropy. That's all that matters for turning burnt coins into simulated mining rigs.)

Right then! What do we do with this RAND(t) stream? We simulate the capricious behaviour of a true proof-of-work mining rig! Let us assume that, in the real proof-of-work world, you can buy an h hashes/second mining rig for b=c*h BTC. (c varies with technical progress, BTC price fluctuations, etc; but in the simulated world it can just be left constant.) Or, inverting this, if you spend b BTC, you acquire a mining rig of h=b/c hashes/s power. Now, what does it actually mean for your rig to perform h hashes during 1 second? It means you're producing h uniform random numbers between 0 and 1. (That binary point again!) But you don't really care what they all are individually - how well you did during that 1 second is defined as "what was the '''lowest''' hash value you produced during that 1 second?". This is then inspected for whether it beats [is lower than] the network's current target; or, perhaps, whether it beats the lesser [i.e. numerically greater] target of a pooled mining operation. If it's good enough, that precious lowest hash is published to the network (or mining pool), and the others are just thrown away (not published). If it's not good enough, even the [not-so-]precious lowest hash isn't published - and certainly not the others. So, in the simulation, we only need to produce, for each second, a simulated "lowest hash for that 1 second". The "others" don't have to exist at all!

For reproducing (statistically) the pattern of hits and misses w.r.t. targets tough enough to not be achieving several hits within 1 second, and for h>>1, we can take the simulated lowest hash for time t to be (1/h) * HASH(signatures-of-the-act-of-burning-the-b-BTC ++ RAND(t)). [In fact this even works for h<1, despite the rather surreal appearance of "lowest hashes" >1 every so often in that case - i.e. values outside the range that ''real'' lowest (or any other!) hashes can ever actually be: it turns out this surreal behaviour is just what's needed to degrade the probability of beating the target by just the right amount. Values >1 in effect represent "I didn't generate any hashes at all during this particular 1-second window".]

Two further subtleties. First of all, it turns out to be desirable to include the block number (chain height @ 1 per block) in the formula - just to keep the owners of simulated mining rigs "on their toes" and not be able to tell a week or so in advance when they'll be lucky. (This encourages them to run a continuous full node. Maybe that's not in fact that important.) So we take simulated-lowest-hash = (1/h) * HASH(signatures-of-the-act-of-burning-the-b-BTC ++ block-number-of-would-be-block ++ RAND(t)). (We should '''not''' include finer details of the block, to avoid "gaming" a la the hundred blocks business I mentioned earlier. - Or if I'm wrong about that, then OK, by all means mix in finer details of the block!)

Secondly, it turns out that to keep the burning process going forever, rather than a pulse of initial burning that no-one ever again wants to contribute further burning to, we should simulate one more property of real-world mining rigs: they break down! That is, we should demurrage away the strength of a simulated mining rig. (A plea to the reader: Don't be alarmed by the word "demurrage". This is '''burnt''' coins I'm talking about - they ''should'' be treated "harshly", in whatever style mimics real-world mining rigs to the required fidelity. Ordinary unburnt coins are not being demurraged! [Unless that's independently desirable as a policy matter, e.g. if it's felt that network strength can only be achieved via more revenue for miners than fees alone will ever provide.]) A real mining rig likely works at full tilt for a few years and then conks out. We ''could'' demurrage each burnt coin in that style - it abruptly expires E years after its creation - but I think a smooth exponential demurrage is nicer, i.e. its burnt value after y years is b'=b*exp(-y/E). Thus h = b'/c = (b/c)*exp(-y/E). [And 1/h = c/b' = (c/b)*exp(y/E).]

Taking these two further subtleties into account, we get the following formula:

simulated-lowest-hash(t) = (c/b)*exp([t - t_burning]/E) * HASH(signatures-of-the-act-of-burning-the-b-BTC ++ block-number-of-would-be-block ++ RAND(t)).

So there you have it! With this formula, life as a miner is spookily similar to the real proof-of-work case. You "buy a mining rig" - you burn coins, and that hits ''you'' in exactly the way sending off money to a chip supplier would have hit you, even though over the whole economy, no real resources have been expended - and you then hope that, by submitting lucky hashes to the network in the form of blocks, you can make more back in fees over time than you spent initially. If you don't keep connected to the network, you won't know what transactions are eligible for including in your next would-be block, and your next lucky hash will run to waste. Meanwhile, other people are "buying mining rigs" (burning coins) too, either freshly or to make up for the "wearing out" of their existing ones; and the network is adjusting its target hash value [reciprocal difficulty] to regulate the rate all this mining effort is producing blocks at, to some preferred average rate. All spookily normal, in other words!

Now, I'm being a little bit disingenuous to say that ''everything'' is normal. We need protection against certain things (use of a lucky hash on two or more competing chains; timestamp-falsification abuse) which either do not exist at all under true proof-of-work - the former - or exist but with the consequences and mitigation strategy being different in detail - the latter. I believe I have a way of standing up to the various forms of malice we need to worry about of those kinds. More to follow soon hopefully!

=== Economic implications ===

The key insight is that verifiably, publicly burning some coins of a known-total-stock-issued currency is the same as "remurrage" (opposite of "demurrage" - it may not be a correct word, but it's a nice back-formation) on the remainder. That is, if there are verifiably 21 million issued-and-not-burned coins, and then you go to sleep and wake up later and there are now only 20 million issued-and-not-burned coins, that's the same as if some magic genie multiplied all wake-up-time nominal bitcoin figures by 21/20. Another way to see the identity of real effect would be to redefine "burning n bitcoins" to mean, not "sending n to an unspendable address", but rather "scattering" the n bitcoins, i.e. sending them to '''every existing''' [non-zero-balance] address, in proportion to the balance [sum of unspent txouts] already stored in each. This would be a horribly gigantic transaction to actually do explicitly, but the point is, burning can be thought of "as if" done that way. (Slogan: Quantity-deflation is remurrage in disguise, in exactly the same way that quantity-inflation is demurrage in disguise.)

So, what ''that'' means is, if while you're sleeping you (a non-miner) hold 1 bitcoin purely passively, i.e. it just sits undisturbed on the blockchain, well, when you wake up, it's as if you've received a "dividend" (of 5% in the particular numeric example above) on top of the general economy-tracking price we expect of a constant-quantity currency. In a world with actual, visibly performed remurrage, this is made explicit - your balance is now 21/20, with the nominal circulation [issued-and-not-burned, and remurraged for good measure] constant at 21 million. You can go and spend the 1/20 "dividend" on some treat, and still have the same fraction (1 out of 21 million) of the money stock as when you went to sleep.

In a world ''without'' any attempt at explicit remurrage, the real facts of the situation are (of course!) the same, but their nominal expression is not perhaps so instantly obvious. Your nominal holding is unchanged at 1; but this is now 1 part in 20 million of the whole money stock, not the 1 part in 21 million it was before. So, you can go and spend 1/21 of it on some treat, taking your nominal balance down to 20/21, and ''that'' nominal balance is the same (1 out of 21 million) fraction of the money stock as when you went to sleep.

So, basically, if you're holding bitcoins and trying to hold an "economy-tracking amount", no more and no less, you find you can go out into the market and use the fraction of your holdings that counts as "dividend above and beyond economy-tracking" on some treat or other. (Indeed, "you can go out..." should read "you ''must'' go out...", if you're really determined to pursue precisely that tracking strategy.)

Who's selling you the real resources embodied in the "treat"? And what's ''their'' motive? Well, transaction fee payers presumably like to re-stock their bitcoin real balances to roughly the same [economy-tracking] level as before, on average - they're paying for the transaction processing as a service. These fees are then burned by miners. (Well, not literally the fees themselves - the fees themselves are ''collected'' by miners, but the way they achieve this is to burn an approximately equal amount, as explained earlier.) So, ordinary Bitcoin users, to achieve their desired re-stocking, have to either produce slightly more, or consume slightly less, or a proper or improper mixture thereof, than they would have needed to in a hypothetical (presumably impracticable) alternative world where they pay no fees for their everyday transactions (and some magic mining-god just altruistically and reliably creates a blockchain out of all the transactions, without charging anybody anything). [This follows directly from their re-stocking desire, and has nothing to do with proof-of-burn specifically. That is, they have to do this regardless of whether the protocol is proof-of-work, proof-of-stake, proof-of-burn or whatever.] It's that extra gap between production and consumption - "extra" on top of whatever gap people are already choosing as a real saving[/dis-saving] strategy - that goes on to the market, for you and all other bitcoin holders to bid off the market by spending on your "treat".

This whole stable pattern of spending habits is, perhaps surprisingly, the same pattern of real resource allocation as would have happened if Cunicula's proof of stake (with close to 100% stake / 0% work admixture) had been in operation, and all bitcoin holders, large and small, had enthusiastically thrown their bitcoins (that is, their stream of bitcoin days destroyed) into the stake-claiming process. The fraction of fees they'd collect if they did that would be just like the "dividend" as I called it above - it would be like explicit remurrage, except instead of being automatic, it would require each holder's active participation (i.e. they couldn't just go to sleep, unless they left some sort of "trusted bot" running and using their private keys to sign their stream of bitcoin days destroyed). So, if you like, proof-of-burn is like automated, 100%-stakeholder-participation Cunicula-style proof-of-stake!

Incidentally, it's also fascinating to consider what happens if the community does decide a demurraging of [ordinary, unburnt] coins, the revenue being added as a coin-[re-]minting stream to the flow of fees, ''is'' necessary to continue with forever, for the sake of network strength. The amazing answer, as far as I can honestly work out, is that in long-run equilibrium, the burn rate is just such as '''to make hardly any of this demurrage ''real'' demurrage at all!''' [The implicit remurrage of burning almost exactly cancels the explicit demurrage of network-strengthening coin-[re-]minting! (Or if you like, the implicit demurrage of inflationary fresh-coin-minting.) Either way, we ''seem'' to get the possibility of amazing network strength "for free"!] This opens up the shocking possibility of turning up the demurrage/inflation rate to startlingly high levels - 5% of money stock / year, 10% of money stock / year... levels that would bring the whole cryptocurrency into disrepute in the true proof-of-work case, since coin-holders really would suffer that actual amount of explicit or implicit demurrage - and yet '''not''' hitting coin-holders with more than a frictional residual fraction of that ''in real terms'' at all, because of the way burning simulates remurrage! Extraordinary stuff! I plan to say more about this soon - but this quick teaser description should already be food for thought.

=== Coin-burning as a tool for transition between cryptocurrencies ===

Proof of burn may also be of interest as a tool for managing an orderly transition from one cryptocurrency ("oldcoin", let's call it) to another ("newcoin"). If the developers of newcoin are looking for a way of avoiding proof-of-work's real resource consumption '''even in newcoin's initial distribution phase''', they can't use proof of newcoin-burn: newcoins don't exist yet. But they ''can'' use proof of oldcoin-burn! (Assuming their reason for creating newcoin is '''not''' a doubting of oldcoin's security model, anyway. - Or at least, not a doubting severe enough to affect sufficiently deeply buried oldcoins, these being the candidates for burning.)

The newcoin blockchain would thus start with (at least a hash referring to) a complete catalogue of all the [sufficiently deeply buried] unspent txouts of oldcoin. Miners would then exhibit burning events within oldcoin up to a certain date; after which, the protocol would switch to burning of newcoin itself (and the dependency on oldcoin could even be thrown away entirely, if a checkpoint of that transition moment was promulgated and accepted by the newcoin community).

This has the nice consequence that, if people throughout the broader economy are gradually deserting oldcoin (as newcoin catches on), '''''its value need not collapse!''''' Instead, oldcoin gets burnt in the transition process, neatly reducing its nominal supply in just such a way as to roughly keep pace with its declining real demand. Meanwhile, those same acts of burning are minting fresh newcoins, at just the pace required to keep up with newcoin's ''growing'' real demand. (At least, that's the case if miners anticipate the transition speed correctly, and enter / exit the coins' respective mining trades at a pace that competes away supra-normal profits. We also have to assume that the ''total'' real demand for both[/all...] cryptocurrencies is roughly stable in "economy-tracking" terms; or at least, that miners anticipate the time path of the size of total real demand, and of its currency-by-currency composition, correctly, or near enough correctly.)

'''To sum up:''' proof of burn ''could'', just maybe, qualify as a new tool to greatly assist overall (multi-cryptocurrency) economic robustness and stability!

== Earlier work suggesting a role for the burning of coins ==

[https://bitcointalk.org/index.php?topic=131139.msg1404195#msg1404195 Forum member ripper234 points out] an earlier work by forum member [https://bitcointalk.org/index.php?action=profile;u=3313 dacoinminster] suggesting coins could be burnt as one component of a broader protocol. [https://bitcointalk.org/index.php?topic=56901.0 The earlier work] is [http://bitcoin.stackexchange.com/questions/2458/is-dacoinminsters-second-bitcoin-whitepaper-logically-economically-consistent discussed on StackExchange]. It revolves around a centralised "trusted entity" system, and so is not directly comparable to decentralised proof-of-burn mining; but it may be of interest to some readers.

== See also ==
*[[Proof_of_work|Proof of work]]
*[[Proof_of_Stake|Proof of stake]]

[[category:mining]]
[[category:proof-of-x]]

User:Ids

2013-12-15T20:48:14Z

Ids: "hard-fork" -> just "fork" (we're talking the code, not the running of it...)

User:Ids

2013-12-15T20:45:32Z

Ids: added Splash! (but explaining it's barely begun of course...)

'''(real name: Iain Stewart)'''

I worked as a computing lab assistant at Imperial College, London, U.K. from 1991-2011.

I am especially interested in helping to improve Bitcoin's usability from a non-tech-savvy user's perspective. By this I don't just mean GUI improvements and the like - plenty of people far more talented than me are working on that - but changes to the network protocol itself that will help with responsiveness from a merchant's or customer's point of view, while not compromising cryptographic security, decentralization, or the strength of the blockchain.

I have a provisional proposal, which I call [[Adaptive_difficulty|adaptive difficulty]], which I believe will help with this. Comments and feedback welcome. ''['''EDIT 2012-11-22:''' [https://bitcointalk.org/index.php?topic=79837.0 Meni Rosenfeld's adaptive difficulty proposal] effectively contains and subsumes mine. Please give comments and feedback there.]''

You might also be interested in a proof-of-stake-based system which I at least provisionally believe can be made extraordinarily robust! I call it "[[Proof_of_blockchain_fair_sharing|proof of blockchain fair sharing]]". (That page is currently just a teaser description, sketching the idea and why it doesn't contradict an "obvious" theorem on >50% attacks; followed by a forum post where I speculate on possible broader approaches to the >50% attack problem.)

I've just begun development of [[Splash]] - a hard-fork of [https://ripple.com/ Ripple] where the built-in currency is mined by proof of work a la Bitcoin, rather than just magicked into RippleLabs's ownership by software fiat at the start. Forum announcement to follow shortly I hope.

Last but, I hope, not least: I offer [[Proof_of_burn|proof of burn]] as an alternative to both proof of work and proof of stake (though perhaps closer in spirit to the latter), with many interesting properties and economic consequences, the exploration of which has barely begun.

I can be contacted at iain dot david dot stewart at gmail dot com.

Script

2013-08-19T07:07:40Z

Ids: /* Standard Transaction to Bitcoin address (pay-to-script-hash) */ renamed to pay-to-pubkey-hash: the phrase pay-to-script-hash (abbr. P2SH) has come to mean a specific, different thing than this!

Bitcoin uses a scripting system for [[transactions]]. [[Wikipedia:FORTH|Forth]]-like, Script is simple, stack-based, and processed from left to right. It is purposefully not Turing-complete, with no loops.

A script is essentially a list of instructions recorded with each transaction that describe how the next person wanting to spend the Bitcoins being transferred can gain access to them. The script for a typical Bitcoin transfer to destination Bitcoin address D simply encumbers future spending of the bitcoins with two things: the spender must provide
# a public key that, when hashed, yields destination address D embedded in the script, and
# a signature to show evidence of the private key corresponding to the public key just provided.

Scripting provides the flexibility to change the parameters of what's needed to spend transferred Bitcoins. For example, the scripting system could be used to require two private keys, or a combination of several, or even no keys at all.

A transaction is valid if nothing in the combined script triggers failure and the top stack item is true (non-zero). The party who originally ''sent'' the Bitcoins now being spent, dictates the script operations that will occur ''last'' in order to release them for use in another transaction. The party wanting to spend them must provide the input(s) to the previously recorded script that results in those operations occurring last leaving behind true (non-zero).

Scripts are big-endian.

The stacks hold byte vectors. Byte vectors are interpreted as little-endian variable-length integers with the most significant bit determining the sign of the integer. Thus 0x81 represents -1. 0x80 is another representation of zero (so called negative 0). Byte vectors are interpreted as Booleans where False is represented by any representation of zero, and True is represented by any representation of non-zero.

== Words ==
This is a list of all Script words (commands/functions). Some of the more complicated opcodes are disabled out of concern that the client might have a bug in their implementation; if a transaction using such an opcode were to be included in the chain any fix would risk forking the chain.

True=1 and False=0.

=== Constants ===
When talking about scripts, these value-pushing words are usually omitted.

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Input
!Output
!Description
|-
|OP_0, OP_FALSE
|0
|0x00
|Nothing.
|(empty value)
|An empty array of bytes is pushed onto the stack. (This is not a no-op: an item is added to the stack.)
|-
|N/A
|1-75
|0x01-0x4b
|(special)
|data
|The next ''opcode'' bytes is data to be pushed onto the stack
|-
|OP_PUSHDATA1
|76
|0x4c
|(special)
|data
|The next byte contains the number of bytes to be pushed onto the stack.
|-
|OP_PUSHDATA2
|77
|0x4d
|(special)
|data
|The next two bytes contain the number of bytes to be pushed onto the stack.
|-
|OP_PUSHDATA4
|78
|0x4e
|(special)
|data
|The next four bytes contain the number of bytes to be pushed onto the stack.
|-
|OP_1NEGATE
|79
|0x4f
|Nothing.
| -1
|The number -1 is pushed onto the stack.
|-
|OP_1, OP_TRUE
|81
|0x51
|Nothing.
|1
|The number 1 is pushed onto the stack.
|-
|OP_2-OP_16
|82-96
|0x52-0x60
|Nothing.
|2-16
|The number in the word name (2-16) is pushed onto the stack.
|}

=== Flow control ===

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Input
!Output
!Description
|-
|OP_NOP
|97
|0x61
|Nothing
|Nothing
|Does nothing.
|-
|OP_IF
|99
|0x63
| colspan="2"|<expression> if [statements] [else [statements]]* endif
|If the top stack value is not 0, the statements are executed. The top stack value is removed.
|-
|OP_NOTIF
|100
|0x64
| colspan="2"|<expression> if [statements] [else [statements]]* endif
|If the top stack value is 0, the statements are executed. The top stack value is removed.
|-
|OP_ELSE
|103
|0x67
| colspan="2"|<expression> if [statements] [else [statements]]* endif
|If the preceding OP_IF or OP_NOTIF or OP_ELSE was not executed then these statements are and if the preceding OP_IF or OP_NOTIF or OP_ELSE was executed then these statements are not.
|-
|OP_ENDIF
|104
|0x68
| colspan="2"|<expression> if [statements] [else [statements]]* endif
|Ends an if/else block.
|-
|OP_VERIFY
|105
|0x69
|True / false
|Nothing / False
|'''Marks transaction as invalid''' if top stack value is not true. True is removed, but false is not.
|-
|OP_RETURN
|106
|0x6a
|Nothing
|Nothing
|'''Marks transaction as invalid'''.
|}

=== Stack ===

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Input
!Output
!Description
|-
|OP_TOALTSTACK
|107
|0x6b
|x1
|(alt)x1
|Puts the input onto the top of the alt stack. Removes it from the main stack.
|-
|OP_FROMALTSTACK
|108
|0x6c
|(alt)x1
|x1
|Puts the input onto the top of the main stack. Removes it from the alt stack.
|-
|OP_IFDUP
|115
|0x73
|x
|x / x x
|If the top stack value is not 0, duplicate it.
|-
|OP_DEPTH
|116
|0x74
|Nothing
|<Stack size>
|Puts the number of stack items onto the stack.
|-
|OP_DROP
|117
|0x75
|x
|Nothing
|Removes the top stack item.
|-
|OP_DUP
|118
|0x76
|x
|x x
|Duplicates the top stack item.
|-
|OP_NIP
|119
|0x77
|x1 x2
|x2
|Removes the second-to-top stack item.
|-
|OP_OVER
|120
|0x78
|x1 x2
|x1 x2 x1
|Copies the second-to-top stack item to the top.
|-
|OP_PICK
|121
|0x79
|xn ... x2 x1 x0 <n>
|xn ... x2 x1 x0 xn
|The item ''n'' back in the stack is copied to the top.
|-
|OP_ROLL
|122
|0x7a
|xn ... x2 x1 x0 <n>
|... x2 x1 x0 xn
|The item ''n'' back in the stack is moved to the top.
|-
|OP_ROT
|123
|0x7b
|x1 x2 x3
|x2 x3 x1
|The top three items on the stack are rotated to the left.
|-
|OP_SWAP
|124
|0x7c
|x1 x2
|x2 x1
|The top two items on the stack are swapped.
|-
|OP_TUCK
|125
|0x7d
|x1 x2
|x2 x1 x2
|The item at the top of the stack is copied and inserted before the second-to-top item.
|-
|OP_2DROP
|109
|0x6d
|x1 x2
|Nothing
|Removes the top two stack items.
|-
|OP_2DUP
|110
|0x6e
|x1 x2
|x1 x2 x1 x2
|Duplicates the top two stack items.
|-
|OP_3DUP
|111
|0x6f
|x1 x2 x3
|x1 x2 x3 x1 x2 x3
|Duplicates the top three stack items.
|-
|OP_2OVER
|112
|0x70
|x1 x2 x3 x4
|x1 x2 x3 x4 x1 x2
|Copies the pair of items two spaces back in the stack to the front.
|-
|OP_2ROT
|113
|0x71
|x1 x2 x3 x4 x5 x6
|x3 x4 x5 x6 x1 x2
|The fifth and sixth items back are moved to the top of the stack.
|-
|OP_2SWAP
|114
|0x72
|x1 x2 x3 x4
|x3 x4 x1 x2
|Swaps the top two pairs of items.
|}

=== Splice ===

If any opcode marked as disabled is present in a script, it must abort and fail.

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Input
!Output
!Description
|-
|OP_CAT
|126
|0x7e
|x1 x2
|out
|style="background:#D97171;"|Concatenates two strings. ''disabled.''
|-
|OP_SUBSTR
|127
|0x7f
|in begin size
|out
|style="background:#D97171;"|Returns a section of a string. ''disabled.''
|-
|OP_LEFT
|128
|0x80
|in size
|out
|style="background:#D97171;"|Keeps only characters left of the specified point in a string. ''disabled.''
|-
|OP_RIGHT
|129
|0x81
|in size
|out
|style="background:#D97171;"|Keeps only characters right of the specified point in a string. ''disabled.''
|-
|OP_SIZE
|130
|0x82
|in
|in size
|Returns the length of the input string.
|}

=== Bitwise logic ===

If any opcode marked as disabled is present in a script, it must abort and fail.

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Input
!Output
!Description
|-
|OP_INVERT
|131
|0x83
|in
|out
|style="background:#D97171;"|Flips all of the bits in the input. ''disabled.''
|-
|OP_AND
|132
|0x84
|x1 x2
|out
|style="background:#D97171;"|Boolean ''and'' between each bit in the inputs. ''disabled.''
|-
|OP_OR
|133
|0x85
|x1 x2
|out
|style="background:#D97171;"|Boolean ''or'' between each bit in the inputs. ''disabled.''
|-
|OP_XOR
|134
|0x86
|x1 x2
|out
|style="background:#D97171;"|Boolean ''exclusive or'' between each bit in the inputs. ''disabled.''
|-
|OP_EQUAL
|135
|0x87
|x1 x2
|True / false
|Returns 1 if the inputs are exactly equal, 0 otherwise.
|-
|OP_EQUALVERIFY
|136
|0x88
|x1 x2
|True / false
|Same as OP_EQUAL, but runs OP_VERIFY afterward.
|}

=== Arithmetic ===

Note: Arithmetic inputs are limited to signed 32-bit integers, but may overflow their output.

If any input value for any of these commands is longer than 4 bytes, the script must abort and fail.
If any opcode marked as ''disabled'' is present in a script - it must also abort and fail.

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Input
!Output
!Description
|-
|OP_1ADD
|139
|0x8b
|in
|out
|1 is added to the input.
|-
|OP_1SUB
|140
|0x8c
|in
|out
|1 is subtracted from the input.
|-
|OP_2MUL
|141
|0x8d
|in
|out
|style="background:#D97171;"|The input is multiplied by 2. ''disabled.''
|-
|OP_2DIV
|142
|0x8e
|in
|out
|style="background:#D97171;"|The input is divided by 2. ''disabled.''
|-
|OP_NEGATE
|143
|0x8f
|in
|out
|The sign of the input is flipped.
|-
|OP_ABS
|144
|0x90
|in
|out
|The input is made positive.
|-
|OP_NOT
|145
|0x91
|in
|out
|If the input is 0 or 1, it is flipped. Otherwise the output will be 0.
|-
|OP_0NOTEQUAL
|146
|0x92
|in
|out
|Returns 0 if the input is 0. 1 otherwise.
|-
|OP_ADD
|147
|0x93
|a b
|out
|a is added to b.
|-
|OP_SUB
|148
|0x94
|a b
|out
|b is subtracted from a.
|-
|OP_MUL
|149
|0x95
|a b
|out
|style="background:#D97171;"|a is multiplied by b. ''disabled.''
|-
|OP_DIV
|150
|0x96
|a b
|out
|style="background:#D97171;"|a is divided by b. ''disabled.''
|-
|OP_MOD
|151
|0x97
|a b
|out
|style="background:#D97171;"|Returns the remainder after dividing a by b. ''disabled.''
|-
|OP_LSHIFT
|152
|0x98
|a b
|out
|style="background:#D97171;"|Shifts a left b bits, preserving sign. ''disabled.''
|-
|OP_RSHIFT
|153
|0x99
|a b
|out
|style="background:#D97171;"|Shifts a right b bits, preserving sign. ''disabled.''
|-
|OP_BOOLAND
|154
|0x9a
|a b
|out
|If both a and b are not 0, the output is 1. Otherwise 0.
|-
|OP_BOOLOR
|155
|0x9b
|a b
|out
|If a or b is not 0, the output is 1. Otherwise 0.
|-
|OP_NUMEQUAL
|156
|0x9c
|a b
|out
|Returns 1 if the numbers are equal, 0 otherwise.
|-
|OP_NUMEQUALVERIFY
|157
|0x9d
|a b
|out
|Same as OP_NUMEQUAL, but runs OP_VERIFY afterward.
|-
|OP_NUMNOTEQUAL
|158
|0x9e
|a b
|out
|Returns 1 if the numbers are not equal, 0 otherwise.
|-
|OP_LESSTHAN
|159
|0x9f
|a b
|out
|Returns 1 if a is less than b, 0 otherwise.
|-
|OP_GREATERTHAN
|160
|0xa0
|a b
|out
|Returns 1 if a is greater than b, 0 otherwise.
|-
|OP_LESSTHANOREQUAL
|161
|0xa1
|a b
|out
|Returns 1 if a is less than or equal to b, 0 otherwise.
|-
|OP_GREATERTHANOREQUAL
|162
|0xa2
|a b
|out
|Returns 1 if a is greater than or equal to b, 0 otherwise.
|-
|OP_MIN
|163
|0xa3
|a b
|out
|Returns the smaller of a and b.
|-
|OP_MAX
|164
|0xa4
|a b
|out
|Returns the larger of a and b.
|-
|OP_WITHIN
|165
|0xa5
|x min max
|out
|Returns 1 if x is within the specified range (left-inclusive), 0 otherwise.
|}

=== Crypto ===

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Input
!Output
!Description
|-
|OP_RIPEMD160
|166
|0xa6
|in
|hash
|The input is hashed using RIPEMD-160.
|-
|OP_SHA1
|167
|0xa7
|in
|hash
|The input is hashed using SHA-1.
|-
|OP_SHA256
|168
|0xa8
|in
|hash
|The input is hashed using SHA-256.
|-
|OP_HASH160
|169
|0xa9
|in
|hash
|The input is hashed twice: first with SHA-256 and then with RIPEMD-160.
|-
|OP_HASH256
|170
|0xaa
|in
|hash
|The input is hashed two times with SHA-256.
|-
|OP_CODESEPARATOR
|171
|0xab
|Nothing
|Nothing
|All of the signature checking words will only match signatures to the data after the most recently-executed OP_CODESEPARATOR.
|-
|[[OP_CHECKSIG]]
|172
|0xac
|sig pubkey
|True / false
|The entire transaction's outputs, inputs, and script (from the most recently-executed OP_CODESEPARATOR to the end) are hashed. The signature used by OP_CHECKSIG must be a valid signature for this hash and public key. If it is, 1 is returned, 0 otherwise.
|-
|OP_CHECKSIGVERIFY
|173
|0xad
|sig pubkey
|True / false
|Same as OP_CHECKSIG, but OP_VERIFY is executed afterward.
|-
|OP_CHECKMULTISIG
|174
|0xae
|x sig1 sig2 ... <number of signatures> pub1 pub2 <number of public keys>
|True / False
|For each signature and public key pair, OP_CHECKSIG is executed. If more public keys than signatures are listed, some key/sig pairs can fail. All signatures need to match a public key. If all signatures are valid, 1 is returned, 0 otherwise. Due to a bug, one extra unused value is removed from the stack.
|-
|OP_CHECKMULTISIGVERIFY
|175
|0xaf
|x sig1 sig2 ... <number of signatures> pub1 pub2 ... <number of public keys>
|True / False
|Same as OP_CHECKMULTISIG, but OP_VERIFY is executed afterward.
|}

===Pseudo-words===
These words are used internally for assisting with transaction matching. They are invalid if used in actual scripts.
{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Description
|-
|OP_PUBKEYHASH
|253
|0xfd
|Represents a public key hashed with OP_HASH160.
|-
|OP_PUBKEY
|254
|0xfe
|Represents a public key compatible with OP_CHECKSIG.
|-
|OP_INVALIDOPCODE
|255
|0xff
|Matches any opcode that is not yet assigned.
|}

=== Reserved words ===
Any opcode not assigned is also reserved. Using an unassigned opcode makes the transaction invalid.

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!When used...
|-
|OP_RESERVED
|80
|0x50
|Transaction is invalid unless occuring in an unexecuted OP_IF branch
|-
|OP_VER
|98
|0x62
|Transaction is invalid unless occuring in an unexecuted OP_IF branch
|-
|OP_VERIF
|101
|0x65
|Transaction is invalid even when occuring in an unexecuted OP_IF branch
|-
|OP_VERNOTIF
|102
|0x66
|Transaction is invalid even when occuring in an unexecuted OP_IF branch
|-
|OP_RESERVED1
|137
|0x89
|Transaction is invalid unless occuring in an unexecuted OP_IF branch
|-
|OP_RESERVED2
|138
|0x8a
|Transaction is invalid unless occuring in an unexecuted OP_IF branch
|-
|OP_NOP1-OP_NOP10
|176-185
|0xb0-0xb9
|The word is ignored.
|}

== Scripts ==
This is a list of interesting scripts. Keep in mind that all constants actually use the data-pushing commands above. Note that there is a small number of standard script forms that are relayed from node to node; non-standard scripts are accepted if they are in a block, but nodes will not relay them.

=== Standard Transaction to Bitcoin address (pay-to-pubkey-hash) ===

scriptPubKey: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
scriptSig: <sig> <pubKey>

To demonstrate how scripts look on the wire, here is a raw scriptPubKey:
<pre> 76 A9 14
OP_DUP OP_HASH160 Bytes to push

89 AB CD EF AB BA AB BA AB BA AB BA AB BA AB BA AB BA AB BA 88 AC
Data to push OP_EQUALVERIFY OP_CHECKSIG</pre>

Note: scriptSig is in the input of the spending transaction and scriptPubKey is in the output of the previously unspent i.e. "available" transaction.

Here is how each word is processed:
{| class="wikitable"
|-
! Stack
! Script
! Description
|-
|Empty.
| <sig> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| scriptSig and scriptPubKey are combined.
|-
|<sig> <pubKey>
| OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| Constants are added to the stack.
|-
|<sig> <pubKey> <pubKey>
| OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| Top stack item is duplicated.
|-
|<sig> <pubKey> <pubHashA>
|<pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| Top stack item is hashed.
|-
|<sig> <pubKey> <pubHashA> <pubKeyHash>
|OP_EQUALVERIFY OP_CHECKSIG
| Constant added.
|-
|<sig> <pubKey>
|OP_CHECKSIG
| Equality is checked between the top two stack items.
|-
|true
|Empty.
|Signature is checked for top two stack items.
|}

=== Standard Generation Transaction (pay-to-pubkey) ===

OP_CHECKSIG is used directly without first hashing the public key. By default the reference implementation uses this form for coinbase payment, and scriptPubKeys of this transaction form are recognized as payments to user. The disadvantage of this transaction form is that the whole public key needs to be known in advance, implying longer payment addresses, and that it provides less protection in the event of a break in the ECDSA signature algorithm.

scriptPubKey: <pubKey> OP_CHECKSIG
scriptSig: <sig>

Checking process:
{| class="wikitable"
|-
! Stack
! Script
! Description
|-
|Empty.
|<sig> <pubKey> OP_CHECKSIG
|scriptSig and scriptPubKey are combined.
|-
|<sig> <pubKey>
| OP_CHECKSIG
|Constants are added to the stack.
|-
|true
|Empty.
|Signature is checked for top two stack items.
|}

=== Provably Unspendable/Prunable Outputs ===

The standard way to mark a transaction as provably unspendable is with a scriptPubKey of the following form:

scriptPubKey: OP_RETURN {zero or more ops}

OP_RETURN immediately marks the script as invalid, guaranteeing that no scriptSig exists that could possibly spend that output. Thus the output can be immediately pruned from the UTXO set even if it has not been spent. eb31ca1a4cbd97c2770983164d7560d2d03276ae1aee26f12d7c2c6424252f29 is an example: it has a single output of zero value, thus giving the full 0.125BTC fee to the miner who mined the transaction without adding an entry to the UTXO set. You can also use OP_RETURN to add data to a transaction without the data ever appearing in the UTXO set, as seen in 1a2e22a717d626fc5db363582007c46924ae6b28319f07cb1b907776bd8293fc; [[P2Pool]] does this with the share chain hash txout in the coinbase of blocks it creates.

Note that this mechanism is not yet a standard transaction type, and thus will not be relayed by nodes on mainnet.

=== Anyone-Can-Spend Outputs ===

Conversely a transaction can be made spendable by anyone at all:

scriptPubKey: (empty)
scriptSig: OP_TRUE

With some software changes such transactions can be used as a way to donate funds to miners in addition to transaction fees: any miner who mines such a transaction can also include an additional one after it sending the funds to an address they control. This mechanism may be used in the future for [[fidelity bonds]] to sacrifice funds in a provable way.

Anyone-Can-Spend outputs are currently considered non-standard, and are not relayed on the P2P network.

=== Transaction puzzle ===

Transaction a4bfa8ab6435ae5f25dae9d89e4eb67dfa94283ca751f393c1ddc5a837bbc31b is an interesting puzzle.

scriptPubKey: OP_HASH256 6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000 OP_EQUAL
scriptSig: <data>

To spend the transaction you need to come up with some data such that hashing the data twice results in the given hash.

{| class="wikitable"
|-
! Stack
! Script
! Description
|-
|Empty.
|<data> OP_HASH256 <given_hash> OP_EQUAL
|
|-
|<data>
|OP_HASH256 <given_hash> OP_EQUAL
|scriptSig added to the stack.
|-
|<data_hash>
|<given_hash> OP_EQUAL
|The data is hashed.
|-
|<data_hash> <given_hash>
|OP_EQUAL
|The given hash is pushed to the stack.
|-
|true
|Empty.
|The hashes are compared, leaving true on the stack.
|}

This transaction was successfully spent by 09f691b2263260e71f363d1db51ff3100d285956a40cc0e4f8c8c2c4a80559b1. The required data happened to be the [[Genesis block]], and the given hash was the genesis block hash. Note that while transactions like this are fun, they are not secure, because they do not contain any signatures and thus any transaction attempting to spend them can be replaced with a different transaction sending the funds somewhere else.

==See Also==

* [[Transactions]]
* [[Contracts]]

[[Category:Technical]]
[[Category:Vocabulary]]

Proof of burn

2013-06-07T19:24:15Z

Ids: /* Economic implications */ corrected "fee as processing service payment" wording

'''Proof of burn''' is a potential alternative to [[Proof_of_work|proof of work]] and [[Proof_of_Stake|proof of stake]] as a "scarce resource" to be exhibited by miners competing for the stream of rewards (minted coins and transaction fees) which a cryptocurrency's design makes available. 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 unlike proof of work, it consumes no real resources from a whole economy perspective. This has interesting implications, discussed below.

There are likely many possible variants of proof of burn. This page currently describes [[User:Ids|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 ==

=== Introduction and motivation ===

The key idea of proof-of-burn (this would also apply to proof-of-stake, by the way) is that when choosing the thing which is to qualify as a "difficulty", i.e. to require miners to exhibit proof that they've "done something that's tough to do", all that matters is that ''an individual miner'' finds the task expensive. (Well... it also matters that everyone else should find it cheap to verify that it has been done.) 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 all 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.e. [the fast early phase of] its initial distribution) - or, more precisely, while ''the first'' cryptocurrency is being set up; more on this distinction later! - no good alternative has been proposed. (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 variety", I mean) is in 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: burning the currency!

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. With Bitcoin, any address which is [the RIPEMD160/SHA256 hash of] a script that evaluates to false will do. 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 RIPEMD160 since you can choose big numbers to taste. So, bitcoins sent to such a txout can never be redeemed on a future txin. (Barring the cracking of RIPEMD160 and the finding of an alternative matching script, that is. If ''that'' happens, the cryptocurrency is in 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. (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: burning merely needs to be defined as sending to some ''fixed'' unspendable address, with no variation - e.g. we could settle on the hash of "push 4, and check if it's equal to 5".

So, miners are creating candidate winning blocks by saying to the listening world, not "Look! I've done this many trillion hashes! [or struck lucky with fewer: you, the listening world, wouldn't know the difference... but this doesn't matter...]", but rather "Look! 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! Thanks!" That extremely recent act of burning could be undone in a block chain reorganisation; and then the same miner would be able to "re-burn" those same coins in an attempt to grab a block afresh, post-reorganisation. 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. A proof-of-work miner must simply shrug and say "Oh well, that's those expenses [electricity, mining rig rental / imputed rental,...] lost and gone... time to try again!" And that's the way things should be, for security - it '''should not''' be as cheap to extend the height of two or more competing chains as it is to focus on one. (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. Details to follow.

Now then! 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 users are sending them fees (and any coin-minting still going on too of course), minus the miners' true real-resource costs (i.e. the hardware and electricity and the like for handling transactions and blocks and burn proofs - these costs will be far lower than the hashing costs incurred under proof-of-work, but of course still non-zero). 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.

=== Technical sketch of proof of burn: "Burnt coins are mining rigs!" ===

''Iain Stewart writes:'' 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:

'''''"Burnt coins are mining rigs!"'''''

What that slogan means will become clear as I go on. Basically, 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! - to simulate the generating of random hashes that a real proof-of-work mining rig would produce. Now, obviously we don't want to "simulate" every actual hash! A "simulation" of proof-of-work at ''that'' level of detail would just ''be'' proof-of-work! Rather, we want to mimic the statistical properties of a mining rig's stream of hashes, to just the level of detail required to give the same sort of pattern of meeting / not meeting a moving difficulty target, and all the rest of it, that we get with the real thing.

So: first of all, what exactly is my "stream of true randomness"? Chop up time into units considerably shorter than the intended inter-block time, but 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!) at time t, they can't predict the value of RAND(any t' 2 months or more to the future of t). [Where "2 months" means the dead time a burnt coin must wait before it becomes a simulated active mining rig. 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.] We do '''not''' need fresh statistical independence of RAND(t) w.r.t. all of RAND(t-1), RAND(t-2), RAND(t-3), etc. (And we don't mind if the stream is known a "short" time into the future - e.g. a week or two; at any rate a small portion of the waiting period.)

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: lotteries. 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.dat or whatever) should get "the latest lottery results" appended to it. 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. Like this:

.
.
.
for use from 2013-06-24 00:00:00 onwards: UK national lottery 2013-06-12: 4 9 20 22 37 42, bonus ball 19
for use from 2013-07-01 00:00:00 onwards: UK national lottery 2013-06-19: 7 12 14 19 33 41, bonus ball 28

(Obviously the meta-level words "for use from... onwards" aren't really needed - I just put them in for clarity.) Each line is added in a leisurely, unhurried fashion, at some time (it doesn't matter when) between the draw and the intended start-paying-attention-to-it date. (Some time between 2013-06-19 and 2013-07-01 00:00:00, in the case of the example last line above.) 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.g. 2013-07-02 23:14:05, or just the Unix numeric time] as a final line). - Or if you like, HASH(HASH(config-file) ++ t), for efficiency. (Where "++" means "append together in some standard fashion".) "HASH()" is your favourite hash function, e.g. SHA256(SHA256()). Thus RAND(t) is a 256-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. [For their application or for mine!] Someone producing the latest block, given the previous 99, can privately produce billions of cheap variations on it, by varying the order the transactions are listed etc, until they find, and publish, the one that "games" the randomness in their favour. 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 of bits of unknowable future entropy. That's all that matters for turning burnt coins into simulated mining rigs.)

Right then! What do we do with this RAND(t) stream? We simulate the capricious behaviour of a true proof-of-work mining rig! Let us assume that, in the real proof-of-work world, you can buy an h hashes/second mining rig for b=c*h BTC. (c varies with technical progress, BTC price fluctuations, etc; but in the simulated world it can just be left constant.) Or, inverting this, if you spend b BTC, you acquire a mining rig of h=b/c hashes/s power. Now, what does it actually mean for your rig to perform h hashes during 1 second? It means you're producing h uniform random numbers between 0 and 1. (That binary point again!) But you don't really care what they all are individually - how well you did during that 1 second is defined as "what was the '''lowest''' hash value you produced during that 1 second?". This is then inspected for whether it beats [is lower than] the network's current target; or, perhaps, whether it beats the lesser [i.e. numerically greater] target of a pooled mining operation. If it's good enough, that precious lowest hash is published to the network (or mining pool), and the others are just thrown away (not published). If it's not good enough, even the [not-so-]precious lowest hash isn't published - and certainly not the others. So, in the simulation, we only need to produce, for each second, a simulated "lowest hash for that 1 second". The "others" don't have to exist at all!

For reproducing (statistically) the pattern of hits and misses w.r.t. targets tough enough to not be achieving several hits within 1 second, and for h>>1, we can take the simulated lowest hash for time t to be (1/h) * HASH(signatures-of-the-act-of-burning-the-b-BTC ++ RAND(t)). [In fact this even works for h<1, despite the rather surreal appearance of "lowest hashes" >1 every so often in that case - i.e. values outside the range that ''real'' lowest (or any other!) hashes can ever actually be: it turns out this surreal behaviour is just what's needed to degrade the probability of beating the target by just the right amount. Values >1 in effect represent "I didn't generate any hashes at all during this particular 1-second window".]

Two further subtleties. First of all, it turns out to be desirable to include the block number (chain height @ 1 per block) in the formula - just to keep the owners of simulated mining rigs "on their toes" and not be able to tell a week or so in advance when they'll be lucky. (This encourages them to run a continuous full node. Maybe that's not in fact that important.) So we take simulated-lowest-hash = (1/h) * HASH(signatures-of-the-act-of-burning-the-b-BTC ++ block-number-of-would-be-block ++ RAND(t)). (We should '''not''' include finer details of the block, to avoid "gaming" a la the hundred blocks business I mentioned earlier. - Or if I'm wrong about that, then OK, by all means mix in finer details of the block!)

Secondly, it turns out that to keep the burning process going forever, rather than a pulse of initial burning that no-one ever again wants to contribute further burning to, we should simulate one more property of real-world mining rigs: they break down! That is, we should demurrage away the strength of a simulated mining rig. (A plea to the reader: Don't be alarmed by the word "demurrage". This is '''burnt''' coins I'm talking about - they ''should'' be treated "harshly", in whatever style mimics real-world mining rigs to the required fidelity. Ordinary unburnt coins are not being demurraged! [Unless that's independently desirable as a policy matter, e.g. if it's felt that network strength can only be achieved via more revenue for miners than fees alone will ever provide.]) A real mining rig likely works at full tilt for a few years and then conks out. We ''could'' demurrage each burnt coin in that style - it abruptly expires E years after its creation - but I think a smooth exponential demurrage is nicer, i.e. its burnt value after y years is b'=b*exp(-y/E). Thus h = b'/c = (b/c)*exp(-y/E). [And 1/h = c/b' = (c/b)*exp(y/E).]

Taking these two further subtleties into account, we get the following formula:

simulated-lowest-hash(t) = (c/b)*exp([t - t_burning]/E) * HASH(signatures-of-the-act-of-burning-the-b-BTC ++ block-number-of-would-be-block ++ RAND(t)).

So there you have it! With this formula, life as a miner is spookily similar to the real proof-of-work case. You "buy a mining rig" - you burn coins, and that hits ''you'' in exactly the way sending off money to a chip supplier would have hit you, even though over the whole economy, no real resources have been expended - and you then hope that, by submitting lucky hashes to the network in the form of blocks, you can make more back in fees over time than you spent initially. If you don't keep connected to the network, you won't know what transactions are eligible for including in your next would-be block, and your next lucky hash will run to waste. Meanwhile, other people are "buying mining rigs" (burning coins) too, either freshly or to make up for the "wearing out" of their existing ones; and the network is adjusting its target hash value [reciprocal difficulty] to regulate the rate all this mining effort is producing blocks at, to some preferred average rate. All spookily normal, in other words!

Now, I'm being a little bit disingenuous to say that ''everything'' is normal. We need protection against certain things (use of a lucky hash on two or more competing chains; timestamp-falsification abuse) which either do not exist at all under true proof-of-work - the former - or exist but with the consequences and mitigation strategy being different in detail - the latter. I believe I have a way of standing up to the various forms of malice we need to worry about of those kinds. More to follow soon hopefully!

=== Economic implications ===

The key insight is that verifiably, publicly burning some coins of a known-total-stock-issued currency is the same as "remurrage" (opposite of "demurrage" - it may not be a correct word, but it's a nice back-formation) on the remainder. That is, if there are verifiably 21 million issued-and-not-burned coins, and then you go to sleep and wake up later and there are now only 20 million issued-and-not-burned coins, that's the same as if some magic genie multiplied all wake-up-time nominal bitcoin figures by 21/20. Another way to see the identity of real effect would be to redefine "burning n bitcoins" to mean, not "sending n to an unspendable address", but rather "scattering" the n bitcoins, i.e. sending them to '''every existing''' [non-zero-balance] address, in proportion to the balance [sum of unspent txouts] already stored in each. This would be a horribly gigantic transaction to actually do explicitly, but the point is, burning can be thought of "as if" done that way. (Slogan: Quantity-deflation is remurrage in disguise, in exactly the same way that quantity-inflation is demurrage in disguise.)

So, what ''that'' means is, if while you're sleeping you (a non-miner) hold 1 bitcoin purely passively, i.e. it just sits undisturbed on the blockchain, well, when you wake up, it's as if you've received a "dividend" (of 5% in the particular numeric example above) on top of the general economy-tracking price we expect of a constant-quantity currency. In a world with actual, visibly performed remurrage, this is made explicit - your balance is now 21/20, with the nominal circulation [issued-and-not-burned, and remurraged for good measure] constant at 21 million. You can go and spend the 1/20 "dividend" on some treat, and still have the same fraction (1 out of 21 million) of the money stock as when you went to sleep.

In a world ''without'' any attempt at explicit remurrage, the real facts of the situation are (of course!) the same, but their nominal expression is not perhaps so instantly obvious. Your nominal holding is unchanged at 1; but this is now 1 part in 20 million of the whole money stock, not the 1 part in 21 million it was before. So, you can go and spend 1/21 of it on some treat, taking your nominal balance down to 20/21, and ''that'' nominal balance is the same (1 out of 21 million) fraction of the money stock as when you went to sleep.

So, basically, if you're holding bitcoins and trying to hold an "economy-tracking amount", no more and no less, you find you can go out into the market and use the fraction of your holdings that counts as "dividend above and beyond economy-tracking" on some treat or other. (Indeed, "you can go out..." should read "you ''must'' go out...", if you're really determined to pursue precisely that tracking strategy.)

Who's selling you the real resources embodied in the "treat"? And what's ''their'' motive? Well, transaction fee payers presumably like to re-stock their bitcoin real balances to roughly the same [economy-tracking] level as before, on average - they're paying for the transaction processing as a service. These fees are then burned by miners. (Well, not literally the fees themselves - the fees themselves are ''collected'' by miners, but the way they achieve this is to burn an approximately equal amount, as explained earlier.) So, ordinary Bitcoin users, to achieve their desired re-stocking, have to either produce slightly more, or consume slightly less, or a proper or improper mixture thereof, than they would have needed to in a hypothetical (presumably impracticable) alternative world where they pay no fees for their everyday transactions (and some magic mining-god just altruistically and reliably creates a blockchain out of all the transactions, without charging anybody anything). [This follows directly from their re-stocking desire, and has nothing to do with proof-of-burn specifically. That is, they have to do this regardless of whether the protocol is proof-of-work, proof-of-stake, proof-of-burn or whatever.] It's that extra gap between production and consumption - "extra" on top of whatever gap people are already choosing as a real saving[/dis-saving] strategy - that goes on to the market, for you and all other bitcoin holders to bid off the market by spending on your "treat".

This whole stable pattern of spending habits is, perhaps surprisingly, the same pattern of real resource allocation as would have happened if Cunicula's proof of stake (with close to 100% stake / 0% work admixture) had been in operation, and all bitcoin holders, large and small, had enthusiastically thrown their bitcoins (that is, their stream of bitcoin days destroyed) into the stake-claiming process. The fraction of fees they'd collect if they did that would be just like the "dividend" as I called it above - it would be like explicit remurrage, except instead of being automatic, it would require each holder's active participation (i.e. they couldn't just go to sleep, unless they left some sort of "trusted bot" running and using their private keys to sign their stream of bitcoin days destroyed). So, if you like, proof-of-burn is like automated, 100%-stakeholder-participation Cunicula-style proof-of-stake!

Incidentally, it's also fascinating to consider what happens if the community does decide a demurraging of [ordinary, unburnt] coins, the revenue being added as a coin-[re-]minting stream to the flow of fees, ''is'' necessary to continue with forever, for the sake of network strength. The amazing answer, as far as I can honestly work out, is that in long-run equilibrium, the burn rate is just such as '''to make hardly any of this demurrage ''real'' demurrage at all!''' [The implicit remurrage of burning almost exactly cancels the explicit demurrage of network-strengthening coin-[re-]minting! (Or if you like, the implicit demurrage of inflationary fresh-coin-minting.) Either way, we ''seem'' to get the possibility of amazing network strength "for free"!] This opens up the shocking possibility of turning up the demurrage/inflation rate to startlingly high levels - 5% of money stock / year, 10% of money stock / year... levels that would bring the whole cryptocurrency into disrepute in the true proof-of-work case, since coin-holders really would suffer that actual amount of explicit or implicit demurrage - and yet '''not''' hitting coin-holders with more than a frictional residual fraction of that ''in real terms'' at all, because of the way burning simulates remurrage! Extraordinary stuff! I plan to say more about this soon - but this quick teaser description should already be food for thought.

=== Coin-burning as a tool for transition between cryptocurrencies ===

Proof of burn may also be of interest as a tool for managing an orderly transition from one cryptocurrency ("oldcoin", let's call it) to another ("newcoin"). If the developers of newcoin are looking for a way of avoiding proof-of-work's real resource consumption '''even in newcoin's initial distribution phase''', they can't use proof of newcoin-burn: newcoins don't exist yet. But they ''can'' use proof of oldcoin-burn! (Assuming their reason for creating newcoin is '''not''' a doubting of oldcoin's security model, anyway. - Or at least, not a doubting severe enough to affect sufficiently deeply buried oldcoins, these being the candidates for burning.)

The newcoin blockchain would thus start with (at least a hash referring to) a complete catalogue of all the [sufficiently deeply buried] unspent txouts of oldcoin. Miners would then exhibit burning events within oldcoin up to a certain date; after which, the protocol would switch to burning of newcoin itself (and the dependency on oldcoin could even be thrown away entirely, if a checkpoint of that transition moment was promulgated and accepted by the newcoin community).

This has the nice consequence that, if people throughout the broader economy are gradually deserting oldcoin (as newcoin catches on), '''''its value need not collapse!''''' Instead, oldcoin gets burnt in the transition process, neatly reducing its nominal supply in just such a way as to roughly keep pace with its declining real demand. Meanwhile, those same acts of burning are minting fresh newcoins, at just the pace required to keep up with newcoin's ''growing'' real demand. (At least, that's the case if miners anticipate the transition speed correctly, and enter / exit the coins' respective mining trades at a pace that competes away supra-normal profits. We also have to assume that the ''total'' real demand for both[/all...] cryptocurrencies is roughly stable in "economy-tracking" terms; or at least, that miners anticipate the time path of the size of total real demand, and of its currency-by-currency composition, correctly, or near enough correctly.)

'''To sum up:''' proof of burn ''could'', just maybe, qualify as a new tool to greatly assist overall (multi-cryptocurrency) economic robustness and stability!

== Earlier work suggesting a role for the burning of coins ==

[https://bitcointalk.org/index.php?topic=131139.msg1404195#msg1404195 Forum member ripper234 points out] an earlier work by forum member [https://bitcointalk.org/index.php?action=profile;u=3313 dacoinminster] suggesting coins could be burnt as one component of a broader protocol. [https://bitcointalk.org/index.php?topic=56901.0 The earlier work] is [http://bitcoin.stackexchange.com/questions/2458/is-dacoinminsters-second-bitcoin-whitepaper-logically-economically-consistent discussed on StackExchange]. It revolves around a centralised "trusted entity" system, and so is not directly comparable to decentralised proof-of-burn mining; but it may be of interest to some readers.

== See also ==
*[[Proof_of_work|Proof of work]]
*[[Proof_of_Stake|Proof of stake]]

[[category:mining]]

Proof of burn

2013-06-07T19:16:27Z

Ids: /* Technical sketch of proof of burn: "Burnt coins are mining rigs!" */ markup correction - angle brackets don't work

'''Proof of burn''' is a potential alternative to [[Proof_of_work|proof of work]] and [[Proof_of_Stake|proof of stake]] as a "scarce resource" to be exhibited by miners competing for the stream of rewards (minted coins and transaction fees) which a cryptocurrency's design makes available. 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 unlike proof of work, it consumes no real resources from a whole economy perspective. This has interesting implications, discussed below.

There are likely many possible variants of proof of burn. This page currently describes [[User:Ids|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 ==

=== Introduction and motivation ===

The key idea of proof-of-burn (this would also apply to proof-of-stake, by the way) is that when choosing the thing which is to qualify as a "difficulty", i.e. to require miners to exhibit proof that they've "done something that's tough to do", all that matters is that ''an individual miner'' finds the task expensive. (Well... it also matters that everyone else should find it cheap to verify that it has been done.) 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 all 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.e. [the fast early phase of] its initial distribution) - or, more precisely, while ''the first'' cryptocurrency is being set up; more on this distinction later! - no good alternative has been proposed. (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 variety", I mean) is in 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: burning the currency!

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. With Bitcoin, any address which is [the RIPEMD160/SHA256 hash of] a script that evaluates to false will do. 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 RIPEMD160 since you can choose big numbers to taste. So, bitcoins sent to such a txout can never be redeemed on a future txin. (Barring the cracking of RIPEMD160 and the finding of an alternative matching script, that is. If ''that'' happens, the cryptocurrency is in 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. (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: burning merely needs to be defined as sending to some ''fixed'' unspendable address, with no variation - e.g. we could settle on the hash of "push 4, and check if it's equal to 5".

So, miners are creating candidate winning blocks by saying to the listening world, not "Look! I've done this many trillion hashes! [or struck lucky with fewer: you, the listening world, wouldn't know the difference... but this doesn't matter...]", but rather "Look! 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! Thanks!" That extremely recent act of burning could be undone in a block chain reorganisation; and then the same miner would be able to "re-burn" those same coins in an attempt to grab a block afresh, post-reorganisation. 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. A proof-of-work miner must simply shrug and say "Oh well, that's those expenses [electricity, mining rig rental / imputed rental,...] lost and gone... time to try again!" And that's the way things should be, for security - it '''should not''' be as cheap to extend the height of two or more competing chains as it is to focus on one. (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. Details to follow.

Now then! 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 users are sending them fees (and any coin-minting still going on too of course), minus the miners' true real-resource costs (i.e. the hardware and electricity and the like for handling transactions and blocks and burn proofs - these costs will be far lower than the hashing costs incurred under proof-of-work, but of course still non-zero). 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.

=== Technical sketch of proof of burn: "Burnt coins are mining rigs!" ===

''Iain Stewart writes:'' 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:

'''''"Burnt coins are mining rigs!"'''''

What that slogan means will become clear as I go on. Basically, 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! - to simulate the generating of random hashes that a real proof-of-work mining rig would produce. Now, obviously we don't want to "simulate" every actual hash! A "simulation" of proof-of-work at ''that'' level of detail would just ''be'' proof-of-work! Rather, we want to mimic the statistical properties of a mining rig's stream of hashes, to just the level of detail required to give the same sort of pattern of meeting / not meeting a moving difficulty target, and all the rest of it, that we get with the real thing.

So: first of all, what exactly is my "stream of true randomness"? Chop up time into units considerably shorter than the intended inter-block time, but 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!) at time t, they can't predict the value of RAND(any t' 2 months or more to the future of t). [Where "2 months" means the dead time a burnt coin must wait before it becomes a simulated active mining rig. 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.] We do '''not''' need fresh statistical independence of RAND(t) w.r.t. all of RAND(t-1), RAND(t-2), RAND(t-3), etc. (And we don't mind if the stream is known a "short" time into the future - e.g. a week or two; at any rate a small portion of the waiting period.)

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: lotteries. 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.dat or whatever) should get "the latest lottery results" appended to it. 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. Like this:

.
.
.
for use from 2013-06-24 00:00:00 onwards: UK national lottery 2013-06-12: 4 9 20 22 37 42, bonus ball 19
for use from 2013-07-01 00:00:00 onwards: UK national lottery 2013-06-19: 7 12 14 19 33 41, bonus ball 28

(Obviously the meta-level words "for use from... onwards" aren't really needed - I just put them in for clarity.) Each line is added in a leisurely, unhurried fashion, at some time (it doesn't matter when) between the draw and the intended start-paying-attention-to-it date. (Some time between 2013-06-19 and 2013-07-01 00:00:00, in the case of the example last line above.) 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.g. 2013-07-02 23:14:05, or just the Unix numeric time] as a final line). - Or if you like, HASH(HASH(config-file) ++ t), for efficiency. (Where "++" means "append together in some standard fashion".) "HASH()" is your favourite hash function, e.g. SHA256(SHA256()). Thus RAND(t) is a 256-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. [For their application or for mine!] Someone producing the latest block, given the previous 99, can privately produce billions of cheap variations on it, by varying the order the transactions are listed etc, until they find, and publish, the one that "games" the randomness in their favour. 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 of bits of unknowable future entropy. That's all that matters for turning burnt coins into simulated mining rigs.)

Right then! What do we do with this RAND(t) stream? We simulate the capricious behaviour of a true proof-of-work mining rig! Let us assume that, in the real proof-of-work world, you can buy an h hashes/second mining rig for b=c*h BTC. (c varies with technical progress, BTC price fluctuations, etc; but in the simulated world it can just be left constant.) Or, inverting this, if you spend b BTC, you acquire a mining rig of h=b/c hashes/s power. Now, what does it actually mean for your rig to perform h hashes during 1 second? It means you're producing h uniform random numbers between 0 and 1. (That binary point again!) But you don't really care what they all are individually - how well you did during that 1 second is defined as "what was the '''lowest''' hash value you produced during that 1 second?". This is then inspected for whether it beats [is lower than] the network's current target; or, perhaps, whether it beats the lesser [i.e. numerically greater] target of a pooled mining operation. If it's good enough, that precious lowest hash is published to the network (or mining pool), and the others are just thrown away (not published). If it's not good enough, even the [not-so-]precious lowest hash isn't published - and certainly not the others. So, in the simulation, we only need to produce, for each second, a simulated "lowest hash for that 1 second". The "others" don't have to exist at all!

For reproducing (statistically) the pattern of hits and misses w.r.t. targets tough enough to not be achieving several hits within 1 second, and for h>>1, we can take the simulated lowest hash for time t to be (1/h) * HASH(signatures-of-the-act-of-burning-the-b-BTC ++ RAND(t)). [In fact this even works for h<1, despite the rather surreal appearance of "lowest hashes" >1 every so often in that case - i.e. values outside the range that ''real'' lowest (or any other!) hashes can ever actually be: it turns out this surreal behaviour is just what's needed to degrade the probability of beating the target by just the right amount. Values >1 in effect represent "I didn't generate any hashes at all during this particular 1-second window".]

Two further subtleties. First of all, it turns out to be desirable to include the block number (chain height @ 1 per block) in the formula - just to keep the owners of simulated mining rigs "on their toes" and not be able to tell a week or so in advance when they'll be lucky. (This encourages them to run a continuous full node. Maybe that's not in fact that important.) So we take simulated-lowest-hash = (1/h) * HASH(signatures-of-the-act-of-burning-the-b-BTC ++ block-number-of-would-be-block ++ RAND(t)). (We should '''not''' include finer details of the block, to avoid "gaming" a la the hundred blocks business I mentioned earlier. - Or if I'm wrong about that, then OK, by all means mix in finer details of the block!)

Secondly, it turns out that to keep the burning process going forever, rather than a pulse of initial burning that no-one ever again wants to contribute further burning to, we should simulate one more property of real-world mining rigs: they break down! That is, we should demurrage away the strength of a simulated mining rig. (A plea to the reader: Don't be alarmed by the word "demurrage". This is '''burnt''' coins I'm talking about - they ''should'' be treated "harshly", in whatever style mimics real-world mining rigs to the required fidelity. Ordinary unburnt coins are not being demurraged! [Unless that's independently desirable as a policy matter, e.g. if it's felt that network strength can only be achieved via more revenue for miners than fees alone will ever provide.]) A real mining rig likely works at full tilt for a few years and then conks out. We ''could'' demurrage each burnt coin in that style - it abruptly expires E years after its creation - but I think a smooth exponential demurrage is nicer, i.e. its burnt value after y years is b'=b*exp(-y/E). Thus h = b'/c = (b/c)*exp(-y/E). [And 1/h = c/b' = (c/b)*exp(y/E).]

Taking these two further subtleties into account, we get the following formula:

simulated-lowest-hash(t) = (c/b)*exp([t - t_burning]/E) * HASH(signatures-of-the-act-of-burning-the-b-BTC ++ block-number-of-would-be-block ++ RAND(t)).

So there you have it! With this formula, life as a miner is spookily similar to the real proof-of-work case. You "buy a mining rig" - you burn coins, and that hits ''you'' in exactly the way sending off money to a chip supplier would have hit you, even though over the whole economy, no real resources have been expended - and you then hope that, by submitting lucky hashes to the network in the form of blocks, you can make more back in fees over time than you spent initially. If you don't keep connected to the network, you won't know what transactions are eligible for including in your next would-be block, and your next lucky hash will run to waste. Meanwhile, other people are "buying mining rigs" (burning coins) too, either freshly or to make up for the "wearing out" of their existing ones; and the network is adjusting its target hash value [reciprocal difficulty] to regulate the rate all this mining effort is producing blocks at, to some preferred average rate. All spookily normal, in other words!

Now, I'm being a little bit disingenuous to say that ''everything'' is normal. We need protection against certain things (use of a lucky hash on two or more competing chains; timestamp-falsification abuse) which either do not exist at all under true proof-of-work - the former - or exist but with the consequences and mitigation strategy being different in detail - the latter. I believe I have a way of standing up to the various forms of malice we need to worry about of those kinds. More to follow soon hopefully!

=== Economic implications ===

The key insight is that verifiably, publicly burning some coins of a known-total-stock-issued currency is the same as "remurrage" (opposite of "demurrage" - it may not be a correct word, but it's a nice back-formation) on the remainder. That is, if there are verifiably 21 million issued-and-not-burned coins, and then you go to sleep and wake up later and there are now only 20 million issued-and-not-burned coins, that's the same as if some magic genie multiplied all wake-up-time nominal bitcoin figures by 21/20. Another way to see the identity of real effect would be to redefine "burning n bitcoins" to mean, not "sending n to an unspendable address", but rather "scattering" the n bitcoins, i.e. sending them to '''every existing''' [non-zero-balance] address, in proportion to the balance [sum of unspent txouts] already stored in each. This would be a horribly gigantic transaction to actually do explicitly, but the point is, burning can be thought of "as if" done that way. (Slogan: Quantity-deflation is remurrage in disguise, in exactly the same way that quantity-inflation is demurrage in disguise.)

So, what ''that'' means is, if while you're sleeping you (a non-miner) hold 1 bitcoin purely passively, i.e. it just sits undisturbed on the blockchain, well, when you wake up, it's as if you've received a "dividend" (of 5% in the particular numeric example above) on top of the general economy-tracking price we expect of a constant-quantity currency. In a world with actual, visibly performed remurrage, this is made explicit - your balance is now 21/20, with the nominal circulation [issued-and-not-burned, and remurraged for good measure] constant at 21 million. You can go and spend the 1/20 "dividend" on some treat, and still have the same fraction (1 out of 21 million) of the money stock as when you went to sleep.

In a world ''without'' any attempt at explicit remurrage, the real facts of the situation are (of course!) the same, but their nominal expression is not perhaps so instantly obvious. Your nominal holding is unchanged at 1; but this is now 1 part in 20 million of the whole money stock, not the 1 part in 21 million it was before. So, you can go and spend 1/21 of it on some treat, taking your nominal balance down to 20/21, and ''that'' nominal balance is the same (1 out of 21 million) fraction of the money stock as when you went to sleep.

So, basically, if you're holding bitcoins and trying to hold an "economy-tracking amount", no more and no less, you find you can go out into the market and use the fraction of your holdings that counts as "dividend above and beyond economy-tracking" on some treat or other. (Indeed, "you can go out..." should read "you ''must'' go out...", if you're really determined to pursue precisely that tracking strategy.)

Who's selling you the real resources embodied in the "treat"? And what's ''their'' motive? Well, transaction fee payers presumably like to re-stock their bitcoin real balances to roughly the same [economy-tracking] level as before, on average - they're paying for the fee processing as a service. These fees are then burned by miners. (Well, not literally the fees themselves - the fees themselves are ''collected'' by miners, but the way they achieve this is to burn an approximately equal amount, as explained earlier.) So, ordinary Bitcoin users, to achieve their desired re-stocking, have to either produce slightly more, or consume slightly less, or a proper or improper mixture thereof, than they would have needed to in a hypothetical (presumably impracticable) alternative world where they pay no fees for their everyday transactions (and some magic mining-god just altruistically and reliably creates a blockchain out of all the transactions, without charging anybody anything). [This follows directly from their re-stocking desire, and has nothing to do with proof-of-burn specifically. That is, they have to do this regardless of whether the protocol is proof-of-work, proof-of-stake, proof-of-burn or whatever.] It's that extra gap between production and consumption - "extra" on top of whatever gap people are already choosing as a real saving[/dis-saving] strategy - that goes on to the market, for you and all other bitcoin holders to bid off the market by spending on your "treat".

This whole stable pattern of spending habits is, perhaps surprisingly, the same pattern of real resource allocation as would have happened if Cunicula's proof of stake (with close to 100% stake / 0% work admixture) had been in operation, and all bitcoin holders, large and small, had enthusiastically thrown their bitcoins (that is, their stream of bitcoin days destroyed) into the stake-claiming process. The fraction of fees they'd collect if they did that would be just like the "dividend" as I called it above - it would be like explicit remurrage, except instead of being automatic, it would require each holder's active participation (i.e. they couldn't just go to sleep, unless they left some sort of "trusted bot" running and using their private keys to sign their stream of bitcoin days destroyed). So, if you like, proof-of-burn is like automated, 100%-stakeholder-participation Cunicula-style proof-of-stake!

Incidentally, it's also fascinating to consider what happens if the community does decide a demurraging of [ordinary, unburnt] coins, the revenue being added as a coin-[re-]minting stream to the flow of fees, ''is'' necessary to continue with forever, for the sake of network strength. The amazing answer, as far as I can honestly work out, is that in long-run equilibrium, the burn rate is just such as '''to make hardly any of this demurrage ''real'' demurrage at all!''' [The implicit remurrage of burning almost exactly cancels the explicit demurrage of network-strengthening coin-[re-]minting! (Or if you like, the implicit demurrage of inflationary fresh-coin-minting.) Either way, we ''seem'' to get the possibility of amazing network strength "for free"!] This opens up the shocking possibility of turning up the demurrage/inflation rate to startlingly high levels - 5% of money stock / year, 10% of money stock / year... levels that would bring the whole cryptocurrency into disrepute in the true proof-of-work case, since coin-holders really would suffer that actual amount of explicit or implicit demurrage - and yet '''not''' hitting coin-holders with more than a frictional residual fraction of that ''in real terms'' at all, because of the way burning simulates remurrage! Extraordinary stuff! I plan to say more about this soon - but this quick teaser description should already be food for thought.

=== Coin-burning as a tool for transition between cryptocurrencies ===

Proof of burn may also be of interest as a tool for managing an orderly transition from one cryptocurrency ("oldcoin", let's call it) to another ("newcoin"). If the developers of newcoin are looking for a way of avoiding proof-of-work's real resource consumption '''even in newcoin's initial distribution phase''', they can't use proof of newcoin-burn: newcoins don't exist yet. But they ''can'' use proof of oldcoin-burn! (Assuming their reason for creating newcoin is '''not''' a doubting of oldcoin's security model, anyway. - Or at least, not a doubting severe enough to affect sufficiently deeply buried oldcoins, these being the candidates for burning.)

The newcoin blockchain would thus start with (at least a hash referring to) a complete catalogue of all the [sufficiently deeply buried] unspent txouts of oldcoin. Miners would then exhibit burning events within oldcoin up to a certain date; after which, the protocol would switch to burning of newcoin itself (and the dependency on oldcoin could even be thrown away entirely, if a checkpoint of that transition moment was promulgated and accepted by the newcoin community).

This has the nice consequence that, if people throughout the broader economy are gradually deserting oldcoin (as newcoin catches on), '''''its value need not collapse!''''' Instead, oldcoin gets burnt in the transition process, neatly reducing its nominal supply in just such a way as to roughly keep pace with its declining real demand. Meanwhile, those same acts of burning are minting fresh newcoins, at just the pace required to keep up with newcoin's ''growing'' real demand. (At least, that's the case if miners anticipate the transition speed correctly, and enter / exit the coins' respective mining trades at a pace that competes away supra-normal profits. We also have to assume that the ''total'' real demand for both[/all...] cryptocurrencies is roughly stable in "economy-tracking" terms; or at least, that miners anticipate the time path of the size of total real demand, and of its currency-by-currency composition, correctly, or near enough correctly.)

'''To sum up:''' proof of burn ''could'', just maybe, qualify as a new tool to greatly assist overall (multi-cryptocurrency) economic robustness and stability!

== Earlier work suggesting a role for the burning of coins ==

[https://bitcointalk.org/index.php?topic=131139.msg1404195#msg1404195 Forum member ripper234 points out] an earlier work by forum member [https://bitcointalk.org/index.php?action=profile;u=3313 dacoinminster] suggesting coins could be burnt as one component of a broader protocol. [https://bitcointalk.org/index.php?topic=56901.0 The earlier work] is [http://bitcoin.stackexchange.com/questions/2458/is-dacoinminsters-second-bitcoin-whitepaper-logically-economically-consistent discussed on StackExchange]. It revolves around a centralised "trusted entity" system, and so is not directly comparable to decentralised proof-of-burn mining; but it may be of interest to some readers.

== See also ==
*[[Proof_of_work|Proof of work]]
*[[Proof_of_Stake|Proof of stake]]

[[category:mining]]

Proof of blockchain fair sharing

2013-05-06T22:42:39Z

Ids: added a "see also" section, pointing to proof of stake

'''Proof of blockchain fair sharing''' is a draft Bitcoin protocol change proposal by [[User:Ids|Iain Stewart]], with the goal of allowing the network to continue to settle on a sensible consensus blockchain ''even when subject to a considerably-greater-than-50% attack''.

The protocol is under construction. The following description is a "teaser", establishing its basic flavour and sketching how it exploits an asymmetry in the goals of the honest (<50%) and malicious (>50%) miners to avoid the usual reductio ad absurdum argument against ''any'' protocol surviving a >50% attack.

== Teaser description ==

''Iain Stewart writes:'' Proof of blockchain fair sharing is of proof-of-stake flavour (which makes me nervous in some ways, but that's another story), and it relies on the fact that stakeholders are '''pseudonymously trackable''', unlike proof-of-work contributors, and therefore a formula for blockchain height can reward '''closeness to fair-share proportions''' in such a way that a 90% attacker finds they can't stop the honest 10% contributing too-expensive-for-the-attacker-to-reverse blocks which, to the attacker's chagrin, '''incorporate''' the accumulated transactions the attacker has been endlessly reversing and re-excluding in an effort to ruin the credibility of Bitcoin. (And any change to the attacker's pseudonymous identity/identities destroys their bitcoin-days' stake and takes them out of the running as a big attacker for a long time.)

To expand a little on the above teaser: One might think that by reductio ad absurdum '''no''' system can protect against a >50% attack, because in a purported proof of immunity of the honest <50% from the malicious >50%, the labels "honest" and "malicious" ultimately have no technical meaning, and so just swapping the labels would, absurdly, give a second proof, saying that the <50% community can't "attack" (i.e. save us all from) the >50% community, in contradiction to the first proof. That reductio argument is false here - '''there is an asymmetry''' between the two communities' goals, as follows. (I'm talking about an attack to destroy the usability of Bitcoin. An attack to achieve [[Double-spending|double spending]] is a much lower-impact event, the analysis of which I'm therefore postponing, although on general grounds the situation is probably neither especially better nor worse than with other protocols.) The >50% "community" [the attacker(s)] is trying to exclude transactions - perhaps all of them, perhaps those of specific people it wants to harass, perhaps random ones just to create fear that "I could be next" - from entering the winning blockchain. Thus it has to achieve '''total''' exclusion of the would-be blocks originating from the <50% community, who keep including the transactions to try and earn an honest profit from the fees. By contrast, the <50% community [the just-trying-to-earn-a-living honest miners] '''doesn't''' have to achieve exclusion of the attacker's blocks - they're happy with a mixed blockchain where, reasonably often, another honest block gets in and stays in. So long as they can get transactions bedded down into the blockchain, they've avoided the ruining of Bitcoin as a usable system. It's this crucial asymmetry between the two communities which lets the honest miners win - a chain height formula which suitably rewards diversity of pseudonymous composition will stop even a 90% attacker "community" from achieving its, tougher, goal. I hope this indicates the general direction I'm headed. [[User:Ids|Iain Stewart]] 11:15, 21 May 2012 (GMT)

=== A more discursive description, but still of a "teaser" nature... ===

''Iain Stewart writes:'' I contributed a more discursive description of the proof of blockchain fair sharing idea, though still ultimately of a "teaser" nature (sorry!), to the [https://en.bitcoin.it/wiki/Talk:Proof_of_Stake proof of stake talk page]. That talk page has since moved on to other things; but you can find my contribution [https://en.bitcoin.it/w/index.php?title=Talk:Proof_of_Stake&oldid=29541 in its archive], namely, the gloriously-named "'''''Proof of stake - done right - is maybe, just maybe, the way to eliminate 51% (even 90%!) attack worries altogether!'''''" section thereof. Enjoy! [[User:Ids|Iain Stewart]] 23:18, 24 November 2012 (GMT)

== Broader approaches to the >50% attack problem ==

''Iain Stewart writes:'' I apologise for the unfinished state of the above teaser description. It's a hard problem, and it may even be impossible in its "pure" form, without help from fallible heuristics and the like.

In the spirit of exploring broader approaches with rough-and-ready fallible heuristics, I reproduce below [https://bitcointalk.org/index.php?topic=125822.msg1352625#msg1352625 my forum post] about how a cryptocurrency might resist a >50% attack from (in Cunicula's opening post's example) a central bank. It's not fair sharing as defined above - but maybe it doesn't need to be. [[User:Ids|Iain Stewart]] 08:45, 23 November 2012 (GMT)

=== (The quoted forum post...) ===

Well! [https://bitcointalk.org/index.php?topic=125822.0 This thread] has certainly got us all thinking about the robustness or lack thereof of various cryptocurrency designs! [https://bitcointalk.org/index.php?topic=125822.msg1341095#msg1341095 Cunicula's opening post] paints (possibly provocatively or tongue-in-cheek?) a central bank's hypothetical successful 51% attack as a good thing. I think most of us on this forum would disagree. We want our cryptocurrency to '''stop''' any would-be central bank / central planner from saying "you can only spend your coins in a style approved by our macroeconomic policies". (In just the same way as we want it to '''stop''' a present or future PayPal from saying "you can only buy what we think you ought to buy, and donate to who we think you ought to donate to". - Or, more precisely, they can say it, but we can reply "we don't need you any more".)

That's what we want. How do we get it?

For attacks falling short of 51%, there's some mileage to be had in changing the "proof-of-..." choice from one thing to another. Proof-of-work, proof-of-stake, proof-of-activity... they all have interesting advantages and disadvantages and are all debated vigorously in various corners of this forum. Indeed, I'm planning to add to the list myself real soon now, with something I call "proof-of-burn". But they all crumple under a 51% attack. (That includes my proof-of-burn too! It's not immune!) So, when facing an adversary wealthy enough to acquire and use 51% of ''whichever'' "proof-of..." resource is being measured by the network - hashing work, stake, burn rate, signature activity, you name it - we need new techniques to stand up to such an attacker.

I think the good news here is that a 51% attacker's chain has to behave '''visibly strangely''' when excluding "technically fully sensible but politically unapproved" transactions, such as the "no, I'm not going to pay your coin-year-demurrage level of fees!" transactions Cunicula's example central bank would like to exclude. Such transactions sit in every node's memory pool. Then, every time any such transaction gets into a block (mined by an honest miner who's perfectly happy with its "ordinary" competitive-mining-market-clearing level of fee), the winning chain always ends up building on the ''previous'' block, orphaning the honest block and orphaning the transaction back into the memory pool. Whereas, every time ''no'' such transactions get into a block, the winning chain always ends up building on ''that'' block - it being a block produced by the 51% attacker (or by an honest miner who happens to have inadvertently followed the attacker's policy by happening not to have included those transactions for whatever mundane reason).

This behaviour is visibly strange in a statistical sense. It may not seem strange the first time, or the second time, or the tenth time, but as the politically-unapproved transactions hop in and out of everyone's memory pool more and more often, it becomes ever more absurd to ascribe their exclusion to bad luck.

(Contrast this with an attack whose motive is double-spending, rather than political control of the cryptocurrency. In the double-spending scenario, the network has no real opinion about which of the incompatible transactions ''ought'' to succeed and which ought to fail. An attacker can choose whichever one profits them and hurts the recipients[-until-later-reversed] of its double-spending sibling(s). Recipients just have to learn to wait long enough that ''even the attacker'' loses interest in further reversing their own chain - their own reversal-attack upon some earlier apparently winning chain - to that block-depth extent. But in the transaction-excluding scenario, the network's honest users '''do''' have an opinion about which ''treatment'' of the ''single'' [no double-spending siblings] transaction ought to succeed and which ought to fail. Namely: the transaction's ''presence'' is what ought to succeed, and its ''absence'' is what ought to fail!)

This visibly strange behaviour opens up the possibility of a "heuristic defence". I'm certainly not claiming I have such a defence in polished form ready to implement; but in broad outline, nodes would try to compute a "probability (or plausibility) rating" for each new block they encounter. How long has an in-again-out-again transaction been in (and out and in...) my memory pool? What fraction of my network neighbours agree it's been stuck like this for ages? (And recursively, can they report the statistics of ''their'' neighbours' opinions, in cheap aggregated form?) If it's ever more obvious that essentially the whole network knows about it, it becomes ever more ridiculous (exponentially so, I'd suspect) to believe that a whole sequence of miners can have not heard of it. Even more so, since it was sitting there inside ''an expensive object to produce'' - namely, a later-to-be-orphaned block produced by an honest miner - and a thousand websites could spring up, listing (unfakeably! the orphaned blocks are expensive things to produce!) all the transactions therein that are compatible with, but mysteriously excluded for ages by, the current winning chain.

The naive height-strength (difficulty or its proof-of-whatever equivalent) of a block would then be multiplied by that probability or plausibility rating, and it would be the sum of such ''plausibility-adjusted'' height-strengths, not the sum of the naive strengths, which would be used to judge a winning chain.

Yes, this does have the danger that different nodes would compute somewhat different plausibility ratings to multiply naive strengths by; and network consensus convergence could be placed in jeopardy if their opinions were too divergent. So, one would not want to be ''too'' eager to deprecate a block by a large factor. Still, in really extreme cases (say down into one-in-a-million territory for a transaction to have been excluded by bad luck - the power of exponential shrinkage means we get down there quite fast!), a sizeable deprecation becomes sensible (e.g. if we deprecate by the sixth root of plausibility, the attacker's blocks are deprecated by a factor of 10 in the one-in-a-million example - enough that 10% honest miners win out over a 90% attacker).

So... '''there's hope for us yet!''' Even with a billionaire central bank as adversary!

(A final note: who's running those "thousand websites" [or tor-sites... whatever] listing the suspiciously excluded transactions? Well, anyone can set one up; and serious, big full nodes, such as those run by serious professional miners, should be eager to subscribe to such sites, for a micropayment or subscription fee or the like if necessary. After all, if you're a miner, and you know that ''other'' nodes are going to deprecate ''your'' block if you don't make an effort to include that gaggle of suspiciously excluded transactions, that's a powerful incentive to keep yourself up to date with the general state of play! - And yes, we should of course aim for ''the network itself'' to achieve such functionality, without external sites' involvement. Perhaps nodes could report to their neighbours a standardised-mathematical-language ''set of reasons'' why they attached such-and-such a deprecation factor to such-and-such a block? The challenge would be to handle one's neighbours' reasons-descriptions in a way that, while stopping short of naive slavish agreement therewith, still encourages a helpful consensus to emerge.)

<big>'''(end of quoted forum post)'''</big>

== Related work ==
* [http://gavintech.blogspot.co.uk/ Gavin Andresen] has proposed [http://gavintech.blogspot.co.uk/2012/05/neutralizing-51-attack.html looking at a block's transactions' coin-age priority], when deciding a best chain, as a possible way of standing up to some forms of >50% attack.

* [http://john-edwin-tobey.org/ John Tobey] has proposed a scheme which studies the detailed distribution of fees and difficulty over a chain and its side-chains, including detection of any tendency for transactions to be orphaned, with a view to deprecating a chain that exhibits symptoms likely in an attack. For now, he has placed a description of his scheme, and some simulation code and results, on ''this'' page's talk page. (In most browsers this is accessible via a "Discussion" link at the top of this page; if not, here's [https://en.bitcoin.it/wiki/Talk:Proof_of_blockchain_fair_sharing a direct link].)

== See also ==
*[[Proof_of_Stake|Proof of stake]]

Proof of blockchain fair sharing

2013-05-06T02:49:30Z

Ids: new related work section, incl. John Tobey's scheme, which he's placed (for now) right here, on this page's talk page!

Proof of burn

2012-12-18T22:30:24Z

Ids: /* Introduction and motivation */ markup tweak

'''Proof of burn''' is a potential alternative to [[Proof_of_work|proof of work]] and [[Proof_of_Stake|proof of stake]] as a "scarce resource" to be exhibited by miners competing for the stream of rewards (minted coins and transaction fees) which a cryptocurrency's design makes available. 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 unlike proof of work, it consumes no real resources from a whole economy perspective. This has interesting implications, discussed below.

There are likely many possible variants of proof of burn. This page currently describes [[User:Ids|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 ==

=== Introduction and motivation ===

The key idea of proof-of-burn (this would also apply to proof-of-stake, by the way) is that when choosing the thing which is to qualify as a "difficulty", i.e. to require miners to exhibit proof that they've "done something that's tough to do", all that matters is that ''an individual miner'' finds the task expensive. (Well... it also matters that everyone else should find it cheap to verify that it has been done.) 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 all 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.e. [the fast early phase of] its initial distribution) - or, more precisely, while ''the first'' cryptocurrency is being set up; more on this distinction later! - no good alternative has been proposed. (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 variety", I mean) is in 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: burning the currency!

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. With Bitcoin, any address which is [the RIPEMD160/SHA256 hash of] a script that evaluates to false will do. 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 RIPEMD160 since you can choose big numbers to taste. So, bitcoins sent to such a txout can never be redeemed on a future txin. (Barring the cracking of RIPEMD160 and the finding of an alternative matching script, that is. If ''that'' happens, the cryptocurrency is in 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. (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: burning merely needs to be defined as sending to some ''fixed'' unspendable address, with no variation - e.g. we could settle on the hash of "push 4, and check if it's equal to 5".

So, miners are creating candidate winning blocks by saying to the listening world, not "Look! I've done this many trillion hashes! [or struck lucky with fewer: you, the listening world, wouldn't know the difference... but this doesn't matter...]", but rather "Look! 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! Thanks!" That extremely recent act of burning could be undone in a block chain reorganisation; and then the same miner would be able to "re-burn" those same coins in an attempt to grab a block afresh, post-reorganisation. 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. A proof-of-work miner must simply shrug and say "Oh well, that's those expenses [electricity, mining rig rental / imputed rental,...] lost and gone... time to try again!" And that's the way things should be, for security - it '''should not''' be as cheap to extend the height of two or more competing chains as it is to focus on one. (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. Details to follow.

Now then! 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 users are sending them fees (and any coin-minting still going on too of course), minus the miners' true real-resource costs (i.e. the hardware and electricity and the like for handling transactions and blocks and burn proofs - these costs will be far lower than the hashing costs incurred under proof-of-work, but of course still non-zero). 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.

=== Technical sketch of proof of burn: "Burnt coins are mining rigs!" ===

''Iain Stewart writes:'' 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:

'''''"Burnt coins are mining rigs!"'''''

What that slogan means will become clear as I go on. Basically, 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! - to simulate the generating of random hashes that a real proof-of-work mining rig would produce. Now, obviously we don't want to "simulate" every actual hash! A "simulation" of proof-of-work at ''that'' level of detail would just ''be'' proof-of-work! Rather, we want to mimic the statistical properties of a mining rig's stream of hashes, to just the level of detail required to give the same sort of pattern of meeting / not meeting a moving difficulty target, and all the rest of it, that we get with the real thing.

So: first of all, what exactly is my "stream of true randomness"? Chop up time into units considerably shorter than the intended inter-block time, but 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!) at time t, they can't predict the value of RAND(any t' 2 months or more to the future of t). [Where "2 months" means the dead time a burnt coin must wait before it becomes a simulated active mining rig. 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.] We do '''not''' need fresh statistical independence of RAND(t) w.r.t. all of RAND(t-1), RAND(t-2), RAND(t-3), etc. (And we don't mind if the stream is known a "short" time into the future - e.g. a week or two; at any rate a small portion of the waiting period.)

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: lotteries. 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.dat or whatever) should get "the latest lottery results" appended to it. 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. Like this:

.
.
.
for use from 2013-06-24 00:00:00 onwards: UK national lottery 2013-06-12: 4 9 20 22 37 42, bonus ball 19
for use from 2013-07-01 00:00:00 onwards: UK national lottery 2013-06-19: 7 12 14 19 33 41, bonus ball 28

(Obviously the meta-level words "for use from... onwards" aren't really needed - I just put them in for clarity.) Each line is added in a leisurely, unhurried fashion, at some time (it doesn't matter when) between the draw and the intended start-paying-attention-to-it date. (Some time between 2013-06-19 and 2013-07-01 00:00:00, in the case of the example last line above.) 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.g. 2013-07-02 23:14:05, or just the Unix numeric time] as a final line). - Or if you like, HASH(HASH(config-file) ++ t), for efficiency. (Where "++" means "append together in some standard fashion".) "HASH()" is your favourite hash function, e.g. SHA256(SHA256()). Thus RAND(t) is a 256-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. [For their application or for mine!] Someone producing the latest block, given the previous 99, can privately produce billions of cheap variations on it, by varying the order the transactions are listed etc, until they find, and publish, the one that "games" the randomness in their favour. 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 of bits of unknowable future entropy. That's all that matters for turning burnt coins into simulated mining rigs.)

Right then! What do we do with this RAND(t) stream? We simulate the capricious behaviour of a true proof-of-work mining rig! Let us assume that, in the real proof-of-work world, you can buy an h hashes/second mining rig for b=c*h BTC. (c varies with technical progress, BTC price fluctuations, etc; but in the simulated world it can just be left constant.) Or, inverting this, if you spend b BTC, you acquire a mining rig of h=b/c hashes/s power. Now, what does it actually mean for your rig to perform h hashes during 1 second? It means you're producing h uniform random numbers between 0 and 1. (That binary point again!) But you don't really care what they all are individually - how well you did during that 1 second is defined as "what was the '''lowest''' hash value you produced during that 1 second?". This is then inspected for whether it beats [is lower than] the network's current target; or, perhaps, whether it beats the lesser [i.e. numerically greater] target of a pooled mining operation. If it's good enough, that precious lowest hash is published to the network (or mining pool), and the others are just thrown away (not published). If it's not good enough, even the [not-so-]precious lowest hash isn't published - and certainly not the others. So, in the simulation, we only need to produce, for each second, a simulated "lowest hash for that 1 second". The "others" don't have to exist at all!

For reproducing (statistically) the pattern of hits and misses w.r.t. targets tough enough to not be achieving several hits within 1 second, and for h>>1, we can take the simulated lowest hash for time t to be (1/h) * HASH(signatures-of-the-act-of-burning-the-b-BTC ++ RAND(t)). [In fact this even works for h<1, despite the rather surreal appearance of "lowest hashes" >1 every so often in that case - i.e. values outside the range that ''real'' lowest (or any other!) hashes can ever actually be: it turns out this surreal behaviour is just what's needed to degrade the probability of beating the target by just the right amount. Values >1 in effect represent "I didn't generate any hashes at all during this particular 1-second window".]

Two further subtleties. First of all, it turns out to be desirable to include the block number (chain height @ 1 per block) in the formula - just to keep the owners of simulated mining rigs "on their toes" and not be able to tell a week or so in advance when they'll be lucky. (This encourages them to run a continuous full node. Maybe that's not in fact that important.) So we take simulated-lowest-hash = (1/h) * HASH(signatures-of-the-act-of-burning-the-b-BTC ++ block-number-of-would-be-block ++ RAND(t)). (We should '''not''' include finer details of the block, to avoid "gaming" a la the hundred blocks business I mentioned earlier. - Or if I'm wrong about that, then OK, by all means mix in finer details of the block!)

Secondly, it turns out that to keep the burning process going forever, rather than a pulse of initial burning that no-one ever again wants to contribute further burning to, we should simulate one more property of real-world mining rigs: they break down! That is, we should demurrage away the strength of a simulated mining rig. (A plea to the reader: Don't be alarmed by the word "demurrage". This is '''burnt''' coins I'm talking about - they ''should'' be treated "harshly", in whatever style mimics real-world mining rigs to the required fidelity. Ordinary unburnt coins are not being demurraged! [Unless that's independently desirable as a policy matter, e.g. if it's felt that network strength can only be achieved via more revenue for miners than fees alone will ever provide.]) A real mining rig likely works at full tilt for a few years and then conks out. We ''could'' demurrage each burnt coin in that style - it abruptly expires E years after its creation - but I think a smooth exponential demurrage is nicer, i.e. its burnt value after y years is b'=b*exp(-y/E). Thus h = b'/c = (b/c)*exp(-y/E). [And 1/h = c/b' = (c/b)*exp(y/E).]

Taking these two further subtleties into account, we get the following formula:

simulated-lowest-hash(t) = (c/b)*exp([t - t_burning]/E) * HASH(signatures-of-the-act-of-burning-the-b-BTC ++ block-number-of-would-be-block ++ RAND(t)).

So there you have it! With this formula, life as a miner is spookily similar to the real proof-of-work case. You "buy a mining rig" - you burn coins, and that hits ''you'' in exactly the way sending off money to a chip supplier would have hit you, even though over the whole economy, no real resources have been expended - and you then hope that, by submitting lucky hashes to the network in the form of blocks, you can make more back in fees over time than you spent initially. If you don't keep connected to the network, you won't know what transactions are eligible for including in your next would-be block, and your next lucky hash will run to waste. Meanwhile, other people are "buying mining rigs" (burning coins) too, either freshly or to make up for the "wearing out" of their existing ones; and the network is adjusting its target hash value [reciprocal difficulty] to regulate the rate all this mining effort is producing blocks at, to some preferred average rate. All spookily normal, in other words!

Now, I'm being a little bit disingenuous to say that ''everything'' is normal. We need protection against certain things (use of a lucky hash on two or more competing chains; timestamp-falsification abuse) which either do not exist at all under true proof-of-work - the former - or exist but with the consequences and mitigation strategy being different in detail - the latter. I believe I have a way of standing up to the various forms of malice we need to worry about of those kinds. More to follow soon hopefully!

=== Economic implications ===

The key insight is that verifiably, publicly burning some coins of a known-total-stock-issued currency is the same as "remurrage" (opposite of "demurrage" - it may not be a correct word, but it's a nice back-formation) on the remainder. That is, if there are verifiably 21 million issued-and-not-burned coins, and then you go to sleep and wake up later and there are now only 20 million issued-and-not-burned coins, that's the same as if some magic genie multiplied all wake-up-time nominal bitcoin figures by 21/20. Another way to see the identity of real effect would be to redefine "burning n bitcoins" to mean, not "sending n to an unspendable address", but rather "scattering" the n bitcoins, i.e. sending them to '''every existing''' [non-zero-balance] address, in proportion to the balance [sum of unspent txouts] already stored in each. This would be a horribly gigantic transaction to actually do explicitly, but the point is, burning can be thought of "as if" done that way. (Slogan: Quantity-deflation is remurrage in disguise, in exactly the same way that quantity-inflation is demurrage in disguise.)

So, what ''that'' means is, if while you're sleeping you (a non-miner) hold 1 bitcoin purely passively, i.e. it just sits undisturbed on the blockchain, well, when you wake up, it's as if you've received a "dividend" (of 5% in the particular numeric example above) on top of the general economy-tracking price we expect of a constant-quantity currency. In a world with actual, visibly performed remurrage, this is made explicit - your balance is now 21/20, with the nominal circulation [issued-and-not-burned, and remurraged for good measure] constant at 21 million. You can go and spend the 1/20 "dividend" on some treat, and still have the same fraction (1 out of 21 million) of the money stock as when you went to sleep.

In a world ''without'' any attempt at explicit remurrage, the real facts of the situation are (of course!) the same, but their nominal expression is not perhaps so instantly obvious. Your nominal holding is unchanged at 1; but this is now 1 part in 20 million of the whole money stock, not the 1 part in 21 million it was before. So, you can go and spend 1/21 of it on some treat, taking your nominal balance down to 20/21, and ''that'' nominal balance is the same (1 out of 21 million) fraction of the money stock as when you went to sleep.

So, basically, if you're holding bitcoins and trying to hold an "economy-tracking amount", no more and no less, you find you can go out into the market and use the fraction of your holdings that counts as "dividend above and beyond economy-tracking" on some treat or other. (Indeed, "you can go out..." should read "you ''must'' go out...", if you're really determined to pursue precisely that tracking strategy.)

Who's selling you the real resources embodied in the "treat"? And what's ''their'' motive? Well, transaction fee payers presumably like to re-stock their bitcoin real balances to roughly the same [economy-tracking] level as before, on average - they're paying for the fee processing as a service. These fees are then burned by miners. (Well, not literally the fees themselves - the fees themselves are ''collected'' by miners, but the way they achieve this is to burn an approximately equal amount, as explained earlier.) So, ordinary Bitcoin users, to achieve their desired re-stocking, have to either produce slightly more, or consume slightly less, or a proper or improper mixture thereof, than they would have needed to in a hypothetical (presumably impracticable) alternative world where they pay no fees for their everyday transactions (and some magic mining-god just altruistically and reliably creates a blockchain out of all the transactions, without charging anybody anything). [This follows directly from their re-stocking desire, and has nothing to do with proof-of-burn specifically. That is, they have to do this regardless of whether the protocol is proof-of-work, proof-of-stake, proof-of-burn or whatever.] It's that extra gap between production and consumption - "extra" on top of whatever gap people are already choosing as a real saving[/dis-saving] strategy - that goes on to the market, for you and all other bitcoin holders to bid off the market by spending on your "treat".

This whole stable pattern of spending habits is, perhaps surprisingly, the same pattern of real resource allocation as would have happened if Cunicula's proof of stake (with close to 100% stake / 0% work admixture) had been in operation, and all bitcoin holders, large and small, had enthusiastically thrown their bitcoins (that is, their stream of bitcoin days destroyed) into the stake-claiming process. The fraction of fees they'd collect if they did that would be just like the "dividend" as I called it above - it would be like explicit remurrage, except instead of being automatic, it would require each holder's active participation (i.e. they couldn't just go to sleep, unless they left some sort of "trusted bot" running and using their private keys to sign their stream of bitcoin days destroyed). So, if you like, proof-of-burn is like automated, 100%-stakeholder-participation Cunicula-style proof-of-stake!

Incidentally, it's also fascinating to consider what happens if the community does decide a demurraging of [ordinary, unburnt] coins, the revenue being added as a coin-[re-]minting stream to the flow of fees, ''is'' necessary to continue with forever, for the sake of network strength. The amazing answer, as far as I can honestly work out, is that in long-run equilibrium, the burn rate is just such as '''to make hardly any of this demurrage ''real'' demurrage at all!''' [The implicit remurrage of burning almost exactly cancels the explicit demurrage of network-strengthening coin-[re-]minting! (Or if you like, the implicit demurrage of inflationary fresh-coin-minting.) Either way, we ''seem'' to get the possibility of amazing network strength "for free"!] This opens up the shocking possibility of turning up the demurrage/inflation rate to startlingly high levels - 5% of money stock / year, 10% of money stock / year... levels that would bring the whole cryptocurrency into disrepute in the true proof-of-work case, since coin-holders really would suffer that actual amount of explicit or implicit demurrage - and yet '''not''' hitting coin-holders with more than a frictional residual fraction of that ''in real terms'' at all, because of the way burning simulates remurrage! Extraordinary stuff! I plan to say more about this soon - but this quick teaser description should already be food for thought.

=== Coin-burning as a tool for transition between cryptocurrencies ===

Proof of burn may also be of interest as a tool for managing an orderly transition from one cryptocurrency ("oldcoin", let's call it) to another ("newcoin"). If the developers of newcoin are looking for a way of avoiding proof-of-work's real resource consumption '''even in newcoin's initial distribution phase''', they can't use proof of newcoin-burn: newcoins don't exist yet. But they ''can'' use proof of oldcoin-burn! (Assuming their reason for creating newcoin is '''not''' a doubting of oldcoin's security model, anyway. - Or at least, not a doubting severe enough to affect sufficiently deeply buried oldcoins, these being the candidates for burning.)

The newcoin blockchain would thus start with (at least a hash referring to) a complete catalogue of all the [sufficiently deeply buried] unspent txouts of oldcoin. Miners would then exhibit burning events within oldcoin up to a certain date; after which, the protocol would switch to burning of newcoin itself (and the dependency on oldcoin could even be thrown away entirely, if a checkpoint of that transition moment was promulgated and accepted by the newcoin community).

This has the nice consequence that, if people throughout the broader economy are gradually deserting oldcoin (as newcoin catches on), '''''its value need not collapse!''''' Instead, oldcoin gets burnt in the transition process, neatly reducing its nominal supply in just such a way as to roughly keep pace with its declining real demand. Meanwhile, those same acts of burning are minting fresh newcoins, at just the pace required to keep up with newcoin's ''growing'' real demand. (At least, that's the case if miners anticipate the transition speed correctly, and enter / exit the coins' respective mining trades at a pace that competes away supra-normal profits. We also have to assume that the ''total'' real demand for both[/all...] cryptocurrencies is roughly stable in "economy-tracking" terms; or at least, that miners anticipate the time path of the size of total real demand, and of its currency-by-currency composition, correctly, or near enough correctly.)

'''To sum up:''' proof of burn ''could'', just maybe, qualify as a new tool to greatly assist overall (multi-cryptocurrency) economic robustness and stability!

== Earlier work suggesting a role for the burning of coins ==

[https://bitcointalk.org/index.php?topic=131139.msg1404195#msg1404195 Forum member ripper234 points out] an earlier work by forum member [https://bitcointalk.org/index.php?action=profile;u=3313 dacoinminster] suggesting coins could be burnt as one component of a broader protocol. [https://bitcointalk.org/index.php?topic=56901.0 The earlier work] is [http://bitcoin.stackexchange.com/questions/2458/is-dacoinminsters-second-bitcoin-whitepaper-logically-economically-consistent discussed on StackExchange]. It revolves around a centralised "trusted entity" system, and so is not directly comparable to decentralised proof-of-burn mining; but it may be of interest to some readers.

== See also ==
*[[Proof_of_work|Proof of work]]
*[[Proof_of_Stake|Proof of stake]]

[[category:mining]]

Proof of burn

2012-12-17T03:57:48Z

Ids: /* Earlier work suggesting a role for the burning of coins */ clearer linking to earlier work

'''Proof of burn''' is a potential alternative to [[Proof_of_work|proof of work]] and [[Proof_of_Stake|proof of stake]] as a "scarce resource" to be exhibited by miners competing for the stream of rewards (minted coins and transaction fees) which a cryptocurrency's design makes available. 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 unlike proof of work, it consumes no real resources from a whole economy perspective. This has interesting implications, discussed below.

There are likely many possible variants of proof of burn. This page currently describes [[User:Ids|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 ==

=== Introduction and motivation ===

The key idea of proof-of-burn (this would also apply to proof-of-stake, by the way) is that when choosing the thing which is to qualify as a "difficulty", i.e. to require miners to exhibit proof that they've "done something that's tough to do", all that matters is that '''an individual miner''' finds the task expensive. (Well... it also matters that everyone else should find it cheap to verify that it has been done.) 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 all 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.e. [the fast early phase of] its initial distribution) - or, more precisely, while ''the first'' cryptocurrency is being set up; more on this distinction later! - no good alternative has been proposed. (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 variety", I mean) is in 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: burning the currency!

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. With Bitcoin, any address which is [the RIPEMD160/SHA256 hash of] a script that evaluates to false will do. 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 RIPEMD160 since you can choose big numbers to taste. So, bitcoins sent to such a txout can never be redeemed on a future txin. (Barring the cracking of RIPEMD160 and the finding of an alternative matching script, that is. If ''that'' happens, the cryptocurrency is in 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. (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: burning merely needs to be defined as sending to some ''fixed'' unspendable address, with no variation - e.g. we could settle on the hash of "push 4, and check if it's equal to 5".

So, miners are creating candidate winning blocks by saying to the listening world, not "Look! I've done this many trillion hashes! [or struck lucky with fewer: you, the listening world, wouldn't know the difference... but this doesn't matter...]", but rather "Look! 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! Thanks!" That extremely recent act of burning could be undone in a block chain reorganisation; and then the same miner would be able to "re-burn" those same coins in an attempt to grab a block afresh, post-reorganisation. 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. A proof-of-work miner must simply shrug and say "Oh well, that's those expenses [electricity, mining rig rental / imputed rental,...] lost and gone... time to try again!" And that's the way things should be, for security - it '''should not''' be as cheap to extend the height of two or more competing chains as it is to focus on one. (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. Details to follow.

Now then! 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 users are sending them fees (and any coin-minting still going on too of course), minus the miners' true real-resource costs (i.e. the hardware and electricity and the like for handling transactions and blocks and burn proofs - these costs will be far lower than the hashing costs incurred under proof-of-work, but of course still non-zero). 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.

=== Technical sketch of proof of burn: "Burnt coins are mining rigs!" ===

''Iain Stewart writes:'' 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:

'''''"Burnt coins are mining rigs!"'''''

What that slogan means will become clear as I go on. Basically, 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! - to simulate the generating of random hashes that a real proof-of-work mining rig would produce. Now, obviously we don't want to "simulate" every actual hash! A "simulation" of proof-of-work at ''that'' level of detail would just ''be'' proof-of-work! Rather, we want to mimic the statistical properties of a mining rig's stream of hashes, to just the level of detail required to give the same sort of pattern of meeting / not meeting a moving difficulty target, and all the rest of it, that we get with the real thing.

So: first of all, what exactly is my "stream of true randomness"? Chop up time into units considerably shorter than the intended inter-block time, but 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!) at time t, they can't predict the value of RAND(any t' 2 months or more to the future of t). [Where "2 months" means the dead time a burnt coin must wait before it becomes a simulated active mining rig. 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.] We do '''not''' need fresh statistical independence of RAND(t) w.r.t. all of RAND(t-1), RAND(t-2), RAND(t-3), etc. (And we don't mind if the stream is known a "short" time into the future - e.g. a week or two; at any rate a small portion of the waiting period.)

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: lotteries. 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.dat or whatever) should get "the latest lottery results" appended to it. 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. Like this:

.
.
.
for use from 2013-06-24 00:00:00 onwards: UK national lottery 2013-06-12: 4 9 20 22 37 42, bonus ball 19
for use from 2013-07-01 00:00:00 onwards: UK national lottery 2013-06-19: 7 12 14 19 33 41, bonus ball 28

(Obviously the meta-level words "for use from... onwards" aren't really needed - I just put them in for clarity.) Each line is added in a leisurely, unhurried fashion, at some time (it doesn't matter when) between the draw and the intended start-paying-attention-to-it date. (Some time between 2013-06-19 and 2013-07-01 00:00:00, in the case of the example last line above.) 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.g. 2013-07-02 23:14:05, or just the Unix numeric time] as a final line). - Or if you like, HASH(HASH(config-file) ++ t), for efficiency. (Where "++" means "append together in some standard fashion".) "HASH()" is your favourite hash function, e.g. SHA256(SHA256()). Thus RAND(t) is a 256-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. [For their application or for mine!] Someone producing the latest block, given the previous 99, can privately produce billions of cheap variations on it, by varying the order the transactions are listed etc, until they find, and publish, the one that "games" the randomness in their favour. 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 of bits of unknowable future entropy. That's all that matters for turning burnt coins into simulated mining rigs.)

Right then! What do we do with this RAND(t) stream? We simulate the capricious behaviour of a true proof-of-work mining rig! Let us assume that, in the real proof-of-work world, you can buy an h hashes/second mining rig for b=c*h BTC. (c varies with technical progress, BTC price fluctuations, etc; but in the simulated world it can just be left constant.) Or, inverting this, if you spend b BTC, you acquire a mining rig of h=b/c hashes/s power. Now, what does it actually mean for your rig to perform h hashes during 1 second? It means you're producing h uniform random numbers between 0 and 1. (That binary point again!) But you don't really care what they all are individually - how well you did during that 1 second is defined as "what was the '''lowest''' hash value you produced during that 1 second?". This is then inspected for whether it beats [is lower than] the network's current target; or, perhaps, whether it beats the lesser [i.e. numerically greater] target of a pooled mining operation. If it's good enough, that precious lowest hash is published to the network (or mining pool), and the others are just thrown away (not published). If it's not good enough, even the [not-so-]precious lowest hash isn't published - and certainly not the others. So, in the simulation, we only need to produce, for each second, a simulated "lowest hash for that 1 second". The "others" don't have to exist at all!

For reproducing (statistically) the pattern of hits and misses w.r.t. targets tough enough to not be achieving several hits within 1 second, and for h>>1, we can take the simulated lowest hash for time t to be (1/h) * HASH(signatures-of-the-act-of-burning-the-b-BTC ++ RAND(t)). [In fact this even works for h<1, despite the rather surreal appearance of "lowest hashes" >1 every so often in that case - i.e. values outside the range that ''real'' lowest (or any other!) hashes can ever actually be: it turns out this surreal behaviour is just what's needed to degrade the probability of beating the target by just the right amount. Values >1 in effect represent "I didn't generate any hashes at all during this particular 1-second window".]

Two further subtleties. First of all, it turns out to be desirable to include the block number (chain height @ 1 per block) in the formula - just to keep the owners of simulated mining rigs "on their toes" and not be able to tell a week or so in advance when they'll be lucky. (This encourages them to run a continuous full node. Maybe that's not in fact that important.) So we take simulated-lowest-hash = (1/h) * HASH(signatures-of-the-act-of-burning-the-b-BTC ++ block-number-of-would-be-block ++ RAND(t)). (We should '''not''' include finer details of the block, to avoid "gaming" a la the hundred blocks business I mentioned earlier. - Or if I'm wrong about that, then OK, by all means mix in finer details of the block!)

Secondly, it turns out that to keep the burning process going forever, rather than a pulse of initial burning that no-one ever again wants to contribute further burning to, we should simulate one more property of real-world mining rigs: they break down! That is, we should demurrage away the strength of a simulated mining rig. (A plea to the reader: Don't be alarmed by the word "demurrage". This is '''burnt''' coins I'm talking about - they ''should'' be treated "harshly", in whatever style mimics real-world mining rigs to the required fidelity. Ordinary unburnt coins are not being demurraged! [Unless that's independently desirable as a policy matter, e.g. if it's felt that network strength can only be achieved via more revenue for miners than fees alone will ever provide.]) A real mining rig likely works at full tilt for a few years and then conks out. We ''could'' demurrage each burnt coin in that style - it abruptly expires E years after its creation - but I think a smooth exponential demurrage is nicer, i.e. its burnt value after y years is b'=b*exp(-y/E). Thus h = b'/c = (b/c)*exp(-y/E). [And 1/h = c/b' = (c/b)*exp(y/E).]

Taking these two further subtleties into account, we get the following formula:

simulated-lowest-hash(t) = (c/b)*exp([t - t_burning]/E) * HASH(signatures-of-the-act-of-burning-the-b-BTC ++ block-number-of-would-be-block ++ RAND(t)).

So there you have it! With this formula, life as a miner is spookily similar to the real proof-of-work case. You "buy a mining rig" - you burn coins, and that hits ''you'' in exactly the way sending off money to a chip supplier would have hit you, even though over the whole economy, no real resources have been expended - and you then hope that, by submitting lucky hashes to the network in the form of blocks, you can make more back in fees over time than you spent initially. If you don't keep connected to the network, you won't know what transactions are eligible for including in your next would-be block, and your next lucky hash will run to waste. Meanwhile, other people are "buying mining rigs" (burning coins) too, either freshly or to make up for the "wearing out" of their existing ones; and the network is adjusting its target hash value [reciprocal difficulty] to regulate the rate all this mining effort is producing blocks at, to some preferred average rate. All spookily normal, in other words!

Now, I'm being a little bit disingenuous to say that ''everything'' is normal. We need protection against certain things (use of a lucky hash on two or more competing chains; timestamp-falsification abuse) which either do not exist at all under true proof-of-work - the former - or exist but with the consequences and mitigation strategy being different in detail - the latter. I believe I have a way of standing up to the various forms of malice we need to worry about of those kinds. More to follow soon hopefully!

=== Economic implications ===

The key insight is that verifiably, publicly burning some coins of a known-total-stock-issued currency is the same as "remurrage" (opposite of "demurrage" - it may not be a correct word, but it's a nice back-formation) on the remainder. That is, if there are verifiably 21 million issued-and-not-burned coins, and then you go to sleep and wake up later and there are now only 20 million issued-and-not-burned coins, that's the same as if some magic genie multiplied all wake-up-time nominal bitcoin figures by 21/20. Another way to see the identity of real effect would be to redefine "burning n bitcoins" to mean, not "sending n to an unspendable address", but rather "scattering" the n bitcoins, i.e. sending them to '''every existing''' [non-zero-balance] address, in proportion to the balance [sum of unspent txouts] already stored in each. This would be a horribly gigantic transaction to actually do explicitly, but the point is, burning can be thought of "as if" done that way. (Slogan: Quantity-deflation is remurrage in disguise, in exactly the same way that quantity-inflation is demurrage in disguise.)

So, what ''that'' means is, if while you're sleeping you (a non-miner) hold 1 bitcoin purely passively, i.e. it just sits undisturbed on the blockchain, well, when you wake up, it's as if you've received a "dividend" (of 5% in the particular numeric example above) on top of the general economy-tracking price we expect of a constant-quantity currency. In a world with actual, visibly performed remurrage, this is made explicit - your balance is now 21/20, with the nominal circulation [issued-and-not-burned, and remurraged for good measure] constant at 21 million. You can go and spend the 1/20 "dividend" on some treat, and still have the same fraction (1 out of 21 million) of the money stock as when you went to sleep.

In a world ''without'' any attempt at explicit remurrage, the real facts of the situation are (of course!) the same, but their nominal expression is not perhaps so instantly obvious. Your nominal holding is unchanged at 1; but this is now 1 part in 20 million of the whole money stock, not the 1 part in 21 million it was before. So, you can go and spend 1/21 of it on some treat, taking your nominal balance down to 20/21, and ''that'' nominal balance is the same (1 out of 21 million) fraction of the money stock as when you went to sleep.

So, basically, if you're holding bitcoins and trying to hold an "economy-tracking amount", no more and no less, you find you can go out into the market and use the fraction of your holdings that counts as "dividend above and beyond economy-tracking" on some treat or other. (Indeed, "you can go out..." should read "you ''must'' go out...", if you're really determined to pursue precisely that tracking strategy.)

Who's selling you the real resources embodied in the "treat"? And what's ''their'' motive? Well, transaction fee payers presumably like to re-stock their bitcoin real balances to roughly the same [economy-tracking] level as before, on average - they're paying for the fee processing as a service. These fees are then burned by miners. (Well, not literally the fees themselves - the fees themselves are ''collected'' by miners, but the way they achieve this is to burn an approximately equal amount, as explained earlier.) So, ordinary Bitcoin users, to achieve their desired re-stocking, have to either produce slightly more, or consume slightly less, or a proper or improper mixture thereof, than they would have needed to in a hypothetical (presumably impracticable) alternative world where they pay no fees for their everyday transactions (and some magic mining-god just altruistically and reliably creates a blockchain out of all the transactions, without charging anybody anything). [This follows directly from their re-stocking desire, and has nothing to do with proof-of-burn specifically. That is, they have to do this regardless of whether the protocol is proof-of-work, proof-of-stake, proof-of-burn or whatever.] It's that extra gap between production and consumption - "extra" on top of whatever gap people are already choosing as a real saving[/dis-saving] strategy - that goes on to the market, for you and all other bitcoin holders to bid off the market by spending on your "treat".

This whole stable pattern of spending habits is, perhaps surprisingly, the same pattern of real resource allocation as would have happened if Cunicula's proof of stake (with close to 100% stake / 0% work admixture) had been in operation, and all bitcoin holders, large and small, had enthusiastically thrown their bitcoins (that is, their stream of bitcoin days destroyed) into the stake-claiming process. The fraction of fees they'd collect if they did that would be just like the "dividend" as I called it above - it would be like explicit remurrage, except instead of being automatic, it would require each holder's active participation (i.e. they couldn't just go to sleep, unless they left some sort of "trusted bot" running and using their private keys to sign their stream of bitcoin days destroyed). So, if you like, proof-of-burn is like automated, 100%-stakeholder-participation Cunicula-style proof-of-stake!

Incidentally, it's also fascinating to consider what happens if the community does decide a demurraging of [ordinary, unburnt] coins, the revenue being added as a coin-[re-]minting stream to the flow of fees, ''is'' necessary to continue with forever, for the sake of network strength. The amazing answer, as far as I can honestly work out, is that in long-run equilibrium, the burn rate is just such as '''to make hardly any of this demurrage ''real'' demurrage at all!''' [The implicit remurrage of burning almost exactly cancels the explicit demurrage of network-strengthening coin-[re-]minting! (Or if you like, the implicit demurrage of inflationary fresh-coin-minting.) Either way, we ''seem'' to get the possibility of amazing network strength "for free"!] This opens up the shocking possibility of turning up the demurrage/inflation rate to startlingly high levels - 5% of money stock / year, 10% of money stock / year... levels that would bring the whole cryptocurrency into disrepute in the true proof-of-work case, since coin-holders really would suffer that actual amount of explicit or implicit demurrage - and yet '''not''' hitting coin-holders with more than a frictional residual fraction of that ''in real terms'' at all, because of the way burning simulates remurrage! Extraordinary stuff! I plan to say more about this soon - but this quick teaser description should already be food for thought.

=== Coin-burning as a tool for transition between cryptocurrencies ===

Proof of burn may also be of interest as a tool for managing an orderly transition from one cryptocurrency ("oldcoin", let's call it) to another ("newcoin"). If the developers of newcoin are looking for a way of avoiding proof-of-work's real resource consumption '''even in newcoin's initial distribution phase''', they can't use proof of newcoin-burn: newcoins don't exist yet. But they ''can'' use proof of oldcoin-burn! (Assuming their reason for creating newcoin is '''not''' a doubting of oldcoin's security model, anyway. - Or at least, not a doubting severe enough to affect sufficiently deeply buried oldcoins, these being the candidates for burning.)

The newcoin blockchain would thus start with (at least a hash referring to) a complete catalogue of all the [sufficiently deeply buried] unspent txouts of oldcoin. Miners would then exhibit burning events within oldcoin up to a certain date; after which, the protocol would switch to burning of newcoin itself (and the dependency on oldcoin could even be thrown away entirely, if a checkpoint of that transition moment was promulgated and accepted by the newcoin community).

This has the nice consequence that, if people throughout the broader economy are gradually deserting oldcoin (as newcoin catches on), '''''its value need not collapse!''''' Instead, oldcoin gets burnt in the transition process, neatly reducing its nominal supply in just such a way as to roughly keep pace with its declining real demand. Meanwhile, those same acts of burning are minting fresh newcoins, at just the pace required to keep up with newcoin's ''growing'' real demand. (At least, that's the case if miners anticipate the transition speed correctly, and enter / exit the coins' respective mining trades at a pace that competes away supra-normal profits. We also have to assume that the ''total'' real demand for both[/all...] cryptocurrencies is roughly stable in "economy-tracking" terms; or at least, that miners anticipate the time path of the size of total real demand, and of its currency-by-currency composition, correctly, or near enough correctly.)

'''To sum up:''' proof of burn ''could'', just maybe, qualify as a new tool to greatly assist overall (multi-cryptocurrency) economic robustness and stability!

== Earlier work suggesting a role for the burning of coins ==

[https://bitcointalk.org/index.php?topic=131139.msg1404195#msg1404195 Forum member ripper234 points out] an earlier work by forum member [https://bitcointalk.org/index.php?action=profile;u=3313 dacoinminster] suggesting coins could be burnt as one component of a broader protocol. [https://bitcointalk.org/index.php?topic=56901.0 The earlier work] is [http://bitcoin.stackexchange.com/questions/2458/is-dacoinminsters-second-bitcoin-whitepaper-logically-economically-consistent discussed on StackExchange]. It revolves around a centralised "trusted entity" system, and so is not directly comparable to decentralised proof-of-burn mining; but it may be of interest to some readers.

== See also ==
*[[Proof_of_work|Proof of work]]
*[[Proof_of_Stake|Proof of stake]]

[[category:mining]]

Proof of burn

2012-12-17T03:47:42Z

Ids: /* See also */ becomes "Earlier work suggesting a role for the burning of coins" (and then its previous self)

'''Proof of burn''' is a potential alternative to [[Proof_of_work|proof of work]] and [[Proof_of_Stake|proof of stake]] as a "scarce resource" to be exhibited by miners competing for the stream of rewards (minted coins and transaction fees) which a cryptocurrency's design makes available. 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 unlike proof of work, it consumes no real resources from a whole economy perspective. This has interesting implications, discussed below.

There are likely many possible variants of proof of burn. This page currently describes [[User:Ids|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 ==

=== Introduction and motivation ===

The key idea of proof-of-burn (this would also apply to proof-of-stake, by the way) is that when choosing the thing which is to qualify as a "difficulty", i.e. to require miners to exhibit proof that they've "done something that's tough to do", all that matters is that '''an individual miner''' finds the task expensive. (Well... it also matters that everyone else should find it cheap to verify that it has been done.) 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 all 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.e. [the fast early phase of] its initial distribution) - or, more precisely, while ''the first'' cryptocurrency is being set up; more on this distinction later! - no good alternative has been proposed. (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 variety", I mean) is in 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: burning the currency!

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. With Bitcoin, any address which is [the RIPEMD160/SHA256 hash of] a script that evaluates to false will do. 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 RIPEMD160 since you can choose big numbers to taste. So, bitcoins sent to such a txout can never be redeemed on a future txin. (Barring the cracking of RIPEMD160 and the finding of an alternative matching script, that is. If ''that'' happens, the cryptocurrency is in 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. (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: burning merely needs to be defined as sending to some ''fixed'' unspendable address, with no variation - e.g. we could settle on the hash of "push 4, and check if it's equal to 5".

So, miners are creating candidate winning blocks by saying to the listening world, not "Look! I've done this many trillion hashes! [or struck lucky with fewer: you, the listening world, wouldn't know the difference... but this doesn't matter...]", but rather "Look! 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! Thanks!" That extremely recent act of burning could be undone in a block chain reorganisation; and then the same miner would be able to "re-burn" those same coins in an attempt to grab a block afresh, post-reorganisation. 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. A proof-of-work miner must simply shrug and say "Oh well, that's those expenses [electricity, mining rig rental / imputed rental,...] lost and gone... time to try again!" And that's the way things should be, for security - it '''should not''' be as cheap to extend the height of two or more competing chains as it is to focus on one. (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. Details to follow.

Now then! 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 users are sending them fees (and any coin-minting still going on too of course), minus the miners' true real-resource costs (i.e. the hardware and electricity and the like for handling transactions and blocks and burn proofs - these costs will be far lower than the hashing costs incurred under proof-of-work, but of course still non-zero). 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.

=== Technical sketch of proof of burn: "Burnt coins are mining rigs!" ===

''Iain Stewart writes:'' 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:

'''''"Burnt coins are mining rigs!"'''''

What that slogan means will become clear as I go on. Basically, 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! - to simulate the generating of random hashes that a real proof-of-work mining rig would produce. Now, obviously we don't want to "simulate" every actual hash! A "simulation" of proof-of-work at ''that'' level of detail would just ''be'' proof-of-work! Rather, we want to mimic the statistical properties of a mining rig's stream of hashes, to just the level of detail required to give the same sort of pattern of meeting / not meeting a moving difficulty target, and all the rest of it, that we get with the real thing.

So: first of all, what exactly is my "stream of true randomness"? Chop up time into units considerably shorter than the intended inter-block time, but 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!) at time t, they can't predict the value of RAND(any t' 2 months or more to the future of t). [Where "2 months" means the dead time a burnt coin must wait before it becomes a simulated active mining rig. 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.] We do '''not''' need fresh statistical independence of RAND(t) w.r.t. all of RAND(t-1), RAND(t-2), RAND(t-3), etc. (And we don't mind if the stream is known a "short" time into the future - e.g. a week or two; at any rate a small portion of the waiting period.)

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: lotteries. 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.dat or whatever) should get "the latest lottery results" appended to it. 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. Like this:

.
.
.
for use from 2013-06-24 00:00:00 onwards: UK national lottery 2013-06-12: 4 9 20 22 37 42, bonus ball 19
for use from 2013-07-01 00:00:00 onwards: UK national lottery 2013-06-19: 7 12 14 19 33 41, bonus ball 28

(Obviously the meta-level words "for use from... onwards" aren't really needed - I just put them in for clarity.) Each line is added in a leisurely, unhurried fashion, at some time (it doesn't matter when) between the draw and the intended start-paying-attention-to-it date. (Some time between 2013-06-19 and 2013-07-01 00:00:00, in the case of the example last line above.) 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.g. 2013-07-02 23:14:05, or just the Unix numeric time] as a final line). - Or if you like, HASH(HASH(config-file) ++ t), for efficiency. (Where "++" means "append together in some standard fashion".) "HASH()" is your favourite hash function, e.g. SHA256(SHA256()). Thus RAND(t) is a 256-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. [For their application or for mine!] Someone producing the latest block, given the previous 99, can privately produce billions of cheap variations on it, by varying the order the transactions are listed etc, until they find, and publish, the one that "games" the randomness in their favour. 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 of bits of unknowable future entropy. That's all that matters for turning burnt coins into simulated mining rigs.)

Right then! What do we do with this RAND(t) stream? We simulate the capricious behaviour of a true proof-of-work mining rig! Let us assume that, in the real proof-of-work world, you can buy an h hashes/second mining rig for b=c*h BTC. (c varies with technical progress, BTC price fluctuations, etc; but in the simulated world it can just be left constant.) Or, inverting this, if you spend b BTC, you acquire a mining rig of h=b/c hashes/s power. Now, what does it actually mean for your rig to perform h hashes during 1 second? It means you're producing h uniform random numbers between 0 and 1. (That binary point again!) But you don't really care what they all are individually - how well you did during that 1 second is defined as "what was the '''lowest''' hash value you produced during that 1 second?". This is then inspected for whether it beats [is lower than] the network's current target; or, perhaps, whether it beats the lesser [i.e. numerically greater] target of a pooled mining operation. If it's good enough, that precious lowest hash is published to the network (or mining pool), and the others are just thrown away (not published). If it's not good enough, even the [not-so-]precious lowest hash isn't published - and certainly not the others. So, in the simulation, we only need to produce, for each second, a simulated "lowest hash for that 1 second". The "others" don't have to exist at all!

For reproducing (statistically) the pattern of hits and misses w.r.t. targets tough enough to not be achieving several hits within 1 second, and for h>>1, we can take the simulated lowest hash for time t to be (1/h) * HASH(signatures-of-the-act-of-burning-the-b-BTC ++ RAND(t)). [In fact this even works for h<1, despite the rather surreal appearance of "lowest hashes" >1 every so often in that case - i.e. values outside the range that ''real'' lowest (or any other!) hashes can ever actually be: it turns out this surreal behaviour is just what's needed to degrade the probability of beating the target by just the right amount. Values >1 in effect represent "I didn't generate any hashes at all during this particular 1-second window".]

Two further subtleties. First of all, it turns out to be desirable to include the block number (chain height @ 1 per block) in the formula - just to keep the owners of simulated mining rigs "on their toes" and not be able to tell a week or so in advance when they'll be lucky. (This encourages them to run a continuous full node. Maybe that's not in fact that important.) So we take simulated-lowest-hash = (1/h) * HASH(signatures-of-the-act-of-burning-the-b-BTC ++ block-number-of-would-be-block ++ RAND(t)). (We should '''not''' include finer details of the block, to avoid "gaming" a la the hundred blocks business I mentioned earlier. - Or if I'm wrong about that, then OK, by all means mix in finer details of the block!)

Secondly, it turns out that to keep the burning process going forever, rather than a pulse of initial burning that no-one ever again wants to contribute further burning to, we should simulate one more property of real-world mining rigs: they break down! That is, we should demurrage away the strength of a simulated mining rig. (A plea to the reader: Don't be alarmed by the word "demurrage". This is '''burnt''' coins I'm talking about - they ''should'' be treated "harshly", in whatever style mimics real-world mining rigs to the required fidelity. Ordinary unburnt coins are not being demurraged! [Unless that's independently desirable as a policy matter, e.g. if it's felt that network strength can only be achieved via more revenue for miners than fees alone will ever provide.]) A real mining rig likely works at full tilt for a few years and then conks out. We ''could'' demurrage each burnt coin in that style - it abruptly expires E years after its creation - but I think a smooth exponential demurrage is nicer, i.e. its burnt value after y years is b'=b*exp(-y/E). Thus h = b'/c = (b/c)*exp(-y/E). [And 1/h = c/b' = (c/b)*exp(y/E).]

Taking these two further subtleties into account, we get the following formula:

simulated-lowest-hash(t) = (c/b)*exp([t - t_burning]/E) * HASH(signatures-of-the-act-of-burning-the-b-BTC ++ block-number-of-would-be-block ++ RAND(t)).

So there you have it! With this formula, life as a miner is spookily similar to the real proof-of-work case. You "buy a mining rig" - you burn coins, and that hits ''you'' in exactly the way sending off money to a chip supplier would have hit you, even though over the whole economy, no real resources have been expended - and you then hope that, by submitting lucky hashes to the network in the form of blocks, you can make more back in fees over time than you spent initially. If you don't keep connected to the network, you won't know what transactions are eligible for including in your next would-be block, and your next lucky hash will run to waste. Meanwhile, other people are "buying mining rigs" (burning coins) too, either freshly or to make up for the "wearing out" of their existing ones; and the network is adjusting its target hash value [reciprocal difficulty] to regulate the rate all this mining effort is producing blocks at, to some preferred average rate. All spookily normal, in other words!

Now, I'm being a little bit disingenuous to say that ''everything'' is normal. We need protection against certain things (use of a lucky hash on two or more competing chains; timestamp-falsification abuse) which either do not exist at all under true proof-of-work - the former - or exist but with the consequences and mitigation strategy being different in detail - the latter. I believe I have a way of standing up to the various forms of malice we need to worry about of those kinds. More to follow soon hopefully!

=== Economic implications ===

The key insight is that verifiably, publicly burning some coins of a known-total-stock-issued currency is the same as "remurrage" (opposite of "demurrage" - it may not be a correct word, but it's a nice back-formation) on the remainder. That is, if there are verifiably 21 million issued-and-not-burned coins, and then you go to sleep and wake up later and there are now only 20 million issued-and-not-burned coins, that's the same as if some magic genie multiplied all wake-up-time nominal bitcoin figures by 21/20. Another way to see the identity of real effect would be to redefine "burning n bitcoins" to mean, not "sending n to an unspendable address", but rather "scattering" the n bitcoins, i.e. sending them to '''every existing''' [non-zero-balance] address, in proportion to the balance [sum of unspent txouts] already stored in each. This would be a horribly gigantic transaction to actually do explicitly, but the point is, burning can be thought of "as if" done that way. (Slogan: Quantity-deflation is remurrage in disguise, in exactly the same way that quantity-inflation is demurrage in disguise.)

So, what ''that'' means is, if while you're sleeping you (a non-miner) hold 1 bitcoin purely passively, i.e. it just sits undisturbed on the blockchain, well, when you wake up, it's as if you've received a "dividend" (of 5% in the particular numeric example above) on top of the general economy-tracking price we expect of a constant-quantity currency. In a world with actual, visibly performed remurrage, this is made explicit - your balance is now 21/20, with the nominal circulation [issued-and-not-burned, and remurraged for good measure] constant at 21 million. You can go and spend the 1/20 "dividend" on some treat, and still have the same fraction (1 out of 21 million) of the money stock as when you went to sleep.

In a world ''without'' any attempt at explicit remurrage, the real facts of the situation are (of course!) the same, but their nominal expression is not perhaps so instantly obvious. Your nominal holding is unchanged at 1; but this is now 1 part in 20 million of the whole money stock, not the 1 part in 21 million it was before. So, you can go and spend 1/21 of it on some treat, taking your nominal balance down to 20/21, and ''that'' nominal balance is the same (1 out of 21 million) fraction of the money stock as when you went to sleep.

So, basically, if you're holding bitcoins and trying to hold an "economy-tracking amount", no more and no less, you find you can go out into the market and use the fraction of your holdings that counts as "dividend above and beyond economy-tracking" on some treat or other. (Indeed, "you can go out..." should read "you ''must'' go out...", if you're really determined to pursue precisely that tracking strategy.)

Who's selling you the real resources embodied in the "treat"? And what's ''their'' motive? Well, transaction fee payers presumably like to re-stock their bitcoin real balances to roughly the same [economy-tracking] level as before, on average - they're paying for the fee processing as a service. These fees are then burned by miners. (Well, not literally the fees themselves - the fees themselves are ''collected'' by miners, but the way they achieve this is to burn an approximately equal amount, as explained earlier.) So, ordinary Bitcoin users, to achieve their desired re-stocking, have to either produce slightly more, or consume slightly less, or a proper or improper mixture thereof, than they would have needed to in a hypothetical (presumably impracticable) alternative world where they pay no fees for their everyday transactions (and some magic mining-god just altruistically and reliably creates a blockchain out of all the transactions, without charging anybody anything). [This follows directly from their re-stocking desire, and has nothing to do with proof-of-burn specifically. That is, they have to do this regardless of whether the protocol is proof-of-work, proof-of-stake, proof-of-burn or whatever.] It's that extra gap between production and consumption - "extra" on top of whatever gap people are already choosing as a real saving[/dis-saving] strategy - that goes on to the market, for you and all other bitcoin holders to bid off the market by spending on your "treat".

This whole stable pattern of spending habits is, perhaps surprisingly, the same pattern of real resource allocation as would have happened if Cunicula's proof of stake (with close to 100% stake / 0% work admixture) had been in operation, and all bitcoin holders, large and small, had enthusiastically thrown their bitcoins (that is, their stream of bitcoin days destroyed) into the stake-claiming process. The fraction of fees they'd collect if they did that would be just like the "dividend" as I called it above - it would be like explicit remurrage, except instead of being automatic, it would require each holder's active participation (i.e. they couldn't just go to sleep, unless they left some sort of "trusted bot" running and using their private keys to sign their stream of bitcoin days destroyed). So, if you like, proof-of-burn is like automated, 100%-stakeholder-participation Cunicula-style proof-of-stake!

Incidentally, it's also fascinating to consider what happens if the community does decide a demurraging of [ordinary, unburnt] coins, the revenue being added as a coin-[re-]minting stream to the flow of fees, ''is'' necessary to continue with forever, for the sake of network strength. The amazing answer, as far as I can honestly work out, is that in long-run equilibrium, the burn rate is just such as '''to make hardly any of this demurrage ''real'' demurrage at all!''' [The implicit remurrage of burning almost exactly cancels the explicit demurrage of network-strengthening coin-[re-]minting! (Or if you like, the implicit demurrage of inflationary fresh-coin-minting.) Either way, we ''seem'' to get the possibility of amazing network strength "for free"!] This opens up the shocking possibility of turning up the demurrage/inflation rate to startlingly high levels - 5% of money stock / year, 10% of money stock / year... levels that would bring the whole cryptocurrency into disrepute in the true proof-of-work case, since coin-holders really would suffer that actual amount of explicit or implicit demurrage - and yet '''not''' hitting coin-holders with more than a frictional residual fraction of that ''in real terms'' at all, because of the way burning simulates remurrage! Extraordinary stuff! I plan to say more about this soon - but this quick teaser description should already be food for thought.

=== Coin-burning as a tool for transition between cryptocurrencies ===

Proof of burn may also be of interest as a tool for managing an orderly transition from one cryptocurrency ("oldcoin", let's call it) to another ("newcoin"). If the developers of newcoin are looking for a way of avoiding proof-of-work's real resource consumption '''even in newcoin's initial distribution phase''', they can't use proof of newcoin-burn: newcoins don't exist yet. But they ''can'' use proof of oldcoin-burn! (Assuming their reason for creating newcoin is '''not''' a doubting of oldcoin's security model, anyway. - Or at least, not a doubting severe enough to affect sufficiently deeply buried oldcoins, these being the candidates for burning.)

The newcoin blockchain would thus start with (at least a hash referring to) a complete catalogue of all the [sufficiently deeply buried] unspent txouts of oldcoin. Miners would then exhibit burning events within oldcoin up to a certain date; after which, the protocol would switch to burning of newcoin itself (and the dependency on oldcoin could even be thrown away entirely, if a checkpoint of that transition moment was promulgated and accepted by the newcoin community).

This has the nice consequence that, if people throughout the broader economy are gradually deserting oldcoin (as newcoin catches on), '''''its value need not collapse!''''' Instead, oldcoin gets burnt in the transition process, neatly reducing its nominal supply in just such a way as to roughly keep pace with its declining real demand. Meanwhile, those same acts of burning are minting fresh newcoins, at just the pace required to keep up with newcoin's ''growing'' real demand. (At least, that's the case if miners anticipate the transition speed correctly, and enter / exit the coins' respective mining trades at a pace that competes away supra-normal profits. We also have to assume that the ''total'' real demand for both[/all...] cryptocurrencies is roughly stable in "economy-tracking" terms; or at least, that miners anticipate the time path of the size of total real demand, and of its currency-by-currency composition, correctly, or near enough correctly.)

'''To sum up:''' proof of burn ''could'', just maybe, qualify as a new tool to greatly assist overall (multi-cryptocurrency) economic robustness and stability!

== Earlier work suggesting a role for the burning of coins ==

[https://bitcointalk.org/index.php?topic=131139.msg1404195#msg1404195 Forum member ripper234 points out] an earlier work suggesting coins could be burnt as one component of a broader protocol. The earlier work is [http://bitcoin.stackexchange.com/questions/2458/is-dacoinminsters-second-bitcoin-whitepaper-logically-economically-consistent described on StackExchange]. It revolves around a centralised "trusted entity" system, and so is not directly comparable to decentralised proof-of-burn mining; but it may be of interest to some readers.

== See also ==
*[[Proof_of_work|Proof of work]]
*[[Proof_of_Stake|Proof of stake]]

[[category:mining]]

Proof of burn

2012-12-16T23:58:51Z

Ids: it may as well go in the category "mining", since proof of stake is there... maybe not the world's best category (for either of them!) though?

'''Proof of burn''' is a potential alternative to [[Proof_of_work|proof of work]] and [[Proof_of_Stake|proof of stake]] as a "scarce resource" to be exhibited by miners competing for the stream of rewards (minted coins and transaction fees) which a cryptocurrency's design makes available. 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 unlike proof of work, it consumes no real resources from a whole economy perspective. This has interesting implications, discussed below.

There are likely many possible variants of proof of burn. This page currently describes [[User:Ids|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 ==

=== Introduction and motivation ===

The key idea of proof-of-burn (this would also apply to proof-of-stake, by the way) is that when choosing the thing which is to qualify as a "difficulty", i.e. to require miners to exhibit proof that they've "done something that's tough to do", all that matters is that '''an individual miner''' finds the task expensive. (Well... it also matters that everyone else should find it cheap to verify that it has been done.) 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 all 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.e. [the fast early phase of] its initial distribution) - or, more precisely, while ''the first'' cryptocurrency is being set up; more on this distinction later! - no good alternative has been proposed. (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 variety", I mean) is in 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: burning the currency!

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. With Bitcoin, any address which is [the RIPEMD160/SHA256 hash of] a script that evaluates to false will do. 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 RIPEMD160 since you can choose big numbers to taste. So, bitcoins sent to such a txout can never be redeemed on a future txin. (Barring the cracking of RIPEMD160 and the finding of an alternative matching script, that is. If ''that'' happens, the cryptocurrency is in 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. (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: burning merely needs to be defined as sending to some ''fixed'' unspendable address, with no variation - e.g. we could settle on the hash of "push 4, and check if it's equal to 5".

So, miners are creating candidate winning blocks by saying to the listening world, not "Look! I've done this many trillion hashes! [or struck lucky with fewer: you, the listening world, wouldn't know the difference... but this doesn't matter...]", but rather "Look! 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! Thanks!" That extremely recent act of burning could be undone in a block chain reorganisation; and then the same miner would be able to "re-burn" those same coins in an attempt to grab a block afresh, post-reorganisation. 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. A proof-of-work miner must simply shrug and say "Oh well, that's those expenses [electricity, mining rig rental / imputed rental,...] lost and gone... time to try again!" And that's the way things should be, for security - it '''should not''' be as cheap to extend the height of two or more competing chains as it is to focus on one. (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. Details to follow.

Now then! 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 users are sending them fees (and any coin-minting still going on too of course), minus the miners' true real-resource costs (i.e. the hardware and electricity and the like for handling transactions and blocks and burn proofs - these costs will be far lower than the hashing costs incurred under proof-of-work, but of course still non-zero). 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.

=== Technical sketch of proof of burn: "Burnt coins are mining rigs!" ===

''Iain Stewart writes:'' 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:

'''''"Burnt coins are mining rigs!"'''''

What that slogan means will become clear as I go on. Basically, 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! - to simulate the generating of random hashes that a real proof-of-work mining rig would produce. Now, obviously we don't want to "simulate" every actual hash! A "simulation" of proof-of-work at ''that'' level of detail would just ''be'' proof-of-work! Rather, we want to mimic the statistical properties of a mining rig's stream of hashes, to just the level of detail required to give the same sort of pattern of meeting / not meeting a moving difficulty target, and all the rest of it, that we get with the real thing.

So: first of all, what exactly is my "stream of true randomness"? Chop up time into units considerably shorter than the intended inter-block time, but 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!) at time t, they can't predict the value of RAND(any t' 2 months or more to the future of t). [Where "2 months" means the dead time a burnt coin must wait before it becomes a simulated active mining rig. 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.] We do '''not''' need fresh statistical independence of RAND(t) w.r.t. all of RAND(t-1), RAND(t-2), RAND(t-3), etc. (And we don't mind if the stream is known a "short" time into the future - e.g. a week or two; at any rate a small portion of the waiting period.)

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: lotteries. 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.dat or whatever) should get "the latest lottery results" appended to it. 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. Like this:

.
.
.
for use from 2013-06-24 00:00:00 onwards: UK national lottery 2013-06-12: 4 9 20 22 37 42, bonus ball 19
for use from 2013-07-01 00:00:00 onwards: UK national lottery 2013-06-19: 7 12 14 19 33 41, bonus ball 28

(Obviously the meta-level words "for use from... onwards" aren't really needed - I just put them in for clarity.) Each line is added in a leisurely, unhurried fashion, at some time (it doesn't matter when) between the draw and the intended start-paying-attention-to-it date. (Some time between 2013-06-19 and 2013-07-01 00:00:00, in the case of the example last line above.) 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.g. 2013-07-02 23:14:05, or just the Unix numeric time] as a final line). - Or if you like, HASH(HASH(config-file) ++ t), for efficiency. (Where "++" means "append together in some standard fashion".) "HASH()" is your favourite hash function, e.g. SHA256(SHA256()). Thus RAND(t) is a 256-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. [For their application or for mine!] Someone producing the latest block, given the previous 99, can privately produce billions of cheap variations on it, by varying the order the transactions are listed etc, until they find, and publish, the one that "games" the randomness in their favour. 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 of bits of unknowable future entropy. That's all that matters for turning burnt coins into simulated mining rigs.)

Right then! What do we do with this RAND(t) stream? We simulate the capricious behaviour of a true proof-of-work mining rig! Let us assume that, in the real proof-of-work world, you can buy an h hashes/second mining rig for b=c*h BTC. (c varies with technical progress, BTC price fluctuations, etc; but in the simulated world it can just be left constant.) Or, inverting this, if you spend b BTC, you acquire a mining rig of h=b/c hashes/s power. Now, what does it actually mean for your rig to perform h hashes during 1 second? It means you're producing h uniform random numbers between 0 and 1. (That binary point again!) But you don't really care what they all are individually - how well you did during that 1 second is defined as "what was the '''lowest''' hash value you produced during that 1 second?". This is then inspected for whether it beats [is lower than] the network's current target; or, perhaps, whether it beats the lesser [i.e. numerically greater] target of a pooled mining operation. If it's good enough, that precious lowest hash is published to the network (or mining pool), and the others are just thrown away (not published). If it's not good enough, even the [not-so-]precious lowest hash isn't published - and certainly not the others. So, in the simulation, we only need to produce, for each second, a simulated "lowest hash for that 1 second". The "others" don't have to exist at all!

For reproducing (statistically) the pattern of hits and misses w.r.t. targets tough enough to not be achieving several hits within 1 second, and for h>>1, we can take the simulated lowest hash for time t to be (1/h) * HASH(signatures-of-the-act-of-burning-the-b-BTC ++ RAND(t)). [In fact this even works for h<1, despite the rather surreal appearance of "lowest hashes" >1 every so often in that case - i.e. values outside the range that ''real'' lowest (or any other!) hashes can ever actually be: it turns out this surreal behaviour is just what's needed to degrade the probability of beating the target by just the right amount. Values >1 in effect represent "I didn't generate any hashes at all during this particular 1-second window".]

Two further subtleties. First of all, it turns out to be desirable to include the block number (chain height @ 1 per block) in the formula - just to keep the owners of simulated mining rigs "on their toes" and not be able to tell a week or so in advance when they'll be lucky. (This encourages them to run a continuous full node. Maybe that's not in fact that important.) So we take simulated-lowest-hash = (1/h) * HASH(signatures-of-the-act-of-burning-the-b-BTC ++ block-number-of-would-be-block ++ RAND(t)). (We should '''not''' include finer details of the block, to avoid "gaming" a la the hundred blocks business I mentioned earlier. - Or if I'm wrong about that, then OK, by all means mix in finer details of the block!)

Secondly, it turns out that to keep the burning process going forever, rather than a pulse of initial burning that no-one ever again wants to contribute further burning to, we should simulate one more property of real-world mining rigs: they break down! That is, we should demurrage away the strength of a simulated mining rig. (A plea to the reader: Don't be alarmed by the word "demurrage". This is '''burnt''' coins I'm talking about - they ''should'' be treated "harshly", in whatever style mimics real-world mining rigs to the required fidelity. Ordinary unburnt coins are not being demurraged! [Unless that's independently desirable as a policy matter, e.g. if it's felt that network strength can only be achieved via more revenue for miners than fees alone will ever provide.]) A real mining rig likely works at full tilt for a few years and then conks out. We ''could'' demurrage each burnt coin in that style - it abruptly expires E years after its creation - but I think a smooth exponential demurrage is nicer, i.e. its burnt value after y years is b'=b*exp(-y/E). Thus h = b'/c = (b/c)*exp(-y/E). [And 1/h = c/b' = (c/b)*exp(y/E).]

Taking these two further subtleties into account, we get the following formula:

simulated-lowest-hash(t) = (c/b)*exp([t - t_burning]/E) * HASH(signatures-of-the-act-of-burning-the-b-BTC ++ block-number-of-would-be-block ++ RAND(t)).

So there you have it! With this formula, life as a miner is spookily similar to the real proof-of-work case. You "buy a mining rig" - you burn coins, and that hits ''you'' in exactly the way sending off money to a chip supplier would have hit you, even though over the whole economy, no real resources have been expended - and you then hope that, by submitting lucky hashes to the network in the form of blocks, you can make more back in fees over time than you spent initially. If you don't keep connected to the network, you won't know what transactions are eligible for including in your next would-be block, and your next lucky hash will run to waste. Meanwhile, other people are "buying mining rigs" (burning coins) too, either freshly or to make up for the "wearing out" of their existing ones; and the network is adjusting its target hash value [reciprocal difficulty] to regulate the rate all this mining effort is producing blocks at, to some preferred average rate. All spookily normal, in other words!

Now, I'm being a little bit disingenuous to say that ''everything'' is normal. We need protection against certain things (use of a lucky hash on two or more competing chains; timestamp-falsification abuse) which either do not exist at all under true proof-of-work - the former - or exist but with the consequences and mitigation strategy being different in detail - the latter. I believe I have a way of standing up to the various forms of malice we need to worry about of those kinds. More to follow soon hopefully!

=== Economic implications ===

The key insight is that verifiably, publicly burning some coins of a known-total-stock-issued currency is the same as "remurrage" (opposite of "demurrage" - it may not be a correct word, but it's a nice back-formation) on the remainder. That is, if there are verifiably 21 million issued-and-not-burned coins, and then you go to sleep and wake up later and there are now only 20 million issued-and-not-burned coins, that's the same as if some magic genie multiplied all wake-up-time nominal bitcoin figures by 21/20. Another way to see the identity of real effect would be to redefine "burning n bitcoins" to mean, not "sending n to an unspendable address", but rather "scattering" the n bitcoins, i.e. sending them to '''every existing''' [non-zero-balance] address, in proportion to the balance [sum of unspent txouts] already stored in each. This would be a horribly gigantic transaction to actually do explicitly, but the point is, burning can be thought of "as if" done that way. (Slogan: Quantity-deflation is remurrage in disguise, in exactly the same way that quantity-inflation is demurrage in disguise.)

So, what ''that'' means is, if while you're sleeping you (a non-miner) hold 1 bitcoin purely passively, i.e. it just sits undisturbed on the blockchain, well, when you wake up, it's as if you've received a "dividend" (of 5% in the particular numeric example above) on top of the general economy-tracking price we expect of a constant-quantity currency. In a world with actual, visibly performed remurrage, this is made explicit - your balance is now 21/20, with the nominal circulation [issued-and-not-burned, and remurraged for good measure] constant at 21 million. You can go and spend the 1/20 "dividend" on some treat, and still have the same fraction (1 out of 21 million) of the money stock as when you went to sleep.

In a world ''without'' any attempt at explicit remurrage, the real facts of the situation are (of course!) the same, but their nominal expression is not perhaps so instantly obvious. Your nominal holding is unchanged at 1; but this is now 1 part in 20 million of the whole money stock, not the 1 part in 21 million it was before. So, you can go and spend 1/21 of it on some treat, taking your nominal balance down to 20/21, and ''that'' nominal balance is the same (1 out of 21 million) fraction of the money stock as when you went to sleep.

So, basically, if you're holding bitcoins and trying to hold an "economy-tracking amount", no more and no less, you find you can go out into the market and use the fraction of your holdings that counts as "dividend above and beyond economy-tracking" on some treat or other. (Indeed, "you can go out..." should read "you ''must'' go out...", if you're really determined to pursue precisely that tracking strategy.)

Who's selling you the real resources embodied in the "treat"? And what's ''their'' motive? Well, transaction fee payers presumably like to re-stock their bitcoin real balances to roughly the same [economy-tracking] level as before, on average - they're paying for the fee processing as a service. These fees are then burned by miners. (Well, not literally the fees themselves - the fees themselves are ''collected'' by miners, but the way they achieve this is to burn an approximately equal amount, as explained earlier.) So, ordinary Bitcoin users, to achieve their desired re-stocking, have to either produce slightly more, or consume slightly less, or a proper or improper mixture thereof, than they would have needed to in a hypothetical (presumably impracticable) alternative world where they pay no fees for their everyday transactions (and some magic mining-god just altruistically and reliably creates a blockchain out of all the transactions, without charging anybody anything). [This follows directly from their re-stocking desire, and has nothing to do with proof-of-burn specifically. That is, they have to do this regardless of whether the protocol is proof-of-work, proof-of-stake, proof-of-burn or whatever.] It's that extra gap between production and consumption - "extra" on top of whatever gap people are already choosing as a real saving[/dis-saving] strategy - that goes on to the market, for you and all other bitcoin holders to bid off the market by spending on your "treat".

This whole stable pattern of spending habits is, perhaps surprisingly, the same pattern of real resource allocation as would have happened if Cunicula's proof of stake (with close to 100% stake / 0% work admixture) had been in operation, and all bitcoin holders, large and small, had enthusiastically thrown their bitcoins (that is, their stream of bitcoin days destroyed) into the stake-claiming process. The fraction of fees they'd collect if they did that would be just like the "dividend" as I called it above - it would be like explicit remurrage, except instead of being automatic, it would require each holder's active participation (i.e. they couldn't just go to sleep, unless they left some sort of "trusted bot" running and using their private keys to sign their stream of bitcoin days destroyed). So, if you like, proof-of-burn is like automated, 100%-stakeholder-participation Cunicula-style proof-of-stake!

Incidentally, it's also fascinating to consider what happens if the community does decide a demurraging of [ordinary, unburnt] coins, the revenue being added as a coin-[re-]minting stream to the flow of fees, ''is'' necessary to continue with forever, for the sake of network strength. The amazing answer, as far as I can honestly work out, is that in long-run equilibrium, the burn rate is just such as '''to make hardly any of this demurrage ''real'' demurrage at all!''' [The implicit remurrage of burning almost exactly cancels the explicit demurrage of network-strengthening coin-[re-]minting! (Or if you like, the implicit demurrage of inflationary fresh-coin-minting.) Either way, we ''seem'' to get the possibility of amazing network strength "for free"!] This opens up the shocking possibility of turning up the demurrage/inflation rate to startlingly high levels - 5% of money stock / year, 10% of money stock / year... levels that would bring the whole cryptocurrency into disrepute in the true proof-of-work case, since coin-holders really would suffer that actual amount of explicit or implicit demurrage - and yet '''not''' hitting coin-holders with more than a frictional residual fraction of that ''in real terms'' at all, because of the way burning simulates remurrage! Extraordinary stuff! I plan to say more about this soon - but this quick teaser description should already be food for thought.

=== Coin-burning as a tool for transition between cryptocurrencies ===

Proof of burn may also be of interest as a tool for managing an orderly transition from one cryptocurrency ("oldcoin", let's call it) to another ("newcoin"). If the developers of newcoin are looking for a way of avoiding proof-of-work's real resource consumption '''even in newcoin's initial distribution phase''', they can't use proof of newcoin-burn: newcoins don't exist yet. But they ''can'' use proof of oldcoin-burn! (Assuming their reason for creating newcoin is '''not''' a doubting of oldcoin's security model, anyway. - Or at least, not a doubting severe enough to affect sufficiently deeply buried oldcoins, these being the candidates for burning.)

The newcoin blockchain would thus start with (at least a hash referring to) a complete catalogue of all the [sufficiently deeply buried] unspent txouts of oldcoin. Miners would then exhibit burning events within oldcoin up to a certain date; after which, the protocol would switch to burning of newcoin itself (and the dependency on oldcoin could even be thrown away entirely, if a checkpoint of that transition moment was promulgated and accepted by the newcoin community).

This has the nice consequence that, if people throughout the broader economy are gradually deserting oldcoin (as newcoin catches on), '''''its value need not collapse!''''' Instead, oldcoin gets burnt in the transition process, neatly reducing its nominal supply in just such a way as to roughly keep pace with its declining real demand. Meanwhile, those same acts of burning are minting fresh newcoins, at just the pace required to keep up with newcoin's ''growing'' real demand. (At least, that's the case if miners anticipate the transition speed correctly, and enter / exit the coins' respective mining trades at a pace that competes away supra-normal profits. We also have to assume that the ''total'' real demand for both[/all...] cryptocurrencies is roughly stable in "economy-tracking" terms; or at least, that miners anticipate the time path of the size of total real demand, and of its currency-by-currency composition, correctly, or near enough correctly.)

'''To sum up:''' proof of burn ''could'', just maybe, qualify as a new tool to greatly assist overall (multi-cryptocurrency) economic robustness and stability!

== See also ==
*[[Proof_of_work|Proof of work]]
*[[Proof_of_Stake|Proof of stake]]

[[category:mining]]

Proof of burn

2012-12-16T23:53:33Z

Ids: added "see also" section, cross-referencing to proof of work and proof of stake

'''Proof of burn''' is a potential alternative to [[Proof_of_work|proof of work]] and [[Proof_of_Stake|proof of stake]] as a "scarce resource" to be exhibited by miners competing for the stream of rewards (minted coins and transaction fees) which a cryptocurrency's design makes available. 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 unlike proof of work, it consumes no real resources from a whole economy perspective. This has interesting implications, discussed below.

There are likely many possible variants of proof of burn. This page currently describes [[User:Ids|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 ==

=== Introduction and motivation ===

The key idea of proof-of-burn (this would also apply to proof-of-stake, by the way) is that when choosing the thing which is to qualify as a "difficulty", i.e. to require miners to exhibit proof that they've "done something that's tough to do", all that matters is that '''an individual miner''' finds the task expensive. (Well... it also matters that everyone else should find it cheap to verify that it has been done.) 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 all 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.e. [the fast early phase of] its initial distribution) - or, more precisely, while ''the first'' cryptocurrency is being set up; more on this distinction later! - no good alternative has been proposed. (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 variety", I mean) is in 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: burning the currency!

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. With Bitcoin, any address which is [the RIPEMD160/SHA256 hash of] a script that evaluates to false will do. 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 RIPEMD160 since you can choose big numbers to taste. So, bitcoins sent to such a txout can never be redeemed on a future txin. (Barring the cracking of RIPEMD160 and the finding of an alternative matching script, that is. If ''that'' happens, the cryptocurrency is in 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. (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: burning merely needs to be defined as sending to some ''fixed'' unspendable address, with no variation - e.g. we could settle on the hash of "push 4, and check if it's equal to 5".

So, miners are creating candidate winning blocks by saying to the listening world, not "Look! I've done this many trillion hashes! [or struck lucky with fewer: you, the listening world, wouldn't know the difference... but this doesn't matter...]", but rather "Look! 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! Thanks!" That extremely recent act of burning could be undone in a block chain reorganisation; and then the same miner would be able to "re-burn" those same coins in an attempt to grab a block afresh, post-reorganisation. 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. A proof-of-work miner must simply shrug and say "Oh well, that's those expenses [electricity, mining rig rental / imputed rental,...] lost and gone... time to try again!" And that's the way things should be, for security - it '''should not''' be as cheap to extend the height of two or more competing chains as it is to focus on one. (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. Details to follow.

Now then! 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 users are sending them fees (and any coin-minting still going on too of course), minus the miners' true real-resource costs (i.e. the hardware and electricity and the like for handling transactions and blocks and burn proofs - these costs will be far lower than the hashing costs incurred under proof-of-work, but of course still non-zero). 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.

=== Technical sketch of proof of burn: "Burnt coins are mining rigs!" ===

''Iain Stewart writes:'' 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:

'''''"Burnt coins are mining rigs!"'''''

What that slogan means will become clear as I go on. Basically, 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! - to simulate the generating of random hashes that a real proof-of-work mining rig would produce. Now, obviously we don't want to "simulate" every actual hash! A "simulation" of proof-of-work at ''that'' level of detail would just ''be'' proof-of-work! Rather, we want to mimic the statistical properties of a mining rig's stream of hashes, to just the level of detail required to give the same sort of pattern of meeting / not meeting a moving difficulty target, and all the rest of it, that we get with the real thing.

So: first of all, what exactly is my "stream of true randomness"? Chop up time into units considerably shorter than the intended inter-block time, but 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!) at time t, they can't predict the value of RAND(any t' 2 months or more to the future of t). [Where "2 months" means the dead time a burnt coin must wait before it becomes a simulated active mining rig. 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.] We do '''not''' need fresh statistical independence of RAND(t) w.r.t. all of RAND(t-1), RAND(t-2), RAND(t-3), etc. (And we don't mind if the stream is known a "short" time into the future - e.g. a week or two; at any rate a small portion of the waiting period.)

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: lotteries. 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.dat or whatever) should get "the latest lottery results" appended to it. 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. Like this:

.
.
.
for use from 2013-06-24 00:00:00 onwards: UK national lottery 2013-06-12: 4 9 20 22 37 42, bonus ball 19
for use from 2013-07-01 00:00:00 onwards: UK national lottery 2013-06-19: 7 12 14 19 33 41, bonus ball 28

(Obviously the meta-level words "for use from... onwards" aren't really needed - I just put them in for clarity.) Each line is added in a leisurely, unhurried fashion, at some time (it doesn't matter when) between the draw and the intended start-paying-attention-to-it date. (Some time between 2013-06-19 and 2013-07-01 00:00:00, in the case of the example last line above.) 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.g. 2013-07-02 23:14:05, or just the Unix numeric time] as a final line). - Or if you like, HASH(HASH(config-file) ++ t), for efficiency. (Where "++" means "append together in some standard fashion".) "HASH()" is your favourite hash function, e.g. SHA256(SHA256()). Thus RAND(t) is a 256-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. [For their application or for mine!] Someone producing the latest block, given the previous 99, can privately produce billions of cheap variations on it, by varying the order the transactions are listed etc, until they find, and publish, the one that "games" the randomness in their favour. 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 of bits of unknowable future entropy. That's all that matters for turning burnt coins into simulated mining rigs.)

Right then! What do we do with this RAND(t) stream? We simulate the capricious behaviour of a true proof-of-work mining rig! Let us assume that, in the real proof-of-work world, you can buy an h hashes/second mining rig for b=c*h BTC. (c varies with technical progress, BTC price fluctuations, etc; but in the simulated world it can just be left constant.) Or, inverting this, if you spend b BTC, you acquire a mining rig of h=b/c hashes/s power. Now, what does it actually mean for your rig to perform h hashes during 1 second? It means you're producing h uniform random numbers between 0 and 1. (That binary point again!) But you don't really care what they all are individually - how well you did during that 1 second is defined as "what was the '''lowest''' hash value you produced during that 1 second?". This is then inspected for whether it beats [is lower than] the network's current target; or, perhaps, whether it beats the lesser [i.e. numerically greater] target of a pooled mining operation. If it's good enough, that precious lowest hash is published to the network (or mining pool), and the others are just thrown away (not published). If it's not good enough, even the [not-so-]precious lowest hash isn't published - and certainly not the others. So, in the simulation, we only need to produce, for each second, a simulated "lowest hash for that 1 second". The "others" don't have to exist at all!

For reproducing (statistically) the pattern of hits and misses w.r.t. targets tough enough to not be achieving several hits within 1 second, and for h>>1, we can take the simulated lowest hash for time t to be (1/h) * HASH(signatures-of-the-act-of-burning-the-b-BTC ++ RAND(t)). [In fact this even works for h<1, despite the rather surreal appearance of "lowest hashes" >1 every so often in that case - i.e. values outside the range that ''real'' lowest (or any other!) hashes can ever actually be: it turns out this surreal behaviour is just what's needed to degrade the probability of beating the target by just the right amount. Values >1 in effect represent "I didn't generate any hashes at all during this particular 1-second window".]

Two further subtleties. First of all, it turns out to be desirable to include the block number (chain height @ 1 per block) in the formula - just to keep the owners of simulated mining rigs "on their toes" and not be able to tell a week or so in advance when they'll be lucky. (This encourages them to run a continuous full node. Maybe that's not in fact that important.) So we take simulated-lowest-hash = (1/h) * HASH(signatures-of-the-act-of-burning-the-b-BTC ++ block-number-of-would-be-block ++ RAND(t)). (We should '''not''' include finer details of the block, to avoid "gaming" a la the hundred blocks business I mentioned earlier. - Or if I'm wrong about that, then OK, by all means mix in finer details of the block!)

Secondly, it turns out that to keep the burning process going forever, rather than a pulse of initial burning that no-one ever again wants to contribute further burning to, we should simulate one more property of real-world mining rigs: they break down! That is, we should demurrage away the strength of a simulated mining rig. (A plea to the reader: Don't be alarmed by the word "demurrage". This is '''burnt''' coins I'm talking about - they ''should'' be treated "harshly", in whatever style mimics real-world mining rigs to the required fidelity. Ordinary unburnt coins are not being demurraged! [Unless that's independently desirable as a policy matter, e.g. if it's felt that network strength can only be achieved via more revenue for miners than fees alone will ever provide.]) A real mining rig likely works at full tilt for a few years and then conks out. We ''could'' demurrage each burnt coin in that style - it abruptly expires E years after its creation - but I think a smooth exponential demurrage is nicer, i.e. its burnt value after y years is b'=b*exp(-y/E). Thus h = b'/c = (b/c)*exp(-y/E). [And 1/h = c/b' = (c/b)*exp(y/E).]

Taking these two further subtleties into account, we get the following formula:

simulated-lowest-hash(t) = (c/b)*exp([t - t_burning]/E) * HASH(signatures-of-the-act-of-burning-the-b-BTC ++ block-number-of-would-be-block ++ RAND(t)).

So there you have it! With this formula, life as a miner is spookily similar to the real proof-of-work case. You "buy a mining rig" - you burn coins, and that hits ''you'' in exactly the way sending off money to a chip supplier would have hit you, even though over the whole economy, no real resources have been expended - and you then hope that, by submitting lucky hashes to the network in the form of blocks, you can make more back in fees over time than you spent initially. If you don't keep connected to the network, you won't know what transactions are eligible for including in your next would-be block, and your next lucky hash will run to waste. Meanwhile, other people are "buying mining rigs" (burning coins) too, either freshly or to make up for the "wearing out" of their existing ones; and the network is adjusting its target hash value [reciprocal difficulty] to regulate the rate all this mining effort is producing blocks at, to some preferred average rate. All spookily normal, in other words!

Now, I'm being a little bit disingenuous to say that ''everything'' is normal. We need protection against certain things (use of a lucky hash on two or more competing chains; timestamp-falsification abuse) which either do not exist at all under true proof-of-work - the former - or exist but with the consequences and mitigation strategy being different in detail - the latter. I believe I have a way of standing up to the various forms of malice we need to worry about of those kinds. More to follow soon hopefully!

=== Economic implications ===

The key insight is that verifiably, publicly burning some coins of a known-total-stock-issued currency is the same as "remurrage" (opposite of "demurrage" - it may not be a correct word, but it's a nice back-formation) on the remainder. That is, if there are verifiably 21 million issued-and-not-burned coins, and then you go to sleep and wake up later and there are now only 20 million issued-and-not-burned coins, that's the same as if some magic genie multiplied all wake-up-time nominal bitcoin figures by 21/20. Another way to see the identity of real effect would be to redefine "burning n bitcoins" to mean, not "sending n to an unspendable address", but rather "scattering" the n bitcoins, i.e. sending them to '''every existing''' [non-zero-balance] address, in proportion to the balance [sum of unspent txouts] already stored in each. This would be a horribly gigantic transaction to actually do explicitly, but the point is, burning can be thought of "as if" done that way. (Slogan: Quantity-deflation is remurrage in disguise, in exactly the same way that quantity-inflation is demurrage in disguise.)

So, what ''that'' means is, if while you're sleeping you (a non-miner) hold 1 bitcoin purely passively, i.e. it just sits undisturbed on the blockchain, well, when you wake up, it's as if you've received a "dividend" (of 5% in the particular numeric example above) on top of the general economy-tracking price we expect of a constant-quantity currency. In a world with actual, visibly performed remurrage, this is made explicit - your balance is now 21/20, with the nominal circulation [issued-and-not-burned, and remurraged for good measure] constant at 21 million. You can go and spend the 1/20 "dividend" on some treat, and still have the same fraction (1 out of 21 million) of the money stock as when you went to sleep.

In a world ''without'' any attempt at explicit remurrage, the real facts of the situation are (of course!) the same, but their nominal expression is not perhaps so instantly obvious. Your nominal holding is unchanged at 1; but this is now 1 part in 20 million of the whole money stock, not the 1 part in 21 million it was before. So, you can go and spend 1/21 of it on some treat, taking your nominal balance down to 20/21, and ''that'' nominal balance is the same (1 out of 21 million) fraction of the money stock as when you went to sleep.

So, basically, if you're holding bitcoins and trying to hold an "economy-tracking amount", no more and no less, you find you can go out into the market and use the fraction of your holdings that counts as "dividend above and beyond economy-tracking" on some treat or other. (Indeed, "you can go out..." should read "you ''must'' go out...", if you're really determined to pursue precisely that tracking strategy.)

Who's selling you the real resources embodied in the "treat"? And what's ''their'' motive? Well, transaction fee payers presumably like to re-stock their bitcoin real balances to roughly the same [economy-tracking] level as before, on average - they're paying for the fee processing as a service. These fees are then burned by miners. (Well, not literally the fees themselves - the fees themselves are ''collected'' by miners, but the way they achieve this is to burn an approximately equal amount, as explained earlier.) So, ordinary Bitcoin users, to achieve their desired re-stocking, have to either produce slightly more, or consume slightly less, or a proper or improper mixture thereof, than they would have needed to in a hypothetical (presumably impracticable) alternative world where they pay no fees for their everyday transactions (and some magic mining-god just altruistically and reliably creates a blockchain out of all the transactions, without charging anybody anything). [This follows directly from their re-stocking desire, and has nothing to do with proof-of-burn specifically. That is, they have to do this regardless of whether the protocol is proof-of-work, proof-of-stake, proof-of-burn or whatever.] It's that extra gap between production and consumption - "extra" on top of whatever gap people are already choosing as a real saving[/dis-saving] strategy - that goes on to the market, for you and all other bitcoin holders to bid off the market by spending on your "treat".

This whole stable pattern of spending habits is, perhaps surprisingly, the same pattern of real resource allocation as would have happened if Cunicula's proof of stake (with close to 100% stake / 0% work admixture) had been in operation, and all bitcoin holders, large and small, had enthusiastically thrown their bitcoins (that is, their stream of bitcoin days destroyed) into the stake-claiming process. The fraction of fees they'd collect if they did that would be just like the "dividend" as I called it above - it would be like explicit remurrage, except instead of being automatic, it would require each holder's active participation (i.e. they couldn't just go to sleep, unless they left some sort of "trusted bot" running and using their private keys to sign their stream of bitcoin days destroyed). So, if you like, proof-of-burn is like automated, 100%-stakeholder-participation Cunicula-style proof-of-stake!

Incidentally, it's also fascinating to consider what happens if the community does decide a demurraging of [ordinary, unburnt] coins, the revenue being added as a coin-[re-]minting stream to the flow of fees, ''is'' necessary to continue with forever, for the sake of network strength. The amazing answer, as far as I can honestly work out, is that in long-run equilibrium, the burn rate is just such as '''to make hardly any of this demurrage ''real'' demurrage at all!''' [The implicit remurrage of burning almost exactly cancels the explicit demurrage of network-strengthening coin-[re-]minting! (Or if you like, the implicit demurrage of inflationary fresh-coin-minting.) Either way, we ''seem'' to get the possibility of amazing network strength "for free"!] This opens up the shocking possibility of turning up the demurrage/inflation rate to startlingly high levels - 5% of money stock / year, 10% of money stock / year... levels that would bring the whole cryptocurrency into disrepute in the true proof-of-work case, since coin-holders really would suffer that actual amount of explicit or implicit demurrage - and yet '''not''' hitting coin-holders with more than a frictional residual fraction of that ''in real terms'' at all, because of the way burning simulates remurrage! Extraordinary stuff! I plan to say more about this soon - but this quick teaser description should already be food for thought.

=== Coin-burning as a tool for transition between cryptocurrencies ===

Proof of burn may also be of interest as a tool for managing an orderly transition from one cryptocurrency ("oldcoin", let's call it) to another ("newcoin"). If the developers of newcoin are looking for a way of avoiding proof-of-work's real resource consumption '''even in newcoin's initial distribution phase''', they can't use proof of newcoin-burn: newcoins don't exist yet. But they ''can'' use proof of oldcoin-burn! (Assuming their reason for creating newcoin is '''not''' a doubting of oldcoin's security model, anyway. - Or at least, not a doubting severe enough to affect sufficiently deeply buried oldcoins, these being the candidates for burning.)

The newcoin blockchain would thus start with (at least a hash referring to) a complete catalogue of all the [sufficiently deeply buried] unspent txouts of oldcoin. Miners would then exhibit burning events within oldcoin up to a certain date; after which, the protocol would switch to burning of newcoin itself (and the dependency on oldcoin could even be thrown away entirely, if a checkpoint of that transition moment was promulgated and accepted by the newcoin community).

This has the nice consequence that, if people throughout the broader economy are gradually deserting oldcoin (as newcoin catches on), '''''its value need not collapse!''''' Instead, oldcoin gets burnt in the transition process, neatly reducing its nominal supply in just such a way as to roughly keep pace with its declining real demand. Meanwhile, those same acts of burning are minting fresh newcoins, at just the pace required to keep up with newcoin's ''growing'' real demand. (At least, that's the case if miners anticipate the transition speed correctly, and enter / exit the coins' respective mining trades at a pace that competes away supra-normal profits. We also have to assume that the ''total'' real demand for both[/all...] cryptocurrencies is roughly stable in "economy-tracking" terms; or at least, that miners anticipate the time path of the size of total real demand, and of its currency-by-currency composition, correctly, or near enough correctly.)

'''To sum up:''' proof of burn ''could'', just maybe, qualify as a new tool to greatly assist overall (multi-cryptocurrency) economic robustness and stability!

== See also ==
*[[Proof_of_work|Proof of work]]
*[[Proof_of_Stake|Proof of stake]]

Proof of Stake

2012-12-16T23:49:51Z

Ids: added "see also" section, cross-referencing to proof of work and (oh yes!) the brand new proof of burn!

Proof of Stake is a proposed alternative to [[Proof of Work]]. Like proof of work, proof of stake provides a mechanism for determining who signs bitcoin transactions (see [https://bitcointalk.org/index.php?topic=68213.0 "main" bitcointalk thread], and a [https://bitcointalk.org/index.php?topic=96854.0 Bounty Thread]).

It was probablly first proposed [https://bitcointalk.org/index.php?topic=27787.0 here] by Quantum Mechanic. With Proof of Work, the probability of mining a block depends on the work done by the miner (e.g. CPU/GPU cycles spent checking hashes). With Proof of Stake, the resource that's compared is the amount of Bitcoin a miner holds - someone holding 1% of the Bitcoin can mine 1% of the "Proof of Stake blocks".

Some argue that methods based on Proof of Work alone might lead to a low network security due to [[Tragedy of the Commons]], and Proof of Stake is one way of changing the miner's incentives in favor of higher network security.

= Motivation For Proof of Stake =

* A proof-of-stake system might provide increased protection from a malicious attack on the network. Additional protection comes from two sources:
1) Executing an attack would be much more expensive.
2) Reduced incentives for attack. The attacker would need to own a near majority of all bitcoin. Therefore, the attacker suffer severely from his own attack.

* When block rewards are produced through txn fees, a proof of stake system would result in lower equilibrium txn fees. Lower long-run fees would increase the competiveness of bitcoin relative to alternative payments systems. Intuitively reduced fees are do to vast reductions in the scale of wastage of resources.
== The Monopoly Problem ==

If a single entity (hereafter a monopolist) took control of the majority of txn verification resources, he could use these resources to impose conditions on the rest of the network. Potentially, the monopolist could choose to do this in malicious ways, such as double spending or denying service. If the monopolist chose a malicious strategy and maintained his control for a long period, confidence in bitcoin would be undermined and bitcoin purchasing power would collapse. Alternatively, the monopolist could choose to act benevolently. A benevolent monopolist would exclude all other txn verifiers from fee collection and currency generation, but would not try to exploit currency holders in any way. In order to maintain a good reputation, he would refrain from double spends and maintain service provision. In this case, confidence in Bitcoin could be maintained under monopoly since all of its basic functionality would not be affected.

Both benevolent and malevolent monopoly are potentially profitable, so there are reasons to suspect that an entrepreneurial miner might attempt to become a monopolist at some point. Due to the [[Tragedy of the Commons]] effect, attempts at monopoly become increasingly likely over time.

== How Proof of Stake Addresses Monopoly Problems ==

Monopoly is still possible under proof-of-stake. However, proof-of-stake would be more secure against malicious attacks for two reasons.

Firstly, proof-of-stake makes establishing a verification monopoly more difficult. At the time of writing, an entrepreneur could achieve monopoly over proof-of-work by investing at most 10 million USD in computing hardware. The actual investment necessary might be less than this because other miners will exit as difficulty increases, but it is difficult to predict exactly how much exit will occur. If price remained constant in the face of extremely large purchases (unlikely), such an entrepreneur would need to invest at least 20 million USD to obtain monopoly under proof-of-stake. Since such a large purchase would dramatically increase bitcoin price, the entrepreneur would likely need to invest several times this amount. Thus, even now proof-of-stake monopoly would be several-fold more costly to achieve than proof-of-work monopoly. Over time the comparison of monopoly costs will become more and more dramatic. The ratio of bitcoin's mining rewards to market value is programmed to decline exponentially. As this happens, proof-of-work monopoly will become easier and easier to obtain, whereas obtaining proof-of-stake monopoly will become progressively more difficult as more of the total money supply is released into circulation.

Secondly, and perhaps more importantly, a proof-of-stake monopolist is more likely to behave benevolently exactly because of his stake in Bitcoin. In a benevolent monopoly, the currency txn continue as usual, but the monopolist earns all txn fees and coin generations. Other txn verifiers are shut out of the system, however. Since mining is not source of demand for bitcoin, bitcoin might retain most of its value in the event of a benevolent attack. Earnings from a benevolent attack are similar regardless of whether the attack occurs under proof-of-stake or proof-of-work. In a malicious attack, the attacker has some outside opportunity which allows profit from bitcoin's destruction (simple double-spends are not a plausible motivation; ownership of a competing payment platform is). At the same time, the attacker faces costs related to losses on bitcoin-specific investments which are necessary for the attack. It can be assumed that a malicious attack causes the purchasing power of bitcoin to fall to zero. Under such an attack, the proof-of-stake monopolist will lose his entire investment. By contrast, a malicious proof-of-work monopolist will be able to recover much of their hardware investment through resale. Recall also, that the necessary proof-of-work investment is much smaller than the proof-of-stake investment. Thus, the costs of a malicious attack are several-fold lower under proof-of-work. The low costs associated with malicious attack make a malicious attack more likely to occur.

== Why Proof of Stake Would Likely Decrease Long-run Txn Fees Considerably ==
In a competitive market equilibrium, the total volume of txn fees must be equal to opportunity cost of all resources used to verify txns. Under proof-of-work mining, opportunity cost can be calculated as the total sum spent on mining electricity, mining equipment depreciation, mining labor, and a market rate of return on mining capital. Electricity costs, returns on mining equipment, and equipment depreciation costs are likely to dominate here. If these costs are not substantial, then it will be exceptionally easy to monopolize the mining network. The fees necessary to prevent monopolization will be onerous, possibly in excess of the 3% fee currently charged for credit card purchases. Under pure proof-of-stake, opportunity cost can be calculated as the total sum spent on mining labor and the market interest rate for risk-free bitcoin lending (hardware-related costs will be negligible). Since bitcoins are designed to appreciate over time due to hard-coded supply limitations, interest rates on risk-free bitcoin-denominated loans are likely to be negligible. Therefore, the total volume of txn fees under pure proof-of-stake will just need to be just sufficient to compensate labor involved in maintaining bandwidth and storage space. The associated txn fees will be exceptionally low. Despite these exceptionally low fees, a proof-of-stake network will be many times more costly to exploit than the proof-of-work network. Approximately, a proof-of-work network can be exploited using expenditure equal to about one years worth of currency generation and txn fees. By contrast, exploitation of a proof-of-stake network requires purchase of a majority or near majority of all extant coins.

= Implementation =
There are currently a few distinct proposals on how to implement PoS

== Cunicula's Implementation of Mixed Proof-of-Work and Proof-of-Stake ==

This suggestion is of a mixed Proof-of-Work / Proof-of-Stake system.

=== Cunicula's Note ===
Check the page history for the older implementation. I am replacing my description with a new system which I believe to be much more secure. The new system is a greatly improved version of Colbee's proof of activity. It provides extremely strong protection against PoW attacks, both double-spends and denials of service. It is not vulnerable even if PoW attackers also have substantial (but non majority) stake. It provides strong incentives to maintain full nodes. The system is supported through taxes on coin owners who fail to maintain full nodes. Tax revenue is redistributed to coin owners who maintain full nodes. The maintenance of full nodes is the key element providing security in the system.

The discussion focuses on long-term maintenance of the system. Initial distribution of coins could occur through PoW mining, an IPO mechanism, or a more complex scheme that allows initial coins to be distributed to both PoW miners and businesses voted for by coin owners. The issue of initial distribution is separate from long-term maintenance and it is confusing to discuss the two together.

=== Glossary ===
Voluntary Signatures - Voluntary signatures result from a random auditing processes. As blocks are mined, keys are selected for auditing based on random selection. The signatures provide public evidence that a public key owner is running a full node. Passing the audit allows a private key to remain active.

Active Keys - By default, public keys that appear in the blockchain are active if they have a balance of at least one full coin. Public keys that provide voluntary signatures when randomly audited remain active. Active public keys are eligible to participate in lotteries to sign PoW blocks and mine PoS blocks. This is remunerative. Public keys that fail to provide signatures become dead private keys.

Dead Keys - Keys that have failed to provide signatures lose lottery eligibility. Keys that have balances of less than 1 coin are considered dead by default. Dead keys can no longer mine PoS blocks. However, these dead keys can still be used to generate txns. Network maintenance is supported primarily through mandatory fees levied on coins sent by dead keys. After coins are sent using a dead key, the key becomes active provided that it retains a balance of at least 1 coin.

Mandatory Signature Sequence - In order for a PoW block to be valid and enter the blockchain, it must be signed by a sequence of 5 randomly selected active keys. The fifth signatory in the sequence mines a PoS block.

PoS block - The fifth signatory of a PoW block must mint his own block without any PoW submission at all. This block is called a PoS block.

Coin-age - Coin age refers to the age of txn inputs. Coin age is equal to the number of coins sent times the average age on these coins. Age is measured in blocks. Age is reset to 1 block whenever a coin is sent AND whenever a coin provides a signature (both mandatory and voluntary signatures count). Coin-age is used to calculate mandatory fees.

Demurrage Fee - Chain Security is supported primarily through a demurrage tax on sent inputs. This tax proportional to average input age as measured in coin-years. I suggest 5% per coin-year as a reasonable fee. Active keys can avoid demurrage fees simply by remaining active. Thus the actual fee generation will be much lower than 5% per year. Dead keys must pay demurrage. The opportunity to evade demurrage motivates activity.

Optional Fee - Fees are used to ration block space. Blocks select prioritize txns with high fees. If demurrage fees alone are insufficient to motivate txn inclusion, the user can add an optional fee to his txn.

Fee Fund - Both optional fees and demurrage fees enter a fund, rather than being distributed directly to miners. Fees are added to the fund immediately, so there is a weak incentive to include high fee txns in blocks. The PoW miner receives a distribution equal to 0.01% of the accumulated fund. The first four mandatory signatories also receive 0.1% each. The PoS block miner receives 0.1% as well, but his takings will differ slightly because the fund is updated based on txns included in his block. Use of a fund reduces volatility in mining reward.

Root Private Key - The root private key has full spending and signing authority. When significant balances are held, this key should be kept as an offline backup to guard against theft.

Stake Signing Key - Private Key can delegate signing and sending authority to one other private key. The delegated key can sign blocks and has limited authority to send coins. Authority to send coins is determined by two positive constants, t and k. The following txn rule limits the stake signing keys' spending authority:

Change Returned to Public Key >= all coins sent to other addresses * {max(k,k*(t/coin-years on public key)}
k=9 and t=1/12 are suggested as possible parameters. These parameters allows the stake signing key to spend up to 10% of the total key balance per month. The max value at risk in event of theft of
this key is 10%. Holders of large balances 'zero-out' their coin-age frequently via mining and face less theft risk. If this occurs once per week, for example, the large balance holder will only
risk be able to spend up to 2.3% of their balance per week and will only lose 2.3% in the event of theft. Once theft is detected, all remaining coins can be moved to a secure computer using the
root private key.

=== Mining Process ===

1) Block meeting work difficulty target is mined. Difficulty target periodically adjusted so that 1 PoW block arrives every 10 minutes.

2) Work submission is hashed 10 times consecutively. Each consecutive hash maps to an individual unspent output in the blockchain. This is essentially a lottery drawing two sets of five winners. The first five hashes map to mandatory signatures, the final five hashses map to voluntary signatures.

3) If the mandatory signatures map to active public keys [see glossary], the block can potentially be valid. Otherwise, the block is invalid and must be discarded.

4) If PoW miner finds a potentially valid block, he transmits the following hash to the network: {work submission;hash(his block, the previous valid block)}

5) If the work submission meets the difficulty target and maps to active signatories, then the block is relayed through the network. Otherwise, the message is dropped as spam.

5) The first five selected signatories sequentially sign this hash and transmit it onwards as {work submission; hash; sig 1; sig 2; sig 3; sig 4; sig 5}

6) After the mandatory signature sequence is complete, the final signatory publishes the PoW block and also his own PoS block.

7) The final five hashes map to voluntary signatures. These voluntary signatures can be inserted into any block within the next 6 blocks as special txns. These txns do not require fees.

9) Go to step 1

Note: This process is simultaneous so that multiple block hashes can circulate in the network attempting to collect five signatures and generate PoW/PoS block pairs. Block pairs that lose this race
are orphaned.

=== Infeasability of standard attack vectors ===

Unless attackers own a large share of stake, all types of PoW attacks are computationally infeasible. I think there are two types of known attacks: 1) Double-Spend 2) Denial of Service
I consider approximations below. The numbers are so favorable that consideration of exact statistics is not particularly interesting.

1) Double Spend.

Double spends rely on secrecy. In order to mine blocks in secret a PoW miner must select his 5 of his own public keys in the lottery. If the PoW miner owns a share 0<s<1 of all coins,
the probability of doing that a block meeting the difficulty target will select the miner's coins is (1/s)^5. For s=0.01, 1 out of 10 billion blocks will satisfy this criteria.
Even for extremely small hash aggregate rates, it is not practical to privately mine at a rate 10 billion times faster than all other miners combined. For s=0.1, 1 out of 100,000 blocks will
satisfy this criteria. (i.e. the attack still requires approximately 99.999% of all hashing power). For s=0.5, the attacker will succeed if he controls 51% of the aggregate hash rate.

2) Denial of Service

An attacker who mines publicly could simply produce empty PoW blocks. However, this would fail to deny service. 50% of all blocks are randomly mined via PoS. The attacker cannot
force the PoS miners to produce empty blocks. Therefore he cannot deny service regardless of how much hash rate he controls.

=== Long-term Chain Evaluation ===
1) Comparison of two long chains is based on a simple sum of block difficulty, just as in bitcoin.

2) A criticism of PoS is that there is no reason not to sign attack chains. However, in a long secret chain, many stakeholders will have dead signatures. These dead stakeholders will not be able to sign the main chain, but not the attack chain. They will have a strong incentive to make sure the main chain wins because the attack chain will impose demurrage fees on them.

=== Incentives to maintain full nodes ===

This system introduces powerful incentives to maintain full nodes. Many people argue that the lack of an incentive to maintain a full node is a problem in the bitcoin system.

1) a steady flow of txns will generate some fees even if all public keys remain active. Active keys must be maintaining full nodes. Otherwise they could not provide the voluntary signatures which prove their activity. Even very weak incentives are sufficient in this case. If almost all keys are associated with active nodes, then it is not necessary to motivate additional participation.

2) Some public keys may decide to become inactive. This is costly for them. They will suffer a loss of 5% of their balance per year for as long as they remain inactive.

3) The active public keys constantly capture revenue from inactive public keys. This means that the incentives to remain increase dramatically as participation falls. Suppose that 50% of public keys maintain full nodes, then this 50% will capture 2.5% of coins per annum. This is equal to an annual of return of 2.0%. The alternative, inactivity, yields an annual return of -5.0% as discussed in point 2. I consider this a reasonable incentive level and participation rate. Suppose that I am wrong, and only 10% of public keys maintain full nodes. Then these 10% will capture 4.5% of all extant coins per annum. This implies an annual return on participation equal to 45% per annum. This is a very strong incentive and is almost certain to be sufficient, even if nodes are quite costly to maintain. If only 1% of coins participate, then 4.95% of all extant coins will be distributed to this 1% each year. This implies a weekly return on participation of 3%, a pirate ponzi scheme level return. If these incentive are inadequate to support a healthy network of full nodes (which seems unlikely to me), then the levy on dead coins could be increased to exceed 5% per annum.

4) Many people will not have enough coins to justify running their own node. Such individuals will likely use an online banking service which could store their limited spend key. The service could return interest to users in exchange for managing their keys.

5) Other individuals may prefer the privacy associated with dropping out of participation. These individuals are still welcome to use the network, but must face a wealth tax of 5% per annum to compensate for the security risk created by their behavior.

=== Storage of Blockchain Metadata ===
To facilitate the system, data should be extracted from the block chain in a readily accessible database that is updated with each block. The database only needs to incorporate
public keys which control at least 1 coin. Keys with balances less than 1 coin are considered dead by default. These low-value public keys
are not allowed to create limited stake public keys. If a public key balance drops below 1 coin, the limited stake public key associated with the root key is invalidated.

The database would look like this:

{| class="wikitable"
|-
! Public Key (ordered list) !! Linked Stake Public key (if any) !! Balance !! Cumulative Balance !! Active? !! Coin-age (in years)
|-
| A || As || 1 || 1 || 1 || 0.03
|-
| B || Bs || 2.5 || 3.5 || 0 || 0.1
|-
| C || Cs || 3 || 6.5 || 1 || 0.2
|-
| ... || ... || ... || ... || ... || ...
|}
The block chain must maintain records of links between public keys and delegated limited stake public keys. These should be put in a simple database for easy access.

Cumulative balance can be used to determine the winners of the lottery. (i.e. the lottery is a uniform draw on the support [0,total issued coins]) This indicates a unique lottery winner,
whose chance of winning is proportional to his ownership share.

Coin-age is updated as follows.
If no send, Coin-age_t = Coin-age_t-1 + 1.
If send, Coin_age_t = 1.
If send and receipt of coins, Coin_age_t = 1.
If receipt of coins but no send, Coin_age_t = [Coin_age_(t-1)*balance_(t-1)+received coins]/balance(t)

Coin-age is necessary to determine mandatory demurrage fees and to calculate spending limits for limited stake public keys.

Active is 1 by default and becomes 0 if a key fails to provide a requested voluntary signature. 0 is an absorbing state.

=== Beneficiaries and Lossers from Txn Fees ===
The total amount of demurrage fees collected annually varies between 0% and 5% of the total money supply.

The most burdensome fee in the system is the fee paid to PoW miners. This fee imposes a demurrage tax of between 0% and 0.1% per annum on all users of the system. In addition to the demurrage tax, PoW miners receive a 2% share of any optional fees paid to access scarce block space. All coin owners are net losers as a result of PoW mining fees. To minimize costs to coin owners, PoW fee payments are kept as low as possible. Since large hash rates play only a tiny role in security, larger fees for PoW miners are unnecessary.

Other demurrage fees are transfers of revenue from one private key to another. Some keys are net beneficiaries of these transfers, while other keys are net losers. Collectively, these fees do not make coin owners better or worse off. Their effects are neutral. However, individually, the fees do create winners and losers. ''Active'' users that spend infrequently gain from the system. An ''active'' user with average spend frequency is likely to gain from the system as well, but only by a small amount. An ''active'' user that spends very frequently will probably lose from the system. ''Dead'' users will certainly lose from the system. This loss serves as a punishment for failure to maintain an ''active'' node.

== Meni's implementation ==
This proposal is for a proof-of-work (PoW) skeleton on which occasional checkpoints set by stakeholders are placed. In one variant, double-spending is prevented by waiting for a transaction to be included in a checkpoint; the variant described here uses cementing to prevent double-spending, and checkpoints to resolve cementing conflicts.

=== Proof of work ===
Miners use their hashrate to find blocks and build the blockchain exactly as with the pure PoW system. They receive any new generated coins from the block; there will be two kinds of transaction fees, one of which is a mining fee given to the miner who finds the block, just like the PoW transaction fees.

=== Signatures ===
One block every 100 blocks (a different number can be used instead) is a signature block. When a signature block is found and confirmed with several subsequent blocks, stakeholders (people who have bitcoins) are expected to sign it by using a private key associated with their address which contains coins to sign the block hash. If there are several blocks of the same height, an address should not sign more than one of them. The signatures are broadcast on the network and included in a future block. For every candidate block, the total weight of all signatures is tallied (the weight of an address is determined mostly by the number of coins in it, as of the last signature block). Stakeholders will be able to collect signature fees when providing a signature, proportionally to their weight.

At the basic level, there are no rules to choosing which of several conflicting blocks to sign, stakeholders should just choose one.

=== Cementing ===
Cementing is a node's reluctance to do a blockchain reorganization. A node will reject any new block found if it contradicts a 6-block deep branch it is already aware of and currently considers valid. That is, once a node receives 6 confirmations for a block, it will not accept a competing block even if it is part of a longer branch.

In a pure PoW system this is problematic to do because a node could be stuck on "the wrong version" - if an attacker isolates the node and feeds him bogus data, it will not embrace the true, longer chain when he learns of it. However, using PoS to have the final say in such situations makes this possible.

=== Branch selection ===
When a node needs to select which of several branches is valid, it chooses one based on the following criteria in increasing importance (each one is overridden by the next):

#Branch length (total difficulty of all blocks), as in a PoW system.
#Cementing - an already cemented block will not be replaced by a longer branch.
#Signatures - even a cemented block will be overridden by a signature block with signature weight more than half the total possible weight by some margin.

If the conflict is so long that it contains more than one spot for a signature block, the conflicting signature blocks will be traversed earliest to latest, each time choosing the branch with the majority vote. After the newest uncontested signature block it proceeds to use cementing and branch length.

A signature block with no clear majority will be considered tied, and will not override the other criteria. Signature fees will not be given out but instead carried over to the next signature spot, to encourage stakeholders to participate then.

=== [[Double-spending]] prevention ===
A good level of security can be achieved by waiting for a block to be cemented. By that time it is safe to assume that the network recognizes this block and will not easily switch to a different block, even if a longer branch is presented.

A more authoritative confirmation is enabled by waiting for a signature block. Once a block achieves a majority (and some more time is allowed for this majority to spread in the network), it is extremely unlikely that the network will ever switch away from this block.

=== Weights ===
The weight of every address starts at 0. When an address provides a signature, its weight increases so that after several signatures, the weight approaches the number of coins in the address as of the last signature block. For example,
New weight = 0.9 * Old weight + 0.1 * Balance
If a signature is not provided by the address in a signature block, its weight decreases:
New weight = 0.9 * Old weight
This way, addresses whose owners do not wish to participate in signing do not hamper the ability to reach a majority.

If an address signs two conflicting blocks, its weight is reset to 0. This is to limit the power of malicious stakeholders.

If coins move to a new address, weight is proportionally taken away from the addressed, but is not transferred to the new address. The new stakeholder will have to build up his weight.

=== Malicious stakeholders ===
The system is resilient against stakeholders who misuse their signature power, even if they have a majority of the bitcoins. Since their only obligation is to not sign conflicting blocks, the only way they could double-spend is if they first sign one block so it achieves a majority, then sign a different one so that it achieves a bigger majority. Generally this will not work. A short while after a majority is achieved, most of the network will be aware of the relevant signatures. If a different signature is broadcast, the conflict will be detected and both signatures will be ignored. This will cause the current majority block to become tied, but the network is already cemented on it and will vote for this branch in the next signature block. The weight of the attacker will by then reduce to 0 so he will be unable to create more disruption.

Another attack is refusing to sign blocks to keep them tied. Since this causes a decay of the weight, they can only stand in the way of a majority for a short time.

=== Denial of service ===
The method as described does not solve a denial of service scenario. A majority miner could create only blocks with no transactions (or with many transactions missing) and reject all other blocks.

This may be solvable by adding some measure of the transaction in a block to the selection criteria, such as Bitcoin days destroyed.

Also, proposals to replace the block chain with a directed acyclic graph have been made, and could be used to make it easier to include transactions.

== Key difference between the two proposals ==
In Cunicula's system, voting power is determined by combining (multiplicatively) your hashrate and stake. This would be problematic if small players could not compete effectively with large players. Though we are waiting on a formal mathematical proof, evidence to date suggests that small and large players would have an equal competitive footing. Simulations described in this thread [https://bitcointalk.org/index.php?topic=68213.msg801253#msg801253] indicate that small players are competitive with large players because the multiplicative combination of hashrate and stake exhibits constant returns. Evidence in the thread suggests that these simulation results are accepted by both Cunicula and Meni.)

In Meni's, there's a skeleton based purely on hashrate, and superimposed on it are occasional checkpoints set by stakeholders. You can contribute PoW without having stake, and you can contribute PoS without having work, and in both cases your voting power and reward is linearly proportional to the resources you have.

== PPCoin ==
[http://ppcoin.org PPCoin] is the first known implementation of a combined PoS/PoW system (released August 19 2012).

== See also ==
*[[Proof_of_work|Proof of work]]
*[[Proof_of_burn|Proof of burn]]

[[category:mining]]

User:Ids

2012-12-16T23:10:56Z

Ids: advertised Meni Rosenfeld's proposal, now that I see how similar our ideas are!

User:Ids

2012-12-16T23:02:59Z

Ids: advertised proof of burn page

'''(real name: Iain Stewart)'''

I worked as a computing lab assistant at Imperial College, London, U.K. from 1991-2011.

I am especially interested in helping to improve Bitcoin's usability from a non-tech-savvy user's perspective. By this I don't just mean GUI improvements and the like - plenty of people far more talented than me are working on that - but changes to the network protocol itself that will help with responsiveness from a merchant's or customer's point of view, while not compromising cryptographic security, decentralization, or the strength of the blockchain.

I have a provisional proposal, which I call [[Adaptive_difficulty|adaptive difficulty]], which I believe will help with this. I'm hoping to eventually put it up as a BIP. For now I'll work on it at that non-BIP page. Comments and feedback welcome. (Remember that for now, the Bayesian analysis of what proof-of-work is deserved by what difficulty-sequence is ''unfinished'', and the formulae are of indicative status only.) ''(in fact the whole page is just a stub for now - I must first master mathematical wiki-speak!)''

You might also be interested in a proof-of-stake-based system which I at least provisionally believe can be made extraordinarily robust! I call it "[[Proof_of_blockchain_fair_sharing|proof of blockchain fair sharing]]". (That page is currently just a teaser description, sketching the idea and why it doesn't contradict an "obvious" theorem on >50% attacks; followed by a forum post where I speculate on possible broader approaches to the >50% attack problem.)

Last but, I hope, not least: I offer [[Proof_of_burn|proof of burn]] as an alternative to both proof of work and proof of stake (though perhaps closer in spirit to the latter), with many interesting properties and economic consequences, the exploration of which has barely begun.

I can be contacted at iain dot david dot stewart at gmail dot com.

Proof of burn

2012-12-16T22:56:08Z

Ids: /* Coin-burning as a tool for transition between cryptocurrencies */

'''Proof of burn''' is a potential alternative to [[Proof_of_work|proof of work]] and [[Proof_of_Stake|proof of stake]] as a "scarce resource" to be exhibited by miners competing for the stream of rewards (minted coins and transaction fees) which a cryptocurrency's design makes available. 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 unlike proof of work, it consumes no real resources from a whole economy perspective. This has interesting implications, discussed below.

There are likely many possible variants of proof of burn. This page currently describes [[User:Ids|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 ==

=== Introduction and motivation ===

The key idea of proof-of-burn (this would also apply to proof-of-stake, by the way) is that when choosing the thing which is to qualify as a "difficulty", i.e. to require miners to exhibit proof that they've "done something that's tough to do", all that matters is that '''an individual miner''' finds the task expensive. (Well... it also matters that everyone else should find it cheap to verify that it has been done.) 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 all 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.e. [the fast early phase of] its initial distribution) - or, more precisely, while ''the first'' cryptocurrency is being set up; more on this distinction later! - no good alternative has been proposed. (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 variety", I mean) is in 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: burning the currency!

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. With Bitcoin, any address which is [the RIPEMD160/SHA256 hash of] a script that evaluates to false will do. 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 RIPEMD160 since you can choose big numbers to taste. So, bitcoins sent to such a txout can never be redeemed on a future txin. (Barring the cracking of RIPEMD160 and the finding of an alternative matching script, that is. If ''that'' happens, the cryptocurrency is in 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. (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: burning merely needs to be defined as sending to some ''fixed'' unspendable address, with no variation - e.g. we could settle on the hash of "push 4, and check if it's equal to 5".

So, miners are creating candidate winning blocks by saying to the listening world, not "Look! I've done this many trillion hashes! [or struck lucky with fewer: you, the listening world, wouldn't know the difference... but this doesn't matter...]", but rather "Look! 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! Thanks!" That extremely recent act of burning could be undone in a block chain reorganisation; and then the same miner would be able to "re-burn" those same coins in an attempt to grab a block afresh, post-reorganisation. 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. A proof-of-work miner must simply shrug and say "Oh well, that's those expenses [electricity, mining rig rental / imputed rental,...] lost and gone... time to try again!" And that's the way things should be, for security - it '''should not''' be as cheap to extend the height of two or more competing chains as it is to focus on one. (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. Details to follow.

Now then! 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 users are sending them fees (and any coin-minting still going on too of course), minus the miners' true real-resource costs (i.e. the hardware and electricity and the like for handling transactions and blocks and burn proofs - these costs will be far lower than the hashing costs incurred under proof-of-work, but of course still non-zero). 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.

=== Technical sketch of proof of burn: "Burnt coins are mining rigs!" ===

''Iain Stewart writes:'' 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:

'''''"Burnt coins are mining rigs!"'''''

What that slogan means will become clear as I go on. Basically, 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! - to simulate the generating of random hashes that a real proof-of-work mining rig would produce. Now, obviously we don't want to "simulate" every actual hash! A "simulation" of proof-of-work at ''that'' level of detail would just ''be'' proof-of-work! Rather, we want to mimic the statistical properties of a mining rig's stream of hashes, to just the level of detail required to give the same sort of pattern of meeting / not meeting a moving difficulty target, and all the rest of it, that we get with the real thing.

So: first of all, what exactly is my "stream of true randomness"? Chop up time into units considerably shorter than the intended inter-block time, but 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!) at time t, they can't predict the value of RAND(any t' 2 months or more to the future of t). [Where "2 months" means the dead time a burnt coin must wait before it becomes a simulated active mining rig. 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.] We do '''not''' need fresh statistical independence of RAND(t) w.r.t. all of RAND(t-1), RAND(t-2), RAND(t-3), etc. (And we don't mind if the stream is known a "short" time into the future - e.g. a week or two; at any rate a small portion of the waiting period.)

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: lotteries. 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.dat or whatever) should get "the latest lottery results" appended to it. 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. Like this:

.
.
.
for use from 2013-06-24 00:00:00 onwards: UK national lottery 2013-06-12: 4 9 20 22 37 42, bonus ball 19
for use from 2013-07-01 00:00:00 onwards: UK national lottery 2013-06-19: 7 12 14 19 33 41, bonus ball 28

(Obviously the meta-level words "for use from... onwards" aren't really needed - I just put them in for clarity.) Each line is added in a leisurely, unhurried fashion, at some time (it doesn't matter when) between the draw and the intended start-paying-attention-to-it date. (Some time between 2013-06-19 and 2013-07-01 00:00:00, in the case of the example last line above.) 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.g. 2013-07-02 23:14:05, or just the Unix numeric time] as a final line). - Or if you like, HASH(HASH(config-file) ++ t), for efficiency. (Where "++" means "append together in some standard fashion".) "HASH()" is your favourite hash function, e.g. SHA256(SHA256()). Thus RAND(t) is a 256-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. [For their application or for mine!] Someone producing the latest block, given the previous 99, can privately produce billions of cheap variations on it, by varying the order the transactions are listed etc, until they find, and publish, the one that "games" the randomness in their favour. 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 of bits of unknowable future entropy. That's all that matters for turning burnt coins into simulated mining rigs.)

Right then! What do we do with this RAND(t) stream? We simulate the capricious behaviour of a true proof-of-work mining rig! Let us assume that, in the real proof-of-work world, you can buy an h hashes/second mining rig for b=c*h BTC. (c varies with technical progress, BTC price fluctuations, etc; but in the simulated world it can just be left constant.) Or, inverting this, if you spend b BTC, you acquire a mining rig of h=b/c hashes/s power. Now, what does it actually mean for your rig to perform h hashes during 1 second? It means you're producing h uniform random numbers between 0 and 1. (That binary point again!) But you don't really care what they all are individually - how well you did during that 1 second is defined as "what was the '''lowest''' hash value you produced during that 1 second?". This is then inspected for whether it beats [is lower than] the network's current target; or, perhaps, whether it beats the lesser [i.e. numerically greater] target of a pooled mining operation. If it's good enough, that precious lowest hash is published to the network (or mining pool), and the others are just thrown away (not published). If it's not good enough, even the [not-so-]precious lowest hash isn't published - and certainly not the others. So, in the simulation, we only need to produce, for each second, a simulated "lowest hash for that 1 second". The "others" don't have to exist at all!

For reproducing (statistically) the pattern of hits and misses w.r.t. targets tough enough to not be achieving several hits within 1 second, and for h>>1, we can take the simulated lowest hash for time t to be (1/h) * HASH(signatures-of-the-act-of-burning-the-b-BTC ++ RAND(t)). [In fact this even works for h<1, despite the rather surreal appearance of "lowest hashes" >1 every so often in that case - i.e. values outside the range that ''real'' lowest (or any other!) hashes can ever actually be: it turns out this surreal behaviour is just what's needed to degrade the probability of beating the target by just the right amount. Values >1 in effect represent "I didn't generate any hashes at all during this particular 1-second window".]

Two further subtleties. First of all, it turns out to be desirable to include the block number (chain height @ 1 per block) in the formula - just to keep the owners of simulated mining rigs "on their toes" and not be able to tell a week or so in advance when they'll be lucky. (This encourages them to run a continuous full node. Maybe that's not in fact that important.) So we take simulated-lowest-hash = (1/h) * HASH(signatures-of-the-act-of-burning-the-b-BTC ++ block-number-of-would-be-block ++ RAND(t)). (We should '''not''' include finer details of the block, to avoid "gaming" a la the hundred blocks business I mentioned earlier. - Or if I'm wrong about that, then OK, by all means mix in finer details of the block!)

Secondly, it turns out that to keep the burning process going forever, rather than a pulse of initial burning that no-one ever again wants to contribute further burning to, we should simulate one more property of real-world mining rigs: they break down! That is, we should demurrage away the strength of a simulated mining rig. (A plea to the reader: Don't be alarmed by the word "demurrage". This is '''burnt''' coins I'm talking about - they ''should'' be treated "harshly", in whatever style mimics real-world mining rigs to the required fidelity. Ordinary unburnt coins are not being demurraged! [Unless that's independently desirable as a policy matter, e.g. if it's felt that network strength can only be achieved via more revenue for miners than fees alone will ever provide.]) A real mining rig likely works at full tilt for a few years and then conks out. We ''could'' demurrage each burnt coin in that style - it abruptly expires E years after its creation - but I think a smooth exponential demurrage is nicer, i.e. its burnt value after y years is b'=b*exp(-y/E). Thus h = b'/c = (b/c)*exp(-y/E). [And 1/h = c/b' = (c/b)*exp(y/E).]

Taking these two further subtleties into account, we get the following formula:

simulated-lowest-hash(t) = (c/b)*exp([t - t_burning]/E) * HASH(signatures-of-the-act-of-burning-the-b-BTC ++ block-number-of-would-be-block ++ RAND(t)).

So there you have it! With this formula, life as a miner is spookily similar to the real proof-of-work case. You "buy a mining rig" - you burn coins, and that hits ''you'' in exactly the way sending off money to a chip supplier would have hit you, even though over the whole economy, no real resources have been expended - and you then hope that, by submitting lucky hashes to the network in the form of blocks, you can make more back in fees over time than you spent initially. If you don't keep connected to the network, you won't know what transactions are eligible for including in your next would-be block, and your next lucky hash will run to waste. Meanwhile, other people are "buying mining rigs" (burning coins) too, either freshly or to make up for the "wearing out" of their existing ones; and the network is adjusting its target hash value [reciprocal difficulty] to regulate the rate all this mining effort is producing blocks at, to some preferred average rate. All spookily normal, in other words!

Now, I'm being a little bit disingenuous to say that ''everything'' is normal. We need protection against certain things (use of a lucky hash on two or more competing chains; timestamp-falsification abuse) which either do not exist at all under true proof-of-work - the former - or exist but with the consequences and mitigation strategy being different in detail - the latter. I believe I have a way of standing up to the various forms of malice we need to worry about of those kinds. More to follow soon hopefully!

=== Economic implications ===

The key insight is that verifiably, publicly burning some coins of a known-total-stock-issued currency is the same as "remurrage" (opposite of "demurrage" - it may not be a correct word, but it's a nice back-formation) on the remainder. That is, if there are verifiably 21 million issued-and-not-burned coins, and then you go to sleep and wake up later and there are now only 20 million issued-and-not-burned coins, that's the same as if some magic genie multiplied all wake-up-time nominal bitcoin figures by 21/20. Another way to see the identity of real effect would be to redefine "burning n bitcoins" to mean, not "sending n to an unspendable address", but rather "scattering" the n bitcoins, i.e. sending them to '''every existing''' [non-zero-balance] address, in proportion to the balance [sum of unspent txouts] already stored in each. This would be a horribly gigantic transaction to actually do explicitly, but the point is, burning can be thought of "as if" done that way. (Slogan: Quantity-deflation is remurrage in disguise, in exactly the same way that quantity-inflation is demurrage in disguise.)

So, what ''that'' means is, if while you're sleeping you (a non-miner) hold 1 bitcoin purely passively, i.e. it just sits undisturbed on the blockchain, well, when you wake up, it's as if you've received a "dividend" (of 5% in the particular numeric example above) on top of the general economy-tracking price we expect of a constant-quantity currency. In a world with actual, visibly performed remurrage, this is made explicit - your balance is now 21/20, with the nominal circulation [issued-and-not-burned, and remurraged for good measure] constant at 21 million. You can go and spend the 1/20 "dividend" on some treat, and still have the same fraction (1 out of 21 million) of the money stock as when you went to sleep.

In a world ''without'' any attempt at explicit remurrage, the real facts of the situation are (of course!) the same, but their nominal expression is not perhaps so instantly obvious. Your nominal holding is unchanged at 1; but this is now 1 part in 20 million of the whole money stock, not the 1 part in 21 million it was before. So, you can go and spend 1/21 of it on some treat, taking your nominal balance down to 20/21, and ''that'' nominal balance is the same (1 out of 21 million) fraction of the money stock as when you went to sleep.

So, basically, if you're holding bitcoins and trying to hold an "economy-tracking amount", no more and no less, you find you can go out into the market and use the fraction of your holdings that counts as "dividend above and beyond economy-tracking" on some treat or other. (Indeed, "you can go out..." should read "you ''must'' go out...", if you're really determined to pursue precisely that tracking strategy.)

Who's selling you the real resources embodied in the "treat"? And what's ''their'' motive? Well, transaction fee payers presumably like to re-stock their bitcoin real balances to roughly the same [economy-tracking] level as before, on average - they're paying for the fee processing as a service. These fees are then burned by miners. (Well, not literally the fees themselves - the fees themselves are ''collected'' by miners, but the way they achieve this is to burn an approximately equal amount, as explained earlier.) So, ordinary Bitcoin users, to achieve their desired re-stocking, have to either produce slightly more, or consume slightly less, or a proper or improper mixture thereof, than they would have needed to in a hypothetical (presumably impracticable) alternative world where they pay no fees for their everyday transactions (and some magic mining-god just altruistically and reliably creates a blockchain out of all the transactions, without charging anybody anything). [This follows directly from their re-stocking desire, and has nothing to do with proof-of-burn specifically. That is, they have to do this regardless of whether the protocol is proof-of-work, proof-of-stake, proof-of-burn or whatever.] It's that extra gap between production and consumption - "extra" on top of whatever gap people are already choosing as a real saving[/dis-saving] strategy - that goes on to the market, for you and all other bitcoin holders to bid off the market by spending on your "treat".

This whole stable pattern of spending habits is, perhaps surprisingly, the same pattern of real resource allocation as would have happened if Cunicula's proof of stake (with close to 100% stake / 0% work admixture) had been in operation, and all bitcoin holders, large and small, had enthusiastically thrown their bitcoins (that is, their stream of bitcoin days destroyed) into the stake-claiming process. The fraction of fees they'd collect if they did that would be just like the "dividend" as I called it above - it would be like explicit remurrage, except instead of being automatic, it would require each holder's active participation (i.e. they couldn't just go to sleep, unless they left some sort of "trusted bot" running and using their private keys to sign their stream of bitcoin days destroyed). So, if you like, proof-of-burn is like automated, 100%-stakeholder-participation Cunicula-style proof-of-stake!

Incidentally, it's also fascinating to consider what happens if the community does decide a demurraging of [ordinary, unburnt] coins, the revenue being added as a coin-[re-]minting stream to the flow of fees, ''is'' necessary to continue with forever, for the sake of network strength. The amazing answer, as far as I can honestly work out, is that in long-run equilibrium, the burn rate is just such as '''to make hardly any of this demurrage ''real'' demurrage at all!''' [The implicit remurrage of burning almost exactly cancels the explicit demurrage of network-strengthening coin-[re-]minting! (Or if you like, the implicit demurrage of inflationary fresh-coin-minting.) Either way, we ''seem'' to get the possibility of amazing network strength "for free"!] This opens up the shocking possibility of turning up the demurrage/inflation rate to startlingly high levels - 5% of money stock / year, 10% of money stock / year... levels that would bring the whole cryptocurrency into disrepute in the true proof-of-work case, since coin-holders really would suffer that actual amount of explicit or implicit demurrage - and yet '''not''' hitting coin-holders with more than a frictional residual fraction of that ''in real terms'' at all, because of the way burning simulates remurrage! Extraordinary stuff! I plan to say more about this soon - but this quick teaser description should already be food for thought.

=== Coin-burning as a tool for transition between cryptocurrencies ===

Proof of burn may also be of interest as a tool for managing an orderly transition from one cryptocurrency ("oldcoin", let's call it) to another ("newcoin"). If the developers of newcoin are looking for a way of avoiding proof-of-work's real resource consumption '''even in newcoin's initial distribution phase''', they can't use proof of newcoin-burn: newcoins don't exist yet. But they ''can'' use proof of oldcoin-burn! (Assuming their reason for creating newcoin is '''not''' a doubting of oldcoin's security model, anyway. - Or at least, not a doubting severe enough to affect sufficiently deeply buried oldcoins, these being the candidates for burning.)

The newcoin blockchain would thus start with (at least a hash referring to) a complete catalogue of all the [sufficiently deeply buried] unspent txouts of oldcoin. Miners would then exhibit burning events within oldcoin up to a certain date; after which, the protocol would switch to burning of newcoin itself (and the dependency on oldcoin could even be thrown away entirely, if a checkpoint of that transition moment was promulgated and accepted by the newcoin community).

This has the nice consequence that, if people throughout the broader economy are gradually deserting oldcoin (as newcoin catches on), '''''its value need not collapse!''''' Instead, oldcoin gets burnt in the transition process, neatly reducing its nominal supply in just such a way as to roughly keep pace with its declining real demand. Meanwhile, those same acts of burning are minting fresh newcoins, at just the pace required to keep up with newcoin's ''growing'' real demand. (At least, that's the case if miners anticipate the transition speed correctly, and enter / exit the coins' respective mining trades at a pace that competes away supra-normal profits. We also have to assume that the ''total'' real demand for both[/all...] cryptocurrencies is roughly stable in "economy-tracking" terms; or at least, that miners anticipate the time path of the size of total real demand, and of its currency-by-currency composition, correctly, or near enough correctly.)

'''To sum up:''' proof of burn ''could'', just maybe, qualify as a new tool to greatly assist overall (multi-cryptocurrency) economic robustness and stability!

Proof of burn

2012-12-16T22:32:16Z

Ids: /* Economic implications */ added subsubsection "Coin-burning as a tool for transition between cryptocurrencies" (header only, for now)

'''Proof of burn''' is a potential alternative to [[Proof_of_work|proof of work]] and [[Proof_of_Stake|proof of stake]] as a "scarce resource" to be exhibited by miners competing for the stream of rewards (minted coins and transaction fees) which a cryptocurrency's design makes available. 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 unlike proof of work, it consumes no real resources from a whole economy perspective. This has interesting implications, discussed below.

There are likely many possible variants of proof of burn. This page currently describes [[User:Ids|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 ==

=== Introduction and motivation ===

The key idea of proof-of-burn (this would also apply to proof-of-stake, by the way) is that when choosing the thing which is to qualify as a "difficulty", i.e. to require miners to exhibit proof that they've "done something that's tough to do", all that matters is that '''an individual miner''' finds the task expensive. (Well... it also matters that everyone else should find it cheap to verify that it has been done.) 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 all 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.e. [the fast early phase of] its initial distribution) - or, more precisely, while ''the first'' cryptocurrency is being set up; more on this distinction later! - no good alternative has been proposed. (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 variety", I mean) is in 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: burning the currency!

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. With Bitcoin, any address which is [the RIPEMD160/SHA256 hash of] a script that evaluates to false will do. 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 RIPEMD160 since you can choose big numbers to taste. So, bitcoins sent to such a txout can never be redeemed on a future txin. (Barring the cracking of RIPEMD160 and the finding of an alternative matching script, that is. If ''that'' happens, the cryptocurrency is in 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. (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: burning merely needs to be defined as sending to some ''fixed'' unspendable address, with no variation - e.g. we could settle on the hash of "push 4, and check if it's equal to 5".

So, miners are creating candidate winning blocks by saying to the listening world, not "Look! I've done this many trillion hashes! [or struck lucky with fewer: you, the listening world, wouldn't know the difference... but this doesn't matter...]", but rather "Look! 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! Thanks!" That extremely recent act of burning could be undone in a block chain reorganisation; and then the same miner would be able to "re-burn" those same coins in an attempt to grab a block afresh, post-reorganisation. 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. A proof-of-work miner must simply shrug and say "Oh well, that's those expenses [electricity, mining rig rental / imputed rental,...] lost and gone... time to try again!" And that's the way things should be, for security - it '''should not''' be as cheap to extend the height of two or more competing chains as it is to focus on one. (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. Details to follow.

Now then! 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 users are sending them fees (and any coin-minting still going on too of course), minus the miners' true real-resource costs (i.e. the hardware and electricity and the like for handling transactions and blocks and burn proofs - these costs will be far lower than the hashing costs incurred under proof-of-work, but of course still non-zero). 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.

=== Technical sketch of proof of burn: "Burnt coins are mining rigs!" ===

''Iain Stewart writes:'' 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:

'''''"Burnt coins are mining rigs!"'''''

What that slogan means will become clear as I go on. Basically, 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! - to simulate the generating of random hashes that a real proof-of-work mining rig would produce. Now, obviously we don't want to "simulate" every actual hash! A "simulation" of proof-of-work at ''that'' level of detail would just ''be'' proof-of-work! Rather, we want to mimic the statistical properties of a mining rig's stream of hashes, to just the level of detail required to give the same sort of pattern of meeting / not meeting a moving difficulty target, and all the rest of it, that we get with the real thing.

So: first of all, what exactly is my "stream of true randomness"? Chop up time into units considerably shorter than the intended inter-block time, but 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!) at time t, they can't predict the value of RAND(any t' 2 months or more to the future of t). [Where "2 months" means the dead time a burnt coin must wait before it becomes a simulated active mining rig. 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.] We do '''not''' need fresh statistical independence of RAND(t) w.r.t. all of RAND(t-1), RAND(t-2), RAND(t-3), etc. (And we don't mind if the stream is known a "short" time into the future - e.g. a week or two; at any rate a small portion of the waiting period.)

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: lotteries. 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.dat or whatever) should get "the latest lottery results" appended to it. 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. Like this:

.
.
.
for use from 2013-06-24 00:00:00 onwards: UK national lottery 2013-06-12: 4 9 20 22 37 42, bonus ball 19
for use from 2013-07-01 00:00:00 onwards: UK national lottery 2013-06-19: 7 12 14 19 33 41, bonus ball 28

(Obviously the meta-level words "for use from... onwards" aren't really needed - I just put them in for clarity.) Each line is added in a leisurely, unhurried fashion, at some time (it doesn't matter when) between the draw and the intended start-paying-attention-to-it date. (Some time between 2013-06-19 and 2013-07-01 00:00:00, in the case of the example last line above.) 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.g. 2013-07-02 23:14:05, or just the Unix numeric time] as a final line). - Or if you like, HASH(HASH(config-file) ++ t), for efficiency. (Where "++" means "append together in some standard fashion".) "HASH()" is your favourite hash function, e.g. SHA256(SHA256()). Thus RAND(t) is a 256-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. [For their application or for mine!] Someone producing the latest block, given the previous 99, can privately produce billions of cheap variations on it, by varying the order the transactions are listed etc, until they find, and publish, the one that "games" the randomness in their favour. 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 of bits of unknowable future entropy. That's all that matters for turning burnt coins into simulated mining rigs.)

Right then! What do we do with this RAND(t) stream? We simulate the capricious behaviour of a true proof-of-work mining rig! Let us assume that, in the real proof-of-work world, you can buy an h hashes/second mining rig for b=c*h BTC. (c varies with technical progress, BTC price fluctuations, etc; but in the simulated world it can just be left constant.) Or, inverting this, if you spend b BTC, you acquire a mining rig of h=b/c hashes/s power. Now, what does it actually mean for your rig to perform h hashes during 1 second? It means you're producing h uniform random numbers between 0 and 1. (That binary point again!) But you don't really care what they all are individually - how well you did during that 1 second is defined as "what was the '''lowest''' hash value you produced during that 1 second?". This is then inspected for whether it beats [is lower than] the network's current target; or, perhaps, whether it beats the lesser [i.e. numerically greater] target of a pooled mining operation. If it's good enough, that precious lowest hash is published to the network (or mining pool), and the others are just thrown away (not published). If it's not good enough, even the [not-so-]precious lowest hash isn't published - and certainly not the others. So, in the simulation, we only need to produce, for each second, a simulated "lowest hash for that 1 second". The "others" don't have to exist at all!

For reproducing (statistically) the pattern of hits and misses w.r.t. targets tough enough to not be achieving several hits within 1 second, and for h>>1, we can take the simulated lowest hash for time t to be (1/h) * HASH(signatures-of-the-act-of-burning-the-b-BTC ++ RAND(t)). [In fact this even works for h<1, despite the rather surreal appearance of "lowest hashes" >1 every so often in that case - i.e. values outside the range that ''real'' lowest (or any other!) hashes can ever actually be: it turns out this surreal behaviour is just what's needed to degrade the probability of beating the target by just the right amount. Values >1 in effect represent "I didn't generate any hashes at all during this particular 1-second window".]

Two further subtleties. First of all, it turns out to be desirable to include the block number (chain height @ 1 per block) in the formula - just to keep the owners of simulated mining rigs "on their toes" and not be able to tell a week or so in advance when they'll be lucky. (This encourages them to run a continuous full node. Maybe that's not in fact that important.) So we take simulated-lowest-hash = (1/h) * HASH(signatures-of-the-act-of-burning-the-b-BTC ++ block-number-of-would-be-block ++ RAND(t)). (We should '''not''' include finer details of the block, to avoid "gaming" a la the hundred blocks business I mentioned earlier. - Or if I'm wrong about that, then OK, by all means mix in finer details of the block!)

Secondly, it turns out that to keep the burning process going forever, rather than a pulse of initial burning that no-one ever again wants to contribute further burning to, we should simulate one more property of real-world mining rigs: they break down! That is, we should demurrage away the strength of a simulated mining rig. (A plea to the reader: Don't be alarmed by the word "demurrage". This is '''burnt''' coins I'm talking about - they ''should'' be treated "harshly", in whatever style mimics real-world mining rigs to the required fidelity. Ordinary unburnt coins are not being demurraged! [Unless that's independently desirable as a policy matter, e.g. if it's felt that network strength can only be achieved via more revenue for miners than fees alone will ever provide.]) A real mining rig likely works at full tilt for a few years and then conks out. We ''could'' demurrage each burnt coin in that style - it abruptly expires E years after its creation - but I think a smooth exponential demurrage is nicer, i.e. its burnt value after y years is b'=b*exp(-y/E). Thus h = b'/c = (b/c)*exp(-y/E). [And 1/h = c/b' = (c/b)*exp(y/E).]

Taking these two further subtleties into account, we get the following formula:

simulated-lowest-hash(t) = (c/b)*exp([t - t_burning]/E) * HASH(signatures-of-the-act-of-burning-the-b-BTC ++ block-number-of-would-be-block ++ RAND(t)).

So there you have it! With this formula, life as a miner is spookily similar to the real proof-of-work case. You "buy a mining rig" - you burn coins, and that hits ''you'' in exactly the way sending off money to a chip supplier would have hit you, even though over the whole economy, no real resources have been expended - and you then hope that, by submitting lucky hashes to the network in the form of blocks, you can make more back in fees over time than you spent initially. If you don't keep connected to the network, you won't know what transactions are eligible for including in your next would-be block, and your next lucky hash will run to waste. Meanwhile, other people are "buying mining rigs" (burning coins) too, either freshly or to make up for the "wearing out" of their existing ones; and the network is adjusting its target hash value [reciprocal difficulty] to regulate the rate all this mining effort is producing blocks at, to some preferred average rate. All spookily normal, in other words!

Now, I'm being a little bit disingenuous to say that ''everything'' is normal. We need protection against certain things (use of a lucky hash on two or more competing chains; timestamp-falsification abuse) which either do not exist at all under true proof-of-work - the former - or exist but with the consequences and mitigation strategy being different in detail - the latter. I believe I have a way of standing up to the various forms of malice we need to worry about of those kinds. More to follow soon hopefully!

=== Economic implications ===

The key insight is that verifiably, publicly burning some coins of a known-total-stock-issued currency is the same as "remurrage" (opposite of "demurrage" - it may not be a correct word, but it's a nice back-formation) on the remainder. That is, if there are verifiably 21 million issued-and-not-burned coins, and then you go to sleep and wake up later and there are now only 20 million issued-and-not-burned coins, that's the same as if some magic genie multiplied all wake-up-time nominal bitcoin figures by 21/20. Another way to see the identity of real effect would be to redefine "burning n bitcoins" to mean, not "sending n to an unspendable address", but rather "scattering" the n bitcoins, i.e. sending them to '''every existing''' [non-zero-balance] address, in proportion to the balance [sum of unspent txouts] already stored in each. This would be a horribly gigantic transaction to actually do explicitly, but the point is, burning can be thought of "as if" done that way. (Slogan: Quantity-deflation is remurrage in disguise, in exactly the same way that quantity-inflation is demurrage in disguise.)

So, what ''that'' means is, if while you're sleeping you (a non-miner) hold 1 bitcoin purely passively, i.e. it just sits undisturbed on the blockchain, well, when you wake up, it's as if you've received a "dividend" (of 5% in the particular numeric example above) on top of the general economy-tracking price we expect of a constant-quantity currency. In a world with actual, visibly performed remurrage, this is made explicit - your balance is now 21/20, with the nominal circulation [issued-and-not-burned, and remurraged for good measure] constant at 21 million. You can go and spend the 1/20 "dividend" on some treat, and still have the same fraction (1 out of 21 million) of the money stock as when you went to sleep.

In a world ''without'' any attempt at explicit remurrage, the real facts of the situation are (of course!) the same, but their nominal expression is not perhaps so instantly obvious. Your nominal holding is unchanged at 1; but this is now 1 part in 20 million of the whole money stock, not the 1 part in 21 million it was before. So, you can go and spend 1/21 of it on some treat, taking your nominal balance down to 20/21, and ''that'' nominal balance is the same (1 out of 21 million) fraction of the money stock as when you went to sleep.

So, basically, if you're holding bitcoins and trying to hold an "economy-tracking amount", no more and no less, you find you can go out into the market and use the fraction of your holdings that counts as "dividend above and beyond economy-tracking" on some treat or other. (Indeed, "you can go out..." should read "you ''must'' go out...", if you're really determined to pursue precisely that tracking strategy.)

Who's selling you the real resources embodied in the "treat"? And what's ''their'' motive? Well, transaction fee payers presumably like to re-stock their bitcoin real balances to roughly the same [economy-tracking] level as before, on average - they're paying for the fee processing as a service. These fees are then burned by miners. (Well, not literally the fees themselves - the fees themselves are ''collected'' by miners, but the way they achieve this is to burn an approximately equal amount, as explained earlier.) So, ordinary Bitcoin users, to achieve their desired re-stocking, have to either produce slightly more, or consume slightly less, or a proper or improper mixture thereof, than they would have needed to in a hypothetical (presumably impracticable) alternative world where they pay no fees for their everyday transactions (and some magic mining-god just altruistically and reliably creates a blockchain out of all the transactions, without charging anybody anything). [This follows directly from their re-stocking desire, and has nothing to do with proof-of-burn specifically. That is, they have to do this regardless of whether the protocol is proof-of-work, proof-of-stake, proof-of-burn or whatever.] It's that extra gap between production and consumption - "extra" on top of whatever gap people are already choosing as a real saving[/dis-saving] strategy - that goes on to the market, for you and all other bitcoin holders to bid off the market by spending on your "treat".

This whole stable pattern of spending habits is, perhaps surprisingly, the same pattern of real resource allocation as would have happened if Cunicula's proof of stake (with close to 100% stake / 0% work admixture) had been in operation, and all bitcoin holders, large and small, had enthusiastically thrown their bitcoins (that is, their stream of bitcoin days destroyed) into the stake-claiming process. The fraction of fees they'd collect if they did that would be just like the "dividend" as I called it above - it would be like explicit remurrage, except instead of being automatic, it would require each holder's active participation (i.e. they couldn't just go to sleep, unless they left some sort of "trusted bot" running and using their private keys to sign their stream of bitcoin days destroyed). So, if you like, proof-of-burn is like automated, 100%-stakeholder-participation Cunicula-style proof-of-stake!

Incidentally, it's also fascinating to consider what happens if the community does decide a demurraging of [ordinary, unburnt] coins, the revenue being added as a coin-[re-]minting stream to the flow of fees, ''is'' necessary to continue with forever, for the sake of network strength. The amazing answer, as far as I can honestly work out, is that in long-run equilibrium, the burn rate is just such as '''to make hardly any of this demurrage ''real'' demurrage at all!''' [The implicit remurrage of burning almost exactly cancels the explicit demurrage of network-strengthening coin-[re-]minting! (Or if you like, the implicit demurrage of inflationary fresh-coin-minting.) Either way, we ''seem'' to get the possibility of amazing network strength "for free"!] This opens up the shocking possibility of turning up the demurrage/inflation rate to startlingly high levels - 5% of money stock / year, 10% of money stock / year... levels that would bring the whole cryptocurrency into disrepute in the true proof-of-work case, since coin-holders really would suffer that actual amount of explicit or implicit demurrage - and yet '''not''' hitting coin-holders with more than a frictional residual fraction of that ''in real terms'' at all, because of the way burning simulates remurrage! Extraordinary stuff! I plan to say more about this soon - but this quick teaser description should already be food for thought.

==== Coin-burning as a tool for transition between cryptocurrencies ====

Proof of burn

2012-12-16T22:29:40Z

Ids: /* Economic implications */ added teaser of the extraordinary business of network strength almost for free!

'''Proof of burn''' is a potential alternative to [[Proof_of_work|proof of work]] and [[Proof_of_Stake|proof of stake]] as a "scarce resource" to be exhibited by miners competing for the stream of rewards (minted coins and transaction fees) which a cryptocurrency's design makes available. 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 unlike proof of work, it consumes no real resources from a whole economy perspective. This has interesting implications, discussed below.

There are likely many possible variants of proof of burn. This page currently describes [[User:Ids|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 ==

=== Introduction and motivation ===

The key idea of proof-of-burn (this would also apply to proof-of-stake, by the way) is that when choosing the thing which is to qualify as a "difficulty", i.e. to require miners to exhibit proof that they've "done something that's tough to do", all that matters is that '''an individual miner''' finds the task expensive. (Well... it also matters that everyone else should find it cheap to verify that it has been done.) 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 all 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.e. [the fast early phase of] its initial distribution) - or, more precisely, while ''the first'' cryptocurrency is being set up; more on this distinction later! - no good alternative has been proposed. (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 variety", I mean) is in 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: burning the currency!

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. With Bitcoin, any address which is [the RIPEMD160/SHA256 hash of] a script that evaluates to false will do. 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 RIPEMD160 since you can choose big numbers to taste. So, bitcoins sent to such a txout can never be redeemed on a future txin. (Barring the cracking of RIPEMD160 and the finding of an alternative matching script, that is. If ''that'' happens, the cryptocurrency is in 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. (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: burning merely needs to be defined as sending to some ''fixed'' unspendable address, with no variation - e.g. we could settle on the hash of "push 4, and check if it's equal to 5".

So, miners are creating candidate winning blocks by saying to the listening world, not "Look! I've done this many trillion hashes! [or struck lucky with fewer: you, the listening world, wouldn't know the difference... but this doesn't matter...]", but rather "Look! 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! Thanks!" That extremely recent act of burning could be undone in a block chain reorganisation; and then the same miner would be able to "re-burn" those same coins in an attempt to grab a block afresh, post-reorganisation. 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. A proof-of-work miner must simply shrug and say "Oh well, that's those expenses [electricity, mining rig rental / imputed rental,...] lost and gone... time to try again!" And that's the way things should be, for security - it '''should not''' be as cheap to extend the height of two or more competing chains as it is to focus on one. (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. Details to follow.

Now then! 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 users are sending them fees (and any coin-minting still going on too of course), minus the miners' true real-resource costs (i.e. the hardware and electricity and the like for handling transactions and blocks and burn proofs - these costs will be far lower than the hashing costs incurred under proof-of-work, but of course still non-zero). 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.

=== Technical sketch of proof of burn: "Burnt coins are mining rigs!" ===

''Iain Stewart writes:'' 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:

'''''"Burnt coins are mining rigs!"'''''

What that slogan means will become clear as I go on. Basically, 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! - to simulate the generating of random hashes that a real proof-of-work mining rig would produce. Now, obviously we don't want to "simulate" every actual hash! A "simulation" of proof-of-work at ''that'' level of detail would just ''be'' proof-of-work! Rather, we want to mimic the statistical properties of a mining rig's stream of hashes, to just the level of detail required to give the same sort of pattern of meeting / not meeting a moving difficulty target, and all the rest of it, that we get with the real thing.

So: first of all, what exactly is my "stream of true randomness"? Chop up time into units considerably shorter than the intended inter-block time, but 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!) at time t, they can't predict the value of RAND(any t' 2 months or more to the future of t). [Where "2 months" means the dead time a burnt coin must wait before it becomes a simulated active mining rig. 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.] We do '''not''' need fresh statistical independence of RAND(t) w.r.t. all of RAND(t-1), RAND(t-2), RAND(t-3), etc. (And we don't mind if the stream is known a "short" time into the future - e.g. a week or two; at any rate a small portion of the waiting period.)

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: lotteries. 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.dat or whatever) should get "the latest lottery results" appended to it. 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. Like this:

.
.
.
for use from 2013-06-24 00:00:00 onwards: UK national lottery 2013-06-12: 4 9 20 22 37 42, bonus ball 19
for use from 2013-07-01 00:00:00 onwards: UK national lottery 2013-06-19: 7 12 14 19 33 41, bonus ball 28

(Obviously the meta-level words "for use from... onwards" aren't really needed - I just put them in for clarity.) Each line is added in a leisurely, unhurried fashion, at some time (it doesn't matter when) between the draw and the intended start-paying-attention-to-it date. (Some time between 2013-06-19 and 2013-07-01 00:00:00, in the case of the example last line above.) 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.g. 2013-07-02 23:14:05, or just the Unix numeric time] as a final line). - Or if you like, HASH(HASH(config-file) ++ t), for efficiency. (Where "++" means "append together in some standard fashion".) "HASH()" is your favourite hash function, e.g. SHA256(SHA256()). Thus RAND(t) is a 256-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. [For their application or for mine!] Someone producing the latest block, given the previous 99, can privately produce billions of cheap variations on it, by varying the order the transactions are listed etc, until they find, and publish, the one that "games" the randomness in their favour. 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 of bits of unknowable future entropy. That's all that matters for turning burnt coins into simulated mining rigs.)

Right then! What do we do with this RAND(t) stream? We simulate the capricious behaviour of a true proof-of-work mining rig! Let us assume that, in the real proof-of-work world, you can buy an h hashes/second mining rig for b=c*h BTC. (c varies with technical progress, BTC price fluctuations, etc; but in the simulated world it can just be left constant.) Or, inverting this, if you spend b BTC, you acquire a mining rig of h=b/c hashes/s power. Now, what does it actually mean for your rig to perform h hashes during 1 second? It means you're producing h uniform random numbers between 0 and 1. (That binary point again!) But you don't really care what they all are individually - how well you did during that 1 second is defined as "what was the '''lowest''' hash value you produced during that 1 second?". This is then inspected for whether it beats [is lower than] the network's current target; or, perhaps, whether it beats the lesser [i.e. numerically greater] target of a pooled mining operation. If it's good enough, that precious lowest hash is published to the network (or mining pool), and the others are just thrown away (not published). If it's not good enough, even the [not-so-]precious lowest hash isn't published - and certainly not the others. So, in the simulation, we only need to produce, for each second, a simulated "lowest hash for that 1 second". The "others" don't have to exist at all!

For reproducing (statistically) the pattern of hits and misses w.r.t. targets tough enough to not be achieving several hits within 1 second, and for h>>1, we can take the simulated lowest hash for time t to be (1/h) * HASH(signatures-of-the-act-of-burning-the-b-BTC ++ RAND(t)). [In fact this even works for h<1, despite the rather surreal appearance of "lowest hashes" >1 every so often in that case - i.e. values outside the range that ''real'' lowest (or any other!) hashes can ever actually be: it turns out this surreal behaviour is just what's needed to degrade the probability of beating the target by just the right amount. Values >1 in effect represent "I didn't generate any hashes at all during this particular 1-second window".]

Two further subtleties. First of all, it turns out to be desirable to include the block number (chain height @ 1 per block) in the formula - just to keep the owners of simulated mining rigs "on their toes" and not be able to tell a week or so in advance when they'll be lucky. (This encourages them to run a continuous full node. Maybe that's not in fact that important.) So we take simulated-lowest-hash = (1/h) * HASH(signatures-of-the-act-of-burning-the-b-BTC ++ block-number-of-would-be-block ++ RAND(t)). (We should '''not''' include finer details of the block, to avoid "gaming" a la the hundred blocks business I mentioned earlier. - Or if I'm wrong about that, then OK, by all means mix in finer details of the block!)

Secondly, it turns out that to keep the burning process going forever, rather than a pulse of initial burning that no-one ever again wants to contribute further burning to, we should simulate one more property of real-world mining rigs: they break down! That is, we should demurrage away the strength of a simulated mining rig. (A plea to the reader: Don't be alarmed by the word "demurrage". This is '''burnt''' coins I'm talking about - they ''should'' be treated "harshly", in whatever style mimics real-world mining rigs to the required fidelity. Ordinary unburnt coins are not being demurraged! [Unless that's independently desirable as a policy matter, e.g. if it's felt that network strength can only be achieved via more revenue for miners than fees alone will ever provide.]) A real mining rig likely works at full tilt for a few years and then conks out. We ''could'' demurrage each burnt coin in that style - it abruptly expires E years after its creation - but I think a smooth exponential demurrage is nicer, i.e. its burnt value after y years is b'=b*exp(-y/E). Thus h = b'/c = (b/c)*exp(-y/E). [And 1/h = c/b' = (c/b)*exp(y/E).]

Taking these two further subtleties into account, we get the following formula:

simulated-lowest-hash(t) = (c/b)*exp([t - t_burning]/E) * HASH(signatures-of-the-act-of-burning-the-b-BTC ++ block-number-of-would-be-block ++ RAND(t)).

So there you have it! With this formula, life as a miner is spookily similar to the real proof-of-work case. You "buy a mining rig" - you burn coins, and that hits ''you'' in exactly the way sending off money to a chip supplier would have hit you, even though over the whole economy, no real resources have been expended - and you then hope that, by submitting lucky hashes to the network in the form of blocks, you can make more back in fees over time than you spent initially. If you don't keep connected to the network, you won't know what transactions are eligible for including in your next would-be block, and your next lucky hash will run to waste. Meanwhile, other people are "buying mining rigs" (burning coins) too, either freshly or to make up for the "wearing out" of their existing ones; and the network is adjusting its target hash value [reciprocal difficulty] to regulate the rate all this mining effort is producing blocks at, to some preferred average rate. All spookily normal, in other words!

Now, I'm being a little bit disingenuous to say that ''everything'' is normal. We need protection against certain things (use of a lucky hash on two or more competing chains; timestamp-falsification abuse) which either do not exist at all under true proof-of-work - the former - or exist but with the consequences and mitigation strategy being different in detail - the latter. I believe I have a way of standing up to the various forms of malice we need to worry about of those kinds. More to follow soon hopefully!

=== Economic implications ===

The key insight is that verifiably, publicly burning some coins of a known-total-stock-issued currency is the same as "remurrage" (opposite of "demurrage" - it may not be a correct word, but it's a nice back-formation) on the remainder. That is, if there are verifiably 21 million issued-and-not-burned coins, and then you go to sleep and wake up later and there are now only 20 million issued-and-not-burned coins, that's the same as if some magic genie multiplied all wake-up-time nominal bitcoin figures by 21/20. Another way to see the identity of real effect would be to redefine "burning n bitcoins" to mean, not "sending n to an unspendable address", but rather "scattering" the n bitcoins, i.e. sending them to '''every existing''' [non-zero-balance] address, in proportion to the balance [sum of unspent txouts] already stored in each. This would be a horribly gigantic transaction to actually do explicitly, but the point is, burning can be thought of "as if" done that way. (Slogan: Quantity-deflation is remurrage in disguise, in exactly the same way that quantity-inflation is demurrage in disguise.)

So, what ''that'' means is, if while you're sleeping you (a non-miner) hold 1 bitcoin purely passively, i.e. it just sits undisturbed on the blockchain, well, when you wake up, it's as if you've received a "dividend" (of 5% in the particular numeric example above) on top of the general economy-tracking price we expect of a constant-quantity currency. In a world with actual, visibly performed remurrage, this is made explicit - your balance is now 21/20, with the nominal circulation [issued-and-not-burned, and remurraged for good measure] constant at 21 million. You can go and spend the 1/20 "dividend" on some treat, and still have the same fraction (1 out of 21 million) of the money stock as when you went to sleep.

In a world ''without'' any attempt at explicit remurrage, the real facts of the situation are (of course!) the same, but their nominal expression is not perhaps so instantly obvious. Your nominal holding is unchanged at 1; but this is now 1 part in 20 million of the whole money stock, not the 1 part in 21 million it was before. So, you can go and spend 1/21 of it on some treat, taking your nominal balance down to 20/21, and ''that'' nominal balance is the same (1 out of 21 million) fraction of the money stock as when you went to sleep.

So, basically, if you're holding bitcoins and trying to hold an "economy-tracking amount", no more and no less, you find you can go out into the market and use the fraction of your holdings that counts as "dividend above and beyond economy-tracking" on some treat or other. (Indeed, "you can go out..." should read "you ''must'' go out...", if you're really determined to pursue precisely that tracking strategy.)

Who's selling you the real resources embodied in the "treat"? And what's ''their'' motive? Well, transaction fee payers presumably like to re-stock their bitcoin real balances to roughly the same [economy-tracking] level as before, on average - they're paying for the fee processing as a service. These fees are then burned by miners. (Well, not literally the fees themselves - the fees themselves are ''collected'' by miners, but the way they achieve this is to burn an approximately equal amount, as explained earlier.) So, ordinary Bitcoin users, to achieve their desired re-stocking, have to either produce slightly more, or consume slightly less, or a proper or improper mixture thereof, than they would have needed to in a hypothetical (presumably impracticable) alternative world where they pay no fees for their everyday transactions (and some magic mining-god just altruistically and reliably creates a blockchain out of all the transactions, without charging anybody anything). [This follows directly from their re-stocking desire, and has nothing to do with proof-of-burn specifically. That is, they have to do this regardless of whether the protocol is proof-of-work, proof-of-stake, proof-of-burn or whatever.] It's that extra gap between production and consumption - "extra" on top of whatever gap people are already choosing as a real saving[/dis-saving] strategy - that goes on to the market, for you and all other bitcoin holders to bid off the market by spending on your "treat".

This whole stable pattern of spending habits is, perhaps surprisingly, the same pattern of real resource allocation as would have happened if Cunicula's proof of stake (with close to 100% stake / 0% work admixture) had been in operation, and all bitcoin holders, large and small, had enthusiastically thrown their bitcoins (that is, their stream of bitcoin days destroyed) into the stake-claiming process. The fraction of fees they'd collect if they did that would be just like the "dividend" as I called it above - it would be like explicit remurrage, except instead of being automatic, it would require each holder's active participation (i.e. they couldn't just go to sleep, unless they left some sort of "trusted bot" running and using their private keys to sign their stream of bitcoin days destroyed). So, if you like, proof-of-burn is like automated, 100%-stakeholder-participation Cunicula-style proof-of-stake!

Incidentally, it's also fascinating to consider what happens if the community does decide a demurraging of [ordinary, unburnt] coins, the revenue being added as a coin-[re-]minting stream to the flow of fees, ''is'' necessary to continue with forever, for the sake of network strength. The amazing answer, as far as I can honestly work out, is that in long-run equilibrium, the burn rate is just such as '''to make hardly any of this demurrage ''real'' demurrage at all!''' [The implicit remurrage of burning almost exactly cancels the explicit demurrage of network-strengthening coin-[re-]minting! (Or if you like, the implicit demurrage of inflationary fresh-coin-minting.) Either way, we ''seem'' to get the possibility of amazing network strength "for free"!] This opens up the shocking possibility of turning up the demurrage/inflation rate to startlingly high levels - 5% of money stock / year, 10% of money stock / year... levels that would bring the whole cryptocurrency into disrepute in the true proof-of-work case, since coin-holders really would suffer that actual amount of explicit or implicit demurrage - and yet '''not''' hitting coin-holders with more than a frictional residual fraction of that ''in real terms'' at all, because of the way burning simulates remurrage! Extraordinary stuff! I plan to say more about this soon - but this quick teaser description should already be food for thought.

Proof of burn

2012-12-16T22:23:52Z

Ids: /* Technical sketch of proof of burn: "Burnt coins are mining rigs!" */ OK, first content under this section

'''Proof of burn''' is a potential alternative to [[Proof_of_work|proof of work]] and [[Proof_of_Stake|proof of stake]] as a "scarce resource" to be exhibited by miners competing for the stream of rewards (minted coins and transaction fees) which a cryptocurrency's design makes available. 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 unlike proof of work, it consumes no real resources from a whole economy perspective. This has interesting implications, discussed below.

There are likely many possible variants of proof of burn. This page currently describes [[User:Ids|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 ==

=== Introduction and motivation ===

The key idea of proof-of-burn (this would also apply to proof-of-stake, by the way) is that when choosing the thing which is to qualify as a "difficulty", i.e. to require miners to exhibit proof that they've "done something that's tough to do", all that matters is that '''an individual miner''' finds the task expensive. (Well... it also matters that everyone else should find it cheap to verify that it has been done.) 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 all 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.e. [the fast early phase of] its initial distribution) - or, more precisely, while ''the first'' cryptocurrency is being set up; more on this distinction later! - no good alternative has been proposed. (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 variety", I mean) is in 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: burning the currency!

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. With Bitcoin, any address which is [the RIPEMD160/SHA256 hash of] a script that evaluates to false will do. 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 RIPEMD160 since you can choose big numbers to taste. So, bitcoins sent to such a txout can never be redeemed on a future txin. (Barring the cracking of RIPEMD160 and the finding of an alternative matching script, that is. If ''that'' happens, the cryptocurrency is in 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. (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: burning merely needs to be defined as sending to some ''fixed'' unspendable address, with no variation - e.g. we could settle on the hash of "push 4, and check if it's equal to 5".

So, miners are creating candidate winning blocks by saying to the listening world, not "Look! I've done this many trillion hashes! [or struck lucky with fewer: you, the listening world, wouldn't know the difference... but this doesn't matter...]", but rather "Look! 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! Thanks!" That extremely recent act of burning could be undone in a block chain reorganisation; and then the same miner would be able to "re-burn" those same coins in an attempt to grab a block afresh, post-reorganisation. 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. A proof-of-work miner must simply shrug and say "Oh well, that's those expenses [electricity, mining rig rental / imputed rental,...] lost and gone... time to try again!" And that's the way things should be, for security - it '''should not''' be as cheap to extend the height of two or more competing chains as it is to focus on one. (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. Details to follow.

Now then! 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 users are sending them fees (and any coin-minting still going on too of course), minus the miners' true real-resource costs (i.e. the hardware and electricity and the like for handling transactions and blocks and burn proofs - these costs will be far lower than the hashing costs incurred under proof-of-work, but of course still non-zero). 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.

=== Technical sketch of proof of burn: "Burnt coins are mining rigs!" ===

''Iain Stewart writes:'' 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:

'''''"Burnt coins are mining rigs!"'''''

What that slogan means will become clear as I go on. Basically, 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! - to simulate the generating of random hashes that a real proof-of-work mining rig would produce. Now, obviously we don't want to "simulate" every actual hash! A "simulation" of proof-of-work at ''that'' level of detail would just ''be'' proof-of-work! Rather, we want to mimic the statistical properties of a mining rig's stream of hashes, to just the level of detail required to give the same sort of pattern of meeting / not meeting a moving difficulty target, and all the rest of it, that we get with the real thing.

So: first of all, what exactly is my "stream of true randomness"? Chop up time into units considerably shorter than the intended inter-block time, but 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!) at time t, they can't predict the value of RAND(any t' 2 months or more to the future of t). [Where "2 months" means the dead time a burnt coin must wait before it becomes a simulated active mining rig. 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.] We do '''not''' need fresh statistical independence of RAND(t) w.r.t. all of RAND(t-1), RAND(t-2), RAND(t-3), etc. (And we don't mind if the stream is known a "short" time into the future - e.g. a week or two; at any rate a small portion of the waiting period.)

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: lotteries. 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.dat or whatever) should get "the latest lottery results" appended to it. 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. Like this:

.
.
.
for use from 2013-06-24 00:00:00 onwards: UK national lottery 2013-06-12: 4 9 20 22 37 42, bonus ball 19
for use from 2013-07-01 00:00:00 onwards: UK national lottery 2013-06-19: 7 12 14 19 33 41, bonus ball 28

(Obviously the meta-level words "for use from... onwards" aren't really needed - I just put them in for clarity.) Each line is added in a leisurely, unhurried fashion, at some time (it doesn't matter when) between the draw and the intended start-paying-attention-to-it date. (Some time between 2013-06-19 and 2013-07-01 00:00:00, in the case of the example last line above.) 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.g. 2013-07-02 23:14:05, or just the Unix numeric time] as a final line). - Or if you like, HASH(HASH(config-file) ++ t), for efficiency. (Where "++" means "append together in some standard fashion".) "HASH()" is your favourite hash function, e.g. SHA256(SHA256()). Thus RAND(t) is a 256-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. [For their application or for mine!] Someone producing the latest block, given the previous 99, can privately produce billions of cheap variations on it, by varying the order the transactions are listed etc, until they find, and publish, the one that "games" the randomness in their favour. 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 of bits of unknowable future entropy. That's all that matters for turning burnt coins into simulated mining rigs.)

Right then! What do we do with this RAND(t) stream? We simulate the capricious behaviour of a true proof-of-work mining rig! Let us assume that, in the real proof-of-work world, you can buy an h hashes/second mining rig for b=c*h BTC. (c varies with technical progress, BTC price fluctuations, etc; but in the simulated world it can just be left constant.) Or, inverting this, if you spend b BTC, you acquire a mining rig of h=b/c hashes/s power. Now, what does it actually mean for your rig to perform h hashes during 1 second? It means you're producing h uniform random numbers between 0 and 1. (That binary point again!) But you don't really care what they all are individually - how well you did during that 1 second is defined as "what was the '''lowest''' hash value you produced during that 1 second?". This is then inspected for whether it beats [is lower than] the network's current target; or, perhaps, whether it beats the lesser [i.e. numerically greater] target of a pooled mining operation. If it's good enough, that precious lowest hash is published to the network (or mining pool), and the others are just thrown away (not published). If it's not good enough, even the [not-so-]precious lowest hash isn't published - and certainly not the others. So, in the simulation, we only need to produce, for each second, a simulated "lowest hash for that 1 second". The "others" don't have to exist at all!

For reproducing (statistically) the pattern of hits and misses w.r.t. targets tough enough to not be achieving several hits within 1 second, and for h>>1, we can take the simulated lowest hash for time t to be (1/h) * HASH(signatures-of-the-act-of-burning-the-b-BTC ++ RAND(t)). [In fact this even works for h<1, despite the rather surreal appearance of "lowest hashes" >1 every so often in that case - i.e. values outside the range that ''real'' lowest (or any other!) hashes can ever actually be: it turns out this surreal behaviour is just what's needed to degrade the probability of beating the target by just the right amount. Values >1 in effect represent "I didn't generate any hashes at all during this particular 1-second window".]

Two further subtleties. First of all, it turns out to be desirable to include the block number (chain height @ 1 per block) in the formula - just to keep the owners of simulated mining rigs "on their toes" and not be able to tell a week or so in advance when they'll be lucky. (This encourages them to run a continuous full node. Maybe that's not in fact that important.) So we take simulated-lowest-hash = (1/h) * HASH(signatures-of-the-act-of-burning-the-b-BTC ++ block-number-of-would-be-block ++ RAND(t)). (We should '''not''' include finer details of the block, to avoid "gaming" a la the hundred blocks business I mentioned earlier. - Or if I'm wrong about that, then OK, by all means mix in finer details of the block!)

Secondly, it turns out that to keep the burning process going forever, rather than a pulse of initial burning that no-one ever again wants to contribute further burning to, we should simulate one more property of real-world mining rigs: they break down! That is, we should demurrage away the strength of a simulated mining rig. (A plea to the reader: Don't be alarmed by the word "demurrage". This is '''burnt''' coins I'm talking about - they ''should'' be treated "harshly", in whatever style mimics real-world mining rigs to the required fidelity. Ordinary unburnt coins are not being demurraged! [Unless that's independently desirable as a policy matter, e.g. if it's felt that network strength can only be achieved via more revenue for miners than fees alone will ever provide.]) A real mining rig likely works at full tilt for a few years and then conks out. We ''could'' demurrage each burnt coin in that style - it abruptly expires E years after its creation - but I think a smooth exponential demurrage is nicer, i.e. its burnt value after y years is b'=b*exp(-y/E). Thus h = b'/c = (b/c)*exp(-y/E). [And 1/h = c/b' = (c/b)*exp(y/E).]

Taking these two further subtleties into account, we get the following formula:

simulated-lowest-hash(t) = (c/b)*exp([t - t_burning]/E) * HASH(signatures-of-the-act-of-burning-the-b-BTC ++ block-number-of-would-be-block ++ RAND(t)).

So there you have it! With this formula, life as a miner is spookily similar to the real proof-of-work case. You "buy a mining rig" - you burn coins, and that hits ''you'' in exactly the way sending off money to a chip supplier would have hit you, even though over the whole economy, no real resources have been expended - and you then hope that, by submitting lucky hashes to the network in the form of blocks, you can make more back in fees over time than you spent initially. If you don't keep connected to the network, you won't know what transactions are eligible for including in your next would-be block, and your next lucky hash will run to waste. Meanwhile, other people are "buying mining rigs" (burning coins) too, either freshly or to make up for the "wearing out" of their existing ones; and the network is adjusting its target hash value [reciprocal difficulty] to regulate the rate all this mining effort is producing blocks at, to some preferred average rate. All spookily normal, in other words!

Now, I'm being a little bit disingenuous to say that ''everything'' is normal. We need protection against certain things (use of a lucky hash on two or more competing chains; timestamp-falsification abuse) which either do not exist at all under true proof-of-work - the former - or exist but with the consequences and mitigation strategy being different in detail - the latter. I believe I have a way of standing up to the various forms of malice we need to worry about of those kinds. More to follow soon hopefully!

=== Economic implications ===

The key insight is that verifiably, publicly burning some coins of a known-total-stock-issued currency is the same as "remurrage" (opposite of "demurrage" - it may not be a correct word, but it's a nice back-formation) on the remainder. That is, if there are verifiably 21 million issued-and-not-burned coins, and then you go to sleep and wake up later and there are now only 20 million issued-and-not-burned coins, that's the same as if some magic genie multiplied all wake-up-time nominal bitcoin figures by 21/20. Another way to see the identity of real effect would be to redefine "burning n bitcoins" to mean, not "sending n to an unspendable address", but rather "scattering" the n bitcoins, i.e. sending them to '''every existing''' [non-zero-balance] address, in proportion to the balance [sum of unspent txouts] already stored in each. This would be a horribly gigantic transaction to actually do explicitly, but the point is, burning can be thought of "as if" done that way. (Slogan: Quantity-deflation is remurrage in disguise, in exactly the same way that quantity-inflation is demurrage in disguise.)

So, what ''that'' means is, if while you're sleeping you (a non-miner) hold 1 bitcoin purely passively, i.e. it just sits undisturbed on the blockchain, well, when you wake up, it's as if you've received a "dividend" (of 5% in the particular numeric example above) on top of the general economy-tracking price we expect of a constant-quantity currency. In a world with actual, visibly performed remurrage, this is made explicit - your balance is now 21/20, with the nominal circulation [issued-and-not-burned, and remurraged for good measure] constant at 21 million. You can go and spend the 1/20 "dividend" on some treat, and still have the same fraction (1 out of 21 million) of the money stock as when you went to sleep.

In a world ''without'' any attempt at explicit remurrage, the real facts of the situation are (of course!) the same, but their nominal expression is not perhaps so instantly obvious. Your nominal holding is unchanged at 1; but this is now 1 part in 20 million of the whole money stock, not the 1 part in 21 million it was before. So, you can go and spend 1/21 of it on some treat, taking your nominal balance down to 20/21, and ''that'' nominal balance is the same (1 out of 21 million) fraction of the money stock as when you went to sleep.

So, basically, if you're holding bitcoins and trying to hold an "economy-tracking amount", no more and no less, you find you can go out into the market and use the fraction of your holdings that counts as "dividend above and beyond economy-tracking" on some treat or other. (Indeed, "you can go out..." should read "you ''must'' go out...", if you're really determined to pursue precisely that tracking strategy.)

Who's selling you the real resources embodied in the "treat"? And what's ''their'' motive? Well, transaction fee payers presumably like to re-stock their bitcoin real balances to roughly the same [economy-tracking] level as before, on average - they're paying for the fee processing as a service. These fees are then burned by miners. (Well, not literally the fees themselves - the fees themselves are ''collected'' by miners, but the way they achieve this is to burn an approximately equal amount, as explained earlier.) So, ordinary Bitcoin users, to achieve their desired re-stocking, have to either produce slightly more, or consume slightly less, or a proper or improper mixture thereof, than they would have needed to in a hypothetical (presumably impracticable) alternative world where they pay no fees for their everyday transactions (and some magic mining-god just altruistically and reliably creates a blockchain out of all the transactions, without charging anybody anything). [This follows directly from their re-stocking desire, and has nothing to do with proof-of-burn specifically. That is, they have to do this regardless of whether the protocol is proof-of-work, proof-of-stake, proof-of-burn or whatever.] It's that extra gap between production and consumption - "extra" on top of whatever gap people are already choosing as a real saving[/dis-saving] strategy - that goes on to the market, for you and all other bitcoin holders to bid off the market by spending on your "treat".

This whole stable pattern of spending habits is, perhaps surprisingly, the same pattern of real resource allocation as would have happened if Cunicula's proof of stake (with close to 100% stake / 0% work admixture) had been in operation, and all bitcoin holders, large and small, had enthusiastically thrown their bitcoins (that is, their stream of bitcoin days destroyed) into the stake-claiming process. The fraction of fees they'd collect if they did that would be just like the "dividend" as I called it above - it would be like explicit remurrage, except instead of being automatic, it would require each holder's active participation (i.e. they couldn't just go to sleep, unless they left some sort of "trusted bot" running and using their private keys to sign their stream of bitcoin days destroyed). So, if you like, proof-of-burn is like automated, 100%-stakeholder-participation Cunicula-style proof-of-stake!

Proof of burn

2012-12-16T22:00:27Z

Ids: /* Economic implications */ previous edit was minor, creating this subsection: this edit fills in this subsection

Proof of burn

2012-12-16T21:54:59Z

Ids: /* Iain Stewart's version of proof of burn */

Proof of burn

2012-12-16T21:50:27Z

Ids: /* Iain Stewart's version of proof of burn */ made introduction and motivation into a subsection

Proof of burn

2012-12-16T21:46:58Z

Ids: /* Iain Stewart's version of proof of burn */ initial motivating discussion, leading up to header for "burnt coins are mining rigs" technical sketch

Proof of burn

2012-12-16T21:29:23Z

Ids: an initial few sentences, really just announcing the page is going to be worked on

Proof of blockchain fair sharing

2012-12-02T19:04:30Z

Ids: /* (The quoted forum post...) */ shadowed wording tweak in forum original

Adaptive difficulty

2012-11-25T02:51:07Z

Ids: capitalisation of Bitcoin when it means the system as a whole

'''Adaptive difficulty''' is a Bitcoin protocol change proposal by [[User:Ids|Iain Stewart]], with the goal of letting the typical time interval from one block to the next adjust smoothly to prevailing network latency, while not compromising the strength of the blockchain, or the decentralized character of the network.

'''''EDIT 2012-11-22:''' My idea is essentially the same as that proposed by [http://en.wikipedia.org/wiki/User:Meni_Rosenfeld Meni Rosenfeld] on the [https://bitcointalk.org/index.php?board=6.0 Bitcoin forums]. Please read and enjoy and critique [https://bitcointalk.org/index.php?topic=79837.0 his adaptive difficulty proposal]! (I'll leave this page here for historical completeness, but not continue working on it.) [[User:Ids|Iain Stewart]] 01:00, 23 November 2012 (GMT)''

== Background ==

The world is being wired up with ever faster connectivity. A merchant location in particular, where any kind of online transaction is desired, will usually have a fast link to either the net or specific counterparty bank(s), with paid-for higher bandwidth and lower latency than the usual domestic speeds. All but the smallest businesses where an internet presence is de rigeur now routinely choose to pay for a fast connection, sometimes choosing to pay a little extra for a guarantee of quick repair ("five nines" cover and the like).

It will therefore remain an expectation of customers that a merchant can process their transaction quickly as a matter of course. (With Bitcoin, we do have the sub-community of users who desire strong anonymity and may use Tor/i2p, coin mixing services, and the like. They are tech-savvy and accept that these choices cause slowness. We can't expect that to become the broader expectation, however.)

The average 10-minute interval between blocks, and the need to wait a few blocks (6 is often cited) to achieve acceptable closeness to irreversibility of one's transaction, will likely be a barrier to ease of use in cases where an expectation of speed is firmly embedded in customers' and merchants' culture. (Even people who choose to slow down the ''submission'' of their transaction, in exchange for better anonymity for example, would still benefit from fast ''handling'' of their transaction once it has been submitted. They too may well grumble at the tens of minutes' to hours' delay on top of that of their own choosing.)

The 10-minute target interval could of course be changed, by sufficient consensus among miners and the community, to some other fixed value. Miners could boldly assert that the network latency between them "has reliably been such-and-such" (likely pleasantly short, since serious miners with their ASICs or whatever would want to pay for a fast net connection like any other net-centric business); and they could propose some multiple of this as a block interval. A change from one fixed value to another has its problems, though. A danger of choosing too short a value is that the network (of miners) fragments, into clusters who wastefully work on what they each sincerely believe is the most up-to-date block, and only later collectively purges the proliferation of short chains. The community's justified fear of this scenario would likely mean any future fixed target interval would always have to err on the side of caution (slowness).

But why have a ''fixed'' value at all? Can a protocol be fashioned where miners discover ''dynamically'' the interval that's in some sense the "best" choice, given the prevailing network latency between them? Such a protocol would have to avoid perverse incentives for any individual miner to influence the discovery process in a way that was good for that miner, but bad for the security of the blockchain.

One could imagine all sorts of formulae for deciding which way difficulty "should" go on a very fine scale (even from one block to the next) - whether similar or not-so-similar to the fortnightly difficulty adjustment already in place. The fortnightly (2016-block) adjustment is of course intended as a regulator of the impact of ''gradual'' network-wide growth or shrinkage of ''hash-rate'', and not of ''moment-to-moment'' network ''latency'' (or of moment-to-moment anything else for that matter). But one could imagine similar attempts to measure, and adjust to, latency changes, by some clever formula.

Adaptive difficulty is '''not''' an attempt at such a formula. There are good grounds for believing that the (or a candidate) block''chain'' - as opposed to the block''tree'' held at any instant by any particular miner - simply cannot contain enough information to assist with latency discovery. Only the tree, and not any one chain, contains the kind of evidence that could assist with noticing the sort of wasteful fragmentation discussed above, for example. But to compute a network-influencing parameter according to the properties of a whole blocktree, and then embed it in any one would-be winning blockchain, would be dangerous. Even ignoring the fact that the blocktree differs from miner to miner, there would be no way, later, when the rest of the tree had died by neglect, to verify that the information embedded in the winning blockchain was correctly computed from a tree prevailing at the time - and not, for example, just made up by an attacker, who can later create a spurious tree (with false timestamps), at leisure, with bits and pieces dangling off various winning-chain blocks in whatever style it takes to make the attacker's made-up information ''seem'' to have been computed from that spurious tree.

What adaptive difficulty '''is''', is something more radical than any such formula: a scheme where miners ''choose'', and announce in the header, the difficulty of ''every block they proceed to try to solve''. To those despairing that such anarchy could ever work, please read on! The regulatory function of the network - the assurance that it converges on a consensus best chain, with good immunity from attacks other than a 51% attack - is achieved by other aspects of the protocol. Out of anarchy, order will emerge.

== Anarchy in the blockchain ==

Some general remarks first. The proof of work measure of a blockchain is its sum of difficulties, not its mere number of blocks. (The expected work cost of solving two blocks of difficulty ''d'' is the same as that of solving one block of difficulty 2''d''.) If, for example, generally prevailing difficulty is halved (by whatever means), the network will solve blocks of the new difficulty at twice the previous rate; and the average value of transaction fees available for reaping in the latest block will be halved. (The adaptive difficulty protocol will scale the coin-minting block reward to the difficulty too.) A chain of such new, cheaper blocks will grow at the same expected speed ''in sum-of-difficulty terms'' as ever; it is just the ''style'' of growth which will be different (twice as many blocks, of half the difficulty and average miner reward each). The economics of block solving will change in two, mutually cancelling, ways from a miner's perspective: each hash has twice the probability of solving a block, but the reward has halved. Miners should thus be broadly indifferent (ignoring network latency issues for now) to difficulty changes in either direction, so long as they are done in that reward-scaling style.

(.....''got to here''.....)

''(uh, and now a pause folks, while I slowly learn "everything I never wanted to know about how to type in mathematical notation to a wiki but have been forced to find out"!)''

== ''...and now for something completely different! (unpolished teaser for now...)'' ==

''(Just to explain - I'm neglecting this adaptive difficulty stuff for a while [sorry!] because I '''seem''' to have almost accidentally invented [the bare beginnings of] a different system which protects against even a '''considerably-greater-than-50% attack'''! I don't want to create a page on it just yet before I thoroughly check that I'm not making a fool of myself... [well, I'll allow myself a stub, as a home for this teaser stuff: "[[Proof_of_blockchain_fair_sharing|proof of blockchain fair sharing]]"] ...but as a teaser description: it's of proof-of-stake flavour [which makes me nervous in some ways, but that's another story], and it relies on the fact that stakeholders are '''pseudonymously trackable''', unlike proof-of-work contributors, and therefore a formula for blockchain height can reward '''closeness to fair-share proportions''' in such a way that a 90% attacker finds they can't stop the honest 10% contributing too-expensive-for-attacker-to-reverse blocks which, to the attacker's chagrin, '''incorporate''' the accumulated transactions the attacker has been endlessly reversing and re-excluding in an effort to ruin the credibility of Bitcoin. [And any change to the attacker's pseudonymous identity/identities destroys their bitcoin-days' stake and takes them out of the running as a big attacker for a long time.] - More to follow real soon now hopefully!)''

''(To expand a little on the above teaser: One might think that by reductio ad absurdum '''no''' system can protect against a >50% attack, because in a purported proof of immunity of the honest <50% from the malicious >50%, the labels "honest" and "malicious" ultimately have no technical meaning, and so just swapping the labels would, absurdly, give a second proof, saying that the <50% community can't "attack" [i.e. save us all from] the >50% community, in contradiction to the first proof. That reductio argument is false here - '''there is an asymmetry''' between the two communities' goals, as follows. [I'm talking about an attack to destroy the usability of Bitcoin. An attack to achieve double spending is a much lower-impact event, the analysis of which I'm therefore postponing, although on general grounds the situation is probably neither especially better nor worse than with other protocols.] The >50% "community" [the attacker(s)] is trying to exclude transactions - perhaps all of them, perhaps those of specific people it wants to harass, perhaps random ones just to create fear that "I could be next" - from entering the winning blockchain. Thus it has to achieve '''total''' exclusion of the would-be blocks originating from the <50% community, who keep including the transactions to try and earn an honest profit from the fees. By contrast, the <50% community [the just-trying-to-earn-a-living honest miners] '''doesn't''' have to achieve exclusion of the attacker's blocks - they're happy with a mixed blockchain where, reasonably often, another honest block gets in and stays in. So long as they can get transactions bedded down into the blockchain, they've avoided the ruining of Bitcoin as a usable system. It's this crucial asymmetry between the two communities which lets the honest miners win - a chain height formula which suitably rewards diversity of pseudonymous composition will stop even a 90% attacker "community" from achieving its, tougher, goal. I hope this indicates the general direction I'm headed. [[User:Ids|Iain Stewart]] 02:15, 21 May 2012 (GMT))''

User:Ids

2012-11-25T02:47:55Z

Ids: capitalisation of Bitcoin when it means the system as a whole

Proof of blockchain fair sharing

2012-11-25T02:46:22Z

Ids: capitalisation of Bitcoin when it means the system as a whole

'''Proof of blockchain fair sharing''' is a draft Bitcoin protocol change proposal by [[User:Ids|Iain Stewart]], with the goal of allowing the network to continue to settle on a sensible consensus blockchain ''even when subject to a considerably-greater-than-50% attack''.

The protocol is under construction. The following description is a "teaser", establishing its basic flavour and sketching how it exploits an asymmetry in the goals of the honest (<50%) and malicious (>50%) miners to avoid the usual reductio ad absurdum argument against ''any'' protocol surviving a >50% attack.

== Teaser description ==

''Iain Stewart writes:'' Proof of blockchain fair sharing is of proof-of-stake flavour (which makes me nervous in some ways, but that's another story), and it relies on the fact that stakeholders are '''pseudonymously trackable''', unlike proof-of-work contributors, and therefore a formula for blockchain height can reward '''closeness to fair-share proportions''' in such a way that a 90% attacker finds they can't stop the honest 10% contributing too-expensive-for-the-attacker-to-reverse blocks which, to the attacker's chagrin, '''incorporate''' the accumulated transactions the attacker has been endlessly reversing and re-excluding in an effort to ruin the credibility of Bitcoin. (And any change to the attacker's pseudonymous identity/identities destroys their bitcoin-days' stake and takes them out of the running as a big attacker for a long time.)

To expand a little on the above teaser: One might think that by reductio ad absurdum '''no''' system can protect against a >50% attack, because in a purported proof of immunity of the honest <50% from the malicious >50%, the labels "honest" and "malicious" ultimately have no technical meaning, and so just swapping the labels would, absurdly, give a second proof, saying that the <50% community can't "attack" (i.e. save us all from) the >50% community, in contradiction to the first proof. That reductio argument is false here - '''there is an asymmetry''' between the two communities' goals, as follows. (I'm talking about an attack to destroy the usability of Bitcoin. An attack to achieve [[Double-spending|double spending]] is a much lower-impact event, the analysis of which I'm therefore postponing, although on general grounds the situation is probably neither especially better nor worse than with other protocols.) The >50% "community" [the attacker(s)] is trying to exclude transactions - perhaps all of them, perhaps those of specific people it wants to harass, perhaps random ones just to create fear that "I could be next" - from entering the winning blockchain. Thus it has to achieve '''total''' exclusion of the would-be blocks originating from the <50% community, who keep including the transactions to try and earn an honest profit from the fees. By contrast, the <50% community [the just-trying-to-earn-a-living honest miners] '''doesn't''' have to achieve exclusion of the attacker's blocks - they're happy with a mixed blockchain where, reasonably often, another honest block gets in and stays in. So long as they can get transactions bedded down into the blockchain, they've avoided the ruining of Bitcoin as a usable system. It's this crucial asymmetry between the two communities which lets the honest miners win - a chain height formula which suitably rewards diversity of pseudonymous composition will stop even a 90% attacker "community" from achieving its, tougher, goal. I hope this indicates the general direction I'm headed. [[User:Ids|Iain Stewart]] 11:15, 21 May 2012 (GMT)

=== A more discursive description, but still of a "teaser" nature... ===

''Iain Stewart writes:'' I contributed a more discursive description of the proof of blockchain fair sharing idea, though still ultimately of a "teaser" nature (sorry!), to the [https://en.bitcoin.it/wiki/Talk:Proof_of_Stake proof of stake talk page]. That talk page has since moved on to other things; but you can find my contribution [https://en.bitcoin.it/w/index.php?title=Talk:Proof_of_Stake&oldid=29541 in its archive], namely, the gloriously-named "'''''Proof of stake - done right - is maybe, just maybe, the way to eliminate 51% (even 90%!) attack worries altogether!'''''" section thereof. Enjoy! [[User:Ids|Iain Stewart]] 23:18, 24 November 2012 (GMT)

== Broader approaches to the >50% attack problem ==

''Iain Stewart writes:'' I apologise for the unfinished state of the above teaser description. It's a hard problem, and it may even be impossible in its "pure" form, without help from fallible heuristics and the like.

In the spirit of exploring broader approaches with rough-and-ready fallible heuristics, I reproduce below [https://bitcointalk.org/index.php?topic=125822.msg1352625#msg1352625 my forum post] about how a cryptocurrency might resist a >50% attack from (in Cunicula's opening post's example) a central bank. It's not fair sharing as defined above - but maybe it doesn't need to be. [[User:Ids|Iain Stewart]] 08:45, 23 November 2012 (GMT)

=== (The quoted forum post...) ===

Well! [https://bitcointalk.org/index.php?topic=125822.0 This thread] has certainly got us all thinking about the robustness or lack thereof of various cryptocurrency designs! [https://bitcointalk.org/index.php?topic=125822.msg1341095#msg1341095 Cunicula's opening post] paints (possibly provocatively or tongue-in-cheek?) a central bank's hypothetical successful 51% attack as a good thing. I think most of us on this forum would disagree. We want our cryptocurrency to '''stop''' any would-be central bank / central planner from saying "you can only spend your coins in a style approved by our macroeconomic policies". (In just the same way as we want it to '''stop''' a present or future PayPal from saying "you can only buy what we think you ought to buy, and donate to who we think you ought to donate to". - Or, more precisely, they can say it, but we can reply "we don't need you any more".)

That's what we want. How do we get it?

For attacks falling short of 51%, there's some mileage to be had in changing the "proof-of-..." choice from one thing to another. Proof-of-work, proof-of-stake, proof-of-activity... they all have interesting advantages and disadvantages and are all debated vigorously in various corners of this forum. Indeed, I'm planning to add to the list myself real soon now, with something I call "proof-of-burn". But they all crumple under a 51% attack. (That includes my proof-of-burn too! It's not immune!) So, when facing an adversary wealthy enough to acquire and use 51% of ''whichever'' "proof-of..." resource is being measured by the network - hashing work, stake, burn rate, signature activity, you name it - we need new techniques to stand up to such an attacker.

I think the good news here is that a 51% attacker's chain has to behave '''visibly strangely''' when excluding "technically fully sensible but politically unapproved" transactions, such as the "no, I'm not going to pay your coin-year-demurrage level of fees!" transactions Cunicula's example central bank would like to exclude. Such transactions sit in every node's memory pool. Then, every time any such transaction gets into a block (mined by an honest miner who's perfectly happy with its "ordinary" competitive-mining-market-clearing level of fee), the winning chain always ends up building on the ''previous'' block, orphaning the honest block and orphaning the transaction back into the memory pool. Whereas, every time ''no'' such transactions get into a block, the winning chain always ends up building on ''that'' block - it being a block produced by the 51% attacker (or by an honest miner who happens to have inadvertently followed the attacker's policy by happening not to have included those transactions for whatever mundane reason).

This behaviour is visibly strange in a statistical sense. It may not seem strange the first time, or the second time, or the tenth time, but as the politically-unapproved transactions hop in and out of everyone's memory pool more and more often, it becomes ever more absurd to ascribe their exclusion to bad luck.

(Contrast this with an attack whose motive is double-spending, rather than political control of the cryptocurrency. In the double-spending scenario, the network has no real opinion about which of the incompatible transactions ''ought'' to succeed and which ought to fail. An attacker can choose whichever one profits them and hurts the recipients[-until-later-reversed] of its double-spending sibling(s). Recipients just have to learn to wait long enough that ''even the attacker'' loses interest in further reversing their own chain - their own reversal-attack upon some earlier apparently winning chain - to that block-depth extent. But in the transaction-excluding scenario, the network's honest users '''do''' have an opinion about which ''treatment'' of the ''single'' [no double-spending siblings] transaction ought to succeed and which ought to fail. Namely: the transaction's ''presence'' is what ought to succeed, and its ''absence'' is what ought to fail!)

This visibly strange behaviour opens up the possibility of a "heuristic defence". I'm certainly not claiming I have such a defence in polished form ready to implement; but in broad outline, nodes would try to compute a "probability (or plausibility) rating" for each new block they encounter. How long has an in-again-out-again transaction been in (and out and in...) my memory pool? What fraction of my network neighbours agree it's been stuck like this for ages? (And recursively, can they report the statistics of ''their'' neighbours' opinions, in cheap aggregated form?) If it's ever more obvious that essentially the whole network knows about it, it becomes ever more ridiculous (exponentially so, I'd suspect) to believe that a whole sequence of miners can have not heard of it. Even more so, since it was sitting there inside ''an expensive object to produce'' - namely, a later-to-be-orphaned block produced by an honest miner - and a thousand websites could spring up, listing (unfakeably! the orphaned blocks are expensive things to produce!) all the transactions therein that are compatible with, but mysteriously excluded for ages by, the current winning chain.

The naive height-strength (difficulty or its proof-of-whatever equivalent) of a block would then be multiplied by that probability or plausibility rating, and it would be the sum of such ''plausibility-adjusted'' height-strengths, not the sum of the naive strengths, which would be used to judge a winning chain.

Yes, this does have the danger that different nodes would compute somewhat different plausibility ratings to multiply naive strengths by; and network consensus convergence could be placed in jeopardy if their opinions were too divergent. So, one would not want to be ''too'' eager to deprecate a block by a large factor. Still, in really extreme cases (say down into one-in-a-million territory for a transaction to have been excluded by bad luck - the power of exponential shrinkage means we get down there quite fast!), a sizeable deprecation becomes sensible (e.g. if we deprecate by the sixth root of plausibility, the attacker's blocks are deprecated by a factor of 10 in the one-in-a-million example - enough that 10% honest miners win out over a 90% attacker).

So... '''there's hope for us yet!''' Even with a billionaire central bank as adversary!

(A final note: who's running those "thousand websites" [or tor-sites... whatever] listing the suspiciously excluded transactions? Well, anyone can set one up; and serious, big full nodes, such as those run by serious professional miners, should be eager to subscribe to such sites, for a microtransaction or subscription or the like if necessary. After all, if you're a miner, and you know that ''other'' nodes are going to deprecate ''your'' block if you don't make an effort to include that gaggle of suspiciously excluded transactions, that's a powerful incentive to keep yourself up to date with the general state of play! - And yes, we should of course aim for ''the network itself'' to achieve such functionality, without external sites' involvement. Perhaps nodes could report to their neighbours a standardised-mathematical-language ''set of reasons'' why they attached such-and-such a deprecation factor to such-and-such a block? The challenge would be to handle one's neighbours' reasons-descriptions in a way that, while stopping short of naive slavish agreement therewith, still encourages a helpful consensus to emerge.)

<big>'''(end of quoted forum post)'''</big>

Proof of blockchain fair sharing

2012-11-25T02:33:49Z

Ids: /* (The quoted forum post...) */ shadowed spelling correction in forum original

'''Proof of blockchain fair sharing''' is a draft bitcoin protocol change proposal by [[User:Ids|Iain Stewart]], with the goal of allowing the network to continue to settle on a sensible consensus blockchain ''even when subject to a considerably-greater-than-50% attack''.

The protocol is under construction. The following description is a "teaser", establishing its basic flavour and sketching how it exploits an asymmetry in the goals of the honest (<50%) and malicious (>50%) miners to avoid the usual reductio ad absurdum argument against ''any'' protocol surviving a >50% attack.

== Teaser description ==

''Iain Stewart writes:'' Proof of blockchain fair sharing is of proof-of-stake flavour (which makes me nervous in some ways, but that's another story), and it relies on the fact that stakeholders are '''pseudonymously trackable''', unlike proof-of-work contributors, and therefore a formula for blockchain height can reward '''closeness to fair-share proportions''' in such a way that a 90% attacker finds they can't stop the honest 10% contributing too-expensive-for-the-attacker-to-reverse blocks which, to the attacker's chagrin, '''incorporate''' the accumulated transactions the attacker has been endlessly reversing and re-excluding in an effort to ruin the credibility of bitcoin. (And any change to the attacker's pseudonymous identity/identities destroys their bitcoin-days' stake and takes them out of the running as a big attacker for a long time.)

To expand a little on the above teaser: One might think that by reductio ad absurdum '''no''' system can protect against a >50% attack, because in a purported proof of immunity of the honest <50% from the malicious >50%, the labels "honest" and "malicious" ultimately have no technical meaning, and so just swapping the labels would, absurdly, give a second proof, saying that the <50% community can't "attack" (i.e. save us all from) the >50% community, in contradiction to the first proof. That reductio argument is false here - '''there is an asymmetry''' between the two communities' goals, as follows. (I'm talking about an attack to destroy the usability of bitcoin. An attack to achieve [[Double-spending|double spending]] is a much lower-impact event, the analysis of which I'm therefore postponing, although on general grounds the situation is probably neither especially better nor worse than with other protocols.) The >50% "community" [the attacker(s)] is trying to exclude transactions - perhaps all of them, perhaps those of specific people it wants to harass, perhaps random ones just to create fear that "I could be next" - from entering the winning blockchain. Thus it has to achieve '''total''' exclusion of the would-be blocks originating from the <50% community, who keep including the transactions to try and earn an honest profit from the fees. By contrast, the <50% community [the just-trying-to-earn-a-living honest miners] '''doesn't''' have to achieve exclusion of the attacker's blocks - they're happy with a mixed blockchain where, reasonably often, another honest block gets in and stays in. So long as they can get transactions bedded down into the blockchain, they've avoided the ruining of bitcoin as a usable system. It's this crucial asymmetry between the two communities which lets the honest miners win - a chain height formula which suitably rewards diversity of pseudonymous composition will stop even a 90% attacker "community" from achieving its, tougher, goal. I hope this indicates the general direction I'm headed. [[User:Ids|Iain Stewart]] 11:15, 21 May 2012 (GMT)

=== A more discursive description, but still of a "teaser" nature... ===

''Iain Stewart writes:'' I contributed a more discursive description of the proof of blockchain fair sharing idea, though still ultimately of a "teaser" nature (sorry!), to the [https://en.bitcoin.it/wiki/Talk:Proof_of_Stake proof of stake talk page]. That talk page has since moved on to other things; but you can find my contribution [https://en.bitcoin.it/w/index.php?title=Talk:Proof_of_Stake&oldid=29541 in its archive], namely, the gloriously-named "'''''Proof of stake - done right - is maybe, just maybe, the way to eliminate 51% (even 90%!) attack worries altogether!'''''" section thereof. Enjoy! [[User:Ids|Iain Stewart]] 23:18, 24 November 2012 (GMT)

== Broader approaches to the >50% attack problem ==

''Iain Stewart writes:'' I apologise for the unfinished state of the above teaser description. It's a hard problem, and it may even be impossible in its "pure" form, without help from fallible heuristics and the like.

In the spirit of exploring broader approaches with rough-and-ready fallible heuristics, I reproduce below [https://bitcointalk.org/index.php?topic=125822.msg1352625#msg1352625 my forum post] about how a cryptocurrency might resist a >50% attack from (in Cunicula's opening post's example) a central bank. It's not fair sharing as defined above - but maybe it doesn't need to be. [[User:Ids|Iain Stewart]] 08:45, 23 November 2012 (GMT)

=== (The quoted forum post...) ===

Well! [https://bitcointalk.org/index.php?topic=125822.0 This thread] has certainly got us all thinking about the robustness or lack thereof of various cryptocurrency designs! [https://bitcointalk.org/index.php?topic=125822.msg1341095#msg1341095 Cunicula's opening post] paints (possibly provocatively or tongue-in-cheek?) a central bank's hypothetical successful 51% attack as a good thing. I think most of us on this forum would disagree. We want our cryptocurrency to '''stop''' any would-be central bank / central planner from saying "you can only spend your coins in a style approved by our macroeconomic policies". (In just the same way as we want it to '''stop''' a present or future PayPal from saying "you can only buy what we think you ought to buy, and donate to who we think you ought to donate to". - Or, more precisely, they can say it, but we can reply "we don't need you any more".)

That's what we want. How do we get it?

For attacks falling short of 51%, there's some mileage to be had in changing the "proof-of-..." choice from one thing to another. Proof-of-work, proof-of-stake, proof-of-activity... they all have interesting advantages and disadvantages and are all debated vigorously in various corners of this forum. Indeed, I'm planning to add to the list myself real soon now, with something I call "proof-of-burn". But they all crumple under a 51% attack. (That includes my proof-of-burn too! It's not immune!) So, when facing an adversary wealthy enough to acquire and use 51% of ''whichever'' "proof-of..." resource is being measured by the network - hashing work, stake, burn rate, signature activity, you name it - we need new techniques to stand up to such an attacker.

I think the good news here is that a 51% attacker's chain has to behave '''visibly strangely''' when excluding "technically fully sensible but politically unapproved" transactions, such as the "no, I'm not going to pay your coin-year-demurrage level of fees!" transactions Cunicula's example central bank would like to exclude. Such transactions sit in every node's memory pool. Then, every time any such transaction gets into a block (mined by an honest miner who's perfectly happy with its "ordinary" competitive-mining-market-clearing level of fee), the winning chain always ends up building on the ''previous'' block, orphaning the honest block and orphaning the transaction back into the memory pool. Whereas, every time ''no'' such transactions get into a block, the winning chain always ends up building on ''that'' block - it being a block produced by the 51% attacker (or by an honest miner who happens to have inadvertently followed the attacker's policy by happening not to have included those transactions for whatever mundane reason).

This behaviour is visibly strange in a statistical sense. It may not seem strange the first time, or the second time, or the tenth time, but as the politically-unapproved transactions hop in and out of everyone's memory pool more and more often, it becomes ever more absurd to ascribe their exclusion to bad luck.

(Contrast this with an attack whose motive is double-spending, rather than political control of the cryptocurrency. In the double-spending scenario, the network has no real opinion about which of the incompatible transactions ''ought'' to succeed and which ought to fail. An attacker can choose whichever one profits them and hurts the recipients[-until-later-reversed] of its double-spending sibling(s). Recipients just have to learn to wait long enough that ''even the attacker'' loses interest in further reversing their own chain - their own reversal-attack upon some earlier apparently winning chain - to that block-depth extent. But in the transaction-excluding scenario, the network's honest users '''do''' have an opinion about which ''treatment'' of the ''single'' [no double-spending siblings] transaction ought to succeed and which ought to fail. Namely: the transaction's ''presence'' is what ought to succeed, and its ''absence'' is what ought to fail!)

This visibly strange behaviour opens up the possibility of a "heuristic defence". I'm certainly not claiming I have such a defence in polished form ready to implement; but in broad outline, nodes would try to compute a "probability (or plausibility) rating" for each new block they encounter. How long has an in-again-out-again transaction been in (and out and in...) my memory pool? What fraction of my network neighbours agree it's been stuck like this for ages? (And recursively, can they report the statistics of ''their'' neighbours' opinions, in cheap aggregated form?) If it's ever more obvious that essentially the whole network knows about it, it becomes ever more ridiculous (exponentially so, I'd suspect) to believe that a whole sequence of miners can have not heard of it. Even more so, since it was sitting there inside ''an expensive object to produce'' - namely, a later-to-be-orphaned block produced by an honest miner - and a thousand websites could spring up, listing (unfakeably! the orphaned blocks are expensive things to produce!) all the transactions therein that are compatible with, but mysteriously excluded for ages by, the current winning chain.

The naive height-strength (difficulty or its proof-of-whatever equivalent) of a block would then be multiplied by that probability or plausibility rating, and it would be the sum of such ''plausibility-adjusted'' height-strengths, not the sum of the naive strengths, which would be used to judge a winning chain.

Yes, this does have the danger that different nodes would compute somewhat different plausibility ratings to multiply naive strengths by; and network consensus convergence could be placed in jeopardy if their opinions were too divergent. So, one would not want to be ''too'' eager to deprecate a block by a large factor. Still, in really extreme cases (say down into one-in-a-million territory for a transaction to have been excluded by bad luck - the power of exponential shrinkage means we get down there quite fast!), a sizeable deprecation becomes sensible (e.g. if we deprecate by the sixth root of plausibility, the attacker's blocks are deprecated by a factor of 10 in the one-in-a-million example - enough that 10% honest miners win out over a 90% attacker).

So... '''there's hope for us yet!''' Even with a billionaire central bank as adversary!

(A final note: who's running those "thousand websites" [or tor-sites... whatever] listing the suspiciously excluded transactions? Well, anyone can set one up; and serious, big full nodes, such as those run by serious professional miners, should be eager to subscribe to such sites, for a microtransaction or subscription or the like if necessary. After all, if you're a miner, and you know that ''other'' nodes are going to deprecate ''your'' block if you don't make an effort to include that gaggle of suspiciously excluded transactions, that's a powerful incentive to keep yourself up to date with the general state of play! - And yes, we should of course aim for ''the network itself'' to achieve such functionality, without external sites' involvement. Perhaps nodes could report to their neighbours a standardised-mathematical-language ''set of reasons'' why they attached such-and-such a deprecation factor to such-and-such a block? The challenge would be to handle one's neighbours' reasons-descriptions in a way that, while stopping short of naive slavish agreement therewith, still encourages a helpful consensus to emerge.)

<big>'''(end of quoted forum post)'''</big>

Proof of blockchain fair sharing

2012-11-24T23:18:38Z

Ids: /* Teaser description */ added link to my more discursive description (in proof of stake talk page archive)

'''Proof of blockchain fair sharing''' is a draft bitcoin protocol change proposal by [[User:Ids|Iain Stewart]], with the goal of allowing the network to continue to settle on a sensible consensus blockchain ''even when subject to a considerably-greater-than-50% attack''.

The protocol is under construction. The following description is a "teaser", establishing its basic flavour and sketching how it exploits an asymmetry in the goals of the honest (<50%) and malicious (>50%) miners to avoid the usual reductio ad absurdum argument against ''any'' protocol surviving a >50% attack.

== Teaser description ==

''Iain Stewart writes:'' Proof of blockchain fair sharing is of proof-of-stake flavour (which makes me nervous in some ways, but that's another story), and it relies on the fact that stakeholders are '''pseudonymously trackable''', unlike proof-of-work contributors, and therefore a formula for blockchain height can reward '''closeness to fair-share proportions''' in such a way that a 90% attacker finds they can't stop the honest 10% contributing too-expensive-for-the-attacker-to-reverse blocks which, to the attacker's chagrin, '''incorporate''' the accumulated transactions the attacker has been endlessly reversing and re-excluding in an effort to ruin the credibility of bitcoin. (And any change to the attacker's pseudonymous identity/identities destroys their bitcoin-days' stake and takes them out of the running as a big attacker for a long time.)

To expand a little on the above teaser: One might think that by reductio ad absurdum '''no''' system can protect against a >50% attack, because in a purported proof of immunity of the honest <50% from the malicious >50%, the labels "honest" and "malicious" ultimately have no technical meaning, and so just swapping the labels would, absurdly, give a second proof, saying that the <50% community can't "attack" (i.e. save us all from) the >50% community, in contradiction to the first proof. That reductio argument is false here - '''there is an asymmetry''' between the two communities' goals, as follows. (I'm talking about an attack to destroy the usability of bitcoin. An attack to achieve [[Double-spending|double spending]] is a much lower-impact event, the analysis of which I'm therefore postponing, although on general grounds the situation is probably neither especially better nor worse than with other protocols.) The >50% "community" [the attacker(s)] is trying to exclude transactions - perhaps all of them, perhaps those of specific people it wants to harass, perhaps random ones just to create fear that "I could be next" - from entering the winning blockchain. Thus it has to achieve '''total''' exclusion of the would-be blocks originating from the <50% community, who keep including the transactions to try and earn an honest profit from the fees. By contrast, the <50% community [the just-trying-to-earn-a-living honest miners] '''doesn't''' have to achieve exclusion of the attacker's blocks - they're happy with a mixed blockchain where, reasonably often, another honest block gets in and stays in. So long as they can get transactions bedded down into the blockchain, they've avoided the ruining of bitcoin as a usable system. It's this crucial asymmetry between the two communities which lets the honest miners win - a chain height formula which suitably rewards diversity of pseudonymous composition will stop even a 90% attacker "community" from achieving its, tougher, goal. I hope this indicates the general direction I'm headed. [[User:Ids|Iain Stewart]] 11:15, 21 May 2012 (GMT)

=== A more discursive description, but still of a "teaser" nature... ===

''Iain Stewart writes:'' I contributed a more discursive description of the proof of blockchain fair sharing idea, though still ultimately of a "teaser" nature (sorry!), to the [https://en.bitcoin.it/wiki/Talk:Proof_of_Stake proof of stake talk page]. That talk page has since moved on to other things; but you can find my contribution [https://en.bitcoin.it/w/index.php?title=Talk:Proof_of_Stake&oldid=29541 in its archive], namely, the gloriously-named "'''''Proof of stake - done right - is maybe, just maybe, the way to eliminate 51% (even 90%!) attack worries altogether!'''''" section thereof. Enjoy! [[User:Ids|Iain Stewart]] 23:18, 24 November 2012 (GMT)

== Broader approaches to the >50% attack problem ==

''Iain Stewart writes:'' I apologise for the unfinished state of the above teaser description. It's a hard problem, and it may even be impossible in its "pure" form, without help from fallible heuristics and the like.

In the spirit of exploring broader approaches with rough-and-ready fallible heuristics, I reproduce below [https://bitcointalk.org/index.php?topic=125822.msg1352625#msg1352625 my forum post] about how a cryptocurrency might resist a >50% attack from (in Cunicula's opening post's example) a central bank. It's not fair sharing as defined above - but maybe it doesn't need to be. [[User:Ids|Iain Stewart]] 08:45, 23 November 2012 (GMT)

=== (The quoted forum post...) ===

Well! [https://bitcointalk.org/index.php?topic=125822.0 This thread] has certainly got us all thinking about the robustness or lack thereof of various cryptocurrency designs! [https://bitcointalk.org/index.php?topic=125822.msg1341095#msg1341095 Cunicula's opening post] paints (possibly provocatively or tongue-in-cheek?) a central bank's hypothetical successful 51% attack as a good thing. I think most of us on this forum would disagree. We want our cryptocurrency to '''stop''' any would-be central bank / central planner from saying "you can only spend your coins in a style approved by our macroeconomic policies". (In just the same way as we want it to '''stop''' a present or future PayPal from saying "you can only buy what we think you ought to buy, and donate to who we think you ought to donate to". - Or, more precisely, they can say it, but we can reply "we don't need you any more".)

That's what we want. How do we get it?

For attacks falling short of 51%, there's some mileage to be had in changing the "proof-of-..." choice from one thing to another. Proof-of-work, proof-of-stake, proof-of-activity... they all have interesting advantages and disadvantages and are all debated vigorously in various corners of this forum. Indeed, I'm planning to add to the list myself real soon now, with something I call "proof-of-burn". But they all crumple under a 51% attack. (That includes my proof-of-burn too! It's not immune!) So, when facing an adversary wealthy enough to acquire and use 51% of ''whichever'' "proof-of..." resource is being measured by the network - hashing work, stake, burn rate, signature activity, you name it - we need new techniques to stand up to such an attacker.

I think the good news here is that a 51% attacker's chain has to behave '''visibly strangely''' when excluding "technically fully sensible but politically unapproved" transactions, such as the "no, I'm not going to pay your coin-year-demurrage level of fees!" transactions Cunicula's example central bank would like to exclude. Such transactions sit in every node's memory pool. Then, every time any such transaction gets into a block (mined by an honest miner who's perfectly happy with its "ordinary" competitive-mining-market-clearing level of fee), the winning chain always ends up building on the ''previous'' block, orphaning the honest block and orphaning the transaction back into the memory pool. Whereas, every time ''no'' such transactions get into a block, the winning chain always ends up building on ''that'' block - it being a block produced by the 51% attacker (or by an honest miner who happens to have inadvertantly followed the attacker's policy by happening not to have included those transactions for whatever mundane reason).

This behaviour is visibly strange in a statistical sense. It may not seem strange the first time, or the second time, or the tenth time, but as the politically-unapproved transactions hop in and out of everyone's memory pool more and more often, it becomes ever more absurd to ascribe their exclusion to bad luck.

(Contrast this with an attack whose motive is double-spending, rather than political control of the cryptocurrency. In the double-spending scenario, the network has no real opinion about which of the incompatible transactions ''ought'' to succeed and which ought to fail. An attacker can choose whichever one profits them and hurts the recipients[-until-later-reversed] of its double-spending sibling(s). Recipients just have to learn to wait long enough that ''even the attacker'' loses interest in further reversing their own chain - their own reversal-attack upon some earlier apparently winning chain - to that block-depth extent. But in the transaction-excluding scenario, the network's honest users '''do''' have an opinion about which ''treatment'' of the ''single'' [no double-spending siblings] transaction ought to succeed and which ought to fail. Namely: the transaction's ''presence'' is what ought to succeed, and its ''absence'' is what ought to fail!)

This visibly strange behaviour opens up the possibility of a "heuristic defence". I'm certainly not claiming I have such a defence in polished form ready to implement; but in broad outline, nodes would try to compute a "probability (or plausibility) rating" for each new block they encounter. How long has an in-again-out-again transaction been in (and out and in...) my memory pool? What fraction of my network neighbours agree it's been stuck like this for ages? (And recursively, can they report the statistics of ''their'' neighbours' opinions, in cheap aggregated form?) If it's ever more obvious that essentially the whole network knows about it, it becomes ever more ridiculous (exponentially so, I'd suspect) to believe that a whole sequence of miners can have not heard of it. Even more so, since it was sitting there inside ''an expensive object to produce'' - namely, a later-to-be-orphaned block produced by an honest miner - and a thousand websites could spring up, listing (unfakeably! the orphaned blocks are expensive things to produce!) all the transactions therein that are compatible with, but mysteriously excluded for ages by, the current winning chain.

The naive height-strength (difficulty or its proof-of-whatever equivalent) of a block would then be multiplied by that probability or plausibility rating, and it would be the sum of such ''plausibility-adjusted'' height-strengths, not the sum of the naive strengths, which would be used to judge a winning chain.

Yes, this does have the danger that different nodes would compute somewhat different plausibility ratings to multiply naive strengths by; and network consensus convergence could be placed in jeopardy if their opinions were too divergent. So, one would not want to be ''too'' eager to deprecate a block by a large factor. Still, in really extreme cases (say down into one-in-a-million territory for a transaction to have been excluded by bad luck - the power of exponential shrinkage means we get down there quite fast!), a sizeable deprecation becomes sensible (e.g. if we deprecate by the sixth root of plausibility, the attacker's blocks are deprecated by a factor of 10 in the one-in-a-million example - enough that 10% honest miners win out over a 90% attacker).

So... '''there's hope for us yet!''' Even with a billionaire central bank as adversary!

(A final note: who's running those "thousand websites" [or tor-sites... whatever] listing the suspiciously excluded transactions? Well, anyone can set one up; and serious, big full nodes, such as those run by serious professional miners, should be eager to subscribe to such sites, for a microtransaction or subscription or the like if necessary. After all, if you're a miner, and you know that ''other'' nodes are going to deprecate ''your'' block if you don't make an effort to include that gaggle of suspiciously excluded transactions, that's a powerful incentive to keep yourself up to date with the general state of play! - And yes, we should of course aim for ''the network itself'' to achieve such functionality, without external sites' involvement. Perhaps nodes could report to their neighbours a standardised-mathematical-language ''set of reasons'' why they attached such-and-such a deprecation factor to such-and-such a block? The challenge would be to handle one's neighbours' reasons-descriptions in a way that, while stopping short of naive slavish agreement therewith, still encourages a helpful consensus to emerge.)

<big>'''(end of quoted forum post)'''</big>

Proof of blockchain fair sharing

2012-11-24T22:43:35Z

Ids: /* The forum post */ clearer highlighting that it's a quoted post, at start and end

'''Proof of blockchain fair sharing''' is a draft bitcoin protocol change proposal by [[User:Ids|Iain Stewart]], with the goal of allowing the network to continue to settle on a sensible consensus blockchain ''even when subject to a considerably-greater-than-50% attack''.

The protocol is under construction. The following description is a "teaser", establishing its basic flavour and sketching how it exploits an asymmetry in the goals of the honest (<50%) and malicious (>50%) miners to avoid the usual reductio ad absurdum argument against ''any'' protocol surviving a >50% attack.

== Teaser description ==

''Iain Stewart writes:'' Proof of blockchain fair sharing is of proof-of-stake flavour (which makes me nervous in some ways, but that's another story), and it relies on the fact that stakeholders are '''pseudonymously trackable''', unlike proof-of-work contributors, and therefore a formula for blockchain height can reward '''closeness to fair-share proportions''' in such a way that a 90% attacker finds they can't stop the honest 10% contributing too-expensive-for-the-attacker-to-reverse blocks which, to the attacker's chagrin, '''incorporate''' the accumulated transactions the attacker has been endlessly reversing and re-excluding in an effort to ruin the credibility of bitcoin. (And any change to the attacker's pseudonymous identity/identities destroys their bitcoin-days' stake and takes them out of the running as a big attacker for a long time.)

To expand a little on the above teaser: One might think that by reductio ad absurdum '''no''' system can protect against a >50% attack, because in a purported proof of immunity of the honest <50% from the malicious >50%, the labels "honest" and "malicious" ultimately have no technical meaning, and so just swapping the labels would, absurdly, give a second proof, saying that the <50% community can't "attack" (i.e. save us all from) the >50% community, in contradiction to the first proof. That reductio argument is false here - '''there is an asymmetry''' between the two communities' goals, as follows. (I'm talking about an attack to destroy the usability of bitcoin. An attack to achieve [[Double-spending|double spending]] is a much lower-impact event, the analysis of which I'm therefore postponing, although on general grounds the situation is probably neither especially better nor worse than with other protocols.) The >50% "community" [the attacker(s)] is trying to exclude transactions - perhaps all of them, perhaps those of specific people it wants to harass, perhaps random ones just to create fear that "I could be next" - from entering the winning blockchain. Thus it has to achieve '''total''' exclusion of the would-be blocks originating from the <50% community, who keep including the transactions to try and earn an honest profit from the fees. By contrast, the <50% community [the just-trying-to-earn-a-living honest miners] '''doesn't''' have to achieve exclusion of the attacker's blocks - they're happy with a mixed blockchain where, reasonably often, another honest block gets in and stays in. So long as they can get transactions bedded down into the blockchain, they've avoided the ruining of bitcoin as a usable system. It's this crucial asymmetry between the two communities which lets the honest miners win - a chain height formula which suitably rewards diversity of pseudonymous composition will stop even a 90% attacker "community" from achieving its, tougher, goal. I hope this indicates the general direction I'm headed. [[User:Ids|Iain Stewart]] 11:15, 21 May 2012 (GMT)

== Broader approaches to the >50% attack problem ==

''Iain Stewart writes:'' I apologise for the unfinished state of the above teaser description. It's a hard problem, and it may even be impossible in its "pure" form, without help from fallible heuristics and the like.

In the spirit of exploring broader approaches with rough-and-ready fallible heuristics, I reproduce below [https://bitcointalk.org/index.php?topic=125822.msg1352625#msg1352625 my forum post] about how a cryptocurrency might resist a >50% attack from (in Cunicula's opening post's example) a central bank. It's not fair sharing as defined above - but maybe it doesn't need to be. [[User:Ids|Iain Stewart]] 08:45, 23 November 2012 (GMT)

=== (The quoted forum post...) ===

Well! [https://bitcointalk.org/index.php?topic=125822.0 This thread] has certainly got us all thinking about the robustness or lack thereof of various cryptocurrency designs! [https://bitcointalk.org/index.php?topic=125822.msg1341095#msg1341095 Cunicula's opening post] paints (possibly provocatively or tongue-in-cheek?) a central bank's hypothetical successful 51% attack as a good thing. I think most of us on this forum would disagree. We want our cryptocurrency to '''stop''' any would-be central bank / central planner from saying "you can only spend your coins in a style approved by our macroeconomic policies". (In just the same way as we want it to '''stop''' a present or future PayPal from saying "you can only buy what we think you ought to buy, and donate to who we think you ought to donate to". - Or, more precisely, they can say it, but we can reply "we don't need you any more".)

That's what we want. How do we get it?

For attacks falling short of 51%, there's some mileage to be had in changing the "proof-of-..." choice from one thing to another. Proof-of-work, proof-of-stake, proof-of-activity... they all have interesting advantages and disadvantages and are all debated vigorously in various corners of this forum. Indeed, I'm planning to add to the list myself real soon now, with something I call "proof-of-burn". But they all crumple under a 51% attack. (That includes my proof-of-burn too! It's not immune!) So, when facing an adversary wealthy enough to acquire and use 51% of ''whichever'' "proof-of..." resource is being measured by the network - hashing work, stake, burn rate, signature activity, you name it - we need new techniques to stand up to such an attacker.

I think the good news here is that a 51% attacker's chain has to behave '''visibly strangely''' when excluding "technically fully sensible but politically unapproved" transactions, such as the "no, I'm not going to pay your coin-year-demurrage level of fees!" transactions Cunicula's example central bank would like to exclude. Such transactions sit in every node's memory pool. Then, every time any such transaction gets into a block (mined by an honest miner who's perfectly happy with its "ordinary" competitive-mining-market-clearing level of fee), the winning chain always ends up building on the ''previous'' block, orphaning the honest block and orphaning the transaction back into the memory pool. Whereas, every time ''no'' such transactions get into a block, the winning chain always ends up building on ''that'' block - it being a block produced by the 51% attacker (or by an honest miner who happens to have inadvertantly followed the attacker's policy by happening not to have included those transactions for whatever mundane reason).

This behaviour is visibly strange in a statistical sense. It may not seem strange the first time, or the second time, or the tenth time, but as the politically-unapproved transactions hop in and out of everyone's memory pool more and more often, it becomes ever more absurd to ascribe their exclusion to bad luck.

(Contrast this with an attack whose motive is double-spending, rather than political control of the cryptocurrency. In the double-spending scenario, the network has no real opinion about which of the incompatible transactions ''ought'' to succeed and which ought to fail. An attacker can choose whichever one profits them and hurts the recipients[-until-later-reversed] of its double-spending sibling(s). Recipients just have to learn to wait long enough that ''even the attacker'' loses interest in further reversing their own chain - their own reversal-attack upon some earlier apparently winning chain - to that block-depth extent. But in the transaction-excluding scenario, the network's honest users '''do''' have an opinion about which ''treatment'' of the ''single'' [no double-spending siblings] transaction ought to succeed and which ought to fail. Namely: the transaction's ''presence'' is what ought to succeed, and its ''absence'' is what ought to fail!)

This visibly strange behaviour opens up the possibility of a "heuristic defence". I'm certainly not claiming I have such a defence in polished form ready to implement; but in broad outline, nodes would try to compute a "probability (or plausibility) rating" for each new block they encounter. How long has an in-again-out-again transaction been in (and out and in...) my memory pool? What fraction of my network neighbours agree it's been stuck like this for ages? (And recursively, can they report the statistics of ''their'' neighbours' opinions, in cheap aggregated form?) If it's ever more obvious that essentially the whole network knows about it, it becomes ever more ridiculous (exponentially so, I'd suspect) to believe that a whole sequence of miners can have not heard of it. Even more so, since it was sitting there inside ''an expensive object to produce'' - namely, a later-to-be-orphaned block produced by an honest miner - and a thousand websites could spring up, listing (unfakeably! the orphaned blocks are expensive things to produce!) all the transactions therein that are compatible with, but mysteriously excluded for ages by, the current winning chain.

The naive height-strength (difficulty or its proof-of-whatever equivalent) of a block would then be multiplied by that probability or plausibility rating, and it would be the sum of such ''plausibility-adjusted'' height-strengths, not the sum of the naive strengths, which would be used to judge a winning chain.

Yes, this does have the danger that different nodes would compute somewhat different plausibility ratings to multiply naive strengths by; and network consensus convergence could be placed in jeopardy if their opinions were too divergent. So, one would not want to be ''too'' eager to deprecate a block by a large factor. Still, in really extreme cases (say down into one-in-a-million territory for a transaction to have been excluded by bad luck - the power of exponential shrinkage means we get down there quite fast!), a sizeable deprecation becomes sensible (e.g. if we deprecate by the sixth root of plausibility, the attacker's blocks are deprecated by a factor of 10 in the one-in-a-million example - enough that 10% honest miners win out over a 90% attacker).

So... '''there's hope for us yet!''' Even with a billionaire central bank as adversary!

(A final note: who's running those "thousand websites" [or tor-sites... whatever] listing the suspiciously excluded transactions? Well, anyone can set one up; and serious, big full nodes, such as those run by serious professional miners, should be eager to subscribe to such sites, for a microtransaction or subscription or the like if necessary. After all, if you're a miner, and you know that ''other'' nodes are going to deprecate ''your'' block if you don't make an effort to include that gaggle of suspiciously excluded transactions, that's a powerful incentive to keep yourself up to date with the general state of play! - And yes, we should of course aim for ''the network itself'' to achieve such functionality, without external sites' involvement. Perhaps nodes could report to their neighbours a standardised-mathematical-language ''set of reasons'' why they attached such-and-such a deprecation factor to such-and-such a block? The challenge would be to handle one's neighbours' reasons-descriptions in a way that, while stopping short of naive slavish agreement therewith, still encourages a helpful consensus to emerge.)

<big>'''(end of quoted forum post)'''</big>

Adaptive difficulty

2012-11-24T22:27:11Z

Ids: removed nonexistent talk page link, added automatically by the ~~~~ expansion

'''Adaptive difficulty''' is a bitcoin protocol change proposal by [[User:Ids|Iain Stewart]], with the goal of letting the typical time interval from one block to the next adjust smoothly to prevailing network latency, while not compromising the strength of the blockchain, or the decentralized character of the network.

'''''EDIT 2012-11-22:''' My idea is essentially the same as that proposed by [http://en.wikipedia.org/wiki/User:Meni_Rosenfeld Meni Rosenfeld] on the [https://bitcointalk.org/index.php?board=6.0 Bitcoin forums]. Please read and enjoy and critique [https://bitcointalk.org/index.php?topic=79837.0 his adaptive difficulty proposal]! (I'll leave this page here for historical completeness, but not continue working on it.) [[User:Ids|Iain Stewart]] 01:00, 23 November 2012 (GMT)''

== Background ==

The world is being wired up with ever faster connectivity. A merchant location in particular, where any kind of online transaction is desired, will usually have a fast link to either the net or specific counterparty bank(s), with paid-for higher bandwidth and lower latency than the usual domestic speeds. All but the smallest businesses where an internet presence is de rigeur now routinely choose to pay for a fast connection, sometimes choosing to pay a little extra for a guarantee of quick repair ("five nines" cover and the like).

It will therefore remain an expectation of customers that a merchant can process their transaction quickly as a matter of course. (With bitcoin, we do have the sub-community of users who desire strong anonymity and may use Tor/i2p, coin mixing services, and the like. They are tech-savvy and accept that these choices cause slowness. We can't expect that to become the broader expectation, however.)

The average 10-minute interval between blocks, and the need to wait a few blocks (6 is often cited) to achieve acceptable closeness to irreversibility of one's transaction, will likely be a barrier to ease of use in cases where an expectation of speed is firmly embedded in customers' and merchants' culture. (Even people who choose to slow down the ''submission'' of their transaction, in exchange for better anonymity for example, would still benefit from fast ''handling'' of their transaction once it has been submitted. They too may well grumble at the tens of minutes' to hours' delay on top of that of their own choosing.)

The 10-minute target interval could of course be changed, by sufficient consensus among miners and the community, to some other fixed value. Miners could boldly assert that the network latency between them "has reliably been such-and-such" (likely pleasantly short, since serious miners with their ASICs or whatever would want to pay for a fast net connection like any other net-centric business); and they could propose some multiple of this as a block interval. A change from one fixed value to another has its problems, though. A danger of choosing too short a value is that the network (of miners) fragments, into clusters who wastefully work on what they each sincerely believe is the most up-to-date block, and only later collectively purges the proliferation of short chains. The community's justified fear of this scenario would likely mean any future fixed target interval would always have to err on the side of caution (slowness).

But why have a ''fixed'' value at all? Can a protocol be fashioned where miners discover ''dynamically'' the interval that's in some sense the "best" choice, given the prevailing network latency between them? Such a protocol would have to avoid perverse incentives for any individual miner to influence the discovery process in a way that was good for that miner, but bad for the security of the blockchain.

One could imagine all sorts of formulae for deciding which way difficulty "should" go on a very fine scale (even from one block to the next) - whether similar or not-so-similar to the fortnightly difficulty adjustment already in place. The fortnightly (2016-block) adjustment is of course intended as a regulator of the impact of ''gradual'' network-wide growth or shrinkage of ''hash-rate'', and not of ''moment-to-moment'' network ''latency'' (or of moment-to-moment anything else for that matter). But one could imagine similar attempts to measure, and adjust to, latency changes, by some clever formula.

Adaptive difficulty is '''not''' an attempt at such a formula. There are good grounds for believing that the (or a candidate) block''chain'' - as opposed to the block''tree'' held at any instant by any particular miner - simply cannot contain enough information to assist with latency discovery. Only the tree, and not any one chain, contains the kind of evidence that could assist with noticing the sort of wasteful fragmentation discussed above, for example. But to compute a network-influencing parameter according to the properties of a whole blocktree, and then embed it in any one would-be winning blockchain, would be dangerous. Even ignoring the fact that the blocktree differs from miner to miner, there would be no way, later, when the rest of the tree had died by neglect, to verify that the information embedded in the winning blockchain was correctly computed from a tree prevailing at the time - and not, for example, just made up by an attacker, who can later create a spurious tree (with false timestamps), at leisure, with bits and pieces dangling off various winning-chain blocks in whatever style it takes to make the attacker's made-up information ''seem'' to have been computed from that spurious tree.

What adaptive difficulty '''is''', is something more radical than any such formula: a scheme where miners ''choose'', and announce in the header, the difficulty of ''every block they proceed to try to solve''. To those despairing that such anarchy could ever work, please read on! The regulatory function of the network - the assurance that it converges on a consensus best chain, with good immunity from attacks other than a 51% attack - is achieved by other aspects of the protocol. Out of anarchy, order will emerge.

== Anarchy in the blockchain ==

Some general remarks first. The proof of work measure of a blockchain is its sum of difficulties, not its mere number of blocks. (The expected work cost of solving two blocks of difficulty ''d'' is the same as that of solving one block of difficulty 2''d''.) If, for example, generally prevailing difficulty is halved (by whatever means), the network will solve blocks of the new difficulty at twice the previous rate; and the average value of transaction fees available for reaping in the latest block will be halved. (The adaptive difficulty protocol will scale the coin-minting block reward to the difficulty too.) A chain of such new, cheaper blocks will grow at the same expected speed ''in sum-of-difficulty terms'' as ever; it is just the ''style'' of growth which will be different (twice as many blocks, of half the difficulty and average miner reward each). The economics of block solving will change in two, mutually cancelling, ways from a miner's perspective: each hash has twice the probability of solving a block, but the reward has halved. Miners should thus be broadly indifferent (ignoring network latency issues for now) to difficulty changes in either direction, so long as they are done in that reward-scaling style.

(.....''got to here''.....)

''(uh, and now a pause folks, while I slowly learn "everything I never wanted to know about how to type in mathematical notation to a wiki but have been forced to find out"!)''

== ''...and now for something completely different! (unpolished teaser for now...)'' ==

''(Just to explain - I'm neglecting this adaptive difficulty stuff for a while [sorry!] because I '''seem''' to have almost accidentally invented [the bare beginnings of] a different system which protects against even a '''considerably-greater-than-50% attack'''! I don't want to create a page on it just yet before I thoroughly check that I'm not making a fool of myself... [well, I'll allow myself a stub, as a home for this teaser stuff: "[[Proof_of_blockchain_fair_sharing|proof of blockchain fair sharing]]"] ...but as a teaser description: it's of proof-of-stake flavour [which makes me nervous in some ways, but that's another story], and it relies on the fact that stakeholders are '''pseudonymously trackable''', unlike proof-of-work contributors, and therefore a formula for blockchain height can reward '''closeness to fair-share proportions''' in such a way that a 90% attacker finds they can't stop the honest 10% contributing too-expensive-for-attacker-to-reverse blocks which, to the attacker's chagrin, '''incorporate''' the accumulated transactions the attacker has been endlessly reversing and re-excluding in an effort to ruin the credibility of bitcoin. [And any change to the attacker's pseudonymous identity/identities destroys their bitcoin-days' stake and takes them out of the running as a big attacker for a long time.] - More to follow real soon now hopefully!)''

''(To expand a little on the above teaser: One might think that by reductio ad absurdum '''no''' system can protect against a >50% attack, because in a purported proof of immunity of the honest <50% from the malicious >50%, the labels "honest" and "malicious" ultimately have no technical meaning, and so just swapping the labels would, absurdly, give a second proof, saying that the <50% community can't "attack" [i.e. save us all from] the >50% community, in contradiction to the first proof. That reductio argument is false here - '''there is an asymmetry''' between the two communities' goals, as follows. [I'm talking about an attack to destroy the usability of bitcoin. An attack to achieve double spending is a much lower-impact event, the analysis of which I'm therefore postponing, although on general grounds the situation is probably neither especially better nor worse than with other protocols.] The >50% "community" [the attacker(s)] is trying to exclude transactions - perhaps all of them, perhaps those of specific people it wants to harass, perhaps random ones just to create fear that "I could be next" - from entering the winning blockchain. Thus it has to achieve '''total''' exclusion of the would-be blocks originating from the <50% community, who keep including the transactions to try and earn an honest profit from the fees. By contrast, the <50% community [the just-trying-to-earn-a-living honest miners] '''doesn't''' have to achieve exclusion of the attacker's blocks - they're happy with a mixed blockchain where, reasonably often, another honest block gets in and stays in. So long as they can get transactions bedded down into the blockchain, they've avoided the ruining of bitcoin as a usable system. It's this crucial asymmetry between the two communities which lets the honest miners win - a chain height formula which suitably rewards diversity of pseudonymous composition will stop even a 90% attacker "community" from achieving its, tougher, goal. I hope this indicates the general direction I'm headed. [[User:Ids|Iain Stewart]] 02:15, 21 May 2012 (GMT))''

Proof of blockchain fair sharing

2012-11-24T21:54:12Z

Ids: /* The forum post */ shadowed clarifying edit on forum

'''Proof of blockchain fair sharing''' is a draft bitcoin protocol change proposal by [[User:Ids|Iain Stewart]], with the goal of allowing the network to continue to settle on a sensible consensus blockchain ''even when subject to a considerably-greater-than-50% attack''.

The protocol is under construction. The following description is a "teaser", establishing its basic flavour and sketching how it exploits an asymmetry in the goals of the honest (<50%) and malicious (>50%) miners to avoid the usual reductio ad absurdum argument against ''any'' protocol surviving a >50% attack.

== Teaser description ==

''Iain Stewart writes:'' Proof of blockchain fair sharing is of proof-of-stake flavour (which makes me nervous in some ways, but that's another story), and it relies on the fact that stakeholders are '''pseudonymously trackable''', unlike proof-of-work contributors, and therefore a formula for blockchain height can reward '''closeness to fair-share proportions''' in such a way that a 90% attacker finds they can't stop the honest 10% contributing too-expensive-for-the-attacker-to-reverse blocks which, to the attacker's chagrin, '''incorporate''' the accumulated transactions the attacker has been endlessly reversing and re-excluding in an effort to ruin the credibility of bitcoin. (And any change to the attacker's pseudonymous identity/identities destroys their bitcoin-days' stake and takes them out of the running as a big attacker for a long time.)

To expand a little on the above teaser: One might think that by reductio ad absurdum '''no''' system can protect against a >50% attack, because in a purported proof of immunity of the honest <50% from the malicious >50%, the labels "honest" and "malicious" ultimately have no technical meaning, and so just swapping the labels would, absurdly, give a second proof, saying that the <50% community can't "attack" (i.e. save us all from) the >50% community, in contradiction to the first proof. That reductio argument is false here - '''there is an asymmetry''' between the two communities' goals, as follows. (I'm talking about an attack to destroy the usability of bitcoin. An attack to achieve [[Double-spending|double spending]] is a much lower-impact event, the analysis of which I'm therefore postponing, although on general grounds the situation is probably neither especially better nor worse than with other protocols.) The >50% "community" [the attacker(s)] is trying to exclude transactions - perhaps all of them, perhaps those of specific people it wants to harass, perhaps random ones just to create fear that "I could be next" - from entering the winning blockchain. Thus it has to achieve '''total''' exclusion of the would-be blocks originating from the <50% community, who keep including the transactions to try and earn an honest profit from the fees. By contrast, the <50% community [the just-trying-to-earn-a-living honest miners] '''doesn't''' have to achieve exclusion of the attacker's blocks - they're happy with a mixed blockchain where, reasonably often, another honest block gets in and stays in. So long as they can get transactions bedded down into the blockchain, they've avoided the ruining of bitcoin as a usable system. It's this crucial asymmetry between the two communities which lets the honest miners win - a chain height formula which suitably rewards diversity of pseudonymous composition will stop even a 90% attacker "community" from achieving its, tougher, goal. I hope this indicates the general direction I'm headed. [[User:Ids|Iain Stewart]] 11:15, 21 May 2012 (GMT)

== Broader approaches to the >50% attack problem ==

''Iain Stewart writes:'' I apologise for the unfinished state of the above teaser description. It's a hard problem, and it may even be impossible in its "pure" form, without help from fallible heuristics and the like.

In the spirit of exploring broader approaches with rough-and-ready fallible heuristics, I reproduce below [https://bitcointalk.org/index.php?topic=125822.msg1352625#msg1352625 my forum post] about how a cryptocurrency might resist a >50% attack from (in Cunicula's opening post's example) a central bank. It's not fair sharing as defined above - but maybe it doesn't need to be. [[User:Ids|Iain Stewart]] 08:45, 23 November 2012 (GMT)

=== The forum post ===

Well! [https://bitcointalk.org/index.php?topic=125822.0 This thread] has certainly got us all thinking about the robustness or lack thereof of various cryptocurrency designs! [https://bitcointalk.org/index.php?topic=125822.msg1341095#msg1341095 Cunicula's opening post] paints (possibly provocatively or tongue-in-cheek?) a central bank's hypothetical successful 51% attack as a good thing. I think most of us on this forum would disagree. We want our cryptocurrency to '''stop''' any would-be central bank / central planner from saying "you can only spend your coins in a style approved by our macroeconomic policies". (In just the same way as we want it to '''stop''' a present or future PayPal from saying "you can only buy what we think you ought to buy, and donate to who we think you ought to donate to". - Or, more precisely, they can say it, but we can reply "we don't need you any more".)

That's what we want. How do we get it?

For attacks falling short of 51%, there's some mileage to be had in changing the "proof-of-..." choice from one thing to another. Proof-of-work, proof-of-stake, proof-of-activity... they all have interesting advantages and disadvantages and are all debated vigorously in various corners of this forum. Indeed, I'm planning to add to the list myself real soon now, with something I call "proof-of-burn". But they all crumple under a 51% attack. (That includes my proof-of-burn too! It's not immune!) So, when facing an adversary wealthy enough to acquire and use 51% of ''whichever'' "proof-of..." resource is being measured by the network - hashing work, stake, burn rate, signature activity, you name it - we need new techniques to stand up to such an attacker.

I think the good news here is that a 51% attacker's chain has to behave '''visibly strangely''' when excluding "technically fully sensible but politically unapproved" transactions, such as the "no, I'm not going to pay your coin-year-demurrage level of fees!" transactions Cunicula's example central bank would like to exclude. Such transactions sit in every node's memory pool. Then, every time any such transaction gets into a block (mined by an honest miner who's perfectly happy with its "ordinary" competitive-mining-market-clearing level of fee), the winning chain always ends up building on the ''previous'' block, orphaning the honest block and orphaning the transaction back into the memory pool. Whereas, every time ''no'' such transactions get into a block, the winning chain always ends up building on ''that'' block - it being a block produced by the 51% attacker (or by an honest miner who happens to have inadvertantly followed the attacker's policy by happening not to have included those transactions for whatever mundane reason).

This behaviour is visibly strange in a statistical sense. It may not seem strange the first time, or the second time, or the tenth time, but as the politically-unapproved transactions hop in and out of everyone's memory pool more and more often, it becomes ever more absurd to ascribe their exclusion to bad luck.

(Contrast this with an attack whose motive is double-spending, rather than political control of the cryptocurrency. In the double-spending scenario, the network has no real opinion about which of the incompatible transactions ''ought'' to succeed and which ought to fail. An attacker can choose whichever one profits them and hurts the recipients[-until-later-reversed] of its double-spending sibling(s). Recipients just have to learn to wait long enough that ''even the attacker'' loses interest in further reversing their own chain - their own reversal-attack upon some earlier apparently winning chain - to that block-depth extent. But in the transaction-excluding scenario, the network's honest users '''do''' have an opinion about which ''treatment'' of the ''single'' [no double-spending siblings] transaction ought to succeed and which ought to fail. Namely: the transaction's ''presence'' is what ought to succeed, and its ''absence'' is what ought to fail!)

This visibly strange behaviour opens up the possibility of a "heuristic defence". I'm certainly not claiming I have such a defence in polished form ready to implement; but in broad outline, nodes would try to compute a "probability (or plausibility) rating" for each new block they encounter. How long has an in-again-out-again transaction been in (and out and in...) my memory pool? What fraction of my network neighbours agree it's been stuck like this for ages? (And recursively, can they report the statistics of ''their'' neighbours' opinions, in cheap aggregated form?) If it's ever more obvious that essentially the whole network knows about it, it becomes ever more ridiculous (exponentially so, I'd suspect) to believe that a whole sequence of miners can have not heard of it. Even more so, since it was sitting there inside ''an expensive object to produce'' - namely, a later-to-be-orphaned block produced by an honest miner - and a thousand websites could spring up, listing (unfakeably! the orphaned blocks are expensive things to produce!) all the transactions therein that are compatible with, but mysteriously excluded for ages by, the current winning chain.

The naive height-strength (difficulty or its proof-of-whatever equivalent) of a block would then be multiplied by that probability or plausibility rating, and it would be the sum of such ''plausibility-adjusted'' height-strengths, not the sum of the naive strengths, which would be used to judge a winning chain.

Yes, this does have the danger that different nodes would compute somewhat different plausibility ratings to multiply naive strengths by; and network consensus convergence could be placed in jeopardy if their opinions were too divergent. So, one would not want to be ''too'' eager to deprecate a block by a large factor. Still, in really extreme cases (say down into one-in-a-million territory for a transaction to have been excluded by bad luck - the power of exponential shrinkage means we get down there quite fast!), a sizeable deprecation becomes sensible (e.g. if we deprecate by the sixth root of plausibility, the attacker's blocks are deprecated by a factor of 10 in the one-in-a-million example - enough that 10% honest miners win out over a 90% attacker).

So... '''there's hope for us yet!''' Even with a billionaire central bank as adversary!

(A final note: who's running those "thousand websites" [or tor-sites... whatever] listing the suspiciously excluded transactions? Well, anyone can set one up; and serious, big full nodes, such as those run by serious professional miners, should be eager to subscribe to such sites, for a microtransaction or subscription or the like if necessary. After all, if you're a miner, and you know that ''other'' nodes are going to deprecate ''your'' block if you don't make an effort to include that gaggle of suspiciously excluded transactions, that's a powerful incentive to keep yourself up to date with the general state of play! - And yes, we should of course aim for ''the network itself'' to achieve such functionality, without external sites' involvement. Perhaps nodes could report to their neighbours a standardised-mathematical-language ''set of reasons'' why they attached such-and-such a deprecation factor to such-and-such a block? The challenge would be to handle one's neighbours' reasons-descriptions in a way that, while stopping short of naive slavish agreement therewith, still encourages a helpful consensus to emerge.)

User:Ids

2012-11-23T09:06:17Z

Ids: proof of blockchain fair sharing has had its own page for some time - linked to it! (and mentioned "broader approaches" forum post.)

'''(real name: Iain Stewart)'''

I worked as a computing lab assistant at Imperial College, London, U.K. from 1991-2011.

I am especially interested in helping to improve bitcoin's usability from a non-tech-savvy user's perspective. By this I don't just mean GUI improvements and the like - plenty of people far more talented than me are working on that - but changes to the network protocol itself that will help with responsiveness from a merchant's or customer's point of view, while not compromising cryptographic security, decentralization, or the strength of the blockchain.

I have a provisional proposal, which I call [[Adaptive_difficulty|adaptive difficulty]], which I believe will help with this. I'm hoping to eventually put it up as a BIP. For now I'll work on it at that non-BIP page. Comments and feedback welcome. (Remember that for now, the Bayesian analysis of what proof-of-work is deserved by what difficulty-sequence is ''unfinished'', and the formulae are of indicative status only.) ''(in fact the whole page is just a stub for now - I must first master mathematical wiki-speak!)''

(You might also be interested in a proof-of-stake-based system which I at least provisionally believe can be made extraordinarily robust! I call it "[[Proof_of_blockchain_fair_sharing|proof of blockchain fair sharing]]". - That page is currently just a teaser description, sketching the idea and why it doesn't contradict an "obvious" theorem on >50% attacks; followed by a forum post where I speculate on possible broader approaches to the >50% attack problem.)

I can be contacted at iain dot david dot stewart at gmail dot com.

Proof of blockchain fair sharing

2012-11-23T08:50:41Z

Ids: /* Broader approaches to the >50% attack problem */ removed nonexistent talk page link, added automatically by the ~~~~ expansion

'''Proof of blockchain fair sharing''' is a draft bitcoin protocol change proposal by [[User:Ids|Iain Stewart]], with the goal of allowing the network to continue to settle on a sensible consensus blockchain ''even when subject to a considerably-greater-than-50% attack''.

The protocol is under construction. The following description is a "teaser", establishing its basic flavour and sketching how it exploits an asymmetry in the goals of the honest (<50%) and malicious (>50%) miners to avoid the usual reductio ad absurdum argument against ''any'' protocol surviving a >50% attack.

== Teaser description ==

''Iain Stewart writes:'' Proof of blockchain fair sharing is of proof-of-stake flavour (which makes me nervous in some ways, but that's another story), and it relies on the fact that stakeholders are '''pseudonymously trackable''', unlike proof-of-work contributors, and therefore a formula for blockchain height can reward '''closeness to fair-share proportions''' in such a way that a 90% attacker finds they can't stop the honest 10% contributing too-expensive-for-the-attacker-to-reverse blocks which, to the attacker's chagrin, '''incorporate''' the accumulated transactions the attacker has been endlessly reversing and re-excluding in an effort to ruin the credibility of bitcoin. (And any change to the attacker's pseudonymous identity/identities destroys their bitcoin-days' stake and takes them out of the running as a big attacker for a long time.)

To expand a little on the above teaser: One might think that by reductio ad absurdum '''no''' system can protect against a >50% attack, because in a purported proof of immunity of the honest <50% from the malicious >50%, the labels "honest" and "malicious" ultimately have no technical meaning, and so just swapping the labels would, absurdly, give a second proof, saying that the <50% community can't "attack" (i.e. save us all from) the >50% community, in contradiction to the first proof. That reductio argument is false here - '''there is an asymmetry''' between the two communities' goals, as follows. (I'm talking about an attack to destroy the usability of bitcoin. An attack to achieve [[Double-spending|double spending]] is a much lower-impact event, the analysis of which I'm therefore postponing, although on general grounds the situation is probably neither especially better nor worse than with other protocols.) The >50% "community" [the attacker(s)] is trying to exclude transactions - perhaps all of them, perhaps those of specific people it wants to harass, perhaps random ones just to create fear that "I could be next" - from entering the winning blockchain. Thus it has to achieve '''total''' exclusion of the would-be blocks originating from the <50% community, who keep including the transactions to try and earn an honest profit from the fees. By contrast, the <50% community [the just-trying-to-earn-a-living honest miners] '''doesn't''' have to achieve exclusion of the attacker's blocks - they're happy with a mixed blockchain where, reasonably often, another honest block gets in and stays in. So long as they can get transactions bedded down into the blockchain, they've avoided the ruining of bitcoin as a usable system. It's this crucial asymmetry between the two communities which lets the honest miners win - a chain height formula which suitably rewards diversity of pseudonymous composition will stop even a 90% attacker "community" from achieving its, tougher, goal. I hope this indicates the general direction I'm headed. [[User:Ids|Iain Stewart]] 11:15, 21 May 2012 (GMT)

== Broader approaches to the >50% attack problem ==

''Iain Stewart writes:'' I apologise for the unfinished state of the above teaser description. It's a hard problem, and it may even be impossible in its "pure" form, without help from fallible heuristics and the like.

In the spirit of exploring broader approaches with rough-and-ready fallible heuristics, I reproduce below [https://bitcointalk.org/index.php?topic=125822.msg1352625#msg1352625 my forum post] about how a cryptocurrency might resist a >50% attack from (in Cunicula's opening post's example) a central bank. It's not fair sharing as defined above - but maybe it doesn't need to be. [[User:Ids|Iain Stewart]] 08:45, 23 November 2012 (GMT)

=== The forum post ===

Well! [https://bitcointalk.org/index.php?topic=125822.0 This thread] has certainly got us all thinking about the robustness or lack thereof of various cryptocurrency designs! [https://bitcointalk.org/index.php?topic=125822.msg1341095#msg1341095 Cunicula's opening post] paints (possibly provocatively or tongue-in-cheek?) a central bank's hypothetical successful 51% attack as a good thing. I think most of us on this forum would disagree. We want our cryptocurrency to '''stop''' any would-be central bank / central planner from saying "you can only spend your coins in a style approved by our macroeconomic policies". (In just the same way as we want it to '''stop''' a present or future PayPal from saying "you can only buy what we think you ought to buy, and donate to who we think you ought to donate to".)

That's what we want. How do we get it?

For attacks falling short of 51%, there's some mileage to be had in changing the "proof-of-..." choice from one thing to another. Proof-of-work, proof-of-stake, proof-of-activity... they all have interesting advantages and disadvantages and are all debated vigorously in various corners of this forum. Indeed, I'm planning to add to the list myself real soon now, with something I call "proof-of-burn". But they all crumple under a 51% attack. (That includes my proof-of-burn too! It's not immune!) So, when facing an adversary wealthy enough to acquire and use 51% of ''whichever'' "proof-of..." resource is being measured by the network - hashing work, stake, burn rate, signature activity, you name it - we need new techniques to stand up to such an attacker.

I think the good news here is that a 51% attacker's chain has to behave '''visibly strangely''' when excluding "technically fully sensible but politically unapproved" transactions, such as the "no, I'm not going to pay your coin-year-demurrage level of fees!" transactions Cunicula's example central bank would like to exclude. Such transactions sit in every node's memory pool. Then, every time any such transaction gets into a block (mined by an honest miner who's perfectly happy with its "ordinary" competitive-mining-market-clearing level of fee), the winning chain always ends up building on the ''previous'' block, orphaning the honest block and orphaning the transaction back into the memory pool. Whereas, every time ''no'' such transactions get into a block, the winning chain always ends up building on ''that'' block - it being a block produced by the 51% attacker (or by an honest miner who happens to have inadvertantly followed the attacker's policy by happening not to have included those transactions for whatever mundane reason).

This behaviour is visibly strange in a statistical sense. It may not seem strange the first time, or the second time, or the tenth time, but as the politically-unapproved transactions hop in and out of everyone's memory pool more and more often, it becomes ever more absurd to ascribe their exclusion to bad luck.

(Contrast this with an attack whose motive is double-spending, rather than political control of the cryptocurrency. In the double-spending scenario, the network has no real opinion about which of the incompatible transactions ''ought'' to succeed and which ought to fail. An attacker can choose whichever one profits them and hurts the recipients[-until-later-reversed] of its double-spending sibling(s). Recipients just have to learn to wait long enough that ''even the attacker'' loses interest in further reversing their own chain - their own reversal-attack upon some earlier apparently winning chain - to that block-depth extent. But in the transaction-excluding scenario, the network's honest users '''do''' have an opinion about which ''treatment'' of the ''single'' [no double-spending siblings] transaction ought to succeed and which ought to fail. Namely: the transaction's ''presence'' is what ought to succeed, and its ''absence'' is what ought to fail!)

This visibly strange behaviour opens up the possibility of a "heuristic defence". I'm certainly not claiming I have such a defence in polished form ready to implement; but in broad outline, nodes would try to compute a "probability (or plausibility) rating" for each new block they encounter. How long has an in-again-out-again transaction been in (and out and in...) my memory pool? What fraction of my network neighbours agree it's been stuck like this for ages? (And recursively, can they report the statistics of ''their'' neighbours' opinions, in cheap aggregated form?) If it's ever more obvious that essentially the whole network knows about it, it becomes ever more ridiculous (exponentially so, I'd suspect) to believe that a whole sequence of miners can have not heard of it. Even more so, since it was sitting there inside ''an expensive object to produce'' - namely, a later-to-be-orphaned block produced by an honest miner - and a thousand websites could spring up, listing (unfakeably! the orphaned blocks are expensive things to produce!) all the transactions therein that are compatible with, but mysteriously excluded for ages by, the current winning chain.

The naive height-strength (difficulty or its proof-of-whatever equivalent) of a block would then be multiplied by that probability or plausibility rating, and it would be the sum of such ''plausibility-adjusted'' height-strengths, not the sum of the naive strengths, which would be used to judge a winning chain.

Yes, this does have the danger that different nodes would compute somewhat different plausibility ratings to multiply naive strengths by; and network consensus convergence could be placed in jeopardy if their opinions were too divergent. So, one would not want to be ''too'' eager to deprecate a block by a large factor. Still, in really extreme cases (say down into one-in-a-million territory for a transaction to have been excluded by bad luck - the power of exponential shrinkage means we get down there quite fast!), a sizeable deprecation becomes sensible (e.g. if we deprecate by the sixth root of plausibility, the attacker's blocks are deprecated by a factor of 10 in the one-in-a-million example - enough that 10% honest miners win out over a 90% attacker).

So... '''there's hope for us yet!''' Even with a billionaire central bank as adversary!

(A final note: who's running those "thousand websites" [or tor-sites... whatever] listing the suspiciously excluded transactions? Well, anyone can set one up; and serious, big full nodes, such as those run by serious professional miners, should be eager to subscribe to such sites, for a microtransaction or subscription or the like if necessary. After all, if you're a miner, and you know that ''other'' nodes are going to deprecate ''your'' block if you don't make an effort to include that gaggle of suspiciously excluded transactions, that's a powerful incentive to keep yourself up to date with the general state of play! - And yes, we should of course aim for ''the network itself'' to achieve such functionality, without external sites' involvement. Perhaps nodes could report to their neighbours a standardised-mathematical-language ''set of reasons'' why they attached such-and-such a deprecation factor to such-and-such a block? The challenge would be to handle one's neighbours' reasons-descriptions in a way that, while stopping short of naive slavish agreement therewith, still encourages a helpful consensus to emerge.)

Proof of blockchain fair sharing

2012-11-23T08:45:42Z

Ids: added forum post with broader approaches to the >50% attack problem

'''Proof of blockchain fair sharing''' is a draft bitcoin protocol change proposal by [[User:Ids|Iain Stewart]], with the goal of allowing the network to continue to settle on a sensible consensus blockchain ''even when subject to a considerably-greater-than-50% attack''.

The protocol is under construction. The following description is a "teaser", establishing its basic flavour and sketching how it exploits an asymmetry in the goals of the honest (<50%) and malicious (>50%) miners to avoid the usual reductio ad absurdum argument against ''any'' protocol surviving a >50% attack.

== Teaser description ==

''Iain Stewart writes:'' Proof of blockchain fair sharing is of proof-of-stake flavour (which makes me nervous in some ways, but that's another story), and it relies on the fact that stakeholders are '''pseudonymously trackable''', unlike proof-of-work contributors, and therefore a formula for blockchain height can reward '''closeness to fair-share proportions''' in such a way that a 90% attacker finds they can't stop the honest 10% contributing too-expensive-for-the-attacker-to-reverse blocks which, to the attacker's chagrin, '''incorporate''' the accumulated transactions the attacker has been endlessly reversing and re-excluding in an effort to ruin the credibility of bitcoin. (And any change to the attacker's pseudonymous identity/identities destroys their bitcoin-days' stake and takes them out of the running as a big attacker for a long time.)

To expand a little on the above teaser: One might think that by reductio ad absurdum '''no''' system can protect against a >50% attack, because in a purported proof of immunity of the honest <50% from the malicious >50%, the labels "honest" and "malicious" ultimately have no technical meaning, and so just swapping the labels would, absurdly, give a second proof, saying that the <50% community can't "attack" (i.e. save us all from) the >50% community, in contradiction to the first proof. That reductio argument is false here - '''there is an asymmetry''' between the two communities' goals, as follows. (I'm talking about an attack to destroy the usability of bitcoin. An attack to achieve [[Double-spending|double spending]] is a much lower-impact event, the analysis of which I'm therefore postponing, although on general grounds the situation is probably neither especially better nor worse than with other protocols.) The >50% "community" [the attacker(s)] is trying to exclude transactions - perhaps all of them, perhaps those of specific people it wants to harass, perhaps random ones just to create fear that "I could be next" - from entering the winning blockchain. Thus it has to achieve '''total''' exclusion of the would-be blocks originating from the <50% community, who keep including the transactions to try and earn an honest profit from the fees. By contrast, the <50% community [the just-trying-to-earn-a-living honest miners] '''doesn't''' have to achieve exclusion of the attacker's blocks - they're happy with a mixed blockchain where, reasonably often, another honest block gets in and stays in. So long as they can get transactions bedded down into the blockchain, they've avoided the ruining of bitcoin as a usable system. It's this crucial asymmetry between the two communities which lets the honest miners win - a chain height formula which suitably rewards diversity of pseudonymous composition will stop even a 90% attacker "community" from achieving its, tougher, goal. I hope this indicates the general direction I'm headed. [[User:Ids|Iain Stewart]] 11:15, 21 May 2012 (GMT)

== Broader approaches to the >50% attack problem ==

''Iain Stewart writes:'' I apologise for the unfinished state of the above teaser description. It's a hard problem, and it may even be impossible in its "pure" form, without help from fallible heuristics and the like.

In the spirit of exploring broader approaches with rough-and-ready fallible heuristics, I reproduce below [https://bitcointalk.org/index.php?topic=125822.msg1352625#msg1352625 my forum post] about how a cryptocurrency might resist a >50% attack from (in Cunicula's opening post's example) a central bank. It's not fair sharing as defined above - but maybe it doesn't need to be. [[User:Ids|Iain Stewart]] ([[User talk:Ids|talk]]) 08:45, 23 November 2012 (GMT)

=== The forum post ===

Well! [https://bitcointalk.org/index.php?topic=125822.0 This thread] has certainly got us all thinking about the robustness or lack thereof of various cryptocurrency designs! [https://bitcointalk.org/index.php?topic=125822.msg1341095#msg1341095 Cunicula's opening post] paints (possibly provocatively or tongue-in-cheek?) a central bank's hypothetical successful 51% attack as a good thing. I think most of us on this forum would disagree. We want our cryptocurrency to '''stop''' any would-be central bank / central planner from saying "you can only spend your coins in a style approved by our macroeconomic policies". (In just the same way as we want it to '''stop''' a present or future PayPal from saying "you can only buy what we think you ought to buy, and donate to who we think you ought to donate to".)

That's what we want. How do we get it?

For attacks falling short of 51%, there's some mileage to be had in changing the "proof-of-..." choice from one thing to another. Proof-of-work, proof-of-stake, proof-of-activity... they all have interesting advantages and disadvantages and are all debated vigorously in various corners of this forum. Indeed, I'm planning to add to the list myself real soon now, with something I call "proof-of-burn". But they all crumple under a 51% attack. (That includes my proof-of-burn too! It's not immune!) So, when facing an adversary wealthy enough to acquire and use 51% of ''whichever'' "proof-of..." resource is being measured by the network - hashing work, stake, burn rate, signature activity, you name it - we need new techniques to stand up to such an attacker.

I think the good news here is that a 51% attacker's chain has to behave '''visibly strangely''' when excluding "technically fully sensible but politically unapproved" transactions, such as the "no, I'm not going to pay your coin-year-demurrage level of fees!" transactions Cunicula's example central bank would like to exclude. Such transactions sit in every node's memory pool. Then, every time any such transaction gets into a block (mined by an honest miner who's perfectly happy with its "ordinary" competitive-mining-market-clearing level of fee), the winning chain always ends up building on the ''previous'' block, orphaning the honest block and orphaning the transaction back into the memory pool. Whereas, every time ''no'' such transactions get into a block, the winning chain always ends up building on ''that'' block - it being a block produced by the 51% attacker (or by an honest miner who happens to have inadvertantly followed the attacker's policy by happening not to have included those transactions for whatever mundane reason).

This behaviour is visibly strange in a statistical sense. It may not seem strange the first time, or the second time, or the tenth time, but as the politically-unapproved transactions hop in and out of everyone's memory pool more and more often, it becomes ever more absurd to ascribe their exclusion to bad luck.

(Contrast this with an attack whose motive is double-spending, rather than political control of the cryptocurrency. In the double-spending scenario, the network has no real opinion about which of the incompatible transactions ''ought'' to succeed and which ought to fail. An attacker can choose whichever one profits them and hurts the recipients[-until-later-reversed] of its double-spending sibling(s). Recipients just have to learn to wait long enough that ''even the attacker'' loses interest in further reversing their own chain - their own reversal-attack upon some earlier apparently winning chain - to that block-depth extent. But in the transaction-excluding scenario, the network's honest users '''do''' have an opinion about which ''treatment'' of the ''single'' [no double-spending siblings] transaction ought to succeed and which ought to fail. Namely: the transaction's ''presence'' is what ought to succeed, and its ''absence'' is what ought to fail!)

This visibly strange behaviour opens up the possibility of a "heuristic defence". I'm certainly not claiming I have such a defence in polished form ready to implement; but in broad outline, nodes would try to compute a "probability (or plausibility) rating" for each new block they encounter. How long has an in-again-out-again transaction been in (and out and in...) my memory pool? What fraction of my network neighbours agree it's been stuck like this for ages? (And recursively, can they report the statistics of ''their'' neighbours' opinions, in cheap aggregated form?) If it's ever more obvious that essentially the whole network knows about it, it becomes ever more ridiculous (exponentially so, I'd suspect) to believe that a whole sequence of miners can have not heard of it. Even more so, since it was sitting there inside ''an expensive object to produce'' - namely, a later-to-be-orphaned block produced by an honest miner - and a thousand websites could spring up, listing (unfakeably! the orphaned blocks are expensive things to produce!) all the transactions therein that are compatible with, but mysteriously excluded for ages by, the current winning chain.

The naive height-strength (difficulty or its proof-of-whatever equivalent) of a block would then be multiplied by that probability or plausibility rating, and it would be the sum of such ''plausibility-adjusted'' height-strengths, not the sum of the naive strengths, which would be used to judge a winning chain.

Yes, this does have the danger that different nodes would compute somewhat different plausibility ratings to multiply naive strengths by; and network consensus convergence could be placed in jeopardy if their opinions were too divergent. So, one would not want to be ''too'' eager to deprecate a block by a large factor. Still, in really extreme cases (say down into one-in-a-million territory for a transaction to have been excluded by bad luck - the power of exponential shrinkage means we get down there quite fast!), a sizeable deprecation becomes sensible (e.g. if we deprecate by the sixth root of plausibility, the attacker's blocks are deprecated by a factor of 10 in the one-in-a-million example - enough that 10% honest miners win out over a 90% attacker).

So... '''there's hope for us yet!''' Even with a billionaire central bank as adversary!

(A final note: who's running those "thousand websites" [or tor-sites... whatever] listing the suspiciously excluded transactions? Well, anyone can set one up; and serious, big full nodes, such as those run by serious professional miners, should be eager to subscribe to such sites, for a microtransaction or subscription or the like if necessary. After all, if you're a miner, and you know that ''other'' nodes are going to deprecate ''your'' block if you don't make an effort to include that gaggle of suspiciously excluded transactions, that's a powerful incentive to keep yourself up to date with the general state of play! - And yes, we should of course aim for ''the network itself'' to achieve such functionality, without external sites' involvement. Perhaps nodes could report to their neighbours a standardised-mathematical-language ''set of reasons'' why they attached such-and-such a deprecation factor to such-and-such a block? The challenge would be to handle one's neighbours' reasons-descriptions in a way that, while stopping short of naive slavish agreement therewith, still encourages a helpful consensus to emerge.)

Adaptive difficulty

2012-11-23T01:06:20Z

Ids: changed forum link to development and technical discussion sub-forum, rather than top-level

'''Adaptive difficulty''' is a bitcoin protocol change proposal by [[User:Ids|Iain Stewart]], with the goal of letting the typical time interval from one block to the next adjust smoothly to prevailing network latency, while not compromising the strength of the blockchain, or the decentralized character of the network.

'''''EDIT 2012-11-22:''' My idea is essentially the same as that proposed by [http://en.wikipedia.org/wiki/User:Meni_Rosenfeld Meni Rosenfeld] on the [https://bitcointalk.org/index.php?board=6.0 Bitcoin forums]. Please read and enjoy and critique [https://bitcointalk.org/index.php?topic=79837.0 his adaptive difficulty proposal]! (I'll leave this page here for historical completeness, but not continue working on it.) [[User:Ids|Iain Stewart]] ([[User talk:Ids|talk]]) 01:00, 23 November 2012 (GMT)''

== Background ==

The world is being wired up with ever faster connectivity. A merchant location in particular, where any kind of online transaction is desired, will usually have a fast link to either the net or specific counterparty bank(s), with paid-for higher bandwidth and lower latency than the usual domestic speeds. All but the smallest businesses where an internet presence is de rigeur now routinely choose to pay for a fast connection, sometimes choosing to pay a little extra for a guarantee of quick repair ("five nines" cover and the like).

It will therefore remain an expectation of customers that a merchant can process their transaction quickly as a matter of course. (With bitcoin, we do have the sub-community of users who desire strong anonymity and may use Tor/i2p, coin mixing services, and the like. They are tech-savvy and accept that these choices cause slowness. We can't expect that to become the broader expectation, however.)

The average 10-minute interval between blocks, and the need to wait a few blocks (6 is often cited) to achieve acceptable closeness to irreversibility of one's transaction, will likely be a barrier to ease of use in cases where an expectation of speed is firmly embedded in customers' and merchants' culture. (Even people who choose to slow down the ''submission'' of their transaction, in exchange for better anonymity for example, would still benefit from fast ''handling'' of their transaction once it has been submitted. They too may well grumble at the tens of minutes' to hours' delay on top of that of their own choosing.)

The 10-minute target interval could of course be changed, by sufficient consensus among miners and the community, to some other fixed value. Miners could boldly assert that the network latency between them "has reliably been such-and-such" (likely pleasantly short, since serious miners with their ASICs or whatever would want to pay for a fast net connection like any other net-centric business); and they could propose some multiple of this as a block interval. A change from one fixed value to another has its problems, though. A danger of choosing too short a value is that the network (of miners) fragments, into clusters who wastefully work on what they each sincerely believe is the most up-to-date block, and only later collectively purges the proliferation of short chains. The community's justified fear of this scenario would likely mean any future fixed target interval would always have to err on the side of caution (slowness).

But why have a ''fixed'' value at all? Can a protocol be fashioned where miners discover ''dynamically'' the interval that's in some sense the "best" choice, given the prevailing network latency between them? Such a protocol would have to avoid perverse incentives for any individual miner to influence the discovery process in a way that was good for that miner, but bad for the security of the blockchain.

One could imagine all sorts of formulae for deciding which way difficulty "should" go on a very fine scale (even from one block to the next) - whether similar or not-so-similar to the fortnightly difficulty adjustment already in place. The fortnightly (2016-block) adjustment is of course intended as a regulator of the impact of ''gradual'' network-wide growth or shrinkage of ''hash-rate'', and not of ''moment-to-moment'' network ''latency'' (or of moment-to-moment anything else for that matter). But one could imagine similar attempts to measure, and adjust to, latency changes, by some clever formula.

Adaptive difficulty is '''not''' an attempt at such a formula. There are good grounds for believing that the (or a candidate) block''chain'' - as opposed to the block''tree'' held at any instant by any particular miner - simply cannot contain enough information to assist with latency discovery. Only the tree, and not any one chain, contains the kind of evidence that could assist with noticing the sort of wasteful fragmentation discussed above, for example. But to compute a network-influencing parameter according to the properties of a whole blocktree, and then embed it in any one would-be winning blockchain, would be dangerous. Even ignoring the fact that the blocktree differs from miner to miner, there would be no way, later, when the rest of the tree had died by neglect, to verify that the information embedded in the winning blockchain was correctly computed from a tree prevailing at the time - and not, for example, just made up by an attacker, who can later create a spurious tree (with false timestamps), at leisure, with bits and pieces dangling off various winning-chain blocks in whatever style it takes to make the attacker's made-up information ''seem'' to have been computed from that spurious tree.

What adaptive difficulty '''is''', is something more radical than any such formula: a scheme where miners ''choose'', and announce in the header, the difficulty of ''every block they proceed to try to solve''. To those despairing that such anarchy could ever work, please read on! The regulatory function of the network - the assurance that it converges on a consensus best chain, with good immunity from attacks other than a 51% attack - is achieved by other aspects of the protocol. Out of anarchy, order will emerge.

== Anarchy in the blockchain ==

Some general remarks first. The proof of work measure of a blockchain is its sum of difficulties, not its mere number of blocks. (The expected work cost of solving two blocks of difficulty ''d'' is the same as that of solving one block of difficulty 2''d''.) If, for example, generally prevailing difficulty is halved (by whatever means), the network will solve blocks of the new difficulty at twice the previous rate; and the average value of transaction fees available for reaping in the latest block will be halved. (The adaptive difficulty protocol will scale the coin-minting block reward to the difficulty too.) A chain of such new, cheaper blocks will grow at the same expected speed ''in sum-of-difficulty terms'' as ever; it is just the ''style'' of growth which will be different (twice as many blocks, of half the difficulty and average miner reward each). The economics of block solving will change in two, mutually cancelling, ways from a miner's perspective: each hash has twice the probability of solving a block, but the reward has halved. Miners should thus be broadly indifferent (ignoring network latency issues for now) to difficulty changes in either direction, so long as they are done in that reward-scaling style.

(.....''got to here''.....)

''(uh, and now a pause folks, while I slowly learn "everything I never wanted to know about how to type in mathematical notation to a wiki but have been forced to find out"!)''

== ''...and now for something completely different! (unpolished teaser for now...)'' ==

''(Just to explain - I'm neglecting this adaptive difficulty stuff for a while [sorry!] because I '''seem''' to have almost accidentally invented [the bare beginnings of] a different system which protects against even a '''considerably-greater-than-50% attack'''! I don't want to create a page on it just yet before I thoroughly check that I'm not making a fool of myself... [well, I'll allow myself a stub, as a home for this teaser stuff: "[[Proof_of_blockchain_fair_sharing|proof of blockchain fair sharing]]"] ...but as a teaser description: it's of proof-of-stake flavour [which makes me nervous in some ways, but that's another story], and it relies on the fact that stakeholders are '''pseudonymously trackable''', unlike proof-of-work contributors, and therefore a formula for blockchain height can reward '''closeness to fair-share proportions''' in such a way that a 90% attacker finds they can't stop the honest 10% contributing too-expensive-for-attacker-to-reverse blocks which, to the attacker's chagrin, '''incorporate''' the accumulated transactions the attacker has been endlessly reversing and re-excluding in an effort to ruin the credibility of bitcoin. [And any change to the attacker's pseudonymous identity/identities destroys their bitcoin-days' stake and takes them out of the running as a big attacker for a long time.] - More to follow real soon now hopefully!)''

''(To expand a little on the above teaser: One might think that by reductio ad absurdum '''no''' system can protect against a >50% attack, because in a purported proof of immunity of the honest <50% from the malicious >50%, the labels "honest" and "malicious" ultimately have no technical meaning, and so just swapping the labels would, absurdly, give a second proof, saying that the <50% community can't "attack" [i.e. save us all from] the >50% community, in contradiction to the first proof. That reductio argument is false here - '''there is an asymmetry''' between the two communities' goals, as follows. [I'm talking about an attack to destroy the usability of bitcoin. An attack to achieve double spending is a much lower-impact event, the analysis of which I'm therefore postponing, although on general grounds the situation is probably neither especially better nor worse than with other protocols.] The >50% "community" [the attacker(s)] is trying to exclude transactions - perhaps all of them, perhaps those of specific people it wants to harass, perhaps random ones just to create fear that "I could be next" - from entering the winning blockchain. Thus it has to achieve '''total''' exclusion of the would-be blocks originating from the <50% community, who keep including the transactions to try and earn an honest profit from the fees. By contrast, the <50% community [the just-trying-to-earn-a-living honest miners] '''doesn't''' have to achieve exclusion of the attacker's blocks - they're happy with a mixed blockchain where, reasonably often, another honest block gets in and stays in. So long as they can get transactions bedded down into the blockchain, they've avoided the ruining of bitcoin as a usable system. It's this crucial asymmetry between the two communities which lets the honest miners win - a chain height formula which suitably rewards diversity of pseudonymous composition will stop even a 90% attacker "community" from achieving its, tougher, goal. I hope this indicates the general direction I'm headed. [[User:Ids|Iain Stewart]] 02:15, 21 May 2012 (GMT))''

Adaptive difficulty

2012-11-23T01:01:40Z

Ids: layout

'''Adaptive difficulty''' is a bitcoin protocol change proposal by [[User:Ids|Iain Stewart]], with the goal of letting the typical time interval from one block to the next adjust smoothly to prevailing network latency, while not compromising the strength of the blockchain, or the decentralized character of the network.

'''''EDIT 2012-11-22:''' My idea is essentially the same as that proposed by [http://en.wikipedia.org/wiki/User:Meni_Rosenfeld Meni Rosenfeld] on the [https://bitcointalk.org/ Bitcoin forums]. Please read and enjoy and critique [https://bitcointalk.org/index.php?topic=79837.0 his adaptive difficulty proposal]! (I'll leave this page here for historical completeness, but not continue working on it.) [[User:Ids|Iain Stewart]] ([[User talk:Ids|talk]]) 01:00, 23 November 2012 (GMT)''

== Background ==

The world is being wired up with ever faster connectivity. A merchant location in particular, where any kind of online transaction is desired, will usually have a fast link to either the net or specific counterparty bank(s), with paid-for higher bandwidth and lower latency than the usual domestic speeds. All but the smallest businesses where an internet presence is de rigeur now routinely choose to pay for a fast connection, sometimes choosing to pay a little extra for a guarantee of quick repair ("five nines" cover and the like).

It will therefore remain an expectation of customers that a merchant can process their transaction quickly as a matter of course. (With bitcoin, we do have the sub-community of users who desire strong anonymity and may use Tor/i2p, coin mixing services, and the like. They are tech-savvy and accept that these choices cause slowness. We can't expect that to become the broader expectation, however.)

The average 10-minute interval between blocks, and the need to wait a few blocks (6 is often cited) to achieve acceptable closeness to irreversibility of one's transaction, will likely be a barrier to ease of use in cases where an expectation of speed is firmly embedded in customers' and merchants' culture. (Even people who choose to slow down the ''submission'' of their transaction, in exchange for better anonymity for example, would still benefit from fast ''handling'' of their transaction once it has been submitted. They too may well grumble at the tens of minutes' to hours' delay on top of that of their own choosing.)

The 10-minute target interval could of course be changed, by sufficient consensus among miners and the community, to some other fixed value. Miners could boldly assert that the network latency between them "has reliably been such-and-such" (likely pleasantly short, since serious miners with their ASICs or whatever would want to pay for a fast net connection like any other net-centric business); and they could propose some multiple of this as a block interval. A change from one fixed value to another has its problems, though. A danger of choosing too short a value is that the network (of miners) fragments, into clusters who wastefully work on what they each sincerely believe is the most up-to-date block, and only later collectively purges the proliferation of short chains. The community's justified fear of this scenario would likely mean any future fixed target interval would always have to err on the side of caution (slowness).

But why have a ''fixed'' value at all? Can a protocol be fashioned where miners discover ''dynamically'' the interval that's in some sense the "best" choice, given the prevailing network latency between them? Such a protocol would have to avoid perverse incentives for any individual miner to influence the discovery process in a way that was good for that miner, but bad for the security of the blockchain.

One could imagine all sorts of formulae for deciding which way difficulty "should" go on a very fine scale (even from one block to the next) - whether similar or not-so-similar to the fortnightly difficulty adjustment already in place. The fortnightly (2016-block) adjustment is of course intended as a regulator of the impact of ''gradual'' network-wide growth or shrinkage of ''hash-rate'', and not of ''moment-to-moment'' network ''latency'' (or of moment-to-moment anything else for that matter). But one could imagine similar attempts to measure, and adjust to, latency changes, by some clever formula.

Adaptive difficulty is '''not''' an attempt at such a formula. There are good grounds for believing that the (or a candidate) block''chain'' - as opposed to the block''tree'' held at any instant by any particular miner - simply cannot contain enough information to assist with latency discovery. Only the tree, and not any one chain, contains the kind of evidence that could assist with noticing the sort of wasteful fragmentation discussed above, for example. But to compute a network-influencing parameter according to the properties of a whole blocktree, and then embed it in any one would-be winning blockchain, would be dangerous. Even ignoring the fact that the blocktree differs from miner to miner, there would be no way, later, when the rest of the tree had died by neglect, to verify that the information embedded in the winning blockchain was correctly computed from a tree prevailing at the time - and not, for example, just made up by an attacker, who can later create a spurious tree (with false timestamps), at leisure, with bits and pieces dangling off various winning-chain blocks in whatever style it takes to make the attacker's made-up information ''seem'' to have been computed from that spurious tree.

What adaptive difficulty '''is''', is something more radical than any such formula: a scheme where miners ''choose'', and announce in the header, the difficulty of ''every block they proceed to try to solve''. To those despairing that such anarchy could ever work, please read on! The regulatory function of the network - the assurance that it converges on a consensus best chain, with good immunity from attacks other than a 51% attack - is achieved by other aspects of the protocol. Out of anarchy, order will emerge.

== Anarchy in the blockchain ==

Some general remarks first. The proof of work measure of a blockchain is its sum of difficulties, not its mere number of blocks. (The expected work cost of solving two blocks of difficulty ''d'' is the same as that of solving one block of difficulty 2''d''.) If, for example, generally prevailing difficulty is halved (by whatever means), the network will solve blocks of the new difficulty at twice the previous rate; and the average value of transaction fees available for reaping in the latest block will be halved. (The adaptive difficulty protocol will scale the coin-minting block reward to the difficulty too.) A chain of such new, cheaper blocks will grow at the same expected speed ''in sum-of-difficulty terms'' as ever; it is just the ''style'' of growth which will be different (twice as many blocks, of half the difficulty and average miner reward each). The economics of block solving will change in two, mutually cancelling, ways from a miner's perspective: each hash has twice the probability of solving a block, but the reward has halved. Miners should thus be broadly indifferent (ignoring network latency issues for now) to difficulty changes in either direction, so long as they are done in that reward-scaling style.

(.....''got to here''.....)

''(uh, and now a pause folks, while I slowly learn "everything I never wanted to know about how to type in mathematical notation to a wiki but have been forced to find out"!)''

== ''...and now for something completely different! (unpolished teaser for now...)'' ==

''(Just to explain - I'm neglecting this adaptive difficulty stuff for a while [sorry!] because I '''seem''' to have almost accidentally invented [the bare beginnings of] a different system which protects against even a '''considerably-greater-than-50% attack'''! I don't want to create a page on it just yet before I thoroughly check that I'm not making a fool of myself... [well, I'll allow myself a stub, as a home for this teaser stuff: "[[Proof_of_blockchain_fair_sharing|proof of blockchain fair sharing]]"] ...but as a teaser description: it's of proof-of-stake flavour [which makes me nervous in some ways, but that's another story], and it relies on the fact that stakeholders are '''pseudonymously trackable''', unlike proof-of-work contributors, and therefore a formula for blockchain height can reward '''closeness to fair-share proportions''' in such a way that a 90% attacker finds they can't stop the honest 10% contributing too-expensive-for-attacker-to-reverse blocks which, to the attacker's chagrin, '''incorporate''' the accumulated transactions the attacker has been endlessly reversing and re-excluding in an effort to ruin the credibility of bitcoin. [And any change to the attacker's pseudonymous identity/identities destroys their bitcoin-days' stake and takes them out of the running as a big attacker for a long time.] - More to follow real soon now hopefully!)''

''(To expand a little on the above teaser: One might think that by reductio ad absurdum '''no''' system can protect against a >50% attack, because in a purported proof of immunity of the honest <50% from the malicious >50%, the labels "honest" and "malicious" ultimately have no technical meaning, and so just swapping the labels would, absurdly, give a second proof, saying that the <50% community can't "attack" [i.e. save us all from] the >50% community, in contradiction to the first proof. That reductio argument is false here - '''there is an asymmetry''' between the two communities' goals, as follows. [I'm talking about an attack to destroy the usability of bitcoin. An attack to achieve double spending is a much lower-impact event, the analysis of which I'm therefore postponing, although on general grounds the situation is probably neither especially better nor worse than with other protocols.] The >50% "community" [the attacker(s)] is trying to exclude transactions - perhaps all of them, perhaps those of specific people it wants to harass, perhaps random ones just to create fear that "I could be next" - from entering the winning blockchain. Thus it has to achieve '''total''' exclusion of the would-be blocks originating from the <50% community, who keep including the transactions to try and earn an honest profit from the fees. By contrast, the <50% community [the just-trying-to-earn-a-living honest miners] '''doesn't''' have to achieve exclusion of the attacker's blocks - they're happy with a mixed blockchain where, reasonably often, another honest block gets in and stays in. So long as they can get transactions bedded down into the blockchain, they've avoided the ruining of bitcoin as a usable system. It's this crucial asymmetry between the two communities which lets the honest miners win - a chain height formula which suitably rewards diversity of pseudonymous composition will stop even a 90% attacker "community" from achieving its, tougher, goal. I hope this indicates the general direction I'm headed. [[User:Ids|Iain Stewart]] 02:15, 21 May 2012 (GMT))''

Adaptive difficulty

2012-11-23T01:00:15Z

Ids: advertised Meni Rosenfeld's proposal, now that I see how similar our ideas are!

'''Adaptive difficulty''' is a bitcoin protocol change proposal by [[User:Ids|Iain Stewart]], with the goal of letting the typical time interval from one block to the next adjust smoothly to prevailing network latency, while not compromising the strength of the blockchain, or the decentralized character of the network.

'''''EDIT 2012-11-22:''' My idea is essentially the same as that proposed by [http://en.wikipedia.org/wiki/User:Meni_Rosenfeld Meni Rosenfeld] on the [https://bitcointalk.org/ Bitcoin forums]. Please read and enjoy and critique [https://bitcointalk.org/index.php?topic=79837.0 his adaptive difficulty proposal]! (I'll leave this page here for historical completeness, but not continue working on it.)[[User:Ids|Iain Stewart]] ([[User talk:Ids|talk]]) 01:00, 23 November 2012 (GMT)''

== Background ==

The world is being wired up with ever faster connectivity. A merchant location in particular, where any kind of online transaction is desired, will usually have a fast link to either the net or specific counterparty bank(s), with paid-for higher bandwidth and lower latency than the usual domestic speeds. All but the smallest businesses where an internet presence is de rigeur now routinely choose to pay for a fast connection, sometimes choosing to pay a little extra for a guarantee of quick repair ("five nines" cover and the like).

It will therefore remain an expectation of customers that a merchant can process their transaction quickly as a matter of course. (With bitcoin, we do have the sub-community of users who desire strong anonymity and may use Tor/i2p, coin mixing services, and the like. They are tech-savvy and accept that these choices cause slowness. We can't expect that to become the broader expectation, however.)

The average 10-minute interval between blocks, and the need to wait a few blocks (6 is often cited) to achieve acceptable closeness to irreversibility of one's transaction, will likely be a barrier to ease of use in cases where an expectation of speed is firmly embedded in customers' and merchants' culture. (Even people who choose to slow down the ''submission'' of their transaction, in exchange for better anonymity for example, would still benefit from fast ''handling'' of their transaction once it has been submitted. They too may well grumble at the tens of minutes' to hours' delay on top of that of their own choosing.)

The 10-minute target interval could of course be changed, by sufficient consensus among miners and the community, to some other fixed value. Miners could boldly assert that the network latency between them "has reliably been such-and-such" (likely pleasantly short, since serious miners with their ASICs or whatever would want to pay for a fast net connection like any other net-centric business); and they could propose some multiple of this as a block interval. A change from one fixed value to another has its problems, though. A danger of choosing too short a value is that the network (of miners) fragments, into clusters who wastefully work on what they each sincerely believe is the most up-to-date block, and only later collectively purges the proliferation of short chains. The community's justified fear of this scenario would likely mean any future fixed target interval would always have to err on the side of caution (slowness).

But why have a ''fixed'' value at all? Can a protocol be fashioned where miners discover ''dynamically'' the interval that's in some sense the "best" choice, given the prevailing network latency between them? Such a protocol would have to avoid perverse incentives for any individual miner to influence the discovery process in a way that was good for that miner, but bad for the security of the blockchain.

One could imagine all sorts of formulae for deciding which way difficulty "should" go on a very fine scale (even from one block to the next) - whether similar or not-so-similar to the fortnightly difficulty adjustment already in place. The fortnightly (2016-block) adjustment is of course intended as a regulator of the impact of ''gradual'' network-wide growth or shrinkage of ''hash-rate'', and not of ''moment-to-moment'' network ''latency'' (or of moment-to-moment anything else for that matter). But one could imagine similar attempts to measure, and adjust to, latency changes, by some clever formula.

Adaptive difficulty is '''not''' an attempt at such a formula. There are good grounds for believing that the (or a candidate) block''chain'' - as opposed to the block''tree'' held at any instant by any particular miner - simply cannot contain enough information to assist with latency discovery. Only the tree, and not any one chain, contains the kind of evidence that could assist with noticing the sort of wasteful fragmentation discussed above, for example. But to compute a network-influencing parameter according to the properties of a whole blocktree, and then embed it in any one would-be winning blockchain, would be dangerous. Even ignoring the fact that the blocktree differs from miner to miner, there would be no way, later, when the rest of the tree had died by neglect, to verify that the information embedded in the winning blockchain was correctly computed from a tree prevailing at the time - and not, for example, just made up by an attacker, who can later create a spurious tree (with false timestamps), at leisure, with bits and pieces dangling off various winning-chain blocks in whatever style it takes to make the attacker's made-up information ''seem'' to have been computed from that spurious tree.

What adaptive difficulty '''is''', is something more radical than any such formula: a scheme where miners ''choose'', and announce in the header, the difficulty of ''every block they proceed to try to solve''. To those despairing that such anarchy could ever work, please read on! The regulatory function of the network - the assurance that it converges on a consensus best chain, with good immunity from attacks other than a 51% attack - is achieved by other aspects of the protocol. Out of anarchy, order will emerge.

== Anarchy in the blockchain ==

Some general remarks first. The proof of work measure of a blockchain is its sum of difficulties, not its mere number of blocks. (The expected work cost of solving two blocks of difficulty ''d'' is the same as that of solving one block of difficulty 2''d''.) If, for example, generally prevailing difficulty is halved (by whatever means), the network will solve blocks of the new difficulty at twice the previous rate; and the average value of transaction fees available for reaping in the latest block will be halved. (The adaptive difficulty protocol will scale the coin-minting block reward to the difficulty too.) A chain of such new, cheaper blocks will grow at the same expected speed ''in sum-of-difficulty terms'' as ever; it is just the ''style'' of growth which will be different (twice as many blocks, of half the difficulty and average miner reward each). The economics of block solving will change in two, mutually cancelling, ways from a miner's perspective: each hash has twice the probability of solving a block, but the reward has halved. Miners should thus be broadly indifferent (ignoring network latency issues for now) to difficulty changes in either direction, so long as they are done in that reward-scaling style.

(.....''got to here''.....)

''(uh, and now a pause folks, while I slowly learn "everything I never wanted to know about how to type in mathematical notation to a wiki but have been forced to find out"!)''

== ''...and now for something completely different! (unpolished teaser for now...)'' ==

''(Just to explain - I'm neglecting this adaptive difficulty stuff for a while [sorry!] because I '''seem''' to have almost accidentally invented [the bare beginnings of] a different system which protects against even a '''considerably-greater-than-50% attack'''! I don't want to create a page on it just yet before I thoroughly check that I'm not making a fool of myself... [well, I'll allow myself a stub, as a home for this teaser stuff: "[[Proof_of_blockchain_fair_sharing|proof of blockchain fair sharing]]"] ...but as a teaser description: it's of proof-of-stake flavour [which makes me nervous in some ways, but that's another story], and it relies on the fact that stakeholders are '''pseudonymously trackable''', unlike proof-of-work contributors, and therefore a formula for blockchain height can reward '''closeness to fair-share proportions''' in such a way that a 90% attacker finds they can't stop the honest 10% contributing too-expensive-for-attacker-to-reverse blocks which, to the attacker's chagrin, '''incorporate''' the accumulated transactions the attacker has been endlessly reversing and re-excluding in an effort to ruin the credibility of bitcoin. [And any change to the attacker's pseudonymous identity/identities destroys their bitcoin-days' stake and takes them out of the running as a big attacker for a long time.] - More to follow real soon now hopefully!)''

''(To expand a little on the above teaser: One might think that by reductio ad absurdum '''no''' system can protect against a >50% attack, because in a purported proof of immunity of the honest <50% from the malicious >50%, the labels "honest" and "malicious" ultimately have no technical meaning, and so just swapping the labels would, absurdly, give a second proof, saying that the <50% community can't "attack" [i.e. save us all from] the >50% community, in contradiction to the first proof. That reductio argument is false here - '''there is an asymmetry''' between the two communities' goals, as follows. [I'm talking about an attack to destroy the usability of bitcoin. An attack to achieve double spending is a much lower-impact event, the analysis of which I'm therefore postponing, although on general grounds the situation is probably neither especially better nor worse than with other protocols.] The >50% "community" [the attacker(s)] is trying to exclude transactions - perhaps all of them, perhaps those of specific people it wants to harass, perhaps random ones just to create fear that "I could be next" - from entering the winning blockchain. Thus it has to achieve '''total''' exclusion of the would-be blocks originating from the <50% community, who keep including the transactions to try and earn an honest profit from the fees. By contrast, the <50% community [the just-trying-to-earn-a-living honest miners] '''doesn't''' have to achieve exclusion of the attacker's blocks - they're happy with a mixed blockchain where, reasonably often, another honest block gets in and stays in. So long as they can get transactions bedded down into the blockchain, they've avoided the ruining of bitcoin as a usable system. It's this crucial asymmetry between the two communities which lets the honest miners win - a chain height formula which suitably rewards diversity of pseudonymous composition will stop even a 90% attacker "community" from achieving its, tougher, goal. I hope this indicates the general direction I'm headed. [[User:Ids|Iain Stewart]] 02:15, 21 May 2012 (GMT))''

Proof of blockchain fair sharing

2012-08-10T16:19:34Z

Ids: /* Teaser description */ corrected link to double spending page

Talk:Proof of Stake

2012-08-07T23:20:06Z

Ids: /* Malicious forking */ made it clear I'm fully aware p.o.b.f.s. is hopelessly unfinished

== Malicious forking ==

Surely proof-of-stake is vulnerable to malicious forking of the blockchain, whether motivated by double spending or just sowing destructive confusion of multiple versions?

Each version of the blockchain is a full, self-contained "version of reality". If you (the malicious party engineering a fork) burn through your "stake" - whether bitcoins owned, bitcoin days destroyed, or anything similar - on one version of the blockchain, that still doesn't stop you creating another version, starting from the same block-before-yours as you started from for your first effort, where your same "stake" still exists and hasn't been burned through. (And then another, and another... All forking from the blockchain-as-was (just before you started your malicious antics), which records your untouched stake.) So with trivial computational effort, you can create huge multiple forks; and there's no easy way for the network to pick a winner.

Proof-of-work doesn't suffer from this problem. A malicious party trying the above trick would have to perform fresh work for each fork, since the work done in finding a difficulty-satisfying hash on one fork has no transferable value to the task of finding one on the other fork(s).

Am I missing something? [[User:Ids|Iain Stewart]] 23:24, 24 March 2012 (GMT)

This is a good point, but perhaps what you are missing is the mixed proof-of-stake/proof-of-work concept. Your argument applies to pure proof-of-stake, but I don't believe that it applies to a mixed proof-of-stake/proof-of-wrok system, even one where work is a very small component. Please let me know if you think otherwise. Here are some thoughts:

1) The creation of multiple forks is only a problem if there is doubt about which chain is the correct one. This happens when multiple chains have equal cumulative difficulty (measured as the sum of all difficulties in the chain). In the case of a tie in cumulative difficulty, other miners can pick a chain to extend at random. One well-intentioned miner will get lucky and find the first block after the attacker. He will pick one of the attacker's chains, extend it, and broadcast this to the network. Even though they may have been working on other chains before, other miners will also extend this chain because it is now longer and thus more likely to survive. As usual, users awaiting txn confirmation just wait for a chain to become sufficiently long that there is no significant probaility that it will get overtaken. Once this happens, txns become extremely costly to reverse.

2) Perhaps you are worried that all other miners will extend every single competing chain. If so, all chains will grow at the same rate and it won't work to pick the winner at random. This is a problem in pure proof-of-stake. As you point out, in pure proof-of-stake extending multiple chains simultaneously has no resource cost. However, under a mixed-system, there is a non-trivial work component to any chain extension. Miners would not find it worthwhile to extend chains that have a low probability of becoming the dominant chain. I think even a pretty small computational cost would be sufficient to discourage this. [[User:Cunicula|Cunicula]] 27 March 2012

Thanks for your reply Cunicula, and apologies for taking so long to even acknowledge it. (I log in rather intermittently, although hopefully I'll be logging in more often now that I'm working on my [[Adaptive_difficulty|adaptive difficulty]] proposal. ''[and (edit 2012-05-21) a stake-based proposal (or the bare beginnings thereof) which '''seems''' to achieve the impossible and stand up to a >>50% attack! see teaser section at end of [[Adaptive_difficulty|adaptive difficulty]] page for now...]'') I'll not try to form a proper opinion of the mixed work/stake case until I've cleared my mind of some, ah, heavy-going skeptical Bayesian analysis of my own proposal (which for now is entirely within the proof-of-work universe, by the way, so not directly relevant here); but yes, thank you for making the general point that the mixed case is likely to be more robust than the pure stake case. [[User:Ids|Iain Stewart]] 22:23, 6 May 2012 (GMT)

== Proof of stake - done right - is maybe, just maybe, the way to eliminate 51% (even 90%!) attack worries altogether! ==

The vigorous debate about which of various systems, on a spectrum from pure proof of work to pure proof of stake via hybrids in between, is very enjoyable and thought-provoking. But when all is said and done, the evaluation process always boils down to "which system is least likely to allow the horror of a 51% attacker getting total control?". It's just assumed, by everybody as far as I can tell reading through the forums etc, that a 51% attack ''is'' a sure-fire route to total control, and that there's nothing anyone can ever do about ''that''.

(And make no mistake, total control will not stay benevolent, even if it starts off that way. The temptation of the total controller to start acting exactly like the banking system as we know it today - inventing ever more elaborate rules for what sort of transactions it will deign to process, how much it feels like "knowing" about its "customers", and so on - and, beyond that, the temptation of the political system to put unstoppable pressure on the controlling entity to do all these things and more - will be huge, permanent and irresistible. "Decentralisation" will become worthy only of a hollow laugh.)

But, I would like to ask: are we thinking imaginatively enough about this? What about seeking a protocol where '''even a much more than 50% attack still fails'''? (Where the "%" figure refers to whatever the scarce resource is - work, stake, an optimum Cobb-Douglas mix of the two in a hybrid system... whatever.)

It's been taken as "obvious" that a 51% attack will succeed. One unit of the scarce resource is the same as another, and 51% beats 49%, and that's all there is to it! But proof of stake means the scarce resource is '''not''' the fungible "stuff" we're used to from proof of work. Stakeholders (unlike proof-of-work miners) are '''pseudonymously trackable'''. (They sign with a pseudonymous identity when they supply bitcoin days destroyed into a coinbase transaction, or whatever similar thing they have to do to establish they're a stakeholder.) And they can't cheaply change their pseudonymous identity (sloshing bitcoins around ''before'' landing them on a coinbase throws away all those lovely bitcoin days that could have been destroyed into the coinbase).

This opens up wonderful new possibilities. We no longer have to compute the "height" of a candidate blockchain as just the sum of atomistic contributions from each block (like the sum of their difficulties, in the case of the current Bitcoin). '''We can reward preferred structures and patterns''' in the way the pseudonymously-trackable stakeholders are interleaved in the chain.

In particular: we can reward "closeness", in some mathematical sense yet to be pinned down, to a sort of proportionality or "fair sharing" pattern. So, for example, a miner or set of miners with 10% of the deployable stake, who so far has ''less'' than 10% occupation fraction of the blockchain (maybe they've barely started mining at all), can have each block they mine (and help bring their share closer to the "ideal" 10%) be deemed to contribute '''more''' incremental height to the chain than an atomistic sum formula would have given. And conversely, if they overshoot and already have 15%, a structure-aware chain height formula can allocate '''less''' incremental chain height for the overshooting fraction than an atomistic formula would have given.

I believe that if we choose such a formula cleverly, we may well be able to protect against attacks that have been considered an obvious lost cause - 51%, 80%, 90%. For note that the attacker(s), say with 90% of the stake resource, and the honest miners, with the remaining 10%, have '''asymmetrically different goals'''.

The attacker, or attacker cartel, wants (in the scenario we're traditionally most worried about) to either bring down Bitcoin, or keep it going but with control over what transactions are "acceptable" - e.g. to act like a know-your-customer bank, or to harass targeted persons or economic sectors by rejecting their transactions. To achieve this, the attacker has to keep '''all''' blocks generated by the honest 10% out of the winning blockchain. (If even an occasional one got through, in a way the attacker couldn't reverse, it would of course include all the accumulated pool of "ordinary, reasonable" transactions the attacker is trying to reject - the 10% just want to earn an honest profit by collecting all those fees.)

By contrast, the honest 10% do '''not''' have to aim for the symmetrically opposite goal (of excluding the malicious 90%). They merely have to aim for achieving a ''reasonable interleaving'' of their honest blocks into the winning blockchain. Then ordinary users will get their transactions handled (albeit more slowly than they might have got used to); and the honest miners will collect their fees.

The challenge, then, is to design the structure-aware chain height formula so that the attacker's would-be chain ''loses'' (even though, of course, a mere ''sum'' of stake-achievements block by block would allow a 90% attacker to effortlessly ''win''). The idea is that, if closeness to fair share interleaving is being especially highly rewarded, then the attacker's chain gets penalized for being far away from fairness: the 90% have 100% occupancy, and the 10% have 0%. The competing chain with some honest blocks here and there gets strongly rewarded by comparison (say for example the 90% have 93% and the 10% have 7% - that's closer to fair shares than the attacker-only chain). '''It wins!'''

The exasperated attacker fumes, "Why the hell can't I reverse these pesky honest blocks? I'm deploying 90% of the network's entire power! My chain without them should be the winner!" Ah, but structure-awareness is rewarding their presence and penalizing their absence. And with a strong enough such effect, who knows, perhaps ''any'' percentage level of such a style of attack can be thwarted!

I've created a draft page, [[Proof_of_blockchain_fair_sharing]], for ideas fitting into this general milieu. At the moment it just has a teaser description of the general idea (pretty much similar to what you've just finished reading here). I had hoped to spring a polished structure-aware height formula on the world; sadly, my first effort I believe has subtle economies and diseconomies of scale (giving stakeholders perverse incentives to either club together, cartel-like, or disaggregate, taking on multiple pseudonymous identities each). That's not the end of the world perhaps - especially since the whole point of this revolutionary new approach is that a cartel (even going above 50%) is no longer something to be terrified of - but I'd prefer long-run scale-neutrality if possible. More importantly, I now ''also'' believe my first effort doesn't achieve a strong enough bias in favour of fair-shares chains to make much difference (it maybe means a 67% attack is needed to gain total power, rather than 51%... mildly helpful I suppose, but I still aspire to the dream case where no finite attack succeeds in the long run).

Naturally, I'm hoping to invent a formula that achieves the miracle of letting any honest minority, no matter how small, achieve a non-zero occupation fraction of the winning chain. (Their achieved occupation fraction might not be exactly the "fair" one; but ''any'' non-zero fraction would let Bitcoin continue, albeit slowly and creakily, and with luck the attacker eventually concedes defeat.) To speed up progress, I thought it only fair to throw open this challenge to all mathematically-minded Bitcoin folk - after all, there are doubtless others far more talented than me! [[User:Ids|Iain Stewart]] 16:41, 21 May 2012 (GMT)

Adaptive difficulty

2012-08-07T23:06:12Z

Ids: /* ...and now for something completely different! (unpolished teaser for now...) */ made it clear I'm fully aware p.o.b.f.s. is hopelessly unfinished

'''Adaptive difficulty''' is a bitcoin protocol change proposal by [[User:Ids|Iain Stewart]], with the goal of letting the typical time interval from one block to the next adjust smoothly to prevailing network latency, while not compromising the strength of the blockchain, or the decentralized character of the network.

== Background ==

The world is being wired up with ever faster connectivity. A merchant location in particular, where any kind of online transaction is desired, will usually have a fast link to either the net or specific counterparty bank(s), with paid-for higher bandwidth and lower latency than the usual domestic speeds. All but the smallest businesses where an internet presence is de rigeur now routinely choose to pay for a fast connection, sometimes choosing to pay a little extra for a guarantee of quick repair ("five nines" cover and the like).

It will therefore remain an expectation of customers that a merchant can process their transaction quickly as a matter of course. (With bitcoin, we do have the sub-community of users who desire strong anonymity and may use Tor/i2p, coin mixing services, and the like. They are tech-savvy and accept that these choices cause slowness. We can't expect that to become the broader expectation, however.)

The average 10-minute interval between blocks, and the need to wait a few blocks (6 is often cited) to achieve acceptable closeness to irreversibility of one's transaction, will likely be a barrier to ease of use in cases where an expectation of speed is firmly embedded in customers' and merchants' culture. (Even people who choose to slow down the ''submission'' of their transaction, in exchange for better anonymity for example, would still benefit from fast ''handling'' of their transaction once it has been submitted. They too may well grumble at the tens of minutes' to hours' delay on top of that of their own choosing.)

The 10-minute target interval could of course be changed, by sufficient consensus among miners and the community, to some other fixed value. Miners could boldly assert that the network latency between them "has reliably been such-and-such" (likely pleasantly short, since serious miners with their ASICs or whatever would want to pay for a fast net connection like any other net-centric business); and they could propose some multiple of this as a block interval. A change from one fixed value to another has its problems, though. A danger of choosing too short a value is that the network (of miners) fragments, into clusters who wastefully work on what they each sincerely believe is the most up-to-date block, and only later collectively purges the proliferation of short chains. The community's justified fear of this scenario would likely mean any future fixed target interval would always have to err on the side of caution (slowness).

But why have a ''fixed'' value at all? Can a protocol be fashioned where miners discover ''dynamically'' the interval that's in some sense the "best" choice, given the prevailing network latency between them? Such a protocol would have to avoid perverse incentives for any individual miner to influence the discovery process in a way that was good for that miner, but bad for the security of the blockchain.

One could imagine all sorts of formulae for deciding which way difficulty "should" go on a very fine scale (even from one block to the next) - whether similar or not-so-similar to the fortnightly difficulty adjustment already in place. The fortnightly (2016-block) adjustment is of course intended as a regulator of the impact of ''gradual'' network-wide growth or shrinkage of ''hash-rate'', and not of ''moment-to-moment'' network ''latency'' (or of moment-to-moment anything else for that matter). But one could imagine similar attempts to measure, and adjust to, latency changes, by some clever formula.

Adaptive difficulty is '''not''' an attempt at such a formula. There are good grounds for believing that the (or a candidate) block''chain'' - as opposed to the block''tree'' held at any instant by any particular miner - simply cannot contain enough information to assist with latency discovery. Only the tree, and not any one chain, contains the kind of evidence that could assist with noticing the sort of wasteful fragmentation discussed above, for example. But to compute a network-influencing parameter according to the properties of a whole blocktree, and then embed it in any one would-be winning blockchain, would be dangerous. Even ignoring the fact that the blocktree differs from miner to miner, there would be no way, later, when the rest of the tree had died by neglect, to verify that the information embedded in the winning blockchain was correctly computed from a tree prevailing at the time - and not, for example, just made up by an attacker, who can later create a spurious tree (with false timestamps), at leisure, with bits and pieces dangling off various winning-chain blocks in whatever style it takes to make the attacker's made-up information ''seem'' to have been computed from that spurious tree.

What adaptive difficulty '''is''', is something more radical than any such formula: a scheme where miners ''choose'', and announce in the header, the difficulty of ''every block they proceed to try to solve''. To those despairing that such anarchy could ever work, please read on! The regulatory function of the network - the assurance that it converges on a consensus best chain, with good immunity from attacks other than a 51% attack - is achieved by other aspects of the protocol. Out of anarchy, order will emerge.

== Anarchy in the blockchain ==

Some general remarks first. The proof of work measure of a blockchain is its sum of difficulties, not its mere number of blocks. (The expected work cost of solving two blocks of difficulty ''d'' is the same as that of solving one block of difficulty 2''d''.) If, for example, generally prevailing difficulty is halved (by whatever means), the network will solve blocks of the new difficulty at twice the previous rate; and the average value of transaction fees available for reaping in the latest block will be halved. (The adaptive difficulty protocol will scale the coin-minting block reward to the difficulty too.) A chain of such new, cheaper blocks will grow at the same expected speed ''in sum-of-difficulty terms'' as ever; it is just the ''style'' of growth which will be different (twice as many blocks, of half the difficulty and average miner reward each). The economics of block solving will change in two, mutually cancelling, ways from a miner's perspective: each hash has twice the probability of solving a block, but the reward has halved. Miners should thus be broadly indifferent (ignoring network latency issues for now) to difficulty changes in either direction, so long as they are done in that reward-scaling style.

(.....''got to here''.....)

''(uh, and now a pause folks, while I slowly learn "everything I never wanted to know about how to type in mathematical notation to a wiki but have been forced to find out"!)''

== ''...and now for something completely different! (unpolished teaser for now...)'' ==

''(Just to explain - I'm neglecting this adaptive difficulty stuff for a while [sorry!] because I '''seem''' to have almost accidentally invented [the bare beginnings of] a different system which protects against even a '''considerably-greater-than-50% attack'''! I don't want to create a page on it just yet before I thoroughly check that I'm not making a fool of myself... [well, I'll allow myself a stub, as a home for this teaser stuff: "[[Proof_of_blockchain_fair_sharing|proof of blockchain fair sharing]]"] ...but as a teaser description: it's of proof-of-stake flavour [which makes me nervous in some ways, but that's another story], and it relies on the fact that stakeholders are '''pseudonymously trackable''', unlike proof-of-work contributors, and therefore a formula for blockchain height can reward '''closeness to fair-share proportions''' in such a way that a 90% attacker finds they can't stop the honest 10% contributing too-expensive-for-attacker-to-reverse blocks which, to the attacker's chagrin, '''incorporate''' the accumulated transactions the attacker has been endlessly reversing and re-excluding in an effort to ruin the credibility of bitcoin. [And any change to the attacker's pseudonymous identity/identities destroys their bitcoin-days' stake and takes them out of the running as a big attacker for a long time.] - More to follow real soon now hopefully!)''

''(To expand a little on the above teaser: One might think that by reductio ad absurdum '''no''' system can protect against a >50% attack, because in a purported proof of immunity of the honest <50% from the malicious >50%, the labels "honest" and "malicious" ultimately have no technical meaning, and so just swapping the labels would, absurdly, give a second proof, saying that the <50% community can't "attack" [i.e. save us all from] the >50% community, in contradiction to the first proof. That reductio argument is false here - '''there is an asymmetry''' between the two communities' goals, as follows. [I'm talking about an attack to destroy the usability of bitcoin. An attack to achieve double spending is a much lower-impact event, the analysis of which I'm therefore postponing, although on general grounds the situation is probably neither especially better nor worse than with other protocols.] The >50% "community" [the attacker(s)] is trying to exclude transactions - perhaps all of them, perhaps those of specific people it wants to harass, perhaps random ones just to create fear that "I could be next" - from entering the winning blockchain. Thus it has to achieve '''total''' exclusion of the would-be blocks originating from the <50% community, who keep including the transactions to try and earn an honest profit from the fees. By contrast, the <50% community [the just-trying-to-earn-a-living honest miners] '''doesn't''' have to achieve exclusion of the attacker's blocks - they're happy with a mixed blockchain where, reasonably often, another honest block gets in and stays in. So long as they can get transactions bedded down into the blockchain, they've avoided the ruining of bitcoin as a usable system. It's this crucial asymmetry between the two communities which lets the honest miners win - a chain height formula which suitably rewards diversity of pseudonymous composition will stop even a 90% attacker "community" from achieving its, tougher, goal. I hope this indicates the general direction I'm headed. [[User:Ids|Iain Stewart]] 02:15, 21 May 2012 (GMT))''

Help:FAQ

2012-07-01T22:56:38Z

Ids: /* What if someone creates a new block chain, or a new digital currency that renders Bitcoin obsolete? */ minor corrections and wording tweaks (still not ideal)

Here you will find answers to the most commonly asked questions.

== General ==
=== What are bitcoins? ===
Bitcoins are the unit of currency of the Bitcoin system. A commonly used shorthand for this is “BTC” to refer to a price or amount (eg: “100 BTC”).
There are such things as [[physical bitcoins]], but ultimately, a bitcoin is just a number associated with a [[Address|Bitcoin Address]]. A physical bitcoin is simply an object, such as a coin, with the number carefully embedded inside. See also an [[Introduction|easy intro]] to bitcoin.

=== How can I get Bitcoins? ===

There are a variety of ways to acquire Bitcoins:

* Accept Bitcoins as payment for goods or services.
* There are several services where you can [[buying bitcoins|trade them]] for traditional currency.
* Find a local trader on [http://tradebitcoin.com tradebitcoin] (or somewhere else) and trade with him in cash.
* Create a new [[block]] (currently yields 50 Bitcoins).
* Participate in a [[Pooled mining|mining pool]].

===Does Bitcoin guarantee an influx of free money?===

Since Bitcoin is a new technology, what it is and how it works may be initially unclear. Bitcoin is sometimes presented as being one of three things:

'''A)''' Some sort of online 'get-rich-quick' scam.

'''B)''' A loophole in the market economy, the installation of which guarantees a steady influx of cash.

'''C)''' A sure investment that will almost certainly yield a profit.

In fact, none of the above are true. Let's look at them independently.

'''Is Bitcoin a 'get-rich-quick' scheme?'''

If you've spent much time on the internet, you've probably seen many 'get-rich-quick' plans advertised on sites such as craigslist. These ads usually promise huge profits for a small amounts of easy work. Such schemes are usually pyramid- and matrix-style schemes that make money from their own employees and offer nothing of any real value. Most convince one to buy packages that will make them earn hundreds a day, which in fact have the buyer distribute more such ads, and make minute profits.

Bitcoin is in no way similar to these sorts of scams. Bitcoin doesn't promise windfall profits, and there is no way for the developers to make money from your involvement, or to take money from you. That the Bitcoin is nearly impossible to acquire without the owner's consent represents one of its greatest strengths. Bitcoin is an experimental, virtual currency; none of its developers expect to get rich off of it.

A more detailed answer to this question can be found [http://bitcointalk.org/?topic=7815.0 here].

'''Will I make money by installing the client?'''

Most people who use Bitcoin don't earn anything by doing so, and the default client has no built-in way to earn Bitcoins. A small minority of people with dedicated, high-performance hardware do earn some Bitcoins. by mining with special software, but joining Bitcoin shouldn't be construed as being the road to riches. Most Bitcoin users get involved because they the find the project conceptually interesting, and don't earn anything by doing so. This is also why you won't find much speculation about the political or economic repercussions of Bitcoin anywhere on this site: Bitcoin developers owe their dedication to the project's intellectual yieldings than more than to those of a monetary nature. Bitcoin is still taking its first baby steps; it may go on to do great things, but right now it only has something to offer

'''As an investment, is the Bitcoin a sure thing?
'''

Bitcoin represents a brand new and risky concept, the value of which is not backed by any formal entity. As a young and unestablished currency, it is only worth something because people are willing to trade it for goods and services. A quick glance at the Mt. Gox exchange reveals that the Bitcoin's worth still fluctuates often, and wildly; it lacks wide acceptance and is still vulnerable to a small-disturbances. Hacked accounts can still trigger major sell-offs, and fluctuations can transform into positive feedback loops that destabilize the entire network. Anyone who puts money into Bitcoin runs the severe risk of losing all of it. As Bitcoin becomes better known and more widely accepted, it should stabilize, but right now, and for some time to come, it will remain unpredictable. Any investment in Bitcoin represents a highly insecure strategy.

It is people who take risks, and trade things with intrinsic value for Bitcoins, who give it value. For Bitcoin to become an accepted currency, users will have to go out on limbs, and be prepared to take smalls losses. However, Bitcoin is far from stable and probably will not be anytime in the near future, and no one should invest in it funds they cannot afford to lose. Ultimately, Bitcoin is a currency, and is intended for trade, not investment.

=== Can I buy Bitcoins with Paypal? ===

It is possible to buy [[physical Bitcoins]] with PayPal. It is much more difficult to buy digital Bitcoins with PayPal, because of the chargeback risk to the seller. Sales of physical goods present a lower risk than sales of digital ones.

While it's possible to find an individual who wishes to sell Bitcoin to you via Paypal, (perhaps via [http://www.bitcoin-otc.com/ #bitcoin-otc] ) most major exchanges do not allow funding through Paypal. This is due to repeated cases where someone pays for Bitcoins with Paypal, receives their Bitcoins, and then fraudulently complains to Paypal that they never received their goods. Paypal too often sides with the fraudulent buyer in this case, and so exchangers no longer allow this method of funding.

Buying Bitcoins from individuals with this method is still possible, but requires mutual trust. In this case, Bitcoin seller beware.

=== Where can I find a forum of Bitcoin users? ===

There is no longer an "official" forum for Bitcoin. The [[Bitcoin:Community_portal#Bitcoin_Community_Forums_on_various_platforms|Community Portal]] includes links to some forums.

=== How are new Bitcoins created? ===

[[File:total_bitcoins_over_time_graph.png|thumb|Number of bitcoins over time, assuming a perfect 10-minute interval.]]
New coins are generated by a network node each time it finds the solution to a certain mathematical problem (i.e. creates a new [[block]]), which is difficult to perform and can demonstrate a [[proof of work]]. The reward for solving a block is [[Controlled Currency Supply|automatically adjusted]] so that in the first 4 years of the Bitcoin network, 10,500,000 BTC will be created. The amount is halved each 4 years, so it will be 5,250,000 over years 4-8, 2,625,000 over years 8-12 and so on. Thus the total number of bitcoins in existence will not exceed 21,000,000. See [[Controlled Currency Supply]].

Blocks are [[Mining|generated]] every 10 minutes, on average. As the number of people who attempt to generate these new coins changes, the difficulty of creating new coins changes. This happens in a manner that is agreed upon in advance by the network as a whole, based upon the time taken to generate the previous 2016 blocks. The difficulty is therefore related to the average computing resources devoted to generate these new coins over the time it took to create these previous blocks. The likelihood of somebody creating a block is based on the calculation speed of the system that they are using compared to the aggregate calculation speed of all the other systems generating blocks on the network. See [[Mining]].

=== What's the current total number of Bitcoins in existence? ===

[http://blockexplorer.com/q/totalbc Current count]. Also see [https://blockchain.info/charts/total-bitcoins Total Bitcoins in circulation chart]

The number of blocks times the coin value of a block is the number of coins in existence. The coin value of a block is 50 BTC for each of the first 210,000 blocks, 25 BTC for the next 210,000 blocks, then 12.5 BTC, 6.25 BTC and so on.

=== How divisible are Bitcoins? ===

Technically, a Bitcoin can be divided down to 8 decimals using existing data structures, so 0.00000001 BTC is the smallest amount currently possible. Discussions about and ideas for ways to provide for even smaller quantities of Bitcoins may be created in the future if the need for them ever arises.

=== What do I call the various denominations of Bitcoins? ===

There is a lot of discussion about the naming of these fractions of Bitcoins. The leading candidates are:

* 1 BTC = 1 Bitcoin
* 0.01 BTC = 1 cBTC = 1 Centi-Bitcoin (also referred to as Bitcent)
* 0.001 BTC = 1 mBTC = 1 Milli-Bitcoin (also referred to as mbit (pronounced em-bit) or millibit)
* 0.000 001 BTC = 1 μBTC = 1 Micro-Bitcoin (also referred to as ubit (pronounced yu-bit) or microbit)

The above follows the accepted international SI units for thousandths, millionths and billionths. There are many arguments against the special case of 0.01 BTC since it is unlikely to represent anything meaningful as the Bitcoin economy grows (it certainly won't be the equivalent of 0.01 USD, GBP or EUR). Equally, the inclusion of existing national currency denominations such as "cent", "nickel", "dime", "pence", "pound", "kopek" and so on are to be discouraged. This is a worldwide currency.

One exception is the "satoshi" which is smallest denomination currently possible

* 0.000 000 01 BTC = 1 Satoshi (pronounced sa-toh-shee)

which is so named in honour of Satoshi Nakamoto the pseudonym of the inventor of Bitcoin.

For an overview of all defined units of Bitcoin (including less common and niche units), see [[Units]].

Further discussion on this topic can be found on the forums here:

* [http://forum.bitcoin.org/index.php?topic=14438.msg195287#msg195287 We need names]
* [http://forum.bitcoin.org/index.php?topic=8282.0 What to call 0.001 BTC]

=== How does the halving work when the number gets really small? ===

The reward will go from 0.00000001 BTC to 0. Then no more coins will likely be created.

The calculation is done as a right bitwise shift of a 64-bit signed integer, which means it is divided by 2 and rounded down. The integer is equal to the value in BTC * 100,000,000. This is how all Bitcoin balances/values are stored internally.

Keep in mind that using current rules this will take nearly 100 years before it becomes an issue and Bitcoins may change considerably before that happens.

=== How long will it take to generate all the coins? ===

The last block that will generate coins will be block #6,929,999. This should be generated around year 2140. Then the total number of coins in circulation will remain static at 20,999,999.9769 BTC.

Even if the allowed precision is expanded from the current 8 decimals, the total BTC in circulation will always be slightly below 21 million (assuming everything else stays the same). For example, with 16 decimals of precision, the end total would be 20999999.999999999496 BTC.

=== If no more coins are going to be generated, will more blocks be created? ===

Absolutely! Even before the creation of coins ends, the use of [[transaction fee|transaction fees]] will likely make creating new blocks more valuable from the fees than the new coins being created. When coin generation ends, what will sustain the ability to use bitcoins will be these fees entirely. There will be blocks generated after block #6,929,999.

=== But if no more coins are generated, what happens when Bitcoins are lost? Won't that be a problem? ===

Because of the law of supply and demand, when fewer bitcoins are available the ones that are left will be in higher demand, and therefore will have a higher value. So, as Bitcoins are lost, the remaining bitcoins will eventually increase in value to compensate. As the value of a bitcoin increases, the number of bitcoins required to purchase an item '''de'''creases. This is a [[Deflationary spiral|deflationary economic model]]. As the average transaction size reduces, transactions will probably be denominated in sub-units of a bitcoin such as millibitcoins ("Millies") or microbitcoins ("Mikes").

The Bitcoin protocol uses a base unit of one hundred-millionth of a Bitcoin ("a Satoshi"), but unused bits are available in the protocol fields that could be used to denote even smaller subdivisions.

=== If every transaction is broadcast via the network, does Bitcoin scale? ===
The Bitcoin protocol allows lightweight clients that can use Bitcoin without downloading the entire transaction history. As traffic grows and this becomes more critical, implementations of the concept will be developed. Full network nodes will at some point become a more specialized service.

With some modifications to the software, full Bitcoin nodes could easily keep up with both VISA and MasterCard combined, using only fairly modest hardware (a couple of racks of machines using todays hardware). It's worth noting that the MasterCard network is structured somewhat like Bitcoin itself - as a peer to peer broadcast network.

Learn more about [[Scalability]].

==Economy==
=== Where does the value of Bitcoin stem from? What backs up Bitcoin? ===
Bitcoins have value because they are useful and because they are [[Controlled Currency Supply|scarce]]. As they are accepted by more merchants, their value will [http://en.wikipedia.org/wiki/Sticky_%28economics%29 stabilize]. See the [[Trade|list of Bitcoin-accepting sites]].

When we say that a currency is backed up by gold, we mean that there's a promise in place that you can exchange the currency for gold. Bitcoins, like dollars and euros, are not backed up by anything except the variety of merchants that accept them.

It's a common misconception that Bitcoins gain their value from the cost of electricity required to generate them. Cost doesn't equal value – hiring 1,000 men to shovel a big hole in the ground may be costly, but not valuable. Also, even though scarcity is a critical requirement for a useful currency, it alone doesn't make anything valuable. For example, your fingerprints are scarce, but that doesn't mean they have any exchange value.

=== Is Bitcoin a bubble? ===
Yes, in the same way as the euro and dollar are. They only have value in exchange and have no inherent value. If everyone suddenly stopped accepting your dollars, euros or bitcoins, the "bubble" would burst and their value would drop to zero. But that is unlikely to happen: even in Somalia, where the government collapsed 20 years ago, [http://en.wikipedia.org/wiki/Somali_shilling Somali shillings] are still accepted as payment.

=== Is Bitcoin a Ponzi scheme? ===
In a Ponzi Scheme, the founders persuade investors that they’ll profit. Bitcoin does not make such a guarantee. There is no central entity, just individuals building an economy.

A ponzi scheme is a zero sum game. Early adopters can only profit at the expense of late adopters. Bitcoin has possible win-win outcomes. Early adopters profit from the rise in value. Late adopters, and indeed, society as a whole, benefit from the usefulness of a stable, fast, inexpensive, and widely accepted p2p currency.

The fact that early adopters benefit more doesn't alone make anything a Ponzi scheme. All good investments in successful companies have this quality.

=== Doesn't Bitcoin unfairly benefit early adopters? ===
Early adopters have a large number of bitcoins now because they took a risk and invested resources in an unproven technology. By so doing, they have helped Bitcoin become what it is now and what it will be in the future (hopefully, a ubiquitous decentralized digital currency). It is only fair they will reap the benefits of their successful investment.

In any case, any bitcoin generated will probably change hands dozens of time as a medium of exchange, so the profit made from the initial distribution will be insignificant compared to the total commerce enabled by Bitcoin.

Since the pricing of Bitcoins has fallen greatly from its June 2011 peak, prices today are much more similar to those enjoyed by many early adopters. Those who are buying Bitcoins today likely believe that Bitcoin will grow significantly in the future. Setting aside the brief opportunity to have sold Bitcoins at the June 2011 peak enjoyed by few, the early-adopter window is arguably still open.

===Won't loss of wallets and the finite amount of Bitcoins create excessive deflation, destroying Bitcoin? ===
Worries about Bitcoin being destroyed by deflation are not entirely unfounded. Unlike most currencies, which experience inflation as their founding institutions create more and more units, Bitcoin will likely experience gradual deflation with the passage of time. Bitcoin is unique in that only a small amount of units will ever be produced (twenty-one million to be exact), this number has been known since the project's inception, and the units are created at a predicable rate.

Also, Bitcoin users are faced with a danger that doesn't threaten users of any other currency: if a Bitcoin user loses his wallet, his money is gone forever, unless he finds it again. And not just to him; it's gone completely out of circulation, rendered utterly inaccessible to anyone. As people will lose their wallets, the total number of Bitcoins will slowly decrease.

Therefore, Bitcoin seems to be faced with a unique problem. Whereas most currencies inflate over time, Bitcoin will mostly likely do the just the opposite. Time will see the irretrievable loss of an ever-increasing number of Bitcoins. An already small number will be permanently whittled down further and further. And as there become fewer and fewer Bitcoins, the laws of supply and demand suggest that their value will probably continually rise.

Thus Bitcoin is bound to once again stray into mysterious territory, because no one exactly knows what happens to a currency that grows continually more valuable. Economists generally agree that a low level of inflation is a good thing for a currency, but nobody is quite sure about what might happens to one that continually deflates. Although deflation could hardly be called a rare phenomenon, steady, constant deflation is unheard of. There may be a lot of speculation, no one has any hard data to back up their claims.

That being said, there is a mechanism in place to combat the obvious consequences. Extreme deflation would render most currencies highly impractical: if a single Canadian dollar could suddenly buy the holder a car, how would one go about buying bread or candy? Even pennies would fetch more than a person could carry. Bitcoin, however, offers a simple and stylish solution: infinite divisibility. Bitcoins can be divided up and trade into as small of pieces as one wants, so no matter how valuable Bitcoins become, one can trade them in practical quantities.

In fact, infinite divisibility should allow Bitcoins to function in cases of extreme wallet loss. Even if, in the far future, so many people have lost their wallets that only a single Bitcoin, or a fraction of one, remains, Bitcoin should continue to function just fine. No one can claim to be sure what is going to happen, but deflation may prove to present a smaller threat than many expect.

For more information, see the [[Deflationary spiral]] page.

=== What if someone bought up all the existing Bitcoins? ===
Bitcoin markets are competitive -- meaning the price of a bitcoin will rise or fall depending on supply and demand at certain price levels. Only a fraction of bitcoins issued to date are found on the exchange markets for sale. So even though technically a buyer with lots of money could buy all the bitcoins offered for sale, unless those holding the rest of the bitcoins offer them for sale as well, even the wealthiest, most determined buyer can't get at them.

Additionally, new currency continues to be issued daily and will continue to do so for decades though over time the rate at which they are issued declines to insignificant levels. Those who are mining aren't obligated to sell their bitcoins so not all bitcoins will make it to the markets even.

This situation doesn't suggest, however, that the markets aren't vulnerable to price manipulation. It doesn't take significant amounts of money to move the market price up or down and thus Bitcoin remains a volatile asset.

===What if someone creates a new block chain, or a new digital currency that renders Bitcoin obsolete?===

That the block chain cannot be easily forked represents one of the central security mechanisms of Bitcoin. Given the choice between two block chains, a Bitcoin miner always chooses the longer one - that is to say, the one with the more complex hash. Thusly, it ensures that each user can only spend their bitcoins once, and that no user gets ripped off.

As a consequence of the block chain structure, there may at any time be many different sub-branches, and the possibility always exists of a transaction being over-written by the longest branch, if it has been recorded in a shorter one. The older a transaction is though, the lower its chances of being over-written, and the higher of becoming permanent. Although the block chain prevents one from spending more Bitcoins than one has, it means that transactions can be accidentally nullified.

A new block chain would leave the network vulnerable to [[double-spending|double-spend]] attacks. However, the creation of a viable new chain presents considerable difficulty, and the possibility does not present much of a risk.

Bitcoin will always choose the longer Block Chain and determines the relative length of two branches by the complexities of their hashes. Since the hash of each new block is made from that of the block preceding it, to create a block with a more complex hash, one must be prepared to do more computation than has been done by the entire Bitcoin network from the fork point up to the newest of the blocks one is trying to supersede. Needless to say, such an undertaking would require a very large amount of processing power and since Bitcoin is continually growing and expanding, it will likely only require more with the passage of time.

A much more distinct and real threat to the Bitcoin use is the development of other, superior virtual currencies, which could supplant Bitcoin and render it obsolete and valueless.

A great deal of careful thought and ingenuity has gone into the development of Bitcoin, but it is the first of its breed, a prototype, and vulnerable to more highly-evolved competitors. At present, any threatening rivals have yet to rear its head; Bitcoin remains the first and foremost private virtual currency, but we can offer no guarantees that it will retain that position. It would certainly be in keeping with internet history for similar system built from the same principles to supersede and cast Bitcoin into obsolescence, after time had revealed its major shortcomings. Friendster and Myspace suffered similar fates at the hand of Facebook, Napster was ousted by Limeware, Bearshare and torrent applications, and Skype has all but crushed the last few disciples of the Microsoft Messenger army.

This may sound rather foreboding, so bear in mind that introduction of new and possibly better virtual currencies will not necessarily herald Bitcoin's demise. If Bitcoin establishes itself sufficiently firmly before the inception of the next generation of private, online currencies as to gain widespread acceptance and general stability, future currencies may pose little threat even if they can claim superior design.

==Sending and Receiving Payments==

=== Why do I have to wait 10 minutes before I can spend money I received? ===

10 minutes is the average time taken to find a block. It can be significantly more or less time than that depending on luck; 10 minutes is simply the average case.

You can see how long all other recent transactions have taken here: [http://bitcoinstats.org/ BitcoinStats.org].

[[Blocks]] (shown as "confirmations" in the GUI) are how the Bitcoin achieves consensus on who owns what. Once a block is found everyone agrees that you now own those coins, so you can spend them again. Until then it's possible that some network nodes believe otherwise, if somebody is attempting to defraud the system by reversing a transaction. The more confirmations a transaction has, the less risk there is of a reversal. Only 6 blocks or 1 hour is enough to make reversal computationally impractical. This is dramatically better than credit cards which can see chargebacks occur up to three months after the original transaction!

Ten minutes was specifically chosen by [[Satoshi]] as a tradeoff between propagation time of new blocks in large networks and the amount of work wasted due to chain splits. For a more technical explanation, see Satoshi's [http://www.bitcoin.org/bitcoin.pdf original technical paper].

[[File:TransactionConfirmationTimesExample.PNG]]

=== Do you have to wait until my transactions are confirmed in order to buy or sell things with Bitcoin? ===

YES, you do, IF the transaction is non-recourse. The Bitcoin reference software does not display transactions as confirmed until six blocks have passed (confirmations). As transactions are burred in the chain they become increasingly non-reversible but are very reversible before the first confirmation. Two to six confirmations are recommended for non-recourse situations depending on the value of the transactions involved.

When people ask this question they are usually thinking about applications like supermarkets. This generally is a recourse situation: if somebody tries to double-spend on a face-to-face transaction it might work a few times, but probabalistically speaking eventually one of the double-spends will get noticed, and the penalty for shoplifting charges in most localities is calibrated to be several times worse than the proceeds of a single shoplifting event.

Double-spends might be a concern for something like a snack machine in a low-traffic area with no nearby security cameras. Such a machine shouldn't honor 0-confirmation payments, and should instead use some other mechanism of clearing Bitcoin or validating transactions against reversal, see the wiki article [[Myths#Point_of_sale_with_bitcoins_isn.27t_possible_because_of_the_10_minute_wait_for_confirmation|here]] for alternatives.

When people ask this question they are usually thinking about applications that require immediate payment processing, like supermarkets or snack machines. Here is one way to reverse an unconfirmed payment:

A [[Double-spending#Finney_attack|Finney attack]], in which an attacker mines a block containing a movement of some coins back to themselves. Once they find a block solution, they quickly go to a merchant and make a purchase, then broadcast the block, thus taking back the coins. This attack is a risk primarily for goods that are dispatched immediately, like song downloads or currency trades. Because the attacker can't choose the time of the attack, it isn't a risk for merchants such as supermarkets where you can't choose exactly when to pay (due to queues, etc). The attack can fail if somebody else finds a block containing the purchasing transaction before you release your own block, therefore, merchants can reduce but not eliminate the risk by making purchasers wait some length of time that's less than a confirm.

Because pulling off this attack is not trivial, merchants who need to sell things automatically and instantly are most likely to just price the cost of reversal fraud in, or use insurance.

=== I was sent some bitcoins and they haven't arrived yet! Where are they? ===

Don't panic! There are a number of reasons why your bitcoins might not show up yet, and a number of ways to diagnose them.

The latest version of the Bitcoin-Qt client will tell you how far it has to go yet in downloading the blockchain. Hover over the icon in the bottom right corner of the client to learn your client's status.

If it has not caught up then it's possible that your transaction hasn't been included in a block yet.

You can check pending transactions in the network by going [http://bitcoincharts.com/bitcoin/ here] and then searching for your address. If the transaction is listed here then it's a matter of waiting until it gets included in a block before it will show in your client.

Bear in mind that if the transaction is based on a coin that was in a recent transaction then it could be considered a low priority transaction take longer to transfer if the transaction fee paid isn't high enough. Very low priority transactions with 0 fees might take hours or days to be included in a block.

=== Why does my Bitcoin address keep changing? ===

Whenever the address listed in "Your address" receives a transaction, Bitcoin replaces it with a new address. This is meant to encourage you to use a new address for every transaction, which enhances [[anonymity]]. All of your old addresses are still usable: you can see them in ''Settings -> Your Receiving Addresses''.

===How much will the transaction fee be?===

Some transactions might require a [[transaction fee]] for them to get confirmed in a timely manner. The transaction fee is processed by and received by the bitcoin miner. The most recent version of the Bitcoin client will estimate an appropriate fee when a fee might be required.

The fee is added to the payment amount. For example, if you are sending a 1.234 BTC payment and the client requires a 0.0005 BTC fee, then 1.2345 BTC will be subtracted from the wallet balance for the entire transaction and the address for where the payment was sent will receive a payment of 1.234 BTC.

In cases where a fee is required it is required because your transaction objectively looks like a denial of service attack to the bitcoin system, either due to it being burdensome to transmit or it recycles bitcoins you recently received. The wallet software attempts to avoid generating burdensome transactions, but it isn't always able if the funds in your wallet are new or are composed of many very tiny payments.

Because the fee is related to the amount of data that makes up the transaction and not to the amount of bitcoins being sent, the fee may seem extremely low (0.0005 BTC for a 1,000 BTC transfer) or unfairly high (0.004 BTC for a 0.02 BTC payment, or about 20%). If you are receiving tiny amounts (e.g., as small payments from a mining pool) then fees when sending will be higher than if your activity follows a more normal consumer or business transaction pattern. As of bitcoin 0.5.3 the required fee it will ask for will not be higher than 0.05 BTC, though for most users there is usually no required fee at all and 0.0005 is the most common when one is required.

=== What happens when someone sends me a bitcoin but my computer is powered off? ===

Bitcoins aren't actually "sent" to your wallet, the software only uses that term so that we can use the currency without having to learn new concepts. Your wallet is only needed when you wish to spend coins that you've received.

The coins that were sent to you when the client was not running will later appear as if they were received in your wallet when you later launch the client. It will download blocks and catch up with any transactions it didn't already have.

=== How long does "synchronizing" take when the bitcoin client is first installed? What is it doing? ===

The popular bitcoin client software from bitcoin.org implements a "full" bitcoin node: It can carry out all the duties of the bitcoin P2P system, it isn't simply a "client". One of the principles behind the operation of full bitcoin nodes is that they don't trust that the other participants have followed the rules of the bitcoin system. During synchronization the software is processing historical bitcoin transactions and making sure for itself that all of the rules of the system have been correctly followed.

In normal operation after synchronizing the software should use a hardly noticeable amount of IO, CPU, or network capacity.

The initial validation is very disk IO intensive so the amount of time to synchronize depend on your disk speed and, to a lesser extent, your cpu speed. It can take anywhere from a few hours to a day or so. You can use the software while this process is going on, but you may not see recent payments to you until the synchronization has caught up to the point where those transactions happened.

If this is too long for you, you can download a pre-synchronized blockchain from [http://eu1.bitcoincharts.com/blockchain/ http://eu1.bitcoincharts.com/blockchain/]. Alternatively, you can try an alternative "lite" client such as Multibit or a super-light client like electrum though these clients have somewhat weaker security, are less mature, and don't contribute to the health of the P2P network.

==Networking==
=== Do I need to configure my firewall to run bitcoin? ===

Bitcoin will connect to other nodes, usually on tcp port 8333. You will need to allow outgoing TCP connections to port 8333 if you want to allow your bitcoin client to connect to many nodes. [[Testnet]] uses tcp port 18333 instead of 8333.

If you want to restrict your firewall rules to a few ips, you can find stable nodes in the [[Fallback Nodes|fallback nodes list]].

=== How does the peer finding mechanism work? ===

Bitcoin finds peers primarily by forwarding peer announcements within its own network and each node saves a database of peers that it's aware of for use in the future. In order to bootstrap this process Bitcoin needs a list of initial peers, these can be provided manually but normally it obtains them by querying a set of DNS domain names which have automatically updated lists, if that doesn't work it falls back to a build-in list which is updated from time to time in new versions of the software. There is also an IRC based mechanism but it is disabled by default.

==Mining==
===What is mining?===
[[Mining]] is the process of spending computation power to secure Bitcoin transactions against reversal and introducing new Bitcoins to the system.

Technically speaking, mining is the calculation of a [[hash]] of the a block header, which includes among other things a reference to the previous block, a hash of a set of transactions and a [[nonce]]. If the hash value is found to be less than the current [[target]] (which is inversely proportional to the [[difficulty]]), a new block is formed and the miner gets the newly generated Bitcoins (50 per block at current levels). If the hash is not less than the current target, a new nonce is tried, and a new hash is calculated. This is done millions of times per second by each miner.

===Is mining used for some useful computation?===
The computations done when mining are internal to Bitcoin and not related to any other distributed computing projects. They serve the purpose of securing the Bitcoin network, which is useful.

===Is it not a waste of energy?===
Spending energy on creating and securing a free monetary system is hardly a waste. Also, services necessary for the operation of currently widespread monetary systems, such as banks and credit card companies, also spend energy, arguably more than Bitcoin would.

===Why don't we use calculations that are also useful for some other purpose?===
To provide security for the Bitcoin network, the calculations involved need to have some very specific features. These features are incompatible with leveraging the computation for other purposes.

===How does the proof-of-work system help secure Bitcoin?===
To give a general idea of the mining process, imagine this setup:

payload = <some data related to things happening on the Bitcoin network>
nonce = 1
hash = [http://en.wikipedia.org/wiki/SHA2 SHA2]( [http://en.wikipedia.org/wiki/SHA2 SHA2]( payload + nonce ) )

The work performed by a miner consists of repeatedly increasing "nonce" until
the hash function yields a value, that has the rare property of being below a certain
target threshold. (In other words: The hash "starts with a certain number of zeroes",
if you display it in the fixed-length representation, that is typically used.)

As can be seen, the mining process doesn't compute anything special. It merely
tries to find a number (also referred to as nonce) which - in combination with the payload -
results in a hash with special properties.

The advantage of using such a mechanism consists of the fact, that it is very easy to check a result: Given
the payload and a specific nonce, only a single call of the hashing function
is needed to verify that the hash has the required properties. Since there is no
known way to find these hashes other than brute force, this can be used as a "proof of work"
that someone invested a lot of computing power to find the correct nonce for this payload.

This feature is then used in the Bitcoin network to secure various aspects. An attacker
that wants to introduce malicious payload data into the network, will need to do the
required proof of work before it will be accepted. And as long as honest miners have more
computing power, they can always outpace an attacker.

Also see [http://en.wikipedia.org/wiki/SHA2 SHA2] and [http://en.wikipedia.org/wiki/Proof-of-work_system Proof-of-work system] on Wikipedia.

===Why was the "Generate coin" option of the client software removed?===

In the early days of Bitcoin, it was easy for anyone to find new blocks using standard CPUs. As more and more people started mining, the [[difficulty]] of finding new blocks has greatly increased to the point where the average time for a CPU to find a single block can be many years. The only cost-effective method of [[Mining|mining]] is using a high-end graphics card with special software (see also [[Why a GPU mines faster than a CPU]]) and/or joining a [[Bitcoin Pool|mining pool]]. Since solo CPU mining is essentially useless, it was removed from the GUI of the Bitcoin software.

==Security==

===Could miners collude to give themselves money or to fundamentally change the nature of Bitcoin?===

There are two questions in here. Let's look at them separately.

'''Could miners gang up and give themselves money?'''

Mining itself is the process of creating new blocks in the block chain. Each block contains a list of all the transactions that have taken place across the entire Bitcoin network since the last block was created, as well as a hash of the previous block. New blocks are 'mined', or rather, generated, by Bitcoin clients correctly guessing sequences of characters in codes called 'hashes,' which are created using information from previous blocks. Bitcoin users may download specialized 'mining' software, which allows them to dedicate some amount of their processing power – however large or small – to guessing at strings within the hash of the previous block. Whoever makes the right guess first, thus creating a new block, receives a reward in Bitcoins.

The block chain is one of the two structures that makes Bitcoin secure, the other being the public-key encryption system on which Bitcoin trade is based. The block chain assures that not only is every single transaction that ever takes place recorded, but that every single transaction is recorded on the computer of anyone who chooses to store the relevant information. Many, many users have complete records of every transaction in Bitcoins history readily available to them at any point, and anyone who wants in the information can obtain it with ease. These things make Bitcoin very hard to fool.

The Bitcoin network takes considerable processing power to run, and since those with the most processing power can make the most guesses, those who put the most power toward to sustaining the network earn the most currency. Each correct guess yields, at present, fifty Bitcoins, and as Bitcoins are presently worth something (although the value still fluctuates) every miner who earns any number of Bitcoins makes money. Some miners pull in Bitcoins on their own; and some also join or form pools wherein all who contribute earn a share of the profits.

Therefore, first answer is a vehement “yes” – no only can miners collude to get more money, Bitcoin is designed to encourage them to do so. Bitcoin pools are communal affairs, and there is nothing dishonest or underhanded about them.

Of course, the real question is:

'''Can they do so in ways not sanction by Bitcoin developers? Is there any way to rip off the network and make loads of money dishonestly?'''

Bitcoin isn't infallible. It can be cheated. But doing so is extremely difficult. Bitcoin was designed to evade some of the central problems with modern currencies – namely, that their trustworthiness hinges upon that of people who might not have user's best interests in mind. Every currency in the world (other than Bitcoin) is controlled by large institutions who keep track of what's done with done with it, and who can manipulate it's value. And every other currency has value because people trust the institutions that control them.

Bitcoin doesn't ask that it users trust any institution. Its security is based on the cryptography that is an integral part of its structure, and that is readily available for any and all to see. Instead of one entity keeping track of transactions, the entire network does, so Bitcoins are astoundingly difficult to steal, or double-spend. Bitcoins are created in a regular and predictable fashion, and by many different users, so no one can decide to make a whole lot more and lessen their value. In short, Bitcoin is designed to be inflation-proof, double-spend-proof and completely distributed.

Nonetheless, there are a few ways that one can acquire Bitcoins dishonestly. Firstly, one can steal private keys. Key theft isn't something that Bitcoin security has been designed to prevent: it's up to users to keep their's safe. But the cryptography is designed so that it is completely impossible to deduce someone's private from their public one. So long as you keep your private key to yourself, you don't have much to worry about. Furthermore, one could theoretically create a new block chain, but due to the way in which the block chain is constructed, this would be extremely difficult and require massive amounts of processing power. A full explanation of the difficulties involved can be found in the [[block chain]] article.

Bitcoin can be ripped off – but doing so would be extremely hard and require considerable expertise and a staggering amount of processing power. And it's only going to get harder with the passage of time. Bitcoin is isn't impenetrable, but it's close enough to put any real worries in the peripherals.

'''Could miners fundamentally change the nature of Bitcoin?'''

Once again, almost certainly not.

Bitcoin is a distributed network, so any changes implemented to the system must be accepted by all users. Someone trying to change the way Bitcoins are generated would have to convince every user to download and use their software – so the only changes that would go through are those that would be equally benefit all users.

And thus, it is more or less impossible for any person to change the function of Bitcoin to their advantage. If users don't like the changes, they won't take, and if uses do like them, then they'll help everyone equally. Of course, one can conceive of a situation where someone manages to get a change pushed through that provides them with an advantage that no one notices, but given that Bitcoin is structurally relatively simple, it is unlikely that any major changes will go through without someone noticing first.

The fact that such changes are so difficult to make testifies to the fully distributed nature of Bitcoin. Any centrally-controlled currency can be modified by its central agency without the consent of its adherents. Bitcoin has no central authority, so it changes only at the behest of the whole community. Bitcoins development represents a kind of collective evolution; the first of its kind among currencies.

==Help==
===I'd like to learn more. Where can I get help?===

* Read the [[Introduction|introduction to bitcoin]]
* See the videos, podcasts, and blog posts from the [[Press]]
* Read and post on the [[Bitcoin:Community_portal#Bitcoin_Community_Forums|forums]]
* Chat on one of the [[Bitcoin:Community_portal#IRC_Chat|Bitcoin IRC]] channels
* Listen to [http://omegataupodcast.net/2011/03/59-bitcoin-a-digital-decentralized-currency/ this podcast], which goes into the details of how bitcoin works
* Ask questions on the [http://bitcoin.stackexchange.com Bitcoin Stack Exchange]

==See Also==

* [[Man page]]
* [[Introduction]]

[[de:FAQ]]
[[zh-cn:FAQ]]
[[fr:FAQ]]
[[ru:FAQ]]

[[Category:Technical]]
[[Category:Vocabulary]]

Wallet import format

2012-06-23T20:47:58Z

Ids: /* Private key to WIF */ corrected where to append checksum

Wallet Import Format (WIF, also known as Wallet Export Format) is a way of encoding a private ECDSA key so as to make it easier to copy.

A testing suite is available for encoding and decoding of WIF at:

http://gobittest.appspot.com/PrivateKey

==Private key to WIF==
1 - Take a private key
0C28FCA386C7A227600B2FE50B7CAE11EC86D3BF1FBE471BE89827E19D72AA1D
2 - Add a 0x80 byte in front of it
800C28FCA386C7A227600B2FE50B7CAE11EC86D3BF1FBE471BE89827E19D72AA1D
3 - Perform SHA-256 hash on the extended key
8147786C4D15106333BF278D71DADAF1079EF2D2440A4DDE37D747DED5403592
4 - Perform SHA-256 hash on result of SHA-256 hash
507A5B8DFED0FC6FE8801743720CEDEC06AA5C6FCA72B07C49964492FB98A714
5 - Take the first 4 bytes of the second SHA-256 hash, this is the checksum
507A5B8D
6 - Add the 4 checksum bytes from point 5 at the end of the extended key from point 2
800C28FCA386C7A227600B2FE50B7CAE11EC86D3BF1FBE471BE89827E19D72AA1D507A5B8D
7 - Convert the result from a byte string into a base58 string using [[Base58Check encoding]]. This is the Wallet Import Format
5HueCGU8rMjxEXxiPuD5BDku4MkFqeZyd4dZ1jvhTVqvbTLvyTJ

==WIF to private key==
1 - Take a Wallet Import Format string
5HueCGU8rMjxEXxiPuD5BDku4MkFqeZyd4dZ1jvhTVqvbTLvyTJ
2 - Convert it to a byte string using [[Base58Check encoding]]
800C28FCA386C7A227600B2FE50B7CAE11EC86D3BF1FBE471BE89827E19D72AA1D507A5B8D
3 - Drop the last 4 checksum bytes from the byte string
800C28FCA386C7A227600B2FE50B7CAE11EC86D3BF1FBE471BE89827E19D72AA1D
4 - Drop the first byte (it should be 0x80). This is the private key
0C28FCA386C7A227600B2FE50B7CAE11EC86D3BF1FBE471BE89827E19D72AA1D
==WIF checksum checking==
1 - Take the Wallet Import Format string
5HueCGU8rMjxEXxiPuD5BDku4MkFqeZyd4dZ1jvhTVqvbTLvyTJ
2 - Convert it to a byte string using [[Base58Check encoding]]
800C28FCA386C7A227600B2FE50B7CAE11EC86D3BF1FBE471BE89827E19D72AA1D507A5B8D
3 - Drop the last 4 checksum bytes from the byte string
800C28FCA386C7A227600B2FE50B7CAE11EC86D3BF1FBE471BE89827E19D72AA1D
3 - Perform SHA-256 hash on the shortened string
8147786C4D15106333BF278D71DADAF1079EF2D2440A4DDE37D747DED5403592
4 - Perform SHA-256 hash on result of SHA-256 hash
507A5B8DFED0FC6FE8801743720CEDEC06AA5C6FCA72B07C49964492FB98A714
5 - Take the first 4 bytes of the second SHA-256 hash, this is the checksum
507A5B8D
6 - Make sure it is the same, as the last 4 bytes from point 2
507A5B8D
7 - If they are, and the byte string from point 2 starts with 0x80, there is no error.

{{Stub}}

Talk:Proof of Stake

2012-05-25T04:42:54Z

Ids: /* Proof of stake - done right - is maybe, just maybe, the way to eliminate 51% (even 90%!) attack worries altogether! */ further wording clarity improvements

== Malicious forking ==

Surely proof-of-stake is vulnerable to malicious forking of the blockchain, whether motivated by double spending or just sowing destructive confusion of multiple versions?

Each version of the blockchain is a full, self-contained "version of reality". If you (the malicious party engineering a fork) burn through your "stake" - whether bitcoins owned, bitcoin days destroyed, or anything similar - on one version of the blockchain, that still doesn't stop you creating another version, starting from the same block-before-yours as you started from for your first effort, where your same "stake" still exists and hasn't been burned through. (And then another, and another... All forking from the blockchain-as-was (just before you started your malicious antics), which records your untouched stake.) So with trivial computational effort, you can create huge multiple forks; and there's no easy way for the network to pick a winner.

Proof-of-work doesn't suffer from this problem. A malicious party trying the above trick would have to perform fresh work for each fork, since the work done in finding a difficulty-satisfying hash on one fork has no transferable value to the task of finding one on the other fork(s).

Am I missing something? [[User:Ids|Iain Stewart]] 23:24, 24 March 2012 (GMT)

This is a good point, but perhaps what you are missing is the mixed proof-of-stake/proof-of-work concept. Your argument applies to pure proof-of-stake, but I don't believe that it applies to a mixed proof-of-stake/proof-of-wrok system, even one where work is a very small component. Please let me know if you think otherwise. Here are some thoughts:

1) The creation of multiple forks is only a problem if there is doubt about which chain is the correct one. This happens when multiple chains have equal cumulative difficulty (measured as the sum of all difficulties in the chain). In the case of a tie in cumulative difficulty, other miners can pick a chain to extend at random. One well-intentioned miner will get lucky and find the first block after the attacker. He will pick one of the attacker's chains, extend it, and broadcast this to the network. Even though they may have been working on other chains before, other miners will also extend this chain because it is now longer and thus more likely to survive. As usual, users awaiting txn confirmation just wait for a chain to become sufficiently long that there is no significant probaility that it will get overtaken. Once this happens, txns become extremely costly to reverse.

2) Perhaps you are worried that all other miners will extend every single competing chain. If so, all chains will grow at the same rate and it won't work to pick the winner at random. This is a problem in pure proof-of-stake. As you point out, in pure proof-of-stake extending multiple chains simultaneously has no resource cost. However, under a mixed-system, there is a non-trivial work component to any chain extension. Miners would not find it worthwhile to extend chains that have a low probability of becoming the dominant chain. I think even a pretty small computational cost would be sufficient to discourage this. [[User:Cunicula|Cunicula]] 27 March 2012

Thanks for your reply Cunicula, and apologies for taking so long to even acknowledge it. (I log in rather intermittently, although hopefully I'll be logging in more often now that I'm working on my [[Adaptive_difficulty|adaptive difficulty]] proposal. ''[and (edit 2012-05-21) a stake-based proposal which '''seems''' to achieve the impossible and stand up to a >>50% attack! see teaser section at end of [[Adaptive_difficulty|adaptive difficulty]] page for now...]'') I'll not try to form a proper opinion of the mixed work/stake case until I've cleared my mind of some, ah, heavy-going skeptical Bayesian analysis of my own proposal (which for now is entirely within the proof-of-work universe, by the way, so not directly relevant here); but yes, thank you for making the general point that the mixed case is likely to be more robust than the pure stake case. [[User:Ids|Iain Stewart]] 22:23, 6 May 2012 (GMT)

== Proof of stake - done right - is maybe, just maybe, the way to eliminate 51% (even 90%!) attack worries altogether! ==

The vigorous debate about which of various systems, on a spectrum from pure proof of work to pure proof of stake via hybrids in between, is very enjoyable and thought-provoking. But when all is said and done, the evaluation process always boils down to "which system is least likely to allow the horror of a 51% attacker getting total control?". It's just assumed, by everybody as far as I can tell reading through the forums etc, that a 51% attack ''is'' a sure-fire route to total control, and that there's nothing anyone can ever do about ''that''.

(And make no mistake, total control will not stay benevolent, even if it starts off that way. The temptation of the total controller to start acting exactly like the banking system as we know it today - inventing ever more elaborate rules for what sort of transactions it will deign to process, how much it feels like "knowing" about its "customers", and so on - and, beyond that, the temptation of the political system to put unstoppable pressure on the controlling entity to do all these things and more - will be huge, permanent and irresistible. "Decentralisation" will become worthy only of a hollow laugh.)

But, I would like to ask: are we thinking imaginatively enough about this? What about seeking a protocol where '''even a much more than 50% attack still fails'''? (Where the "%" figure refers to whatever the scarce resource is - work, stake, an optimum Cobb-Douglas mix of the two in a hybrid system... whatever.)

It's been taken as "obvious" that a 51% attack will succeed. One unit of the scarce resource is the same as another, and 51% beats 49%, and that's all there is to it! But proof of stake means the scarce resource is '''not''' the fungible "stuff" we're used to from proof of work. Stakeholders (unlike proof-of-work miners) are '''pseudonymously trackable'''. (They sign with a pseudonymous identity when they supply bitcoin days destroyed into a coinbase transaction, or whatever similar thing they have to do to establish they're a stakeholder.) And they can't cheaply change their pseudonymous identity (sloshing bitcoins around ''before'' landing them on a coinbase throws away all those lovely bitcoin days that could have been destroyed into the coinbase).

This opens up wonderful new possibilities. We no longer have to compute the "height" of a candidate blockchain as just the sum of atomistic contributions from each block (like the sum of their difficulties, in the case of the current Bitcoin). '''We can reward preferred structures and patterns''' in the way the pseudonymously-trackable stakeholders are interleaved in the chain.

In particular: we can reward "closeness", in some mathematical sense yet to be pinned down, to a sort of proportionality or "fair sharing" pattern. So, for example, a miner or set of miners with 10% of the deployable stake, who so far has ''less'' than 10% occupation fraction of the blockchain (maybe they've barely started mining at all), can have each block they mine (and help bring their share closer to the "ideal" 10%) be deemed to contribute '''more''' incremental height to the chain than an atomistic sum formula would have given. And conversely, if they overshoot and already have 15%, a structure-aware chain height formula can allocate '''less''' incremental chain height for the overshooting fraction than an atomistic formula would have given.

I believe that if we choose such a formula cleverly, we may well be able to protect against attacks that have been considered an obvious lost cause - 51%, 80%, 90%. For note that the attacker(s), say with 90% of the stake resource, and the honest miners, with the remaining 10%, have '''asymmetrically different goals'''.

The attacker, or attacker cartel, wants (in the scenario we're traditionally most worried about) to either bring down Bitcoin, or keep it going but with control over what transactions are "acceptable" - e.g. to act like a know-your-customer bank, or to harass targeted persons or economic sectors by rejecting their transactions. To achieve this, the attacker has to keep '''all''' blocks generated by the honest 10% out of the winning blockchain. (If even an occasional one got through, in a way the attacker couldn't reverse, it would of course include all the accumulated pool of "ordinary, reasonable" transactions the attacker is trying to reject - the 10% just want to earn an honest profit by collecting all those fees.)

By contrast, the honest 10% do '''not''' have to aim for the symmetrically opposite goal (of excluding the malicious 90%). They merely have to aim for achieving a ''reasonable interleaving'' of their honest blocks into the winning blockchain. Then ordinary users will get their transactions handled (albeit more slowly than they might have got used to); and the honest miners will collect their fees.

The challenge, then, is to design the structure-aware chain height formula so that the attacker's would-be chain ''loses'' (even though, of course, a mere ''sum'' of stake-achievements block by block would allow a 90% attacker to effortlessly ''win''). The idea is that, if closeness to fair share interleaving is being especially highly rewarded, then the attacker's chain gets penalized for being far away from fairness: the 90% have 100% occupancy, and the 10% have 0%. The competing chain with some honest blocks here and there gets strongly rewarded by comparison (say for example the 90% have 93% and the 10% have 7% - that's closer to fair shares than the attacker-only chain). '''It wins!'''

The exasperated attacker fumes, "Why the hell can't I reverse these pesky honest blocks? I'm deploying 90% of the network's entire power! My chain without them should be the winner!" Ah, but structure-awareness is rewarding their presence and penalizing their absence. And with a strong enough such effect, who knows, perhaps ''any'' percentage level of such a style of attack can be thwarted!

I've created a draft page, [[Proof_of_blockchain_fair_sharing]], for ideas fitting into this general milieu. At the moment it just has a teaser description of the general idea (pretty much similar to what you've just finished reading here). I had hoped to spring a polished structure-aware height formula on the world; sadly, my first effort I believe has subtle economies and diseconomies of scale (giving stakeholders perverse incentives to either club together, cartel-like, or disaggregate, taking on multiple pseudonymous identities each). That's not the end of the world perhaps - especially since the whole point of this revolutionary new approach is that a cartel (even going above 50%) is no longer something to be terrified of - but I'd prefer long-run scale-neutrality if possible. More importantly, I now ''also'' believe my first effort doesn't achieve a strong enough bias in favour of fair-shares chains to make much difference (it maybe means a 67% attack is needed to gain total power, rather than 51%... mildly helpful I suppose, but I still aspire to the dream case where no finite attack succeeds in the long run).

Naturally, I'm hoping to invent a formula that achieves the miracle of letting any honest minority, no matter how small, achieve a non-zero occupation fraction of the winning chain. (Their achieved occupation fraction might not be exactly the "fair" one; but ''any'' non-zero fraction would let Bitcoin continue, albeit slowly and creakily, and with luck the attacker eventually concedes defeat.) To speed up progress, I thought it only fair to throw open this challenge to all mathematically-minded Bitcoin folk - after all, there are doubtless others far more talented than me! [[User:Ids|Iain Stewart]] 16:41, 21 May 2012 (GMT)

Current Network Status

2012-05-23T23:16:24Z

Ids: /* Block Chain Availability */ spelling

Bitcoins day to day functionality depends on the peer to peer network. This is just a collection of bitcoin clients running on various machines across the internet. The health of that network is critical to the functioning of the bitcoin currency.

===Total Number of Bitcoin Clients===
There are currently as of September 2011 approximately 60,000<ref name="bitcoinstatus">[http://bitcoinstatus.rowit.co.uk Sourced from BitcoinStatus], web site displaying numerous stats on the bitcoin network.</ref> active clients. We know this because as part of the protocol every client broadcasts their address across the network every 24 hours. By listening for these broadcasts and counting the number of unique addresses we can count the number of clients.

[[File:HostsWeek.png|400x200px]]

===Number of Listening Bitcoin Clients===
One of the issues that the peer to peer network faces is the fact that most users of the internet use machines that are behind a Firewall/NAT gateway. This means that they are only able to make outgoing connections to hosts on the internet and not receive incoming connections (unless they manually or automatically - using PnP - configure their firewall). There are over 12,000<ref name="bitcoinstatus" /> bitcoin clients that can be connected to. This figure is be an underestimate of the actual number of hosts that are not behind a firewall as each host is configured to only accept 125 connections, and so if they are full we would not know if the host was behind a firewall or just ignoring out connection request due to too many connections.

===Ratio of Listening to Total Number of Hosts===
All hosts are configured to make 8 outgoing connections. With this and the fact that there is a limit of 125 total connection it can be concluded that once the ratio of total hosts to listening hosts approaches 15 there will be issues with hosts being unable to connect to the network. As of September 2011 this ratio is between 4 and 5<ref name="bitcoinstatus" /> so is not an issue.

[[File:HostServerRatio.png|400x200px]]

===Block Chain Availability===
In order for the network to be stable the current blockchain must be downloadable from the majority of clients on the network. As part of the handshake when a client connects to another client it informs them of the length of blockchain that it has. Currently (September 2011) the network has over 10,000<ref name="bitcoinstatus" /> clients that are listening and have an upto date version of the blockchain. Should this number drop significantly (e.g. due to a network partition or DDOS attack) there would be issues in ensuring that all clients agreed on the current best chain.

[[File:BlockChainStatus.png|400x200px]]

<references />

[[Category:Technical]]

Talk:Proof of Stake

2012-05-23T21:18:44Z

Ids: /* Proof of stake - done right - is maybe, just maybe, the way to eliminate 51% (even 90%!) attack worries altogether! */ more technically precise wording

== Malicious forking ==

Surely proof-of-stake is vulnerable to malicious forking of the blockchain, whether motivated by double spending or just sowing destructive confusion of multiple versions?

Each version of the blockchain is a full, self-contained "version of reality". If you (the malicious party engineering a fork) burn through your "stake" - whether bitcoins owned, bitcoin days destroyed, or anything similar - on one version of the blockchain, that still doesn't stop you creating another version, starting from the same block-before-yours as you started from for your first effort, where your same "stake" still exists and hasn't been burned through. (And then another, and another... All forking from the blockchain-as-was (just before you started your malicious antics), which records your untouched stake.) So with trivial computational effort, you can create huge multiple forks; and there's no easy way for the network to pick a winner.

Proof-of-work doesn't suffer from this problem. A malicious party trying the above trick would have to perform fresh work for each fork, since the work done in finding a difficulty-satisfying hash on one fork has no transferable value to the task of finding one on the other fork(s).

Am I missing something? [[User:Ids|Iain Stewart]] 23:24, 24 March 2012 (GMT)

This is a good point, but perhaps what you are missing is the mixed proof-of-stake/proof-of-work concept. Your argument applies to pure proof-of-stake, but I don't believe that it applies to a mixed proof-of-stake/proof-of-wrok system, even one where work is a very small component. Please let me know if you think otherwise. Here are some thoughts:

1) The creation of multiple forks is only a problem if there is doubt about which chain is the correct one. This happens when multiple chains have equal cumulative difficulty (measured as the sum of all difficulties in the chain). In the case of a tie in cumulative difficulty, other miners can pick a chain to extend at random. One well-intentioned miner will get lucky and find the first block after the attacker. He will pick one of the attacker's chains, extend it, and broadcast this to the network. Even though they may have been working on other chains before, other miners will also extend this chain because it is now longer and thus more likely to survive. As usual, users awaiting txn confirmation just wait for a chain to become sufficiently long that there is no significant probaility that it will get overtaken. Once this happens, txns become extremely costly to reverse.

2) Perhaps you are worried that all other miners will extend every single competing chain. If so, all chains will grow at the same rate and it won't work to pick the winner at random. This is a problem in pure proof-of-stake. As you point out, in pure proof-of-stake extending multiple chains simultaneously has no resource cost. However, under a mixed-system, there is a non-trivial work component to any chain extension. Miners would not find it worthwhile to extend chains that have a low probability of becoming the dominant chain. I think even a pretty small computational cost would be sufficient to discourage this. [[User:Cunicula|Cunicula]] 27 March 2012

Thanks for your reply Cunicula, and apologies for taking so long to even acknowledge it. (I log in rather intermittently, although hopefully I'll be logging in more often now that I'm working on my [[Adaptive_difficulty|adaptive difficulty]] proposal. ''[and (edit 2012-05-21) a stake-based proposal which '''seems''' to achieve the impossible and stand up to a >>50% attack! see teaser section at end of [[Adaptive_difficulty|adaptive difficulty]] page for now...]'') I'll not try to form a proper opinion of the mixed work/stake case until I've cleared my mind of some, ah, heavy-going skeptical Bayesian analysis of my own proposal (which for now is entirely within the proof-of-work universe, by the way, so not directly relevant here); but yes, thank you for making the general point that the mixed case is likely to be more robust than the pure stake case. [[User:Ids|Iain Stewart]] 22:23, 6 May 2012 (GMT)

== Proof of stake - done right - is maybe, just maybe, the way to eliminate 51% (even 90%!) attack worries altogether! ==

The vigorous debate about which of various systems, on a spectrum from pure proof of work to pure proof of stake via hybrids in between, is very enjoyable and thought-provoking. But when all is said and done, the evaluation process always boils down to "which system is least likely to allow the horror of a 51% attacker getting total control?". It's just assumed, by everybody as far as I can tell reading through the forums etc, that a 51% attack ''is'' a sure-fire route to total control, and that there's nothing anyone can ever do about ''that''.

(And make no mistake, total control will not stay benevolent, even if it starts off that way. The temptation of the total controller to start acting exactly like the banking system as we know it today - inventing ever more elaborate rules for what sort of transactions it will deign to process, how much it feels like "knowing" about its "customers", and so on - and, beyond that, the temptation of the political system to put unstoppable pressure on the controlling entity to do all these things and more - will be huge, permanent and irresistible. "Decentralisation" will become worthy only of a hollow laugh.)

But, I would like to ask: are we thinking imaginatively enough about this? What about seeking a protocol where '''even a much more than 50% attack still fails'''? (Where the "%" figure refers to whatever the scarce resource is - work, stake, an optimum Cobb-Douglas mix of the two in a hybrid system... whatever.)

It's been taken as "obvious" that a 51% attack will succeed. One unit of the scarce resource is the same as another, and 51% beats 49%, and that's all there is to it! But proof of stake means the scarce resource is '''not''' the fungible "stuff" we're used to from proof of work. Stakeholders (unlike proof-of-work miners) are '''pseudonymously trackable'''. (They sign with a pseudonymous identity when they supply bitcoin days destroyed into a coinbase transaction, or whatever similar thing they have to do to establish they're a stakeholder.) And they can't cheaply change their pseudonymous identity (sloshing bitcoins around ''before'' landing them on a coinbase throws away all those lovely bitcoin days that could have been destroyed into the coinbase).

This opens up wonderful new possibilities. We no longer have to compute the "height" of a candidate blockchain as just the sum of atomistic contributions from each block (like the sum of their difficulties, in the case of the current Bitcoin). '''We can reward preferred structures and patterns''' in the way the pseudonymously-trackable stakeholders are interleaved in the chain.

In particular: we can reward "closeness", in some mathematical sense yet to be pinned down, to a sort of proportionality or "fair sharing" pattern - so that, for example, a 10% stakeholder who hasn't ''yet'' come near 10% occupation fraction of any recent candidate blockchain (maybe they haven't started mining at all) is deemed to contribute '''more''' incremental chain height, for each block they ''do'' now put in and help bring their share closer to the "ideal" 10%, than an atomistic sum formula would have given. And conversely, if they overshoot and already have 15%, a structure-aware chain height formula can allocate '''less''' incremental chain height for the overshooting fraction than an atomistic formula would have given.

I believe that if we choose such a formula cleverly, we may well be able to protect against attacks that have been considered an obvious lost cause - 51%, 80%, 90%. For note that the attacker(s), say with 90% of the stake resource, and the honest miners, with the remaining 10%, have '''asymmetrically different goals'''.

The attacker, or attacker cartel, wants (in the scenario we're traditionally most worried about) to either bring down Bitcoin, or keep it going but with control over what transactions are "acceptable" - e.g. to act like a know-your-customer bank, or to harass targeted persons or economic sectors by rejecting their transactions. To achieve this, the attacker has to keep '''all''' blocks generated by the honest 10% out of the winning blockchain. (If even an occasional one got through, in a way the attacker couldn't reverse, it would of course include all the accumulated pool of "ordinary, reasonable" transactions the attacker is trying to reject - the 10% just want to earn an honest profit by collecting all those fees.)

By contrast, the honest 10% do '''not''' have to aim for the symmetrically opposite goal (of excluding the malicious 90%). They merely have to aim for achieving a ''reasonable interleaving'' of their honest blocks into the winning blockchain. Then ordinary users will get their transactions handled (albeit more slowly than they might have got used to); and the honest miners will collect their fees.

The challenge, then, is to design the structure-aware chain height formula so that the attacker's would-be chain ''loses'' (even though, of course, a mere ''sum'' of stake-achievements block by block would allow a 90% attacker to effortlessly ''win''). The idea is that, if closeness to fair share interleaving is being especially highly rewarded, then the attacker's chain gets penalized for being far away from fairness: the 90% have 100% occupancy, and the 10% have 0%. The competing chain with some honest blocks here and there gets strongly rewarded by comparison (say for example the 90% have 93% and the 10% have 7% - that's closer to fair shares than the attacker-only chain). '''It wins!'''

The exasperated attacker fumes, "Why the hell can't I reverse these pesky honest blocks? I'm deploying 90% of the network's entire power! My chain without them should be the winner!" Ah, but structure-awareness is rewarding their presence and penalizing their absence. And with a strong enough such effect, who knows, perhaps ''any'' percentage level of such a style of attack can be thwarted!

I've created a draft page, [[Proof_of_blockchain_fair_sharing]], for ideas fitting into this general milieu. At the moment it just has a teaser description of the general idea (pretty much similar to what you've just finished reading here). I had hoped to spring a polished structure-aware height formula on the world; sadly, my first effort I believe has subtle economies and diseconomies of scale (giving stakeholders perverse incentives to either club together, cartel-like, or disaggregate, taking on multiple pseudonymous identities each). That's not the end of the world perhaps - especially since the whole point of this revolutionary new approach is that a cartel (even going above 50%) is no longer something to be terrified of - but I'd prefer long-run scale-neutrality if possible. More importantly, I now ''also'' believe my first effort doesn't achieve a strong enough bias in favour of fair-shares chains to make much difference (it maybe means a 67% attack is needed to gain total power, rather than 51%... mildly helpful I suppose, but I still aspire to the dream case where no finite attack succeeds in the long run).

Naturally, I'm hoping to invent a formula that achieves the miracle of letting any honest minority, no matter how small, achieve a non-zero occupation fraction of the winning chain. (Their achieved occupation fraction might not be exactly the "fair" one; but ''any'' non-zero fraction would let Bitcoin continue, albeit slowly and creakily, and with luck the attacker eventually concedes defeat.) But I thought it only fair to throw open this challenge to all mathematically-minded Bitcoin folk - after all, there are doubtless others far more talented than me! [[User:Ids|Iain Stewart]] 16:41, 21 May 2012 (GMT)

Talk:Proof of Stake

2012-05-21T17:42:03Z

Ids: /* Proof of stake - done right - is maybe, just maybe, the way to eliminate 51% (even 90%!) attack worries altogether! */ spelling

== Malicious forking ==

Surely proof-of-stake is vulnerable to malicious forking of the blockchain, whether motivated by double spending or just sowing destructive confusion of multiple versions?

Each version of the blockchain is a full, self-contained "version of reality". If you (the malicious party engineering a fork) burn through your "stake" - whether bitcoins owned, bitcoin days destroyed, or anything similar - on one version of the blockchain, that still doesn't stop you creating another version, starting from the same block-before-yours as you started from for your first effort, where your same "stake" still exists and hasn't been burned through. (And then another, and another... All forking from the blockchain-as-was (just before you started your malicious antics), which records your untouched stake.) So with trivial computational effort, you can create huge multiple forks; and there's no easy way for the network to pick a winner.

Proof-of-work doesn't suffer from this problem. A malicious party trying the above trick would have to perform fresh work for each fork, since the work done in finding a difficulty-satisfying hash on one fork has no transferable value to the task of finding one on the other fork(s).

Am I missing something? [[User:Ids|Iain Stewart]] 23:24, 24 March 2012 (GMT)

This is a good point, but perhaps what you are missing is the mixed proof-of-stake/proof-of-work concept. Your argument applies to pure proof-of-stake, but I don't believe that it applies to a mixed proof-of-stake/proof-of-wrok system, even one where work is a very small component. Please let me know if you think otherwise. Here are some thoughts:

1) The creation of multiple forks is only a problem if there is doubt about which chain is the correct one. This happens when multiple chains have equal cumulative difficulty (measured as the sum of all difficulties in the chain). In the case of a tie in cumulative difficulty, other miners can pick a chain to extend at random. One well-intentioned miner will get lucky and find the first block after the attacker. He will pick one of the attacker's chains, extend it, and broadcast this to the network. Even though they may have been working on other chains before, other miners will also extend this chain because it is now longer and thus more likely to survive. As usual, users awaiting txn confirmation just wait for a chain to become sufficiently long that there is no significant probaility that it will get overtaken. Once this happens, txns become extremely costly to reverse.

2) Perhaps you are worried that all other miners will extend every single competing chain. If so, all chains will grow at the same rate and it won't work to pick the winner at random. This is a problem in pure proof-of-stake. As you point out, in pure proof-of-stake extending multiple chains simultaneously has no resource cost. However, under a mixed-system, there is a non-trivial work component to any chain extension. Miners would not find it worthwhile to extend chains that have a low probability of becoming the dominant chain. I think even a pretty small computational cost would be sufficient to discourage this. [[User:Cunicula|Cunicula]] 27 March 2012

Thanks for your reply Cunicula, and apologies for taking so long to even acknowledge it. (I log in rather intermittently, although hopefully I'll be logging in more often now that I'm working on my [[Adaptive_difficulty|adaptive difficulty]] proposal. ''[and (edit 2012-05-21) a stake-based proposal which '''seems''' to achieve the impossible and stand up to a >>50% attack! see teaser section at end of [[Adaptive_difficulty|adaptive difficulty]] page for now...]'') I'll not try to form a proper opinion of the mixed work/stake case until I've cleared my mind of some, ah, heavy-going skeptical Bayesian analysis of my own proposal (which for now is entirely within the proof-of-work universe, by the way, so not directly relevant here); but yes, thank you for making the general point that the mixed case is likely to be more robust than the pure stake case. [[User:Ids|Iain Stewart]] 22:23, 6 May 2012 (GMT)

== Proof of stake - done right - is maybe, just maybe, the way to eliminate 51% (even 90%!) attack worries altogether! ==

The vigorous debate about which of various systems, on a spectrum from pure proof of work to pure proof of stake via hybrids in between, is very enjoyable and thought-provoking. But when all is said and done, the evaluation process always boils down to "which system is least likely to allow the horror of a 51% attacker getting total control?". It's just assumed, by everybody as far as I can tell reading through the forums etc, that a 51% attack ''is'' a sure-fire route to total control, and that there's nothing anyone can ever do about ''that''.

(And make no mistake, total control will not stay benevolent, even if it starts off that way. The temptation of the total controller to start acting exactly like the banking system as we know it today - inventing ever more elaborate rules for what sort of transactions it will deign to process, how much it feels like "knowing" about its "customers", and so on - and, beyond that, the temptation of the political system to put unstoppable pressure on the controlling entity to do all these things and more - will be huge, permanent and irresistible. "Decentralisation" will become worthy only of a hollow laugh.)

But, I would like to ask: are we thinking imaginatively enough about this? What about seeking a protocol where '''even a much more than 50% attack still fails'''? (Where the "%" figure refers to whatever the scarce resource is - work, stake, an optimum Cobb-Douglas mix of the two in a hybrid system... whatever.)

It's been taken as "obvious" that a 51% attack will succeed. One unit of the scarce resource is the same as another, and 51% beats 49%, and that's all there is to it! But proof of stake means the scarce resource is '''not''' the fungible "stuff" we're used to from proof of work. Stakeholders (unlike proof-of-work miners) are '''pseudonymously trackable'''. (They sign with a pseudonymous identity when they supply bitcoin days destroyed into a coinbase transaction, or whatever similar thing they have to do to establish they're a stakeholder.) And they can't cheaply change their pseudonymous identity (sloshing bitcoins around ''before'' landing them on a coinbase throws away all those lovely bitcoin days that could have been destroyed into the coinbase).

This opens up wonderful new possibilities. We no longer have to compute the "height" of a candidate blockchain as just the sum of atomistic contributions from each block (like the sum of their difficulties, in the case of the current Bitcoin). '''We can reward preferred structures and patterns''' in the way the pseudonymously-trackable stakeholders are interleaved in the chain.

In particular: we can reward "closeness", in some mathematical sense yet to be pinned down, to a sort of proportionality or "fair sharing" pattern - so that, for example, a 10% stakeholder who hasn't ''yet'' come near 10% occupation fraction of any recent candidate blockchain (maybe they haven't started mining at all) is deemed to contribute '''more''' incremental chain height, for each block they ''do'' now put in and help bring their share closer to the "ideal" 10%, than an atomistic sum formula would have given. And conversely, if they overshoot and already have 15%, a structure-aware chain height formula can allocate '''less''' incremental chain height for the overshooting fraction than an atomistic formula would have given.

I believe that if we choose such a formula cleverly, we may well be able to protect against attacks that have been considered an obvious lost cause - 51%, 80%, 90%. For note that the attacker(s), say with 90% of the stake resource, and the honest miners, with the remaining 10%, have '''asymmetrically different goals'''.

The attacker, or attacker cartel, wants the frisson of sheer, unadulterated power. Power to starve rivals and enemies by mysteriously never quite accepting their bitcoin transactions; power to accept and reject transactions on whim; power to bring down Bitcoin altogether by just not accepting ''any'' transactions (or accepting/rejecting so whimsically and arbitrarily that the system becomes unusable). To achieve this power, the attacker has to keep '''all''' blocks generated by the honest 10% out of the winning blockchain. (If even an occasional one got through, in a way the attacker couldn't reverse, it would of course include all the accumulated pool of "ordinary, reasonable" transactions the attacker is trying to reject - the 10% just want to earn an honest profit by collecting all those fees.)

By contrast, the honest 10% do '''not''' have to aim for the symmetrically opposite goal (of excluding the malicious 90%). They merely have to aim for achieving a ''reasonable interleaving'' of their honest blocks into the winning blockchain. Then ordinary users will get their transactions handled (albeit more slowly than they might have got used to); and the honest miners will collect their fees.

The challenge, then, is to design the structure-aware chain height formula so that the attacker's would-be chain ''loses'' (even though, of course, a mere ''sum'' of stake-achievements block by block would allow a 90% attacker to effortlessly ''win''). The idea is that, if closeness to fair share interleaving is being especially highly rewarded, then the attacker's chain gets penalized for being far away from fairness: the 90% have 100% occupancy, and the 10% have 0%. The competing chain with some honest blocks here and there gets strongly rewarded (say for example the 90% have 93% and the 10% have 7% - that's closer to fair shares than the attacker-only chain). '''It wins!'''

The exasperated attacker fumes, "Why the hell can't I reverse these pesky honest blocks? I'm deploying 90% of the network's entire power! My chain without them should be the winner!" Ah, but structure-awareness is rewarding their presence and penalizing their absence. And with a strong enough such effect, who knows, perhaps ''any'' percentage level of such a style of attack can be thwarted!

I've created a draft page, [[Proof_of_blockchain_fair_sharing]], for ideas fitting into this general milieu. At the moment it just has a teaser description of the general idea (pretty much similar to what you've just finished reading here). I had hoped to spring a polished structure-aware height formula on the world; sadly, my first effort I believe has subtle economies and diseconomies of scale (giving stakeholders perverse incentives to either club together, cartel-like, or disaggregate, taking on multiple pseudonymous identities each). That's not the end of the world perhaps - especially since the whole point of this revolutionary new approach is that a cartel (even going above 50%) is no longer something to be terrified of - but I'd prefer long-run linearity [scale-neutrality] if possible. More importantly, I now ''also'' believe my first effort doesn't achieve a strong enough bias in favour of fair-shares chains to make much difference (it maybe means a 67% attack is needed to gain total power, rather than 51%... mildly helpful I suppose, but I still aspire to the dream case where no finite attack succeeds in the long run).

Naturally, I'm hoping to invent a formula that achieves the miracle of letting any honest minority, no matter how small, achieve a non-zero occupation fraction of the winning chain. (Their achieved occupation fraction might not be exactly the "fair" one; but ''any'' non-zero fraction would let Bitcoin continue, albeit slowly and creakily, and with luck the attacker eventually concedes defeat.) But I thought it only fair to throw open this challenge to all mathematically-minded Bitcoin folk - after all, others are doubtless far more talented than me! [[User:Ids|Iain Stewart]] 16:41, 21 May 2012 (GMT)