Re: [bitcoin-dev] BIP proposal: Timelocked address fidelity bond for BIP39 seeds

2022-05-02 Thread ZmnSCPxj via bitcoin-dev
Good morning Chris, > Hello ZmnSCPxj, > > Renting out fidelity bonds is an interesting idea. It might happen in > the situation where a hodler wants to generate yield but doesn't want > the hassle of running a full node and yield generator. A big downside of > it is that the yield generator income

[bitcoin-dev] CTV Meeting #8 Reminder + Agenda (Tuesday, May 3rd, 12:00 PT / 7PM UTC)

2022-05-02 Thread Jeremy Rubin via bitcoin-dev
Developers, A reminder that the regularly scheduled CTV Meeting is tomorrow at 12:00 Pacific Time in ##ctv-bip-review in Libera. In terms of agenda, we'll keep it as an open forum for discussion guided by the participants. Feel free to propose meeting topics in the IRC in advance of the meeting t

Re: [bitcoin-dev] [Pre-BIP] Fee Accounts

2022-05-02 Thread Jeremy Rubin via bitcoin-dev
Ok, got it. Won't waste anyone's time on terminology pedantism. The model that I proposed above is simply what *any* correct timestamping service must do. If OTS does not follow that model, then I suspect whatever OTS is, is provably incorrect or, in this context, unreliable, even when servers an

Re: [bitcoin-dev] BIP proposal: Timelocked address fidelity bond for BIP39 seeds

2022-05-02 Thread Chris Belcher via bitcoin-dev
Hello ZmnSCPxj, Renting out fidelity bonds is an interesting idea. It might happen in the situation where a hodler wants to generate yield but doesn't want the hassle of running a full node and yield generator. A big downside of it is that the yield generator income is random while the rent pa

Re: [bitcoin-dev] ANYPREVOUT in place of CTV

2022-05-02 Thread Billy Tetrud via bitcoin-dev
> If a QC is able overnight to spend a large fraction of the supply, your coins in your super non-QC vulnerable-bare-CTV-covenant (that would eventually become vulnerable when trying to use it) are worthless.[1] I know this has been debated to death, but I really don't think this argument is ver

Re: [bitcoin-dev] Conjectures on solving the high interactivity issue in payment pools and channel factories

2022-05-02 Thread Billy Tetrud via bitcoin-dev
Hi Antoine, Very interesting exploration. I think you're right that there are issues with the kind of partitioning you're talking about. Lightning works because all participants sign all offchain states (barring data loss). If a participant can be excluded from needing to agree to a new state, the

Re: [bitcoin-dev] Multiple ways to do bitcoin covenants

2022-05-02 Thread Billy Tetrud via bitcoin-dev
I've been thinking about writing something about covenant proposals from the viewpoint of wallet vaults specifically (mostly because that's the use case I care most about). CTV is basically the minimal covenant opcode you can do that doesn't have malleability. Everything else either introduces mal

Re: [bitcoin-dev] Towards a means of measuring user support for Soft Forks

2022-05-02 Thread Billy Tetrud via bitcoin-dev
> if you are perfectly rational, you can certainly imagine a "what if" where your goal is different from your current goal and figure out what you would do ***if*** that were your goal instead. I see what you're saying, and I'm a lot more on board with that. I still think "rational" can't mean "p

Re: [bitcoin-dev] Working Towards Consensus

2022-05-02 Thread John Carvalho via bitcoin-dev
Jeremy, The path to consensus is to propose things that everyone needs. Demand comes from the market, not the designers. Designers (engineers) solve problems with designs, but when they speculate and lead the process, they create problems instead. Bitcoin is not a place for speculative feature ad