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 [Remote host closed the connection]
dgenr8 has joined #bitcoin-wizards
tromp has joined #bitcoin-wizards
mdunnio has quit [Ping timeout: 264 seconds]
Toflar has joined #bitcoin-wizards
tromp has quit [Ping timeout: 272 seconds]
schmidty has quit [Ping timeout: 272 seconds]
schmidty has joined #bitcoin-wizards
tromp has joined #bitcoin-wizards
tromp_ has joined #bitcoin-wizards
tromp__ has joined #bitcoin-wizards
tromp has quit [Ping timeout: 272 seconds]
dgenr8 has quit [Ping timeout: 244 seconds]
tromp_ has quit [Ping timeout: 272 seconds]
tromp has joined #bitcoin-wizards
bitdex has quit [Ping timeout: 240 seconds]
tromp__ has quit [Ping timeout: 272 seconds]
bitdex has joined #bitcoin-wizards
tromp has quit [Ping timeout: 272 seconds]
tromp has joined #bitcoin-wizards
dgenr8 has joined #bitcoin-wizards
TheoStorm has joined #bitcoin-wizards
TheoStorm has quit [Remote host closed the connection]
ratbanebo has joined #bitcoin-wizards
PaulTroo_ has joined #bitcoin-wizards
proofofkeags has joined #bitcoin-wizards
dgenr8 has quit [Ping timeout: 260 seconds]
PaulTroo_ has quit [Ping timeout: 260 seconds]
shesek has joined #bitcoin-wizards
shesek has quit [Changing host]
shesek has joined #bitcoin-wizards
dgenr8 has joined #bitcoin-wizards
AaronvanW has quit []
dgenr8 has quit [Ping timeout: 260 seconds]
tromp has quit [Remote host closed the connection]
dgenr8 has joined #bitcoin-wizards
Guyver2_ has joined #bitcoin-wizards
dgenr8 has quit [Ping timeout: 260 seconds]
Guyver2 has quit [Ping timeout: 256 seconds]
justanotheruser has joined #bitcoin-wizards
dgenr8 has joined #bitcoin-wizards
dgenr8 has quit [Ping timeout: 260 seconds]
a5m0 has joined #bitcoin-wizards
tromp has joined #bitcoin-wizards
tromp has quit [Ping timeout: 256 seconds]
tromp has joined #bitcoin-wizards
<treyzania>
Does anyone know if there's been any work on using OP_CTV to make the opendime concept scale better by rolling up the funding of a whole bunch of opendimes into a single utxo?
CryptoDavid has quit [Quit: Connection closed for inactivity]
<BlueMatt>
would probably be more interesting to phrase the question as "how would we design a covanent soft fork to accomplish X" instead of "how would we accomplish X with OP_CTV"
arowser has quit [Remote host closed the connection]
arowser has joined #bitcoin-wizards
<treyzania>
I think the similarities are enough that CTV as-is would work fine. Instead of, say, an exchange wanting to send to a bunch of withdrawal addresses, you have a vendor that wants to deposit into a bunch of funding addresses from the opendimes.
<treyzania>
I'm wondering if anyone has worked out how to make that practical
jeremyrubin has joined #bitcoin-wizards
<BlueMatt>
I really dont think CTV makes sense without a lot of answering of "if we want to do X, how would we design a soft-fork covanent system". So far the only thing I've seen is a lot of "here's how you can do it, in some kinda-effecient way with CTV", not "here's how you'd do it". So I mention the other question format as an exercise both in design and also as an exercise in figuring out what types of covanent designs bitcoin protocol
<BlueMatt>
should be moving towards
<jeremyrubin>
OTOH, CTV does perfectly support what you're asking for with provisioning a huge number of open dimes
<jeremyrubin>
w.r.t. here's how you can do it vs here's how you you do it, it's because CTV is flexible enough to support doing things in more than one way
tromp has quit [Remote host closed the connection]
Toflar has quit []
<jeremyrubin>
it's generally very hard to come up with a single simple primitive that supports a litany of designs. If you wanted bespoke designs per contract then you could probably be more efficient? But often times that's not even the case
<BlueMatt>
jeremyrubin: I dont think I said it was easy, I only said that we should have a list of potential use-cases and compare a few potential designs before we start talking about soft forking :)
wk057 has quit [Read error: Connection reset by peer]
<jeremyrubin>
BlueMatt: you can see https://utxos.org/alternatives/ which compares a decent chunk of alternative designs presented over the years
PaulTroo_ has joined #bitcoin-wizards
<treyzania>
the reason for bringing it up is to avoid creating tons of utxos when funding the opendimes that would just sit there for an extended period of time, or perhaps forever if the opendime is lost/destroyed
<treyzania>
so while batching would make it *cheaper* to fund it wouldn't avoid that problem
<treyzania>
ooooh that looks like an interesting paper
<kanzure>
let us know if you have any questions
proofofkeags has quit [Remote host closed the connection]
<jeremyrubin>
treyzania: yep CTV should mostly fix this issue; the only wrinkle is you need to store the redemption transactions *somewhere* (either on device or off)
<jeremyrubin>
Does opendime have any writeable storage?
PaulTroo_ has quit [Ping timeout: 246 seconds]
wk057 has joined #bitcoin-wizards
<treyzania>
I don't believe it has any arbitrary block storage for the host to use, but it wouldn't be impossible to implement something specific for using CTV
<jeremyrubin>
BlueMatt: Procedurally, I'm not sure if we do that in Bitcoin much TBH (come up with concrete applications and then compare tech alternatives). E.g., was that process followed with Taproot? AFAIK not really... but if there's a resource for that happy to look
<jeremyrubin>
I agree the epistemology is stronger though
<BlueMatt>
jeremyrubin: its pretty different when we're talking about absolutely the biggest change to bitcoin's featureset ever :)
<BlueMatt>
I want Covanents, not covanents :p
<jeremyrubin>
?
<BlueMatt>
I mean like, covanents is a big deal in terms of bitcoin featureset, and unlike segwit and taproot which are relatively straightforward changes which address current shortcomings
<jeremyrubin>
I think schnorr is a bigger deal than CTV
<treyzania>
I want sighash_noinput :)
<BlueMatt>
eh, schnorr isnt bigger than covanents. ctv may be cut down covanents, but if we're gonna do covanents, lets do real, feature-full covanents.
<jeremyrubin>
I don't agree
<sipa>
what does that mean?
<jeremyrubin>
If you want that then just focus on simplicity
<jeremyrubin>
sipa: who are you responding to?
<sipa>
there is no limit to what "feature full" can mean in terms of covenants
<BlueMatt>
sure, but doesnt mean you target a deliberately limited version
<BlueMatt>
I dont feel like there's really been that much exploration of how to do simple but more powerful covanents
<jeremyrubin>
Actually Bram has a solid explanation of why you want CTV even if you had more complex ones
<jeremyrubin>
let me dig it up :)
<sipa>
BlueMatt: do you have any specific things in mind?
<BlueMatt>
ie the space of possible covanent soft forks is relatively unexplored, and should probably be explored so we have a longer-term vision in mind before committing to a direction
<sipa>
BlueMatt: i agree with that in general
<BlueMatt>
sipa: there's a few use-cases for covanents that i think are pretty critical
<sipa>
but it's also kind of hard to just say "more exploration is needed", without offering specific things that are unexplored
<BlueMatt>
but, its totally possible we explore a bunch and then end up loving ctv :)
<jeremyrubin>
BlueMatt: do you want Sapio access to play with the ecosystem I'm trying to get together?
<jeremyrubin>
It's still gross code so not public yet, but happy to add anyone here
<BlueMatt>
yea, true. I definitely mentioned a few previously in discussions with jeremyrubin. I think he came up with some ideas for how to do it but they required longer-term secondary soft forks
<BlueMatt>
ie long-term vision :)
<sipa>
BlueMatt: i'm personally rather hesitant about covenants features in general, even very limited ones - but i fear that's not a battle i will win (and not even sure i want to; the use cases are very appealing)
<jeremyrubin>
Yes the long term is there; CTV is actually designed to accrue features with the addition of e.g. OP_CAT
<jeremyrubin>
(or shastream)
<sipa>
but if we agree that scripts-that-can-introspect-their-own-semantics are a good idea, i don't really see the problem with doing something simple and iterating either
<BlueMatt>
sipa: yea....i dunno, i kinda gave up on that after a while. and the use-cases seem to be to be pretty critical from a practical scalability perspective
<sipa>
especially given that the potential design space is pretty much unlimited, you need to pick something to focus on first
<BlueMatt>
jeremyrubin: right, but thats a somewhat awkward design. what if we wanted to start from scratch with a set of features to capture the set of features we want instead of making it work with ctv? :p
<jeremyrubin>
BlueMatt: from what I recall when we did the walkthrough on payment pools in January we ended back at needing CTV again ;)
<BlueMatt>
sipa: yep, totally. i just worry that without some level of competing designs or at least well-described long-term vision for the sets of things we want, we're going down a path we'll have to change from at some point
<sipa>
BlueMatt: that's certainly a useful thing to consider
<sipa>
but again, being specific would be very helpful
<BlueMatt>
jeremyrubin: huh? no, i think we ended up with you coming up with a way of doing it with ctv that i was kinda ok with, but wasnt well specified and required a second soft fork which felt awkward
scf-1 has joined #bitcoin-wizards
<BlueMatt>
yep, agreed sipa
<BlueMatt>
definitely not fair to just say "keep researching" as an objection
<jeremyrubin>
BlueMatt: your design required like 3 new other opcodes anyways though, so it didn't seem weird
<jeremyrubin>
(v.s. CTV-native payment pool design which just requires CTV)
<BlueMatt>
hmm, I dont believe it requried 3 new opcodes which were directly covanents. iirc it was more of a few general purpose things (like bit sets or hash trees), plus a simple covanents thing which was a bit more general than ctv
<treyzania>
is there a writeup on that design somewhere?
<jeremyrubin>
The gleb/riard design is basically what Matt and I discussed, it's on the mailing list
<jeremyrubin>
I responded with the CTV-native design
<treyzania>
will check up on that, thanks
<jeremyrubin>
Anyways, the way CTV is set up there's a version flag so you can add new hashtypes and covenants later on down the line... I don't think it's awful if we end up supporting > 1 covenant-template type in the future. And a more general purpose thing will have a different set of use cases than a simpler thing (see bram's thread).
<sipa>
fwiw, one generic concern i had with covenant like structures, is that it breaks "generic coinjoinability" i.e. the ability for any two arbitrary independently created outputs to be spendable together in one transaction (which i feel breaking would be like a "being able to send back to input address" kind of yuck)... it turns out, bitcoin already has that, since OP_CLTV
<sipa>
which was hugely surprising to me
<sipa>
if you have an output that needs a blockheight CLTV, and another output that needs a timelock CLTV, they cannot be spent in the same transaction
<jeremyrubin>
I thought cltv has > semantics?
* BlueMatt
-> dealing with family members in hospital and quarantine rules
<BlueMatt>
see y'all later
<sipa>
jeremyrubin: orthongonal
<jeremyrubin>
BlueMatt: good luck, hope fam is OK
<BlueMatt>
yea, alright, just, you know, dont really want to spend a weekend in the hospital right now
<sipa>
BlueMatt: be safe, and wish them well
<sipa>
jeremyrubin: there is only one nLockTime field in a transaction, which cannot be simultaneously a height and a timestamp
<jeremyrubin>
Oh right, yes.
<jeremyrubin>
I have run up against this before
<jeremyrubin>
it's also annoying that within a single script you can't do both
<sipa>
there could be a "per-input nlocktime" annex
<sipa>
which would solve that
<jeremyrubin>
to make powswap.com work you need to do something with either relative time and absolute height or vice versa
<jeremyrubin>
but you can't do both relative at the same time which is annoying
<jeremyrubin>
ideally we'd have any number of timelocks independently allowed
<jeremyrubin>
The hack for seqeuence and nLockTime is really an artifact for old miners to handle it correctly right
<sipa>
yeah, i think this is a pretty minor thing in practice- you pick your stuff to be either height based or time based, and you can't mix things...
<sipa>
is it?
<sipa>
i don't actually know
<jeremyrubin>
I think so!
<jeremyrubin>
It was rules to be compatible with mempool policy
<sipa>
it sounds plausible
<jeremyrubin>
so that evictions and stuff during reorg works correctly
<sipa>
i don't think so
<jeremyrubin>
I think it's also something about picking an absolute value v.s. just comitting
<sipa>
time-based nLockTime was added in 0.1.6
<sipa>
super early
<jeremyrubin>
ah ok -- the policies may have been in consensus already
<sipa>
and in 0.1.5, it wasn't even consensus
<jeremyrubin>
my point is more that it was to reuse the mechanism already there
<jeremyrubin>
even though there is no hard reason to
<jeremyrubin>
other than not writing new mempool code
<sipa>
i suspect it was more a matter of not needing to add a new field
<jeremyrubin>
You wouldn't need to add a new field to the TX though for CLTV which doesn't check the nlocktime
<jeremyrubin>
CLTV could read the block height during validation
<jeremyrubin>
from the context of tx execution instead of the context of the tx's set nLockTime
<sipa>
CLTV was 5.5 years after the introduction of consensus-critical height-or-time nLockTime
<sipa>
oh, lol, no
<sipa>
if you mean that OP_CLTV could have been reading block height directly, you're right, that would indeed not have that problem... but that would be ridiculous
tromp has joined #bitcoin-wizards
<jeremyrubin>
that is exactly what I mean
tromp has quit [Remote host closed the connection]
<sipa>
the right way to do it would have been to add a per-input nLockTime (or even split height/time) field, and then make OP_CTLV assert on that
tromp has joined #bitcoin-wizards
<jeremyrubin>
Sure, there's an argument in favor of that w.r.t. signing
<jeremyrubin>
so that your later signers can set those values as desired
<jeremyrubin>
anyways this is a tangent :)
<jeremyrubin>
CTV does kinda make an additional break of this property. How critical is that though?
<sipa>
i don't know
<sipa>
it's one of the reasons i don't like covenants :)
<jeremyrubin>
This is similarly broken if I sign an anyonecanpay and you sign an anyonecanpay with diff outputs
<jeremyrubin>
we can't collapse that tx into one
<jeremyrubin>
I agree with full tx introspection it's a *lot* worse
<jeremyrubin>
That's why CTV as is does no introspection of the tx, just a static commitment
<jeremyrubin>
I agree that's way riskier
<jeremyrubin>
I think it also points to a flaw with BlueMatt's epistemological proposal
<jeremyrubin>
The right way to do Bitcoin development may be to find a primitive you think is *safe* and then figure out if you can do good applications with it too.
<sipa>
eh, i don't agree with that
<jeremyrubin>
V.s. finding something that does a handful of apps you like and then figure out if it's safe
<jeremyrubin>
I also do want to make clear (for anyone reading along here) that CTV was not "technology in search of problem", I came up with it originally specifically to make batched payments more efficient and several other use cases...
<jeremyrubin>
so CTV itself wouldn't even pass the prior test i mentioned
alferz has quit [Ping timeout: 240 seconds]
<jeremyrubin>
anyways, if anyone has a list of critical and neccessary covenant applications share them I guess?
tromp has quit [Remote host closed the connection]
tromp has joined #bitcoin-wizards
<jeremyrubin>
So far I can think of things that I'd want to see:
<jeremyrubin>
6) On chain make/take contracts with either fixed or dynamic participant set (e.g., open an oracle option contract and anyone can take the other side if they pay premium)