--- Log opened Sun Oct 01 00:00:33 2017
00:09 -!- _whitelogger [~whitelogg@uruz.whitequark.org] has quit [Remote host closed the connection]
00:10 -!- _whitelogger [~whitelogg@uruz.whitequark.org] has joined #bitcoin-wizards
00:13 -!- deusexbeer [~deusexbee@080-250-076-116-dynamic-pool-adsl.wbt.ru] has quit [Ping timeout: 246 seconds]
00:14 -!- deusexbeer [~deusexbee@093-092-177-075-dynamic-pool-adsl.wbt.ru] has joined #bitcoin-wizards
00:32 -!- dnaleor [~dnaleor@78-23-74-78.access.telenet.be] has joined #bitcoin-wizards
00:35 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-wizards
00:59 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-rwfhyamczvtqqpwr] has joined #bitcoin-wizards
01:02 -!- CheckDavid [uid14990@gateway/web/irccloud.com/x-imdnawvjodvhfxso] has quit [Quit: Connection closed for inactivity]
01:04 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection]
01:05 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-wizards
01:33 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has joined #bitcoin-wizards
01:43 -!- CheckDavid [uid14990@gateway/web/irccloud.com/x-uhnccaiqyrrnhnnq] has joined #bitcoin-wizards
01:44 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 264 seconds]
01:54 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]
01:54 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-wizards
02:01 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-wizards
02:23 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards
02:38 -!- jb55 [~jb55@70-36-49-138.dyn.novuscom.net] has quit [Ping timeout: 248 seconds]
02:39 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-wizards
02:48 -!- jtimon [~quassel@199.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 258 seconds]
02:48 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 258 seconds]
02:50 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 258 seconds]
02:50 -!- jtimon [~quassel@199.31.134.37.dynamic.jazztel.es] has joined #bitcoin-wizards
02:51 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-wizards
02:56 -!- pr0zac- [pr0zac@209.130-200-80.adsl-dyn.isp.belgacom.be] has quit []
03:00 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 248 seconds]
03:04 -!- jtimon [~quassel@199.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 258 seconds]
03:08 -!- BashCo_ [~BashCo@unaffiliated/bashco] has joined #bitcoin-wizards
03:11 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 240 seconds]
03:13 -!- dnaleor [~dnaleor@78-23-74-78.access.telenet.be] has quit [Ping timeout: 248 seconds]
03:18 -!- BashCo_ [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 260 seconds]
03:20 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-rryvkxidmgnlfynd] has joined #bitcoin-wizards
03:25 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-wizards
03:27 -!- dnaleor [~dnaleor@78-23-74-78.access.telenet.be] has joined #bitcoin-wizards
03:28 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-wizards
03:41 -!- eck [~eck@fsf/member/eck] has quit [Ping timeout: 248 seconds]
03:43 -!- eck [~eck@fsf/member/eck] has joined #bitcoin-wizards
03:44 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]
03:44 -!- c0rw1n_ [~c0rw1n@cpc109847-bagu17-2-0-cust223.1-3.cable.virginm.net] has joined #bitcoin-wizards
03:53 -!- CheckDavid [uid14990@gateway/web/irccloud.com/x-uhnccaiqyrrnhnnq] has quit [Quit: Connection closed for inactivity]
04:10 -!- daszorz [~daszorz@cpc106809-live29-2-0-cust896.17-2.cable.virginm.net] has joined #bitcoin-wizards
05:05 -!- BashCo_ [~BashCo@unaffiliated/bashco] has joined #bitcoin-wizards
05:05 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Read error: No route to host]
05:18 -!- dnaleor [~dnaleor@78-23-74-78.access.telenet.be] has quit [Quit: Leaving]
05:23 -!- daszorz [~daszorz@cpc106809-live29-2-0-cust896.17-2.cable.virginm.net] has quit [Ping timeout: 258 seconds]
06:17 -!- Emcy_ [~MC@unaffiliated/emcy] has quit [Quit: Leaving]
06:17 -!- Emcy [~MC@unaffiliated/emcy] has joined #bitcoin-wizards
06:22 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-wizards
06:33 -!- dnaleor [~dnaleor@78-23-74-78.access.telenet.be] has joined #bitcoin-wizards
06:38 -!- Noldorin [~noldorin@unaffiliated/noldorin] has joined #bitcoin-wizards
06:40 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]
06:49 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-wizards
06:49 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit]
06:54 -!- dnaleor [~dnaleor@78-23-74-78.access.telenet.be] has quit [Ping timeout: 258 seconds]
06:59 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-rryvkxidmgnlfynd] has quit [Quit: Connection closed for inactivity]
07:07 -!- dnaleor [~dnaleor@78-23-74-78.access.telenet.be] has joined #bitcoin-wizards
07:26 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-wizards
07:29 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-wizards
07:33 -!- jtimon [~quassel@199.31.134.37.dynamic.jazztel.es] has joined #bitcoin-wizards
07:35 -!- arowser [~quassel@106.120.101.38] has quit [Quit: No Ping reply in 180 seconds.]
07:37 -!- arowser [~quassel@106.120.101.38] has joined #bitcoin-wizards
07:39 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds]
08:07 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-wizards
08:09 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]
08:23 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-wizards
08:27 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit]
08:48 -!- PaulCapestany [~PaulCapes@ip72-209-228-52.dc.dc.cox.net] has joined #bitcoin-wizards
09:05 -!- priidu [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards
09:13 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-wizards
09:17 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds]
09:22 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]
09:29 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-wizards
09:31 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-wizards
09:55 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-wizards
10:13 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 258 seconds]
10:18 < maaku> luke-jr: I was going to suggest moving the 520 push limitation too, but unfortunately that's enforced for all witness types :(
10:20 < maaku> It's only there because of implementation issues that could fully be resolved in script, and I don't know why it would exist for non-script witness types
10:21 -!- dnaleor [~dnaleor@78-23-74-78.access.telenet.be] has quit [Quit: Leaving]
10:22 -!- Aranjedeath [~Aranjedea@unaffiliated/aranjedeath] has joined #bitcoin-wizards
10:27 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-wizards
10:31 -!- dnaleor [~dnaleor@78-23-74-78.access.telenet.be] has joined #bitcoin-wizards
10:38 < luke-jr> maaku: eh, no it isn't?
10:39 -!- dnaleor [~dnaleor@78-23-74-78.access.telenet.be] has quit [Quit: Leaving]
10:39 -!- adiabat [~adiabat@45.63.20.152] has quit [Ping timeout: 240 seconds]
10:42 < sipa> maaku: no, it's not
11:03 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-wizards
11:06 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 258 seconds]
11:08 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
11:08 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-wizards
11:13 < maaku> sipa: explain?
11:15 < maaku> there's no opcodes that modify large stack operations. DUP could have reference counting semantics
11:15 < maaku> *large stack items
11:18 -!- MaxSan [~one@185.156.175.35] has joined #bitcoin-wizards
11:21 < sipa> maaku: ?
11:22 -!- daszorz [~daszorz@cpc106809-live29-2-0-cust896.17-2.cable.virginm.net] has joined #bitcoin-wizards
11:22 < sipa> the 520 byte limit only applies to witness v0
11:22 < sipa> and not to the p2wsh program, only to its initial stack
11:22 < maaku> outside of DUP bombs, which are solved by reference counting instead of duplicating, I don't know of any way a single 520kB push is any worse than 1,000 520b pushes, other than filling the script with repeated dup/hash, which can be trivially prevented with hash limits based on witness size
11:23 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-wizards
11:24 < maaku> sipa: Ah, you're right. I misread VerifyWitnessProgram when I looked into this earlier.
11:24 < sipa> the main reason for the limit is that there is no use for large data elements - for now
11:25 -!- BashCo_ [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 240 seconds]
11:25 -!- dnaleor [~dnaleor@78-23-74-78.access.telenet.be] has joined #bitcoin-wizards
11:25 < sipa> and with the program itself no longer falling under that limit, even more so
11:26 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]
11:27 < maaku> It's possible tail-call scripts might want larger than 520 byte subscripts. Possible; I don't know of any examples. MAST itself reduces the maximum subscript size needed considerably.
11:27 < maaku> But a stronger justification is Merkle branch proofs, for which 520 bytes is quite limiting
11:28 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-wizards
11:32 < sipa> i realized yesterday that if you have a sufficiently large merkle tree, an rsa accumulator would be more efficient instead, to produce set inclusion
11:34 < maaku> any idea what that cutoff woul be?
11:34 < sipa> in size, probably at 24 levels
11:35 < maaku> *would be; and can you compactly prove multiple elements?
11:35 < sipa> yes!
11:35 < sipa> constant size
11:35 < sipa> it's also much more cpu intensive to verify...
11:37 < sipa> if you use 3072-bit arithmetic (~128 bit security), i think the proof would be 768 bytes
11:42 < luke-jr> do we need new opcodes still?
11:42 < luke-jr> and are they expensive enough that we lose the "don't need to count sigops" property?
11:42 < maaku> Ok, FWIW my back-of-the-envelope calculation is that for a 256-depth tree (the highest I can reasonably imagine supporting, unless we want 384 for quantum resistance in the hash presumably used as key), the worst case proof of 1,000 items (stack size limit) is ~100kB with our 3 bit bitfield format
11:43 -!- dnaleor [~dnaleor@78-23-74-78.access.telenet.be] has quit [Quit: Leaving]
11:45 < maaku> sipa: that proof would be constant size right? this hypothetical RSAACCUMULATORVERIFY opcode would take N items or hashes from the stack, a 768 byte proof, and a 3072 bit accumulator?
11:46 < maaku> I should go learn how RSA accumulators work, this is a gap in my knowledge :\
11:49 < luke-jr> maaku: the per-input hashing limit seems potentially controversial :/
11:50 < maaku> Proving one element from a 384-depth MBV is 12,434 bytes. One element from a 256-depth MBV is 8,289 bytes. I would be comfortable with a 12.5kB limit in a strawman proposal.
11:51 < maaku> luke-jr: how so?
11:52 < maaku> luke-jr: my thinking is that there isn't really reason to hash something more than a small constant factor, even if we had CAT or CAT-and-HASH opcodes
11:53 < sipa> maaku: so you (the prover) choose two primes p q, with n=p*q a 3072-bit number; you also choose a generator g (which can be a small number, i think 65537 is often used)
11:53 < sipa> then you compute for element in your set g^H(element) (where H is a 3072-bit hash)
11:53 < maaku> e.g. hash tree validation, in script rather than MBV, is absolutely constrained to < 2 * size of leaf hashes + data
11:54 < maaku> i can't think of a reason you'd hash more than that, other than purposeful attack, but maybe my imagination is limited
11:54 < sipa> wait, no, you compute ((g^H(el1))^H(el2))^H(el3) ...
11:54 < sipa> which is efficient if you know p and q
11:55 < sipa> if i want to prove e1 belongs to the set, i reveal H(el2)*H(el3) mod (p-1)*(q-1)
11:55 < sipa> and n
11:57 < sipa> maaku: so i think the CPU time for verifying a proof is proportional to the number of elements you're proving
11:57 < sipa> (one modular exponentiation for each)
12:00 -!- dnaleor [~dnaleor@78-23-74-78.access.telenet.be] has joined #bitcoin-wizards
12:00 -!- dnaleor [~dnaleor@78-23-74-78.access.telenet.be] has quit [Client Quit]
12:02 < sipa> maaku: so OP_RSAACCUMULATORVERIFY would take N items from the stack, a 3072-bit modulus, a 3072-bit exponent, and a 256-bit hash of the expected result
12:03 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 248 seconds]
12:04 -!- BashCo_ [~BashCo@unaffiliated/bashco] has joined #bitcoin-wizards
12:05 < andytoshi> rsa accumulator proofs can be forged by the person who knows p and q can't they? i don't understand how these can be used on a blockchain
12:06 < sipa> andytoshi: the receiver chooses p and q
12:06 < sipa> and p*q is part of the proof
12:07 < andytoshi> right, that's how these are usually used but for MAST there isn't really a receiver
12:07 -!- Dizzle [~Dizzle@2605:6000:1019:42b6:5c7c:7391:c474:6436] has joined #bitcoin-wizards
12:07 < sipa> andytoshi: the signer is the receiver
12:07 < maaku> sipa: ah, i see. thank you for the explanation
12:08 < sipa> andytoshi: right, this may break down in case there are multiple parties involved
12:08 < sipa> it may only work if there is a single coordinator who is involved in every branch
12:08 < andytoshi> right, and that coordinator has the ability to take the coins (and can't provably eliminate this ability)
12:09 < sipa> right
12:09 < maaku> sipa: :( -- large key thresholds are something I was hoping to achieve here
12:09 < maaku> eg. 18 of 30
12:09 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-lozguhsqqilsdxhy] has joined #bitcoin-wizards
12:09 < sipa> andytoshi: unless trusted setup :(
12:11 < sipa> so for this to work we really only need a group of unknown size... it's not needed that there is anyone who can construct an inverse
12:11 < andytoshi> sipa: sure. so fwiw this setup is super easy to split across multiple parties. there are use cases for this but they're more limited than those for MAST
12:11 < andytoshi> otoh you can do weird things like have n parties agree on a bunch of spending conditions (like various thresholds, timelocks etc) and later they can actually add coniditions if they all cooperate
12:12 < andytoshi> sipa: right, that too. you can use a UFO (but those are super big) or satoshi's pgp key or something
12:14 < sipa> having one party that has p and q makes constructing the proof and the 'root' massively cheaper, though
12:15 < andytoshi> yes. the size of the both is linear in the number of participants in the setup
12:15 < andytoshi> unless there is some prime-splitting black magic i have never heard of
12:16 < andytoshi> the setup i'm thinking of is that everyone choses a modulus, and the product of everyone's modulus is used as n, to be clear
12:17 < sipa> but that makes n much larger?
12:17 < andytoshi> yes, its size is linear in the number of participants
12:17 < sipa> yes, then it doesn't solve much :)
12:17 < andytoshi> heh. yeah :/
12:18 < sipa> i guess it could, if you want to do 18-out-of-30, there are only 30 participants
12:18 < sipa> not 30 choose 18
12:18 < sipa> but still... you're not going to beat a merkle tree then
12:28 -!- jb55 [~jb55@70-36-49-138.dyn.novuscom.net] has joined #bitcoin-wizards
12:29 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Ping timeout: 248 seconds]
12:32 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-wizards
12:44 -!- Dizzle [~Dizzle@2605:6000:1019:42b6:5c7c:7391:c474:6436] has quit [Quit: Leaving...]
13:04 -!- adiabat [~adiabat@45.63.20.152] has joined #bitcoin-wizards
13:12 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 258 seconds]
13:12 -!- dnaleor [~dnaleor@78-23-74-78.access.telenet.be] has joined #bitcoin-wizards
13:35 < gmaxwell> andytoshi: MPC construction of RSA numbers isn't that horrible.
13:56 -!- Aranjedeath [~Aranjedea@unaffiliated/aranjedeath] has quit [Ping timeout: 248 seconds]
14:03 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)]
14:13 -!- Aranjedeath [~Aranjedea@unaffiliated/aranjedeath] has joined #bitcoin-wizards
14:25 -!- priidu [~priidu@unaffiliated/priidu] has quit [Remote host closed the connection]
14:27 -!- pro [~pro@unaffiliated/pro] has joined #bitcoin-wizards
14:29 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-lozguhsqqilsdxhy] has quit [Quit: Connection closed for inactivity]
14:35 -!- Aranjedeath [~Aranjedea@unaffiliated/aranjedeath] has quit [Ping timeout: 264 seconds]
14:49 -!- Guest68082 is now known as [Derek]
14:49 -!- [Derek] [~derek@2605:6400:10:3c9:dfd3:3e96:2608:98a7] has quit [Changing host]
14:49 -!- [Derek] [~derek@unaffiliated/derek/x-8562683] has joined #bitcoin-wizards
15:02 -!- vicenteH` [~user@93.104.135.37.dynamic.jazztel.es] has quit [Read error: Connection reset by peer]
15:09 -!- jtimon [~quassel@199.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 240 seconds]
15:09 -!- vicenteH [~user@93.104.135.37.dynamic.jazztel.es] has joined #bitcoin-wizards
15:13 -!- Dizzle [~Dizzle@2605:6000:1019:42b6:7879:b6c2:7928:46e] has joined #bitcoin-wizards
15:28 -!- dnaleor [~dnaleor@78-23-74-78.access.telenet.be] has quit [Quit: Leaving]
15:33 -!- Aranjedeath [~Aranjedea@unaffiliated/aranjedeath] has joined #bitcoin-wizards
15:40 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit []
15:42 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]
15:54 -!- dnaleor [~dnaleor@78-23-74-78.access.telenet.be] has joined #bitcoin-wizards
16:00 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-umjuqozdsrqxsbkh] has joined #bitcoin-wizards
16:07 -!- daszorz [~daszorz@cpc106809-live29-2-0-cust896.17-2.cable.virginm.net] has quit [Read error: Connection reset by peer]
16:19 -!- Aranjedeath [~Aranjedea@unaffiliated/aranjedeath] has quit [Quit: Three sheets to the wind]
16:28 < maaku> luke-jr: I would let v1,20-byte be the hash160 of a script in your proposal
16:29 < luke-jr> maaku: I thought someone cryptographically-smart decided that was too dangerous for scripts?
16:29 < maaku> there's no need for a v1 upgrade to P2WPKH, and thare are potentially legitimate use cases where 160 bits are sufficient
16:30 < maaku> luke-jr: it's a foot-gun protection
16:30 < luke-jr> are there legitimate use cases, though?
16:31 < maaku> the _general_ recommendation is that you use a 256-bit commitment because in the case of a multi-party script construction you're still secure by default without doing anything extra  -- worst they can do is reduce security down to 128 bits
16:31 < luke-jr> hmm
16:31 < maaku> by, e.g., grinding a nonsense public key for a hash collision
16:33 < maaku> but if you are the only party signing a script, but you're using a script instead of P2WPKH because you have more complex policy requirements (CLTV/CSV, multi-key but you own all the keys in different physical HSMs, etc.)
16:34 < maaku> ... then it is safe to have a smaller commitment. 128bit would be fine, but we seem to prefer hash160 over a 16-byte truncated hash, so _shrug_
16:35 < maaku> Or, if you do some sort of setup step where people sign the keys they intend to use, the keys are delinearized, and there is no other source of data like a hash primage, etc.
16:37 < sipa> as long as there is no P2WPKH-like construction that is Schnorr like, 160 bits is probably enough
16:37 < sipa> and a direct pubkey v1 version could be added later
16:38 < maaku> Having a 32-byte commitment by default is necessary to avoid inexperienced people doing dumb things. But it would be nice to save 12 bytes when you can
16:38 < maaku> with proper warning labels and such
16:39 < sipa> well instead of 32-byte hash P2WPKH, there should just be a direct pubkey in the output
16:40 < maaku> sipa: why was non-20, non-32 segwit commitments treated as invalid instead of return true?
16:41 < sipa> maaku: a mistake
16:41 < maaku> ok
16:42 < maaku> then yes, the signature aggregation patchset could later define v1,33-byte as a serialized pubkey using the new scheme, so long as we don't make that same mistake
16:44 < sipa> indeed
16:50 < luke-jr> tempting to try to shove a SHA3 opcode in, but that seems too much XD
16:50 < luke-jr> and annoying to review since the final SHA3 and draft Keccak are incompatible
16:51 < sipa> i think that can perfectly well be done independently later
16:51 < luke-jr> right, that too
16:52 < luke-jr> since we're ignoring sigops all over the place anyway, I'm just going to drop at least the per-script sigop limits..
16:52 < luke-jr> are witness v0 sigops counted toward the block limit right now? (where?)
16:53 < sipa> yes
16:53 < sipa> there is a concept of sigop weight, with a limit of 80000 per block
16:54 < sipa> there are per-script sigop limits?
16:55 < sipa> there is a 201 per-script opcode limit
16:55 < sipa> but that applies to all non-push opcodes, not just sigops
17:01 -!- Dizzle [~Dizzle@2605:6000:1019:42b6:7879:b6c2:7928:46e] has quit [Remote host closed the connection]
17:01 -!- Dizzle [~Dizzle@2605:6000:1019:42b6:7879:b6c2:7928:46e] has joined #bitcoin-wizards
17:03 -!- Dizzle [~Dizzle@2605:6000:1019:42b6:7879:b6c2:7928:46e] has quit [Remote host closed the connection]
17:04 -!- MaxSan [~one@185.156.175.35] has quit [Quit: Leaving.]
17:12 -!- jb55 [~jb55@70-36-49-138.dyn.novuscom.net] has quit [Ping timeout: 258 seconds]
17:15 < luke-jr> sipa: confusing >_<
17:15 < luke-jr> sipa: any reason not to be consistent and drop the toward-block-sigop-limit too?
17:17 < sipa> luke-jr: dropping limits scares me, but there's no reason to not consider it
17:19 < luke-jr> sipa: well, I'd probably leave it, except it's already dropping it for signature-embedded scripts and tail-call scripts anyway..
17:20 < sipa> why would you drop it for those?
17:21 < luke-jr> not practical, since they break static analysis
17:21 < luke-jr> you'd need to count them at execution
17:22 < sipa> i think you either need a way to count them at execution, or not do it then
17:23 < luke-jr> maaku was arguing that sigops are now so cheap that the weight limit is sufficient
17:23 < gmaxwell> only if you can't do 2DUP 2DUP 2DUP 2DUP CHECKSIG CHECKSIG CHECKSIG ...
17:23 < luke-jr> otoh, the possibility of recursive CHECKSIGs may change that :x
17:24 < luke-jr> hrm
17:24 < gmaxwell> I think the seperate limit can go away, but you can't stop counting. you need to compute a weight equivilent checksig count or whatnot.
17:24 < luke-jr> gmaxwell: what need is there to count, if you don't limit it?
17:25 < luke-jr> or you mean add it to the weight? (effectively decreasing block sizes?)
17:25 < gmaxwell> It's not reasonable to ignore it completely, weight is not sufficient if you can just do the example I just gave, where each operation costs 2 weight.
17:26 < luke-jr> hmm
17:26 < gmaxwell> weight needs to only be one dimensional linear on a whole block basis, within a single transaction you can do things like:
17:26 < gmaxwell> tx_weight = max(size + stripped_size*3, sigops * constant)
17:27 < luke-jr> I suspect counting at execution will be painful. :<
17:27 < gmaxwell> so that ordinary transactions work like now, but sigops abusers get a higher effective weight.
17:28 < gmaxwell> It sure shouldn't be. The execution already has to be exactly specified for other reasons. e.g. you need to precisely specify which gets executed so you terminate on invalidity in a consensus consistent way.
17:29 -!- jb55 [~jb55@70-36-49-138.dyn.novuscom.net] has joined #bitcoin-wizards
17:29 < luke-jr> well, I need to be absolutely sure the end count comes out the same as the static method
17:30 < sipa> not if it's the only method
17:31 < luke-jr> the current consensus rules use the static method
17:31 < sipa> the current consensus rules don't apply to v1 scripts
17:31 < luke-jr> right, I was thinking of refactoring sigops everywhere
17:31 < luke-jr> I guess that's unnecessary
17:33 < gmaxwell> The next question though is it better to do that non-linearity per transaction or per input.  Per input would be better for reasoning about fees if inputs are independanly computed.
17:33 -!- jb55 [~jb55@70-36-49-138.dyn.novuscom.net] has quit [Ping timeout: 248 seconds]
17:34 -!- dnaleor [~dnaleor@78-23-74-78.access.telenet.be] has quit [Quit: Leaving]
17:37 < maaku> luke-jr: I think you shouldn't add anything new except for the prefixed script version in witness
17:37 < maaku> the only other thing you should do is cut things out, like unnecessary limits
17:37 < maaku> (which sometimes means adding new things, making policy consensus or new per-input limits, to make that safe)
17:40 < maaku> gmaxwell: 2DUP 2DUP ... CHECKSIG CHECKSIG ... doesn't do much thanks to the signature cache.
17:41 < gmaxwell> then you've just made specific caching behavior consensus critcial... and there are similarly short sequences that can't be cached (or at least there are if the opcode set isn't absurdly limited)
17:41 < maaku> it's not consensus critical, just critical to performance guarantees
17:42 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards
17:42 < gmaxwell> it's consensus critical because if you don't implement it you will potentially verify slowly enough that you'll end up on a seperate chain in the presence of it.
17:43 < gmaxwell> performance can be consensus critical, that fact that it doesn't form a black and white boundary doesn't make that not the case.
17:43 < maaku> go benchmark secp256k1 and see how long it will take you to verify a block chock full of CHECKSIGs
17:44 < sipa> around a minute, on reasonable hardware
17:44 < maaku> sipa: and that's a single core, I presume, based on my own checks
17:44 < gmaxwell> two million checksigs are about two minutes, on a fastish i7, verified sequentially.
17:44 < sipa> maaku: no, quadcore
17:45 < gmaxwell> and that is more than enough to split the network.
17:45 < maaku> if that's not acceptable, then limit an input to no more than witness_size / 64 checksigs.
17:45 < maaku> now you've reduced it to seconds
17:45 < gmaxwell> Thats what it appears that you were arguing against above. :)
17:46 < maaku> > 01:37 < maaku> (which sometimes means adding new things, making policy consensus or new per-input limits, to make that safe)
17:46 < maaku> per-input, not per-block
17:46 < maaku> it doesn't enter into transaction selection that way.
17:46 < gmaxwell> maaku: you should read the backscroll.
17:48 < maaku> I don
17:48 < maaku> I don't see myself saying anything different
17:48 < gmaxwell> You're repeating what I said above, before you started talking but it sounds like you're disagreeing.
17:48 < sipa> luke-jr: i don't understand why a separate witness for code would be needed
17:48 < sipa> luke-jr: bip114 does not need it
17:49 < sipa> gmaxwell, maaku: this discussion is too meta for me to follow
17:49 < sipa> please, repeat the statement you saw someone make you agree or disagree with - i think it would help everyone
17:54 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-rwfhyamczvtqqpwr] has quit [Quit: Connection closed for inactivity]
17:59 -!- Dizzle [~Dizzle@2605:6000:1019:42b6:c846:ebe4:ad55:7ad6] has joined #bitcoin-wizards
17:59 -!- Belkaar [~Belkaar@unaffiliated/belkaar] has quit [Ping timeout: 248 seconds]
18:00 -!- Belkaar [~Belkaar@xdsl-87-78-142-226.netcologne.de] has joined #bitcoin-wizards
18:00 -!- Belkaar [~Belkaar@xdsl-87-78-142-226.netcologne.de] has quit [Changing host]
18:00 -!- Belkaar [~Belkaar@unaffiliated/belkaar] has joined #bitcoin-wizards
18:11 -!- dabura667 [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has joined #bitcoin-wizards
18:12 -!- jb55 [~jb55@72.143.220.46] has joined #bitcoin-wizards
18:18 -!- dnaleor [~dnaleor@78-23-74-78.access.telenet.be] has joined #bitcoin-wizards
18:19 -!- dnaleor [~dnaleor@78-23-74-78.access.telenet.be] has quit [Remote host closed the connection]
18:23 -!- dnaleor [~dnaleor@78-23-74-78.access.telenet.be] has joined #bitcoin-wizards
18:24 -!- jb55 [~jb55@72.143.220.46] has quit [Ping timeout: 260 seconds]
18:25 -!- jb55 [~jb55@72.143.220.46] has joined #bitcoin-wizards
18:39 < maaku> I'm not sure. I don't think it's relevant. I think we should drop limits where we can and where the worst you can do with them is comparable to what can be accomplished by other means.
18:40 < maaku> That means ideally just the size/weight limit, and everything else is naturally limited because we've eliminated anything with greater than linear cost, and the max block weight is picked from the worst thing you can do, extrapolated to fill the block.
18:42 < maaku> In this case that means making signature caches a requirement for low latency validation, and maybe some other tweaks, or if that can't be accomplished then have a per-input limit instead of a global one, so transaction selection still deals with a linear metric.
18:43 < maaku> Obviously we can't change existing global limits, but at least don't make it worse by continuing to count towards them in new-style scripts.
18:43 < sipa> thanks, now i understand what you're talking about :)
18:44 -!- c0rw1n_ [~c0rw1n@cpc109847-bagu17-2-0-cust223.1-3.cable.virginm.net] has quit [Quit: Leaving]
18:45 -!- c0rw1n_ [~c0rw1n@cpc109847-bagu17-2-0-cust223.1-3.cable.virginm.net] has joined #bitcoin-wizards
18:49 -!- dnaleor [~dnaleor@78-23-74-78.access.telenet.be] has quit [Remote host closed the connection]
18:49 < luke-jr> I'm liking the idea of requiring all executable stuff be directly in the witness stack, and having a tag at the start of each element for number of times executed..
18:49 < luke-jr> does that work for all use cases?
18:49 < luke-jr> (this preserves static analysis)
18:50 < sipa> why would the number of times executed be above 1?
18:50 < gmaxwell> maaku: but then you end up with patterns like DUP2 DUP HASH160 XOR DUP2 DUP HASH160 XOR DUP2 DUP HASH160 XOR... CHECKSIG CHECKSIG CHECKSIG  being phenominal blowups it worst case cost.
18:51 < luke-jr> sipa: using the same condition script for multiple signatures, for example
18:52 < sipa> luke-jr: it's either valid or not, no need to evaluate it more than once
18:52 < gmaxwell> e.g. that has checksig costs about 20 times higher per weight than sane usage, which effectively translates into limits that need to be lower (perhaps under some arguments 20x lower)
18:53 < sipa> luke-jr: i haven't read about the condition script - it sounds a bit like signature delegatio
18:53 < luke-jr> sipa: hm, that might be worth giving up the stack copy to guarantee..
18:53 < sipa> stack copy?
18:53 < luke-jr> sipa: yes, the signature is currently appended with a script, which is executed with a copy of the current stack
18:53 -!- dnaleor [~dnaleor@78-23-74-78.access.telenet.be] has joined #bitcoin-wizards
18:54 < sipa> luke-jr: giving it a separate stack sounds safer
18:54 < luke-jr> I haven't thought through if there are any use cases for the stack copy
18:54 < sipa> or rather, a separate initial stack
18:55 < luke-jr> but separate stack and cache the answer sounds like a good idea
18:55 < luke-jr> right
18:55 < luke-jr> especially since the condition scripts are most likely to be used for things like CHECKBLOCKATHEIGHT, which are likely to be reused for all sigs
18:55 < sipa> it sounds a bit premature to include that in a proposal right now, though
18:55 < luke-jr> it's a pretty annoying thing to have missing in Segwit IMO
18:56 < gmaxwell> ugh, please. don't propose things inside script that aren't pure functions of the transactions; thats recreating the ethereum non-scalablity disaster.
18:56 < luke-jr> gmaxwell: ?
18:56 < gmaxwell> that was a comment to CHECKBLOCKATHEIGHT
18:57 < luke-jr> we don't have any place to put it outside script..?
18:57 < gmaxwell> if the validity of a transactions scripts aren't a pure function of the transaction you must reevaluate the scripts every time something changes that could invalidate them, which means you either need tracing execution that extracts the invarients, or no caching at all or...
18:58 < luke-jr> or cache the additional condition
18:58 < gmaxwell> So? Life is hard. The fact that it's currently the only way you have to do it doesn't makes it acceptable.
18:58 < gmaxwell> Script's purity is a long standing design invarient that we reconized as important, a view which has only been confirmed by the total mess in ethereum.
18:59 -!- jb55 [~jb55@72.143.220.46] has quit [Ping timeout: 240 seconds]
18:59 < luke-jr> I don't see why this should be unacceptable. It's more or less the same thing as SigAgg?
18:59 < sipa> sigagg validity only depends on the txn
18:59 < sipa> not on the context in which it is evaluated
19:00 < luke-jr> sipa: implement CHECKBLOCKATHEIGHT as "always NOP, but log a condition for the transaction to be valid"
19:00 < luke-jr> this way, it's effectively the same as the locktime field
19:00 < gmaxwell> (the other problem with CHECKBLOCKATHEIGHT is that it causes all outputs of the transaction to be non-equally fungible due to their destruction in reorg, so they need maturity like coinbases)
19:00 < luke-jr> except you don't need to store it redundantly
19:00 < sipa> luke-jr: right, so make it actual work like locktime, not as a script feature
19:01 < luke-jr> sipa: that's insanely more complex, for negative value..
19:01 < luke-jr> (now your transaction needs to specify the information twice, and it doesn't improve anything)
19:01 < sipa> i don't understand
19:02 < sipa> for example, allow a particular witness stack element to encode an extra condition
19:02 < sipa> which does not require scriot execution to detect
19:02 < sipa> and signatures automatically commit to it
19:03 < sipa> as if it were part of the txin
19:03 < luke-jr> and then in the script, you still need a CLTV-equivalent with a copy of the data, to make sure it's in there..?
19:03 < luke-jr> hmm, I guess that's redundant with the CHECKSIG
19:04 < luke-jr> provided there is a CHECKSIG in the first place (but condition scripts don't help if there aren't anyway)
19:04 < luke-jr> ok, so how would you detect the particular witness stack element? add a type prefix to every element? :/
19:04 < sipa> fair, but transactions with no checksigs at all are pointless anyway
19:05 < sipa> luke-jr: let the bikeshedding begin :)
19:05 < luke-jr> :<
19:10 < luke-jr> while a possible option, I don't really see how this is *better* than a CLTV-like opcode that implies the locktime on the tx rather than requires a separate commitment. It just adds complexity, but the net result is essentially identical.
19:10 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-wizards
19:13 < luke-jr> I suppose it comes down to the static analysis thing again
19:15 < maaku> sipa: a hypothetical 2-way SPV peg implemented in an expanded script would have no checksigs but be useful
19:15 < maaku> also there's NONE|ANYONECANPAY
19:17 < luke-jr> maaku: in that hypothetical, I'm not sure there is a use case for replay protection
19:20 < sipa> luke-jr: it isn't. if the context is visible.to svript execution, you need to invoke the script validation essentially after every block for your whole mempool, for example
19:20 < sipa> things that are recognizable external to scripts can be dealt with directly
19:23 < sipa> luke-jr: for example, in CLTV, we can just reevaluate the locktimes when a reorg occurs... we know the script validity can't ever change
19:23 < luke-jr> sipa: no, because the outcome of CHECKBLOCKATHEIGHT (hypothetical, ignore the BIP for now) would be NOP *always*; there is a side effect of copying the expected block hash and height to a transaction variable, which is the same for all executions of that script; the transaction validity depends on compatibility of the context and that variable
19:23 < luke-jr> it's the same as runtime counting of sigops
19:24 < sipa> define 'transaction variable' ?
19:24 < sipa> ah, i see - some tx-wide result of script execution
19:24 < luke-jr> sipa: we could store it on CTxMemPoolEntry, or even CTransaction (but never serialise it)
19:24 < luke-jr> right
19:24 < sipa> i think that's ugly - just make the outcome of that variable directly something part of the transaction
19:25 -!- pro [~pro@unaffiliated/pro] has quit [Quit: Leaving]
19:25 < sipa> why make it be the outcome of script validation?
19:25 < sipa> it's semantically the same, but the construction is easier
19:25 < luke-jr> simpler and less ugly :x
19:26 < luke-jr> also programmable
19:26 < luke-jr> eg, this way a script can commit upfront to specific heights
19:27 < sipa> right
19:27 -!- dnaleor [~dnaleor@78-23-74-78.access.telenet.be] has quit [Quit: Leaving]
19:29 < sipa> you effectively have the script has output true/false, plus a list of additional validity criteria
19:30 < sipa> but the evaluation itself is context independent, it's just the produced criteria that may be context-dependent and need re-evaluation
19:31 < luke-jr> right, and in this case, the end output can be collapsed for all the inputs
19:31 < luke-jr> (select the lattermost height)\
19:31 < luke-jr> well, assuming the inputs don't contradict each other.. maybe not so simple to optimise there
19:31 < gmaxwell> among other things now you need to execute scripts fully to even know if the result is valid with your current context.
19:32 < gmaxwell> you cannot ban a peer for having a different context than you...
19:32 < luke-jr> hmm, true
19:33 < gmaxwell> and you also now have some output property (outputs that need maturity) depending on script execution.
19:34 < luke-jr> ugh
19:35 < luke-jr> if only the witness data was a map.. XD
19:36 < luke-jr> I suppose we could serialize the entire initial-stack for witnessv1.. although that feels ugly, it's probably less ugly than tagging every single stack item?
19:36 < luke-jr> (going back to sipa's idea of a witness-data field)
19:38 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 240 seconds]
19:41 < maaku> luke-jr: you might consider expanding the CHECKBLOCKATHEIGHT bip. it's not obvious to me what use cases it enables that are both interesting and not easily accomplished by other means
19:44 < luke-jr> maaku: not sure what there is to say besides the Motivation section.. :/
19:45 < luke-jr> you're looking at the BIP 115, right?
19:49 -!- carman^^ [d55657e4@gateway/web/freenode/ip.213.86.87.228] has joined #bitcoin-wizards
19:52 -!- dnaleor [~dnaleor@78-23-74-78.access.telenet.be] has joined #bitcoin-wizards
19:53 -!- dnaleor [~dnaleor@78-23-74-78.access.telenet.be] has quit [Remote host closed the connection]
19:54 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 248 seconds]
20:12 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-wizards
20:13 -!- dnaleor [~dnaleor@78-23-74-78.access.telenet.be] has joined #bitcoin-wizards
20:17 -!- carman^^ [d55657e4@gateway/web/freenode/ip.213.86.87.228] has quit [Quit: Page closed]
20:22 -!- Emcy [~MC@unaffiliated/emcy] has quit [Ping timeout: 258 seconds]
20:24 -!- Emcy [~MC@unaffiliated/emcy] has joined #bitcoin-wizards
20:36 -!- jb55 [~jb55@70-36-49-138.dyn.novuscom.net] has joined #bitcoin-wizards
20:42 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 240 seconds]
20:54 < CryptAxe> It seems like the relay protection that OP_CHECKBLOCKATHEIGHT would provide couldn't be done in any other way, so there's that
20:55 < CryptAxe> Also didn't see what time you guys were disussing this but maybe you'll still see that
21:00 -!- legogris [~legogris@128.199.205.238] has quit [Remote host closed the connection]
21:00 -!- legogris [~legogris@128.199.205.238] has joined #bitcoin-wizards
21:02 -!- dnaleor [~dnaleor@78-23-74-78.access.telenet.be] has quit [Quit: Leaving]
21:05 -!- TheSeven [~quassel@rockbox/developer/TheSeven] has quit [Ping timeout: 246 seconds]
21:07 -!- jb55 [~jb55@70-36-49-138.dyn.novuscom.net] has quit [Ping timeout: 240 seconds]
21:08 -!- TheSeven [~quassel@rockbox/developer/TheSeven] has joined #bitcoin-wizards
21:12 -!- Noldorin [~noldorin@unaffiliated/noldorin] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
21:12 -!- jb55 [~jb55@70-36-49-138.dyn.novuscom.net] has joined #bitcoin-wizards
21:27 -!- _whitelogger [~whitelogg@uruz.whitequark.org] has quit [Remote host closed the connection]
21:28 -!- _whitelogger [~whitelogg@uruz.whitequark.org] has joined #bitcoin-wizards
21:34 -!- CubicEarth [~cubiceart@c-73-181-185-197.hsd1.wa.comcast.net] has joined #bitcoin-wizards
21:37 -!- TheSeven [~quassel@rockbox/developer/TheSeven] has quit [Ping timeout: 258 seconds]
21:37 -!- [7] [~quassel@rockbox/developer/TheSeven] has joined #bitcoin-wizards
22:04 -!- Dizzle [~Dizzle@2605:6000:1019:42b6:c846:ebe4:ad55:7ad6] has quit [Remote host closed the connection]
22:05 -!- Dizzle [~Dizzle@2605:6000:1019:42b6:c846:ebe4:ad55:7ad6] has joined #bitcoin-wizards
22:22 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 248 seconds]
22:25 -!- CubicEarth [~cubiceart@c-73-181-185-197.hsd1.wa.comcast.net] has quit []
22:35 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection]
22:36 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-wizards
22:42 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-wizards
22:47 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards
22:47 -!- Dizzle_ [~Dizzle@2605:6000:1019:42b6:494d:cb5b:3316:57e0] has joined #bitcoin-wizards
22:48 -!- Dizzle [~Dizzle@2605:6000:1019:42b6:c846:ebe4:ad55:7ad6] has quit [Disconnected by services]
22:48 -!- Dizzle_ is now known as Dizzle
22:52 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]
22:56 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-wizards
22:58 -!- kisspunch [~za3k@smtp.za3k.com] has quit [Quit: ZNC - http://znc.in]
22:59 -!- kisspunch [~za3k@smtp.za3k.com] has joined #bitcoin-wizards
23:03 -!- kisspunch [~za3k@smtp.za3k.com] has quit [Client Quit]
23:03 -!- kisspunch [~za3k@smtp.za3k.com] has joined #bitcoin-wizards
23:05 -!- kisspunch [~za3k@smtp.za3k.com] has quit [Client Quit]
23:06 -!- kisspunch [~za3k@smtp.za3k.com] has joined #bitcoin-wizards
23:07 -!- jb55 [~jb55@70-36-49-138.dyn.novuscom.net] has quit [Ping timeout: 258 seconds]
23:13 -!- bsm117532 [~mcelrath@static-100-38-216-231.nycmny.fios.verizon.net] has quit [Ping timeout: 248 seconds]
23:28 -!- kisspunch [~za3k@smtp.za3k.com] has quit [Quit: ZNC - http://znc.in]
23:28 -!- kisspunch [~za3k@smtp.za3k.com] has joined #bitcoin-wizards
23:50 < maaku> CryptAxe: there are a great many other ways that replay protection can be provided
23:50 < maaku> luke-jr: I was looking at an earlier version in your repo it seems. the one in the bips repo is more clear
23:53 < maaku> But the first motivating feature, "Securely recovering from double spends" seems like a NASA space pen vs Russian pencil situation. We have a mechanism for resolving double-spends. If you want to make sure that one transaction is dependent on another transaction going through, including an output linking the two.
23:54 -!- BashCo_ [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]
23:55 < maaku> The second motivating feature is not very motivating. Purposeful chain splits should have built-in replay protection, by changing the signature hash, for example, and we should be advocating for a standard approach to that (in as much as we should be advocating for anything regarding chain splits)
23:58 < maaku> pinning specific block heights has the disadvantage of not being something you can do until after the split, whereas most people are interested in preparing for the split -- signing time-locked transactions valid on one but not the other. And if you constrain yourself to only being able to sign post-split, then there's already an existing technique that requires no consensus code changes -- using
23:58 < maaku> post-split coinbase outputs or their descendents
--- Log closed Mon Oct 02 00:00:34 2017