> I suppose ultimately this brings up the question of the scope of this BIP.
> The abstract points out that the BIP contains both a definition of address
> derivation, but also how to sign fidelity bond certificates.
>
> My feeling is that the latter might be better not included? I note that the
--- Original Message ---
On Tuesday, May 10th, 2022 at 17:54, ZmnSCPxj via bitcoin-dev
wrote:
> Good morning waxwing,
>
> Ah, yes, now I remember.
> I discussed this with Tamas as well in the past and that is why we concluded
> that in defiads, each UTXO can host at most one advertise
Hello devs,
I've had this thought rattling around and thought it was worth putting to a
wider audience since
I haven't really seen it in other contexts. I've been working on eltoo
designs for Elements and
eventual inclusion into Bitcoin. With that in mind there's been a
reasonable amount of discus
Good morning waxwing,
> --- Original Message ---
> On Sunday, May 1st, 2022 at 11:01, Chris Belcher via bitcoin-dev
> bitcoin-dev@lists.linuxfoundation.org wrote:
>
> > Hello ZmnSCPxj,
> > This is an intended feature. I'm thinking that the same fidelity bond
> > can be used to running a J
Good morning Billy,
> 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
I think this is a useful proposal. There are certainly things about BIP9
that BIP8 fixes. I believe taproot's speedy trial did kind of a hybrid, but
a BIP spec was never produced for it afaik. A possibly unhelpful comment:
> minimum_activation_height
I think a minor improvement would be to specif
Hi Rusty,
Thanks for this. Seems like a productive direction to explore.
To me, one of the biggest limitations of CTV is that the script is
specific to the amount of the input being spent. OP_TX makes it
possible, although clumsy, to emulate OP_IN_OUT_AMOUNT, which could be
combined with CTV emul
> So if you don't want to receive restricted coins, just don't generate an
address with those restrictions embedded.
This is an interesting point that I for some reason haven't thought of
before. However...
> Unless governments can mandate that you generate these addresses AND
force you to accep
Hi Bitcoin Developers,
There were some disagreements with speedy trial activation method recently and
BIP 8 became controversial because of LOT earlier. I have tried to solve these
two problems after reading some arguments for/against different activation
methods by removing LOT from BIP 8 and
--- Original Message ---
On Sunday, May 1st, 2022 at 11:01, Chris Belcher via bitcoin-dev
wrote:
> Hello ZmnSCPxj,
>
> This is an intended feature. I'm thinking that the same fidelity bond
> can be used to running a JoinMarket maker as well as a Teleport
> (Coinswap) maker.
>
> I don't
Hi all,
TL;DR: a v1 tapscript opcode for generic covenants, but
OP_SUCCESS unless it's used a-la OP_CHECKTEMPLATEVERIFY. This gives an
obvious use case, with clean future expansion. OP_NOP4 can be
repurposed in future as a shortcut, if experience shows that to be a
useful optimization.
Hi Antoine and Billy,
Thank you for your comments and for looking into the proposal.
On Mon, 9 May 2022 at 12:36, darosior wrote:
> 1. The `` optimization for the common usecase of using 2
> descriptors at different derivation indices
>for receive and change. [1]
> 2. The `/**` optimization
12 matches
Mail list logo
