From: lf-lists@mattcorallo•com
To: Anthony Towns <aj@erisian•com.au>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP 118 and SIGHASH_ANYPREVOUT
Date: Tue, 4 Aug 2020 00:02:21 -0400 [thread overview]
Message-ID: <4AFF2D6A-57BE-40CF-A15F-E972AEB9ACDE@mattcorallo.com> (raw)
In-Reply-To: <20200709214048.27mycsi5h2bnv3cc@erisian.com.au>
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@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@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
next prev parent reply other threads:[~2020-08-04 4:02 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-09 21:40 Anthony Towns
2020-07-09 22:30 ` Anthony Towns
2020-07-10 7:46 ` Christian Decker
2020-07-10 3:29 ` ZmnSCPxj
2020-08-03 19:27 ` Richard Myers
2020-08-04 1:38 ` ZmnSCPxj
2020-08-04 4:02 ` lf-lists [this message]
2020-08-04 4:23 ` ZmnSCPxj
2020-08-04 10:38 ` Christian Decker
2020-08-04 13:10 ` Matt Corallo
2020-08-04 14:59 ` ZmnSCPxj
2020-08-06 15:58 ` Matt Corallo
2020-08-07 15:34 ` Richard Myers
2020-08-11 0:14 ` Matt Corallo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4AFF2D6A-57BE-40CF-A15F-E972AEB9ACDE@mattcorallo.com \
--to=lf-lists@mattcorallo$(echo .)com \
--cc=aj@erisian$(echo .)com.au \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox