On Tue, Jan 18, 2022 at 6:25 PM Billy Tetrud wrote:
> > 'assert that my parent has a scriptpubkey of X'... That way you can, for
> example, have a UTXO which only allows itself to be absorbed by a
> transaction also involving a UTXO with a particular capability
>
> I'm not sure I fully follow. I
On Tue, Jan 18, 2022 at 03:54:21PM -0800, Jeremy via bitcoin-dev wrote:
> Some of it's kind of annoying because
> the legal definition of covenant is [...]
> so I do think things like CLTV/CSV are covenants
I think that in the context of Bitcoin, the most useful definition of
covenant is that
> BIP8 is also BIP9 based, and ST is its own thing that's neither BIP8 nor
> BIP9, so characterization one way or another is moot IMO.
For a selective definition of “based” you can draw any conclusion you desire.
However I was very clear, as was Luke, and the history on this issue is equally
On Thu, Jan 20, 2022 at 11:23:30AM -0800, Bram Cohen via bitcoin-dev wrote:
> > Nodes currently aren't required to keep around the whole blockchain, but
> > your proposal sounds like it would require them to. I think this could be
> > pretty detrimental to future scalability. Monero, for example,
Thanks for the info.
> you could "sponsor yourself" directly or through a cycle involving > 1
txn.
Ah I see, because the sighash flags aren't used to create the TXID. I don't
really see the problem with cycles tho. Could a cycle cause problems for
anyone? Seems like it would be a harmless waste
Hi
I'd just like to bring some attention to this blog post from the Suredbits team
who when implementing Taproot in bitcoin-s found a mainnet output that did not
conform to the BIP 340 specification [0] (invalid x coordinate) and hence were
burned.
I'm curious to hear clarification on most of Luke's non-activation related
comments.
> I would ideally like to see fully implemented BIPs for at least one of
these
While that would be interesting, I think that's a heavy burden to be placed
on this BIP. More in depth exploration would be helpful,
