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
toony1 has quit []
rusty has quit [Quit: Leaving.]
<jb55>
only because each field in the bolt11 is tagged with a length so it can catch these. I wonder about deletions now...
accerqueira has joined #bitcoin-wizards
engil1 has joined #bitcoin-wizards
Lightsword has quit [Quit: ZNC]
Lightsword has joined #bitcoin-wizards
guest3456 has left #bitcoin-wizards [#bitcoin-wizards]
pinheadmz has joined #bitcoin-wizards
ghost43 has quit [Remote host closed the connection]
ghost43 has joined #bitcoin-wizards
Chris_Stewart_5 has quit [Ping timeout: 248 seconds]
AaronvanW has joined #bitcoin-wizards
michaelfolkson has joined #bitcoin-wizards
AaronvanW has quit [Ping timeout: 248 seconds]
luke-jr has quit [Excess Flood]
luke-jr has joined #bitcoin-wizards
ccdle12 has quit [Remote host closed the connection]
luke-jr has quit [Excess Flood]
luke-jr has joined #bitcoin-wizards
rusty has joined #bitcoin-wizards
spinza has quit [Quit: Coyote finally caught up with me...]
ddustin_ has joined #bitcoin-wizards
ddustin has quit [Read error: Connection reset by peer]
dgenr8 has quit [Ping timeout: 244 seconds]
luke-jr has quit [Excess Flood]
dgenr8 has joined #bitcoin-wizards
luke-jr has joined #bitcoin-wizards
jtimon has quit [Quit: gone]
luke-jr has quit [Excess Flood]
luke-jr has joined #bitcoin-wizards
spinza has joined #bitcoin-wizards
luke-jr has quit [Excess Flood]
luke-jr has joined #bitcoin-wizards
luke-jr has quit [Excess Flood]
luke-jr has joined #bitcoin-wizards
jb55 has quit [Ping timeout: 246 seconds]
luke-jr has quit [Excess Flood]
luke-jr has joined #bitcoin-wizards
luke-jr has quit [Ping timeout: 258 seconds]
tromp has joined #bitcoin-wizards
luke-jr has joined #bitcoin-wizards
tromp_ has quit [Ping timeout: 252 seconds]
luke-jr has quit [Excess Flood]
justanotheruser has joined #bitcoin-wizards
luke-jr has joined #bitcoin-wizards
justan0theruser has joined #bitcoin-wizards
AaronvanW has joined #bitcoin-wizards
justanotheruser has quit [Ping timeout: 272 seconds]
jb55 has joined #bitcoin-wizards
michaelfolkson has quit [Quit: Sleep mode]
ccdle12 has joined #bitcoin-wizards
TheoStorm has quit [Quit: Leaving]
ccdle12 has quit [Ping timeout: 245 seconds]
ddustin_ has quit [Remote host closed the connection]
ddustin has joined #bitcoin-wizards
ddustin has quit [Remote host closed the connection]
ddustin has joined #bitcoin-wizards
ddustin has quit [Read error: Connection reset by peer]
ddustin has joined #bitcoin-wizards
ddustin has quit [Read error: Connection reset by peer]
ddustin has joined #bitcoin-wizards
AaronvanW has quit [Ping timeout: 272 seconds]
Belkaar has quit [Ping timeout: 248 seconds]
Belkaar has joined #bitcoin-wizards
Belkaar has quit [Changing host]
Belkaar has joined #bitcoin-wizards
AaronvanW has joined #bitcoin-wizards
AaronvanW has quit [Ping timeout: 248 seconds]
<ghost43>
even with bitcoin addresses, one issue is that all already deployed software only validates length for segwit v0
<ghost43>
this includes the reference implementation
<ghost43>
makes sense, as the length is not known for future versions
<ghost43>
but say, people start using v1 addresses, and give it out to existing slow to change implementations or older clients that will not validate v1 length
<ghost43>
bc1p2qmrqwfhhwmdhm8qreqhkx5t0vsd5rtmqxpv9n3rhnjvfy9haq2qkzs3nqp << presumably valid segwit v1 address that can be plausibly spent
<ghost43>
skip the second to last "q", pay to that: bc1p2qmrqwfhhwmdhm8qreqhkx5t0vsd5rtmqxpv9n3rhnjvfy9haq2qkzs3np
<ghost43>
money lost :P
ddustin has quit [Remote host closed the connection]
ddustin has joined #bitcoin-wizards
<ghost43>
"all errors treated equally" sha256 had its pros, not just cons :)
engil1 has quit []
DragonEyes1 has joined #bitcoin-wizards
justan0theruser is now known as justanotheruser
<ghost43>
if, after the soft fork, consensus would enforce the witness program length to be 33 (or whatever is fit), then this risk would go away; but as above, bip-taproot does not enforce witness program length. but even a standardness rule would probably go a long way; and the whole scenario is a bit contrived
ccdle12 has joined #bitcoin-wizards
ccdle12 has quit [Ping timeout: 272 seconds]
AaronvanW has joined #bitcoin-wizards
_whitelogger has joined #bitcoin-wizards
michaelfolkson has joined #bitcoin-wizards
AaronvanW has quit [Ping timeout: 246 seconds]
michaelfolkson has quit [Quit: Sleep mode]
ccdle12 has joined #bitcoin-wizards
michaelfolkson has joined #bitcoin-wizards
michaelfolkson has quit [Client Quit]
AaronvanW has joined #bitcoin-wizards
AaronvanW has quit [Ping timeout: 258 seconds]
luke-jr has quit [Ping timeout: 272 seconds]
luke-jr has joined #bitcoin-wizards
luke-jr has quit [Excess Flood]
luke-jr has joined #bitcoin-wizards
luke-jr has quit [Ping timeout: 244 seconds]
luke-jr has joined #bitcoin-wizards
AaronvanW has joined #bitcoin-wizards
DragonEyes1 has quit []
murrayn has joined #bitcoin-wizards
dscho has joined #bitcoin-wizards
AaronvanW has quit [Ping timeout: 248 seconds]
<jeremyrubin>
Maybe this is silly and I'm missing something, but why use a Merkle Tree at all for taproot? Can't you just do a tweak for every branch? E.g., Q = Tweak(H(Branch 1), Tweak(....,Tweak(Branch N, P))? and then your control is just proving that you can remove one of the tweaks?
<sipa>
jeremyrubin: that's linear
<sipa>
merkle trees are logarithmic
<jeremyrubin>
No?
<jeremyrubin>
Is tweak non-commutative?
<sipa>
yes
<sipa>
if it was commutative we'd have a pretty awesome accumulator :)
<jeremyrubin>
fair point
<sipa>
in particular, tweaking includes a hash
<sipa>
which would break any nice algebraic properties
<sipa>
Tweak(P,s) = P + H(P || s)G
rusty has quit [Quit: Leaving.]
<jeremyrubin>
I see -- there's not a way to make the tweaks be something like... Tweak(P, s1, s2) = P + H(P || H(s1 || s2) || s1) G + H(P || H(s1 || s2) || s2) G
<jeremyrubin>
so that each tweak is not independent of each other, and that you can reveal any one tweak in O(1) space
<sipa>
no, that would imply you have invented an accumulator :)
<sipa>
and afaik there are no EC based accumulators
<jeremyrubin>
Humor me for my own learnin', what's the type of issue with the above EC accumulator?
<jeremyrubin>
(also it's not an accumulator because it's static, can't be grown -- it's more like an accumulated)
<jeremyrubin>
(so I'm not sure if accumulator is the right word)
<jeremyrubin>
Concretely, how am I going to trick you into accepting some s3 against the above?
<jeremyrubin>
s.t. s3 \not\in {s1,s2}
<sipa>
you need to reveal all the scripts
<jeremyrubin>
Why?
<sipa>
how can the verifier compute the hashes otherwise?
<jeremyrubin>
H(s1 || s2) can be provided as is
<sipa>
no, the verifier has to be able to compute all the terms
<jeremyrubin>
No? As long as we hold that the spender and receiver can verify this
<sipa>
tell me exactly what you're giving the verifier, and i'll break it :)
<jeremyrubin>
The bitcoin-verifier need not
<sipa>
it needs to verify something!
<sipa>
what are you revealing on chain when spending?
<jeremyrubin>
Ok let me define three agents: Charlie the Chain, Sarah the Sender, Robert Receiver
<sipa>
no, just tell me the exact things that go on chain
<sipa>
with the s1, s2, P example above
<jeremyrubin>
ok
<jeremyrubin>
On chain goes Q=Tweak(P, s1, s2), P, s1, H(s1||s2)
<sipa>
how does the verifier compute H(P || H(s1 || s2) || s2)G ?
<sipa>
(as that's the difference between Q and P+H(P || H(s1||s2))
<sipa>
so it can't compute H(P || H(s1||s2) || s1)G
<jeremyrubin>
Ah right, so you can just pick an arbitary (Q - stuff) and then cheat the person
<sipa>
yes
<sipa>
i mean; no, you can't verify anything
<jeremyrubin>
All you'd be doing is checking that Q-stuff + stuff = Q
<jeremyrubin>
which is pointless
<sipa>
because you haven't given enough information to let the verifier determine that Q = P + H(P || H(s1 || s2) || s1) G + H(P || H(s1 || s2) || s2) G
<sipa>
right
<sipa>
what you can do is say Q = P + HashToPoint(s1) + HashToPoint(s2) + ...
<sipa>
but you'll still need to reveal all scripts
<sipa>
or at least a hash of every script if you make it Q = P + HashToPoint(H(s1)) + ...
laptop500 has joined #bitcoin-wizards
<jeremyrubin>
And if you were to do something like Q = H(P || H(s1 || s2) || s1) H(P || H(s1 || s2) || s2) P, and I reveal s1, P, H(s1 || s2), \prod H(P || H(s1 || s2) || sn)?
<jeremyrubin>
(I'm not trying to claim that I've discovered something more than the holes in my knowledge)
<sipa>
nothing commits to the product of scalars you claim
<sipa>
so you can change it to be anything, and prove anything