Buck O Perley [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2022-04-20 to 2022-09-12
💬 Posted a total of 3 messages
📚 Participated in the following categories: bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 23:13:22

- reply

📅 Original date posted:2022-09-11
📝 Original message:Hi Antoine,
First just wanted to thank you for taking the initiative to
put this together. I think that as the community and
ecosystem continue to grow, it's going to be an important
part of the process to have groups like this develop. Hopefully
they allow us to resist the "Tyranny of Structurelessness" without
resorting to formalized governance processes and systems.
> Defining a communication channel is still an open question: IRC, Slack,
Discord, Discourse, ...
I would vote against Slack. IRC is probably the best but maybe too
high a barrier to entry? Publishing logs at least would counter
concerns of it being exclusive. Maybe discord as an alternative.
> About the starting point for regular meetings, I think the good timing is
somewhere in November, after the upcoming cycle of Bitcoin conferences,
+1
> softfork activation discussions will be considered as
off-topic and discouraged. This is first and foremost a long-term R&D
effort.
I understand the reason for this but I do have some concerns that
it's not as off-topic as most of us would like. It shouldn't
be a priority but how any of these primitives end up getting activated
is part of the proposal itself in my opinion.
I think it also became clear in some of the discussions over the past
~year that maybe there were more concerns than people realized about
even the taproot activation process, whether the method used or if it
was done too quickly. An example of where there might be
some intersection with the WG as proposed is the question of how much
research, security audits, etc. are "enough" before it should be
considered for activation?
Maybe as a way to keep these topics separate, it would make sense
for activation to have its own WG. As norms develop around this one,
they could inform creating a separate space focused on forwarding
research and discussion around how to introduce upgrades to bitcoin.
In general it would be nice to have multiple of these groups
happening at once, and finding a way that they can operate separate
from centralized companies. To my mind, there's no good reason why
a supposedly decentralized protocol should have to be focusing on only
one set of protocol advancements at a time. The linear way that
discussions post-Taproot activation took shape ("What do you think the
next bitcoin softfork should be?") is a sign of weakness in my opinion.
Definitely a big red flag that we should be concerned with.
Couple other comments from the proposal/repo:
* it seems like there might be some opportunities to work with
bipbounty.org which grew out of the organic bounty donations that
were made towards finding CTV vulnerabilities. For example,
if the group develops specific, achievable research goals (building
out use cases, researching vulnerabilities or limitations, etc.),
bipbounty.org could help support these efforts in a more decentralized
way by diversifying funding.
* Any thoughts on starting to commit to an in-person meetup to happen
~6 months - 1 year after the start of the regular online meetings?
That should be plenty of time for people to plan and formalize
a location and it seems like other IRL dev meetups have been
very productive in terms of knowledge sharing and setting priorities.
An in-person meetup would give a nice goal to work towards and a way
to measure progress.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: publickey - buck.perley at protonmail.com - 0xC64EEB00.asc
Type: application/pgp-keys
Size: 608 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220912/600d520a/attachment.bin>

2023-06-07 23:08:17

- reply

📅 Original date posted:2022-04-25
📝 Original message:Just a couple of comments re-CTV vault security concerns.
1. One way to assuage the concern of the hot wallet vulnerability
is pre-program the spends such that the hot wallet can only
spend a certain amount from the hot wallet spend and the rest would
kind of be "recursive" in that it would be sent back to a
new instantiation of the CTV vault. I believe kanzure's vaults
does this w/ the non-covenant version using pre-signed transactions
(https://github.com/kanzure/python-vaults). While this doesn't
prevent the theft it caps off the total risk. I would argue that
this is strictly better than a multisig because you can also use
multisig as you normally would if you want but you have the option
if you think your hot key is secure to use that spending path.
You also get the nice benefit of learning about compromised
keys without having to risk all funds associated with that key.
2. As to how to improve UX for CTV with other proposals, I think
you get a lot of benefits when using with taproot because you can
use CTV in tapleaves to secure specific spend conditions, but can
always fall back to other off-ramps (e.g. a musig key path spend or
other script path conditions). Of course you can do this without
taproot but taproot makes this more space efficient. This idea has
been used to some effect in some recent exploration of how CTV can
help improve UX around DLCs. You could even do this to help with
the problems of not sending the right amount such that you have a
really really cold key or set of keys for example such that if you
have UTXOs that have values that can't be spent with the given CTV
commitment, then you just use that other branch.
- Buck
------- Original Message -------
> Date: Sun, 24 Apr 2022 18:03:52 -0500
> From: Billy Tetrud billy.tetrud at gmail.com
>
> To: "Russell O'Connor" roconnor at blockstream.com, Bitcoin Protocol
>
> Discussion bitcoin-dev at lists.linuxfoundation.org
>
> Subject: Re: [bitcoin-dev] Vaulting (Was: Automatically reverting
> ("transitory") soft forks)
> Message-ID:
> CAGpPWDaeKYABkK+StFXoxgWEhVGzqY02KPGOFjOtt9W8UPRr1A at mail.gmail.com
>
> Content-Type: text/plain; charset="utf-8"
>
> @Matt
>
> > both of which are somewhat frustrating limitations, but not security
>
> limitations, only practical ones.
>
> So I think the first limitation you mentioned (that if your hot wallet's
> key gets stolen you need) can be legitimately considered a security
> limitation. Not because you need to rotate your keys, but because you might
> not know your hot wallet key has been stolen. If you unvault an output to
> your hot wallet, the thief could be lying in wait, ready to steal those
> funds upon them landing. At that point, you would then know your hot wallet
> key was compromised and could rotate your vault keys in order to prevent
> further theft. However, the fact that there is a clear theft vulnerability
> is something I would say should be considered a "security limitation".
>
> As you mentioned, this is of course also a security limitation of a hot
> wallet, so this setup definitely has a lot of advantages over a simple hot
> wallet. However, if you compare it against a multisig wallet (eg 2 of 3),
> you can see that while theft of a single key would never result in any
> theft in that setup, it could in a CTV vault. The other trade offs there
> are ones of practicality and convenience.
>
> This isn't to say a CTV vault wouldn't be useful. Just that it has
> significant trade offs.
>
> @Russel
>
> > the original MES vault .. commits to the destination address during
>
> unvaulting
>
> I see. Looking at the MES16 paper, OP_COV isn't described clearly enough
> for me to understand that it does that. However, I can imagine how it
> might do that.
>
> One possibility is that the intended destination is predetermined and
> hardcoded. This wouldn't be very useful, and also wouldn't be different
> than how CTV could do it, so I assume that isn't what you envisioned this
> doing.
>
> I can imagine instead that the definition of the pattern could be specified
> as a number indicating the number of stack items in the pattern, followed
> by that number of stack items. If that's how it is done, I can see the user
> inputting an intended destination script (corresponding to the intended
> destination address) which would then be somehow rotated in to the right
> spot within the pattern, allowing the pattern to specify the coins
> eventually reaching an address with that script. However, this could be
> quite cumbersome, and would require fully specifying the scripts along the
> covenant pathways leading to a fair amount of information duplication
> (since scripts must be specified both in the covenant and in spending the
> subsequent output). Both of these things would seem to make OP_COV in
> practice quite an expensive opcode to spend with. It also means that, since
> the transactor must fully specify the script, its not possible to take
> advantage of taproot's script hiding capabilities (were it to send to a
> taproot address).
>
> However, my assumptions might be incorrect. If you think OP_COV would be a
> useful opcode, I would encourage you to write up a complete specification.
>
> > What ways can we build a secured vault that commits to the destination
>
> address?
>
> Some kind of passed-through state allows doing this. With OP_COV (if my
> assumptions above are correct), the intended destination can be passed
> through the output script pattern(s). With my own proposed
> op_pushoutputstack
> https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/pos/bip-pushoutputstack.md,
>
> state is passed as an attachment on the output more directly. Curious what
> you think about that proposal.
>
> > Are there elegant ways of building secure vaults by using CTV plus
>
> something else.
>
> Since CTV predefines all the transactions that can happen under its
> control, passed state like this can't help because any dynamic state would
> change the template and render the CTV transaction invalid. I don't see any
> way of solving this problem for CTV.
>
> I'm curious how you think op_cat could enable this with CTV (other than the
> cat+schnorr tricks that don't require CTV at all).
>
>
>
> On Sat, Apr 23, 2022 at 2:31 PM Russell O'Connor via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> > Okay, Matt explained to me the intended application of CTV vaults off
> > list, so I have a better understanding now.
> >
> > The CTV vault scheme is designed as an improvement over the traditional
> > management of hot-wallets and cold-wallets. The CTV vault is logically on
> > the "cold-side" and lets funds be sent from the "cold" side to one's own
> > the hot wallet after the unvaulting delay. In this case, the hot wallet
> > funds are always at risk, so it isn't unexpected that those funds could be
> > stolen. After all, that is how hot wallets are today. The advantage is
> > that funds can be moved from the "cold" side without needing to dig out the
> > cold keys.
> >
> > The MES vault scheme applies to a different scenario. In the MES case it
> > is the hot funds are inside the vault, and it is the hot key that unvaults
> > the funds and sends them to customer's addresses after a delay. If the
> > hot-key is used in any unauthorised way, then funds can be sent to the
> > address of the cold key (the MES vault actually does something fancy in
> > case of recovery, but it could be adapted to simply send funds to a cold
> > wallet).
> >
> > The MES vault lie somewhere between "better" and "different" when compared
> > to the CTV vault. If one is unwilling to use the MES vault on the hot side
> > and have every withdrawl vetted, then, while you could use the MES design
> > on the cold side like the CTV vault, it wouldn't really offer you any
> > advantages over a CTV vault. However, if you are interested in managing
> > all your payments through a vault (as I've been imagining) then the CTV
> > vault comes across as ineffective when compared to an MES style vault.
> >
> > On Sat, Apr 23, 2022 at 2:24 PM Matt Corallo lf-lists at mattcorallo.com
> > wrote:
> >
> > > Still trying to make sure I understand this concern, let me know if I get
> > > this all wrong.
> > >
> > > On 4/22/22 10:25 AM, Russell O'Connor via bitcoin-dev wrote:
> > >
> > > > It's not the attackers only choice to succeed. If an attacker steals
> > > > the hot key, then they have
> > > > the option to simply wait for the user to unvault their funds of their
> > > > own accord and then race /
> > > > outspend the users transaction with their own. Indeed, this is what we
> > > > expect would happen in the
> > > > dark forest.
> > >
> > > Right, a key security assumption of the CTV-based vaults would be that
> > > you MUST NOT EVER withdraw
> > > more in one go than your hot wallet risk tolerance, but given that your
> > > attack isn't any worse than
> > > simply stealing the hot wallet key immediately after a withdraw.
> > >
> > > It does have the drawback that if you ever get a hot wallet key stole you
> > > have to rotate all of your
> > > CTV outputs and your CTV outputs must never be any larger than your hot
> > > wallet risk tolerance
> > > amount, both of which are somewhat frustrating limitations, but not
> > > security limitations, only
> > > practical ones.
> > >
> > > > And that's not even mentioning the issues already noted by the document
> > > > regarding fee management,
> > > > which would likely also benefit from a less constrained design for
> > > > covenants.
> > >
> > > Of course I've always been in favor of a less constrained covenants
> > > design from day one for ten
> > > reasons, but that's a whole other rabbit hole :)
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220425/e6f9b337/attachment-0001.sig>

2023-06-07 23:07:24

- reply

📅 Original date posted:2022-04-20
📝 Original message:Hi AJ,
Long time listener first time caller here.
All merits (or lack thereof depending on your view) of CTV aside, I find this topic around decision making both interesting and important. While I think I sympathize with the high level concern about making sure there are use cases, interest, and sufficient testing of a particular proposal before soft forking it into consensus code, it does feel like the attempt to attribute hard numbers in this way is somewhat arbitrary.
For example, I think it could be reasonable to paint the list of examples you provided where CTV has been used on signet in a positive light. 317 CTV spends “out in the wild” before there’s a known activation date is quite a lot (more than taproot had afaik). If we don’t think it is enough, then what number of unique spends and use cases should we expect to see of a new proposal before it’s been sufficiently tested?
Perhaps this is simply a case of the Justice Stewart view on pornography where “you know it when you see it”[1], but then if that’s the case than it really doesn’t seem productive to use these numbers to evaluate the readiness and eagerness to use CTV since they are effectively arbitrary and could be used to make the argument in either direction.
So perhaps it just *felt* like there was more need and ready-to-use applications of taproot, and perhaps this feeling is broadly shared and that’s fine, and it doesn’t *feel* that way for CTV, but by the measures you laid out were there as many uses in the wild of taproot spends before it was brought to Speedy Trial? As far as I’m aware there seemed to be more broken [2], premature Taproot spends then actual practical uses of it on a test network before it was fully activated (I might be wrong about this though). Meanwhile the primary tooling necessary to really make it useful (PTLCs, Musig2, FROST) weren’t even fully specced out yet let alone actively being used on a test network and the list of proposed applications on the bitcoin wiki [3] (last updated April 2021) is similarly sparse and not quite up to the standards you’ve set for CTV to be the next soft fork (this is to say nothing of the fact that many prefer to develop, build, and test on regtest than signet at this stage).
Maybe this is similarly an argument for Taproot being activated too early and that may be a fair argument (not one I share to be clear). If that’s the case, I think it’s reasonable to put all cards on the table and we should be explicit that Taproot activation was premature for [X] reasons, here’s the new standard we want to have new proposals hit (a signet, expected level of activity, etc.). Then whether it’s CTV or TLUV or ANYPREVOUT, that’s what we as a community, the developers maintaining the proposals, and the developers/companies that plan to build on top of the new proposal should strive to achieve.
In absence of the above, the risk of a constantly moving bar means the possibility of either insufficiently reviewed proposals getting activated because we’re complacent and just placing trust in a small cadre of experts (nothing malicious in this, just seems worth avoiding) or personal and subjective reasoning allowing for premature ossification and blocking of upgrades that could otherwise be considered safe, useful, and perhaps even necessary on a long enough time horizon.
There’s also the other risk which you point out:
> One challenge with building a soft fork is that people don't want tocommit to spending time building something that relies on consensusfeatures and run the risk that they might never get deployed. But thereverse of that is also a concern: you don't want to deploy consensuschanges and run the risk that they won't actually turn out to be useful.
Perhaps if we had clear metrics of what would make the work worth it, if we knew what we were working towards, we’d be more likely to get that proof of work. To use your meme, miners know precisely what they’re mining for and what a metric of success looks like which makes the risk/costs of attempting the PoW worth it (or conversely sometimes resulting the decision for miners to be decommissioned). In addition to the examples listed above, even Taproot which most agree had relatively broad consensus didn’t have much work happening on top of it until it was activated. Suredbits as far as I’m aware didn’t want to build DLCs on top of lightning until taproot AND PTLCs were in use (in contrast we already have a DLC implementation that uses CTV[4]). We also have new ideas that only started coming up after Taproot activation (TLUV and Taro for example), so there’s also the unknown of what we could have once it becomes clear that it’s worth devoting mental energy and financial resources towards research.
One last wrinkle with regards to using countable metrics to determine a feature’s “worth” is that not all features are the same. Many of the use cases that people are excited to use CTV for ([5], [6]) are very long term in nature and targeted for long term store of value in contrast to medium of exchange. Metrics for measuring value of a store of value upgrade are fundamentally different than those measuring value of MoE. It’s like people pointing to transaction volume on other cryptocurrency systems to show that their chain is more valuable. You can build a CTV vault in signet, but you’ll only really see a lot of people using it when it’s to store real value on a time scale measured in decades not minutes or days like you might find for lightning testing and experimentation. This doesn’t make one more or less desirable or valuable imo, just that the evaluation metrics should be treated totally differently.
Anyway, I guess that’s a (very) long way of saying, are these constructive ways to evaluate an upgrade and if they are can we maybe have an idea of what a success vs. a failure metric looks like (and in the interest of retrospection and iterative improvement, it would be useful to know if in retrospect Taproot didn’t reach these metrics and maybe was activated prematurely as a result). To put another way and leave CTV out of it completely, what should an outside, unbiased observer that doesn’t spend much time on Twitter expect to be able to see to evaluate the readiness or acceptability of ANYPREVOUT, TLUV, or any other possible future soft forks? If nothing else, nailing this down would seem to help make the lives of key bitcoin core maintainers much easier by removing politics from decisions that should otherwise be as technical in nature as possible.
[1](http://cbldf.org/about-us/case-files/obscenity-case-files/obscenity-case-files-jacobellis-v-ohio-i-know-it-when-i-see-it/)
[2](https://suredbits.com/taproot-funds-burned-on-the-bitcoin-blockchain/)
[3](https://en.bitcoin.it/wiki/Taproot_Uses)
[4](https://github.com/sapio-lang/sapio/blob/master/sapio-contrib/src/contracts/derivatives/dlc.rs)
[5](https://github.com/kanzure/python-vaults/blob/master/vaults/bip119_ctv.py)
[6](https://github.com/jamesob/simple-ctv-vault)
> On Thu, Feb 17, 2022 at 01:58:38PM -0800, Jeremy Rubin via bitcoin-dev wrote:AJ Wrote (in another thread): I'd much rather see some real third-party experimentation *somewhere* public first, and Jeremy's CTV signet being completely empty seems like a bad sign to me.
> There's now been some 2,200 txs on CTV signet, of which (if I haven'tmissed anything) 317 have been CTV spends:
> - none have been bare CTV (ie, CTV in scriptPubKey directly, not via p2sh/p2wsh/taproot)
> - none have been via p2sh
> - 3 have been via taproot: https://explorer.ctvsignet.com/tx/f73f4671c6ee2bdc8da597f843b2291ca539722a168e8f6b68143b8c157bee20 https://explorer.ctvsignet.com/tx/7e4ade977db94117f2d7a71541d87724ccdad91fa710264206bb87ae1314c796 https://explorer.ctvsignet.com/tx/e05d828bf716effc65b00ae8b826213706c216b930aff194f1fb2fca045f7f11
> The first two of these had alternative merkle paths, the last didn't.
> - 314 have been via p2wsh https://explorer.ctvsignet.com/tx/62292138c2f55713c3c161bd7ab36c7212362b648cf3f054315853a081f5808e (don't think there's any meaningfully different examples?)
> As far as I can see, all the scripts take the form:
> [PUSH 32 bytes] [OP_NOP4] [OP_DROP] [OP_1]
> (I didn't think DROP/1 is necessary here? Doesn't leaving the 32 bytehash on the stack evaluate as true? I guess that means everyone's usingsapio to construct the txs?)
> I don't think there's any demos of jamesob's simple-ctv-vault [0], whichI think uses a p2wsh of "IF n CSV DROP hotkey CHECKSIG ELSE lockcoldtx CTVENDIF", rather than taproot branches.
> [0] https://github.com/jamesob/simple-ctv-vault
> Likewise I don't think there's any examples of "this CTV immediately;or if fees are too high, this other CTV that pays more fees after Xdays", though potentially they could be hidden in the untaken taprootmerkle branches.
> I don't think there's any examples of two CTV outputs being combinedand spent in a single transaction.
> I don't see any txs with nSequence set meaningfully; though most (all?)of the CTV spends seem to set nSequence to 0x00400000 which I thinkdoesn't have a different effect from 0xfffffffe?
> That looks to me like there's still not much practical (vs theoretical)exploration of CTV going on; but perhaps it's an indication that CTVcould be substantially simplified and still get all the benefits thatpeople are particularly eager for.
> I am unsure that "learning in public" is required --
> For a consensus system, part of the learning is "this doesn't seem thatinteresting to me; is it actually valuable enough to others that thechange is worth the risk it imposes on me?" and that's not somethingyou can do purely in private.
> One challenge with building a soft fork is that people don't want tocommit to spending time building something that relies on consensusfeatures and run the risk that they might never get deployed. But thereverse of that is also a concern: you don't want to deploy consensuschanges and run the risk that they won't actually turn out to be useful.
> Or, perhaps, to "meme-ify" it -- part of the "proof of work" for deployinga consensus change is actually proving that it's going to be useful.Like sha256 hashing, that does require real work, and it might turn outto be wasteful.
> Cheers,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220420/2585027e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220420/2585027e/attachment-0001.sig>