lf-lists at mattcorallo.com [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2020-08-04 to 2020-08-21
💬 Posted a total of 2 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 18:26:28

- reply

📅 Original date posted:2020-08-21
📝 Original message:Sure, we could do a new message for negotiation, but there doesn’t seem to be a lot of reason for it - using the same namespace for negotiation seems fine too. In any case, this is one of those things that doesn’t matter in the slightest, and if one person volunteers to write a BIP and code, no reason they shouldn’t just decide and be allowed to run with it. Rough consensus and running code, as it were :)
Matt
> On Aug 20, 2020, at 22:37, Anthony Towns via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> On Fri, Aug 14, 2020 at 03:28:41PM -0400, Suhas Daftuar via bitcoin-dev wrote:
>> In thinking about the mechanism used there, I thought it would be helpful to
>> codify in a BIP the idea that Bitcoin network clients should ignore unknown
>> messages received before a VERACK. A draft of my proposal is available here
>> [2].
>
> Rather than allowing arbitrary messages, maybe it would make sense to
> have a specific feature negotiation message, eg:
>
> VERSION ...
> FEATURE wtxidrelay
> FEATURE packagerelay
> VERACK
>
> with the behaviour being that it's valid only between VERSION and VERACK,
> and it takes a length-prefixed-string giving the feature name, optional
> additional data, and if the feature name isn't recognised the message
> is ignored.
>
> If we were to support a "polite disconnect" feature like Jeremy suggested,
> it might be easier to do that for a generic FEATURE message, than
> reimplement it for the message proposed by each new feature.
>
> Cheers,
> aj
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 18:26:07

- reply

📅 Original date posted:2020-08-04
📝 Original message:While I admit I haven’t analyzed the feasibility, I want to throw one additional design consideration into the ring.
Namely, it would ideally be trivial, at the p2p protocol layer, to relay a transaction to a full node without knowing exactly which input transaction that full node has in its mempool/active chain. This is at least potentially important for systems like lighting where you do not know which counterparty commitment transaction(s) are in a random node’s mempool and you should be able to describe to that node that you are spending then nonetheless.
This is (obviously) an incredibly nontrivial problem both in p2p protocol complexity and mempool optimization, but it may leave SIGHASH_NOINPUT rather useless for lighting without it.
The least we could do is think about the consensus design in that context, even if we have to provide an external overlay relay network in order to make lighting transactions relay properly (presumably with miners running such software).
Matt
> On Jul 9, 2020, at 17:46, Anthony Towns via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Hello world,
>
> After talking with Christina ages ago, we came to the conclusion that
> it made more sense to update BIP 118 to the latest thinking than have
> a new BIP number, so I've (finally) opened a (draft) PR to update BIP
> 118 with the ANYPREVOUT bip I've passed around to a few people,
>
> https://github.com/bitcoin/bips/pull/943
>
> Probably easiest to just read the new BIP text on github:
>
> https://github.com/ajtowns/bips/blob/bip-anyprevout/bip-0118.mediawiki
>
> It doesn't come with tested code at this point, but I figure better to
> have the text available for discussion than nothing.
>
> Some significant changes since previous discussion include complete lack
> of chaperone signatures or anything like it (if you want them, you can
> always add them yourself, of course), and that ANYPREVOUTANYSCRIPT no
> longer commits to the value (details/rationale in the text).
>
> Cheers,
> aj
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev