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
Guest3606 has quit []
llfourn` has joined #bitcoin-wizards
Chris_Stewart_5 has quit [Ping timeout: 265 seconds]
llfourn` has quit [Remote host closed the connection]
llfourn` has joined #bitcoin-wizards
nuncanada has quit [Read error: Connection reset by peer]
Belkaar has quit [Ping timeout: 245 seconds]
Belkaar has joined #bitcoin-wizards
Belkaar has quit [Changing host]
Belkaar has joined #bitcoin-wizards
pinheadmz has quit [Quit: pinheadmz]
pinheadmz has joined #bitcoin-wizards
McMurdo has joined #bitcoin-wizards
mappum has joined #bitcoin-wizards
mappum has quit [Client Quit]
McMurdo has quit [Ping timeout: 260 seconds]
mappum has joined #bitcoin-wizards
kutio has quit []
superkuh_ has joined #bitcoin-wizards
fnichol has joined #bitcoin-wizards
llfourn` has quit [Ping timeout: 258 seconds]
fox2p has quit [Ping timeout: 248 seconds]
llfourn` has joined #bitcoin-wizards
fox2p has joined #bitcoin-wizards
superkuh_ has quit [Quit: the neuronal action potential is an electrical manipulation of reversible abrupt phase changes in the lipid bilayer]
mappum has quit [Quit: Connection closed for inactivity]
Krellan_ has quit [Quit: Leaving...]
fnichol has quit []
slivera has quit [Remote host closed the connection]
kabaum has quit [Ping timeout: 250 seconds]
fancyremarker has joined #bitcoin-wizards
llfourn` has quit [Ping timeout: 252 seconds]
Dean_Guss has quit [Remote host closed the connection]
Dean_Guss has joined #bitcoin-wizards
ghost43 has quit [Ping timeout: 260 seconds]
rusty has quit [Quit: Leaving.]
votesmith has quit [Ping timeout: 265 seconds]
Dean_Guss has quit [Remote host closed the connection]
Dean_Guss has joined #bitcoin-wizards
votesmith has joined #bitcoin-wizards
llfourn` has joined #bitcoin-wizards
llfourn` has quit [Ping timeout: 268 seconds]
kabaum has joined #bitcoin-wizards
Kiminuo has joined #bitcoin-wizards
kabaum has quit [Ping timeout: 258 seconds]
kabaum has joined #bitcoin-wizards
llfourn` has joined #bitcoin-wizards
llfourn` has quit [Ping timeout: 258 seconds]
laptop500 has joined #bitcoin-wizards
spinza has quit [Quit: Coyote finally caught up with me...]
spinza has joined #bitcoin-wizards
kabaum has quit [Ping timeout: 245 seconds]
marcoagner has joined #bitcoin-wizards
jonatack has quit [Ping timeout: 252 seconds]
fancyremarker has quit []
kabaum has joined #bitcoin-wizards
spinza has quit [Quit: Coyote finally caught up with me...]
gde331 has joined #bitcoin-wizards
spinza has joined #bitcoin-wizards
llfourn` has joined #bitcoin-wizards
Guyver2 has joined #bitcoin-wizards
llfourn` has quit [Ping timeout: 248 seconds]
jeremyrubin has quit [Ping timeout: 265 seconds]
spinza has quit [Quit: Coyote finally caught up with me...]
spinza has joined #bitcoin-wizards
spinza has quit [Quit: Coyote finally caught up with me...]
t-bast has joined #bitcoin-wizards
<t-bast>
Hey! I've been wondering if people have already suggested in the past to split the signature into two separate stack arguments for OP_CHECKSIG?
<t-bast>
It would allow a very limited form of OP_SPLIT/CAT that would allow leveraging nonce reuse as a feature against double-spending
<t-bast>
Unless I missed something obvious (which is totally possible)
<gmaxwell>
That would make the overwhelmingly common case less efficient, doesn't seem like a good tradeoff.
<gmaxwell>
Also, sharing R in advance is insecure if someone else can grind the message you'll sign.
<gmaxwell>
already the encoding is carefully setup to use a fixed length for r, so it could be split and compared with a hash (for example) with other opcodes.
<t-bast>
In my case I wouldn't be sharing R in advance since it would be hidden in the script leaf. However when I do reveal it, that means I'm committing to spend my UTXO with that specific tx. I believe this could be quite helpful in many scenario, doesn't it?
<t-bast>
Why does it make the common case less efficient?
<t-bast>
And with what opcodes could you do that split? That needs new opcodes in a soft-fork, right?
<gmaxwell>
it takes more space to serialize two stack elements instead of one.
<t-bast>
(thanks for the answer, sorry it brings more questions)
<t-bast>
Interesting, I don't know how that serialization is done, this surprises me a bit but I understand that this could be an issue. Would it be hard to allow both cases for OP_CHECKSIG? Either a single arg or a split arg?
<gmaxwell>
t-bast: a split or a cat would be sufficient, which were purposefully left out of tapscript even though the application of single show signatures is a known one... either can be added via OP_SUCCESS opcodes.
<gmaxwell>
t-bast: only by introducing a seperate OP_CHECKSIG opcode.
<t-bast>
Ok so that would be added in another soft-fork; the risk being that it's more general to add the whole opcode than to restrict it to splitting the signature into R and s
<gmaxwell>
t-bast: not clear to me that the leaf is sufficient. It needs to be the case the the signer does not reveal R before he knows the one and only message he will sign with it. He can reveal a hash of R, however.
<gmaxwell>
If I know the R you will use and then can grind the message I'll ask you to sign, I can extract signatures which you didn't sign. (particularly if you'll run several instances in parallel with different R and the same pubkey). Hashing R avoids that problem.
<t-bast>
You would reveal the script and R only once you produce the signature (at least in my use-case). So I don't think what I'm doing can be subject to that kind of grinding, but I'll think about it more...
<gmaxwell>
K, maybe in that case it's okay. It's just a surprising vulnerablity that most single show signature attempts have.
<t-bast>
Do you think adding a new OP_CHECKSIG_SPLIT that expects the signature split into two stack arguments would be open to discussion for the Taproot soft-fork?
<t-bast>
Or is it a complete no-go?
<gmaxwell>
I think adding an additional op-code particular for a niche use case would be a total no-go... after all, OP_CAT was omitted and it is utterly trivial and obviously useful (in particular it would let you construct this)
<gmaxwell>
t-bast: how do you avoid the single show being a very limited protection? if someone double spends, they race to collect the coins. (or have their double spend show up in a finney attack)
andytoshi has quit [Read error: Connection reset by peer]
<t-bast>
re "That would make the overwhelmingly common case less efficient, doesn't seem like a good tradeoff", is that still true for Tapscript? As long as the key-path spend is using a normal signature (not split), are we really expecting many uses of OP_CHECKSIG in script-path spends to be the common cases (instead of OP_CHECKSIGADD which could keep a single stack argument).
<t-bast>
True that if someone double-spends, there's a race to
<t-bast>
steal the UTXO. But the original owner has everything to lose, others can bid all the way to the UTXO amount minus something very small to still gain something
<gmaxwell>
t-bast: yes, because key path spending with multiple parties requires multiple rounds of interaction. Even for lightning it sounds like people are planning on using checksigs for latency reasons.
<t-bast>
So it's only an incentive security that the owner never has an incentive to double spend (but depends on the exact use-case though)
<gmaxwell>
t-bast: right but the original owner can spend the full value of the utxo (by making a payment via it) AND attempt to steal it back in a double spend. If you'll only trust them up to (say) the amount of a tx fee then I suppose that would likely be incentive compatible (though still lose in a finney attack)
<t-bast>
That's true, it isn't a protection for all protocols that would leverage it. For our use-case in Lightning I think it works well, but maybe that doesn't reflect how other people would want to use that single-show construction.
<gmaxwell>
well it's come up many times before, and in most cases it seems to be "potentially interesting, but more limited than it seems at first blush"
<gmaxwell>
I don't know enough about the potential lightning usage to say, just wanted to make sure you'd considered finney attacks and races in general.
<t-bast>
In Lightning it would be pretty useful though, because it would mean that you don't need to wait for a confirmation on a channel funding tx -> as soon as it's in the mempool and using this single-show signature, you can start using the channel. That unlocks quite a few interesting features where we'd create channels on-the-fly atomically
<t-bast>
Thanks for all your comments, I'll keep thinking about this and try to justify a potential opcode for this with compelling use-cases
<gmaxwell>
t-bast: if you can just use the channel outright, why woudldn't I open a channel to you, and as soon as it's mempooled pay mayself (via a loop around to another channel) the full value. Then attempt to double spend it?
<gmaxwell>
If I lose the double spend, I lose nothing (except an otherwise useful channel I paid a fee to create).
<gmaxwell>
And if I win, I double my money at your expense.
<t-bast>
Good point, this doesn't work for routing nodes: in my case this is used to open a channel to a non-routing node, so you can't do that. But that's a limited use-case then...
<t-bast>
You would only need to disallow relaying in the direction funder -> fundee though while the tx is unconfirmed
<t-bast>
And then that attack vector disappears, right?
<gmaxwell>
Yes but it's not like you can relay in the other direction, as there are no funds in that direction.
ghost43 has joined #bitcoin-wizards
<t-bast>
In the use-case I'm exploring, the idea is to create a channel on the fly when relaying to a node to which we don't have a channel (or not enough capacity)
<t-bast>
That means that we would create the channel with some funds on the fundee's side
<t-bast>
And while the channel is unconfirmed, the fundee can still receive payments for which he's the recipient
<t-bast>
Which puts more funds on his side that we can then spend
<t-bast>
It's the fundee who would reject payments for which he's not the final recipient until the funding tx confirms
llfourn` has joined #bitcoin-wizards
llfourn` has quit [Remote host closed the connection]
llfourn` has joined #bitcoin-wizards
gde331 has quit []
Chris_Stewart_5 has joined #bitcoin-wizards
kabaum has quit [Ping timeout: 268 seconds]
TheoStorm has joined #bitcoin-wizards
llfourn` has quit [Read error: Connection reset by peer]
spinza has quit [Quit: Coyote finally caught up with me...]
porygon2 has joined #bitcoin-wizards
llfourn has joined #bitcoin-wizards
spinza has joined #bitcoin-wizards
slivera has joined #bitcoin-wizards
llfourn has quit [Ping timeout: 258 seconds]
spinza has quit [Quit: Coyote finally caught up with me...]
slivera has quit [Quit: Leaving]
llfourn has joined #bitcoin-wizards
llfourn has quit [Ping timeout: 246 seconds]
charuto has quit [Ping timeout: 246 seconds]
TheFuzzStone[m] has quit [Ping timeout: 252 seconds]
catcow has quit [Ping timeout: 246 seconds]
kewde[m] has quit [Ping timeout: 240 seconds]
hsngrmpf[m] has quit [Ping timeout: 246 seconds]
azdrianz[m] has quit [Ping timeout: 246 seconds]
tomtau[m] has quit [Ping timeout: 252 seconds]
M7918070_[m] has quit [Ping timeout: 248 seconds]
dl3br[m] has quit [Ping timeout: 250 seconds]
Jeremy_Rand_Talo has quit [Ping timeout: 240 seconds]
spinza has joined #bitcoin-wizards
spinza has quit [Client Quit]
TheoStorm has quit [Quit: Leaving]
spinza has joined #bitcoin-wizards
justanotheruser has quit [Ping timeout: 248 seconds]
llfourn has joined #bitcoin-wizards
llfourn has quit [Ping timeout: 248 seconds]
spinza has quit [Quit: Coyote finally caught up with me...]
Chris_Stewart_5 has quit [Ping timeout: 248 seconds]
spinza has joined #bitcoin-wizards
Chris_Stewart_5 has joined #bitcoin-wizards
Kiminuo has quit [Ping timeout: 268 seconds]
nuncanada has joined #bitcoin-wizards
spinza has quit [Quit: Coyote finally caught up with me...]
justanotheruser has joined #bitcoin-wizards
spinza has joined #bitcoin-wizards
dl3br[m] has joined #bitcoin-wizards
gribble has quit [Read error: Connection reset by peer]
justanotheruser has quit [Read error: Connection reset by peer]
porygon2 has quit []
gribble has joined #bitcoin-wizards
justanotheruser has joined #bitcoin-wizards
esandeen has joined #bitcoin-wizards
TheoStorm has joined #bitcoin-wizards
Kiminuo has joined #bitcoin-wizards
spinza has quit [Quit: Coyote finally caught up with me...]
dl3br[m] has quit [Read error: Connection reset by peer]
llfourn has joined #bitcoin-wizards
llfourn has quit [Ping timeout: 245 seconds]
mdunnio has joined #bitcoin-wizards
justanotheruser has quit [Ping timeout: 248 seconds]
kabaum has joined #bitcoin-wizards
justanotheruser has joined #bitcoin-wizards
laptop500 has quit [Ping timeout: 246 seconds]
spinza has joined #bitcoin-wizards
spinza has quit [Quit: Coyote finally caught up with me...]
t-bast has quit [Quit: Leaving]
pinheadmz has quit [Remote host closed the connection]
pinheadmz has joined #bitcoin-wizards
spinza has joined #bitcoin-wizards
kabaum has quit [Ping timeout: 252 seconds]
spinza has quit [Client Quit]
spinza has joined #bitcoin-wizards
spinza has quit [Quit: Coyote finally caught up with me...]
andytoshi has joined #bitcoin-wizards
andytoshi has joined #bitcoin-wizards
andytoshi has quit [Changing host]
spinza has joined #bitcoin-wizards
jonatack has joined #bitcoin-wizards
justanotheruser has quit [Ping timeout: 246 seconds]
spinza has quit [Quit: Coyote finally caught up with me...]
Chris_Stewart_5 has quit [Ping timeout: 252 seconds]
fiatjaf_ has quit [Quit: ~]
fiatjaf has joined #bitcoin-wizards
fox2p has quit [Ping timeout: 258 seconds]
tomtau[m] has joined #bitcoin-wizards
charuto has joined #bitcoin-wizards
Jeremy_Rand_Talo has joined #bitcoin-wizards
TheFuzzStone[m] has joined #bitcoin-wizards
dl3br[m] has joined #bitcoin-wizards
catcow has joined #bitcoin-wizards
M7918070_[m] has joined #bitcoin-wizards
kewde[m] has joined #bitcoin-wizards
azdrianz[m] has joined #bitcoin-wizards
hsngrmpf[m] has joined #bitcoin-wizards
fox2p has joined #bitcoin-wizards
lapidary has joined #bitcoin-wizards
shesek has quit [Read error: Connection reset by peer]