Nostr notes by

📅 Original date posted:2023-05-11 🗒️ Summary of this ...

2023-06-19T19:42:08+02:00

In reply to nevent1q…f8rq
_________________________

📅 Original date posted:2023-05-11
🗒️ Summary of this message: A developer expresses the importance of freedom of expression, presumption of innocence, and due process in the Bitcoin community, and vows to fight for these values.
📝 Original message:
Hi Antoine,

> I can say missing an open-source engineering meeting or being revoked a few Github permissions matters far less than the clear affirmation and respect of the freedom of expression, the presumption of innocence and due process in the Bitcoin common space, all proportions conserved.

This is not acceptable. I will fight with you. Never feel alone.

/devfd0
floppy disk guy

Sent with [Proton Mail](https://proton.me/) secure email.

------- Original Message -------
On Wednesday, May 10th, 2023 at 10:27 PM, Antoine Riard <antoine.riard at gmail.com> wrote:

> Hi Tony,
>
>> Is there a better place to havepubliccommunication? Unfortunately since one off topic email was sent here, it's been a ghost town. It appears that there's many emails being held and only one moderator that checks them once a week.
>
> As I think you're referring to my post of March 21th and as the author of this post, I'll politely refuse the qualification of "off-topic". I had and I still have the concerns of "frivolous legal claims" being used between bitcoin developers/organizations provoking a distortion of the neutrality of the development and a chilling effect of the technical discussions (i.e code we compile and spec we implement). For those reasons, it was my legal right and moral duty to inform the community of what is happening between Chaincode and myself. And here I'm following the recommendation of one of the moderators of the Lightning mailing list himself "If this worries you too, let's make sure we keep each other honest, OK?" [0].
>
> When you think a group of people with open-source responsibilities are in a situation of conflict of interests or "moral hazards", or even the appearance of them, you have the right to expose the wrongdoing, including the _proportional_ revelation of private elements. People have done the "free choice" to conduct a career in open-source, for some even declaring in some context to maintain integrity and accept their actions to be submitted to external accountability [1]. While the exposure of private elements of public personalities might break common courtesy, it's a morally valid practice if you're familiar with the public institutions of US and Europe, and I think this practice has found validity in the history of open-source commons or IETF's protocol development [1].
>
> Beyond, the Bitcoin and Lightning development communication channels constitute a public forum, where by nature the participants are exchanging ideas and defending competing interests. In consequence, the participants' rights and capabilities to contribute and speak their minds in those communication channels should be protected. Those communication channels are not your usual corporate workplace, and in case of conflicting principles, the maintainers of those communication channels should ensure a balance of rights and a proportionality in any restraining measure.
>
> And this new post is not to exonerate myself of any legal responsibility for personal matters that could be recognized as the outcome of a judicial process, respective of both rights of the accusation and rights of the defense. Rather to enlighten the Bitcoin community that the formal separation between private matters and open-source responsibilities, and the adequate check-and-balances to guarantee this separation is somehow what are the underlying stakes for this feud between Chaincode and myself, from my perspective. I can say missing an open-source engineering meeting or being revoked a few Github permissions matters far less than the clear affirmation and respect of the freedom of expression, the presumption of innocence and due process in the Bitcoin common space, all proportions conserved.
>
> I don't blame any party involved in this issue, nor assign "bad intentions''. One position is really a function of your life experiences, knowledge of the legal and cultural framework and access to the factual elements. As all human conflicts it is not binary rather "grey". People can be top executives at a billion-dollar company, having successful ventures with hundreds of folks under management, or have a lot of responsibilities for their relative young age, and still disagree on the set of legal and moral principles to apply in the present case.
>
> Finally, thanks to the Bitcoin friends who have reached out to call for level-headedness and cool-mindness in the public discussion of this complex topic. Like I said to them, in the lack of more suspected wrongdoing from the other side, I won't communicate further on this subject on the Bitcoin and Lightning technical channels. However I still firmly believe the discussion on the principles, abstract in the maximum from its private elements, should still be pursued on other channels. Independently, there is a legal channel opened between Chaincode and myself and good progress is made to find a serene and long-standing resolution to this issue.
>
> Best,
> Antoine
>
> [0] https://rusty-lightning.medium.com/the-corrosion-of-ethics-in-cryptocurrencies-f7ba77e9dfc3
> [1] https://github.com/btrustteam/board-book/blob/main/vision/genesis_principles.md
> [2] https://www.ietf.org/about/administration/policies-procedures/conflict-interest/
>
> Le lun. 8 mai 2023 à 21:26, Tony Giorgio via Lightning-dev <lightning-dev at lists.linuxfoundation.org> a écrit :
>
>> Is there a better place to have public communication? Unfortunately since one off topic email was sent here, it's been a ghost town. It appears that there's many emails being held and only one moderator that checks them once a week.
>>
>> Would hate to see this list die but wondering if there's a better place for discussions?
>>
>> Tony
>>
>> -------- Original Message --------
>> On Apr 29, 2023, 9:57 PM, niftynei < niftynei at gmail.com> wrote:
>>
>>> Hi all,
>>>
>>> When I joined the lightning community a few years ago, I was relatively new to open source software and specification work. Rusty really impressed on me on the importance of holding conversations, as much as possible in public.
>>>
>>> Practically speaking, this encompasses IRC, this mailing list, and github issues/PRs.
>>>
>>> The reason for this is twofold. It helps document the range of options considered for technical decisions and it provides an interface point for new participants to contribute to the discussion.
>>>
>>> Given some recent mails that were posted to this list, now seems like a good time to reiterate the importance and preference of public communication whenever possible, especially for specification or technical discussions.
>>>
>>> ~ nifty
>>>
>>> _______________________________________________
>>> Lightning-dev mailing list
>>> Lightning-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230511/a2cad51d/attachment.html>;

📅 Original date posted:2023-06-12 🗒️ Summary of this ...

2023-06-15T02:54:55+02:00

In reply to nevent1q…9fwz
_________________________

📅 Original date posted:2023-06-12
🗒️ Summary of this message: The email discusses a proof of concept for using nostr npub and relays for payjoin, but there are concerns about the use of SIGHASH_NONE and security issues.
📝 Original message:
Hi Symphonic,

> I'm a bit confused as to what exactly this is a proof of concept for.

This is a proof of concept for using nostr npub and relays for payjoin.

> Your use of SIGHASH_NONE does in fact make it possible for the reciever to do whatever they want with your funds (which I see you acknowledge in your brief description, but still, not very practical).

SIGHASH_NONE can be used when there is no change in the transaction and sender wants to spend whole UTXO for the payment. Recipient is free to decide the outputs and extra input for the transaction.

> However, it is also possible for anyone who sees the final broadcasted transaction to extract the sender's input and use it for any purpose they wish; game theoretically miners would just steal your funds, but it's possible for any user to RBF and send those funds wherever they like.

- Based on my understanding of SIGHASH flags and a [blog post][0] by Raghav Sood, use of SIGHASH_ALL by recipient will secure all outputs. However I have realized it is still vulnerable in a [tweet thread][1] as you mentioned. While writing this email, poll was still 50-50 so I guess its a learning thing. We have less docs about SIGHASH flags, maybe an e-book with all experiments would improve this.
- Since this was just a PoC to use nostr, use of specific SIGHASH flags can be ignored and developers can use other flags or default. I will improve/change it as well. I wanted to use SIGHASH_NONE to improve privacy and less UX issues.
- There are no incentives for sender or recipient to use RBF and double spend in a payjoin transaction.

[0]: https://raghavsood.com/blog/2018/06/10/bitcoin-signature-types-sighash
[1]: https://twitter.com/1440000bytes/status/1668261886884708352

/dev/fd0
flopyy disk guy

Sent with Proton Mail secure email.

------- Original Message -------
On Sunday, June 11th, 2023 at 8:02 AM, symphonicbtc <symphonicbtc at proton.me> wrote:

> Hey alicexbt,
> I'm a bit confused as to what exactly this is a proof of concept for. Your use of SIGHASH_NONE does in fact make it possible for the reciever to do whatever they want with your funds (which I see you acknowledge in your brief description, but still, not very practical). However, it is also possible for anyone who sees the final broadcasted transaction to extract the sender's input and use it for any purpose they wish; game theoretically miners would just steal your funds, but it's possible for any user to RBF and send those funds wherever they like.
>
> As is the case with any work-in-progress software, but especially in this instance, I urge you to disable the ability to use mainnet coins directly in your code. This is highly irresponsible to post in this state.
>
> Moreover, a bit redundantly considering the glaring and severe security issues, this is not a proper implemenation of a payjoin, even in a theoretical scenario, as it is trivial to discern which inputs belong to the sender and reciever respectively in the final transaction.
>
> Symphonic
>
>
> Sent with Proton Mail secure email.

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

2023-06-15T02:54:55+02:00

In reply to nevent1q…6jj0
_________________________

📅 Original date posted:2023-06-10
🗒️ Summary of this message: A proof of concept for a payjoin (p2ep) proposal that doesn't require a personal server has been shared, but adoption is uncertain without common nostr relays.
📝 Original message:
Hello Bitcoin Developers,

Since I learnt about payjoin(p2ep), there was always discussion of it not being adopted because of need for sever. This proposal needs no personal sever however I am doubtful it still gets any adoption.

Note: Even stowaway (used by samourai) uses servers in fact two: soroban.samouraiwallet.com and paynym.is

I am sharing a proof of concept that does not need any server however there need to be some common nostr relays between sender and recipient:

Repository: https://gitlab.com/1440000bytes/postr
Demo Video: https://www.youtube.com/watch?v=O5qbexzO37c

/dev/fd0
floppy disk guy

Sent with [Proton Mail](https://proton.me/) secure email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230610/ee10872c/attachment.html>;

📅 Original date posted:2022-06-08 📝 Original message: Hi ...

2023-06-09T15:06:11+02:00

In reply to nevent1q…jqjm
_________________________

📅 Original date posted:2022-06-08
📝 Original message:
Hi Tony,

> The reason this is possible is because probing is a free operation on the Lightning Network after a channel is opened, the error reasons given are way too verbose, and currently channel IDs are based on UTXO's. Scid aliases may be the biggest benefit here, but the use of `unknown_next_peer` , `invalid_onion_hmac`, `incorrect_cltv_expiry`, and `amount_below_minimum` have been the biggest helpers in exploiting channel privacy.

Can this be fixed by making error messages less verbose or reveal less information?

> We should definitely migrate to alias scid's, and encourage every active unannounced channel holder to close, coinjoin, and reopen with an alias. But care should be given in the future when it comes to error reasons revealing information that is meant to be "private". Until this migration happens, it would be beneficial to stop being so specific about errors, this does not really seem to help end users anyways.

Alias SCID would be better for privacy as they allow a node to request a channel by a random value instead of value derived from the on-chain transaction. Are alias SCIDs necessary to fix it or error messages alone can fix it?

I found these pull requests and assuming alias SCID are already implemented in LDK/rust-lightning:

[https://github.com/lightningdevkit/rust-lightning/pull/1311/](https://github.com/lightningdevkit/rust-lightning/pull/1311/commits)
https://github.com/lightningdevkit/rust-lightning/pull/1351

> I'll be continuing with this probing project while the problem exists, and work on narrowing down the other channel partner and fixing efficiency bugs. I am publicizing the results as I go, so fair warning that if you have any unannounced channels that you assumed were private and need them to be, close them now on the off chance they get revealed. This could have always been happening already already by analytic firms, so I hope by publicizing this we are all on the same playing field. It is also beneficial to get a better estimate of the unknown size of the Lightning Network.

I love the research and thanks for sharing all the information. I am assuming analytic firms would be using this already.

/dev/fd0

Sent with [Proton Mail](https://proton.me/) secure email.

------- Original Message -------
On Wednesday, June 8th, 2022 at 7:35 AM, Tony Giorgio via Lightning-dev <lightning-dev at lists.linuxfoundation.org> wrote:

> Hi,
>
> For the past few months I have been working on an LDK probing project that searches for unannounced channels on the Lightning Network. For the past week, I have been probing on mainnet and squashing bugs / making optimizations.
>
> So far I have found near 445 unannounced channels totaling 1,076,077,750 satoshi's locked across the 3 nodes I have probed, some with just a minimized set (~30,000) of probable channels based on "round payment amount" and "1 or 2 tx output" heuristics on P2WSH UTXO's. Most of them being on Aincq's node found with the minimized set, I've yet to run the complete set with them. There are about ~860,000 P2WSH UTXO's, about ~60,000 of which are public, so the upward limit of possible private channels is around ~800,000.
>
> The exact results are publicized here: https://github.com/BitcoinDevShop/hidden-lightning-network/blob/master/data/results/results.json
>
> The reason this is possible is because probing is a free operation on the Lightning Network after a channel is opened, the error reasons given are way too verbose, and currently channel IDs are based on UTXO's. Scid aliases may be the biggest benefit here, but the use of `unknown_next_peer` , `invalid_onion_hmac`, `incorrect_cltv_expiry`, and `amount_below_minimum` have been the biggest helpers in exploiting channel privacy.
>
> By creating a probe guessing the Channel ID based on unspent p2wsh transactions, it's a `m * n` problem to probe the entire network, where `m` is utxos and `n` is nodes. Without these errors and instead something like `temporary_channel_failure` or a generic indistinguishable error, guessing a Channel ID would come down to an upwards of `m * n * n-1 * ~2000`, which would be each utxo with each pairing of nodes, each with about ~2000 cltv's to guess (numbers are as low as 7 to as high as ~2000). I threw the extra 2000 into the equation because even with `800,000 * 1 * 2000`, it gets much more time consuming to even probe a single node when we're already spending upwards of a day or so for near 1 million or 2 probes. Concurrent probing is possible, but starts to require more locked up liquidity.
>
> We should definitely migrate to alias scid's, and encourage every active unannounced channel holder to close, coinjoin, and reopen with an alias. But care should be given in the future when it comes to error reasons revealing information that is meant to be "private". Until this migration happens, it would be beneficial to stop being so specific about errors, this does not really seem to help end users anyways.
>
> I'll be continuing with this probing project while the problem exists, and work on narrowing down the other channel partner and fixing efficiency bugs. I am publicizing the results as I go, so fair warning that if you have any unannounced channels that you assumed were private and need them to be, close them now on the off chance they get revealed. This could have always been happening already already by analytic firms, so I hope by publicizing this we are all on the same playing field. It is also beneficial to get a better estimate of the unknown size of the Lightning Network.
>
> For more about this project and viewing the dataset, go to http://hiddenlightningnetwork.com
>
> Thanks,
> Tony
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220608/55e9f88f/attachment.html>;

📅 Original date posted:2023-05-08 🗒️ Summary of this ...

2023-06-08T01:21:42+02:00

In reply to nevent1q…un6m
_________________________

📅 Original date posted:2023-05-08
🗒️ Summary of this message: A vulnerability in Bitcoin Core was reported publicly on GitHub, but the author suggests it should have been reported privately as a potential security issue.
📝 Original message:Hi Bitcoin Developers,

There is an open issue in bitcoin core repository which was created last week: https://github.com/bitcoin/bitcoin/issues/27586

I think this should have been reported privately as vulnerability instead of creating a GitHub issue even if it worked only in debug mode. Some users in the comments have also experienced similar issues without debug build used for bitcoind. I have not noticed any decline in the number of listening nodes on bitnodes.io in last 24 hours so I am assuming this is not an issue with majority of bitcoin core nodes. However, things could have been worse and there is nothing wrong in reporting something privately if there is even 1% possibility of it being a vulnerability. I had recently reported something to LND security team based on a closed issue on GitHub which eventually was not considered a vulnerability: https://github.com/lightningnetwork/lnd/issues/7449

In the CPU usage issue, maybe the users can run bitcoind with bigger mempool or try other things shared in the issue by everyone.

This isn't the first time either when vulnerability was reported publicly: https://gist.github.com/chjj/4ff628f3a0d42823a90edf47340f0db9 and this was even exploited on mainnet which affected some projects.

This email is just a request to consider the impact of any vulnerability if gets exploited could affect lot of things. Even the projects with no financial activity involved follow better practices.

/dev/fd0
floppy disk guy

Sent with [Proton Mail](https://proton.me/) secure email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230509/c664f3f5/attachment-0001.html>;

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

2023-06-08T01:20:38+02:00

In reply to nevent1q…7xsz
_________________________

📅 Original date posted:2023-04-19
🗒️ Summary of this message: A message suggests creating a competition for Brink, funding Bitcoin developers, and acknowledging knowledgeable reviewers. Disrespecting new people and being bossy is discouraged.
📝 Original message:Hi Michael,

I will share something even though you didn't let me write things on several occasions on github, twitter etc.

Try this:

- As Gloria said (respect people you don't like and shared something against), create a competition for Brink. Fund bitcoin developers.
- Do more reviews personally and devs you train even if they are neglected.
- Acknowledge some reviewer know more than you. Try to learn and test things.
- After some time you will achieve the power you crave.

Its not possible to satisfy everyone even if you were bitcoin core maintainer now, some people would have issues. Closing a pull request hurt more so I respect them if they kept open something.

Note: Do not disrespect people who are new and say something. Do not try to harass them. Do not try to be boss.

/dev/fd0
floppy disk guy

Sent with Proton Mail secure email.

------- Original Message -------
On Wednesday, April 19th, 2023 at 7:03 PM, Michael Folkson <michaelfolkson at protonmail.com> wrote:

> Hi alicexbt
>
> > I don't think commentary is required for each pull request that gets merged with enough reviews, ACKs and no controversy.
>
>
> The problem is defining what is "enough". "Enough" is determined by the quality of the review, the expertise of the reviewer(s), the complexity of the pull request and most importantly what risks a merge of the pull request poses. When there is zero communication on merge decisions (both merging and not merging over a long period of time) it creates frustration and worse vacuums and soft fork activation chaos. It is a complete black box. The vast majority of merge decisions are uncontroversial but it would still be nice to have a comment saying something like:
>
> "This pull request only has 2 ACKs but it is low risk, relatively simple and is unlikely to be reviewed by anybody else in the near term"
>
> "This pull request is a consensus change, extremely high risk and is unlikely to be merged in the near term"
>
> On the rare occasions when merge decisions are controversial communication becomes a lot more important. If some maintainers aren't responsive on IRC and refuse to discuss merge decisions what can we expect in future? We wake up one day, a contentious consensus change has been merged with little review in advance of a release window and the maintainer won't discuss why they have merged it. This isn't a toy anymore, it is supporting hundreds of billions of dollars of value and could end up supporting a lot more. It is surely completely unreasonable to let maintainers merge or not merge whatever they like with no explanation and no willingness to discuss their merge decisions.
>
> > So I'll add that if you wish to have more decentralization in Bitcoin Core funding, you can start by creating a nonprofit, gathering donations, and funding somebody who works on Bitcoin Core."
>
>
> As I responded on the pull request if any long term contributor from this alternative nonprofit is blocked from being a maintainer and current maintainers refuse to discuss merge decisions it is irrelevant. To contribute you need a maintainer to merge your pull request(s) and to spend your review time wisely you need to know what pull request(s) could viably be merged by a maintainer. Otherwise you're just wasting your time. We not only have opacity on merge decisions for normal pull requests (e.g. code) we also now have opacity on decisions for the addition of new maintainers. I was always under the impression that any long term contributor who demonstrated over time that they were sufficiently competent, qualified and able to contribute both through opening pull requests and reviewing other people's pull requests could become a maintainer. To me and many others (until it was blocked by two maintainers for 5 months) Vasil met this criteria. This not only impacts Vasil's and others' commitment to the project but it impacts what pull requests are ultimately reviewed and merged. What is the point of spending time opening or reviewing a pull request if the current maintainers won't look at it or are unqualified to review it and hence won't merge it?
>
> Gloria's advice effectively boils down to spend months setting up a non-profit, spend years becoming a long term contributor to the project and then you can have the honor of being blocked from becoming a maintainer and have your contributions stunted by the current maintainers with no recourse or ability to discuss their merge decisions. So yeah thanks for repeating that advice but I'm sure most would rather pass and do something else.
>
> Thanks
> Michael
>
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>
>
> ------- Original Message -------
> On Wednesday, April 19th, 2023 at 13:24, alicexbt alicexbt at protonmail.com wrote:
>
>
>
> > Hi Michael,
> >
> > I was initially sad about the politics in Vasil's pull request, written about it and also tried to document the process. Still think he deserves to be a maintainer. Although I have some counter arguments:
> >
> > > Maintainers merge a pull request and provide no commentary on why they’ve merged it.
> >
> > I don't think commentary is required for each pull request that gets merged with enough reviews, ACKs and no controversy.
> >
> > > Maintainers leave a pull request with many ACKs and few (if any) NACKs for months and provide no commentary on why they haven't merged it
> >
> > This could be considered normal in pull requests that involve code changes.
> >
> > > The difference between say previous maintainers like Wladimir and some of the current maintainers is that previous maintainers were extremely responsive on IRC.
> >
> > Unfair to expect every human to behave the same or work similarly. Sometimes the unresponsiveness could be to avoid controversies and heated debates that go off-topic.
> >
> > > One farcical recent example 0 was the pull request to add Vasil Dimov as a maintainer where despite many ACKs from other maintainers and other long term contributors two maintainers (fanquake and Gloria) refused to discuss it on the pull request or on IRC. It took almost 5 months for Gloria to comment on the pull request despite many requests from me on the PR and on IRC. I even requested that they attend the weekly Core Dev IRC meeting to discuss it which they didn’t attend.
> >
> > - Maintainers should be free to avoid involvement in a pull request. As long as a subset of maintainers have an opinion on the pull request, things should be fine.
> > - I agree with Gloria's comment: "I had not NACKed this either because my opinion could change over time, NACKs are sometimes needlessly interpreted as personal attacks, and Brink has been antagonized on Twitter each time multiple grantees have similar opinions about this. So I'll add that if you wish to have more decentralization in Bitcoin Core funding, you can start by creating a nonprofit, gathering donations, and funding somebody who works on Bitcoin Core." Last part of this comment also solves the problem shared in other thread related to new bitcoin implementation. Brink needs some competition and bitcoin core needs more reviewers.
> > - I also agree with Andrew's comment: "frankly, I think opinions aren't being shared because of potential backlash from aggressive users such as yourself and bytes1440000"
> >
> > > Maintainers and long term contributors (if they commented at all) were gently enthusiastic (Concept ACKing etc) without ACKing that it was ready to merge. A long term observer of the Core repo would have known that it wasn’t ready to merge or ready to attempt to activate (especially given it was a consensus change) but a casual observer would have only seen Concept ACKs and ACKs with 3 stray NACKs. Many of these casual observers inflated the numbers on the utxos.org site 4 signalling support for a soft fork activation attempt.
> >
> > - I don't see anything wrong with sharing honest opinion if someone agrees with the concept. It does not make a pull request ready to get merged.
> > - utxos.org is an external site maintained by Jeremy with opinions on BIP 119. Everyone is free to maintain such lists and I think you had also created one as GitHub gist.
> >
> > > I will probably write about bitcoin-inquisition/default signet in a future email as I do think the perception that it is “the one and only” staging ground for consensus changes is dangerous 6 if the maintainer(s) on that project have the same inclinations as a subset of the Core maintainers.
> >
> > This perception (if exists) can be killed by creating a custom signet, maintaining it differently, get more reviews, testing and share details with community regularly.
> >
> > /dev/fd0
> > floppy disk guy
> >
> > 0: https://github.com/bitcoin/bitcoin/pull/25871#issuecomment-1381654564
> > 1: https://bitcoin-irc.chaincode.com/bitcoin-core-dev/2023-01-12#883748
> >
> > Sent with Proton Mail secure email.
> >
> > ------- Original Message -------
> > On Tuesday, April 18th, 2023 at 6:10 PM, Michael Folkson via bitcoin-dev bitcoin-dev at lists.linuxfoundation.org wrote:
> >
> > > Communication has been a challenge on Bitcoin Core for what I can tell the entire history of the project. Maintainers merge a pull request and provide no commentary on why they’ve merged it. Maintainers leave a pull request with many ACKs and few (if any) NACKs for months and provide no commentary on why they haven't merged it. I can only speculate on why and it probably depends on the individual maintainer. Sometimes it will be poor communication skills, sometimes it will be a desire to avoid accountability, sometimes it will be fear of unreasonable and spiteful legal action if they mistakenly merge a pull request that ends up containing a bug. But search through the pull requests on Bitcoin Core and you will rarely see a rationale for a merge decision. The difference between say previous maintainers like Wladimir and some of the current maintainers is that previous maintainers were extremely responsive on IRC. If you disagreed with a merge decision or thought it had been merged prematurely they would be happy to discuss it on IRC. In present times at least a subset of the current maintainers are not responsive on IRC and will refuse to discuss a merge decision. One farcical recent example 0 was the pull request to add Vasil Dimov as a maintainer where despite many ACKs from other maintainers and other long term contributors two maintainers (fanquake and Gloria) refused to discuss it on the pull request or on IRC. It took almost 5 months for Gloria to comment on the pull request despite many requests from me on the PR and on IRC. I even requested that they attend the weekly Core Dev IRC meeting to discuss it which they didn’t attend.
> > >
> > > A pull request to add a maintainer isn’t a normal pull request. Generally pull requests contain a lot more lines of code than a single line adding a trusted key. Not merging a pull request for a long period of time can be extremely frustrating for a pull request author especially when maintainers and long term contributors don’t comment on the pull request and the pull request is stuck in “rebase hell”. Clearly it is the lesser evil when compared to merging a harmful or bug ridden pull request but poor non-existent communication is not the only way to prevent this. Indeed it creates as many problems as it solves.
> > >
> > > Another farcical recent(ish) example was the CTV pull request 1 that ultimately led to a contentious soft fork activation attempt that was called off at the last minute. If you look at the comments on the pull request there were 3 individuals (including myself) who NACKed the pull request and I think it is fair to say that none of us would be considered long term contributors to Bitcoin Core. I have criticised Jeremy Rubin multiple times for continuing to pursue a soft fork activation attempt when it was clear it was contentious 3 but if you look at the pull request comments it certainly isn’t clear it was. Maintainers and long term contributors (if they commented at all) were gently enthusiastic (Concept ACKing etc) without ACKing that it was ready to merge. A long term observer of the Core repo would have known that it wasn’t ready to merge or ready to attempt to activate (especially given it was a consensus change) but a casual observer would have only seen Concept ACKs and ACKs with 3 stray NACKs. Many of these casual observers inflated the numbers on the utxos.org site 4 signalling support for a soft fork activation attempt.
> > >
> > > I set out originally to write about the controls and processes around merges on the default signet (bitcoin-inquisition 5) but it quickly became obvious to me that if communication around Core merges/non-merges is this weak you can hardly expect it to be any better on bitcoin-inquisition/default signet where there is no real monetary value at stake. I will probably write about bitcoin-inquisition/default signet in a future email as I do think the perception that it is “the one and only” staging ground for consensus changes is dangerous 6 if the maintainer(s) on that project have the same inclinations as a subset of the Core maintainers.
> > >
> > > As I stated at the beginning there is an element to this which is not individual(s) specific and an adverse reaction to outright malicious actors external to any of these projects. I do not think any of the current maintainers on Core or bitcoin-inquisition are outright malicious even if a subset of them consistently frustrate me with their lack of transparency and accountability. But this issue isn't going away and I'm sure we'll hear more on this from others in the coming months. To me it is a straight choice of taking transparency and accountability much more seriously or failing that investing more heavily (time and resources) in consensus compatible forks of Core and treating Core like it is a proprietary "open source" project where merge decisions are not explained or justified in the open.
> > >
> > > --
> > > Michael Folkson
> > > Email: michaelfolkson at protonmail.com
> > > Keybase: michaelfolkson
> > > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3

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

2023-06-08T01:20:36+02:00

In reply to nevent1q…gj7y
_________________________

📅 Original date posted:2023-04-19
🗒️ Summary of this message: A debate over the role of maintainers in Bitcoin Core has arisen, with some arguing for more responsiveness and commentary on pull requests. One recent example involved a pull request to add Vasil Dimov as a maintainer, which was met with resistance from some maintainers. However, others argue that maintainers should be free to avoid involvement in certain pull requests and that commentary is not always necessary. The discussion also touched on the issue of decentralization in Bitcoin Core funding and the need for more reviewers.
📝 Original message:Hi Michael,

I was initially sad about the politics in Vasil's pull request, written about it and also tried to document the process. Still think he deserves to be a maintainer. Although I have some counter arguments:

> Maintainers merge a pull request and provide no commentary on why they’ve merged it.

I don't think commentary is required for each pull request that gets merged with enough reviews, ACKs and no controversy.

> Maintainers leave a pull request with many ACKs and few (if any) NACKs for months and provide no commentary on why they haven't merged it

This could be considered normal in pull requests that involve code changes.

> The difference between say previous maintainers like Wladimir and some of the current maintainers is that previous maintainers were extremely responsive on IRC.

Unfair to expect every human to behave the same or work similarly. Sometimes the unresponsiveness could be to avoid controversies and heated debates that go off-topic.

> One farcical recent example [0] was the pull request to add Vasil Dimov as a maintainer where despite many ACKs from other maintainers and other long term contributors two maintainers (fanquake and Gloria) refused to discuss it on the pull request or on IRC. It took almost 5 months for Gloria to comment on the pull request despite many requests from me on the PR and on IRC. I even requested that they attend the weekly Core Dev IRC meeting to discuss it which they didn’t attend.

- Maintainers should be free to avoid involvement in a pull request. As long as a subset of maintainers have an opinion on the pull request, things should be fine.
- I agree with Gloria's [comment][0]: "I had not NACKed this either because my opinion could change over time, NACKs are sometimes needlessly interpreted as personal attacks, and Brink has been antagonized on Twitter each time multiple grantees have similar opinions about this. So I'll add that if you wish to have more decentralization in Bitcoin Core funding, you can start by creating a nonprofit, gathering donations, and funding somebody who works on Bitcoin Core." Last part of this comment also solves the problem shared in other thread related to new bitcoin implementation. Brink needs some competition and bitcoin core needs more reviewers.
- I also agree with Andrew's [comment][1]: "frankly, I think opinions aren't being shared because of potential backlash from aggressive users such as yourself and bytes1440000"

> Maintainers and long term contributors (if they commented at all) were gently enthusiastic (Concept ACKing etc) without ACKing that it was ready to merge. A long term observer of the Core repo would have known that it wasn’t ready to merge or ready to attempt to activate (especially given it was a consensus change) but a casual observer would have only seen Concept ACKs and ACKs with 3 stray NACKs. Many of these casual observers inflated the numbers on the utxos.org site [4] signalling support for a soft fork activation attempt.

- I don't see anything wrong with sharing honest opinion if someone agrees with the concept. It does not make a pull request ready to get merged.
- utxos.org is an external site maintained by Jeremy with opinions on BIP 119. Everyone is free to maintain such lists and I think you had also created one as GitHub gist.

> I will probably write about bitcoin-inquisition/default signet in a future email as I do think the perception that it is “the one and only” staging ground for consensus changes is dangerous [6] if the maintainer(s) on that project have the same inclinations as a subset of the Core maintainers.

This perception (if exists) can be killed by creating a custom signet, maintaining it differently, get more reviews, testing and share details with community regularly.

/dev/fd0
floppy disk guy

[0]: https://github.com/bitcoin/bitcoin/pull/25871#issuecomment-1381654564
[1]: https://bitcoin-irc.chaincode.com/bitcoin-core-dev/2023-01-12#883748

Sent with Proton Mail secure email.

------- Original Message -------
On Tuesday, April 18th, 2023 at 6:10 PM, Michael Folkson via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:

> Communication has been a challenge on Bitcoin Core for what I can tell the entire history of the project. Maintainers merge a pull request and provide no commentary on why they’ve merged it. Maintainers leave a pull request with many ACKs and few (if any) NACKs for months and provide no commentary on why they haven't merged it. I can only speculate on why and it probably depends on the individual maintainer. Sometimes it will be poor communication skills, sometimes it will be a desire to avoid accountability, sometimes it will be fear of unreasonable and spiteful legal action if they mistakenly merge a pull request that ends up containing a bug. But search through the pull requests on Bitcoin Core and you will rarely see a rationale for a merge decision. The difference between say previous maintainers like Wladimir and some of the current maintainers is that previous maintainers were extremely responsive on IRC. If you disagreed with a merge decision or thought it had been merged prematurely they would be happy to discuss it on IRC. In present times at least a subset of the current maintainers are not responsive on IRC and will refuse to discuss a merge decision. One farcical recent example [0] was the pull request to add Vasil Dimov as a maintainer where despite many ACKs from other maintainers and other long term contributors two maintainers (fanquake and Gloria) refused to discuss it on the pull request or on IRC. It took almost 5 months for Gloria to comment on the pull request despite many requests from me on the PR and on IRC. I even requested that they attend the weekly Core Dev IRC meeting to discuss it which they didn’t attend.
>
>
>
> A pull request to add a maintainer isn’t a normal pull request. Generally pull requests contain a lot more lines of code than a single line adding a trusted key. Not merging a pull request for a long period of time can be extremely frustrating for a pull request author especially when maintainers and long term contributors don’t comment on the pull request and the pull request is stuck in “rebase hell”. Clearly it is the lesser evil when compared to merging a harmful or bug ridden pull request but poor non-existent communication is not the only way to prevent this. Indeed it creates as many problems as it solves.
>
>
>
> Another farcical recent(ish) example was the CTV pull request [1] that ultimately led to a contentious soft fork activation attempt that was called off at the last minute. If you look at the comments on the pull request there were 3 individuals (including myself) who NACKed the pull request and I think it is fair to say that none of us would be considered long term contributors to Bitcoin Core. I have criticised Jeremy Rubin multiple times for continuing to pursue a soft fork activation attempt when it was clear it was contentious [3] but if you look at the pull request comments it certainly isn’t clear it was. Maintainers and long term contributors (if they commented at all) were gently enthusiastic (Concept ACKing etc) without ACKing that it was ready to merge. A long term observer of the Core repo would have known that it wasn’t ready to merge or ready to attempt to activate (especially given it was a consensus change) but a casual observer would have only seen Concept ACKs and ACKs with 3 stray NACKs. Many of these casual observers inflated the numbers on the utxos.org site [4] signalling support for a soft fork activation attempt.
>
>
>
> I set out originally to write about the controls and processes around merges on the default signet (bitcoin-inquisition [5]) but it quickly became obvious to me that if communication around Core merges/non-merges is this weak you can hardly expect it to be any better on bitcoin-inquisition/default signet where there is no real monetary value at stake. I will probably write about bitcoin-inquisition/default signet in a future email as I do think the perception that it is “the one and only” staging ground for consensus changes is dangerous [6] if the maintainer(s) on that project have the same inclinations as a subset of the Core maintainers.
>
>
>
> As I stated at the beginning there is an element to this which is not individual(s) specific and an adverse reaction to outright malicious actors external to any of these projects. I do not think any of the current maintainers on Core or bitcoin-inquisition are outright malicious even if a subset of them consistently frustrate me with their lack of transparency and accountability. But this issue isn't going away and I'm sure we'll hear more on this from others in the coming months. To me it is a straight choice of taking transparency and accountability much more seriously or failing that investing more heavily (time and resources) in consensus compatible forks of Core and treating Core like it is a proprietary "open source" project where merge decisions are not explained or justified in the open.
>
>
>
> [0]: https://github.com/bitcoin/bitcoin/pull/25871
>
> [1]: https://github.com/bitcoin/bitcoin/pull/21702
>
> [2]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020386.html
>
> [3]: https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718
>
> [4]: https://utxos.org/signals/
>
> [5]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020921.html
>
> [6]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020948.html
>
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3

📅 Original date posted:2023-03-02 🗒️ Summary of this ...

2023-06-08T01:20:17+02:00

In reply to nevent1q…trts
_________________________

📅 Original date posted:2023-03-02
🗒️ Summary of this message: A new BIP proposes using PSBTs for trust-minimized swaps of inscriptions in Bitcoin. The process involves creating and signing a PSBT, publishing it as an offer, and updating it with appropriate inputs and outputs. The use of SINGLE|ANYONECANPAY is recommended, and the order of inputs and outputs is crucial to avoid burning inscriptions. The BIP was authored by /dev/fd0 and is currently in draft status.
📝 Original message:Hi Bitcoin Developers,

I have written a BIP that describes the process to swap inscriptions however there can be other use cases for it as well: https://gist.github.com/1440000bytes/a7deeb3f1740bc533a61fbcc1fe58d77

Feel free to share your opinion or feedback to improve the usage of PSBTs in swaps.

BIP: 2023-ordswap
Layer: Applications
Title: Trust minimized swaps using PSBTs
Author: /dev/fd0
Status: Draft
Created: 2023-03-02
License: Public Domain

### Introduction

This BIP describes a process for creating offers using PSBTs to swap inscriptions. It was originally shared by [Casey](https://github.com/casey/ord/issues/802). There are two other approaches (`joinpsbts` and coinswap) to swap inscriptions however they degrade the UX and use of SINGLE|ANYONECANPAY works better.

### Specification

[SINGLE|ANYONECANPAY](https://en.bitcoin.it/wiki/Contract#SIGHASH_flags) is used for creating a PSBT by the seller. It is signed and published as offer. Buyer updates the PSBT with appropriate inputs and outputs. Order of inputs and outputs in the PSBT is very important as wrong ordering can burn inscriptions. [Ordinal theory](https://docs.ordinals.com/faq.html?#how-does-ordinal-theory-work) uses an algorithm to determine how satoshis hop from the inputs of a transaction to its outputs.

### Protocol

Sequence diagram:

```mermaid
sequenceDiagram
Note right of Seller: Create and Sign PSBT
Seller->>+Nostr relays: Publish offer
Buyer->>+Nostr relays: Accept offer
Note left of Buyer: Add inputs, outputs, sign and broadcast PSBT
```

Seller:

- Create PSBT with inscription UTXO input and a new address with sell amount as output
- Sign PSBT
- Publish PSBT as defined in [NIP](https://github.com/orenyomtov/openordex/blob/main/NIP.md)

Buyer:

- Add new address as output in PSBT to receive inscription
- Create [dummy UTXO]( ) if not available in wallet (Less than 1000 sats)
- Add UTXO to pay seller and dummy UTXO as inputs in PSBT
- Sign and broadcast transaction.

Example tx: https://mempool.space/signet/tx/ee7032f08ed18113c16ab8759d294c09f57492d8d255b5dbd16326df53bbdcac

This transaction has 3 inputs (dummy, inscription, UTXO used for paying seller) and 4 outputs (inscription, payment, new dummy for future, change)

Note: Openordex creates a dummy UTXO and reuses address if there is no dummy UTXO found for the address entered by buyer. Example: https://mempool.space/signet/tx/388942887f79358a1deba3aae86e97b982a923566b2ef2249eab42288efc5abf

Pseudocode or Implementation (2 functions used by openordex for creating PSBTs)

```js

async function generatePSBTListingInscriptionForSale(ordinalOutput, price, paymentAddress) {
let psbt = new bitcoin.Psbt({ network });

const [ordinalUtxoTxId, ordinalUtxoVout] = ordinalOutput.split(':')
const tx = bitcoin.Transaction.fromHex(await getTxHexById(ordinalUtxoTxId))
for (const output in tx.outs) {
try { tx.setWitness(output, []) } catch { }
}

psbt.addInput({
hash: ordinalUtxoTxId,
index: parseInt(ordinalUtxoVout),
nonWitnessUtxo: tx.toBuffer(),
// witnessUtxo: tx.outs[ordinalUtxoVout],
sighashType: bitcoin.Transaction.SIGHASH_SINGLE | bitcoin.Transaction.SIGHASH_ANYONECANPAY,
});

psbt.addOutput({
address: paymentAddress,
value: price,
});

return psbt.toBase64();
}

```

```js

generatePSBTBuyingInscription = async (payerAddress, receiverAddress, price, paymentUtxos, dummyUtxo) => {
const psbt = new bitcoin.Psbt({ network });
let totalValue = 0
let totalPaymentValue = 0

// Add dummy utxo input
const tx = bitcoin.Transaction.fromHex(await getTxHexById(dummyUtxo.txid))
for (const output in tx.outs) {
try { tx.setWitness(output, []) } catch { }
}
psbt.addInput({
hash: dummyUtxo.txid,
index: dummyUtxo.vout,
nonWitnessUtxo: tx.toBuffer(),
// witnessUtxo: tx.outs[dummyUtxo.vout],
});

// Add inscription output
psbt.addOutput({
address: receiverAddress,
value: dummyUtxo.value + Number(inscription['output value']),
});

// Add payer signed input
psbt.addInput({
...sellerSignedPsbt.data.globalMap.unsignedTx.tx.ins[0],
...sellerSignedPsbt.data.inputs[0]
})
// Add payer output
psbt.addOutput({
...sellerSignedPsbt.data.globalMap.unsignedTx.tx.outs[0],
})

// Add payment utxo inputs
for (const utxo of paymentUtxos) {
const tx = bitcoin.Transaction.fromHex(await getTxHexById(utxo.txid))
for (const output in tx.outs) {
try { tx.setWitness(output, []) } catch { }
}

psbt.addInput({
hash: utxo.txid,
index: utxo.vout,
nonWitnessUtxo: tx.toBuffer(),
// witnessUtxo: tx.outs[utxo.vout],
});

totalValue += utxo.value
totalPaymentValue += utxo.value
}

// Create a new dummy utxo output for the next purchase
psbt.addOutput({
address: payerAddress,
value: dummyUtxoValue,
})

const fee = calculateFee(psbt.txInputs.length, psbt.txOutputs.length, await recommendedFeeRate)

const changeValue = totalValue - dummyUtxo.value - price - fee

if (changeValue < 0) {
throw `Your wallet address doesn't have enough funds to buy this inscription.
Price: ${satToBtc(price)} BTC
Fees: ${satToBtc(fee + dummyUtxoValue)} BTC
You have: ${satToBtc(totalPaymentValue)} BTC
Required: ${satToBtc(totalValue - changeValue)} BTC
Missing: ${satToBtc(-changeValue)} BTC`
}

// Change utxo
psbt.addOutput({
address: payerAddress,
value: changeValue,
});

return psbt.toBase64();
}

```

Note: Openordex reuses address for change, however this can be avoided.

### Acknowledgements

- Casey Rodarmor
- Oren Yomtov
- Rijndael

/dev/fd0
floppy disk guy

Sent with Proton Mail secure email.

📅 Original date posted:2023-03-29 🗒️ Summary of this ...

2023-06-08T01:20:04+02:00

In reply to nevent1q…m3tw
_________________________

📅 Original date posted:2023-03-29
🗒️ Summary of this message: A developer shares the achievements of parasitical use cases of Bitcoin, including increased fees, more users, and developers exploring new features. They advocate for respecting different perspectives to avoid becoming niche like Linux.
📝 Original message:Hi Zac,

Let me share what those parasites achieved:

- Fees paid: 150 BTC
- Lot of users and developers trying bitcoin that either never tried or gave up early in 2013-15
- Mempools of nodes of being busy on weekends and got lots of transactions
- PSBT became cool and application devs are trying their best to use it in different ways
- Some developers exploring taproot and multisig
- AJ shared things how covenants could help in fair, non-custodial, on-chain auction of ordinals that is MEV resistant although I had shared it earlier which involves more steps: https://twitter.com/1440000bytes/status/1634368411760476161
- Investors exploring about funding projects
- Bitcoin more than Bitcoin and people excited about it

We can have difference of opinion, however I want bitcoin to be money and money means different things for people in this world. Please respect that else it will become like Linux, something used by 1% of world.

/dev/fd0
floppy disk guy

Sent with Proton Mail secure email.

------- Original Message -------
On Wednesday, March 29th, 2023 at 12:40 PM, Zac Greenwood via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:

> I’m not sure why any effort should be spent on theorizing how new opcodes might be used to facilitate parasitical use cases of the blockchain.
>
> If anything, business models relying on the ability to abuse the blockchain as a data store must be made less feasible, not more.
>
> Zac
>
>
> On Fri, 24 Mar 2023 at 20:10, Anthony Towns via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> > On Tue, Mar 07, 2023 at 10:45:34PM +1000, Anthony Towns via bitcoin-dev wrote:
> > > I think there are perhaps four opcodes that are interesting in this class:
> > >
> > > idx sPK OP_FORWARD_TARGET
> > > -- sends the value to a particular output (given by idx), and
> > > requires that output have a particular scriptPubKey (given
> > > by sPK).
> > >
> > > idx [...] n script OP_FORWARD_LEAF_UPDATE
> > > -- sends the value to a particular output (given by idx), and
> > > requires that output to have almost the same scriptPubKey as this
> > > input, _except_ that the current leaf is replaced by "script",
> > > with that script prefixed by "n" pushes (of values given by [...])
> > >
> > > idx OP_FORWARD_SELF
> > > -- sends the value to a particular output (given by idx), and
> > > requires that output to have the same scriptPubKey as this input
> > >
> > > amt OP_FORWARD_PARTIAL
> > > -- modifies the next OP_FORWARD_* opcode to only affect "amt",
> > > rather than the entire balance. opcodes after that affect the
> > > remaining balance, after "amt" has been subtracted. if "amt" is
> > > 0, the next OP_FORWARD_* becomes a no-op.
> >
> > The BIP 345 draft has been updated [0] [1] and now pretty much defines
> > OP_VAULT to have the behaviour specced for OP_FORWARD_LEAF_UPDATE above,
> > and OP_VAULT_RECOVER to behave as OP_FORWARD_TARGET above. Despite
> > that, for this email I'm going to continue using the OP_FORWARD_*
> > naming convention.
> >
> > Given the recent controversy over the Yuga labs ordinal auction [2],
> > perhaps it's interesting to consider that these proposed opcodes come
> > close to making it possible to do a fair, non-custodial, on-chain auction
> > of ordinals [3].
> >
> > The idea here is that you create a utxo on chain that contains the ordinal
> > in question, which commits to the address of the current leading bidder,
> > and can be spent in two ways:
> >
> > 1) it can be updated to a new bidder, if the bid is raised by at least
> > K satoshis, in which case the previous bidder is refunded their
> > bid; or,
> >
> > 2) if there have been no new bids for a day, the current high bidder
> > wins, and the ordinal is moved to their address, while the funds
> > from their winning bid are sent to the original vendor's address.
> >
> > I believe this can be implemented in script as follows,
> > assuming the opcodes OP_FORWARD_TARGET(OP_VAULT_RECOVER),
> > OP_FORWARD_LEAF_UPDATE(OP_VAULT), OP_FORWARD_PARTIAL (as specced above),
> > and OP_PUSHCURRENTINPUTINDEX (as implemented in liquid/elements [4])
> > are all available.
> >
> > First, figure out the parameters:
> >
> > * Set VENDOR to the scriptPubKey corresponding to the vendor's address.
> > * Set K to the minimum bid increment [5].
> > * Initially, set X equal to VENDOR.
> > * Initially, set V to just below the reserve price (V+K is the
> > minimum initial bid).
> >
> > Then construct the following script:
> >
> > [X] [V] [SSS] TOALT TOALT TOALT
> > 0 PUSHCURRENTINPUTINDEX EQUALVERIFY
> > DEPTH NOT IF
> > 0 10000 FORWARD_PARTIAL
> > 0 FROMALT FORWARD_TARGET
> > 1 [VENDOR] FWD_TARGET
> > 144
> > ELSE
> > FROMALT SWAP TUCK FROMALT
> > [K] ADD GREATERTHANOREQUAL VERIFY
> > 1 SWAP FORWARD_TARGET
> > DUP FORWARD_PARTIAL
> > 0 ROT ROT
> > FROMALT DUP 3 SWAP FORWARD_LEAF_UPDATE
> > 0
> > ENDIF
> > CSV
> > 1ADD
> >
> > where "SSS" is a pushdata of the rest of the script ("TOALT TOALT TOALT
> > .. 1ADD").
> >
> > Finally, make that script the sole tapleaf, accompanied by a NUMS point
> > as the internal public key, calculate the taproot address corresponding
> > to that, and send the ordinal to that address as the first satoshi.
> >
> > There are two ways to spend that script. With an empty witness stack,
> > the following will be executed:
> >
> > [X] [V] [SSS] TOALT TOALT TOALT
> > -- altstack now contains [SSS V X]
> > 0 PUSHCURRENTINPUTINDEX EQUALVERIFY
> > -- this input is the first, so the ordinal will move to the first
> > output
> > DEPTH NOT IF
> > -- take this branch: the auction is over!
> > 1 [VENDOR] FWD_TARGET
> > -- output 1 gets the entire value of this input, and pays to
> > the vendor's hardcoded scriptPubKey
> > 0 10000 FORWARD_PARTIAL
> > 0 FROMALT FORWARD_TARGET
> > -- we forward at least 10k sats to output 0 (if there were 0 sats,
> > the ordinal would end up in output 1 instead, which would be a
> > bug), and output 0 pays to scriptPubKey "X"
> > 144
> > ELSE .. ENDIF
> > -- skip over the other branch
> > CSV
> > -- check that this input has baked for 144 blocks (~1 day)
> > 1ADD
> > -- leave 145 on the stack, which is true. success!
> >
> > Alternatively, if you want to increase the bid you provide a stack with
> > two items: your scriptPubKey and the new bid [X' V']. Execution this
> > time looks like:
> >
> > [X] [V] [SSS] TOALT TOALT TOALT
> > -- stack contains [X' V'], altstack now contains [SSS V X]
> > 0 PUSHCURRENTINPUTINDEX EQUALVERIFY
> > -- this input is the first, so the ordinal will move to the first
> > output
> > DEPTH NOT IF ... ELSE
> > -- skip over the other branch (without violating minimalif rules)
> > FROMALT SWAP TUCK FROMALT
> > -- stack contains [X' V' X V' V], altstack contains [SSS]
> > [K] ADD GREATERTHANOREQUAL VERIFY
> > -- check V' >= V+K, stack contains [X' V' X]
> > 1 SWAP FORWARD_TARGET
> > -- output 1 pays to X (previous bidder's scriptPubKey), and the
> > entire value of this input goes there; stack contains [X' V']
> > DUP FORWARD_PARTIAL
> > -- execute "V' FORWARD_PARTIAL", stack contains [X' V']
> > 0 ROT ROT
> > -- stack contains [0 X' V']
> > FROMALT DUP 3 SWAP FORWARD_LEAF_UPDATE
> > -- execute "0 X' V' SSS 3 SSS FORWARD_LEAF_UPDATE" which checks
> > that output 0 spends at least V' satoshis back to the same
> > script (because that's how we defined SSS), except the first
> > three pushes (previously X V SSS) are replaced by X' V' SSS.
> > 0
> > ENDIF
> > CSV
> > -- "0 CSV" requires nSequnce to be set, which makes the tx rbf'able,
> > which hopefully makes it harder to pin
> > 1ADD
> > -- ends with 1 on the stack; success!
> >
> > (The "SSS n SSS FORWARD_LEAF_UPDATE" construct is more or less a quine,
> > ie a program that outputs its own source code)
> >
> > I think that script is about 211 witness bytes, with an additional 40
> > witness bytes for X'/V', so when making a bid, your tx would be
> > something like:
> >
> > tx header, 10vb
> > input 0: 103vb for the old bid including witness and control block
> > input 1: 58vb for a taproot key path spend
> > output 0: 43vb for the new bid
> > output 1: 43vb for your change
> >
> > for a total of about 257vb -- slightly larger than a regular 2-in-2-out
> > transaction, but not terribly much. Mostly because input 0 doesn't require
> > a signature -- it's size is effectively 6 pubkeys: X, X' VENDOR twice,
> > and the script code twice, along with a little extra to encode the
> > various numbers (10000, 144, K, V, V').
> >
> > This approach seems pretty "MEV" resistant: you pay fees via input 1 if
> > your bid succeeds; if it doesn't, you don't pay any fees. A potential
> > scalper might want to put in an early low ball bid, then prevent
> > higher bidders from winning the auction, take control of the ordinal,
> > and resell it later, but unless they can prevent another miner from
> > mining alternative bids for 144 blocks, they will fail at that. The bid
> > is fixed by the bidder and committed to by the signature on input 1, so
> > frontrunning a bid can't do anything beyond invalidate the bid entirely.
> >
> > Obviously, this is a pretty limited auction mechanism in various ways;
> > eg maybe you'd rather specify K as a percentage than an absoute increment;
> > maybe you'd like to have the auction definitely finish by some particular
> > time; maybe you'd like to be able to have the auction be able to continue
> > above 21.47 BTC (2**31 sats); maybe you'd like to do a dutch auction
> > rather than an english auction. I think you can probably do all those
> > things with this set of opcodes and clever scripting, though it probably
> > gets ugly.
> >
> > I don't think this is easily extensible to taro or rgb style assets,
> > as rather than being able to ensure the asset is transferred by
> > controlling the input/output positions, I think you'd need to build
> > up merkle trees and do point tweaks beyond what's supported by
> > OP_FORWARD_LEAF_UPDATE/OP_VAULT. Of course, without something like
> > OP_PUSHCURRENTINPUTINDEX I don't think you could do it for ordinals
> > either.
> >
> > Cheers,
> > aj
> >
> > [0] https://github.com/bitcoin/bips/blob/7f747fba82675f28c239df690a07b75529bd0960/bip-0345.mediawiki
> >
> > [1] https://twitter.com/jamesob/status/1639019107432513537
> >
> > [2] https://cointelegraph.com/news/scammers-dream-yuga-s-auction-model-for-bitcoin-nfts-sees-criticism
> >
> > [3] Inscriptions remain a wasteful way of publishing/committing
> > to content, however!
> >
> > [4] https://github.com/ElementsProject/elements/blob/master/doc/tapscript_opcodes.md
> >
> > [5] Setting K too low probably invites griefing, where a bidder may be
> > able to use rbf pinning vectors to prevent people who would be willing
> > to bid substantially higher from getting their bid confirmed on
> > chain.
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

📅 Original date posted:2023-02-13 🗒️ Summary of this ...

2023-06-08T01:19:34+02:00

In reply to nevent1q…24fw
_________________________

📅 Original date posted:2023-02-13
🗒️ Summary of this message: Bitcoin developers discuss the potential for censorship of transactions and the need for tools to test censorship resistance, including an external mempool.
📝 Original message:Hi Bitcoin Developers,

There is a famous quote attributed to Evelyn Beatrice Hall in her biography of Voltaire: "I disapprove of what you say, but I will defend to the death your right to say it." I'm curious to know how many Bitcoin developers share this sentiment.

Recently there was a lot of enthusiasm on social media to run bitcoin core with a [patch][0] that would reject some transactions in mempool. Bitcoin Knots already has an option to reject transactions that reuse addresses. What if such practices become common and some projects that provide easy to use node software start censoring transactions? How would government agencies take advantage of this whole drama?

I understand it is difficult to censor different type of transaction because there will be some nodes relaying them and miners including in blocks. It is still important to discuss this and different ways to test censorship resistance.

- Peter Todd had written a [blog post][1] in which counting number of INVs (step 5,6,7 and 8) helps in testing if your transactions are getting relayed by the connected peers.
- I had tried broadcasting transaction to specific nodes using [libbtc][2]. Based on my understanding it uses GETDATA to confirm your transaction was seen on other nodes after broadcasting.

What would an ideal tool for testing censorship resistance look like?

- Allows user to construct different types of transactions that might be considered "bad" by some people. Example: OFAC address in output, Inscription, OP_RETURN, Address reuse etc.
- Option to broadcast transaction to specific nodes
- Verify if the transaction was relayed successfully or rejected
- Ban such peers using [setban][3] RPC as it would increase the probability of tx getting propagated to miners

There was even some discussion about an [external mempool][4] that could be used for non-standard transactions. It could also help in avoiding censorship in some cases. I welcome your thoughts and feedback on this topic.

[0]: https://gist.github.com/luke-jr/4c022839584020444915c84bdd825831
[1]: https://petertodd.org/2022/bitcoin-core-nodes-running-fullrbf
[2]: https://twitter.com/1440000bytes/status/1574225052240777216
[3]: https://bitcoincore.org/en/doc/24.0.0/rpc/network/setban/
[4]: https://twitter.com/jamesob/status/1623827708168863747

/dev/fd0
floppy disc guy

Sent with Proton Mail secure email.

📅 Original date posted:2022-11-20 📝 Original message:Hi ...

2023-06-08T01:17:04+02:00

In reply to nevent1q…92gv
_________________________

📅 Original date posted:2022-11-20
📝 Original message:Hi Bitcoin Developers,

I have setup a [custom signet][0] for testing full RBF. You can connect to one or more of these nodes using `addnode`:

13.115.34.55 (issuer, full-rbf)
kfupbqwb2yvzzqjomfq5pkem553a6uzp2k73seqn4d46smy7azua.b32.i2p (rbf-optin)
luvczzzppiqnc2b7poivkxlugafe3uqaj245ebjqxtceio7poaorqcyd.onion (full-rbf)

Example config:

```
signet=1
signetchallenge=5121035daaa313aada6310340a242af17238cc1fd8849e875940bce65a60ac7e0e0ff751ae
proxy=127.0.0.1:9050

[signet]
addnode=luvczzzppiqnc2b7poivkxlugafe3uqaj245ebjqxtceio7poaorqcyd.onion

mempoolfullrbf=1
```

Example for a simple test case:

- Run 2 nodes
- Connect node 1 with i2p node and use default opt-in rbf
- Connect node 2 with node 1 and onion node. This node should use `mempoolfullrbf=1` in config and compile bitcoind using PR [#26454][1] branch
- Broadcast Tx1 using node 2 and replace with Tx2 using `bumpfee` RPC

It will be fun to test with more nodes joining this custom signet. If anyone interested to test, please post your bitcoin address in [full-rbf room][2]. We can even setup an explorer if this experiment makes sense.

[0]: https://en.bitcoin.it/wiki/Signet#Custom_Signet
[1]: https://github.com/bitcoin/bitcoin/pull/26454
[2]: #full-rbf:matrix.org

Sent with Proton Mail secure email.

/dev/fd0

📅 Original date posted:2022-10-12 📝 Original message:Hi ...

2023-06-08T01:15:10+02:00

In reply to nevent1q…0xg5
_________________________

📅 Original date posted:2022-10-12
📝 Original message:Hi Bitcoin Developers,

I did some research about nLocktime and nVersion used by some open source Bitcoin wallets. I have written a [blog post][0] co-authored with 'nothingmuch' and this is the first post for the privacy focused blog 'consent':

Most wallets use nVersion 2. nLocktime for Bitcoin Core, Knots, Electrum, Sparrow and Specter is nearest block height. However, nLocktime for Bitcoin Core/Knots is zero by default if the transaction is created manually using RPC commands like createpsbt or createrawtransaction. Peter Todd had implemented nLocktime based on anti-fee sniping in [#2340][1] and [#24128][2] implements BIP 326 sequence based anti-fee-snipe for taproot inputs.
'0xb10c' has written about wallet [fingerprinting with fee rate][3]. However, nLocktime and nVersion are also important. There may be other factors that might help if a fingerprint matches more than one wallet. Andrew Chow has build a [tool][4] to check if a transaction was created using Bitcoin Core or Electrum.

### Why is wallet fingerprinting important?

Consider the following scenario: Alice is spying on Bob and Carol. She suspects one of them is participating in an activity based on a transaction, but she cannot confirm it. She recognizes that one of the wallets that claims to improve privacy was used for these transactions and examines the nVersion and nLocktime. This makes it simpler to identify Bob, who used Wasabi wallet for the transaction with version 1 and nLocktime 0.

### How to fix it?

If more wallets have the same nVersion and nLocktime, it will be difficult to identify the wallets used for a transaction. nLocktime could be any nearest block height however version needs to be 2 as most of the wallets use it and it is used for transactions that follow new consensus rules.

Please let me know if something incorrect is mentioned or anything important missing about wallet fingerprinting with nLocktime and nVersion.

### Acknowledgements

- achow101
- 0xb10c
- nothingmuch- RedGrittyBrick

[0]: https://consentonchain.github.io/blog/posts/fingerprinting/
[1]: https://github.com/bitcoin/bitcoin/pull/2340
[2]: https://github.com/bitcoin/bitcoin/pull/24128
[3]: https://b10c.me/observations/03-blockchaincom-recommendations/
[4]: https://github.com/achow101/wallet-fingerprinting

/dev/fd0

Sent with [Proton Mail](https://proton.me/) secure email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221012/8205a831/attachment-0001.html>;

📅 Original date posted:2022-10-13 📝 Original message:Hi ...

2023-06-08T01:14:29+02:00

In reply to nevent1q…6ge3
_________________________

📅 Original date posted:2022-10-13
📝 Original message:Hi cndm1,

> Bitrefill already supports lightning, so for them it would be easy to
> solve by displaying the lightning transfer by default and only show
> the on-chain payment as a fallback. Currently the on-chain payment at
> Bitrefill and other similar providers is really a drop-down where you
> select your wallet and then they display a tutorial to you on how to
> create the on-chain transaction (fee rate, RBF flag, etc). I don't
> have insights into Bitrefill, but one might suspect that encouraging a
> lightning payment might be a win-win situation for them and their
> users.

Lightning is only used for 4% payments compared to 32% on-chain payments according to a [tweet][1] from Jan 2022 by Sergej Kotliar and stats are similar based on the slides shared in a [presentation][2] in Pizza Day Prague 2022.

By EUR:

onchain - 30%
lightning - 5%

By unique users:

onchain - 40%
lightning - 9%

> Relay of fullrbf transactions works reasonable well
> already, unless you get unlucky with your selected peers. The only
> missing piece is a few percent of hashrate that will accept fullrbf
> replacement transactions.

I don't believe relay of fullrbf transactions works well right now. The missing piece you mentioned is important and a real need for all full node users to try fullrbf.

> While this will certainly happen if a
> Bitcoin Core release ships with the flag on by default, it still may
> happen at any time even if Bitcoin Core doesn't ship with the flag at
> all.

Changing default at this moment does not make sense as v24.0 could give some insights about usage of fullrbf and we could wait for a few months before changing default for users that run latest version of bitcoin core.

I will quote Antoine Riard's comment from PR [#25353][3]:

"_I know I've advocated in the past to turn RBF support by default in the past. Though after gathering a lot of feedbacks, this approach of offering the policy flexiblity to the interested users only and favoring a full-rbf gradual deployment sounds better to me. As a follow-up, if we add p2p logic to connect to few "full-rbf" service-bit signaling peers and recommend to the ~17000 LN nodes operators, likely (hopefully!) running bitcoind as a backend, that should be okay to guarantee a good propagation to miners (and yes reaching out to few mining pools ops to explain the income increase brought by full-rbf). Unless we observe a significant impact on compact blocks reconstruction, personally I'm really fine waiting another multi-years development cycle before to propose a default change, or even let opt-in forever the default as it is._"

"_Once again, the proposed change is only targeting educated users aiming to deploy full RBF for their application specific needs. If the majority of Bitcoin users is not interested, that's okay. It's a policy rule, not a consensus one._"

Although Antoine has opened another [pull request][4] to make fullrbf default a few hours ago, so I am not sure what is the new motivation or discussion that I am missing.

[1]: https://twitter.com/ziggamon/status/1481307334068641795
[2]: https://youtu.be/bkjEcSmZKfc?t=463
[3]: https://github.com/bitcoin/bitcoin/pull/25353
[4]: https://github.com/bitcoin/bitcoin/pull/26305

/dev/fd0

Sent with Proton Mail secure email.

------- Original Message -------
On Thursday, October 13th, 2022 at 9:37 PM, linuxfoundation.cndm1--- via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:

> > - Bitrefill's on-chain payments for gift cards and phone top-ups
>
>
> Bitrefill already supports lightning, so for them it would be easy to
> solve by displaying the lightning transfer by default and only show
> the on-chain payment as a fallback. Currently the on-chain payment at
> Bitrefill and other similar providers is really a drop-down where you
> select your wallet and then they display a tutorial to you on how to
> create the on-chain transaction (fee rate, RBF flag, etc). I don't
> have insights into Bitrefill, but one might suspect that encouraging a
> lightning payment might be a win-win situation for them and their
> users.
>
> It would be interesting to know if there are any obstacles that
> Bitrefill and other services face, or if they don't agree that
> lightning is an improvement over accepting unconfirmed on-chain
> transactions from untrusted parties.
>
> > - Many bitcoin ATMs' on-chain deposits for selling bitcoin for cash (at least
>
>
> I haven't tried them yet, but I suspect they could benefit in a
> similar by showing lightning transfers more prominently. Moreover, any
> UX improvement they can offer to users that intentionally or
> accidentally selected RBF opt-in, will also benefit users once fullrbf
> is widespread. To give an example, ATMs could immediately give out a
> voucher for the cash amount that can be redeemed as soon as the
> transaction is confirmed on-chain, to allow (untrusted) users to leave
> the ATM and go for a walk in the meantime.
>
> > With full-RBF, wallets should make it extremely clear to users that unconfirmed
> > funds are not theirs (yet). Otherwise, protocol-unaware users that are
> > transacting on-chain with untrusted parties can be easily scammed if they don't
> > know they have to wait for a confirmation. Eg. in Argentina, it's pretty common
> > to meet someone in person to buy bitcoin P2P for cash, even for newcomers.
>
>
> This is easy to solve, because a wallet can simply display all
> unconfirmed transactions as if they signalled for RBF. Your suggested
> solution to "activate" fullrbf at a specific block height might be
> counter productive, because educating users that unconfirmed
> transactions are unsafe takes longer than a single block. So the
> earlier users are educated that unconfirmed transactions from
> untrusted parties are unsafe, the better.
>
> > # Impact at Muun
> >
> > Work to transition Muun from using zero-conf submarine swaps to using payment
> > channels is ongoing, but we are still several months away from being production
> > ready. This means we would have to turn off outgoing lightning payments for
> > +100k monthly active users, which is a good chunk of all users making
> > non-custodial lightning payments today.
>
>
> It would be unfortunate for those users, but I think that the risk
> exists today. Relay of fullrbf transactions works reasonable well
> already, unless you get unlucky with your selected peers. The only
> missing piece is a few percent of hashrate that will accept fullrbf
> replacement transactions. While this will certainly happen if a
> Bitcoin Core release ships with the flag on by default, it still may
> happen at any time even if Bitcoin Core doesn't ship with the flag at
> all.
>
> Best,
> cndm1
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

📅 Original date posted:2022-10-08 📝 Original message:Hi ...

2023-06-08T01:14:27+02:00

In reply to nevent1q…ss6r
_________________________

📅 Original date posted:2022-10-08
📝 Original message:Hi Dario,

There aren't any risks with latest release of bitcoin core. However its not just munn or other things mentioned, even other bitcoin projects could be affected if [#25600][1] is merged.

Anyway I cannot comment anymore, neither in the PR or repository. I tried my best. Peter Todd has ACKed it and it would affect his favorite coinjoin implementation that works with governments.

Replacement policies are a per-node decision as Luke Dashjr said and projects should build upon it.

[1]: https://github.com/bitcoin/bitcoin/pull/25600

/dev/fd0

Sent with [Proton Mail](https://proton.me/) secure email.

------- Original Message -------
On Friday, October 7th, 2022 at 9:50 PM, Dario Sneidermanis via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:

> Hello list,
>
> I'm Dario, from Muun wallet, a mobile non-custodial bitcoin wallet. For the past
> few days we've been reviewing the latest bitcoin core release candidate, and we
> found some troubling facts related to the opt-in full-RBF deployment.
>
> We first learned about the opt-in full-RBF proposal last June when it was
> announced on the mailing list. Closing the gap between the protocol's relay
> policies and the miner incentives is inevitable, so it was a welcomed addition.
> Furthermore, allowing transaction replacements that remove the opt-in RBF flag
> was deeply problematic.
>
> At the time, we understood we had at least a year from the initial opt-in
> deployment until opt-out was deployed, giving us enough time to adapt Muun to
> the new policies. However, when reviewing the 24.0 release candidate just a few
> days ago, we realized that zero-conf apps (like Muun) must *immediately turn
> off* their zero-conf features.
>
> I understand this wasn't the intention when designing the opt-in deployment
> mechanism. Given this new information, do you see a path where we can delay the
> opt-in deployment and find a safer way to deploy full-RBF?
>
> It'd be great for this deployment to be a success so that we can continue fixing
> the remaining relay policy problems, such as package relay and the RBF rules.
> Maybe we could go straight to an opt-out deployment locked by code at a certain
> height in the future to give time to everyone and, at the same time, avoid a
> huge mempool divergence event?
>
> Below is our analysis of how zero-conf apps break with opt-in full-RBF. I hope
> it helps.
>
> Cheers,
> Dario
>
> # How do zero-conf apps work
>
> While the workings and trade-offs of zero-conf applications might be known by
> many in this list, it's useful to define precisely how they work to understand
> how they break.
>
> We call zero-conf applications to entities that accept on-chain payments from
> *untrusted parties* and will sometimes deliver the paid-for product or service
> without waiting for the transaction to be included in a block.
>
> Some examples of zero-conf apps:
>
> - Muun's submarine swaps for outgoing lightning payments
> - Bitrefill's on-chain payments for gift cards and phone top-ups
> - Many bitcoin ATMs' on-chain deposits for selling bitcoin for cash (at least
> the two biggest bitcoin ATM manufacturers support this: Genesis Coin and
> General Byte)
>
> All of these applications are receiving incoming on-chain transactions for which
> they don't control the inputs, and performing a risk analysis to decide whether
> they are ok with accepting the payment without confirmation.
>
> In practice, this works because once the bitcoin P2P network has fully
> propagated a non-RBF transaction, you need the collaboration of a miner to
> replace it, which isn't easy to get today. Even though many of the biggest
> miners offer off-band transaction broadcasting services, they currently won't
> process conflicting transactions.
>
> Roughly, the risk analysis goes like this:
>
> 1. if an incoming transaction is RBF (direct or inherited)
> --> too risky, wait for 1 conf (or more) since it can be replaced at any time
> 2. if the payment is for an amount greater than X
> --> too risky, wait for 1 conf (or more), since the amount is worthy of a
> sophisticated attacker
> 3. wait for full(ish) propagation of the incoming transaction
> 4. if there's no double-spend attempt
> --> accept 0-conf
>
> As with any other risk analysis, there's always a false-negative detection rate,
> leading to an expected loss, which the zero-conf app should be willing to bear.
> Notice that the expected loss is tunable via the amount X in the above analysis.
>
> # Why are zero-conf apps not protected with an opt-in deployment
>
> Full-RBF adoption works on three different layers:
>
> - The transaction application layer
> - The transaction relaying layer
> - The transaction mining layer
>
> If an application wants to replace with full-RBF an *outgoing* transaction, it
> will need:
>
> - An upgraded node that opted into full-RBF, from which it can broadcast the
> replacement transaction
> - A connected component of upgraded nodes that opted into full-RBF, that can
> relay the replacement transaction
> - A miner in that connected component with an upgraded node that opted into
> full-RBF, that can mine the replacement transaction
>
> However, an application cannot control whether a replacement to an *incoming*
> transaction is relayed via full-RBF. As soon as a single application can
> generate replacements easily via full-RBF, all other applications have to assume
> that any incoming transaction from an untrusted party might be replaced via
> full-RBF. That is, for the application layer this is a forced upgrade.
>
> As soon as an unsophisticated attacker can use opt-in full-RBF, the risk
> analysis performed by zero-conf applications stops working because the
> transactions to analyze are all incoming transactions from untrusted parties.
> Since some wallets already implement cancel functionality for opt-in RBF
> transactions, enabling the same functionality for every transaction wouldn't
> require much work, making canceling any unconfirmed transaction a one-click
> experience. After this, the security model of zero-conf applications goes from
> "susceptible to attacks from miners" to "anyone can perform an attack, with an
> easy-to-use interface".
>
> That is, the opt-in deployment of full-RBF doesn't protect zero-conf
> applications from having to turn off their zero-conf features very soon after
> the initial deployment. All mitigations are mostly ineffective against
> untrusted parties.
>
> # Other things we have to fix
>
> While it's clear how full-RBF breaks zero-conf applications, other more subtle
> things break in *many* wallets (Muun included). If given the opportunity, we
> would like to fix them before deployment. One could argue that these things
> were already broken, but they get considerably worse as the network adopts
> full-RBF (even with an opt-in deployment), so we should fix them.
>
> ## Mental model for unconfirmed incoming transactions
>
> Many wallets with support for on-chain payments (Muun included) show incoming
> external transactions in some way to their users before they confirm. This is a
> common practice because not showing them leads users to worry that their money
> disappeared (exchanges doing this is the #1 issue we have to deal with in our
> customer support channels).
>
> With full-RBF, wallets should make it extremely clear to users that unconfirmed
> funds are not theirs (yet). Otherwise, protocol-unaware users that are
> transacting on-chain with untrusted parties can be easily scammed if they don't
> know they have to wait for a confirmation. Eg. in Argentina, it's pretty common
> to meet someone in person to buy bitcoin P2P for cash, even for newcomers.
>
> ## Block explorers as payment receipts
>
> Most wallets with support for on-chain payments (Muun included) use the
> transaction view of a block explorer as a shareable payment receipt. The sender
> of an on-chain transaction usually shares this link with the receiver to let
> them know they made a payment. Protocol-unaware receivers sometimes take this
> link as proof of payment.
>
> Most explorers currently don't track payment replacements and, more importantly,
> don't warn users that unconfirmed funds are not theirs (yet). With full-RBF,
> wallets should either stop relying on explorers for this functionality or wait
> for them to support it explicitly.
>
> # Impact at Muun
>
> Work to transition Muun from using zero-conf submarine swaps to using payment
> channels is ongoing, but we are still several months away from being production
> ready. This means we would have to turn off outgoing lightning payments for
> +100k monthly active users, which is a good chunk of all users making
> non-custodial lightning payments today.
>
> Furthermore, the more subtle fixes imply non-trivial amounts of product work
> that we cannot reasonably deploy before they start affecting users.
>
> While I cannot talk for other applications, there are many impacted in one way
> or another, and none of the ones I checked with were aware of this change, or
> its implications.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221008/1ee7b850/attachment-0001.html>;

📅 Original date posted:2022-10-19 📝 Original message:Hi aj, ...

2023-06-08T01:14:25+02:00

In reply to nevent1q…jg7u
_________________________

📅 Original date posted:2022-10-19
📝 Original message:Hi aj,

> I mean, I guess I can understand wanting to reduce that responsibility
> for maintainers of the github repo, even if for no other reason than to
> avoid frivolous lawsuits, but where do you expect people to find better
> advice about what things are a good/bad idea if core devs as a whole
> are avoiding that responsibility?

Bitcoin Core contributors and maintainers should provide the options, recommendations etc. about mempool policies. If these policies are kept for users to change based on their needs, why force anything or change defaults ignoring feedback?

> Core devs are supposedly top technical experts at bitcoin -- which means
> they're the ones that should have the best understanding of all the
> implications of policy changes like this.

Why even provide options for users to change RBF policy in that case? Option to disable was already [removed][1] ignoring NACKs and MarcoFalke prefers users try the [workaround][2] if there is ever a need to disable it. Are we going to remove all the options to switch RBF policies in future because fullrbf has been suggested by leading technical experts? Is there a possibility of experts going wrong and has it ever happened in past?

> It's a bit disappointing that the people that's a problem for didn't
> engage earlier -- though looking back, I guess there wasn't all that
> much effort made to reach out, either.

To be fair, John Carvalho did [comment][3] about this in a pull request although it was wrong PR and never going to be merged.

> And I mean: all this is only about drawing a line in sand; if people
> think core devs are wrong, they can still let that line blow away in
> the wind, by running different software, configuring core differently,
> patching core, or whatever else.

I think this is the best option for users at this point. Keep running older versions of Core and use Knots or other implementations until technical experts in core repository, other bitcoin projects and users are on the same page.

> And the
> impression I got from the PR review club discussion more seemed like
> devs making assumptions about businesses rather than having talked to
> them (eg "[I] think there are fewer and fewer businesses who absolutely
> cannot survive without relying on zeroconf. Or at least hope so").

Even I noticed this since I don't recall the developers of the 3 main coinjoin implementations that are claimed to be impacted by opt-in RBF making any remarks.

[1]: https://github.com/bitcoin/bitcoin/pull/16171
[2]: https://github.com/bitcoin/bitcoin/pull/25373#issuecomment-1157846575
[3]: https://github.com/bitcoin/bitcoin/pull/25373#issuecomment-1163422654

/dev/fd0

Sent with Proton Mail secure email.

------- Original Message -------
On Tuesday, October 18th, 2022 at 12:30 PM, Anthony Towns via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:

> On Mon, Oct 17, 2022 at 05:41:48PM -0400, Antoine Riard via bitcoin-dev wrote:
>
> > > 1) Continue supporting and encouraging accepting unconfirmed "on-chain"
> > > payments indefinitely
> > > 2) Draw a line in the sand now, but give people who are currently
> > > accepting unconfirmed txs time to update their software and business
> > > model
> > > 3) Encourage mainnet miners and relay nodes to support unconditional
> > > RBF immediately, no matter how much that increases the risk to
> > > existing businesses that are still accepting unconfirmed txs
> > > To give more context, the initial approach of enabling full RBF through
> > > #25353 + #25600 wasn't making the assumption the enablement itself would
> > > reach agreement of the economic majority or unanimity.
>
>
> Full RBF doesn't need a majority or unanimity to have an impact; it needs
> adoption by perhaps 10% of hashrate (so a low fee tx at the bottom of
> a 10MvB mempool can be replaced before being mined naturally), and some
> way of finding a working path to relay txs to that hashrate.
>
> Having a majority of nodes/hashrate support it makes the upsides better,
> but doesn't change the downsides to the people who are relying on it
> not being available.
>
> > Without denying that such equilibrium would be unstable, it was designed to
> > remove the responsibility of the Core project itself to "draw a hard line"
> > on the subject.
>
>
> Removing responsibility from core developers seems like it's very much
> optimising for the wrong thing to me.
>
> I mean, I guess I can understand wanting to reduce that responsibility
> for maintainers of the github repo, even if for no other reason than to
> avoid frivolous lawsuits, but where do you expect people to find better
> advice about what things are a good/bad idea if core devs as a whole
> are avoiding that responsibility?
>
> Core devs are supposedly top technical experts at bitcoin -- which means
> they're the ones that should have the best understanding of all the
> implications of policy changes like this. Is opt-in RBF only fine? If
> you look at the network today, it sure seems like it; it takes a pretty
> good technical understanding to figure out what problems it has, and
> an even better one to figure out whether those problems can be solved
> while keeping an opt-in RBF regime, or if full RBF is needed.
>
> At that point, the technical experts should be coming up with a
> specific recommendation, and, personally, I think that's exactly what
> happened with [0] [1] and [2].
>
> [0] https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html
> [1] https://github.com/bitcoin/bitcoin/pull/25353
> [2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020557.html
>
> That did draw hard line in the sand: it said "hey, opt-in RBF had a good
> run, but it's time to switch over to full RBF, for these reasons".
>
> It's a bit disappointing that the people that's a problem for didn't
> engage earlier -- though looking back, I guess there wasn't all that
> much effort made to reach out, either. There were two mentions in the
> optech newsletter [3] [4] but it wasn't called out as an "action item"
> (maybe those aren't a thing anymore), so it may have been pretty missable,
> especially given RBF has been discussed on and off for so long. And the
> impression I got from the PR review club discussion more seemed like
> devs making assumptions about businesses rather than having talked to
> them (eg "[I] think there are fewer and fewer businesses who absolutely
> cannot survive without relying on zeroconf. Or at least hope so").
>
> [3] https://bitcoinops.org/en/newsletters/2022/06/22/
> [4] https://bitcoinops.org/en/newsletters/2022/07/13/
>
> If we're happy to not get feedback until we start doing rcs, that's fine;
> but if we want to say "oops, we're into release candidates, you should
> have something earlier, it's too late now", that's a pretty closed-off
> way of doing things.
>
> And I mean: all this is only about drawing a line in sand; if people
> think core devs are wrong, they can still let that line blow away in
> the wind, by running different software, configuring core differently,
> patching core, or whatever else.
>
> > Moreover, relying on node operators turning on the setting
> > provides a smoother approach offering time to zero-conf services to react
> > in consequence.
>
>
> I don't think that's remotely true: take a look at taproot activation:
> it took two months between releasing code that supported signalling and
> having 98% of hashrate signalling; with 40% of blocks signalling within
> the first two weeks.
>
> > So the current path definitely belongs more to a 3) approach.
>
> > > 3) Encourage mainnet miners and relay nodes to support unconditional
> > > RBF immediately, no matter how much that increases the risk to
> > > existing businesses that are still accepting unconfirmed txs
>
>
> Yes, that's how it appears to me, too. It's not my preference (giving
> people clear warning of changes seems much better to me), but I can
> certainly live with it.
>
> But if the line in the sand is "we're doing this, no matter how much that
> increases the risk to existing businesses that weren't expecting it" then
> it seems very disingenuous not to make those risks very clear so that
> people who weren't expecting it actually take action to avoid those risks.
>
> That is, it seems to me that Dario was exactly right in titling this
> thread "Zero-conf apps in immediate danger", and our co-developers who
> are dismissing the risk by saying things along the lines of "probably
> nothing will change anytime soon" are exactly wrong.
>
> (More generally, that's similar to one of the things I've hated
> watching in mainstream economics over the past few years: "doing this
> will cause massive inflation" "no it won't, there's no inflation risk"
> "oops, inflation magically appeared, how did that happen? oh well, too
> bad, we have to live with it now". This looks pretty similar to me: "do
> something risky, deny the risk, make sure nobody can hold us accountable
> when the risk eventuates later" so it makes me really uncomfortable)
>
> > While this
> > way cannot be denied to be a zero-risk deployment for business accepting
> > unconfirmed transactions, it should be weighed in face of multi-party
> > contracting protocols encumbering an annoying pinning vector.
>
>
> Sure; that's a fine reason to draw the line in the sand. But it's not
> a good reason to have it happen immediately, rather than giving people
> time to react, and it's not a good reason to understate the risk of
> it happening now. Maybe there are good reasons for either or both of
> those, though?
>
> > Since Dario's mail, I think we have learnt new data points, a) on the long
> > term full RBF to align miner incentives is acknowledged and b) a clear
> > timeline based on e.g a block height is favored over the pollination
> > deployment.
>
>
> Using the passive voice there doesn't seem helpful. Who learnt these
> things? You, I and Dario all seem to agree with (a), but John Carvalho
> certainly appears not to, for instance. I'm not sure who agrees with
> (b) -- I know I do, and I think Dario does; but multiple people seem
> opposed to the clear timeline offered in #26323, and your #26305 seems
> more likely to encourage a "pollination" approach rather than discourage
> it ("oh, this will be the default option for 25.0, might as well enable
> it now like all the cool kids are").
>
> For what it's worth, my guess is that releasing core with full rbf
> support and having you and Murch and others advocating for people to
> try it out, will mean that full RBF is usable on mainnet within two
> or three months, supported by perhaps 5%-20% hashpower, but probably
> still requiring special effort to actually find a peer that can relay
> full rbf txs to that hashpower (probably doing an addnode, despite the
> privacy implications). Even if that happens, I'm not super confident
> that it would mean people would actively steal from zeroconf businesses
> in any volume, though. It's not something I'd risk happening to me,
> but accepting zeroconf from strangers isn't something I'd risk anyway.
>
> Slowing that down from January-ish to May seems like it ought to be a
> big win for anyone who has been doing zeroconf, and having it be easy
> to find a path to miners when it is supported seems like a big win even
> given a cost of a few months delay.
>
> OTOH, if we're really not expecting full rbf to be available for many
> months, then I would have expected the "disable this for mainnet,
> reconsider after the release" PR (#26287) to have gone ahead already.
>
> > Tie-breaking between
> > both, I believe I would favor something like #26323 though only post 24.0
> > to avoid introducing a bikeshedding precedent in terms of release process,
>
>
> Doing something like #26323 only after 24.0 is out does nothing to
> mitigate whatever immediate risk there is to bitcoin businesses/users...
>
> And if the choice is between "bikeshedding" and "merge a PR, then ignore
> feedback that it's harmful", I'd much rather the bikeshedding. What's
> the point of having rcs if you're going to ignore negative feedback?
>
> I mean, if you think the feedback is wrong, that's different: maybe we
> shouldn't care that zeroconf apps are in immediate danger, and maybe
> bitcoin would be better if any that don't adapt immediately all die
> horribly as a lesson to others not to make similarly bad assumptions.
>
> But saying "we don't want them to be in danger" and also refusing to do
> anything to avoid it?
>
> Cheers,
> aj
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

📅 Original date posted:2022-08-20 📝 Original message:Hi ...

2023-06-08T01:12:55+02:00

In reply to nevent1q…5w73
_________________________

📅 Original date posted:2022-08-20
📝 Original message:Hi Bitcoin Developers,

I have written a python script as proof of concept for the [coinjoin implementation][1] using [nostr][2]. I used a lot of Python scripts created by others in school, so it feels nice to offer something that could be useful to others.

The implementation uses Bitcoin Core wallet and RPCs: `listunspent`, `getnewaddress`, `scantxoutset`, `createpsbt`, `combinepsbt`, `finalizepsbt` and `sendrawtransaction`. It requires python-nostr library because nostr is used for coordination between peers. Nostr is a decentralized network based on cryptographic keypairs. It is not peer-to-peer however simple and scalable.

Every step is published as an event using a nostr relay and 5 peers coordinate to create, sign and broadcast a coinjoin transaction. I need to write a NIP that would be an alternative to blind signatures. Relay will share a random secret with clients for one round which should be present in output registration request although never gets published. If someone tries to register an output without registering any inputs, request would not have the number initially shared with inputs so request would get rejected or published as unverified. Relay would not be able to link inputs and outputs as the number is same for all inputs in a round and they get registered at different times with new keys and IP address. Clients can use multiple relays at the same time to avoid trusting one relay. This would result in different shared secret number but same process. If a relay tries to cheat, users will not sign the transaction and avoid using it in future.

Usage:

1)Run `python coinjoin.py` and enter descriptor for one of the inputs.
2)Script will check inputs for this round in every 30 seconds and register a new adddress for output once 5 inputs are registered.
3)Similar check happens every 30 seconds for outputs. Last peer should create a PSBT.
4)Unsigned PSBT will be printed and signed by wallet with `walletprocesspsbt` RPC.
5)Script will check signed PSBTs and last peer to sign should finalize coinjoin transaction once 5 signed PSBTs are received.
6)Coinjoin transaction will be broadcasted and txid will printed.

Example:

```
List of utxos in wallet:

wpkh([53830dca/84'/1'/0'/0/0]02449be5fb74725255eeeb50eba930fa87705f21e99d13cd710cf2c1f21153c808)#x2hyyeg5

Enter descriptor for the input registration: wpkh([53830dca/84'/1'/0'/0/0]02449be5fb74725255eeeb50eba930fa87705f21e99d13cd710cf2c1f21153c808)#x2hyyeg5

event id: bcbbe62d75d99fed73f1e50ac58a38d1840b658951893e63c0322b378d7d56f0

```
```
tb1qhxrp4zl54ul0twtyz0gury5399q7z0kvqqrl6m registered for output

event id: 9449c9065bef356d21507a98f88b028b17fc1c49eb195c8d4420604fcaaef041
```
```
Unsigned PSBT: cHNidP8BAP1yAQIAAAAFtMaoJYcXvOG5L3Yaz3YyS7gIt4h5/zzOrRRS3hrVvwoAAAAAAP////+o83geaSm4L76KToIUl5MiZqLAUbIDJLq6DWrjP/3b8AEAAAAA/////zEF3CXIvVHpIa7No1s1yg+KtyOfXTRSyWnOdXMfzcDwAQAAAAD/////wMa4XAgnU+39Ien+KG9rYtv8bLMNYakmZyY/QFfwLRcAAAAAAP/////5M42ID6uLmQTb2tnFHnN7UMpnDD25uN8ZX7A+GNSM3QEAAAAA/////wV4xwEAAAAAABYAFLmGGov0rz71uWQT0cGSkSlB4T7MeMcBAAAAAAAWABSc0/FM6Hdbdxh10IJkYOklVFWqjnjHAQAAAAAAFgAUPSZKe/w6PT6qIF+WhL4wHaFymjd4xwEAAAAAABYAFMx0rxYlpPWB3NFry4Ctk2eVi/UNeMcBAAAAAAAWABSzc4xK0VTfvjK0MHXrAUFLYgYnOgAAAAAAAAAAAAAAAAAAAA==

event id: 976744b38fa9343fb79e1b5215512ead6ee08e5890d79a201fc5b872f6de4eba
```
```
Signed PSBT: cHNidP8BAP1yAQIAAAAFtMaoJYcXvOG5L3Yaz3YyS7gIt4h5/zzOrRRS3hrVvwoAAAAAAP////+o83geaSm4L76KToIUl5MiZqLAUbIDJLq6DWrjP/3b8AEAAAAA/////zEF3CXIvVHpIa7No1s1yg+KtyOfXTRSyWnOdXMfzcDwAQAAAAD/////wMa4XAgnU+39Ien+KG9rYtv8bLMNYakmZyY/QFfwLRcAAAAAAP/////5M42ID6uLmQTb2tnFHnN7UMpnDD25uN8ZX7A+GNSM3QEAAAAA/////wV4xwEAAAAAABYAFLmGGov0rz71uWQT0cGSkSlB4T7MeMcBAAAAAAAWABSc0/FM6Hdbdxh10IJkYOklVFWqjnjHAQAAAAAAFgAUPSZKe/w6PT6qIF+WhL4wHaFymjd4xwEAAAAAABYAFMx0rxYlpPWB3NFry4Ctk2eVi/UNeMcBAAAAAAAWABSzc4xK0VTfvjK0MHXrAUFLYgYnOgAAAAAAAQBxAgAAAAG+qpMXZCy6tBuUlgo8JD0GVXKp60FkhwDeg2sF1fkFkwMAAAAA/f///wLo9wEAAAAAABYAFFfLA5xarC/w/SxeMDQ5tuXrYJLUWwMAAAAAAAAWABRfPf//hwMjHB4OKj87cU19XOSh7yOWAQABAR/o9wEAAAAAABYAFFfLA5xarC/w/SxeMDQ5tuXrYJLUAQhrAkcwRAIgOIhLoC5348U8YkEr4GU1K4yWskIOEXgW4Wsk/W2cR7ICIEJXqtOuDJ5CkwrSuwJLWtzab4dslbN3KuL/pyooMnOCASECRJvl+3RyUlXu61DrqTD6h3BfIemdE81xDPLB8hFTyAgAAAAAACICA77Cnd6o3kr0yc+91eabpOn5igs/MUMbudNYSS6oyMWMGFODDcpUAACAAQAAgAAAAIAAAAAAFAAAAAAAAAAA

event id: 5846b6e6902f3c5a43496d7d9785ed62444aa74963f03c33d637d8b09ee7a139
```
```
Coinjoin tx: 75e490b10b15a6a0422f25ff66ad98ef70390c8fecaac02712705dce8cc3564b

event id: 9b5d4bf279b59e2b6e539e683fba83da72dce2b640360aa95db1b1400be93190
```

There are lot of things that could be improved and a few suggestions are in the gist that described the [idea][3]. I would love read to any opinions about this experiment and will start working on creating an Android app for joinstr next week.

Credits:

- fiatjaf (Nostr)
- Andrew Chow (PSBT)
- Jeff Thibault (python-nostr)
- Existing coinjoin implmentations

[1]: https://github.com/1440000bytes/joinstr
[2]: https://github.com/nostr-protocol/nostr
[3]: https://gist.github.com/1440000bytes/1c305097b070c8374cc3b91f50314a45

/dev/fd0

Sent with Proton Mail secure email.

📅 Original date posted:2022-07-26 📝 Original message:Hi ...

2023-06-08T01:12:09+02:00

In reply to nevent1q…0d3a
_________________________

📅 Original date posted:2022-07-26
📝 Original message:Hi Aaradhya,

> As it's not a consensus rule, I think it can be done easily, just needing support from full node operators

A few miners will need to use a lower minrelaytxfee for this to work. I don't think miners would want to lower their profits.

/dev/fd0

Sent with [Proton Mail](https://proton.me/) secure email.

------- Original Message -------
On Tuesday, July 26th, 2022 at 1:56 PM, Aaradhya Chauhan via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:

I know this might be a sort of repetition for a previous question, but I do want to know from enthusiasts in this group that while Bitcoin was trading at much lower price in its early days, 1 sat/vB was a good dust protection measure. But now, I think it's a bit high for merely a dust protection measure, and should be lowered slightly. Even if not, it should be lowered to half when prices go double than today and keeps oscillating at that point. As it's not a consensus rule, I think it can be done easily, just needing support from full node operators. I support LN but I think transaction affordability should remain constant in the future. If I'm okay to wait in a queue, I should have the option for same affordability for minimum fees in the future as it is today. (Like we still have posts today while email still exists).

Awaiting your response.

Regards
Aaradhya Chauhan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220726/801c59fe/attachment.html>;

📅 Original date posted:2022-07-10 📝 Original message:Sorry, ...

2023-06-08T01:11:27+02:00

In reply to nevent1q…7hjj
_________________________

📅 Original date posted:2022-07-10
📝 Original message:Sorry, I made some wrong calculations in the last email. I think the change would just be required in validation.cpp:

https://github.com/bitcoin/bitcoin/blob/a7f3479ba3fda4c9fb29bd7080165744c02ee921/src/validation.cpp#L1472

/dev/fd0

Sent with Proton Mail secure email.

------- Original Message -------
On Sunday, July 10th, 2022 at 2:17 PM, alicexbt via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:

> Hi ZmnSCPxj,
>
> > Thus, we should instead prepare for a future where the block subsidy must be removed, possibly before the existing schedule removes it, in case a majority coalition of miner ever decides to censor particular transactions without community consensus.
> > Fortunately forcing the block subsidy to 0 is a softfork and thus easier to deploy.
>
>
> `consensus.nSubsidyHalvingInterval` for mainnet in [chainparams.cpp][1] can be decreased to 195000. This will reduce the number of halvings from 34 to 14 and subsidy will be 0 when it becomes less than 0.01 although not sure if this will be a soft fork.
>
> I doubt there will be consensus for it because all the [projections and predictability][2] about bitcoin(currency) would be affected by this change. Maybe everyone can agree with this change if most of the miners start being 'compliant' like one of the coinjoin implementation.
>
> [1]: https://github.com/bitcoin/bitcoin/blob/master/src/chainparams.cpp#L66
> [2]: https://en.bitcoin.it/wiki/Controlled_supply
>
>
> /dev/fd0
>
> Sent with Proton Mail secure email.
>
>
> ------- Original Message -------
> On Saturday, July 9th, 2022 at 9:59 PM, ZmnSCPxj via bitcoin-dev bitcoin-dev at lists.linuxfoundation.org wrote:
>
>
>
> > Good morning e, and list,
> >
> > > Yet you posted several links which made that specific correlation, to which I was responding.
> > >
> > > Math cannot prove how much coin is “lost”, and even if it was provable that the amount of coin lost converges to the amount produced, it is of no consequence - for the reasons I’ve already pointed out. The amount of market production has no impact on market price, just as it does not with any other good.
> > >
> > > The reason to object to perpetual issuance is the impact on censorship resistance, not on price.
> >
> > To clarify about censorship resistance and perpetual issuance ("tail emission"):
> >
> > * Suppose I have two blockchains, one with a constant block subsidy, and one which had a block subsidy but the block subsidy has become negligible or zero.
> > * Now consider a censoring miner.
> > * If the miner rejects particular transactions (i.e. "censors") the miner loses out on the fees of those transactions.
> > * Presumably, the miner does this because it gains other benefits from the censorship, economically equal or better to the earnings lost.
> > * If the blockchain had a block subsidy, then the loss the miner incurs is small relative to the total earnings of each block.
> > * If the blockchain had 0 block subsidy, then the loss the miner incurs is large relative to the total earnings of each block.
> > * Thus, in the latter situation, the external benefit the miner gains from the censorship has to be proportionately larger than in the first situation.
> >
> > Basically, the block subsidy is a market distortion: the block subsidy erodes the value of held coins to pay for the security of coins being moved.
> > But the block subsidy is still issued whether or not coins being moved are censored or not censored.
> > Thus, there is no incentive, considering only the block subsidy, to not censor coin movements.
> > Only per-transaction fees have an incentive to not censor coin movements.
> >
> > Thus, we should instead prepare for a future where the block subsidy must be removed, possibly before the existing schedule removes it, in case a majority coalition of miner ever decides to censor particular transactions without community consensus.
> > Fortunately forcing the block subsidy to 0 is a softfork and thus easier to deploy.
> >
> > Regards,
> > ZmnSCPxj
> > _______________________________________________
> > 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

📅 Original date posted:2022-07-10 📝 Original message:Hi ...

2023-06-08T01:11:27+02:00

In reply to nevent1q…qz4h
_________________________

📅 Original date posted:2022-07-10
📝 Original message:Hi ZmnSCPxj,

> Thus, we should instead prepare for a future where the block subsidy must be removed, possibly before the existing schedule removes it, in case a majority coalition of miner ever decides to censor particular transactions without community consensus.
> Fortunately forcing the block subsidy to 0 is a softfork and thus easier to deploy.

`consensus.nSubsidyHalvingInterval` for mainnet in [chainparams.cpp][1] can be decreased to 195000. This will reduce the number of halvings from 34 to 14 and subsidy will be 0 when it becomes less than 0.01 although not sure if this will be a soft fork.

I doubt there will be consensus for it because all the [projections and predictability][2] about bitcoin(currency) would be affected by this change. Maybe everyone can agree with this change if most of the miners start being 'compliant' like one of the coinjoin implementation.

[1]: https://github.com/bitcoin/bitcoin/blob/master/src/chainparams.cpp#L66
[2]: https://en.bitcoin.it/wiki/Controlled_supply

/dev/fd0

Sent with Proton Mail secure email.

------- Original Message -------
On Saturday, July 9th, 2022 at 9:59 PM, ZmnSCPxj via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:

> Good morning e, and list,
>
> > Yet you posted several links which made that specific correlation, to which I was responding.
> >
> > Math cannot prove how much coin is “lost”, and even if it was provable that the amount of coin lost converges to the amount produced, it is of no consequence - for the reasons I’ve already pointed out. The amount of market production has no impact on market price, just as it does not with any other good.
> >
> > The reason to object to perpetual issuance is the impact on censorship resistance, not on price.
>
>
> To clarify about censorship resistance and perpetual issuance ("tail emission"):
>
> * Suppose I have two blockchains, one with a constant block subsidy, and one which had a block subsidy but the block subsidy has become negligible or zero.
> * Now consider a censoring miner.
> * If the miner rejects particular transactions (i.e. "censors") the miner loses out on the fees of those transactions.
> * Presumably, the miner does this because it gains other benefits from the censorship, economically equal or better to the earnings lost.
> * If the blockchain had a block subsidy, then the loss the miner incurs is small relative to the total earnings of each block.
> * If the blockchain had 0 block subsidy, then the loss the miner incurs is large relative to the total earnings of each block.
> * Thus, in the latter situation, the external benefit the miner gains from the censorship has to be proportionately larger than in the first situation.
>
> Basically, the block subsidy is a market distortion: the block subsidy erodes the value of held coins to pay for the security of coins being moved.
> But the block subsidy is still issued whether or not coins being moved are censored or not censored.
> Thus, there is no incentive, considering only the block subsidy, to not censor coin movements.
> Only per-transaction fees have an incentive to not censor coin movements.
>
>
> Thus, we should instead prepare for a future where the block subsidy must be removed, possibly before the existing schedule removes it, in case a majority coalition of miner ever decides to censor particular transactions without community consensus.
> Fortunately forcing the block subsidy to 0 is a softfork and thus easier to deploy.
>
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

📅 Original date posted:2022-07-05 📝 Original message:Hi ...

2023-06-08T01:11:12+02:00

In reply to nevent1q…vzf3
_________________________

📅 Original date posted:2022-07-05
📝 Original message:Hi Peter,

> Note that Wasabi already has a DoS attack vector in that a participant can stop
> participating after the first phase of the round, with the result that the
> coinjoin fails. Wasabi mitigates that by punishing participating in future
> rounds. Double-spends only create additional types of DoS attack that need to
> be detected and punished as well - they don't create a fundamentally new
> vulerability.

I agree some DoS vectors are already mitigated however punishment in this case will be difficult because the transaction is broadcasted after signing and before coinjoin tx broadcast.

Inputs are already checked multiple times for double spend during coinjoin round: https://github.com/zkSNACKs/WalletWasabi/pull/6460

If all the inputs in the coinjoin transaction that failed to relay are checked and one or more are found to be spent later, what will be punished and how does this affect the attacker with thousands of UTXOs or normal users?

/dev/fd0

Sent with Proton Mail secure email.

------- Original Message -------
On Monday, June 27th, 2022 at 12:43 AM, Peter Todd <pete at petertodd.org> wrote:

> On Sun, Jun 26, 2022 at 04:40:24PM +0000, alicexbt via bitcoin-dev wrote:
>
> > Hi Antoine,
> >
> > Thanks for sharing the DoS attack example with alternatives.
> >
> > > - Caroll broadcasts a double-spend of her own input C, the double-spend is attached with a low-fee (1sat/vb) and it does not signal opt-in RBF
> > > - Alice broadcasts the multi-party transaction, it is rejected by the network mempools because Alice double-spend is already present
> >
> > I think this affects almost all types of coinjoin transaction including coordinator based implementations. I tried a few things and have already reported details for an example DoS attack to one of the team but there is no response yet.
> >
> > It was fun playing with RBF, DoS and Coinjoin. Affected projects should share their opinion about full-rbf as it seems it might improve things.
> >
> > Example:
> >
> > In Wasabi an attacker can broadcast a transaction spending input used in coinjoin after sending signature in the round. This would result in a coinjoin tx which never gets relayed: https://nitter.net/1440000bytes/status/1540727534093905920
>
>
> Note that Wasabi already has a DoS attack vector in that a participant can stop
> participating after the first phase of the round, with the result that the
> coinjoin fails. Wasabi mitigates that by punishing participating in future
> rounds. Double-spends only create additional types of DoS attack that need to
> be detected and punished as well - they don't create a fundamentally new
> vulerability.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org

📅 Original date posted:2022-06-26 📝 Original message:Hi ...

2023-06-08T01:10:35+02:00

In reply to nevent1q…n4hd
_________________________

📅 Original date posted:2022-06-26
📝 Original message:Hi Antoine,

Thanks for sharing the DoS attack example with alternatives.

> - Caroll broadcasts a double-spend of her own input C, the double-spend is attached with a low-fee (1sat/vb) and it does _not_ signal opt-in RBF
> - Alice broadcasts the multi-party transaction, it is rejected by the network mempools because Alice double-spend is already present

I think this affects almost all types of coinjoin transaction including coordinator based implementations. I tried a few things and have already reported details for an example DoS attack to one of the team but there is no response yet.

It was fun playing with RBF, DoS and Coinjoin. Affected projects should share their opinion about full-rbf as it seems it might improve things.

Example:

In Wasabi an attacker can broadcast a transaction spending input used in coinjoin after sending signature in the round. This would result in a coinjoin tx which never gets relayed: https://nitter.net/1440000bytes/status/1540727534093905920

/dev/fd0

Sent with Proton Mail secure email.

------- Original Message -------
On Tuesday, June 21st, 2022 at 11:43 PM, Antoine Riard <antoine.riard at gmail.com> wrote:

> HI alicexbt,
>
> > Lets consider there are 2 users with name Bob (normal LN user) and Carol (attacker running LN node) which I will use in this email for examples. In this case Bob and Carol can manage security of their OS and it is not affected by others using vulnerable systems or OS.
>
> Yes, I believe my argument was the set of components making the security of your LN node is far beyond Bitcoin softwares. Of course, you might review by yourself the millions lines of code entering in the trusted computing base (OS, bootloader, BIOS, device firmwares, essential utilities, ...) on which your cryptocurrency software stack lays out, and as such exercise an extended span of control on your personal computation. Though, while I hope we'll have more LN node operators doing so, I'm not sure it's realistic to expect it will be the behavior standard among them..
>
> > The odds are low as you said, this can be managed by Bob and Carol because they can use a better ISP. Others using ISP with some issues may not affect their LN usage.
>
> Sure, though as I would like to underscore being dependent on a Bitcoin node policy and being dependent on a ISP internet traffic routing policy could be analyzed as logically equivalent, all things are equal. That said, if your personal risk aversion is too high for the Lightning security model, once it's well-understood there is a strong reliance on a censorship-resistant tx-relay network back to economically-rational miners, you're free to not use it and satisfy yourself with the Bitcoin base layer.
>
> > Bob might use full-rbf as its suggested by LN developers for secure LN usage and better for miners. Carol could use a different RBF policy for some nodes and mining. In this case Bob may get affected at some point because of Carol's choice to use a different RBF policy which was not true above.
>
> Indeed, your secure LN usage is going to be dependent of the number of p2p network nodes running an economically-rational policy like full-rbf. That said, I think it's reasonable to assume that the players of the Bitcoin game are economically-rational, and as such incentived to pick up a policy such as full-rbf. I know the term "economically-rational" is poorly defined here, and I think it could be interesting for any academic with an economic background to study the incentives of Bitcoin actors.
>
> > Allowing users to create different mempool policies is great. My thought process is to code for happy path, where X policy is expected for replacement and edge cases where Y policy or no policy would be used. Users can try out different policies and even act as attackers. This is also true for other things in mempool, 'spkreuse=conflict' prevents address reuse in the mempool when using knots. If I assume that address reuse is always relayed, this could become a problem if some users and miners adopt this setting in their mempool.
>
> Agree, I'm all in for people to experiment with mempool policies. Though at the end it's a software engineering resource question. If users are interested in more features, they're always free to implement themselves. Really, the binary distinction developers-vs-users doesn't make sense and if we would like Bitcoin to be successful in the long-term, we should promote high degree of software literacy among bitcoiners.
>
> > This makes sense and I would be interested to follow two things once full-rbf is available in a bitcoin core release: 1. Percentage of transaction getting replaced 2. Miners profit (Fee for replaced Tx - Fee for original Tx)
>
> Yes, I would be interested too to have those metrics once full-rbf is available in a bitcoin core release. I think that's something every full-rbf curious node operator could observe on its own with a few more loggers, at least for the first metric.
>
> > Can you explain how p2p coinjoin is affected with mempool DoS vector with some examples? What is considered a p2p coinjoin? Joinmarket or [Stonewall][1]?
>
> I don't remember the Joinmarket code right now and I don't know the ins and outs of Samourai coinjoin as I'm not sure the code is open source. Though let's say for a p2p coinjoin as one you can build once you have implemented LN's interactive construction protocol [0].
>
> [0] https://github.com/lightning/bolts/pull/851
>
> Here the DoS attack situation :
> - Alice, Bob and Caroll would like to coinjoin 3 inputs to 3 outputs
> - Each of the input is singly controlled by one party, e.g Alice owns input A, Bob owns input B, ...
> - Alice, Bob and Caroll exchanges a PSBT to build a multi-party funded transaction (the coinjoin_tx)
> - Alice is elected as the multi-party transaction broadcaster once the signatures have been exchanged
> - The block feerate is around 10sat/vb
> - One of the transaction input signals opt-in RBF, the transaction is attached a compelling feerate 10sat/vb
> - Caroll broadcasts a double-spend of her own input C, the double-spend is attached with a low-fee (1sat/vb) and it does _not_ signal opt-in RBF
> - Alice broadcasts the multi-party transaction, it is rejected by the network mempools because Alice double-spend is already present
> - Two alternatives are offered to the coinjoin participants :
>
> Alternative A)
> - They estimate the multi-party feerate as not high enough
> - They fee-bump at 20sat/vb
> - Caroll double-spend one of the input of her malicious double-spend to eject it from the network mempools
> - The multi-party transaction is confirmed at a block feerare far above what was necessary
> - Alice, Bob, Caroll have loss fee-bumping value without compensation
> - Note, even if Caroll is attacker and assuming the fee-bumping burden is fairly spread among participants, the economic loss inflicted is asymmetric
>
> Alternative B)
> - They wait until some time-out
> - They double-spend their own inputs, Alice double-spend utxo A, Bob double-spend utxo B
> - They wasted the timevalue of their inputs for the time-out delay
> - Note, even if Caroll is attacker and loss some timevalue too, the economic loss inflicted is asymmetric
>
> Let me know if you see any error or wrong in this DoS scenario exposure. I believe it's fairly simple to execute
> for a medium-skilled attacker.
>
> Antoine
>
> Le ven. 17 juin 2022 à 00:54, alicexbt <alicexbt at protonmail.com> a écrit :
>
> > Hi Antoine,
> >
> >
> >
> > > One could list the operating system on which is running your Lightning process or the compiler toolchain turning out your Lightning source code in a binary artifact. Some weird kernel's memory mapping change could allow access to your channel funding keys, _without_ breaking the Bitcoin consensus rules [0].
> >
> > Lets consider there are 2 users with name Bob (normal LN user) and Carol (attacker running LN node) which I will use in this email for examples. In this case Bob and Carol can manage security of their OS and it is not affected by others using vulnerable systems or OS.
> >
> >
> > > Moreover, your Lightning node is also relying on the existence of a global Internet allowing your HTLC transaction to flow from your physical host to the crowd of transactions confirming in the blockchain. Due to this "protocol assumption" your channel balance would be vulnerable to any change in your ISP routing policy, e.g refusing to accept your IPV4 traffic by a sudden desiderata to impose an IPV6 supremacy. Still _without_ breaking the Bitcoin consensus rules. Of course, the odds of your ISP operator adopting this behavior are really low, mostly because your operator has to bind to social and economic constraints to stay in business.
> >
> > The odds are low as you said, this can be managed by Bob and Carol because they can use a better ISP. Others using ISP with some issues may not affect their LN usage.
> >
> >
> > > And I believe this imperative to stay in business is certainly not absent in the incentives of the Bitcoin node operators. You're free to run any policy on your node, especially one hardening the safety of your operations beyond the default one. However, if you start to a transaction-relay non-compatible with miner incentives, you won't have an efficient view of the blockspace demand, and from then won't be able to offer compelling feerates to execute your business transactions to satisfy your client needs. Or you won't consolidate your wallet UTXOs at times of low-demand. Indeed, a sane visibility of the mempools might not be critical now for your Bitcoin operations, but this is not likely to become true with miner's coinbase reward lowering with time and the system security relying on a fruitful fee market.
> >
> > Bob might use full-rbf as its suggested by LN developers for secure LN usage and better for miners. Carol could use a different RBF policy for some nodes and mining. In this case Bob may get affected at some point because of Carol's choice to use a different RBF policy which was not true above.
> >
> >
> >
> > > So assuming there is a significant number of economically rational entities running p2p nodes, I think it's a reasonable assumption for Lightning developers that a policy maximizing miner's income and economic nodes operations will be widely run on the p2p network, and therefore lay its security model on that. When there is a gap between the economically optimal policy (full-rbf) and the effectively deployed one (optin), and this gap constitutes a flaw for exploitation, I believe it's better to fix it.
> >
> > Agree with the assumption there is nothing wrong in experimenting with a new RBF policy (non-default) if that helps some users and projects.
> >
> >
> > > If you have a different mode of thinking w.r.t how we should design protocol in a trust-minimized, open, adversarial environment such as Bitcoin, I'm curious to listen to it.
> >
> > Allowing users to create different mempool policies is great. My thought process is to code for happy path, where X policy is expected for replacement and edge cases where Y policy or no policy would be used. Users can try out different policies and even act as attackers. This is also true for other things in mempool, 'spkreuse=conflict' prevents address reuse in the mempool when using knots. If I assume that address reuse is always relayed, this could become a problem if some users and miners adopt this setting in their mempool.
> >
> >
> > > Of course not. If you deliver any critical software, you should attach a solid manual explaining all the corner cases and rough edges. Even better would be to enshrine the manual directly in your software API to minimize the footgunish behaviors. E.g, with any ECC library, forbidding to reuse nonces. If your user still ignores or misread the manual and provides an insecure input, there is not that much you can do.
> >
> > Agree with the documentation as it helps users.
> >
> >
> > > Given there are like 17000 public LN nodes, if half of them adopt full-rbf it should give already a good number of full-rbf transaction-relay routes across the p2p network graph. When we're there, we can measure and think more about how to tune the full-rbf sub-topology.
> >
> > Sounds good.
> >
> >
> > > Because it's breaking the reliability and security of their use-cases. Use-cases which didn't exist a few years ago. The mempool DoS vector is described here [4]. To the best of my understanding, it might affect a bunch of use-cases, such as dual-funded channels, on-chain DLCs, p2p coinjoins, batched submarine swaps out. With the attack described, the honest set of users might not have visibility of the network mempools that there is a malicious, low-cost, opt-out double-spend preventing the propagation of their multi-party transaction. With the existence of a full-rbf transaction-relay topology, the multi-party transaction is able to replace the optout.
> >
> > This makes sense and I would be interested to follow two things once full-rbf is available in a bitcoin core release: 1. Percentage of transaction getting replaced 2. Miners profit (Fee for replaced Tx - Fee for original Tx)
> >
> >
> > Can you explain how p2p coinjoin is affected with mempool DoS vector with some examples? What is considered a p2p coinjoin? Joinmarket or [Stonewall][1]?
> >
> >
> > > Selecting a full-node to underpin any serious Bitcoin infrastructure or secure a significant stack of coins should be submitted to a fully-fledged decision-making process. Many factors are likely to matter such as the level of activity of the contributor community, the chain of trust w.r.t dependencies, the security incident track records, the quality of the documentation, the exhaustivity and robustness of the set of features, ...
> >
> > I agree that contributor community and documentation could be improved in Knots.
> >
> >
> > > Developers are also Bitcoin users, and they're modifying the software to suit their use-case needs. And that's exactly the purpose of the 'full-rbf' PR I'm proposing, aiming to propose a "good" policy for a Lightning node, without actually seeking to change the default.
> >
> > I like that default still remains opt-in and cool with different policies being tried out if that helps some users.
> >
> >
> > > If they're parties interested in implementing more RBF policy options in Bitcoin Core, I think they're free to propose such changes and invest the engineering effort to do so. If you're interested in advancing the state of policy options in Bitcoin Core, there are a lot of interesting resources available and communities to encourage you in the learning process to contribute to the codebase [6].
> >
> > Thanks for sharing the link. I would love to see 5 RBF policies available to use in bitcoin core. I have already tried experimenting with a few on regtest and will try to open pull request if there are enough people interested to test it on other chains (testnet3, signet, mainnet)
> >
> >
> > [1]: https://docs.samourai.io/spend-tools
> >
> >
> >
> >
> > /dev/fd0
> >
> >
> >
> > Sent with Proton Mail secure email.
> >
> > ------- Original Message -------
> > On Friday, June 17th, 2022 at 7:04 AM, Antoine Riard <antoine.riard at gmail.com> wrote:
> >
> >
> > > Hi alicexbt,
> > >
> > >
> > >
> > > Thanks for taking time to review the pull request,
> > >
> > >
> > >
> > > > 1)If something relies on a policy which can be changed without breaking consensus rules, how is it secure in any case with or without full rbf?
> > >
> > >
> > >
> > > Your Lightning node software relies on far more software and hardware components than the transaction-relay p2p network. One could list the operating system on which is running your Lightning process or the compiler toolchain turning out your Lightning source code in a binary artifact. Some weird kernel's memory mapping change could allow access to your channel funding keys, _without_ breaking the Bitcoin consensus rules [0]. Moreover, your Lightning node is also relying on the existence of a global Internet allowing your HTLC transaction to flow from your physical host to the crowd of transactions confirming in the blockchain. Due to this "protocol assumption" your channel balance would be vulnerable to any change in your ISP routing policy, e.g refusing to accept your IPV4 traffic by a sudden desiderata to impose an IPV6 supremacy. Still _without_ breaking the Bitcoin consensus rules. Of course, the odds of your ISP operator adopting this behavior are really low, mostly because your operator has to bind to social and economic constraints to stay in business.
> > >
> > >
> > >
> > > And I believe this imperative to stay in business is certainly not absent in the incentives of the Bitcoin node operators. You're free to run any policy on your node, especially one hardening the safety of your operations beyond the default one. However, if you start to a transaction-relay non-compatible with miner incentives, you won't have an efficient view of the blockspace demand, and from then won't be able to offer compelling feerates to execute your business transactions to satisfy your client needs. Or you won't consolidate your wallet UTXOs at times of low-demand. Indeed, a sane visibility of the mempools might not be critical now for your Bitcoin operations, but this is not likely to become true with miner's coinbase reward lowering with time and the system security relying on a fruitful fee market.
> > >
> > >
> > >
> > > So assuming there is a significant number of economically rational entities running p2p nodes, I think it's a reasonable assumption for Lightning developers that a policy maximizing miner's income and economic nodes operations will be widely run on the p2p network, and therefore lay its security model on that. When there is a gap between the economically optimal policy (full-rbf) and the effectively deployed one (optin), and this gap constitutes a flaw for exploitation, I believe it's better to fix it.
> > >
> > >
> > >
> > > If you have a different mode of thinking w.r.t how we should design protocol in a trust-minimized, open, adversarial environment such as Bitcoin, I'm curious to listen to it.
> > >
> > >
> > >
> > > > If I write a python script that expects user to enter char 'a' or 'b' but user can enter 'c' and there is no code to handle exceptions or other chars, will it be secure?
> > >
> > >
> > >
> > > Of course not. If you deliver any critical software, you should attach a solid manual explaining all the corner cases and rough edges. Even better would be to enshrine the manual directly in your software API to minimize the footgunish behaviors. E.g, with any ECC library, forbidding to reuse nonces. If your user still ignores or misread the manual and provides an insecure input, there is not that much you can do.
> > >
> > >
> > >
> > > By analogy, I believe that's the same with Lightning. One recommendation of the deployment manual would be to be always connected to a full-rbf transaction-relay topology. Defaulting to this rule and your node exposes far more surface of attacks. Assuming the manual has been well-written (big assumption!), I don't think the system designer would be to blame.
> > >
> > >
> > >
> > > That said, one issue to confess with current Lightning is our lack of understanding of what should be figured out in the LN user manual for safe operations. I would say that's an active area of research [1] [2] [3]
> > >
> > >
> > >
> > > > 2)full-rbf is not default in the 2 open pull requests, so this experiment still relies on users changing RBF policies manually. If majority of nodes use default opt-in policy, how would this affect vulnerable projects?
> > >
> > >
> > >
> > > If we define the goal as ensuring there is a significant number of transaction-relay routes between the L2s nodes requiring full-rbf and the set of miners supporting this policy, and the set of miners is populated enough, there is no need to convince the majority of nodes operators to switch to full-rbf.
> > >
> > >
> > >
> > > Beyond landing the 'full-rbf' pull request, in pursuit of a partial full-rbf deployment, I'm thinking of reaching out to Lightning vendors to recommend running LN nodes operators run their full-node with the setting enabled. And also to few mining pool operators to advocate the potential increase in their income.
> > >
> > >
> > >
> > > Given there are like 17000 public LN nodes, if half of them adopt full-rbf it should give already a good number of full-rbf transaction-relay routes across the p2p network graph. When we're there, we can measure and think more about how to tune the full-rbf sub-topology.
> > >
> > >
> > >
> > > > 2-3% transactions are replaced with opt-in RBF, if someone did not replace earlier why would they do it with full RBF?
> > >
> > >
> > >
> > > Because it's breaking the reliability and security of their use-cases. Use-cases which didn't exist a few years ago. The mempool DoS vector is described here [4]. To the best of my understanding, it might affect a bunch of use-cases, such as dual-funded channels, on-chain DLCs, p2p coinjoins, batched submarine swaps out. With the attack described, the honest set of users might not have visibility of the network mempools that there is a malicious, low-cost, opt-out double-spend preventing the propagation of their multi-party transaction. With the existence of a full-rbf transaction-relay topology, the multi-party transaction is able to replace the optout.
> > >
> > >
> > >
> > > None of those use-cases were deployed a few years ago, and the understanding of the interactions with the mempool policy is still nascent among their operators. However, if we assume that layering is a way to grow the Bitcoin ecosystem, as I do, it is reasonable to expect they will constitute a notable share of the Bitcoin transaction traffic during the next decade.
> > >
> > >
> > >
> > > > I am not opposed to full-rbf; rather, I am opposed to the notion that full-rbf will solve all problems
> > >
> > >
> > >
> > > I wished we had a magic Silver Bullet (tm) solving all the Bitcoin problems...
> > >
> > >
> > >
> > > I'm only advocating a partial full-rbf deployment to solve a real precise security issue affecting multi-party funded transactions. That said, full-rbf is far from solving the known set of problems affecting the L2s due to interactions with network mempools. E,g, see package relay motivation [5]
> > >
> > >
> > >
> > > > I would suggest users to try Bitcoin Knots instead which already has an option to disable all RBF policies if required, opt-in and full RBF policy.
> > >
> > >
> > >
> > > Selecting a full-node to underpin any serious Bitcoin infrastructure or secure a significant stack of coins should be submitted to a fully-fledged decision-making process. Many factors are likely to matter such as the level of activity of the contributor community, the chain of trust w.r.t dependencies, the security incident track records, the quality of the documentation, the exhaustivity and robustness of the set of features, ...
> > >
> > >
> > >
> > > This process might take tens of hours, to be duplicated by the number of node operators who would have to do the full-node vending switch. If you consider the cognitive cost at the level of the Bitcoin ecosystem, it's far less costly to implement and review a few lines of codes in Bitcoin Core.
> > >
> > >
> > >
> > > > Developers should provide basic RBF policy options rather than attempting to define what constitutes a good policy and removing the ability to disable something when necessary.
> > >
> > >
> > >
> > > Of course, this statement assumes there is a clear line between the developers and the users. Developers are also Bitcoin users, and they're modifying the software to suit their use-case needs. And that's exactly the purpose of the 'full-rbf' PR I'm proposing, aiming to propose a "good" policy for a Lightning node, without actually seeking to change the default. If they're parties interested in implementing more RBF policy options in Bitcoin Core, I think they're free to propose such changes and invest the engineering effort to do so. If you're interested in advancing the state of policy options in Bitcoin Core, there are a lot of interesting resources available and communities to encourage you in the learning process to contribute to the codebase [6].
> > >
> > >
> > >
> > > Antoine
> > >
> > >
> > >
> > > [0] https://dirtycow.ninja
> > >
> > > [1] https://github.com/t-bast/lightning-docs/blob/master/pinning-attacks.md
> > >
> > > [2] https://arxiv.org/pdf/2006.01418.pdf
> > >
> > > [3] https://arxiv.org/pdf/2006.08513.pdf
> > >
> > > [4] https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html
> > >
> > > [5] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020493.html
> > >
> > > [6] https://www.summerofbitcoin.org
> > >
> > >
> > > Le jeu. 16 juin 2022 à 00:15, alicexbt <alicexbt at protonmail.com> a écrit :
> > >
> > > > Hi Antoine,
> > > >
> > > >
> > > > Thanks for opening the pull request to add support for full-rbf in Bitcoin Core. I have a disagreements with the approach and questions.
> > > >
> > > >
> > > > > Recent discussions among LN devs have brought back on the surface concerns about the security of multi-party funded transactions (coinjoins, dual-funded LN channels, on-chain DLCs, ...). It turns out there is a low-fruit, naive DoS vector playable against the funding flow of any such construction due to the lack of existent full-rbf transaction-relay topology on today's p2p network [0] [1].
> > > >
> > > > 1)If something relies on a policy which can be changed without breaking consensus rules, how is it secure in any case with or without full rbf? If I write a python script that expects user to enter char 'a' or 'b' but user can enter 'c' and there is no code to handle exceptions or other chars, will it be secure?
> > > >
> > > > 2)full-rbf is not default in the 2 open pull requests, so this experiment still relies on users changing RBF policies manually. If majority of nodes use default opt-in policy, how would this affect vulnerable projects?
> > > >
> > > >
> > > > > If you're a mining operator looking to increase your income, you might be interested to experiment with full-rbf as a policy.
> > > >
> > > > Miners can only increase their income if users replace transactions. 2-3% transactions are replaced with opt-in RBF, if someone did not replace earlier why would they do it now even with full RBF? Or even if we add some users in it who could not signal for some reasons, do you think it would be anything above 5%?
> > > >
> > > >
> > > > > If you're a Bitcoin user or business and you don't like full-rbf, please express an opinion on how it might affect your software/operations. I'm always interested to learn more about mempool and transaction-relay interactions with upper-layers and applications and to listen to feedback in those areas, and I guess a lot of other Bitcoin researchers/devs too. I know there have been a lot of concerns about full-rbf in the past, however I believe the Bitcoin ecosystem has matured a lot since then.
> > > >
> > > > I am not opposed to full-rbf; rather, I am opposed to the notion that full-rbf will solve all problems and the lack of basic options in Bitcoin Core to employ/disable different RBF policies. There is also a speculation about making full RBF default in an year which isn't relevant to discuss at this point without trying different RBF policies.
> > > >
> > > > I would suggest users to try Bitcoin Knots instead which already has an option to disable all RBF policies if required, opt-in and full RBF policy. This can also be done using GUI if not familiar with config option `mempoolreplacement`.
> > > >
> > > > The rationale in PR #16171 was insufficient to justify removing it in the first place, had 2 NACKs and was reopened to merge it. Why bother with a few lines of code that may allow someone disable it if required in local mempool since it's only useful when a big percentage of miners utilize it and essentially underused according to the PR author? Developers should provide basic RBF policy options rather than attempting to define what constitutes a good policy and removing the ability to disable something when necessary.
> > > >
> > > >
> > > > /dev/fd0
> > > >
> > > >
> > > > Sent with Proton Mail secure email.
> > > >
> > > > ------- Original Message -------
> > > > On Tuesday, June 14th, 2022 at 5:55 AM, Antoine Riard via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > > >
> > > >
> > > > > Hi list,
> > > > >
> > > > > Recent discussions among LN devs have brought back on the surface concerns about the security of multi-party funded transactions (coinjoins, dual-funded LN channels, on-chain DLCs, ...). It turns out there is a low-fruit, naive DoS vector playable against the funding flow of any such construction due to the lack of existent full-rbf transaction-relay topology on today's p2p network [0] [1]. While it does not consist in a direct loss of funds, if exploited well I think it's annoying enough to inflict significant timevalue loss or fee-bumping waste
> > > > > to the future providers or distributed swarm of users doing multi-party funded transactions. Of course, it can be fixed one layer above by introducing either fidelity bonds or a reliable centralized coordinator, though at the price of an overhead per-participant ressources cost and loss in system openness [1].
> > > > >
> > > > > For that reason, I believe it would be beneficial to the flourishing of multi-party funded transactions to fix the Dos vector by seeing a subset of the network running full-rbf and enabling propagation of honest multi-party transactions to the interested miners, replacing potential non-signaling double-spend from a malicious counterparty. Moving towards that direction, I've submitted a small patch against Bitcoin Core enabling it to turn on full-rbf as a policy, still under review [3]. The default setting stays **false**, i.e keeping opt-in RBF as a default replacement policy. I've started to run the patch on a public node at 146.190.224.15.
> > > > >
> > > > > If you're a node operator curious to play with full-rbf, feel free to connect to this node or spawn up a toy, public node yourself. There is a ##uafrbf libera chat if you would like information on the settings or looking for full-rbf friends (though that step could be automated in the future by setting up a dedicated network bit and reserving a few outbound slots for them).
> > > > >
> > > > > If you're a mining operator looking to increase your income, you might be interested to experiment with full-rbf as a policy. Indeed, in the future I believe the multi-party transactions issuers who need full-rbf to secure their funding flow should connect by default to full-rbf peers. One can conjecture that their transactions are likely to be more compelling in their feerate as their liquidity needs are higher than the simple transaction. For today, I think we have really few standards and bitcoin softwares relying on multi-party funded transactions [4].
> > > > >
> > > > > If you're a Bitcoin user or business and you don't like full-rbf, please express an opinion on how it might affect your software/operations. I'm always interested to learn more about mempool and transaction-relay interactions with upper-layers and applications and to listen to feedback in those areas, and I guess a lot of other Bitcoin researchers/devs too. I know there have been a lot of concerns about full-rbf in the past, however I believe the Bitcoin ecosystem has matured a lot since then.
> > > > >
> > > > > Any mistakes or missing context is my own.
> > > > >
> > > > > Cheers,
> > > > > Antoine
> > > > >
> > > > > [0] For more info about replace-by-fee, see https://bitcoinops.org/en/topics/replace-by-fee/
> > > > >
> > > > > [1] For more details about the DoS vector, see https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html
> > > > >
> > > > > [2] E.g I think it does not affect the Lightning Pool service, as there is a preliminary step where the participant funds are locked first in a 2-of-2 with the coordinator before being committed in the multi-party batch transaction.
> > > > >
> > > > > [3] https://github.com/bitcoin/bitcoin/pull/25353
> > > > >
> > > > > [4] E.g DLCs : https://github.com/discreetlogcontracts/dlcspecs/blob/master/Transactions.md ; Lightning dual-funded channel : https://github.com/lightning/bolts/pull/851

📅 Original date posted:2022-06-17 📝 Original message:Hi ...

2023-06-08T01:10:33+02:00

In reply to nevent1q…exv0
_________________________

📅 Original date posted:2022-06-17
📝 Original message:Hi Antoine,

> One could list the operating system on which is running your Lightning process or the compiler toolchain turning outyour Lightning source code in a binary artifact. Some weird kernel's memory mapping change could allow access toyour channel funding keys, _without_ breaking the Bitcoin consensus rules [0].

Lets consider there are 2 users with name Bob (normal LN user) and Carol (attacker running LN node) which I will use in this email for examples. In this case Bob and Carol can manage security of their OS and it is not affected by others using vulnerable systems or OS.

> Moreover, your Lightning node is alsorelying on the existence of a global Internet allowing your HTLC transaction to flow from your physical hostto the crowd of transactions confirming in the blockchain. Due to this "protocol assumption" your channel balancewould be vulnerable to any change in your ISP routing policy, e.g refusing to accept your IPV4 traffic by a suddendesiderata to impose an IPV6 supremacy. Still _without_ breaking the Bitcoin consensus rules. Of course, the odds ofyour ISP operator adopting this behavior are really low, mostly because your operator has to bind to social andeconomic constraints to stay in business.

The odds are low as you said, this can be managed by Bob and Carol because they can use a better ISP. Others using ISP with some issues may not affect their LN usage.

> And I believe this imperative to stay in business is certainly not absent in the incentives of the Bitcoin nodeoperators. You're free to run any policy on your node, especially one hardening the safety of your operationsbeyond the default one. However, if you start to a transaction-relay non-compatible with miner incentives, youwon't have an efficient view of the blockspace demand, and from then won't be able to offer compelling feeratesto execute your business transactions to satisfy your client needs. Or you won't consolidate yourwallet UTXOs attimesof low-demand. Indeed, a sane visibility of the mempools might not be critical now foryour Bitcoin operations, but this is not likely to become true with miner's coinbase reward lowering with timeand the system securityrelyingon a fruitful fee market.

Bob might use full-rbf as its suggested by LN developers for secure LN usage and better for miners. Carol could use a different RBF policy for some nodes and mining. In this case Bob may get affected at some point because of Carol's choice to use a different RBF policy which was not true above.

> So assuming there is a significant number of economically rational entities running p2p nodes, I think it's areasonable assumption for Lightning developers that a policy maximizing miner's income and economic nodesoperations will be widely run on the p2p network, and therefore lay its security model on that. When there is agap between the economically optimal policy (full-rbf) and the effectively deployed one (optin), and this gapconstitutes a flaw for exploitation, I believe it's better to fix it.

Agree with the assumption there is nothing wrong in experimenting with a new RBF policy (non-default) if that helps some users and projects.

> If you have a different mode of thinking w.r.t how we should design protocol in a trust-minimized, open,adversarialenvironment such as Bitcoin, I'm curious to listen to it.

Allowing users to create different mempool policies is great. My thought process is to code for happy path, where X policy is expected for replacement and edge cases where Y policy or no policy would be used. Users can try out different policies and even act as attackers. This is also true for other things in mempool, 'spkreuse=conflict' prevents address reuse in the mempool when using knots. If I assume that address reuse is always relayed, this could become a problem if some users and miners adopt this setting in their mempool.

> Of course not. If you deliver any critical software, you should attach a solid manual explaining all thecorner cases and rough edges. Even better would be to enshrine the manual directly in your software APIto minimize the footgunish behaviors. E.g, with any ECC library, forbidding to reuse nonces. If youruserstill ignores or misread the manual and provides an insecure input, there isnot thatmuch you can do.

Agree with the documentation as it helps users.

> Given there are like 17000 public LN nodes, if half of them adopt full-rbf it should givealready a good number of full-rbf transaction-relay routes across the p2p network graph.When we're there, we can measure and think more about how to tune the full-rbf sub-topology.

Sounds good.

> Because it's breaking the reliability and security of their use-cases. Use-cases which didn't exista few years ago. The mempool DoS vector is described here [4]. To the best of my understanding, it mightaffect a bunch of use-cases, such as dual-funded channels, on-chain DLCs, p2pcoinjoins, batched submarineswaps out. With the attack described, the honest set of users might not have visibility of the networkmempools that there is a malicious, low-cost, opt-out double-spend preventing the propagation of their multi-partytransaction. With the existence of a full-rbf transaction-relay topology, the multi-party transactionis able to replace theoptout.

This makes sense and I would be interested to follow two things once full-rbf is available in a bitcoin core release: 1. Percentage of transaction getting replaced 2. Miners profit (Fee for replaced Tx - Fee for original Tx)

Can you explain how p2p coinjoin is affected with mempool DoS vector with some examples? What is considered a p2p coinjoin? Joinmarket or [Stonewall][1]?

> Selecting a full-node to underpin any serious Bitcoin infrastructure or secure a significant stack of coinsshould be submitted to a fully-fledged decision-making process. Many factors are likely tomattersuch asthe level of activity of the contributor community, the chain of trust w.r.t dependencies, the security incident track records, the quality of the documentation, the exhaustivity and robustness of the set of features, ...

I agree that contributor community and documentation could be improved in Knots.

> Developersare also Bitcoin users, and they're modifying the software to suit their use-case needs. And that's exactlythe purpose of the 'full-rbf' PR I'm proposing, aiming to propose a "good" policy for a Lightning node, without actually seeking to change the default.

I like that default still remains opt-in and cool with different policies being tried out if that helps some users.

> If they'reparties interested in implementing more RBF policy options in Bitcoin Core, I think they're free to propose suchchanges and invest the engineering effort to do so. If you're interested in advancing the state ofpolicy options in Bitcoin Core, there are a lot of interestingresourcesavailable and communities toencourage you in the learning process to contribute to the codebase [6].

Thanks for sharing the link. I would love to see 5 RBF policies available to use in bitcoin core. I have already tried experimenting with a few on regtest and will try to open pull request if there are enough people interested to test it on other chains (testnet3, signet, mainnet)

[1]: https://docs.samourai.io/spend-tools

/dev/fd0

Sent with [Proton Mail](https://proton.me/) secure email.

------- Original Message -------
On Friday, June 17th, 2022 at 7:04 AM, Antoine Riard <antoine.riard at gmail.com> wrote:

> Hi alicexbt,
>
> Thanks for taking time to review the pull request,
>
>> 1)If something relies on a policy which can be changed without breaking consensus rules, how is it secure in any case with or without full rbf?
>
> Your Lightning node software relies on far more software and hardware components than the transaction-relay p2p network. One could list the operating system on which is running your Lightning process or the compiler toolchain turning out your Lightning source code in a binary artifact. Some weird kernel's memory mapping change could allow access to your channel funding keys, _without_ breaking the Bitcoin consensus rules [0]. Moreover, your Lightning node is also relying on the existence of a global Internet allowing your HTLC transaction to flow from your physical host to the crowd of transactions confirming in the blockchain. Due to this "protocol assumption" your channel balance would be vulnerable to any change in your ISP routing policy, e.g refusing to accept your IPV4 traffic by a sudden desiderata to impose an IPV6 supremacy. Still _without_ breaking the Bitcoin consensus rules. Of course, the odds of your ISP operator adopting this behavior are really low, mostly because your operator has to bind to social and economic constraints to stay in business.
>
> And I believe this imperative to stay in business is certainly not absent in the incentives of the Bitcoin node operators. You're free to run any policy on your node, especially one hardening the safety of your operationsbeyond the default one. However, if you start to a transaction-relay non-compatible with miner incentives, you won't have an efficient view of the blockspace demand, and from then won't be able to offer compelling feerates to execute your business transactions to satisfy your client needs. Or you won't consolidate your wallet UTXOs at times of low-demand. Indeed, a sane visibility of the mempools might not be critical now for your Bitcoin operations, but this is not likely to become true with miner's coinbase reward lowering with time and the system security relying on a fruitful fee market.
>
> So assuming there is a significant number of economically rational entities running p2p nodes, I think it's a reasonable assumption for Lightning developers that a policy maximizing miner's income and economic nodes operations will be widely run on the p2p network, and therefore lay its security model on that. When there is a gap between the economically optimal policy (full-rbf) and the effectively deployed one (optin), and this gap constitutes a flaw for exploitation, I believe it's better to fix it.
>
> If you have a different mode of thinking w.r.t how we should design protocol in a trust-minimized, open, adversarialenvironment such as Bitcoin, I'm curious to listen to it.
>
>> If I write a python script that expects user to enter char 'a' or 'b' but user can enter 'c' and there is no code to handle exceptions or other chars, will it be secure?
>
> Of course not. If you deliver any critical software, you should attach a solid manual explaining all the corner cases and rough edges. Even better would be to enshrine the manual directly in your software API to minimize the footgunish behaviors. E.g, with any ECC library, forbidding to reuse nonces. If your user still ignores or misread the manual and provides an insecure input, there is not that much you can do.
>
> By analogy, I believe that's the same with Lightning. One recommendation of the deployment manual would be to be always connected to a full-rbf transaction-relay topology. Defaulting to this rule and your node exposes far more surface of attacks. Assuming the manual has been well-written (big assumption!), I don't think the system designer would be to blame.
>
> That said, one issue to confess with current Lightning is our lack of understanding of what should be figured out in the LN user manual for safe operations. I would say that's an active area of research [1] [2] [3]
>
>> 2)full-rbf is not default in the 2 open pull requests, so this experiment still relies on users changing RBF policies manually. If majority of nodes use default opt-in policy, how would this affect vulnerable projects?
>
> If we define the goal as ensuring there is a significant number of transaction-relay routes between the L2s nodes requiring full-rbf and the set of miners supporting this policy, and the set of miners is populated enough, there is no need to convince the majority of nodes operators to switch to full-rbf.
>
> Beyond landing the 'full-rbf' pull request, in pursuit of a partial full-rbf deployment, I'm thinking of reaching out to Lightning vendors to recommend running LN nodes operatorsrun their full-node with the setting enabled. And also to few mining pool operators to advocate the potential increase in their income.
>
> Given there are like 17000 public LN nodes, if half of them adopt full-rbf it should give already a good number of full-rbf transaction-relay routes across the p2p network graph. When we're there, we can measure and think more about how to tune the full-rbf sub-topology.
>
>> 2-3% transactions are replaced with opt-in RBF, if someone did not replace earlier why would they do it with full RBF?
>
> Because it's breaking the reliability and security of their use-cases. Use-cases which didn't exist a few years ago. The mempool DoS vector is described here [4]. To the best of my understanding, it might affect a bunch of use-cases, such as dual-funded channels, on-chain DLCs, p2p coinjoins, batched submarine swaps out. With the attack described, the honest set of users might not have visibility of the network mempools that there is a malicious, low-cost, opt-out double-spend preventing the propagation of their multi-party transaction. With the existence of a full-rbf transaction-relay topology, the multi-party transaction is able to replace the optout.
>
> None of those use-cases were deployed a few years ago, and the understanding of the interactions with the mempool policy is still nascent among their operators. However, if we assume that layering is a way to grow the Bitcoin ecosystem, as I do, it is reasonable to expect they will constitute a notable share of the Bitcoin transaction traffic during the next decade.
>
>> I am not opposed to full-rbf; rather, I am opposed to the notion that full-rbf will solve all problems
>
> I wished we had a magic Silver Bullet (tm) solving all the Bitcoin problems...
>
> I'm only advocating a partial full-rbf deployment to solve a real precise security issue affecting multi-party funded transactions. That said, full-rbf is far from solving the known set of problems affecting the L2s due to interactions with network mempools. E,g, see package relay motivation [5]
>
>> I would suggest users to try Bitcoin Knots instead which already has an option to disable all RBF policies if required, opt-in and full RBF policy.
>
> Selecting a full-node to underpin any serious Bitcoin infrastructure or secure a significant stack of coins should be submitted to a fully-fledged decision-making process. Many factors are likely to matter such as the level of activity of the contributor community, the chain of trust w.r.t dependencies, the security incident track records, the quality of the documentation, the exhaustivity and robustness of the set of features, ...
>
> This process might take tens of hours, to be duplicated by the number of node operators who would have to do the full-node vending switch. If you consider the cognitive cost at the level of the Bitcoin ecosystem, it's far less costly to implement and review a few lines of codes in Bitcoin Core.
>
>> Developers should provide basic RBF policy options rather than attempting to define what constitutes a good policy and removing the ability to disable something when necessary.
>
> Of course, this statement assumes there is a clear line between the developers and the users. Developers are also Bitcoin users, and they're modifying the software to suit their use-case needs. And that's exactly the purpose of the 'full-rbf' PR I'm proposing, aiming to propose a "good" policy for a Lightning node, without actually seeking to change the default. If they're parties interested in implementing more RBF policy options in Bitcoin Core, I think they're free to propose such changes and invest the engineering effort to do so. If you're interested in advancing the state of policy options in Bitcoin Core, there are a lot of interesting resources available and communities to encourage you in the learning process to contribute to the codebase [6].
>
> Antoine
>
> [0] https://dirtycow.ninja
>
> [1] https://github.com/t-bast/lightning-docs/blob/master/pinning-attacks.md
>
> [2] https://arxiv.org/pdf/2006.01418.pdf
>
> [3] https://arxiv.org/pdf/2006.08513.pdf
>
> [4] https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html
>
> [5] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020493.html
>
> [6] https://www.summerofbitcoin.org
>
> Le jeu. 16 juin 2022 à 00:15, alicexbt <alicexbt at protonmail.com> a écrit :
>
>> Hi Antoine,
>>
>> Thanks for opening the pull request to add support for full-rbf in Bitcoin Core. I have a disagreements with the approach and questions.
>>
>>> Recent discussions among LN devs have brought back on the surface concerns about the security of multi-party funded transactions (coinjoins, dual-funded LN channels, on-chain DLCs, ...). It turns out there is a low-fruit, naive DoS vector playable against the funding flow of any such construction due to the lack of existent full-rbf transaction-relay topology on today's p2p network [0] [1].
>>
>> 1)If something relies on a policy which can be changed without breaking consensus rules, how is it secure in any case with or without full rbf? If I write a python script that expects user to enter char 'a' or 'b' but user can enter 'c' and there is no code to handle exceptions or other chars, will it be secure?
>>
>> 2)full-rbf is not default in the 2 open pull requests, so this experiment still relies on users changing RBF policies manually. If majority of nodes use default opt-in policy, how would this affect vulnerable projects?
>>
>>> If you're a mining operator looking to increase your income, you might be interested to experiment with full-rbf as a policy.
>>
>> Miners can only increase their income if users replace transactions. 2-3% transactions are replaced with opt-in RBF, if someone did not replace earlier why would they do it now even with full RBF? Or even if we add some users in it who could not signal for some reasons, do you think it would be anything above 5%?
>>
>>> If you're a Bitcoin user or business and you don't like full-rbf, please express an opinion on how it might affect your software/operations. I'm always interested to learn more about mempool and transaction-relay interactions with upper-layers and applications and to listen to feedback in those areas, and I guess a lot of other Bitcoin researchers/devs too. I know there have been a lot of concerns about full-rbf in the past, however I believe the Bitcoin ecosystem has matured a lot since then.
>>
>> I am not opposed to full-rbf; rather, I am opposed to the notion that full-rbf will solve all problems and the lack of basic options in Bitcoin Core to employ/disable different RBF policies. There is also a speculation about making full RBF default in an year which isn't relevant to discuss at this point without trying different RBF policies.
>>
>> I would suggest users to try Bitcoin Knots instead which already has an option to disable all RBF policies if required, opt-in and full RBF policy. This can also be done using GUI if not familiar with config option mempoolreplacement.
>>
>> The rationale in PR #16171 was insufficient to justify removing it in the first place, had 2 NACKs and was reopened to merge it. Why bother with a few lines of code that may allow someone disable it if required in local mempool since it's only useful when a big percentage of miners utilize it and essentially underused according to the PR author? Developers should provide basic RBF policy options rather than attempting to define what constitutes a good policy and removing the ability to disable something when necessary.
>>
>> /dev/fd0
>>
>> Sent with [Proton Mail](https://proton.me/) secure email.
>>
>> ------- Original Message -------
>> On Tuesday, June 14th, 2022 at 5:55 AM, Antoine Riard via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> Hi list,
>>>
>>> Recent discussions among LN devs have brought back on the surface concerns about the security of multi-party funded transactions (coinjoins, dual-funded LN channels, on-chain DLCs, ...). It turns out there is a low-fruit, naive DoS vector playable against the funding flow of any such construction due to the lack of existent full-rbf transaction-relay topology on today's p2p network [0] [1]. While it does not consist in a direct loss of funds, if exploited well I think it's annoying enough to inflict significant timevalue loss or fee-bumping waste
>>> to the future providers or distributed swarm of users doing multi-party funded transactions. Of course, it can be fixed one layer above by introducing either fidelity bonds or a reliable centralized coordinator, though at the price of an overhead per-participant ressources cost and loss in system openness [1].
>>>
>>> For that reason, I believe it would be beneficial to the flourishing of multi-party funded transactions to fix the Dos vector by seeing a subset of the network running full-rbf and enabling propagation of honest multi-party transactions to the interested miners, replacing potential non-signaling double-spend from a malicious counterparty. Moving towards that direction, I've submitted a small patch against Bitcoin Core enabling it to turn on full-rbf as a policy, still under review [3]. The default setting stays **false**, i.e keeping opt-in RBF as a default replacement policy. I've started to run the patch on a public node at 146.190.224.15.
>>>
>>> If you're a node operator curious to play with full-rbf, feel free to connect to this node or spawn up a toy, public node yourself. There is a ##uafrbf libera chat if you would like information on the settings or looking for full-rbf friends (though that step could be automated in the future by setting up a dedicated network bit and reserving a few outbound slots for them).
>>>
>>> If you're a mining operator looking to increase your income, you might be interested to experiment with full-rbf as a policy. Indeed, in the future I believe the multi-party transactions issuers who need full-rbf to secure their funding flow should connect by default to full-rbf peers. One can conjecture that their transactions are likely to be more compelling in their feerate as their liquidity needs are higher than the simple transaction. For today, I think we have really few standards and bitcoin softwares relying on multi-party funded transactions [4].
>>>
>>> If you're a Bitcoin user or business and you don't like full-rbf, please express an opinion on how it might affect your software/operations. I'm always interested to learn more about mempool and transaction-relay interactions with upper-layers and applications and to listen to feedback in those areas, and I guess a lot of other Bitcoin researchers/devs too. I know there have been a lot of concerns about full-rbf in the past, however I believe the Bitcoin ecosystem has matured a lot since then.
>>>
>>> Any mistakes or missing context is my own.
>>>
>>> Cheers,
>>> Antoine
>>>
>>> [0] For more info about replace-by-fee, see https://bitcoinops.org/en/topics/replace-by-fee/
>>>
>>> [1] For more details about the DoS vector, see https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html
>>>
>>> [2] E.g I think it does not affect the Lightning Pool service, as there is a preliminary step where the participant funds are locked first in a 2-of-2 with the coordinator before being committed in the multi-party batch transaction.
>>>
>>> [3] https://github.com/bitcoin/bitcoin/pull/25353
>>>
>>> [4] E.g DLCs : https://github.com/discreetlogcontracts/dlcspecs/blob/master/Transactions.md ; Lightning dual-funded channel : https://github.com/lightning/bolts/pull/851
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220617/3e36bd4e/attachment-0001.html>;

📅 Original date posted:2022-06-16 📝 Original message:Hi ...

2023-06-08T01:10:31+02:00

In reply to nevent1q…kqv8
_________________________

📅 Original date posted:2022-06-16
📝 Original message:Hi cndm1,

> If you see a "lack of basic options" and no one has opened a pull request for it, it may be for two reasons.

The basic option to disable all RBF policies in a node's mempool if required was removed in [PR #16171][1]. No one has opened a pull request to revert this because most of the maintainers and a few reviewers agreed with this change. It wasn't required, PR had weak rationale, 2 NACKS and was reopened to merge because some reviewers/maintainers believe its a policy that cannot be maintained. One of the reviewers who NACKed it already maintains the config option to disable all RBF policies in Bitcoin Knots which is a derivative of Bitcoin Core.

> However, repeatedly demanding others to do it for you is not helpful in open source software development.

I am not demanding anyone to add a few lines of code and open a pull request. I am _reviewing_ a pull request in an open source project and sharing my feedback. Even Antoine and Luke agreed to add it if other reviewers have no issues or I can do it. This option in context with another being added for a new RBF policy was being discussed in [PR #25353][2] and my earlier emails in this thread.

Other 'basic options' will be easier to accommodate with `-mempoolreplacement` used in [PR #25373] which is unlikely to be merged.

[1]: https://github.com/bitcoin/bitcoin/pull/16171
[2]: https://github.com/bitcoin/bitcoin/pull/25353
[3]: https://github.com/bitcoin/bitcoin/pull/25373

/dev/fd0

Sent with Proton Mail secure email.

------- Original Message -------
On Thursday, June 16th, 2022 at 11:13 AM, linuxfoundation.cndm1--- via bitcoin-dev bitcoin-dev at lists.linuxfoundation.org wrote:

> alicexbt wrote:
>
> > I do not have issues with multiple RBF policies being tried out and full-rbf being one of them. My disagreements are with rationale, lack of basic options in Bitcoin Core to employ/disable different RBF policies and a few arguments made in support for full-rbf. Whether it appears strawman or offtopic on github, there should be a place to share these disagreements.
>
> Bitcoin Core is open source software, where developers open pull
> requests to try to get them merged after review. If you see a "lack of
> basic options" and no one has opened a pull request for it, it may be
> for two reasons. First, it could be that it just doesn't make sense,
> so no one sees a point in implementing it. Secondly, it may be that it
> isn't on anyone's list of priorities. In the second case, you are
> welcome to share your preference once. Moreover, no one is holding you
> back to implement it yourself and suggest a pull request. However,
> repeatedly demanding others to do it for you is not helpful in open
> source software development.
>
> cndm1
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

📅 Original date posted:2022-06-12 📝 Original message:Hi ...

2023-06-08T01:10:05+02:00

In reply to nevent1q…t0d4
_________________________

📅 Original date posted:2022-06-12
📝 Original message:Hi Peter,

> Only because the block reward goes away. If it was made to continue
> indefinitely - most likely with an inflation hard fork - demand for block space
> would not be critical to Bitcoin's security.

I am not completely against your proposal although 100% sure this will not have "consensus" to be implemented. I think if bitcoin doesn't have enough demand for block space, it should die. I will be sad if bitcoin doesn't exist but it should be a lesson for all the people opposing soft forks based on drama and politics instead of technical review.

I don't see anything wrong with users paying 100x fees for opening and closing LN channels.

/dev/fd0

Sent with Proton Mail secure email.

------- Original Message -------
On Sunday, June 12th, 2022 at 9:06 AM, Peter Todd via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:

> On Mon, Jun 06, 2022 at 09:02:18AM -0400, Erik Aronesty via bitcoin-dev wrote:
>
> > Maintaining the security of the protocol is squarely the responsibility of
> > the Bitcoin software and the core developers
> >
> > Continued demand for block space is critical for Bitcoin's security.
>
>
> Only because the block reward goes away. If it was made to continue
> indefinitely - most likely with an inflation hard fork - demand for block space
> would not be critical to Bitcoin's security.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

📅 Original date posted:2022-06-04 📝 Original message:Hi ...

2023-06-08T01:10:03+02:00

In reply to nevent1q…asln
_________________________

📅 Original date posted:2022-06-04
📝 Original message:Hi John,

> Core development is not a hackathon project.
>
> None of the quoted following items are features or responsibilities of the Bitcoin software, nor Core developers

Core development was never listed as a hackathon project. Although I did not share responsibilities, they will improve bitcoin development. Bitcoin isn't only about "core developers" and I contribute to that repository.

> Whether you are a child or an attacker, none of us should care, but CTV, nor any change to Bitcoin software, will never be justifiable simply because you and some of your friends think it is totally cool and might make more people like you or give your friends funding.

These are not my friends and I don't know any of them in real life:

https://utxos.org/signals/

Also the developers who are competent enough to understand code and soft forks that participated in CTV meetings are not my friends. Funding is a real issue for bitcoin developers, you would know if were a developer and these opportunities won't be available for me and my friends but everyone.

> Please stop making noise about CTV, this is not a place for spamming.

Let me share one example of spamming and noise:

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020409.html

I am aware of the things that you post on twitter and your thoughts about developers, author of BIP 119 and the way you would propose changes although not interested to debate anything related to bitcoin development with you as its a waste of time:

https://nitter.net/BitcoinErrorLog/status/1407312037408038919

/dev/fd0

Sent with [Proton Mail](https://proton.me/) secure email.

------- Original Message -------
On Saturday, June 4th, 2022 at 5:57 PM, John Carvalho via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:

> Core development is not a hackathon project.
>
> None of the quoted following items are features or responsibilities of the Bitcoin software, nor Core developers.
>
> Quoted:
> "- Developers can build interesting projects with real demand in market.
> - Students learn Sapio and not just solidity.
> - Better tooling could be available for application developers.
> - Maybe we see bitcoin developer hackathons in different countries.
> - Demand for block space might increase, it wont be just exchanges and coinjoin.
> - Funding of bitcoin developers and projects might improve. Wont need to convince a few people for grants."
>
> Whether you are a child or an attacker, none of us should care, but CTV, nor any change to Bitcoin software, will never be justifiable simply because you and some of your friends think it is totally cool and might make more people like you or give your friends funding.
>
> Please stop making noise about CTV, this is not a place for spamming.
>
> --
>
> John Carvalho
>
> On Sat, Jun 4, 2022 at 1:00 PM <bitcoin-dev-request at lists.linuxfoundation.org> wrote:
>
>> Date: Fri, 03 Jun 2022 18:39:34 +0000
>> From: alicexbt <alicexbt at protonmail.com>
>> To: Bitcoin Protocol Discussion
>> <bitcoin-dev at lists.linuxfoundation.org>
>> Subject: [bitcoin-dev] Bitcoin covenants are inevitable
>> Message-ID:
>> <QOWIpROGDv5HHP2GsDiSOsTJ9TVZhFeSP3C03_e2Z3XtOKC_4N5GJtxbdlxuhErvhLZXo1Rn_7SWAQ9XRPwHFuYyArZryTVENefDZuGTAYA=@protonmail.com>
>>
>> Content-Type: text/plain; charset=utf-8
>>
>> Note: This email is an opinion and not an attack on bitcoin
>>
>> Covenants on bitcoin will eventually be implemented with a soft fork. CTV is the easiest and best possible way OP_TX looks good as well. Apart from the technical merits, covenants will improve a few other things:
>>
>> - Developers can build interesting projects with real demand in market.
>> - Students learn Sapio and not just solidity.
>> - Better tooling could be available for application developers.
>> - Maybe we see bitcoin developer hackathons in different countries.
>> - Demand for block space might increase, it wont be just exchanges and coinjoin.
>> - Funding of bitcoin developers and projects might improve. Wont need to convince a few people for grants.
>>
>> **Why covenants are not contentious?**
>>
>> Some people may write paragraphs about CTV being contentious, spread misinformation and do all types of drama, politics etc. on social media but there are zero technical NACKs for CTV. We have discussed other covenant proposals in detail on mailing list and IRC meetings with an open minded approach.
>>
>> All the developers that participated in the discussion are either okay with CTV or OP_TX or covenants in general.
>>
>> **How and when should covenants be implemented in Bitcoin?**
>>
>> I don't think we should wait for years anticipating a proposal that everyone will agree on or argue for years to pretend changes are hard in Bitcoin. We should improve the review process for soft fork BIPs and share honest opinions with agreement, disagreement on technical merits.
>>
>> I prefer BIP 8 or improved BIP 8 for soft fork but I won't mind anything else being used if that improves Bitcoin. Covenants implemented in Bitcoin before the next cycle would provide opportunity for developers to build interesting things during the bear market. Ossification supporters also believe there is some window that will close soon, maybe doing changes considering each case individually will be a better approach. CTV is not a rushed soft fork, less people followed the research and it was not mentioned on social media repeatedly by the respected developers like other soft forks.
>>
>> /dev/fd0
>>
>> Sent with Proton Mail secure email.
>>
>> ------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220604/676aca8b/attachment-0001.html>;

📅 Original date posted:2022-06-03 📝 Original message:Note: ...

2023-06-08T01:10:01+02:00

In reply to nevent1q…ufqz
_________________________

📅 Original date posted:2022-06-03
📝 Original message:Note: This email is an opinion and not an attack on bitcoin

Covenants on bitcoin will eventually be implemented with a soft fork. CTV is the easiest and best possible way OP_TX looks good as well. Apart from the technical merits, covenants will improve a few other things:

- Developers can build interesting projects with real demand in market.
- Students learn Sapio and not just solidity.
- Better tooling could be available for application developers.
- Maybe we see bitcoin developer hackathons in different countries.
- Demand for block space might increase, it wont be just exchanges and coinjoin.
- Funding of bitcoin developers and projects might improve. Wont need to convince a few people for grants.

**Why covenants are not contentious?**

Some people may write paragraphs about CTV being contentious, spread misinformation and do all types of drama, politics etc. on social media but there are zero technical NACKs for CTV. We have discussed other covenant proposals in detail on mailing list and IRC meetings with an open minded approach.

All the developers that participated in the discussion are either okay with CTV or OP_TX or covenants in general.

**How and when should covenants be implemented in Bitcoin?**

I don't think we should wait for years anticipating a proposal that everyone will agree on or argue for years to pretend changes are hard in Bitcoin. We should improve the review process for soft fork BIPs and share honest opinions with agreement, disagreement on technical merits.

I prefer BIP 8 or improved BIP 8 for soft fork but I won't mind anything else being used if that improves Bitcoin. Covenants implemented in Bitcoin before the next cycle would provide opportunity for developers to build interesting things during the bear market. Ossification supporters also believe there is some window that will close soon, maybe doing changes considering each case individually will be a better approach. CTV is not a rushed soft fork, less people followed the research and it was not mentioned on social media repeatedly by the respected developers like other soft forks.

/dev/fd0

Sent with Proton Mail secure email.

📅 Original date posted:2022-05-11 📝 Original message:Hi ...

2023-06-08T01:09:32+02:00

In reply to nevent1q…yk9w
_________________________

📅 Original date posted:2022-05-11
📝 Original message:Hi Billy,

Thanks for the feedback. I agree with everything and bip-trinary-version-signaling looks interesting.

> A primary difference from both BIP8 and BIP9 is that this proposal uses tri-state version signaling (rather than binary version bits) that can encode both active support as well as active opposition to an active soft fork.

I think 'support' and 'opposition' can be replaced with readiness. Miners should not consider signaling as voting.

> The meaning for each ternary value is as follows:

0 - No signal
1 - Ready for new consensus rules
2 - Not ready for new consensus rules

The concept of a minimum and maximum threshold sounds intriguing, and I'm interested to read what other developers have to say about it.

Concept ACK on removing LOT, using tri-state version signaling, min/max threshold and required threshold calculation.

/dev/fd0

Sent with ProtonMail secure email.
------- Original Message -------
On Tuesday, May 10th, 2022 at 9:01 PM, Billy Tetrud billy.tetrud at gmail.com wrote:

> 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 specify this as minimum_activation_blocks, ie a number of blocks passed the start_height. Slightly easier to reason about and change when necessary. I proposed semantics like that here.
> > In any case, I'll give this a concept ACK. I would very much like future soft forks to use a previously specified activation mechanism rather than rolling out a rushed unspeced thing as part of the (very orthogonal) soft fork implementation.
> > On Tue, May 10, 2022 at 9:02 AM alicexbt via bitcoin-dev bitcoin-dev at lists.linuxfoundation.org wrote:
>
> > 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 calculating MUST_SIGNAL state based on threshold reached.
> >
> > BIP draft with no code and some changes in BIP 8: https://gist.github.com/1440000bytes/5e58cad7ba9d9c1a7000d304920fe6f1
> >
> > State transitions diagram:
> >
> > This proposal removes lockinontimeout flag, activation never fails although MUST_SIGNAL can be longer if miners signaling does not reach the threshold. Longer period for MUST_SIGNAL state is useful for coordination if LOCKED_IN was not reached.
> >
> > MUST_SIGNAL = ((100-t)/10)*2016 blocks, where t is threshold reached and blocks that fail to signal in MUST_SIGNAL phase are invalid.
> >
> > Example:
> >
> > - This activation method is used for a soft fork
> > - Only 60% miners signaled readiness and timeout height was reached
> > - MUST_SIGNAL phase starts and will last for 4*2016 blocks
> > - LOCKED_IN and ACTIVE states remain same as BIP 8
> > - Soft fork is activated with a delay of 2 months
> >
> > /dev/fd0
> >
> > Sent with ProtonMail secure email._______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

📅 Original date posted:2022-05-10 📝 Original message:Hi ...

2023-06-08T01:09:31+02:00

In reply to nevent1q…nd0r
_________________________

📅 Original date posted:2022-05-10
📝 Original message: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 calculating MUST_SIGNAL state based on threshold reached.

BIP draft with no code and some changes in BIP 8: https://gist.github.com/1440000bytes/5e58cad7ba9d9c1a7000d304920fe6f1

State transitions diagram:

This proposal removes lockinontimeout flag, activation never fails although MUST_SIGNAL can be longer if miners signaling does not reach the threshold. Longer period for MUST_SIGNAL state is useful for coordination if LOCKED_IN was not reached.

MUST_SIGNAL = ((100-t)/10)*2016 blocks, where t is threshold reached and blocks that fail to signal in MUST_SIGNAL phase are invalid.

Example:

- This activation method is used for a soft fork
- Only 60% miners signaled readiness and timeout height was reached
- MUST_SIGNAL phase starts and will last for 4*2016 blocks
- LOCKED_IN and ACTIVE states remain same as BIP 8
- Soft fork is activated with a delay of 2 months

/dev/fd0

Sent with [ProtonMail](https://protonmail.com/) secure email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220510/1d4ece3d/attachment.html>;