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
mathepauker has quit []
tromp has quit [Ping timeout: 258 seconds]
obruT1 has joined #bitcoin-wizards
tromp has joined #bitcoin-wizards
tromp has quit [Ping timeout: 258 seconds]
pinheadmz has quit [Quit: pinheadmz]
<Madars>
another option would be using a non-succinct proof system (e.g. Bulletproofs) which heuristically would let you transmit just a PRF seed
<Madars>
so proofs become larger but you save on transmitting the proving key (and for not many sudokus ends up being a net win in communication complexity)
<Madars>
another immediate improvement would be swapping out SHA256 for a different hash function (e.g. Blake2 used in Zcash has a cheaper circuit than SHA256)
mryandao_ is now known as mryandao
<Madars>
(whoops, the latter would not be Bitcoin-compatible as you can't do Blake2 inside a scriptPubKey)
ccdle12 has quit [Remote host closed the connection]
AaronvanW has quit [Ping timeout: 258 seconds]
tromp has joined #bitcoin-wizards
tromp has quit [Ping timeout: 250 seconds]
Belkaar has quit [Ping timeout: 246 seconds]
Belkaar has joined #bitcoin-wizards
Belkaar has joined #bitcoin-wizards
Belkaar has quit [Changing host]
obruT1 has quit []
Lord1 has joined #bitcoin-wizards
tromp has joined #bitcoin-wizards
tromp has quit [Ping timeout: 258 seconds]
instagibbs has quit [Ping timeout: 246 seconds]
pinheadmz has joined #bitcoin-wizards
spinza has quit [Quit: Coyote finally caught up with me...]
brianhoffman_ has joined #bitcoin-wizards
brianhoffman has quit [Ping timeout: 244 seconds]
brianhoffman_ is now known as brianhoffman
ccdle12 has joined #bitcoin-wizards
spinza has joined #bitcoin-wizards
pinheadmz has quit [Quit: pinheadmz]
pinheadmz has joined #bitcoin-wizards
tromp has joined #bitcoin-wizards
Lord1 has quit []
tromp has quit [Ping timeout: 258 seconds]
Sho_1 has joined #bitcoin-wizards
Dean_Guss has joined #bitcoin-wizards
antanst863 has joined #bitcoin-wizards
antanst86 has quit [Ping timeout: 255 seconds]
achow101 has quit [Ping timeout: 246 seconds]
achow101 has joined #bitcoin-wizards
pinheadmz has quit [Quit: pinheadmz]
mryandao has quit [Remote host closed the connection]
mryandao has joined #bitcoin-wizards
ccdle12 has quit [Remote host closed the connection]
<gmaxwell>
I saw a brief presentation by jeremyrubin tonight that I thought was quite interesting. In it he described a scheme for high volume payment commitment using a very simple covenant. To give a toy version of the most critical part of the idea: Alice wants to pay Bob[1..500], now. But it would be costly to make a 500 output txn right now. The bob's don't trust alice much so they want
<gmaxwell>
confirmation now, but they don't actually need the funds anytime soon. So alice constructs a taproot payment with N of N of the 500 bobs OR a script which has a checkhashofoutputs that allows spending via a transaction that pays the first 10 bobs and then rolls the rest to a n-of-n of the remaining 490 plus a script with a checkoutputhash for the next 10 and ... [recursive]
<gmaxwell>
The construction isn't limited to a simple purely serial unrolling, though the serial one is simplest to think about.
<gmaxwell>
This is distinct from a chain of unconfirmed transactions, or just having alice pay the bobs slowly over time-- because the payment is guarenteed.
whitez00 has joined #bitcoin-wizards
<gmaxwell>
I think it should be called CITM (check is in the mail). :P
<gmaxwell>
in theory you could structure the potential payout ordering however you liked... e.g. have an option to pay all at once (if there is room), or halves (with each half carrying forward the other half), and so on.
<gmaxwell>
If some subgroup decides that they want to settle their funds differently (say because the ultimate outputs for them were lightning channels and they've moved funds around), then they're free to N of N sign in order to cut-through the payments.
<gmaxwell>
If a user of this were something like a bitcoin fountain paying loads of people tiny amounts of bitcoin that wouldn't be worth creating outputs for ... then they could, and the outputs would never be created unless it was worth doing so, but would be created if they were. And, again, participants could instead decide to collaborate to do something else like hand their funds over to a charity--
<gmaxwell>
rather than get to their final output.
<gmaxwell>
Jeremyrubin made the case that this would be an effective way of keeping a strong backlog of transactions. Because of course you could give the tree fragments to miners or whoevever to use to fill blocks whenever there was room.
<gmaxwell>
You could also imagine using this to create something of a kind of adhoc multiparty accumulator.
ccdle12 has joined #bitcoin-wizards
<gmaxwell>
Like N parties jointly create an output which is N of N or alternatively a covenant to return their funds.
<gmaxwell>
Then someone wants to make a payment outside of the collective, so they author a transaction that makes a payment out, and updates the refunds to reflect the new state, then get the N of N to sign.
<gmaxwell>
if someone goes offline, then no ones funds are lost.
kinlo has quit [Read error: Connection reset by peer]
<gmaxwell>
with the right structure you could just allow anyone party to backout at any time while leaving the other parties alone.
_whitelogger has joined #bitcoin-wizards
setpill has joined #bitcoin-wizards
kinlo has joined #bitcoin-wizards
Sho_1 has quit []
DeanWeen has joined #bitcoin-wizards
fletom has quit [Ping timeout: 268 seconds]
Dean_Guss has quit [Ping timeout: 256 seconds]
fletom has joined #bitcoin-wizards
geekosaur1 has joined #bitcoin-wizards
<waxwing>
what is 'checkhashofoutputs'? is that a proposed covenant op code? i can't find a reference to it.
<waxwing>
gmaxwell, ^
<gmaxwell>
Right. it's just an opcode that takes a sha256 as an argument and makes sure the txn's outputs matches it exactly. (or at least thats sufficient for these purposes)
<gmaxwell>
waxwing: sipa seemed to be saying that Jeremyrubin made some post about it somewhere recently, but I haven't seen it.
<waxwing>
ok. sounds interesting, i'll try to understand it, but it's kind of a given that with that functionality we can do some pretty powerful things :)
<gmaxwell>
but in any case, feel free to replace it in your mind with anything that just lets the script mandate the set of outputs.
* waxwing
nods
<gmaxwell>
Part of the observation though is that you get a bunch of really intresting results from basically the most limited form of output covenant you can imagine.
<waxwing>
actually i was recently trying to dream up various off-chain off-line payment ideas, none of them really work, but similar to the above ^ .. it certainly helps having taproot! since you can just handwave 100 conditional branches if you need it for some reason :)
<gmaxwell>
what do you think of my payment pool example? that wasn't (directly) in Jeremyrubin's presentation. (he was more concerned with the 'exchange or mining pool pays lots of people at once' sort of model.
<gmaxwell>
Do you get it? I think it creates a kind of rolling coinjoin that people can enter and exit from at any time.
<waxwing>
well the more i read it, the more similar it is to what i was attempting to concoct, except, i couldn't find a way to make it work even with a lot of restrictions (like presigning a combinatorially huge bunch of stuff), because the inability to completely fix forward paths stuffs everything up when you take account of collusion in groups.
<waxwing>
obv my point being with some covenant op code you solve those problems
<gmaxwell>
right. I think something similar might be workable with grafts, without the covenant.
<waxwing>
gmaxwell, not sure i exactly got the "You could also imagine..." part ; "N of N or alternatively a covenant to return"; so it means there's the canonical "we all agree" path to distribute, and the alternative is a script with covenants?
<waxwing>
meaning you can enforce updates basically?
<gmaxwell>
by transacting.
<gmaxwell>
so not an infinite txn volume thing, if you were starting to think that.
<waxwing>
indeed that restriction is something i was pondering in my own musings ..
<gmaxwell>
waxwing: {we all agree} OR {the resulting tx has one of these EXACT sets of outputs}
<waxwing>
i think the technical term is 'novation' right, seems this kind of system doesn't have that.
<gmaxwell>
and the sets are ones that pay out some people and roll forward the obligation to pay out the others.
<gmaxwell>
waxwing: you can get a novation here via the {we all agree} path.
<gmaxwell>
Lets imagine, you, me, and satoshi, each pay in 1BTC to a taproot output the root is {3 of 3 YMS} and there is a MAST under it, with three possible alternative scripts
<waxwing>
oh; you have to set everything in advance
<gmaxwell>
One of them fixes a set of outputs paying satoshi his 1 BTC, and paying Y+M 2 of 2 with a MAST under it...
<gmaxwell>
another paying you, 2 BTC to M+S, another paying me, and 2 BTC to Y+S... and perhaps for good measure a fourth that just pays three outputs.
<gmaxwell>
So at any time, any of us can spend the output and kick someone out (including ourselves).
<gmaxwell>
so we all have good access to our funds.
<gmaxwell>
ALTERNATIVELY at any time the three of us can collaborate to make a payment and set new terms.
<gmaxwell>
For example, I could decide to pay alice 0.5... then we can make a transaction that pays alice 0.5 btc and pays 2.5 BTC into a script like the original one. Except burried in the MAST, my outputs now have value 2.5.
<gmaxwell>
(because I paid alice)
<gmaxwell>
now, interestingly (and this Jeremyrubin did anticipate), if the 'final' outputs we're creating are a bunch of pairwise lightning channels between us. Then we're able to make lightning payments between us, knowing that if we need to close we can just take the txn to the chain. (*** handwaving past some malleability issues)
<waxwing>
how does this differ functionally from a multiparty lightning channel, i'm wondering.
<gmaxwell>
I think multiparty lightning is essentially just one extreme of the operation of this general idea.
<gmaxwell>
in any case back to my join-pool sort of use...
<gmaxwell>
I think this could easily also handle new parties entering the pool, they just join in more inputs, and you go from a 3 of 3 to a 4 of 4...
<gmaxwell>
I don't see any great way though to keep the pool balances private among the participants, except via MPC.
<gmaxwell>
though at least theoretically you could do it with MPC so you only knew your balance and not everyone elses.
spinza has quit [Quit: Coyote finally caught up with me...]
<waxwing>
sorry my computer froze, yeah keeping balances private sounds hard, i hadn't thought of the privacy application but it's promising perhaps; i was more interested in making more offline or even non-interactive second layer stuff, which is hard to impossible, except, with covenants, less so.
<gmaxwell>
I think that if the end states of this thing are lightning channels, then you get offline txn... but essentially with the same limits and tradeoffs as lightning except you amortize the channel opening costs.
<gmaxwell>
It's not clear to me if you can do the multichannel case AND manage a safe global rebalance. maybe it seems tricky.
<gmaxwell>
N people coinjoin in to create up to N^2 channels between each other (hidden under the taproot), with whatever balance distribution they like.
<waxwing>
you mean 'with lightning channel endpoints you get offline payments' to outside parties right; it already gives you offline payment to the participants.
<gmaxwell>
Only a limited form of offline to outside, I think.
<gmaxwell>
Generally you have the problem of what keeps an inside party from paying the same funds to two different outside parties?
<gmaxwell>
you need to update the state to prevent that.
mikerah has quit [Remote host closed the connection]
whitez00 has quit [Ping timeout: 246 seconds]
whitez00 has joined #bitcoin-wizards
roconnor has joined #bitcoin-wizards
ccdle12 has joined #bitcoin-wizards
DougieBot5000_ is now known as DougieBot5000
son0p_ has quit [Read error: Connection reset by peer]
wildermind has quit [Quit: Connection closed for inactivity]
ccdle12 has quit [Ping timeout: 244 seconds]
ccdle12 has joined #bitcoin-wizards
ccdle12 has quit [Ping timeout: 268 seconds]
enemabandit has quit [Ping timeout: 244 seconds]
ccdle12 has joined #bitcoin-wizards
so has joined #bitcoin-wizards
jaromil has joined #bitcoin-wizards
jaromil has joined #bitcoin-wizards
tromp has quit [Remote host closed the connection]
tromp has joined #bitcoin-wizards
whitez00 has quit [Ping timeout: 258 seconds]
Newyorkadam has quit [Quit: Newyorkadam]
Newyorkadam has joined #bitcoin-wizards
Newyorkadam has quit [Client Quit]
fletom has quit [Ping timeout: 258 seconds]
ccdle12 has quit [Ping timeout: 258 seconds]
roconnor has quit [Ping timeout: 258 seconds]
ccdle12 has joined #bitcoin-wizards
antanst863387431 has joined #bitcoin-wizards
antanst86338743 has quit [Ping timeout: 268 seconds]
dlb76_ is now known as dlb76
dlb76 has quit [Changing host]
dlb76 has joined #bitcoin-wizards
michaelfolkson has joined #bitcoin-wizards
ccdle12 has quit [Remote host closed the connection]
ccdle12 has joined #bitcoin-wizards
Newyorkadam has joined #bitcoin-wizards
Newyorkadam has quit [Ping timeout: 252 seconds]
michaelfolkson has quit [Quit: Sleep mode]
michaelfolkson has joined #bitcoin-wizards
ccdle12 has quit [Remote host closed the connection]
<jeremyrubin>
gmaxwell: I posted it to the bitcoin-dev mailing list -- maybe it still hasn't gone thru
gingerling has quit []
<jeremyrubin>
I'm not particularly attached to the name COSHV, I just thought it was a boring name that literally expressed what the opcode was doing, because there might be alternative constructions using primitives which do things differently and the OP name lets us distinguish such approaches
<jeremyrubin>
CPDU was the term I was using for a little bit for the technique: Certified Post-Dated UTXO
<jeremyrubin>
Some other techniques that could be used to make it more flexible include: and operation which commits to the hash of a single output by index (rather that all of them), an opcode that check-set-verifies an atomic::test_flag per transaction (so only allowed one input that has covenants and arbitrary others), an opcode that does PAYMENT_ADD which adds output requirements to a stack of outputs (solving the half-spend problem),
<jeremyrubin>
and a few others
kanzure_ is now known as kanzure
<jeremyrubin>
Notably, this approach technically does not require any new stuff post segwit malleability fixes. As noted in https://github.com/jeremyrubin/lazuli, it's possible to construct a bastardized ECDSA MPC protocol to pre-sign the branches going down and make n-of-n covenants. However such approach is fundamentally limited because it requires interaction to set up a spend