Nostr notes by Greg Sanders [ARCHIVE]

📅 Original date posted:2023-10-17 🗒️ Summary of this ...

2023-10-18T13:02:10Z

In reply to nevent1q…zlfw
_________________________

📅 Original date posted:2023-10-17
🗒️ Summary of this message: Batched splicing is risky because if an old state is broadcasted and confirmed before the splice, it can disrupt the process. It is important for batched splicing mechanisms to have a backout option.
📝 Original message:
> I do not know if existing splice implementations actually perform such a
check.
Unless all splice implementations do this, then any kind of batched
splicing is risky.

As long as the implementation decides to splice again at some point when a
prior
splice isn't confirming, it will self-resolve once any subsequent splice is
confirmed.

Cheers,
Greg

On Tue, Oct 17, 2023 at 1:04 PM ZmnSCPxj via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Good morning Bastien,
>
> I have not gotten around to posting it yet, but I have a write-up in my
> computer with the title:
>
> > Batched Splicing Considered Risky
>
> The core of the risk is that if:
>
> * I have no funds right now in a channel (e.g. the LSP allowed me to have
> 0 reserve, or this is a newly-singlefunded channel from the LSP to me).
> * I have an old state (e.g. for a newly-singlefunded channel, it could
> have been `update_fee`d, so that the initial transaction is old state).
>
> Then if I participate in a batched splice, I can disrupt the batched
> splice by broadcasting the old state and somehow convincing miners to
> confirm it before the batched splice.
>
> Thus, it is important for *any* batched splicing mechanism to have a
> backout, where if the batched splice transaction can no longer be confirmed
> due to some participant disrupting it by posting an old commitment
> transaction, either a subset of the splice is re-created or the channels
> revert back to pre-splice state (with knowledge that the post-splice state
> can no longer be confirmed).
>
> I know that current splicing tech is to run both the pre-splice and
> post-splice state simultaneously until the splicing transaction is
> confirmed.
> However we need to *also* check if the splicing transaction *cannot* be
> confirmed --- by checking if the other inputs to the splice transaction
> were already consumed by transactions that have deeply confirmed, and in
> that case, to drop the post-splice state and revert to the pre-splice state.
> I do not know if existing splice implementations actually perform such a
> check.
> Unless all splice implementations do this, then any kind of batched
> splicing is risky.
>
> Regards,
> ZmnSCPxj
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20231017/831a1dfc/attachment-0001.html>;

📅 Original date posted:2023-07-20 🗒️ Summary of this ...

2023-07-20T09:54:06Z

In reply to nevent1q…4xe6
_________________________

📅 Original date posted:2023-07-20
🗒️ Summary of this message: Antoine acknowledges Greg's development approach but raises concerns about the authority of BOLTs and the technical fitness of Simplicity for small party channels.
📝 Original message:
Hi antoine,

Simplicity was just a stand in for "functionally complete" handwave.

Cheers,
Greg

On Thu, Jul 20, 2023, 1:46 AM Antoine Riard <antoine.riard at gmail.com> wrote:

> Hi Greg,
>
> I'm very meeting your development approach with regards to starting smalls
> about consensus change primitives, and I think taproot has demonstrated
> some good historical process, which has good archives about how development
> was conducted (e.g the community-wide taproot review of which the Bitcoin
> Contracting Primitives WG was built on this experience [0]).
>
> I don't know about saying that the BOLTs (and its process) should be
> authoritative over the running code of implementations. While it's
> definitely a mark of some bar of technical review and inter-compatibility,
> I think ultimately each BOLT has to be judged individually on its own
> technical merits. And I think we had a bunch of cases in the past when "the
> map is not the territory". Even there are few areas of critical Lightning
> operations which are not documented by the BOLTs to the best of my
> knowledge (such as fee-bumping and transactions broadcast reactions as it
> was for on-chain DLCs [1]).
>
> Lastly, there is a huge area of uncertainty about the technical fitness of
> Simplicity for 2/small party channels. I remember a Russell O'connor
> presentation about Simplicity back in Paris (2017 or 2018 ?) and asking him
> how it would work in a chain of transactions, while the answer was iirc
> "yes it has been designed with this constraint", it's a very open question
> when you have off-chain states which advances in independence from the
> on-chain state between a dynamic number of counterparties (kinda the
> interactivity issue for payment pools). Here I guess you would have to come
> to a consensus to the model of logic followed for the analysis of such
> distributed systems e.g Leslie Lamport's temporal logic [2]. Additionally,
> the theoretical foundations on the Coq prover are still actively studied by
> Xavier Leroy at the College de France and some novel insights might be
> interesting for using formal verification in terms of Bitcoin consensus
> changes development (and I don't know if all the works and lessons have
> been translated from French to English).
>
> Best,
> Antoine
>
> [0] https://github.com/ajtowns/taproot-review
> [1]
> https://github.com/discreetlogcontracts/dlcspecs/blob/master/Non-Interactive-Protocol.md
> [2] https://en.wikipedia.org/wiki/Temporal_logic_of_actions
>
> Le mer. 19 juil. 2023 à 21:45, Greg Sanders <gsanders87 at gmail.com> a
> écrit :
>
>> Hello Keagen,
>>
>> Most of the complexity of LN cannot be resolved with covenants. Of the
>> things that can be simplified in my experience, you're going to need more
>> than CTV to get significant gains. And in the end, channels can only get so
>> simple since we have many other BOLTs to deal with. And even then, you're
>> going to have to convince LN spec writers to include such changes, whatever
>> they are, then get deployment.
>>
>> Step 1 is finding a primitive that seems interesting. It's important to
>> moderate enthusiasm for any primitive with reality, and probably by being
>> concrete by writing specs that use a primitive, and code it up to discover
>> what we're overlooking. We're always overlooking something! In my humble
>> opinion these are step 2 and 3 of gathering mind-share.
>>
>> As a more productive tact, if we're thinking beyond 2/small party
>> channels, probably better to snap your fingers, pretend we have Simplicity,
>> see what we can build, and work backwards from there to see if we can
>> accomplish this within the confines of bitcoin script?
>>
>> Cheers,
>> Greg
>>
>> On Wed, Jul 19, 2023 at 3:59 PM Keagan McClelland via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> Hi Antoine,
>>>
>>> Thank you for the effort you've put towards this. I generally agree that
>>> a smooth functioning Lightning Network is of greater importance than
>>> advanced contracting capabilities. However, as I dive deeper into some of
>>> the more ambitious goals for LN development I am learning that a great deal
>>> of complexity of some current lightning (LN) proposals can be handily
>>> discharged with CTV. While I am not intimately familiar with all of the
>>> other covenant schemes to the same level of technical proficiency, I have a
>>> suspicion that a number of them, if not all of them, are capable of
>>> discharging the same flavor and amount of complexity as well. Others should
>>> chime in if they can confirm this claim.
>>>
>>> I have been publicly on the record as supporting the addition of some
>>> covenant scheme into Bitcoin for some time and have long held on
>>> theoretical grounds that the addition of such a mechanism is both necessary
>>> and inevitable if Bitcoin is to survive in the long term. However, as I've
>>> started to work more directly with the Lightning protocol, these
>>> theoretical and purely logical arguments became far more concrete and
>>> immediately beneficial.
>>>
>>> I say this primarily to challenge the idea that covenants are a
>>> distraction from lightning development. It may very well be that your areas
>>> of focus on LN preclude you from splitting your attention and none of this
>>> email should be interpreted as a criticism of you applying your efforts in
>>> the highest leverage manner you can manage. That said, I don't want
>>> observers of this thread to walk away with the impression that they are two
>>> independent efforts as covenants can significantly contribute to LN's
>>> maturity. When and how should they be prioritized? Unfortunately I don't
>>> feel able to comment on that at this time. All I know is that Lightning
>>> would almost certainly benefit substantially from having a covenant
>>> primitive.
>>>
>>> Cheers,
>>> Keags
>>>
>>> On Tue, Jul 18, 2023 at 3:40 PM Antoine Riard via bitcoin-dev <
>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>>> Hi list,
>>>>
>>>> Last year amid the failure of the CTV speedy trial activation and
>>>> intense conversations about a rainbow of covenant proposals, I introduced
>>>> the idea of a new community process to specify covenants [0]. This post is
>>>> to resume the experiment so far and officially mark the process maintenance
>>>> as "up for grabs", as I won't actively pursue it further (after wavering on
>>>> such a decision a bit during May / June).
>>>>
>>>> Few of the goals announced at that time were to build a consistent
>>>> framework to evaluate covenant proposals, see the common grounds between
>>>> proposals if they could be composed or combined by their authors, open the
>>>> consensus changes development process beyond the historical boundaries of
>>>> Bitcoin Core and maintain high-quality technical archive as a consensus
>>>> discussions have spawned half a decade from intellectual conception to
>>>> activation in average (at least for segwit, schnorr, taproot).
>>>>
>>>> Such effort was a speak-by-the-act answer to the issues in
>>>> consensus development changes pointed out by Jeremy Rubin in April of last
>>>> year [1]: namely the lack of a "codified checklist" for consensus changes,
>>>> that "consensus is memoryless" and "bitcoin core is not bitcoin"
>>>> (independently of the technical concerns as I have as limited or
>>>> non-adequate primitive for vaults / payment pools I expressed during the
>>>> same time). Other complementary initiatives have been undertaken during the
>>>> same period, AJ with the bitcoin-inquisition fork where the community of
>>>> developers and contracting primitives of researchers on a consensus-enabled
>>>> fork of core [2]. And Dave Harding with the careful archiving of all
>>>> covenant proposals under the Optech umbrella [3].
>>>>
>>>> About the Bitcoin Contracting Primitives WG, a Github repository was
>>>> started and maintained to archive and document all the primitives (apo,
>>>> tluv, ctv, the taproot annex, sighash_group, CSFS, cat, txhash, evict,
>>>> check_output_covenant_verify, inherited ids, anyamount, singletons,
>>>> op_vault) and the corresponding protocols (payment pools, vaults,
>>>> drivechains, trust-minimized mining pools payouts). We had a total of 6
>>>> monthly meetings on the Libera chat #bitcoin-contracting-primitives-wg for
>>>> a number of more than 20 individual attendees representing most of the
>>>> parts of the community. I think (missing march logs). Numerous in-depth
>>>> discussions did happen on the repository and on the channel on things like
>>>> "merkelized all the things" or "payment pools for miners payoffs".
>>>>
>>>> As I've been busy on the Lightning-side and other Bitcoin projects,
>>>> I've not run an online meeting since the month of April, while still having
>>>> a bunch of fruitful technical discussions with folks involved in the effort
>>>> at conferences and elsewhere. I launched the effort as an experiment with
>>>> the soft commitment to dedicate 20% of my time on it, after few successful
>>>> sessions I think such a process has an interest of its own, however it
>>>> comes with direct competition of my time to work on Lightning robustness.
>>>> Getting my hands dirty on low-level LDK development recently made me
>>>> realize we still have years of titan work to get a secure and reliable
>>>> Lightning Network.
>>>>
>>>> As such, between extended covenant capabilities for advanced contracts
>>>> coming as a reality for Bitcoin _or_ LN working smoothly at scale with
>>>> 50-100M UTXO-sharing users on it during the next 5-7 years cycle, I think
>>>> the latter goal is more critical for Bitcoin existential survival, and
>>>> where on a personal title I'll allocate the best of my time and energy (and
>>>> somehow it match the "slow" technical activity on bitcoin-inquisition
>>>> mostly done by Lightning hands).
>>>>
>>>> This is my personal conclusion only on the state of Bitcoin
>>>> technological momentum, and this is quite tainted by my deep background in
>>>> Lightning development. If you've been working on covenant changes
>>>> proposals, please don't take it as a discouragement, I think Taproot
>>>> (privacy-preserving script policies behind the taproot tree branches) and
>>>> Schnorr (for native multi-sig) soft forks have shown how it can improve the
>>>> building of self-custody solutions by one or two order of magnitude, and
>>>> small incremental changes might be good enough to have a lower technical
>>>> consensus bar.
>>>>
>>>> On my side, I'll pursue pure R&D works on CoinPool, notably coming with
>>>> better solutions with the interactivity issue and mass-compression of
>>>> withdrawal and design exotic advanced Bitcoin contracts based on the
>>>> taproot annex, though more in a "l'art pour l'art" approach for the time
>>>> being [4]. Additionally, I might start to submit an in-depth security
>>>> review of consensus changes under pseudonyms, it has already been done in
>>>> the past and somehow it's good practice in terms of "message neutrality"
>>>> [5]. If folks wanna experiment in terms of payment pools deployment, Greg
>>>> Maxwell's old joinpool can be used today (and somehow it's worthy of its
>>>> own as a net advance for coinjoins).
>>>>
>>>> I'll honestly acknowledge towards the community, I might have
>>>> overpromised with the kickstart of this new process aiming to move the
>>>> frontlines in matters of Bitcoin consensus changes development process. On
>>>> the other hand, I think enough sessions of the working group have been
>>>> runned and enough marks of technical interests have been collected to
>>>> demonstrate the minimal value of such a process, so I would estimate my
>>>> open-source balance sheet towards the community to be in good standing ?
>>>> (open-minded question).
>>>>
>>>> I don't think Bitcoin fundamentally lacks compelling technical
>>>> proposals to advance the capabilities of Bitcoin Script today, nor the
>>>> crowd of seasoned and smart protocol developers to evaluate mature
>>>> proposals end-to-end and on multiple dimensions with a spirit of
>>>> independence. Rather, I believe what Bitcoin is lacking is a small crowd of
>>>> technical historians and archivist doing the work of assessing, collecting
>>>> and preserving consensus changes proposals and QA devs to ensure any
>>>> consensus change proposals has world-class battle-ground testing before to
>>>> be considered for deployment, ideally with the best standards of Bitcoin
>>>> decentralization and FOSS neutrality [6].
>>>>
>>>> If you would like to pursue the maintenance and nurturing of the
>>>> Bitcoin Contracting Primitives WG (or the bitcoin-inquisition fork or
>>>> collaborate with Optech to organize industry-wise workshop on covenants at
>>>> the image of what has been done in 2019 for Taproot), that you're willing
>>>> to show proof-of-work and you estimate that operational ground, legal
>>>> information or financial resources will anchor your individual work on the
>>>> long-term, don't hesitate to reach out, I'll see what I can do with a
>>>> disinterested mind [7].
>>>>
>>>> With humility,
>>>> Antoine
>>>>
>>>> [0]
>>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-July/020763.html
>>>> [1]
>>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020233.html
>>>> [2]
>>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020921.html
>>>> [3] https://github.com/bitcoinops/bitcoinops.github.io/pull/806
>>>> [4] Version 0.2 of the CoinPool whitepaper addressing most of the
>>>> remaining "Big Problems" is still pending on my visit to co-author Gleb
>>>> Naumenko in Ukraine, which has been postponed few times in light of the
>>>> conflict operational evolutions.
>>>> [5] See
>>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-February/017614.html.
>>>> For the philosophical reasons of doing so, I invite you to read Foucault's
>>>> famous essay "Le philosophe masque".
>>>> [6] Somehow I come to share Jeremy's thesis's "Product management is
>>>> not "my Job" it's yours" in matters of consensus changes. I believe we
>>>> might be past the technical complexity threshold where even simple
>>>> consensus changes can be conducted from A to Z as a one man job or even by
>>>> a group of 2/3 elite devs.
>>>> [7] I've been reached out multiple times and consistently by R&D
>>>> non-profits, plebs whales and VC firms who were interested to commit
>>>> resources to advance softforks and covenants in the Bitcoin space, no doubt
>>>> when you're reliable and with a track record, folks are ready to offer you
>>>> opportunities to work full-time on consensus changes.
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev at lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230720/5ec20265/attachment-0001.html>;

📅 Original date posted:2023-07-19 🗒️ Summary of this ...

2023-07-20T09:54:05Z

In reply to nevent1q…0anh
_________________________

📅 Original date posted:2023-07-19
🗒️ Summary of this message: The complexity of the Lightning Network (LN) cannot be resolved with covenants alone. More than CTV is needed for significant gains, and there are other BOLTs to consider. Finding interesting primitives and working backwards from there may be a more productive approach. Covenants can contribute to LN's maturity, but the prioritization is unclear.
📝 Original message:
Hello Keagen,

Most of the complexity of LN cannot be resolved with covenants. Of the
things that can be simplified in my experience, you're going to need more
than CTV to get significant gains. And in the end, channels can only get so
simple since we have many other BOLTs to deal with. And even then, you're
going to have to convince LN spec writers to include such changes, whatever
they are, then get deployment.

Step 1 is finding a primitive that seems interesting. It's important to
moderate enthusiasm for any primitive with reality, and probably by being
concrete by writing specs that use a primitive, and code it up to discover
what we're overlooking. We're always overlooking something! In my humble
opinion these are step 2 and 3 of gathering mind-share.

As a more productive tact, if we're thinking beyond 2/small party channels,
probably better to snap your fingers, pretend we have Simplicity, see what
we can build, and work backwards from there to see if we can accomplish
this within the confines of bitcoin script?

Cheers,
Greg

On Wed, Jul 19, 2023 at 3:59 PM Keagan McClelland via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Hi Antoine,
>
> Thank you for the effort you've put towards this. I generally agree that a
> smooth functioning Lightning Network is of greater importance than advanced
> contracting capabilities. However, as I dive deeper into some of the more
> ambitious goals for LN development I am learning that a great deal of
> complexity of some current lightning (LN) proposals can be handily
> discharged with CTV. While I am not intimately familiar with all of the
> other covenant schemes to the same level of technical proficiency, I have a
> suspicion that a number of them, if not all of them, are capable of
> discharging the same flavor and amount of complexity as well. Others should
> chime in if they can confirm this claim.
>
> I have been publicly on the record as supporting the addition of some
> covenant scheme into Bitcoin for some time and have long held on
> theoretical grounds that the addition of such a mechanism is both necessary
> and inevitable if Bitcoin is to survive in the long term. However, as I've
> started to work more directly with the Lightning protocol, these
> theoretical and purely logical arguments became far more concrete and
> immediately beneficial.
>
> I say this primarily to challenge the idea that covenants are a
> distraction from lightning development. It may very well be that your areas
> of focus on LN preclude you from splitting your attention and none of this
> email should be interpreted as a criticism of you applying your efforts in
> the highest leverage manner you can manage. That said, I don't want
> observers of this thread to walk away with the impression that they are two
> independent efforts as covenants can significantly contribute to LN's
> maturity. When and how should they be prioritized? Unfortunately I don't
> feel able to comment on that at this time. All I know is that Lightning
> would almost certainly benefit substantially from having a covenant
> primitive.
>
> Cheers,
> Keags
>
> On Tue, Jul 18, 2023 at 3:40 PM Antoine Riard via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Hi list,
>>
>> Last year amid the failure of the CTV speedy trial activation and intense
>> conversations about a rainbow of covenant proposals, I introduced the idea
>> of a new community process to specify covenants [0]. This post is to resume
>> the experiment so far and officially mark the process maintenance as "up
>> for grabs", as I won't actively pursue it further (after wavering on such a
>> decision a bit during May / June).
>>
>> Few of the goals announced at that time were to build a consistent
>> framework to evaluate covenant proposals, see the common grounds between
>> proposals if they could be composed or combined by their authors, open the
>> consensus changes development process beyond the historical boundaries of
>> Bitcoin Core and maintain high-quality technical archive as a consensus
>> discussions have spawned half a decade from intellectual conception to
>> activation in average (at least for segwit, schnorr, taproot).
>>
>> Such effort was a speak-by-the-act answer to the issues in
>> consensus development changes pointed out by Jeremy Rubin in April of last
>> year [1]: namely the lack of a "codified checklist" for consensus changes,
>> that "consensus is memoryless" and "bitcoin core is not bitcoin"
>> (independently of the technical concerns as I have as limited or
>> non-adequate primitive for vaults / payment pools I expressed during the
>> same time). Other complementary initiatives have been undertaken during the
>> same period, AJ with the bitcoin-inquisition fork where the community of
>> developers and contracting primitives of researchers on a consensus-enabled
>> fork of core [2]. And Dave Harding with the careful archiving of all
>> covenant proposals under the Optech umbrella [3].
>>
>> About the Bitcoin Contracting Primitives WG, a Github repository was
>> started and maintained to archive and document all the primitives (apo,
>> tluv, ctv, the taproot annex, sighash_group, CSFS, cat, txhash, evict,
>> check_output_covenant_verify, inherited ids, anyamount, singletons,
>> op_vault) and the corresponding protocols (payment pools, vaults,
>> drivechains, trust-minimized mining pools payouts). We had a total of 6
>> monthly meetings on the Libera chat #bitcoin-contracting-primitives-wg for
>> a number of more than 20 individual attendees representing most of the
>> parts of the community. I think (missing march logs). Numerous in-depth
>> discussions did happen on the repository and on the channel on things like
>> "merkelized all the things" or "payment pools for miners payoffs".
>>
>> As I've been busy on the Lightning-side and other Bitcoin projects, I've
>> not run an online meeting since the month of April, while still having a
>> bunch of fruitful technical discussions with folks involved in the effort
>> at conferences and elsewhere. I launched the effort as an experiment with
>> the soft commitment to dedicate 20% of my time on it, after few successful
>> sessions I think such a process has an interest of its own, however it
>> comes with direct competition of my time to work on Lightning robustness.
>> Getting my hands dirty on low-level LDK development recently made me
>> realize we still have years of titan work to get a secure and reliable
>> Lightning Network.
>>
>> As such, between extended covenant capabilities for advanced contracts
>> coming as a reality for Bitcoin _or_ LN working smoothly at scale with
>> 50-100M UTXO-sharing users on it during the next 5-7 years cycle, I think
>> the latter goal is more critical for Bitcoin existential survival, and
>> where on a personal title I'll allocate the best of my time and energy (and
>> somehow it match the "slow" technical activity on bitcoin-inquisition
>> mostly done by Lightning hands).
>>
>> This is my personal conclusion only on the state of Bitcoin technological
>> momentum, and this is quite tainted by my deep background in Lightning
>> development. If you've been working on covenant changes proposals, please
>> don't take it as a discouragement, I think Taproot (privacy-preserving
>> script policies behind the taproot tree branches) and Schnorr (for native
>> multi-sig) soft forks have shown how it can improve the building of
>> self-custody solutions by one or two order of magnitude, and small
>> incremental changes might be good enough to have a lower technical
>> consensus bar.
>>
>> On my side, I'll pursue pure R&D works on CoinPool, notably coming with
>> better solutions with the interactivity issue and mass-compression of
>> withdrawal and design exotic advanced Bitcoin contracts based on the
>> taproot annex, though more in a "l'art pour l'art" approach for the time
>> being [4]. Additionally, I might start to submit an in-depth security
>> review of consensus changes under pseudonyms, it has already been done in
>> the past and somehow it's good practice in terms of "message neutrality"
>> [5]. If folks wanna experiment in terms of payment pools deployment, Greg
>> Maxwell's old joinpool can be used today (and somehow it's worthy of its
>> own as a net advance for coinjoins).
>>
>> I'll honestly acknowledge towards the community, I might have
>> overpromised with the kickstart of this new process aiming to move the
>> frontlines in matters of Bitcoin consensus changes development process. On
>> the other hand, I think enough sessions of the working group have been
>> runned and enough marks of technical interests have been collected to
>> demonstrate the minimal value of such a process, so I would estimate my
>> open-source balance sheet towards the community to be in good standing ?
>> (open-minded question).
>>
>> I don't think Bitcoin fundamentally lacks compelling technical proposals
>> to advance the capabilities of Bitcoin Script today, nor the crowd of
>> seasoned and smart protocol developers to evaluate mature proposals
>> end-to-end and on multiple dimensions with a spirit of independence.
>> Rather, I believe what Bitcoin is lacking is a small crowd of technical
>> historians and archivist doing the work of assessing, collecting and
>> preserving consensus changes proposals and QA devs to ensure any consensus
>> change proposals has world-class battle-ground testing before to be
>> considered for deployment, ideally with the best standards of Bitcoin
>> decentralization and FOSS neutrality [6].
>>
>> If you would like to pursue the maintenance and nurturing of the Bitcoin
>> Contracting Primitives WG (or the bitcoin-inquisition fork or collaborate
>> with Optech to organize industry-wise workshop on covenants at the image of
>> what has been done in 2019 for Taproot), that you're willing to show
>> proof-of-work and you estimate that operational ground, legal information
>> or financial resources will anchor your individual work on the long-term,
>> don't hesitate to reach out, I'll see what I can do with a disinterested
>> mind [7].
>>
>> With humility,
>> Antoine
>>
>> [0]
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-July/020763.html
>> [1]
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020233.html
>> [2]
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020921.html
>> [3] https://github.com/bitcoinops/bitcoinops.github.io/pull/806
>> [4] Version 0.2 of the CoinPool whitepaper addressing most of the
>> remaining "Big Problems" is still pending on my visit to co-author Gleb
>> Naumenko in Ukraine, which has been postponed few times in light of the
>> conflict operational evolutions.
>> [5] See
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-February/017614.html.
>> For the philosophical reasons of doing so, I invite you to read Foucault's
>> famous essay "Le philosophe masque".
>> [6] Somehow I come to share Jeremy's thesis's "Product management is not
>> "my Job" it's yours" in matters of consensus changes. I believe we might be
>> past the technical complexity threshold where even simple consensus changes
>> can be conducted from A to Z as a one man job or even by a group of 2/3
>> elite devs.
>> [7] I've been reached out multiple times and consistently by R&D
>> non-profits, plebs whales and VC firms who were interested to commit
>> resources to advance softforks and covenants in the Bitcoin space, no doubt
>> when you're reliable and with a track record, folks are ready to offer you
>> opportunities to work full-time on consensus changes.
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230719/3995d4a3/attachment-0001.html>;

📅 Original date posted:2022-02-10 📝 Original message:One ...

2023-06-07T23:04:08Z

In reply to nevent1q…kmc5
_________________________

📅 Original date posted:2022-02-10
📝 Original message:One quick thought to the proposal and perhaps to sponsors in general(didn't
have time to go over original proposal again):

Since sponsors can come from anywhere, the wallet application must have
access to the mempool to know what inputs must be double spent to RBF the
sponsor transaction.

Seems like an important difference to be considered.

On Fri, Feb 11, 2022 at 3:49 AM James O'Beirne via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> There's been much talk about fee-bumping lately, and for good reason -
> dynamic fee management is going to be a central part of bitcoin use as
> the mempool fills up (lord willing) and right now fee-bumping is
> fraught with difficulty and pinning peril.
>
> Gloria's recent post on the topic[0] was very lucid and highlights a
> lot of the current issues, as well as some proposals to improve the
> situation.
>
> As others have noted, the post was great. But throughout the course
> of reading it and the ensuing discussion, I became troubled by the
> increasing complexity of both the status quo and some of the
> proposed remedies.
>
> Layering on special cases, more carve-outs, and X and Y percentage
> thresholds is going to make reasoning about the mempool harder than it
> already is. Special consideration for "what should be in the next
> block" and/or the caching of block templates seems like an imposing
> dependency, dragging in a bunch of state and infrastructure to a
> question that should be solely limited to mempool feerate aggregates
> and the feerate of the particular txn package a wallet is concerned
> with.
>
> This is bad enough for protocol designers and Core developers, but
> making the situation any more intractable for "end-users" and wallet
> developers feels wrong.
>
> I thought it might be useful to step back and reframe. Here are a few
> aims that are motivated chiefly by the quality of end-user experience,
> constrained to obey incentive compatibility (i.e. miner reward, DoS
> avoidance). Forgive the abstract dalliance for a moment; I'll talk
> through concretes afterwards.
>
>
> # Purely additive feerate bumps should never be impossible
>
> Any user should always be able to add to the incentive to mine any
> transaction in a purely additive way. The countervailing force here
> ends up being spam prevention (a la min-relay-fee) to prevent someone
> from consuming bandwidth and mempool space with a long series of
> infinitesimal fee-bumps.
>
> A fee bump, naturally, should be given the same per-byte consideration
> as a normal Bitcoin transaction in terms of relay and block space,
> although it would be nice to come up with a more succinct
> representation. This leads to another design principle:
>
>
> # The bandwidth and chain space consumed by a fee-bump should be minimal
>
> Instead of prompting a rebroadcast of the original transaction for
> replacement, which contains a lot of data not new to the network, it
> makes more sense to broadcast the "diff" which is the additive
> contribution towards some txn's feerate.
>
> This dovetails with the idea that...
>
>
> # Special transaction structure should not be required to bump fees
>
> In an ideal design, special structural foresight would not be needed
> in order for a txn's feerate to be improved after broadcast.
>
> Anchor outputs specified solely for CPFP, which amount to many bytes of
> wasted chainspace, are a hack. It's probably uncontroversial at this
> point to say that even RBF itself is kind of a hack - a special
> sequence number should not be necessary for post-broadcast contribution
> toward feerate. Not to mention RBF's seemingly wasteful consumption of
> bandwidth due to the rebroadcast of data the network has already seen.
>
> In a sane design, no structural foresight - and certainly no wasted
> bytes in the form of unused anchor outputs - should be needed in order
> to add to a miner's reward for confirming a given transaction.
>
> Planning for fee-bumps explicitly in transaction structure also often
> winds up locking in which keys are required to bump fees, at odds
> with the idea that...
>
>
> # Feerate bumps should be able to come from anywhere
>
> One of the practical downsides of CPFP that I haven't seen discussed in
> this conversation is that it requires the transaction to pre-specify the
> keys needed to sign for fee bumps. This is problematic if you're, for
> example, using a vault structure that makes use of pre-signed
> transactions.
>
> What if the key you specified n the anchor outputs for a bunch of
> pre-signed txns is compromised? What if you'd like to be able to
> dynamically select the wallet that bumps fees? CPFP does you no favors
> here.
>
> There is of course a tension between allowing fee bumps to come from
> anywhere and the threat of pinning-like attacks. So we should venture
> to remove pinning as a possibility, in line with the first design
> principle I discuss.
>
>
> ---
>
> Coming down to earth, the "tabula rasa" thought experiment above has led
> me to favor an approach like the transaction sponsors design that Jeremy
> proposed in a prior discussion back in 2020[1].
>
> Transaction sponsors allow feerates to be bumped after a transaction's
> broadcast, regardless of the structure of the original transaction.
> No rebroadcast (wasted bandwidth) is required for the original txn data.
> No wasted chainspace on only-maybe-used prophylactic anchor outputs.
>
> The interface for end-users is very straightforward: if you want to bump
> fees, specify a transaction that contributes incrementally to package
> feerate for some txid. Simple.
>
> In the original discussion, there were a few main objections that I noted:
>
> 1. In Jeremy's original proposal, only one sponsor txn per txid is
> allowed by policy. A malicious actor could execute a pinning-like
> attack by specifying an only-slightly-helpful feerate sponsor that
> then precludes other larger bumps.
>
> I think there are some ways around this shortcoming. For example: what
> if, by policy, sponsor txns had additional constraints that
>
> - each input must be signed {SIGHASH_SINGLE,SIGHASH_NONE}|ANYONECANPAY,
> - the txn must be specified RBFable,
> - a replacement for the sponsor txn must raise the sponsor feerate,
> including ancestors (maybe this is inherent in "is RBFable," but
> I don't want to conflate absolute feerates into this).
>
> That way, there is still at most a single sponsor txn per txid in the
> mempool, but anyone can "mix in" inputs which bump the effective
> feerate of the sponsor.
>
> This may not be the exact solution we want, but I think it demonstrates
> that the sponsors design has some flexibility and merits some thinking.
>
> The second objection about sponsors was
>
> 2. (from Suhas) sponsors break the classic invariant: "once a valid
> transaction is created, it should not become invalid later on unless
> the inputs are double-spent."
>
> This doesn't seem like a huge concern to me if you consider the txid
> being sponsored as a sort of spiritual input to the sponsor. While the
> theoretical objection against broadening where one has to look in a txn
> to determine its dependencies is understandable, I don't see what the
> practical cost here is.
>
> Reorg complexity seems comparable if not identical, especially if we
> broaden sponsor rules to allow blocks to contain sponsor txns that are
> both for txids in the same block _or_ already included in the chain.
>
> This theoretical concession seems preferable to heaping more rules onto
> an already labyrinthine mempool policy that is difficult for both
> implementers and users to reason about practically and conceptually.
>
> A third objection that wasn't posed, IIRC, but almost certainly would
> be:
>
> 3. Transaction sponsors requires a soft-fork.
>
> Soft-forks are no fun, but I'll tell you what also isn't fun: being on
> the hook to model (and sometimes implement) a dizzying potpourri of
> mempool policies and special-cases. Expecting wallet implementers to
> abide by a maze of rules faithfully in order to ensure txn broadcast and
> fee management invites bugs for perpetuity and network behavior that is
> difficult to reason about a priori. Use of CPFP in the long-term also
> risks needless chain waste.
>
> If a soft-fork is the cost of cleaning up this essential process,
> consideration should be given to paying it as a one-time cost. This
> topic merits a separate post, but consider that in the 5 years leading
> up to the 2017 SegWit drama, we averaged about a soft-fork a year.
> Uncontroversial, "safe" changes to the consensus protocol shouldn't be
> out of the question when significant practical benefit is plain to see.
>
> ---
>
> I hope this message has added some framing to the discussion on fees,
> as well prompting other participants to go back and give the
> transaction sponsor proposal a serious look. The sponsors interface is
> about the simplest I can imagine for wallets, and it seems easy to
> reason about for implementers on Core and elsewhere.
>
> I'm not out to propose soft-forks lightly, but the current complexity
> in fee management feels untenable, and as evidenced by all the
> discussion lately, fees are an increasingly crucial part of the system.
>
>
>
> [0]:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019817.html
> [1]:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220211/c1c03c95/attachment.html>;

📅 Original date posted:2018-06-21 📝 Original ...

2023-06-07T18:13:08Z

In reply to nevent1q…hzq9
_________________________

📅 Original date posted:2018-06-21
📝 Original message:>Hmm, upon further reflection, maybe it's not even worth including *any*
per-output data, aside from what the original transaction contains.

>The output redeem script is either:
- unknown, because we have received only an address from the receiver
- or it is known, because it is ours and in that case it doesn’t make
sense to include it in PSBT

Signers are an extremely heterogeneous bunch. A signer may need to
introspect on the script, such as "this is a 2-of-3,
and I'm one of the keys". Even in basic p2pkh settings not adding any
output information rules out things like change
detection on any conceivable hardware wallet, or even simple software
wallets that don't carry significant state.

On Thu, Jun 21, 2018 at 10:35 AM Tomas Susanka via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Hello,
>
> First of all, let me thank you for all the hard work you and others have
> put into this.
>
>
> On 21.6.2018 02:39, Achow101 via bitcoin-dev wrote:
> > While I agree that the BIP itself should be revised to reflect these
> suggestions, I fear that it may be too late. I know of a few other
> developers who have implemented BIP 174 already but have not yet responded
> to this email.
>
> We do realize that this discussion should have happened earlier, however
> agreeing on a good standard should be the number one priority for all
> the parties involved.
>
> The fact that someone already implemented this is indeed unfortunate,
> but I don't think we should lower our demands on the standard just
> because of a bad timing.
>
> >> A question to consider is,
> >> will there be more per-output data? If yes, it might make sense to have
> >> an output section.
> > I think it is unlikely that there would be anymore per-output data.
>
> Hmm, upon further reflection, maybe it's not even worth including *any*
> per-output data, aside from what the original transaction contains.
>
> The output redeem script is either:
> - unknown, because we have received only an address from the receiver
> - or it is known, because it is ours and in that case it doesn’t make
> sense to include it in PSBT
>
> We got stuck on the idea of the Creator providing future (output)
> redeem/witness scripts. But that seems to be a minority use case and can
> be solved efficiently via the same channels that coordinate the PSBT
> creation. Sorry to change opinions so quickly on this one.
>
> >
> >> 3) The sighash type 0x03 says the sighash is only a recommendation. That
> >> seems rather ambiguous. If the field is specified shouldn't it be
> binding?
> > I disagree. It is up to the signer to decide what they wish to sign, not
> for the creator to specify what to sign. The creator can ask the signer to
> sign something in a particular way, but it is ultimately up to the signer
> to decide.
>
> This seems very ambiguous. The Signer always has the option of not
> signing. *What* to sign is a matter of coordination between the parties;
> otherwise, you could make all the fields advisory and let anyone sign
> anything they like?
>
> We don't understand the usecase for a field that is advisory but not
> binding. On what basis would you choose to respect or disregard the
> advisory field? Either one party has a preference, in which case they
> have to coordinate with the other anyway - or they don't, in which case
> they simply leave the field out.
>
> > Size is not really a constraint, but we do not want to be unnecessarily
> large. The PSBT still has to be transmitted to other people. It will likely
> be used by copy and pasting the string into a text box. Copying and pasting
> very long strings of text can be annoying and cumbersome. So the goal is to
> keep the format still relatively clear while avoiding the duplication of
> data.
>
> I agree. Just to put some numbers on this: if we expect a 5-part
> derivation path, and add the master key fingerprint, that is 4 + 5*4 =
> 24 bytes (~32 base64 letters) per input and signer. I'd argue this is
> not significant.
> If we used full xpub, per Pieter's suggestion, that would grow to 32 +
> 32 + 5*4 = 84 bytes (~112 letters) per input/signer, which is quite a lot.
>
> On the other hand, keeping the BIP32 paths per-input means that we don't
> need to include the public key (as in the lookup key), so that's 32
> bytes down per path. In general, all the keys can be fully reconstructed
> from their values:
>
> redeem script key = hash160(value)
> witness script key = sha256(value)
> bip32 key = derive(value)
>
> The one exception is a partial signature. But even in that case we
> expect that a given public key will always correspond to the same
> signature, so we can act as if the public key is not part of the "key".
> In other words, we can move the public key to the value part of the record.
>
> This holds true unless there's some non-deterministic signing scheme,
> *and* multiple Signers sign with the same public key, which is what
> Pieter was alluding to on Twitter
> (https://twitter.com/pwuille/status/1002627925110185984). Still, I would
> argue (as he also suggested) that keeping the format more complex to
> support this particular use case is probably not worth it.
>
> Also, we can mostly ignore deduplication of witness/redeem scripts.
> These still need to be included in the resulting transaction, duplicated
> if necessary, so I think counting their repetition against the size of
> PSBT isn't worth it.
>
>
> Best,
> Tomas
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180621/b752efa0/attachment.html>;