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
TheoStorm has quit [Quit: Leaving]
harrymm_ has quit [Remote host closed the connection]
leishman has quit [Remote host closed the connection]
harrymm has joined #bitcoin-wizards
harrymm has quit [Ping timeout: 240 seconds]
harrymm has joined #bitcoin-wizards
nuncanada has quit [Ping timeout: 245 seconds]
schmidty has quit [Read error: Connection reset by peer]
AaronvanW has quit []
schmidty has joined #bitcoin-wizards
schmidty is now known as Guest76245
nuncanada has joined #bitcoin-wizards
Guest76245 has quit [Ping timeout: 252 seconds]
Chris_Stewart_5 has quit [Ping timeout: 252 seconds]
<rusty>
Hmm, I wonder if some of the old ideas on 'transaction timeout' should be reconsidered in a taproot/graftroot world? It would make claiming an HTLC more efficient, for example: we currently 'terminate' the HTLC output by spending it, but if it timed itself out we'd avoid that extra transaction.
Chris_Stewart_5 has quit [Ping timeout: 240 seconds]
valwal has quit [Ping timeout: 240 seconds]
dougsland has quit [Ping timeout: 252 seconds]
<Varunram>
rusty: there might be potential for miners to misuse that? say someone sends 1btc and the miner doesn't allow the tx causing it to timeout
<Varunram>
doesn't mine*
<rusty>
Varunram: sure. That's exactly the same scenario as now, but we use a separate tx to time it out.
<Varunram>
hm, I think that makes sense
<rusty>
The counter-argument is generally that it creates another mechanism by which txs can become invalid, meaning the mempool has to be re-evaluated every new block (worst case). Usually you can just kick things out of the mempool if their input are spent.
<RubenSomsen>
rusty: it probably complicates reorgs too
<rusty>
RubenSomsen: yes, that's a subset of the same problem I think.
<sipa>
rusty: how does taproot change this?
<rusty>
sipa: Not fundamental. One argument against transaction timeouts was the "vendors don't expect payments to vanish in a reorg if parties are honest". If our thinking is moving to a "normal case + unusual cases" model which reflects smart contracts becoming a significant case, this would be consistent with that line of though, I think.
<rusty>
ie. it's not insane to do things in bitcoin script which are really dumb in the normal payment case.
<rusty>
My initial thinking was driven by the "swap lightning tx to onchain funds" case. Right now, that's efficient if you trust the party (lightning tx in, payment onchain out). If you want it trustless, the onchain payment out has to be conditional on some preimage + a timeout; the payer would spend it to complete the swap.
<rusty>
For normal lightning, it's marginal: we aim to never put HTLC txs on the blockchain, so having it slightly more inefficient is not a big deal.
_whitelogger has joined #bitcoin-wizards
<sipa>
rusty: conceptually that makes sense... if transactions are regularly going to have presigned, unbroadcadt alternatives anyway, then the old mantra of "without an attack, every valid transaction can be included in the chain" does no longer hold
<sipa>
rusty: but there are other concerns like how should wallets treat such time-encoumbered funds
<sipa>
that in particular may be forcing some complexity on otherwise unaffected participants
<rusty>
sipa: yes, I agree. I'm...not sure what the answer is there. I'm floating this now in the hope that someone remembers it if it becomes sane to optimize for in future.
<sipa>
also, it's nontrivial to not make it cause constant reevaluations of the mempool
<sipa>
in particular, making scripts observe time is a non-starter for that reason
<maaku>
rusty: the other thing not mentioned here is that you'd have to make a tx using expiry visible, and make those tx's outputs subject to maturation
Chris_Stewart_5 has joined #bitcoin-wizards
<maaku>
otherwise you introduce a rather significant fungibility risk
<sipa>
but you can in theory have something where soke opcodes pushes an 'assertion on time' that must hold independent of script validity
<sipa>
so your script still returns unamboguous and non-context dependent true or false, but also returns a max valid timestamp in a way
<sipa>
which the mempool can reason about (e.g. depending on an unconfirmed tx with expiration time causes the dependency to inherit it)
<rusty>
sipa: hmm, that works in a taproot/graftroot/MAST world I think; eg. OP_MUSTBEBEFOREHEIGHT must be the first opcode in script, next must be a push (or some such hack). That's pretty icky, of course.
<sipa>
rusty: no reason why it needs to be the first opcode
<rusty>
sipa: that's how I read "non-context dependent": not hiding within some branch?
<sipa>
(not saying this is a good idea; but it would avoid having scripts observe the time)
<sipa>
rusty: i just literally mean the script has no way to observe time
<rusty>
Well, I'm basically using the first part of the script to extend the TxIn here to have (conceptually) more fields. I'm not saying it's a good idea either!
<sipa>
and there is an opcode "MAXHEIGHT" which always succeeds, but makes the script evaluation return not just True but (True, timeval)
<sipa>
so the script is only ever evaluated once
<sipa>
ad then the mempool just remembers its maxtime
<sipa>
but the opcode can occur anywhere, or in ifs, or not at all
<sipa>
and it only has an effect ehen executed
<sipa>
afk!
<rusty>
Hmm, it can't always succeed can it? Well, I guess maybe the script eval "succeeds" but the tx fails. And script eval must take the minimum of multiple MAXHEIGHT. Yech...
Chris_Stewart_5 has quit [Ping timeout: 252 seconds]
Krellan has quit [Ping timeout: 250 seconds]
Krellan has joined #bitcoin-wizards
gertjaap has joined #bitcoin-wizards
kallewoof has quit [Ping timeout: 264 seconds]
kallewoof has joined #bitcoin-wizards
rusty has quit [Ping timeout: 246 seconds]
TheoStorm has joined #bitcoin-wizards
Krellan has quit [Read error: Connection reset by peer]
Krellan has joined #bitcoin-wizards
CheckDavid has joined #bitcoin-wizards
Nightw0lf has joined #bitcoin-wizards
nickler_ has joined #bitcoin-wizards
murchandamus1 has joined #bitcoin-wizards
nickler has quit [Ping timeout: 268 seconds]
Nightwolf has quit [Remote host closed the connection]
murchandamus has quit [Ping timeout: 268 seconds]
CheckDavid has joined #bitcoin-wizards
CheckDavid has quit [Changing host]
laurentmt has joined #bitcoin-wizards
kallewoof has quit [Ping timeout: 240 seconds]
kallewoof has joined #bitcoin-wizards
laurentmt has quit [Quit: laurentmt]
AaronvanW has joined #bitcoin-wizards
wildermind has joined #bitcoin-wizards
TheoStorm has quit [Remote host closed the connection]
JackH has quit [Quit: Leaving]
rusty has joined #bitcoin-wizards
TheoStorm has joined #bitcoin-wizards
belcher_ has joined #bitcoin-wizards
Emcy has quit [Ping timeout: 240 seconds]
Emcy has joined #bitcoin-wizards
SopaXorzTaker has joined #bitcoin-wizards
kallewoof has quit [Read error: Connection reset by peer]
kallewoof has joined #bitcoin-wizards
elichai2 has joined #bitcoin-wizards
sipa has quit [Remote host closed the connection]
sipa has joined #bitcoin-wizards
RubenSomsen has quit [Quit: Connection closed for inactivity]
dougsland has joined #bitcoin-wizards
IGHOR has quit [Quit: No Ping reply in 180 seconds.]
IGHOR has joined #bitcoin-wizards
rusty has quit [Read error: Connection reset by peer]
dougsland has quit [Ping timeout: 252 seconds]
kallewoof has quit [Read error: Connection reset by peer]
dvknv has joined #bitcoin-wizards
kallewoof has joined #bitcoin-wizards
dvknv_ has quit [Ping timeout: 240 seconds]
ZmnSCPxj has joined #bitcoin-wizards
<ZmnSCPxj>
Good morning Rusty, this effectively creates a hidden field of the transaction that is initially empty, but gets filled upon script execution. transaction validation would then notice thise new field
<ZmnSCPxj>
So the purpose of the OP_MUSTBEBEFOREHEIGHT operation would be simply to load this field with a value
<ZmnSCPxj>
script execution would always succeed for OP_MUSTBEBEFOREHEIGHT
<ZmnSCPxj>
then a subsequent check after script execution, would check the mustbebeforeheight field
ZmnSCPxj has quit [Client Quit]
brianhoffman has left #bitcoin-wizards [#bitcoin-wizards]
ZmnSCPxj has joined #bitcoin-wizards
<ZmnSCPxj>
Or alternately, mustbebeforeheight could become a "real" field of the transaction (like nLockTime), and OP_MUSTBEBEFOREHEIGHT would verify if that field contains the correct value
<ZmnSCPxj>
and this field would not be part of the txid and would not be given to old nodes that do not understand this field
Guyver2 has joined #bitcoin-wizards
<ZmnSCPxj>
but that would also bring in SegWit-like complexity, of requiring a new signature algorithm, which may be too heavyweight for your purposes
ZmnSCPxj has quit [Client Quit]
belcher_ has quit [Read error: Connection reset by peer]
belcher_ has joined #bitcoin-wizards
belcher_ has quit [Remote host closed the connection]