I don't plan to read the code, and I should not have to. The payment system of the world cannot be defined by a (messy) program.   Bitcoin should be an implementation-independent protocol, like SMTP and HTML. Anyone with sufficient knowledge of algorithms and networking should be able to understand how it works without reading the code.

And there should not be "the" code, since the maintainers of that code would be a central authority.

Whatever "standard" means, you cannot assume that miners will not create non-standard blocks that are accepted as valid by other miners and clients.  You cannot assume that every miner will run unmodified Core software; and you cannot assume that non-mining relay nodes will do anything specific.

Indeed I have little love for the current Core devs, for a dozen separate reasons.  To stay on the technical ones, they include (1) claim that soft forks are safer than hard forks, (2) the "fee market" and its paraphernalia, (3) SegWit, (4) reliance and encouragement of non-mining relays, (5) modifying bitcoin as if the Lightning Network is a certain thing.  Not me, but some very competent people (who also have read the code) have objectively pointed out the faults in those items; but their criticisms have never been answered.

Thanks for the reply.  You write:


The word "standardness" implies that someone is setting a standard that should be followed by all nodes; but it is known that different relay nodes are using different arbitrary criteria to censor transactions and blocks.


Fixed that for you.  They should validate the blocks that they receive, but (unlike the miners) they have no motivation to do so, and there is no way for a client to check that they are.

The miners have a strong incentive to use only valid blocks as parents; when they gamble, as in the (badly named) "SPV mining" of empty blocks, it is because they have high confidence that the parent block is valid.  In the case of classic "SPV mining", they steal the hash of the parent block from another pool via Stratum.  Therefore, if that block was invalid, that other pool would be screwing all its members and itself.  In other words, when miners do "SPV mining" they gamble that the same incentives that spur them to validate their non-mepty blocks will spur the miner who assembled the previous non-empty block to validate it too.

Non-mining relay nodes have no incentives to validate the blocks that they relay.  On the contrary, they have a significant incentive to skip validation altogether. 


How exactly are they going to do that?  A relay node can only withhold a mined block that it considers invalid.  But if the malicious miners have a minority of the hashpower, that block will not get many confirmation, and soon be orphaned and rejected even by SPV clients.  On the other hand, if it comes form a majority branch, then sooner or later the SPV clients will receive it and accept it as valid, rejecting the "good" minority block that some relays offered instead.  And, in that case, bitcoin is done for anyway: nothing will save it if malicious miners have a majority of the hashpower.

On the other hand, a relay can withhold blocks from the majority branch and serve instead blocks from a minority branch, created by old, buggy, or malicious miners.  If all the relay nodes that are contacted by an SPV client do that, the SPV client will be screwed.  Given the way that clients get the addresses of relay nodes, and that such malicious relays are very easy to set up (much easier than setting up an effective malicious miner), this risk is far form negligible.

Perhaps the faith that some people have on relay nodes comes from experience with SMTP, NNTP, bitTorrent and other decentralized p2p networks, where nodes can (must) be assumed to be well-intentioned by default? Bitcoin is quite unlike those networks...


The blame for that incident should go to the Core devs, who choose to deploy BIP66 when 5% of the miners were still not ready, without a grace period and without alerts.  The miners should be blamed only for trusting that the devs knew what they were doing.

It seems that the miners did learn their lesson, because at the next soft fork (BIP65, IIRC) AntPool held back its vote until most of the tiny miners had upgraded, and prodded them to do so.  I wonder if the Core devs have learned theirs?

Based on historical prices, I would guess that the floor price of gold (due to demand for jewelry, decoration, and industrial uses) is less than 400 USD/oz.  If that is correct, gold's current market price of ~1200 USD/oz is at least 3-4 times its floor price, due to demand for speculative trading (people buying it expecting to make money when its price rises) and for hedging or value storage (people buying it because they think that other investment options are more likely to lose their value).    

Demand for speculative trading and hedging is dependent on people's feelings and beliefs about the future of the economy, and therefore very fragile -- as shown by the crash of the gold price from the peak of ~1800 to ~1000 USD/oz in 2013--2015.  The overpricing is sustained by intensive marketing by the likes of Max Kaiser, Peter Schiff, ZeroHedge, etc.

Bitcoin's floor price would be due to demand for use as a currency.  The number unknown, but very low; most estimates put it below 10 USD/BTC, and there is no reason to expect it to grow very quickly. (Indeed, if the network's capacity is not lifted, it is unlikely to rise at all.)  So bitcoin is far more overpriced than gold.  As in the case of gold, the overpricing is due to demand for speculative trading and (to a much lesser extent) hedging and value storage; and is sustained by marketing by Antonopoulos, Ver, Andreessen, Silbert, etc..


Scarcity by itself does not make an item valuable; for this one also needs demand that is large compared to the supply.  Tickets for last year's lottery, Soviet Trabant cars, and the hairs on my head are all very scarce, and have a hard cap on future supply; yet are not very valuable.

Moreover, an item is not effectively "scarce" if there is an abundance of adequate substitutes.  Gold has no adequate substitutes for jewelry, and its possible substitutes for certain industrial applications are even more scarce.  In contrast, one can create an infinite number of cryptocurrencies that are equivalent to bitcoin, or even better than it.  

The only advantage of bitcoin over litecoin and other altcoins is its popularity, its "brand recognition".  (It has more hashpower than the altcoins, but that is because it is more profitable to mine, which is because its coins sell for a higher price; which is again because of its popularity.)  Popularity that is not rooted in an fudamental quality is very fragile; it  could be quickly destroyed by bad news, bad management, or by good marketing of the alternatives.


Only fools and criminals will "invest" by hoarding a currency, whether it is dollars or bitcoins.  Thus, comparing gold to dollars as store of value is a red herring -- a misleading argument that sleazy gold peddlers use all he time.  Good investments are things that will have real value due to expected real demand, not conventional value or value inflated by speculative demand; and, even better, that create real wealth.  Stocks, real estate, tools, shops are examples of such wealth-creating things that are automatically protected against inflation.  In many countries there are also bonds, issued by banks or the government, that pay back a value adjusted for inflation plus a small interest.

The term "inflation" can mean two things.  Popularly, it is any drop in the purchasing value of a currency.  Technically, it is a drop that is caused by an increase in the amount of currency in circulation, following the printing of new cash or the creation of more virtual money through easing of bank credits etc..  Bitcoin has a controlled and ultimately finite amount of the latter, so technically its inflation will decrease and eventually end.  In the popular sense, however, bitcoin's inflation  neither bounded nor temporary. The drop from ~1200 USD/BTC on 2013-11-28 to ~220 in Jan/2015 (a loss of 80% of purchasing power) was not due to the issuance of new coins.

This is not correct, right?  Miners (and relay nodes running new software) will have to include the signatures in the extension part of the block and send the whole block out to other miners (and to relay nodes running new software).  The extension record can be omitted only when a miner or relay node sends a block to a simple client.  Right?


Centralization has happened because of several factors that favor larger miners over smaller ones -- including economies of scale, access to locations with cheaper power and natural cooling, better prices for bulk purchases, in-house hardware and software development, and better support from local governments.  If it is true that larger blocks give an advantage to bigger miners, they could get those same advantages by artificially delaying the transmission of blocks to rivals.

Thanks.  I don't know the script language, but can't you build a script with those opcodes that fails to validate if the opcode is interpreted as a NOP, but succeeds if it is redefined to something else?  I suppose that the only redefinitons that would allow a soft fork are of the kind "if (condition) then FAIL else NOP", correct?


OK, I see what you mean.

Back in 2009 there was only one kind of node, the miner-user-relayer.  Every player could mine; not just in theory, but in practice.  Satoshi apparently assumed that mining would be widespread,even if occasional and anonymous.  And he assumed that players would join primarily for the benefits of being users.

Later a second kind of node (already predicted in the whitepaper) was introduced, the simple client.  Still, the simple client was supposed to use the same rules as the miners, but only check a subset of them.  

Today there is a third kind, the dedicated "full but non-mining" relay, aka "node", which apparently has a very distinct role and is supposed to be an essential defense against misbehaving miners and other menaces.  And, TIL, needs special validity rules.  

The relaying function of miners in the original design was already a bit fuzzy, but since relaying was cheap, and all nodes were supposed to be also users and (potential) miners, they could be assumed to share the mining incentives and have the good intentions.  That does not carry over to the present-day nodes.  We have examples of relay nodes that filter transactions based on arbitrary ideological criteria, nodes that are committed to specific "parties" in the block size war...  Where is the analysis that they are helping rather than harming the security of the network?

PS. For general joy of mankind, I am traveling in a few hours and will be offline for 2 days.

"Sacred Protocol".  Sorry for the typo.


Right when the tone of the responses makes me think that I am getting close to something?  

By the way, you have not told me where I can find a description of the multiple rule sets for different players, nor where in the original design the non-mining relays were described and given their special function.

(Satoshi always used "node" to mean "miner", if that is what you were thinking.)
 

I suppose that you will not tell me where in the original design the non-mining relays were introduced as guardians of the Sared Protocol.

That sounds bizarre if you say it that way: it would mean that a miner *cannot* verify the validity of the parent block, and has to trust the previous miner.

But perhaps what you should have said is: "Yes, it would validate that block fully -- with his (old) validity rules, in which those opcodes are NOPs, hence it would accept the block as valid."  Is that so?  

That is what I have always understood...


This is not wrong, since a miner can exclude any transactions, by any criterion.  However, given that old miners will accept blocks with those opcodes as valid, its seems rather pointless.  There is no way to ensure that all (or any) miners will abide by this rule.  Any miner could create and mine blocks that use those opcodes; and other old miners would accept those blocks;  Correct?

By the way, are those NOPs really NOPs, or do they mean "terminate the verification with success"?  


In the original design, the propagation was supposed to occur among the miners, who have incentives to keep the network running and to keep clients happy.  The original design depended on those incentives to argue that even simple clients would have adequate security.

The non-mining relay nodes were added later, without any justification.  They break that security argument.

A miner may be offering his services for two possible reasons: 1. to get the reward and fees, or 2. some other motive.  Bitcoin is based on the assumption that motive 1 is fairly likely, so if you contact N random miners it is quite likely that you will get at least one such "selfish greeedy" guy.  

A non-mining relay node cannot have motivation 1, so his motivation can be only 2, "some other motive".  What security can you derive from that?


If the party that receives a tx or block checks some rule, then nothing is gained by having the relay to check that rule too.  If the receiver does not check some rule, then he will not notice when the relay sends data that does not satisfy it; and will not ban the relay.

Three days to the resolution of this dramatic competition.  

(Last year's contest was won by @fonzie.)

Thanks. Well, indeed, the fact that the validity rules are different for different players is new for me.  Is it explained in some place that I should have read?  (The descriptions of soft/hard fork that I have read, for example, always say "the rules", "the old rules", "the new rules" -- never "the miner rules" or "the client rules", etc.

So, does the current version of the Core mining software accept transactions with those NOPs, for inclusion into the candidate block? 

Would that software accept as parent a block mined by some other miner that contains them?


No, I did not know that either.  But, again, one cannot assume anything about the behavior of non-mining relay nodes, so it seems pointless to worry about that.

It would have been enough to say "your previous understanding was correct, the current mining software will accept and mine transactions containing those NOPs, and that sentence by Greg meant something else"  or "your previous understanding was wrong, the current mining software will not accept or mine transactions containing those NOPs". 


I have been programming continuously since 1969, and worked for a few years at software research labs in the US...

Sigh.  That is what I always understood.  But then:


What does this mean?  That the current version of the mining software will reject transactions that have those NOPs?


I haven't looked at the code itself, but I do understand a few things about programming.  For example, a few months ago I found a rounding error in the table of block rewards on the bitcoin wiki.  (And integers are math too, you know.)

On the other hand, I wonder if you really understand how the protocol is supposed to work.  Can you see why the original design did not have non-mining relay nodes?

Me too?

I understand that perfectly, thank you.  But, IIUC, Greg just claimed that, in fact, the miners running the current version of the software reject any transactions and blocks with such NOPs.  Whereas the miners running the new version will accept them, if the new semantics given to them is satisfied.

If that is true, then old miners, even if they are a minority, should reject the blocks created by the new miners, as soon as they start including the redefined opcode.  Isn't that correct?


The policies of independent non-mining relay nodes are irrelevant, since they can reject transactions by any criteria they like, and have no incentives to behave in any particular way; and also because clients can (should) always bypass them and talk to miners directly (or to relays run by miners).  The functioning of the network cannot depend on them.

The policies that matter are those of the miners.  It does not make any difference for the network where in the mining software a certain rule is enforced:  if the miners reject transactions that have some property, then that property is effectively part of their validity rules.


Wait, you are telling me that bitcoin is not "guaranteed by math"?  


Edit: created by the miners --> created by the new miners

Why should those non-mining relays (NMRs) be assumed to be "good guys"?

The original bitcoin protocol (without NMRs) provided some guarantee for simple clients, under the hypothesis that there was a majority of selfish greedy miners, and that the miners contacted by a client included at least one selfish greedy one. With NMRs, in order to give the same guarantee one must also assume that there is at least one path of honest NMRs between the client an such miner.  The basic premise of bitcoin is that selfish greed is prevalent, but honesty cannot be assumed.

 

If no miner will mine a transaction that has a NOP code, then the NOP is effectively illegal.  I.e., those lines in the miner's software that say to reject such transactions are effectively part of the validity rules.  

Which means that making those opcodes legal is a relaxation of the existing rules, and therefore not a soft-fork type of change.


Each player can validate as much as he wants, by any rules that he wants.  However, if he wants to use "the" bitcoin that "everybody" uses, he had better use rules that are compatible with them, in the sense that he must trust the same blockchain that they trust.  As long as "everybody" prefers to trust the chain with the 1500 PH/s, "everybody" had better accept as valid whatever chain is created by the miners with the majority of that hashpower.

Likewise, each miner in theory can adopt any validity criteria that he likes.  He can change them at any time, apply them if and when he wants, and build his blocks any way he wants.  But, as long as he wants to earn bitcoins that he can sell, he must make blocks that end up included in some blockchain that enough potential buyers will trust.  There is no algorithm for that: he must watch the "market" and try to guess how the humans will behave.  

My point is that external observers cannot tell which validity rules a miner is using, nor when or whether he applies them.  All they can see are the blocks that he broadcasts.  In particular, there is no way to tell whether a miner is not accepting transactions with NOPs because NOPs are invalid in his version of the validiy rules, or because he is afraid that someone else may consider them invalid, or because he thinks that they bring bad luck.

As for the non-mining relay nodes, they are aberrations that have no place in the protocol and break all its (already weak) security guarantees.   Thhey should not exist, and clients shoud not use them.

If a fork makes a previously illegal opcode legal, how can it be a soft fork?

OK, so now consider the reverse situation: Bob is running a new client, and Alice is running an old one.  If Bob wants Alice to send him coins, what should he tell her: "pay to this address" or "pay to this segwit script", or "pay to either"?

Or: suppose Alice wants to make a payment that can be collected by either Bob or Carol.  Bob is running an old client, and Carol a new one.  Bob tells Alice "pay me to this address",  Carol says "pay me to this segwit script".  What should Alice do?

Suppose Alice is running "new" (SegWit-capable) client software, and sends some bitcoin to Bob, who is running an "old" (SegWit-oblivious) client, with a SegWIt transaction T1.

I understand that Bob would still be able to spend that bitcoin with a non-SegWit transaction T2, by providing the proper signature; is that correct?

But would Bob know what signature he must provide, without Alice telling him?  Or will Bob's client believe that the output of T1 is "anyone can spend", and assume that T2 does not require a signature?

That is mathematically impossible.  A soft fork, by definition, is a change that only makes the rules more restrictive: that is, some transactions that were valid by the old rules are invalid by the new ones, whereas all transactions that are valid by the new rules are also valid by the old ones.  


As I explained already, that is often not an option.  Soft forks are often issued precisely because it is necessary or desirable to outlaw certain types of transactions.  Note that miners cannot distinguish a genuine mothballed transaction from a new transaction that is using the old version number just to frustrate the fork.