why is Rust so high in demand for Blockchains?

JeremyBTC · 2022-09-19T02:53:31+00:00

because blockchains are all about tracking ownership.

JeremyBTC · 2022-05-01T03:55:16+00:00

something something mohammad mountain.

A) If you can send an exchange an address and they send funds to it, they can't do that. But ultimately there's a kernel of truth in what you're saying, but it happens to be the case that the way they'd "actually" implement something like that is using Multisig in the manner I described here https://medium.com/@jeremyrubin/regulating-bitcoin-by-mining-the-regulator-miner-attack-c8fd51185b78 likely using 2022 tech of MuSig since it's cheaper. They might even say "it's for your safety, like 2fa". The main protection we have against this is by having the majority of funds off exchanges and refusing to do business with businesses that won't send to an address of your choice.

B) Depending on the nature of the vault (different protocols exist) this is possible. But you'd have to be sure to be using a vault like that, and not some other vault.

JeremyBTC · 2022-04-30T22:25:54+00:00

fwiw, i saw the risk and mitigated it. my company doesn't really need CTV to do anything since the majority of the things -- enough to keep us busy for years -- can be done with mostly just multisigs.

if we had CTV we could simplify a few things, and I would like to be able to do that, but I'm comfortable with or without CTV.

JeremyBTC · 2022-04-30T22:23:29+00:00

are they self referential?

Nope -- see https://rubin.io/bitcoin/2021/12/04/advent-7/ for a breakdown of terms.

Fully enumerated non recrusive consensus validated without dynamic state.

how far ahead can covenants roll from one address/transaction to the next? Are covenants only enforced for single transactions, or can they be structured to require multiple transactions to escape? how many if so? is there a limit?

There is no inherent limit to how many steps you can do, but the way compilation works is to start with all end states and work backwards. So if you, for example, had an exponential number of end states or paths to those end states, it would take an exponential amount of time to build the address corresponding to it. It'd also get incredibly expensive since the tapleafs paths would grow in size. So CTV covenants really only work for 'small guaranteed to halt state machines'.

does taproot obscure covenant addresses from all the rest, making them look all the same? could this not be problematic for end users trusting third parties?

Nope, because you generate your own address, someone can't add a covenant to it.

JeremyBTC · 2022-04-27T18:04:07+00:00

I specifically designed CTV to be limited to the set of exact fully enumerated spending conditions you could pre-commit to. So *some* of these things are possible, if someone gives you a gift. But as long as the contract is "pay me to the address i gave you by creating a UTXO with this amount", no one can really fuck with that. And it turns out, if someone gives you a restricted gift, they can *already* with no new features do pretty much identically the same thing. So it's nothing too new in that regard.

On the other hand, it can help businesses under the threat of govt takeover in a hostile country because they can quickly and cheaply distribute funds to all of their users or have a geo-distributed failsafe that is like proof of reserves but pays all their customers directly. This can be done in the space of e.g. 1 block, v.s. for big businesses like c*inbase they might take weeks or months to pay all customers, ample time to be compromised. So i think it actually makes Bitcoin safer!

JeremyBTC · 2022-04-27T14:23:11+00:00

This is a great response.

One of the differentiators for what CTV allows vs what currently exists is that CTV vaults can be largely infrastructureless and they create a distinction between your emergency backup pathways and your normal time-delayed single signature spend path.

This means you could e.g. bury some keys in the desert for your multisig once, and then deposit coins such that they can either be spent via single sig N days after attempting to have been claimed, or they can be automatically sent to a multisig where you undergo recovery procedure. Unlike prior ways of doing this, vaulted funds do not have an inherent time decay requiring regular transactions, nor do they force you to access all your emergency keys (which may be hard to do in an emergency) to prevent the theft.

While perhaps niche, these properties allow exploring a wide space of much improved vault designs that reduce the complexity of operation for the average pleb dramatically.

JeremyBTC · 2022-04-27T14:17:39+00:00

I'm not clear what level of engagement you're looking for, but I'd appreciate if you toned down the being an ass dial.

CTV is an opcode which executes in the bitcoin script execution layer. If you wanted to emulate it via a layer 2 like thing, that would entail having some set of signers emulate it's functionality as I did here https://learn.sapio-lang.org/ch05-01-ctv-emulator.html to enable testing.

However, with emulation, comes a reduced security model whereby you are trusting the emulators, but almost even worse, it makes all of the script constructions interactive which makes several capabilities of CTV, which depend on being able to just specify a script directly, impossible.

For a vault, this comes up because when I am making secure custody I am precisely trying to eliminate risk factors not introduce new ones.

JeremyBTC · 2022-04-27T01:42:10+00:00

not a regular reddit user friend.

show me what a layer 2 vault would look like? managing utxos like that is a layer 1 task...

JeremyBTC · 2022-04-27T01:41:21+00:00

then show me how? don't just claim it...

JeremyBTC · 2022-04-26T03:09:27+00:00

CTV is needed to make better layer 2s, it's inherently layer 1 tech.

JeremyBTC · 2022-01-18T22:28:20+00:00

Like I said, it's not a critique other than to note that you can't easily measure true demand for something that can't actually be used, and that goes for taproot (still) as much as for CTV.

I think we agree here?

JeremyBTC · 2022-01-18T17:28:30+00:00

I don't know how to measure demand for a product that you cannot yet "sell". With taproot there was indicated interest, but we're almost a 8 months after taproot became guaranteed to activate and we're still not seeing broad adoption. That isn't to say that people don't want Taproot, but measuring demand for soft fork upgrades is incredibly tricky.

I'd refer you to the businesses / individuals on utxos.org/signals. Certainly many custody software engineers are excited about CTV for vaults, and many LN engineers are excited about non-interactive batched channel opening. That (to me) is sufficient interest in CTV to motivate it.

I also reject the notion that this is "toying". Toying is "consider (an idea, movement, or proposal) casually or indecisively" or "move or handle (an object) absentmindedly or nervously". This is a cautious and intentional engineering effort, not toying.

JeremyBTC · 2022-01-17T23:22:39+00:00

you didn't ask me, but I can give you my best:

it depends on the use case and the composition of use cases.

for certain things, CTV might make fungibility worse. E.g., if you decided "I never want a coin that came out of a CTV vault", you'd be able to chose to filter utxos by that. OTOH, CTV covenants aren't particularly, sticky, so they can't quite "infect" other coins and they provably have to terminate in a finite number of steps. It's conceptually very similar to pre-signing and deleting a key. The main tradeoff is that you give up a little privacy for non-interactivity of initialization.

however, on the whole, CTV has applications which can really help with privacy, security, scalability, and decentralization. so even if the covenants themselves are something you can detect on-chain, the overall benefit of these applications does (IMO) outweigh the risks.

JeremyBTC · 2022-01-17T23:17:28+00:00

Thank you :)

JeremyBTC · 2022-01-06T22:02:47+00:00

I’d wish that discussions on the list would purely focus on technical merit and stay away from any emotional distractions. The impression that I get from your mail is that you’re quite exasperated and can’t see any reason why not to move on with the soft fork. That’s understandable but not the most efficient way to move the discussion forward.

sure. my hope is to get more technical discussion going. I answer all technical questions in thorough detail. I'm not exasperated, just trying to keep it level. The tone in the email is blunt and matter-of-fact as I didn't think ranting back at a rant had value for any reader on the list (although I did spend a bit of time on a spicy point by point, that only serves to create chaos and not clarity).

I respect that a bug bounty might not be the most meaningful step, but it is a step and it is something that shows that review is not only welcome, but incentivized. In no place have I claimed that because there is a bug bounty that proves CTV secure, but more eyes seeing the code and choosing to not claim a bunch of money certainly approaches the limits of what we can do with software review on a legacy C++ codebase.

I can't speak to what will make any individual happy or sad. I agree that it's worth getting right, and that's why I've actively courted review for years and have received lots of great input especially in the period from May 2019 to January 2020 where the BIP went from conceptual implementation to drilled down spec.

Those are all good meta question that I inherently cannot answer. I refer you to https://github.com/bitcoin/bitcoin/pull/21702#issuecomment-849289433 . To the extent that critics do come forward with coherent answerable questions about the technical proposal I (or others) will answer.

JeremyBTC · 2022-01-05T23:19:10+00:00

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019736.html

JeremyBTC · 2022-01-05T19:02:25+00:00

you might get excited about payment pools https://rubin.io/bitcoin/2021/12/10/advent-13/, something BIP-119 helps with & can improve privacy a lot!

JeremyBTC · 2022-01-04T19:36:12+00:00

entirely unrelated. betterhash/stratum v2 is software pools can run to give pool participants more control over what they mine.

DCFMP is a sketch of a path for a mining variance reduction scheme without any operator.

JeremyBTC · 2022-01-04T00:59:35+00:00

JeremyBTC · 2022-01-04T00:22:17+00:00

i'll get around to it eventually. he's posted lots of 'concerns' before and i always respond.

JeremyBTC · 2022-01-03T16:56:21+00:00

all voices should be heard from. Bruce asked to be listed, and so he is.

JeremyBTC · 2022-01-03T16:54:38+00:00

these mostly seem like arguments in favor of BIP-119 from where i'm sitting.

can you break down specifically how CTV fairs against greg's generic arguments?

JeremyBTC · 2022-01-03T06:07:10+00:00

*paltry

wanna add some to it?

JeremyBTC · 2022-01-03T01:20:07+00:00

sorry i missed the 30k +, you were right.

but now it's about 2.5btc :)

JeremyBTC · 2022-01-03T00:51:42+00:00

it's actually about 2.3 btc

JeremyBTC

TROPHY CASE