sipa changed the topic of #bitcoin-wizards to: This channel is for discussing theoretical ideas with regard to cryptocurrencies, not about short-term Bitcoin development | http://bitcoin.ninja/ | This channel is logged. | For logs and more information, visit http://bitcoin.ninja
leonardo2 has quit []
Mark_Cockrell has joined #bitcoin-wizards
davterra has quit [Quit: Leaving]
laptop500 has quit [Ping timeout: 272 seconds]
michaelfolkson has quit [Quit: Sleep mode]
Krellan has joined #bitcoin-wizards
DeanGuss has joined #bitcoin-wizards
Zenton has quit [Ping timeout: 248 seconds]
DeanGuss has quit [Ping timeout: 260 seconds]
davterra has joined #bitcoin-wizards
davterra has quit [Remote host closed the connection]
elichai2 has quit [Quit: Connection closed for inactivity]
Belkaar_ has quit [Ping timeout: 258 seconds]
Belkaar has joined #bitcoin-wizards
Belkaar has joined #bitcoin-wizards
Belkaar has quit [Changing host]
tombusby has quit [Ping timeout: 260 seconds]
brianhoffman has quit [Ping timeout: 244 seconds]
tombusby has joined #bitcoin-wizards
brianhoffman has joined #bitcoin-wizards
mdunnio has joined #bitcoin-wizards
mdunnio has quit [Client Quit]
Mark_Cockrell has quit []
CjNr11 has joined #bitcoin-wizards
elichai2 has joined #bitcoin-wizards
_whitelogger has joined #bitcoin-wizards
<kallewoof>
Right now the new signmessage system assumes that a proof is valid iff the standard script verify flags embedded into the proof are equal to those of the verifying node. This is done to deal with verifiers running into unknown consensus rules and mistakenly claiming an invalid proof is valid (or vice versa). I would argue, however, that the standard verify flags will very seldomly drop any flags and will almost always add
<kallewoof>
discourage_upgradable_nops + cleanstack + minimalif + nullfail + cltv + csv + low_s + witness + dscourage_upgradable_wit + wit_pubkeytype + const_scriptcode and v2 would be all of that plus e.g. witness v1 or whatever the next thing is).
<kallewoof>
flags. So a verifier who sees a proof with fewer flags than the verifier should conclude that a proof that is valid under the verifier's (stricter) rules, is valid. Is that a valid assumption? (Also: standard verify flags are apparently not standardized, which sucks for other software. I wonder if I should just apply a version and map it to a set of flags (i.e. v1 = p2sh + dersig + strictenc + minimaldata + nulldummy +
vtnerd has quit [Ping timeout: 245 seconds]
vtnerd has joined #bitcoin-wizards
<kallewoof>
I didn't realize that the STANDARD_SCRIPT_VERIFY_FLAGS value was not standard across software, so I am going to switch this to a version number where each version is associated with a set of rules. This will have to be maintained, but it seems unreasonable to force on others. (And as Nicolas Dorier pointed out to me in private, if someone refactored these flags, suddenly every other software out there must be updated.
<kallewoof>
Since people use different numbers for different rules, they have to keep a hardcoded number based on bitcoin core around, which is just silly.
vtnerd has quit [Ping timeout: 245 seconds]
vtnerd has joined #bitcoin-wizards
Krellan has quit [Remote host closed the connection]
emilengler has quit [Ping timeout: 246 seconds]
CjNr11 has quit []
<sipa>
kallewoof: my suggestion earlier was that you'd verify twice, once with just consensus rules and once with standard rules, and if the result differs, call it inconclusive
<sipa>
this would automatically account for most uogrades
<sipa>
because those generally get defined as things that used to be nonstandard before
<sipa>
in fact, you just need consensus, and consensus+discourage flags
<sipa>
(the ones making future witness versions invalid etc)
<kallewoof>
sipa: Right now I am including and comparing the prover's flags. Sounds like I dno't even need to do that.
<sipa>
you may still need a version number then, but just when the set of discourage mechanisms changes
<sipa>
which is likely even less frequently than consensus changes
<sipa>
oh you cannot leak the internal values of the verifier flagz
<sipa>
those are internal to bitcoin core and can change arbitrarily
ao2 has joined #bitcoin-wizards
<kallewoof>
Prover you mean?
ao2 is now known as Guest64082
<sipa>
well, they're called verifier flags!
<kallewoof>
And yeah, I realized.
<sipa>
but yes on the prover side
<kallewoof>
oops, yes that's true
<sipa>
or the meaning of existing flags can change over time, and in fact has from time to.time
<sipa>
one difficulty is that most software doesn't have (or even needs) a generic script interpreter
<sipa>
so they're likely restricted to supporting subsets using template matching or whatever
<kallewoof>
the signer puts the version in the proof, so if a version bump is needed to prevent a malicious fake proof, the evil dude will just not update the version number to get around it.
<sipa>
do you understand my idea with two verifications?
<kallewoof>
yes, that part i realize (and remember now).
<kallewoof>
It's obviously the way to go and I will fix the BIP asap.
<sipa>
so i guess you need a version number
<sipa>
and you specify v0 as the current consensus rules, and addition verification using that + discourage_bla (and perhaps things like cleanstack, which may be used for upgrades)
<kallewoof>
It's pointless though. The prover will just use whatever version makes their proof look valid. Or whatever the minimum version at the time happens to be.
<kallewoof>
The verifier will use THEIR standard flags for proof 1 and the consensus flags for proof 2 and base their decision on that, regardless of prover version.
<sipa>
wowow there is just one proof
<kallewoof>
Sorry, I meant verification 1 and 2.
<sipa>
hmm, let me think about thay
<kallewoof>
The two rounds you mentioned above. Same proof both times.
<sipa>
yeah
<sipa>
this is hard
<sipa>
i guess you can do without version number, indeed
<sipa>
it's scary though
<kallewoof>
I'm not sure how a version flag would prevent anything.
<kallewoof>
Anything attack-y.
<aj>
isn't it: if (VerifyStd==OK) { GOOD } else if (VerifyCons==OK && myVER < theirVER) { report("need version newer than theirVER"); } else { BAD } ?
elichai2 has quit [Quit: Connection closed for inactivity]
<kallewoof>
aj: prover can just set theirVER to myVER + 1 and avoid BAD
<aj>
kallewoof: yeah. and try to convince you to upgrade to bitcoin 2.19 only available from the-real-bitcoin.biz
<kallewoof>
Right, but we get the two cases (without BAD) even without a version. A malicious prover would use a version deliberately higher. Nothing really changes.
<NicolasDorier>
aj: I am not fan of this idea, the problem is: Any consensus upgrade will basiclaly make unupgraded verifyer reporting "need version newer than theirVER". Even if the new consensus rule actually does not impact at all the verifying process. (P2PWKH)
<NicolasDorier>
I think the version though for being able to upgrade the proof format
<sipa>
no
<sipa>
new consensus rules that aren't used in the proof won't change the result
<NicolasDorier>
`if (VerifyStd==OK) { GOOD } else if (VerifyCons==OK && myVER < theirVER) { report("need version newer than theirVER"); } else { BAD }`
<NicolasDorier>
in this case yes
<NicolasDorier>
in this case it would
<sipa>
oh, i was talking about my consensus/standard check
<NicolasDorier>
yeah I like it
<NicolasDorier>
I am just wondering if any version field is useful at all. I think it can be useful to upgrade the signature format one day
<NicolasDorier>
outside of that I don't think it is
<NicolasDorier>
the proof format I mean
<sipa>
it's scary that it does mean that old nodes with long outdated discourage rules may accept an invalid proof
<sipa>
but i also don't see a way to prevent that
<NicolasDorier>
well the source of truth is always somebody's node so no way to prevent this
<NicolasDorier>
also the signer would be able to trick the verifier anyway since he is in control of what to put in the version field
<kallewoof>
A non-malicious prover may inadvertently give someone a proof that is invalid but the verifier doesn't catch it. The prover would never make an invald proof though, unless they are malicious, and if they are, they would use a version flag that would make their proof validate for the victim.
<NicolasDorier>
Anyway for whichever reason I think a version number is fine. There is at least once reason: being able to change proof format later on if needed