Segwit details? N + 2*numtxids + numvins > N, segwit uses more space than 2MB HF

[2112]

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.

Non-mining relay nodes have several useful purposes: probably the most important one is as a first line of defense against denial of service attacks. Especially if such nodes are run in the cloud service provider who charges $0/GB for incoming traffic (like Amazon EC2): it nearly completely defangs the most common DDoS via UDP flood.

I have to observe that for somebody with an actual scientific degree you are making questionable statements too fast and too often.

[CIYAM]

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.

Your logic seems to be completely confused - so let's take a practical example to try and help you to understand (although I get the feeling you're not interested in actually understanding this at all).

Let's look at CLTV and see how that works. The NOP code becomes OP_CHECKLOCKTIMEVERIFY after the number of nodes supporting the soft-fork has got to the correct level (that is determined by the super-majority mining new block versions).

At this point a script that uses this previous NOP code now enforces a rule check to make sure that the nLocktime is greater than or equal to the value on the stack (if not then the result is zero).

This is a restriction not a relaxation (as it can now fail this test) - when any node that hasn't upgraded sees this in a block that has been mined then it will also accept the script as valid even though it didn't do the check and this prevents a fork (as it is indeed being treated as a NOP for such nodes and the value that was pushed onto the stack is the result which is non-zero).

If it was a hard-fork then existing (non-upgraded) nodes would not find blocks that included txs with such scripts to be valid - but as stated *this is not the case* (and again you need to understand the difference between relaying, mining and validating but again I'm sure you'll just refuse to admit that there is any difference and insist that it is all just validation).

If you want to keep on arguing about definitions without actually bothering to understand how the system works then I don't think that anyone here is going to keep on wasting their time trying to explain it to you.

Bitcoin isn't some sort of theoretical model but instead is a practical piece of software (so it doesn't actually care about what you think the behaviour of things should be according to what you think the terms should refer to).

[fbueller]

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.

They actually provide a great deal of value to the network. They keep miners honest by checking blocks for validity, and *not* relaying those which are totally invalid, or make coins up out of the air. If you make a block paying yourself with invalid proof of work, it won't get further than the nodes you announce it to.

Care to explain your position on why they are not to be trusted?

[gmaxwell]

The primary established mechanism for safe softforks is the reserved script NOPs (which will not be relayed or mined by unmodified software today)

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

I would encourage you to read what I actually write. I said nothing of illegal opcodes, and for good reason.

[JorgeStolfi]

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.   They should not exist, and clients shoud not use them.

Non-mining relay nodes have several useful purposes: probably the most important one is as a first line of defense against denial of service attacks. Especially if such nodes are run in the cloud service provider who charges $0/GB for incoming traffic (like Amazon EC2): it nearly completely defangs the most common DDoS via UDP flood.

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.

 

[JorgeStolfi]

At this point a script that uses this previous NOP code now enforces a rule check to make sure that the nLocktime is greater than or equal to the value on the stack (if not then the result is zero).

This is a restriction not a relaxation (as it can now fail this test) - when any node that hasn't upgraded sees this in a block that has been mined then it will also accept the script as valid even though it didn't do the check and this prevents a fork (as it is indeed being treated as a NOP for such nodes and the value that was pushed onto the stack is the result which is non-zero).

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?

and again you need to understand the difference between relaying, mining and validating

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.

If you want to keep on arguing about definitions without actually bothering to understand how the system works then I don't think that anyone here is going to keep on wasting their time trying to explain it to you.

Bitcoin isn't some sort of theoretical model but instead is a practical piece of software (so it doesn't actually care about what you think the behaviour of things should be according to what you think the terms should refer to).

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


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

[amaclin]

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

It is not guaranteed.

[CIYAM]

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?

It was explained to you that the op code is *valid* in the context of validating a block (so of course the block would not be rejected by older software). Why do you think it is called a NOP?

If you still cannot grasp such a very basic concept as how this stuff is working then I suggest you simply stop with your "analysis" of Bitcoin because you will never get it.

(and btw - much of software deals with many practical things such as byte size limits that don't apply to math in general so you're not really making any sense with that statement either - if we were talking about pure maths then the block reward would never end for a start)

[JorgeStolfi]

It was explained to you that the op code is *valid* in the context of validating a block (so of course the block would not be rejected by older software). Why do you think it is called a NOP?

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

The primary established mechanism for safe softforks is the reserved script NOPs (which will not be relayed or mined by unmodified software today)

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

much of software deals with many practical things such as byte size limits that don't apply to math in general so you're not really making any sense with that statement either - if we were talking about pure maths then the block reward would never end for a start

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?

[CIYAM]

It was explained to you that the op code is *valid* in the context of validating a block (so of course the block would not be rejected by older software). Why do you think it is called a NOP?

Sigh.  That is what I always understood.  But what does this mean:

The primary established mechanism for safe softforks is the reserved script NOPs (which will not be relayed or mined by unmodified software today)

We have tried again and again to explain but you simply refuse to even read what we post (and just keep on quoting one or another thing to keep on repeating your non-point) - so I'm done with trying to explain things to you (this is also off-topic anyway).

I would advise that you don't try to make suggestions about how Bitcoin should work when you don't even understand how it currently works (or how it used to work for that matter as relaying has been there since day one).

(I have read the code and have been a software engineer since the 1980's)

[JorgeStolfi]

We have tried again and again to explain but you simply refuse to even read what we post (and just keep on quoting one or another thing to keep on repeating your non-point) - so I'm done with trying to explain things to you (this is also off-topic anyway).

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 read the code and have been a software engineer since the 1980's)

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

[CIYAM]

One last time and then I really do give up.

It is not an "either this or that" and that is where you are just getting it wrong (repeatedly).

As stated (on three separate posts already) validation isn't just a simple and single concept.

There are different validation rules depending upon whether you are mining, relaying or verifying a block (i.e. context).

So the rule about a NOP is not the same rule in all three situations (something that you just don't seem to be able to grok).

(also - I am assuming that you know that both txs and blocks are relayed and that the rules are also dependent upon whether you are relaying a tx or a block)

[2112]

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?

OK, now you've shifted your position to open crackpottery.

The original implementation certainly had non-mining relay nodes. In the original implementation mining (then CPU-only) was explicitly optional. The shift between the original and current is just that nowadays the probability that the randomly connected relay node also does mining is much lower.

[JorgeStolfi]

As stated (on three separate posts already) validation isn't just a simple and single concept.
There are different validation rules depending upon whether you are mining, relaying or verifying a block (i.e. context).
So the rule about a NOP is not the same rule in all three situations (something that you just don't seem to be able to grok).

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?

(also - I am assuming that you know that [ ... ] the rules [ for relay nodes ] are also dependent upon whether you are relaying a tx or a block)

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.

[molecular]

It was explained to you that the op code is *valid* in the context of validating a block (so of course the block would not be rejected by older software). Why do you think it is called a NOP?

It's called a "No OPeration" because it doesn't do anything (except maybe wait a clock cycle or so) in the context of script execution.. So it will not influence the result of the script execution. However there could still be a consensus rule that says: scripts shall not contain NOP instructions.

What exactly is the "context of validating" a block? Validating it for wether it should be included in finding the longest chain? So are you saying a block containing a tx with a NOP will be accepted as part of the longest valid chain by core 0.11, 0.12?

There are different validation rules depending upon whether you are mining, relaying or verifying a block (i.e. context).

So the rule about a NOP is not the same rule in all three situations (something that you just don't seem to be able to grok).

I understand that. For example BitcoinUnlimited will not relay some blocks if they are too big for the values given in configuration, yet it will still accept it as a valid block for mining.

The primary established mechanism for safe softforks is the reserved script NOPs (which will not be relayed or mined by unmodified software today)

so maxwell here seems to be saying that in the context of relaying a tx, relaying a block and mining, a tx containting a NOP (is that any different from "a reserved script NOP", btw?) instruction or a block containing a tx containing a NOP instruction will not be relayed (in case of a block or tx) and will not be considered when finding the 'longest' chain to mine on? That seems hard to believe. So I'm putting a NOP into a script and that means the tx wont be relayed by standard core nodes and it wont be mined by a miner who runs a core node? Is that what he's saying? Is it true?

[CIYAM]

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

No - it would not (as it could not know whether or not they are valid).

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

Yes it would as it assumes that whoever has mined them did know that they were valid.

Are you starting to get it now?
(fingers crossed that the penny has dropped)

Also without relaying you actually wouldn't have a P2P network at all (so it is an essential part of the system not some optional thing) and there are expectations that a node will not relay invalid txs or blocks (and any node that does will be banned by your client).

[molecular]

Are you starting to get it now?
(fingers crossed that the penny has dropped)

I know you're not talking to me, but I think I understand now: the NOP really is something that invalidates a tx in the context of relaying and mining it because the assumption is that this NOP isn't there for fun, but it really is not a NOP for the author of the tx or the miner of it. I just don't know the new meaning of the NOP so I don't touch the tx with a ten foot pole... who knows wether that script returns true or false?

On the other hand a NOP in a tx in a block already mined by someone else is not offensive: the assumption is that it was assigned some meaning I don't yet know about and the block was mined by a miner that *does* know about that new meanig and he has verified the tx' validity.

[CIYAM]

Yes @molecular that is precisely what I've been trying to explain.

In the case of CLTV we can't know whether or not a tx that uses this new (reserved NOP) is valid if we are running older software but once a block appears that has this op-code in it then we just treat it as NOP (assuming that whoever mined it knew that it was valid).

Whether or not we relay such txs isn't actually overly important - the key thing is whether or not such txs are included in a block that you mine.

This allows someone to run the older software without being forced to upgrade (whereas a hard-fork requires you to upgrade).

[molecular]

Yes @molecular that is precisely what I've been trying to explain.

A clear way for me to explain the seeming contradiciton ("NOP is ok" vs. "NOP invalidates tx") is not so much in looking at the procedural context we're in (mining, relaying, validating) but at the source of that tx: if it came from the p2p network, a NOP represents an unknown and we can't trust the tx to be valid, if the source is a block in the chain we trust, we can trust the script with that NOP (by extension).

[achow101]

Some things need to be clarified here.

What a node relays is a transaction that is both valid and standard. There are standardness rules and those are node based, not network wide (well usually they are because they are in the software) and not consensus. Solely local node policy. If a transaction is standard, it is also valid.

A valid transaction is any transaction which, when the scripts are run, returns true and nothing in the stack triggers a failure. A valid transaction does not have to be standard.

AFAIK a transaction with a NOP is considered non standard but it is still valid. A NOP is a No Operation so nothing is done when it is being validated. It can still validate true and be a valid transaction, just that because of the NOP, a node will call it not standard and thus reject the transaction. If the transaction makes it into a block, then the miner thought it was standard. The transaction is still valid so when validating the block, a node will find that the block is valid, just that it contains some non standard but still valid transactions.