Pages:

Author

Topic: Segwit details? N + 2*numtxids + numvins > N, segwit uses more space than 2MB HF - page 3. (Read 21361 times)

CIYAM

legendary

Activity: 1890

Merit: 1078

Ian Knowles - CIYAM Lead Developer

Quote from: JorgeStolfi on March 27, 2016, 01:46:27 PM

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

Rubbish.

I'm sorry but you have not tried to understand one thing but instead tried to just post rubbish again and again and again.

I would recommend that you retire as you have zero understanding of this technology and we have zero tolerance for your ignorance.

(and I 100% expected that you would post such a response as I know that you are just a paid shill - seriously you should be ashamed of yourself - if you have any self-respect at all then just stop posting)

(even your grandchildren would be saying "don't post more crap grandpa")

JorgeStolfi

hero member

Activity: 910

Merit: 1003

Quote from: CIYAM on March 27, 2016, 01:39:25 AM

Quote from: JorgeStolfi on March 27, 2016, 01:35:05 AM

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.

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...

Quote from: JorgeStolfi on March 27, 2016, 01:35:05 AM

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).

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"?

Quote

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)

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?

Quote

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).

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.

CIYAM

legendary

Activity: 1890

Merit: 1078

Ian Knowles - CIYAM Lead Developer

Quote from: achow101 on March 27, 2016, 10:41:36 AM

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.

I think this is the crux of the misunderstanding that others have been having. Valid and standard are not the same thing (but something that is standard is also valid).

Because Bitcoin has introduced an entirely new paradigm (that of P2P consensus) it has had to introduce some new software concepts and I think at this stage this is not being well understood (perhaps not surprisingly).

achow101

staff

Activity: 3374

Merit: 6530

Just writing some code

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.

molecular

donator

Activity: 2772

Merit: 1019

Quote from: CIYAM on March 27, 2016, 01:50:18 AM

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).

CIYAM

legendary

Activity: 1890

Merit: 1078

Ian Knowles - CIYAM Lead Developer

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

donator

Activity: 2772

Merit: 1019

Quote from: CIYAM on March 27, 2016, 01:39:25 AM

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

legendary

Activity: 1890

Merit: 1078

Ian Knowles - CIYAM Lead Developer

Quote from: JorgeStolfi on March 27, 2016, 01:35:05 AM

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).

Quote from: JorgeStolfi on March 27, 2016, 01:35:05 AM

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

donator

Activity: 2772

Merit: 1019

Quote from: CIYAM on March 26, 2016, 11:18:24 PM

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?

Quote from: CIYAM on March 27, 2016, 01:04:50 AM

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.

Quote from: gmaxwell on March 24, 2016, 01:24:27 PM

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?

JorgeStolfi

hero member

Activity: 910

Merit: 1003

Quote from: CIYAM on March 27, 2016, 01:04:50 AM

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?

Quote

(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.

2112

legendary

Activity: 2128

Merit: 1068

Quote from: JorgeStolfi on March 27, 2016, 12:42:31 AM

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.

CIYAM

legendary

Activity: 1890

Merit: 1078

Ian Knowles - CIYAM Lead Developer

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)

JorgeStolfi

hero member

Activity: 910

Merit: 1003

Quote from: CIYAM on March 27, 2016, 12:45:31 AM

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".

Quote

(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

legendary

Activity: 1890

Merit: 1078

Ian Knowles - CIYAM Lead Developer

Quote from: JorgeStolfi on March 27, 2016, 12:42:31 AM

Quote from: CIYAM on March 26, 2016, 11:18:24 PM

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:

Quote from: gmaxwell on March 24, 2016, 01:24:27 PM

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

hero member

Activity: 910

Merit: 1003

Quote from: CIYAM on March 26, 2016, 11:18:24 PM

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:

Quote from: gmaxwell on March 24, 2016, 01:24:27 PM

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?

Quote

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

CIYAM

legendary

Activity: 1890

Merit: 1078

Ian Knowles - CIYAM Lead Developer

Quote from: JorgeStolfi on March 26, 2016, 02:34:20 PM

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)

amaclin

legendary

Activity: 1260

Merit: 1019

Quote from: JorgeStolfi on March 26, 2016, 02:34:20 PM

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

It is not guaranteed.

JorgeStolfi

hero member

Activity: 910

Merit: 1003

Quote from: CIYAM on March 26, 2016, 01:42:45 AM

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"? Grin

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

JorgeStolfi

hero member

Activity: 910

Merit: 1003

Quote from: 2112 on March 25, 2016, 03:56:33 PM

Quote from: JorgeStolfi on March 25, 2016, 03:16:48 PM

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.

gmaxwell

staff

Activity: 4200

Merit: 8441

Quote from: JorgeStolfi on March 25, 2016, 02:29:30 AM

Quote from: gmaxwell on March 24, 2016, 01:24:27 PM

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.