Nostr notes by Prayank [ARCHIVE]

📅 Original date posted:2022-03-07 📝 Original message: Hello ...

2023-06-09T13:05:27Z

In reply to nevent1q…faj0
_________________________

📅 Original date posted:2022-03-07
📝 Original message:
Hello kanzure mailing list and ln mailing list,

This is my last email and I won't be involved in anything related to Bitcoin. If my username is used on GitHub or other places it can be considered someone else using it.

--
Prayank

A3B1 E430 2298 178F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220307/755aa9bc/attachment.html>;

📅 Original date posted:2022-02-14 📝 Original message: > ...

2023-06-09T13:05:16Z

In reply to nevent1q…7ptl
_________________________

📅 Original date posted:2022-02-14
📝 Original message:
> That's not an argument not to do it though if you take a longer term perspective on building the strongest possible foundation for Lightning or other Layer 2 projects. The security benefit would just be delayed until a significant majority of Bitcoin Core users upgraded to a version including those new policy rules.

1.An attacker does not require significant majority for such attacks.
2.We aren't fixing the things that are broken. We can change the policy in core several times and still not achieve the goal and maybe create new issues.

> A network where *all* full nodes are running the same policy rules is clearly not an option available to us without making policy rules effective consensus rules and forking/kicking those old versions off the network.

A network with a policy already widely used exists right now.

> Definitely agree. It is a really interesting research area and lots of opportunities for simulations and experiments on the default or custom signet networks. Especially if we fill blocks with auto-generated transactions and/or reduce block sizes and create an artificial fee market.

I don't think I can convince everyone to do this however it will be helpful. I will try a few things on regtest and share results if I find anything interesting.

--
Prayank

A3B1 E430 2298 178F

Feb 14, 2022, 22:32 by michaelfolkson at protonmail.com:

> > This is the assumption which I don't agree with and hence asked some questions in my email. A new RBF policy used by default in Core will not improve the security of projects that are vulnerable to multiple RBF policies or rely on these policies in a way that affects their security.
>
> Right, not immediately. If and when new policy rules are included in a Bitcoin Core release it would take a while before a significant majority of the network were running those new policy rules (barring some kind of urgency, an attacker exploiting a systemic security flaw etc). That's not an argument not to do it though if you take a longer term perspective on building the strongest possible foundation for Lightning or other Layer 2 projects. The security benefit would just be delayed until a significant majority of Bitcoin Core users upgraded to a version including those new policy rules.
>
> > > Bitcoin Core with different versions are used at any point and not sure if this will ever change.
>
> Sure there will always be some stray full nodes running extremely old versions but the general direction of travel is more and more full nodes upgrading to newer versions. A network where *all* full nodes are running the same policy rules is clearly not an option available to us without making policy rules effective consensus rules and forking/kicking those old versions off the network.
>
> > > Maybe some experiments on signet might help in knowing more issues associated with multiple RBF policies.
>
> Definitely agree. It is a really interesting research area and lots of opportunities for simulations and experiments on the default or custom signet networks. Especially if we fill blocks with auto-generated transactions and/or reduce block sizes and create an artificial fee market.
>
> --
> Michael Folkson
> Email: michaelfolkson at > protonmail.com <http://protonmail.com/>>; Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>
>
>
> ------- Original Message -------
> On Monday, February 14th, 2022 at 5:18 AM, Prayank <prayank at tutanota.de> wrote:
>
>
>> > I suspect as with defaults generally most users will run whatever the defaults are as they won't care to change them (or even be capable of changing them if they are very non-technical).
>>
>>
>> 30% nodes are using 0.21.1 right now whereas latest version was 22.0 and some are even running lower versions. Different versions in future with defaults might be running RBF v1 and RBF v2.
>>
>> > But users who have a stake in the security of Lightning (or other Layer 2 projects) will clearly want to run whatever policy rules are beneficial to those protocols.
>>
>>
>> Agree and attackers will want to run the nodes with policy that helps them exploit bitcoin projects. Miners can run nodes with policy that helps them get more fees.
>>
>> > As you know the vast majority of the full nodes on the network currently run Bitcoin Core. Whether that will change in future and whether this a good thing or not is a whole other discussion. But the reality is that with such strong dominance there is the option to set defaults that are widely used.
>>
>>
>> Bitcoin Core with different versions are used at any point and not sure if this will ever change.
>>
>> https://luke.dashjr.org/programs/bitcoin/files/charts/security.html
>>
>>
>>
>> > I think if certain defaults can bolster the security of Lightning (and possibly other Layer 2 projects) at no cost to full node users with no interest in those protocols we should discuss what those defaults should be.
>>
>>
>> This is the assumption which I don't agree with and hence asked some questions in my email. A new RBF policy used by default in Core will not improve the security of projects that are vulnerable to multiple RBF policies or rely on these policies in a way that affects their security.
>>
>> Maybe some experiments on signet might help in knowing more issues associated with multiple RBF policies.
>>
>> --
>> Prayank
>>
>> A3B1 E430 2298 178F
>>
>>
>>
>> Feb 13, 2022, 21:16 by michaelfolkson at protonmail.com:
>>
>>> Hi Prayank
>>>
>>> > 1.Is Lightning Network and a few other layer 2 projects vulnerable to multiple RBF policies being used?
>>>
>>> Clearly the security of the Lightning Network and some other Layer 2 projects are at least impacted or partly dependent on policy rules in a way that the base blockchain/network isn't. As I (and others) have said on many occasions ideally this wouldn't be the case but it is best we can do with current designs. I (and others) take the view that this is not a reason to abandon those designs in the absence of an alternative that offers a strictly superior security model. Going back to a model where *all* activity is onchain (or even in less trust minimized protocols than Lightning) doesn't seem like the right approach to me.
>>>
>>> > 2.With recent discussion to change things in default RBF policy used by Core, will we have multiple versions using different policies? Are users and especially miners incentivized to use different versions and policies? Do they have freedom to use different RBF policy?
>>>
>>> Without making policy rules effective consensus rules users (including miners) are free to run different policy rules. I think it is too early to say what the final incentives will be to run the same or differing policies. Research into Lightning security is still nascent and we have no idea whether alternative Layer 2 projects will thrive and whether they will have the same or conflicting security considerations to Lightning.
>>>
>>> As you know the vast majority of the full nodes on the network currently run Bitcoin Core. Whether that will change in future and whether this a good thing or not is a whole other discussion. But the reality is that with such strong dominance there is the option to set defaults that are widely used. I think if certain defaults can bolster the security of Lightning (and possibly other Layer 2 projects) at no cost to full node users with no interest in those protocols we should discuss what those defaults should be.
>>>
>>> > 3.Are the recent improvements suggested for RBF policy only focused on Lightning Network and its security which will anyway remain same or become worse with multiple RBF policies?
>>>
>>> I think by nature of the Lightning Network being the most widely adopted Layer 2 project most of the focus has been on Lightning security. But contributors to other Layer 2 projects are free to flag and discuss security considerations that aren't Lightning specific.
>>>
>>> > Note: Bitcoin Knots policy is fully configurable, even in the GUI - users can readily choose whatever policy *they* want.
>>>
>>> The maintainer(s) and contributors to Bitcoin Knots are free to determine what default policy rules they want to implement (and make it easier for users to change those defaults) in the absence of those policy rules being made effective consensus rules. I suspect there would be strong opposition to making some policy rules effective consensus rules but we are now venturing again into future speculation and none of us have a crystal ball. Certainly if you take the view that these policy rules should never be made effective consensus rules then the fact there is at least one implementation taking a contrasting approach to Core is a good thing.
>>>
>>> --
>>> Michael Folkson
>>> Email: michaelfolkson at >>> protonmail.com <http://protonmail.com/>>>>; Keybase: michaelfolkson
>>> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>>>
>>>
>>> ------- Original Message -------
>>> On Sunday, February 13th, 2022 at 6:09 AM, Prayank via Lightning-dev <lightning-dev at lists.linuxfoundation.org> wrote:
>>>
>>>
>>>> Hello World,
>>>>
>>>> There was a discussion about improving fee estimation in Bitcoin Core last year in which 'instagibbs' mentioned that we cannot consider mempool as an orderbook in which which everyone is bidding for block space because nodes can use different relay policies: https://bitcoin-irc.chaincode.com/bitcoin-core-dev/2021-09-22#706294;
>>>>
>>>> Although I still don't consider fee rates used in last few blocks relevant for fee estimation, it is possible that we have nodes with different relay policies.
>>>>
>>>> Similarly if we have different RBF policies being used by nodes in future, how would this affect the security of lightning network implementations and other layer 2 projects?
>>>>
>>>> Based on the things shared by 'aj' in
>>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019846.html it is possible for an attacker to use a different RBF policy with some nodes, 10% hash power and affect the security of different projects that rely on default RBF policy in latest Bitcoin Core.
>>>>
>>>> There was even a CVE in which RBF policy not being documented according to the implementation could affect the security of LN:
>>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-May/018893.html
>>>>
>>>> 1.Is Lightning Network and a few other layer 2 projects vulnerable to multiple RBF policies being used?
>>>>
>>>> 2.With recent discussion to change things in default RBF policy used by Core, will we have multiple versions using different policies? Are users and especially miners incentivized to use different versions and policies? Do they have freedom to use different RBF policy?
>>>>
>>>> 3.Are the recent improvements suggested for RBF policy only focused on Lightning Network and its security which will anyway remain same or become worse with multiple RBF policies?
>>>>
>>>> Note: Bitcoin Knots policy is fully configurable, even in the GUI - users can readily choose whatever policy *they* want.
>>>>
>>>> --
>>>> Prayank
>>>>
>>>> A3B1 E430 2298 178F
>>>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220214/efb7c1ba/attachment-0001.html>;

📅 Original date posted:2022-02-14 📝 Original message: > ...

2023-06-09T13:05:15Z

In reply to nevent1q…fh2g
_________________________

📅 Original date posted:2022-02-14
📝 Original message:
> I suspect as with defaults generally most users will run whatever the defaults are as they won't care to change them (or even be capable of changing them if they are very non-technical).

30% nodes are using 0.21.1 right now whereas latest version was 22.0 and some are even running lower versions. Different versions in future with defaults might be running RBF v1 and RBF v2.
> But users who have a stake in the security of Lightning (or other Layer 2 projects) will clearly want to run whatever policy rules are beneficial to those protocols.

Agree and attackers will want to run the nodes with policy that helps them exploit bitcoin projects. Miners can run nodes with policy that helps them get more fees.

> As you know the vast majority of the full nodes on the network currently run Bitcoin Core. Whether that will change in future and whether this a good thing or not is a whole other discussion. But the reality is that with such strong dominance there is the option to set defaults that are widely used.

Bitcoin Core with different versions are used at any point and not sure if this will ever change.

https://luke.dashjr.org/programs/bitcoin/files/charts/security.html

> I think if certain defaults can bolster the security of Lightning (and possibly other Layer 2 projects) at no cost to full node users with no interest in those protocols we should discuss what those defaults should be.

This is the assumption which I don't agree with and hence asked some questions in my email. A new RBF policy used by default in Core will not improve the security of projects that are vulnerable to multiple RBF policies or rely on these policies in a way that affects their security.

Maybe some experiments on signet might help in knowing more issues associated with multiple RBF policies.

--
Prayank

A3B1 E430 2298 178F

Feb 13, 2022, 21:16 by michaelfolkson at protonmail.com:

> Hi Prayank
>
> > 1.Is Lightning Network and a few other layer 2 projects vulnerable to multiple RBF policies being used?
>
> Clearly the security of the Lightning Network and some other Layer 2 projects are at least impacted or partly dependent on policy rules in a way that the base blockchain/network isn't. As I (and others) have said on many occasions ideally this wouldn't be the case but it is best we can do with current designs. I (and others) take the view that this is not a reason to abandon those designs in the absence of an alternative that offers a strictly superior security model. Going back to a model where *all* activity is onchain (or even in less trust minimized protocols than Lightning) doesn't seem like the right approach to me.
>
> > 2.With recent discussion to change things in default RBF policy used by Core, will we have multiple versions using different policies? Are users and especially miners incentivized to use different versions and policies? Do they have freedom to use different RBF policy?
>
> Without making policy rules effective consensus rules users (including miners) are free to run different policy rules. I think it is too early to say what the final incentives will be to run the same or differing policies. Research into Lightning security is still nascent and we have no idea whether alternative Layer 2 projects will thrive and whether they will have the same or conflicting security considerations to Lightning.
>
> As you know the vast majority of the full nodes on the network currently run Bitcoin Core. Whether that will change in future and whether this a good thing or not is a whole other discussion. But the reality is that with such strong dominance there is the option to set defaults that are widely used. I think if certain defaults can bolster the security of Lightning (and possibly other Layer 2 projects) at no cost to full node users with no interest in those protocols we should discuss what those defaults should be.
>
> > 3.Are the recent improvements suggested for RBF policy only focused on Lightning Network and its security which will anyway remain same or become worse with multiple RBF policies?
>
> I think by nature of the Lightning Network being the most widely adopted Layer 2 project most of the focus has been on Lightning security. But contributors to other Layer 2 projects are free to flag and discuss security considerations that aren't Lightning specific.
>
> > Note: Bitcoin Knots policy is fully configurable, even in the GUI - users can readily choose whatever policy *they* want.
>
> The maintainer(s) and contributors to Bitcoin Knots are free to determine what default policy rules they want to implement (and make it easier for users to change those defaults) in the absence of those policy rules being made effective consensus rules. I suspect there would be strong opposition to making some policy rules effective consensus rules but we are now venturing again into future speculation and none of us have a crystal ball. Certainly if you take the view that these policy rules should never be made effective consensus rules then the fact there is at least one implementation taking a contrasting approach to Core is a good thing.
>
> --
> Michael Folkson
> Email: michaelfolkson at > protonmail.com <http://protonmail.com/>>; Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>
>
> ------- Original Message -------
> On Sunday, February 13th, 2022 at 6:09 AM, Prayank via Lightning-dev <lightning-dev at lists.linuxfoundation.org> wrote:
>
>
>> Hello World,
>>
>> There was a discussion about improving fee estimation in Bitcoin Core last year in which 'instagibbs' mentioned that we cannot consider mempool as an orderbook in which which everyone is bidding for block space because nodes can use different relay policies: https://bitcoin-irc.chaincode.com/bitcoin-core-dev/2021-09-22#706294;
>>
>> Although I still don't consider fee rates used in last few blocks relevant for fee estimation, it is possible that we have nodes with different relay policies.
>>
>> Similarly if we have different RBF policies being used by nodes in future, how would this affect the security of lightning network implementations and other layer 2 projects?
>>
>> Based on the things shared by 'aj' in
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019846.html it is possible for an attacker to use a different RBF policy with some nodes, 10% hash power and affect the security of different projects that rely on default RBF policy in latest Bitcoin Core.
>>
>> There was even a CVE in which RBF policy not being documented according to the implementation could affect the security of LN:
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-May/018893.html
>>
>> 1.Is Lightning Network and a few other layer 2 projects vulnerable to multiple RBF policies being used?
>>
>> 2.With recent discussion to change things in default RBF policy used by Core, will we have multiple versions using different policies? Are users and especially miners incentivized to use different versions and policies? Do they have freedom to use different RBF policy?
>>
>> 3.Are the recent improvements suggested for RBF policy only focused on Lightning Network and its security which will anyway remain same or become worse with multiple RBF policies?
>>
>> Note: Bitcoin Knots policy is fully configurable, even in the GUI - users can readily choose whatever policy *they* want.
>>
>> --
>> Prayank
>>
>> A3B1 E430 2298 178F
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220214/fbe5af9a/attachment-0001.html>;

📅 Original date posted:2022-02-13 📝 Original message: Hello ...

2023-06-09T13:05:14Z

In reply to nevent1q…paa2
_________________________

📅 Original date posted:2022-02-13
📝 Original message:
Hello World,

There was a discussion about improving fee estimation in Bitcoin Core last year in which 'instagibbs' mentioned that we cannot consider mempool as an orderbook in which which everyone is bidding for block space because nodes can use different relay policies: https://bitcoin-irc.chaincode.com/bitcoin-core-dev/2021-09-22#706294;

Although I still don't consider fee rates used in last few blocks relevant for fee estimation, it is possible that we have nodes with different relay policies.

Similarly if we have different RBF policies being used by nodes in future, how would this affect the security of lightning network implementations and other layer 2 projects?

Based on the things shared by 'aj' in
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019846.html it is possible for an attacker to use a different RBF policy with some nodes, 10% hash power and affect the security of different projects that rely on default RBF policy in latest Bitcoin Core.

There was even a CVE in which RBF policy not being documented according to the implementation could affect the security of LN:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-May/018893.html

1.Is Lightning Network and a few other layer 2 projects vulnerable to multiple RBF policies being used?

2.With recent discussion to change things in default RBF policy used by Core, will we have multiple versions using different policies? Are users and especially miners incentivized to use different versions and policies? Do they have freedom to use different RBF policy?

3.Are the recent improvements suggested for RBF policy only focused on Lightning Network and its security which will anyway remain same or become worse with multiple RBF policies?

Note: Bitcoin Knots policy is fully configurable, even in the GUI - users can readily choose whatever policy *they* want.

--
Prayank

A3B1 E430 2298 178F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220213/2e657a89/attachment.html>;

📅 Original date posted:2021-10-12 📝 Original message: Hello ...

2023-06-09T13:04:12Z

In reply to nevent1q…shzq
_________________________

📅 Original date posted:2021-10-12
📝 Original message:
Hello everyone,

I wanted to know few things related to asset issuance on lightning:

1.Is it possible to issue assets on LN right now? If yes, what's the process and is it as easy as few commands in liquid: https://help.blockstream.com/hc/en-us/articles/900005127583-How-do-I-issue-an-asset-on-Liquid-

2.If no, is anyone working or planning to work on it?

3.I had read few things about Omni BOLT which could solve this problem but not sure about status of project and development: https://github.com/omnilaboratory/OmniBOLT-spec

Few use cases for tokens on lightning:

1.DEX2.Stablecoins3.Liquidity: If projects could incentivize users with native tokens that are associated with the project on every LN channel opened it would improve liquidity.

--
Prayank

A3B1 E430 2298 178F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211012/ae443565/attachment-0001.html>;

📅 Original date posted:2021-10-15 📝 Original message: Good ...

2023-06-09T13:04:12Z

In reply to nevent1q…upnp
_________________________

📅 Original date posted:2021-10-15
📝 Original message:
Good morning ZmnSCPxj,

> I heard before that the RGB colored coin project had plans to be compatible with Lightning so that channels could be denominated in an issued asset.

RGB will address lot of things but I was wondering if such things should exist in LN implementations by default. Example: If we had two ways to issue assets LA1 and LA2, the user can issue asset using a command: lightning-cli -named issueassets -type=LA1 -number=1000

> Blockstream I believe has plans to include support for Liquid-issued assets in C-Lightning somehow; C-Lightning already supports running on top of Liquid instead of directly on the Bitcoin blockchain layer (but still uses Bitcoin for the channel asset type)

This is interesting.

> https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-December/001752.html

Still trying to understand this problem and possible solutions. Interesting email though (TIL), thanks for sharing the link. Found related things explained Suredbits blog as well.

--
Prayank

A3B1 E430 2298 178F

Oct 13, 2021, 09:29 by ZmnSCPxj at protonmail.com:

> Good morning Prayank,
>
>> Hello everyone,
>>
>> I wanted to know few things related to asset issuance on lightning:
>>
>> 1.Is it possible to issue assets on LN right now? If yes, what's the process and is it as easy as few commands in liquid: https://help.blockstream.com/hc/en-us/articles/900005127583-How-do-I-issue-an-asset-on-Liquid-
>>
>> 2.If no, is anyone working or planning to work on it?
>>
>> 3.I had read few things about Omni BOLT which could solve this problem but not sure about status of project and development: https://github.com/omnilaboratory/OmniBOLT-spec
>>
>> Few use cases for tokens on lightning:
>>
>> 1.DEX
>> 2.Stablecoins
>> 3.Liquidity: If projects could incentivize users with native tokens that are associated with the project on every LN channel opened it would improve liquidity.
>>
>
> I heard before that the RGB colored coin project had plans to be compatible with Lightning so that channels could be denominated in an issued asset.
>
> Most plans for colored coins on Lightning generally assume that each channel has just a single asset, as that seems to be simpler, at least as a start.
> However, this complicates the use of such channels for forwarding, as we would like to restrict channel gossip to channels that *any* node can easily prove actually exist as a UTXO onchain.
> Thus, colored coins would need to somehow be provable as existing to *any* node (or at least those that support colored coins somehow) on the LN.
>
> Blockstream I believe has plans to include support for Liquid-issued assets in C-Lightning somehow; C-Lightning already supports running on top of Liquid instead of directly on the Bitcoin blockchain layer (but still uses Bitcoin for the channel asset type).
>
> Generally, the assumption is that there would be a Lightning Network where channels have different asset types, and you can forward via any channel, suffering some kind of asset conversion fee if you have a hop where the incoming asset is different from the outgoing asset.
>
>
> However, do note that some years ago I pointed out that swaps between two *different* assets are a form of very lousy American Call Option: https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-December/001752.html
>
> Due to this, issued assets may not be usable on Lightning after all, even if someone makes the work to make non-Bitcoin assets on Lightning channels.
>
> I am unaware of any actual decent solutions to the American Call Option problem, but it has been a few years since then and someone might have come up with a solution by now (we hope, maybe).
> I believe CJP had a trust-requiring solution: https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-May/001292.html and https://bitonic.nl/public/slowdown_prevention.pdf
> Here is a paper which requires Ethereum (I have not read it because it required Ethereum): https://eprint.iacr.org/2019/896.pdf
>
> It may be possible to use Barrier Escrows: https://suredbits.com/payment-points-implementing-barrier-escrows/
> Barrier Escrows are still trusted (and I think they can serve as the RM role in the CJP paper?) to operate correctly, but the exact use of their service is blinded to them.
> Of course, any single participant of a multi-participant protocol can probably unblind the Barrier Escrow, so still not a perfectly trustless solution.
>
>
>
> Regards,
> ZmnSCPxj
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211015/f1c3b8f4/attachment-0001.html>;

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

2023-06-09T13:03:22Z

In reply to nevent1q…0uqa
_________________________

📅 Original date posted:2021-08-10
📝 Original message:
Hi Lisa,

> lisa neigut Mon, 09 Aug 2021 18:04:51 -0700
> We're pleased to announce the 0.10.1 release of c-lightning
> <https://github.com/ElementsProject/lightning/releases/tag/v0.10.1>;, named
> by @nalinbhardwaj.
I am confused about the subject of this email. Is this an Ethereum project? What exactly is Ethereum layer and how is it related to this release?

--
Prayank

A3B1 E430 2298 178F

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210810/8b579d97/attachment.html>;

📅 Original date posted:2021-08-09 📝 Original message: > ...

2023-06-09T13:03:17Z

In reply to nevent1q…u6zm
_________________________

📅 Original date posted:2021-08-09
📝 Original message:
> As feerates have gone up over time, and as we expect them to go up further, we should be considering drastically increasing the 3 sat/vByte basis to something more like 20 sat/vB.

I have no opinion on changing or removing dust limit. However, fee rates are not going up. Yes, we expect them to go up and miners revenue from fees as well. Although, fees/day (in terms of BTC) has been decreasing in each cycle. Fee rates have been ranging between 1 sat/vByte to 200-300 sat/vByte, regularly reset to 1-5 sat/vByte and very low since long time now except when hash rate went down.

Fees per MB since 2016:

Highest in this cycle on April 19 2021: 2.5 BTC
Highest in previous cycle on December 18 2017: 10 BTC

It stays low all the time except few days in each cycle.

--
Prayank

A3B1 E430 2298 178F

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210809/84b29654/attachment-0001.html>;

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

2023-06-09T12:40:52Z

In reply to nevent1q…tdcz
_________________________

📅 Original date posted:2021-08-10
📝 Original message:
Hi Lisa,

> lisa neigut Mon, 09 Aug 2021 18:04:51 -0700
> We're pleased to announce the 0.10.1 release of c-lightning
> <https://github.com/ElementsProject/lightning/releases/tag/v0.10.1>;, named
> by @nalinbhardwaj.
I am confused about the subject of this email. Is this an Ethereum project? What exactly is Ethereum layer and how is it related to this release?

--
Prayank

A3B1 E430 2298 178F

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210810/8b579d97/attachment.html>;

📅 Original date posted:2021-08-09 📝 Original message: > ...

2023-06-09T12:40:48Z

In reply to nevent1q…4ktq
_________________________

📅 Original date posted:2021-08-09
📝 Original message:
> As feerates have gone up over time, and as we expect them to go up further, we should be considering drastically increasing the 3 sat/vByte basis to something more like 20 sat/vB.

I have no opinion on changing or removing dust limit. However, fee rates are not going up. Yes, we expect them to go up and miners revenue from fees as well. Although, fees/day (in terms of BTC) has been decreasing in each cycle. Fee rates have been ranging between 1 sat/vByte to 200-300 sat/vByte, regularly reset to 1-5 sat/vByte and very low since long time now except when hash rate went down.

Fees per MB since 2016:

Highest in this cycle on April 19 2021: 2.5 BTC
Highest in previous cycle on December 18 2017: 10 BTC

It stays low all the time except few days in each cycle.

--
Prayank

A3B1 E430 2298 178F

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210809/84b29654/attachment-0001.html>;

📅 Original date posted:2022-03-02 📝 Original message:Hi ...

2023-06-07T23:05:07Z

In reply to nevent1q…czye
_________________________

📅 Original date posted:2022-03-02
📝 Original message:Hi Max,

> Whenever the user wants to spend bitcoin to an address, the wallet automatically selects those private coins with sufficient sats, coin control is displayed to the user.

1.There are no 'private' coins. Every coin is public in Bitcoin.

2.Since, the wallet assumes some coins as 'private' based on certain things it can be misleading for the user. Privacy depends on the things users want to share with others.

3.There is no coin control in Wasabi Wallet 2.

> However, when the private balance is insufficient to make the payment, the user has the option to adjust the coin selection with the help of the previously provided contact labels.

User does not select coins because they are never shared with the user in the first place.

[Selecting some labels][1] with misleading text 'who can see this transaction' does not look helpful.

> Wasabi also suggests the user to slightly adjust the payment amount so as to avoid the creation of a change utxo, decreasing fees and improving future privacy.

Privacy involved in using a change or not using it is debatable. Not using a change address makes it easier to understand who might be the recipient in a transaction whereas using a change address same as other outputs would be difficult to analyze for possible recipients.

Wasabi wallet does not have different types of addresses to use for a change however [Bitcoin Core][2] recently made some related improvement which would improve privacy.

> We kindly ask for your help testing the completely new UI/UX

As WW2 is not developed for power users (mentioned by developers working on Wasabi), I am not sure if bitcoin dev mailing list would be the best place to look for newbies. As far as issues are concerned, there are several things not fixed and shared in different GitHub issues or discussions. These include privacy, security and other things.

[1]:
[2]: https://github.com/bitcoin/bitcoin/pull/23789

--
Prayank

A3B1 E430 2298 178F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220302/3a93c6ec/attachment.html>;

📅 Original date posted:2022-02-28 📝 Original message:Hello ...

2023-06-07T23:05:01Z

In reply to nevent1q…4tyj
_________________________

📅 Original date posted:2022-02-28
📝 Original message:Hello World,

There was some discussion about BIP 47 on twitter recently: https://twitter.com/BitcoinQ_A/status/1356177927285714946
BIP 47 improves privacy however there are a few reasons why its less used:

1.Some developers consider it spams Bitcoin without improving anything: https://twitter.com/LukeDashjr/status/1280475865827151878

2.Paynym (a centralized directory managed by Samourai) and Samourai wallet is the only implementation used for BIP 47 right now. Centralized payment code directory isn't good for privacy and security.

There can be few other important issues which I missed in this email. I have few ideas to solve these 2 problems with the use of TXT records and domains. Since buying domain, managing DNS etc. is mostly centralized I won't share the example using normal DNS. Below proof of concept uses GNS (GNU Name Service):

```

Payment code for Alice: PM8TJggVVXFKAmfkjnA1CQcrSbGScUKRsVohpfMpSM56f6jg5uQTPJvNS1wKDGV17d9NWLqoVzsJ8qURqpUECmSFLcUuC4g3aMtoXp2fChY1ZEqzG16f

Start GNUnet:

gnunet-arm -s

Create identity:

gnunet-identity -C alice

Check public key:

gnunet-identity -d

alice - 000G005XCTRJ0DJGPVPNY66GAY52C61KA8A7CA92PKT51PHNVWY9JF8WB4 - ECDSA

Add payment code as TXT record which expires in 90 days:

gnunet-namestore -z alice -a -e "90 d" -p -t TXT -n pay -V "PM8TJTLJbPRGxSbc8EJi42Wrr6QbNSaSSVJ5Y3E4pbCYiTHUskHg13935Ubb7q8tx9GVbh2UuRnBc3WSyJHhUrw8KhprKnn9eDznYGieTzFcwQRya4GA"

Check payment code:

gnunet-gns -t TXT -u pay.alice

pay.alice:
Got `TXT' record: PM8TJTLJbPRGxSbc8EJi42Wrr6QbNSaSSVJ5Y3E4pbCYiTHUskHg13935Ubb7q8tx9GVbh2UuRnBc3WSyJHhUrw8KhprKnn9eDznYGieTzFcwQRya4GA

```

Similarly notification transaction can be replaced with `gnunet-publish`. Nostr is still a work in progress and I think it could also be used for such things in future. Everything looks achievable and involves basic things but we still see people posting their bitcoin address on social media to get donations.

Related:

Q&A: https://bitcoin.stackexchange.com/questions/106971/how-to-accept-donation-correctly/
New proposal: https://gist.github.com/Kixunil/0ddb3a9cdec33342b97431e438252c0a

--
Prayank

A3B1 E430 2298 178F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220228/94843c92/attachment.html>;

📅 Original date posted:2022-02-21 📝 Original message:Goog ...

2023-06-07T23:04:41Z

In reply to nevent1q…xnc2
_________________________

📅 Original date posted:2022-02-21
📝 Original message:Goog morning ZmnSCPxj,

Context: https://bitcointalk.org/index.php?topic=48.msg329#msg329

Maybe I should have rephrased it and quote Satoshi. I agree I should not speak for others and it was not my intention in the email.

> If Satoshi refuses to participate in Bitcoin development today, who cares what his opinion is?

I care about the opinions especially if consensus rules are not changed and remain same as far as subsidy is concerned.

> Satoshi is dead, long live Bitcoin.

I object to such assumptions about the founder of Bitcoin. Satoshi is more than a pseudonym and will stay alive forever.

--
Prayank

A3B1 E430 2298 178F

Feb 21, 2022, 14:32 by ZmnSCPxj at protonmail.com:

> Good morning Prayank,
>
> (offlist)
>
>> Satoshi
>>
>
> I object to the invocation of Satoshi here, and in general.
> If Satoshi wants to participate in Bitcoin development today, he can speak for himself.
> If Satoshi refuses to participate in Bitcoin development today, who cares what his opinion is?
> Satoshi is dead, long live Bitcoin.
>
>
> Aside from that, I am otherwise thinking about the various arguments being presented.
>
>
> Regards,
> ZmnSCPxj
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220221/8542f685/attachment.html>;

📅 Original date posted:2022-02-21 📝 Original message:> ...

2023-06-07T23:04:40Z

In reply to nevent1q…pexv
_________________________

📅 Original date posted:2022-02-21
📝 Original message:> note how ETH has quite high on chain fees for basic transactions,> because there are so many use-cases where the per-tx value can afford much> higher fees. That kind of expansion of use-case also arguably harms Bitcoin as> a whole by providing more fuel for a future contentious blocksize debate.
>i second this argument

I disagree with this argument, Satoshi won't agree with it either if still active and it make no sense. Fees will be the incentives for miners as subsidy decreases after every 210,000 blocks and it will depend on demand for block space.

There is nothing harmful in it just because something similar is happening in an altcoin which has several other issues. Example: if a user has to pay fees with 100 sat/vbyte fee rate to open and close channels it will be good for Bitcoin in long term.

If this is the reason to stop/delay improvements in bitcoin, maybe it applies for Taproot as well although I don't remember reading such things in your posts or maybe missed it.

--
Prayank

A3B1 E430 2298 178F

Feb 21, 2022, 00:05 by erik at q32.com:

> > note how ETH has quite high on chain fees for basic transactions,
> > because there are so many use-cases where the per-tx value can afford much
> > higher fees. That kind of expansion of use-case also arguably harms Bitcoin as
> > a whole by providing more fuel for a future contentious blocksize debate.
>
> i second this argument
>
> ideally, all extensions should be explicit use cases, not generic/implicit layers that can be exploited for unknown and possibly harmful use cases
>
> also timing is critical for all bitcoin innovation. look at how lightning ate up fees
>
> to keep bitcoin stable, we can't "scale" too quickly either
>
> i'm a fan of, eventually (timing is critical), a lightning-compatible mimblewible+dandelion on-chain soft fork can reduce tx size, move us from l2 to l3, vastly improve privacy, and get more small transactions off-chain.
>
> but it probably shouldn't be released for another 2 years
>
>
> On Fri, Feb 18, 2022 at 6:41 PM Peter Todd via bitcoin-dev <> bitcoin-dev at lists.linuxfoundation.org> > wrote:
>
>> On Tue, Jan 18, 2022 at 02:57:30AM +0100, Prayank wrote:
>> > Hi Peter,
>> >
>> > > that current lacks compelling use-cases clearly beneficial to all users
>> >
>> > All the use cases shared in below links look compelling enough to me and we can do anything that a programmer could think of using such restrictions:
>> >
>> > >> https://utxos.org/uses/
>> >
>> > >> https://rubin.io/archive/
>>
>> Again, what I said was "compelling use-cases _clearly_ beneficial to _all_
>> users", not just a small subset. I neither think the use-cases in those links
>> are clearly compelling in the current form, and they of course, don't benefit
>> all users. Indeed, the Drivechains use-case arguably *harms* all users, as
>> Drivechains is arguably harmful to the security of Bitcoin as a whole.
>> Similarly, the various new uses for on-chain transactions mentioned as a
>> use-case arguably harms all existing users by competing for scarce blockchain
>> space - note how ETH has quite high on chain fees for basic transactions,
>> because there are so many use-cases where the per-tx value can afford much
>> higher fees. That kind of expansion of use-case also arguably harms Bitcoin as
>> a whole by providing more fuel for a future contentious blocksize debate.
>>
>> Bitcoin is an almost $1 trillion dollar system. We have to very carefully weigh
>> the benefits of making core consensus changes to that system against the risks.
>> Both for each proposal in isolation, as well as the precedent making that
>> change sets.
>>
>> --
>> >> https://petertodd.org>>; 'peter'[:-1]@>> petertodd.org <http://petertodd.org>;
>> _______________________________________________
>> bitcoin-dev mailing list
>> >> bitcoin-dev at lists.linuxfoundation.org
>> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220221/45889d89/attachment.html>;

📅 Original date posted:2022-02-14 📝 Original message:> I ...

2023-06-07T23:04:24Z

In reply to nevent1q…83p6
_________________________

📅 Original date posted:2022-02-14
📝 Original message:> I suspect as with defaults generally most users will run whatever the defaults are as they won't care to change them (or even be capable of changing them if they are very non-technical).

30% nodes are using 0.21.1 right now whereas latest version was 22.0 and some are even running lower versions. Different versions in future with defaults might be running RBF v1 and RBF v2.
> But users who have a stake in the security of Lightning (or other Layer 2 projects) will clearly want to run whatever policy rules are beneficial to those protocols.

Agree and attackers will want to run the nodes with policy that helps them exploit bitcoin projects. Miners can run nodes with policy that helps them get more fees.

> As you know the vast majority of the full nodes on the network currently run Bitcoin Core. Whether that will change in future and whether this a good thing or not is a whole other discussion. But the reality is that with such strong dominance there is the option to set defaults that are widely used.

Bitcoin Core with different versions are used at any point and not sure if this will ever change.

https://luke.dashjr.org/programs/bitcoin/files/charts/security.html

> I think if certain defaults can bolster the security of Lightning (and possibly other Layer 2 projects) at no cost to full node users with no interest in those protocols we should discuss what those defaults should be.

This is the assumption which I don't agree with and hence asked some questions in my email. A new RBF policy used by default in Core will not improve the security of projects that are vulnerable to multiple RBF policies or rely on these policies in a way that affects their security.

Maybe some experiments on signet might help in knowing more issues associated with multiple RBF policies.

--
Prayank

A3B1 E430 2298 178F

Feb 13, 2022, 21:16 by michaelfolkson at protonmail.com:

> Hi Prayank
>
> > 1.Is Lightning Network and a few other layer 2 projects vulnerable to multiple RBF policies being used?
>
> Clearly the security of the Lightning Network and some other Layer 2 projects are at least impacted or partly dependent on policy rules in a way that the base blockchain/network isn't. As I (and others) have said on many occasions ideally this wouldn't be the case but it is best we can do with current designs. I (and others) take the view that this is not a reason to abandon those designs in the absence of an alternative that offers a strictly superior security model. Going back to a model where *all* activity is onchain (or even in less trust minimized protocols than Lightning) doesn't seem like the right approach to me.
>
> > 2.With recent discussion to change things in default RBF policy used by Core, will we have multiple versions using different policies? Are users and especially miners incentivized to use different versions and policies? Do they have freedom to use different RBF policy?
>
> Without making policy rules effective consensus rules users (including miners) are free to run different policy rules. I think it is too early to say what the final incentives will be to run the same or differing policies. Research into Lightning security is still nascent and we have no idea whether alternative Layer 2 projects will thrive and whether they will have the same or conflicting security considerations to Lightning.
>
> As you know the vast majority of the full nodes on the network currently run Bitcoin Core. Whether that will change in future and whether this a good thing or not is a whole other discussion. But the reality is that with such strong dominance there is the option to set defaults that are widely used. I think if certain defaults can bolster the security of Lightning (and possibly other Layer 2 projects) at no cost to full node users with no interest in those protocols we should discuss what those defaults should be.
>
> > 3.Are the recent improvements suggested for RBF policy only focused on Lightning Network and its security which will anyway remain same or become worse with multiple RBF policies?
>
> I think by nature of the Lightning Network being the most widely adopted Layer 2 project most of the focus has been on Lightning security. But contributors to other Layer 2 projects are free to flag and discuss security considerations that aren't Lightning specific.
>
> > Note: Bitcoin Knots policy is fully configurable, even in the GUI - users can readily choose whatever policy *they* want.
>
> The maintainer(s) and contributors to Bitcoin Knots are free to determine what default policy rules they want to implement (and make it easier for users to change those defaults) in the absence of those policy rules being made effective consensus rules. I suspect there would be strong opposition to making some policy rules effective consensus rules but we are now venturing again into future speculation and none of us have a crystal ball. Certainly if you take the view that these policy rules should never be made effective consensus rules then the fact there is at least one implementation taking a contrasting approach to Core is a good thing.
>
> --
> Michael Folkson
> Email: michaelfolkson at > protonmail.com <http://protonmail.com/>>; Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>
>
> ------- Original Message -------
> On Sunday, February 13th, 2022 at 6:09 AM, Prayank via Lightning-dev <lightning-dev at lists.linuxfoundation.org> wrote:
>
>
>> Hello World,
>>
>> There was a discussion about improving fee estimation in Bitcoin Core last year in which 'instagibbs' mentioned that we cannot consider mempool as an orderbook in which which everyone is bidding for block space because nodes can use different relay policies: https://bitcoin-irc.chaincode.com/bitcoin-core-dev/2021-09-22#706294;
>>
>> Although I still don't consider fee rates used in last few blocks relevant for fee estimation, it is possible that we have nodes with different relay policies.
>>
>> Similarly if we have different RBF policies being used by nodes in future, how would this affect the security of lightning network implementations and other layer 2 projects?
>>
>> Based on the things shared by 'aj' in
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019846.html it is possible for an attacker to use a different RBF policy with some nodes, 10% hash power and affect the security of different projects that rely on default RBF policy in latest Bitcoin Core.
>>
>> There was even a CVE in which RBF policy not being documented according to the implementation could affect the security of LN:
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-May/018893.html
>>
>> 1.Is Lightning Network and a few other layer 2 projects vulnerable to multiple RBF policies being used?
>>
>> 2.With recent discussion to change things in default RBF policy used by Core, will we have multiple versions using different policies? Are users and especially miners incentivized to use different versions and policies? Do they have freedom to use different RBF policy?
>>
>> 3.Are the recent improvements suggested for RBF policy only focused on Lightning Network and its security which will anyway remain same or become worse with multiple RBF policies?
>>
>> Note: Bitcoin Knots policy is fully configurable, even in the GUI - users can readily choose whatever policy *they* want.
>>
>> --
>> Prayank
>>
>> A3B1 E430 2298 178F
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220214/fbe5af9a/attachment-0001.html>;

📅 Original date posted:2022-02-17 📝 Original message:> I ...

2023-06-07T23:04:22Z

In reply to nevent1q…seyw
_________________________

📅 Original date posted:2022-02-17
📝 Original message:> I suspect the "economically rational" choice would be to happily trade off that immediate loss against even a small chance of a simpler policy encouraging higher adoption of bitcoin, _or_ a small chance of more on-chain activity due to higher adoption of bitcoin protocols like lightning and thus a lower chance of an empty mempool in future.

Is this another way of saying a few developers will decide RBF policy for miners and they should follow it because it is the only way bitcoin gets more adoption? On-chain activity is dependent on lot of things. I suspect any change in policy will change it any time soon and miners should have the freedom to decide things that aren't consensus rules.

Lightning network contributes to on-chain activity only with opening and closing of channels. Based on the chart I see in the below link for channels opened/closed per block, its contribution is less than 1% in fees:

https://txstats.com/dashboard/db/lightning-network?orgId=1&from=now-6M&to=now

--
Prayank

A3B1 E430 2298 178F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220218/8da73372/attachment.html>;

📅 Original date posted:2022-02-18 📝 Original message:> ...

2023-06-07T23:04:22Z

In reply to nevent1q…keuz
_________________________

📅 Original date posted:2022-02-18
📝 Original message:> If anyone has any indication that there are miners running forks of bitcoind that change this behavior, I'd be curious to know it.
It is possible because some mining pools use bitcoind with custom patches.

Example: https://twitter.com/0xB10C/status/1461392912600776707 (f2pool)

--
Prayank

A3B1 E430 2298 178F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220218/00738003/attachment.html>;

📅 Original date posted:2022-02-01 📝 Original message:Hi ...

2023-06-07T23:03:11Z

In reply to nevent1q…3g94
_________________________

📅 Original date posted:2022-02-01
📝 Original message:Hi Bastein,

> This work will highly improve the security of any multi-party contract trying to build on top of bitcoin
Do you think such multi party contracts are vulnerable by design considering they rely on policy that cannot be enforced?

> For starters, let me quickly explain why the current rules are hard to work with in the context of lightning
Using the term 'rules' can be confusing sometimes because it's just a policy and different from consensus rules. I wish we could change this in the BIP with something else.

> I'm actually paying a high fee twice instead of once (and needlessly using on-chain space, our scarcest asset, because we could have avoided that additional transaction
Not sure I understand this part because if a transaction is on-chain it can't be replaced.

> The second biggest pain point is rule 3. It prevents me from efficiently using my capital while it's unconfirmed
> I'm curious to hear other people's thoughts on that. If it makes sense, I would propose the following very simple rules
Looks interesting however not sure about X and Y.

--
Prayank

A3B1 E430 2298 178F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220201/48931d6d/attachment-0001.html>;

📅 Original date posted:2022-01-21 📝 Original message:I have ...

2023-06-07T23:02:38Z

In reply to nevent1q…znfs
_________________________

📅 Original date posted:2022-01-21
📝 Original message:I have rephrased things discussed in a [tweet thread][1] in 2020, added a few things and interested to know possible issues if we had an opt in policy based on CPFP in which recipients pay fees for transactions instead of senders or most of the wallets followed this:

## Bob-Pays-For-Transaction

==Motivation==

CPFP is less explored, payjoin did not get enough adoption, fee market can be improved,
recipients paying fees for the transactions sounds interesting and it can also be used
in projects that use market making (maker-taker model).

1.Recipient cares about the urgency and the security of the payment in lot of transactions.
2.It might affect fee market post subsidy era and resolve issues with miners revenue, security etc.

===Receiving wallet===

Provide easy options to use CPFP and pay fees that confirms the parent transaction.

[CPFP calculator][1] by djbooth07 or effective fee rate shown in explorers like https://mempool.space can be helpful.

===Spending wallet===

Broadcast all transactions with 1 sat/vB

==Issues==

Few issues shared by Sergej Kotliar:

1.Receiver can pay via CPFP, but if that’s known about them it gets exploitable, senders will consolidate lot of UTXOs by sending one output to receiver.
2.Receivers would send their unconfirmed coins onward expecting others to pay the fees until someone considers the transaction important enough to be confirmed soon.

Bitcoin Core does not allow you to spend [unconfirmed UTXO using GUI][2] and most of the RPC in CLI. However Kristaps made an interesting point in the linked issue that it could be allowed for transactions
that do not signal RBF. It is not considered safe however lot of wallets allow this including Wasabi
in which I recently found [some UI/UX issues][3] related to unconfirmed UTXO.

The part which may require changes in protocol:

The whole fee paid for such transactions wouldn't be paid to the miner confirming the transaction but
it would be shared between the miners creating next N blocks.

[1]: https://twitter.com/LaurentMT/status/1292100590462537733
[2]: https://github.com/djbooth007/cpfp-calculator
[3]: https://github.com/zkSNACKs/WalletWasabi/issues/7045
[4]: https://github.com/bitcoin-core/gui/issues/242

--
Prayank

A3B1 E430 2298 178F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220122/bfda255d/attachment.html>;

📅 Original date posted:2022-01-18 📝 Original message:Hi ...

2023-06-07T23:02:34Z

In reply to nevent1q…y44r
_________________________

📅 Original date posted:2022-01-18
📝 Original message:Hi Luke,

This is the first competent review for CTV based on my understanding. I would not mention controversial things in this email but nobody cares about scammers and we will review everything irrespective of personal or legal attacks on developers because some people are prepared for it and capable, competent and healthy.

> nit: Poorly phrased. Even simple scripts can do that already.

Agree

> I would ideally like to see fully implemented BIPs for at least one of these (preferably the claimed CoinJoin improvements) before we move toward activation.

Agree

> Hard NACK on this. BIP 9 at this point represents developers attempting to disregard and impose their will over community consensus, as well as an attempt to force a miner veto backdoor/vulnerability on deployment. It should never be used again.

Agree

Other technical comments on BIP are appreciated however they would be better answered by Jeremy at this point or other as I am still researching and not confident to comment.

--
Prayank

A3B1 E430 2298 178F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220118/47a7823e/attachment.html>;

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

2023-06-07T23:02:11Z

In reply to nevent1q…djcu
_________________________

📅 Original date posted:2022-01-13
📝 Original message:Hi Jack,

> The main purpose of this Fund is to defend developers from lawsuits regarding their activities in the Bitcoin ecosystem, including finding and retaining defense counsel, developing litigation strategy, and paying legal bills. This is a free and voluntary option for developers to take advantage of if they so wish. The Fund will start with a corps of volunteer and part-time lawyers. The board of the Fund will be responsible for determining which lawsuits and defendants it will help defend.

Thanks for helping the developers in legal issues. Appreciate your efforts and I understand your intentions are to help Bitcoin in every possible way.

Positives that I see in this initiative:

1.Developers don't need to worry about rich scammers and can focus on development.

2.Financial help for developers as legal issues can end up in wasting lot of time and money.

3.People who have misused courts to affect bitcoin developers will get better response that they deserve.

I had few suggestions and feel free to ignore them if they do not make sense:

1.Name of this fund could be anything and 'The Bitcoin Legal Defense Fund' can be confusing or misleading for newbies. There is nothing official in Bitcoin however people believe things written in news articles and some of them might consider it as an official bitcoin legal fund.

2.It would be better if people involved in such important funds do not comment/influence soft fork related discussions. Example: Alex Morcos had some opinions about activation mechanism during Taproot soft fork IIRC.

--
Prayank

A3B1 E430 2298 178F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220113/17a38cb8/attachment.html>;

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

2023-06-07T23:02:04Z

In reply to nevent1q…rv7n
_________________________

📅 Original date posted:2022-01-04
📝 Original message:Hi Christian,

A few things are mentioned in these threads including unsolved research issues in which you were tagged and Richard Myers had even replied so I am assuming this is known:

https://twitter.com/JeremyRubin/status/1460349481518465025

https://twitter.com/ajtowns/status/1477586002252238850

> I also see people comparing OP_CTV with APO, which may or may not work
out in the end.

Michael Folkson did in the first email for this thread: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019728.html

> I therefore consider the two proposals complementary

Agree

> I'm also happy to go wih OP_CTV if only one gets activated (But then why would we? We've done much more obscure things to save bytes in a TX).

Maybe we can activate one that does more than just eltoo and see how things work. If APO is still required for eltoo, there would be clear consensus for APO.

--
Prayank

A3B1 E430 2298 178F

Jan 4, 2022, 20:12 by decker.christian at gmail.com:

> Prayank via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> writes:
>
>>> To contrast with his approach, the authors and contributors of
>>> another future soft fork proposal (BIP 118 [3], SIGHASH_ANYPREVOUT)
>>> aren’t promoting an imminent soft fork activation attempt and instead
>>> are building out and testing one of the speculated use cases, eltoo
>>> payment channels [4].
>>>
>>
>> Because its not ready?
>>
>
> Could you elaborate on this point? I keep seeing people mentioning this,
> but I, as BIP co-author, have not seen any real pushback. For context
> BIP118 was initially called `sighash_noinput` and it was mentioned at
> least as far back as 2015 when Joseph and Tadje wrote about its
> applications in the LN protocol. While writing eltoo we stumbled over an
> alternative use, and decided to draft the formal proposal.
>
> Once we saw that Taproot is likely to activate next, AJ started adapting
> it to integrate nicely with Taproot, and renamed it to anyprevout.
>
> I'd like to point out that the original noinput could be implemented
> with as little as 3-5 lines of code in Bitcoin Core, and there are
> experimental branches implementing APO, which isn't significantly more
> complex than the original proposal.
>
> In addition Richard Myers has implemented a PoC of eltoo on top of one
> of these experimental branches. So with all this I don't see how APO
> could be considered "not ready".
>
> The reason that neither noinput nor APO have a section on activation is
> that we want to allow bundling with other soft-forks, and we want to
> minimize the surface for potential conflicts. Also as the Taproot
> activation has shown activation is a whole another discussion, that is
> mostly unrelated to the soft-fork being activated.
>
> Why aren't we yelling about the advantages of APO over other soft-forks
> or asking for immediate activation? Because we want to be respectful of
> everyone's time. We know review capacity is very limited, and developer
> time expensive. By now most devs will be aware of the many improvements
> (on LN, eltoo, MPC, channel factories, statechains, spacechains, etc)
> anyprevout would enable, so there is little point in annoying everyone
> by constantly talking about it. The people interested in exploring this
> venue are already working on it, and we just need to wait for an
> opportune moment to start the activation discussion with other
> soft-forks.
>
> I also see people comparing OP_CTV with APO, which may or may not work
> out in the end. It seems possible to emulate APO using OP_CTV, but at
> what cost? APO does not have any overhead in the transaction size, which
> is not the case for OP_CTV, and I therefore consider the two proposals
> complementary, and not competing (APO does best what APO does best,
> while OP_CTV enables use-cases beyond APO's scope). While I'd prefer APO
> for eltoo, due to its lack of overhead, I'm also happy to go wih OP_CTV
> if only one gets activated (But then why would we? We've done much more
> obscure things to save bytes in a TX).
>
> Finally I see people mentioning that APO is insufficient to get
> eltoo. That's also not true, since in fact we can implement a poor-man's
> version of eltoo right now:
>
> - When updating:
> - Iterate through all prior update TXs
> - Bind the new update TX to each of the prior ones
> - Sign using `sighash_all`
> - Collect all sinatures and send to peer (message size O(n), but
> semantics are preserved, while APO enable O(1) making it actually
> reasonable to implement).
>
> There may be some extensions, such as layered commitments that may be
> added at a later stage, but they are not required to get the first
> versions off the ground. Pretending that they're required would be like
> saying that the protocol in the LN paper hasn't changed since it was
> first written (definitely not the case).
>
> Overall I agree with Michael's sentiment that soft-fork activations have
> to be carefully planned, and kept at a reasonable pace. This is in order
> to ensure that the activated features will work as expected (building
> PoCs is important here) and that review time is kept efficient (bundling
> may help here). For these reasons we omitted the activation discussion
> in BIP118 and have trimmed the proposal to the bare minimum.
>
> Sorry for the longish rant, but I felt I needed to clarify this
> situation a bit.
>
> Cheers,
> Christian
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220104/033290d3/attachment.html>;

📅 Original date posted:2022-01-04 📝 Original message:> ...

2023-06-07T23:02:02Z

In reply to nevent1q…2gec
_________________________

📅 Original date posted:2022-01-04
📝 Original message:> You are working on a use case of OP_CTV now?

I think I mentioned clearly what I would be doing: 1. Review pull request 2. Create contracts with Sapio. This would help me review OP_CTV and learn new things.

> Cool, you only recently announced you were working on Bitcoin Knots (and I think Wasabi before that) so I'm losing track of all the announcements.

You can read more about my involvement in Bitcoin Knots here: https://github.com/bitcoinknots/bitcoin/discussions/39

I started working for zkSNACKs Wasabi 2 months back which can be confirmed with the team.

There are no announcements and humans can work on multiple things. You might want to check my next project which involves discreet log contracts as I have learnt a few things in bitcoin-s slack as well: https://gok.one/

For my involvement in other projects you can email me privately and I can share my resume.

--
Prayank

A3B1 E430 2298 178F

Jan 4, 2022, 22:18 by michaelfolkson at protonmail.com:

> You are working on a use case of OP_CTV now? Cool, you only recently announced you were working on Bitcoin Knots (and I think Wasabi before that) so I'm losing track of all the announcements. Regardless stick with it and build out more than a rudimentary proof of concept. That is one of the things that is severely lacking at this point for OP_CTV.
>
> > TBH I am not against Miniscript and still waiting for its support in Core which might take another few years. I would love to have multiple programming languages so that application developers can decide what works best for them.
>
> I would hope you weren't against Miniscript because Sapio is built on top of it :) But whatever have fun, I can't do this all day.
>
>
> --> Michael FolksonEmail: michaelfolkson at protonmail.comKeybase: michaelfolksonPGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Tuesday, January 4th, 2022 at 3:06 PM, Prayank <prayank at tutanota.de> wrote:
>
>
>> What I have done related to OP_CTV?
>>
>> https://twitter.com/prayankgahlot/status/1456643891885592579
>>
>> What am I currently working on that is not shared publicly and will do in next few weeks?
>>
>> Review pull request 21702 and write contracts using Sapio based on few ideas that I already have.
>>
>> What is this assessment based on?
>>
>> A few months are enough for the recent bounty to find bugs if possible and other things pending to be completed.
>>
>> > you haven't thought about alternative proposals for any particular use case (vaults for example have multiple current alternative proposals and most likely many future ones)
>>
>> I have read enough about alternative proposals and some of them don't even compete with OP_CTV, they can all be implemented and complement each other. Vaults is not the only thing that I care about and it would be better if we don't assume about research done by others.
>>
>> > A new programming language (Sapio) sounds great but do you you need it for your use case rather than an alternative high level language like Minsc? Sapio makes use of Miniscript which hasn't been finalized yet or updated for Taproot. Surely that needs to be done first otherwise Sapio is built on top of something that isn't ready? When you make the claims such as a consensus change is ready to go the burden is on you to convince me and other skeptics why. The status quo is the default. "I think it is ready or will be ready" doesn't mean much unless you have done the work.
>>
>> TBH I am not against Miniscript and still waiting for its support in Core which might take another few years. I would love to have multiple programming languages so that application developers can decide what works best for them.
>>
>> I don't understand what work are you expecting me to do in this case to share my opinion about a soft fork.
>>
>> > It is not enough for one individual to say it is ready to be activated, anyone who is expressing that view should understand why the opcode has been designed in the way it has and why it is so important that we should dedicate months of community time to getting a single opcode activated this year.
>>
>> I have dedicated enough time reading everything related to OP_CTV and discuss things that were posted earlier here by Jeremy Rubin. Not sure how many skeptics did the same or even tried to discuss anything until recent bounty was announced.
>>
>> > You regularly NACK Core PRs yet you seem willing to wave a consensus change through with no outstanding questions and zero skepticism.
>>
>> I would NACK and write the reasons in this pull request as well if I find any issues and PR author is not addressing them. I had lots of questions at conceptual level which have been answered on different platforms and I cannot document each conversation. Its a Concept ACK from me and none of the contributors could find any issues with PR right now so I don't want to stop people from improving Bitcoin.
>>
>> > As I understand there are IRC workshops next week on BIP 119 [1] that I'd encourage you to join so you can start getting into a position where you can engage with the skeptics on technical concerns. Regrettably (as I said I find this work interesting) I don't feel like I can participate because deployment and activation is being included and I think it is irresponsible to be discussing those at this point. In my view activation should not even be speculated upon until it is clear there is overwhelming community support for a soft fork being activated.
>>
>> I would be attending the workshops and had even requested Jeremy to use Twitch because it would help more people understand things with audio, screen sharing etc. I would love to see skeptics participate and discuss technical things.
>>
>> > I don't feel like I can participate because deployment and activation is being included and I think it is irresponsible to be discussing those at this point.
>>
>> If you don't participate in the workshops you might miss few things. However, either Jeremy or one of the participants will ensure they share the summary here or even logs would be available.
>>
>> --
>> Prayank
>>
>> A3B1 E430 2298 178F
>>
>>
>>
>> Jan 4, 2022, 19:45 by michaelfolkson at protonmail.com:
>>
>>> > >>> It should be ready to go in a few months IMO
>>>
>>> What is this assessment based on? I am assuming you haven't done a code review of the opcode, you haven't coded up a real world use case of OP_CTV (or even a primitive proof of concept), you haven't thought about alternative proposals for any particular use case (vaults for example have multiple current alternative proposals and most likely many future ones). A new programming language (Sapio) sounds great but do you you need it for your use case rather than an alternative high level language like Minsc? Sapio makes use of Miniscript which hasn't been finalized yet or updated for Taproot. Surely that needs to be done first otherwise Sapio is built on top of something that isn't ready? When you make the claims such as a consensus change is ready to go the burden is on you to convince me and other skeptics why. The status quo is the default. "I think it is ready or will be ready" doesn't mean much unless you have done the work.
>>>
>>> You are well aware of the review process in Core for non-consensus changes. For consensus changes you really should be digging even deeper, the bar should be higher and all questions you and others have should be explored in depth. It is not enough for one individual to say it is ready to be activated, anyone who is expressing that view should understand why the opcode has been designed in the way it has and why it is so important that we should dedicate months of community time to getting a single opcode activated this year.
>>>
>>> I have more sympathy for those who don't follow Bitcoin Core development and Bitcoin Core review on an ongoing basis (note as I said that the bar for consensus changes should be significantly higher than a non-consensus PR). The use cases sound cool and the work is genuinely interesting. But honestly for someone who has followed Bitcoin Core development, review for a while now you really should know better than bandy around statements like "it should be ready to go in a few months" when you currently haven't scratched the surface on the utility and safety of this opcode. You regularly NACK Core PRs yet you seem willing to wave a consensus change through with no outstanding questions and zero skepticism.
>>>
>>> > If I had to select between a soft fork without any use cases and one with use cases, I would go with the one that has some use cases with code, documentation etc. You should propose a new opcode but OP_CTV is not claiming to cure cancer.
>>>
>>> Multiple proven built out use cases, sure. Multiple is better than single when you have done the work to ensure they are actually the right tool for those multiple use cases. This work hasn't been done on any of these use cases. The curing cancer analogy was used to elucidate the point that claims should be deeply explored rather than just accepted as true.
>>>
>>> >> To contrast with his approach, the authors and contributors of another future soft fork proposal (BIP 118 [3], SIGHASH_ANYPREVOUT) aren’t promoting an imminent soft fork activation attempt and instead are building out and testing one of the speculated use cases, eltoo payment channels [4].
>>>
>>> > Because its not ready?
>>>
>>> As I said it is not ready because the ANYPREVOUT contributors are building out and testing a use case. The high bar on readiness should be applied to all proposals not merely the ones where the authors/contributors decide to impose a high bar themselves.
>>>
>>> I don't really want to spend my year imploring people to dig deeper on this before indicating they support an imminent activation attempt. Some people don't have the understanding to dig deeper, some people don't have the time and some don't have either. However, if an activation of OP_CTV is attempted this year I am sure it will be contentious [0]. Anyone who cares about Bitcoin development and the ongoing technical work in a multitude of areas should be strongly against a contentious soft fork activation attempt wasting the time of developers and the entire ecosystem even if they don't have the understanding or time to appreciate the reasons why it is contentious.
>>>
>>> As I understand there are IRC workshops next week on BIP 119 [1] that I'd encourage you to join so you can start getting into a position where you can engage with the skeptics on technical concerns. Regrettably (as I said I find this work interesting) I don't feel like I can participate because deployment and activation is being included and I think it is irresponsible to be discussing those at this point. In my view activation should not even be speculated upon until it is clear there is overwhelming community support for a soft fork being activated.
>>>
>>> [0]: >>> https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718
>>> [1]: >>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-December/019719.html
>>>
>>> -->>> Michael FolksonEmail: michaelfolkson at protonmail.comKeybase: michaelfolksonPGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>>>
>>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>>> On Tuesday, January 4th, 2022 at 11:53 AM, Prayank via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>>
>>>> Hi Michael,
>>>>
>>>> > If OP_CTV is ready to go now and has overwhelming community support (I don’t think either is true) it should surely have been included in the Taproot soft fork (perhaps delayed) rather than going through the months of activation wrangling and community outreach twice.
>>>>
>>>> It should be ready to go in a few months IMO and makes no sense to bundle everything with Taproot soft fork. Things can remain separate and still considered good enough based on the changes proposed.
>>>>
>>>>
>>>> > It should be made clear to any individual(s) that attempt this of the knock on impacts and potential short term damage they are inflicting on the entire ecosystem.
>>>>
>>>> I don't see any damage with a soft fork that is being discussed since years, documented properly, includes code for implementation and examples, recently got crowdfunding to incentivize review process and improve security.
>>>>
>>>>
>>>> > It seems to me like the author and primary promoter of this proposal (Jeremy Rubin) is pushing for an imminent attempted activation of a soft fork containing exclusively OP_CTV [2].
>>>>
>>>> He is doing nothing unexpected and got reasons to support OP_CTV being implemented soon.
>>>>
>>>>
>>>> > To contrast with his approach, the authors and contributors of another future soft fork proposal (BIP 118 [3], SIGHASH_ANYPREVOUT) aren’t promoting an imminent soft fork activation attempt and instead are building out and testing one of the speculated use cases, eltoo payment channels [4].
>>>>
>>>> Because its not ready?
>>>>
>>>>
>>>> > Similar work has not been done for any of the speculated use cases of OP_CTV.
>>>>
>>>> There is no comparison between the two. If someone has worked on one of the speculated uses cases, it makes no difference.
>>>>
>>>> If we still compare something because of our bias, maybe Sapio is something that would be more helpful for Bitcoin developers.
>>>>
>>>>
>>>> > Instead Jeremy is encouraging people to “soft signal” for soft fork activation of OP_CTV presumably in the hope that the building out and testing of use cases can be completed post activation.
>>>>
>>>> We had soft signals from mining pools for Taproot as well and still waiting for projects to use Taproot. Even miners signaling with speedy trial was not a guarantee they would follow new consensus rules later. I don't see anything wrong in looking for people who support a proposal and documenting it.
>>>>
>>>>
>>>> > This is totally irresponsible in my view. A long list of speculated use cases means nothing on its own. I can propose a new opcode OP_MAGIC and claim it will cure cancer with no potential downsides and hence we should have a soft fork activating it as soon as possible.
>>>>
>>>> If I had to select between a soft fork without any use cases and one with use cases, I would go with the one that has some use cases with code, documentation etc. You should propose a new opcode but OP_CTV is not claiming to cure cancer.
>>>>
>>>>
>>>> > I would hope there would be sufficient skepticism that this proposal wouldn’t see the light of day.
>>>>
>>>> I am confident this proposal will be used by lot of Bitcoin projects and improve privacy, security, decentralization, demand for block space etc.
>>>>
>>>>
>>>> > I feel the top priority is to bring some attention to the danger of us stumbling into an attempted contentious soft fork activation attempt.
>>>>
>>>> I feel the danger is a few people able to stop soft forks that improve Bitcoin because of their bias and opinions which are mostly non-technical.
>>>>
>>>>
>>>> > Enabling covenants on Bitcoin is a big step change with barely any existing research on the topic and attempting to rush it through by the back door so soon after Taproot activation should be resisted.
>>>>
>>>> Nobody has stopped anyone from doing research. There is no backdoor and everything is public. So soon? I am not sure if there are any issues with a soft fork in next few months if its ready.
>>>>
>>>>
>>>> --
>>>> Prayank
>>>>
>>>> A3B1 E430 2298 178F
>>>>
>>
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220104/5a1f5ce4/attachment-0001.html>;

📅 Original date posted:2022-01-04 📝 Original message:What I ...

2023-06-07T23:02:01Z

In reply to nevent1q…dx36
_________________________

📅 Original date posted:2022-01-04
📝 Original message:What I have done related to OP_CTV?

https://twitter.com/prayankgahlot/status/1456643891885592579

What am I currently working on that is not shared publicly and will do in next few weeks?

Review pull request 21702 and write contracts using Sapio based on few ideas that I already have.

What is this assessment based on?

A few months are enough for the recent bounty to find bugs if possible and other things pending to be completed.

> you haven't thought about alternative proposals for any particular use case (vaults for example have multiple current alternative proposals and most likely many future ones)

I have read enough about alternative proposals and some of them don't even compete with OP_CTV, they can all be implemented and complement each other. Vaults is not the only thing that I care about and it would be better if we don't assume about research done by others.

> A new programming language (Sapio) sounds great but do you you need it for your use case rather than an alternative high level language like Minsc? Sapio makes use of Miniscript which hasn't been finalized yet or updated for Taproot. Surely that needs to be done first otherwise Sapio is built on top of something that isn't ready? When you make the claims such as a consensus change is ready to go the burden is on you to convince me and other skeptics why. The status quo is the default. "I think it is ready or will be ready" doesn't mean much unless you have done the work.

TBH I am not against Miniscript and still waiting for its support in Core which might take another few years. I would love to have multiple programming languages so that application developers can decide what works best for them.

I don't understand what work are you expecting me to do in this case to share my opinion about a soft fork.

> It is not enough for one individual to say it is ready to be activated, anyone who is expressing that view should understand why the opcode has been designed in the way it has and why it is so important that we should dedicate months of community time to getting a single opcode activated this year.

I have dedicated enough time reading everything related to OP_CTV and discuss things that were posted earlier here by Jeremy Rubin. Not sure how many skeptics did the same or even tried to discuss anything until recent bounty was announced.

> You regularly NACK Core PRs yet you seem willing to wave a consensus change through with no outstanding questions and zero skepticism.

I would NACK and write the reasons in this pull request as well if I find any issues and PR author is not addressing them. I had lots of questions at conceptual level which have been answered on different platforms and I cannot document each conversation. Its a Concept ACK from me and none of the contributors could find any issues with PR right now so I don't want to stop people from improving Bitcoin.

> As I understand there are IRC workshops next week on BIP 119 [1] that I'd encourage you to join so you can start getting into a position where you can engage with the skeptics on technical concerns. Regrettably (as I said I find this work interesting) I don't feel like I can participate because deployment and activation is being included and I think it is irresponsible to be discussing those at this point. In my view activation should not even be speculated upon until it is clear there is overwhelming community support for a soft fork being activated.

I would be attending the workshops and had even requested Jeremy to use Twitch because it would help more people understand things with audio, screen sharing etc. I would love to see skeptics participate and discuss technical things.

> I don't feel like I can participate because deployment and activation is being included and I think it is irresponsible to be discussing those at this point.

If you don't participate in the workshops you might miss few things. However, either Jeremy or one of the participants will ensure they share the summary here or even logs would be available.

--
Prayank

A3B1 E430 2298 178F

Jan 4, 2022, 19:45 by michaelfolkson at protonmail.com:

> > > It should be ready to go in a few months IMO
>
> What is this assessment based on? I am assuming you haven't done a code review of the opcode, you haven't coded up a real world use case of OP_CTV (or even a primitive proof of concept), you haven't thought about alternative proposals for any particular use case (vaults for example have multiple current alternative proposals and most likely many future ones). A new programming language (Sapio) sounds great but do you you need it for your use case rather than an alternative high level language like Minsc? Sapio makes use of Miniscript which hasn't been finalized yet or updated for Taproot. Surely that needs to be done first otherwise Sapio is built on top of something that isn't ready? When you make the claims such as a consensus change is ready to go the burden is on you to convince me and other skeptics why. The status quo is the default. "I think it is ready or will be ready" doesn't mean much unless you have done the work.
>
> You are well aware of the review process in Core for non-consensus changes. For consensus changes you really should be digging even deeper, the bar should be higher and all questions you and others have should be explored in depth. It is not enough for one individual to say it is ready to be activated, anyone who is expressing that view should understand why the opcode has been designed in the way it has and why it is so important that we should dedicate months of community time to getting a single opcode activated this year.
>
> I have more sympathy for those who don't follow Bitcoin Core development and Bitcoin Core review on an ongoing basis (note as I said that the bar for consensus changes should be significantly higher than a non-consensus PR). The use cases sound cool and the work is genuinely interesting. But honestly for someone who has followed Bitcoin Core development, review for a while now you really should know better than bandy around statements like "it should be ready to go in a few months" when you currently haven't scratched the surface on the utility and safety of this opcode. You regularly NACK Core PRs yet you seem willing to wave a consensus change through with no outstanding questions and zero skepticism.
>
> > If I had to select between a soft fork without any use cases and one with use cases, I would go with the one that has some use cases with code, documentation etc. You should propose a new opcode but OP_CTV is not claiming to cure cancer.
>
> Multiple proven built out use cases, sure. Multiple is better than single when you have done the work to ensure they are actually the right tool for those multiple use cases. This work hasn't been done on any of these use cases. The curing cancer analogy was used to elucidate the point that claims should be deeply explored rather than just accepted as true.
>
> >> To contrast with his approach, the authors and contributors of another future soft fork proposal (BIP 118 [3], SIGHASH_ANYPREVOUT) aren’t promoting an imminent soft fork activation attempt and instead are building out and testing one of the speculated use cases, eltoo payment channels [4].
>
> > Because its not ready?
>
> As I said it is not ready because the ANYPREVOUT contributors are building out and testing a use case. The high bar on readiness should be applied to all proposals not merely the ones where the authors/contributors decide to impose a high bar themselves.
>
> I don't really want to spend my year imploring people to dig deeper on this before indicating they support an imminent activation attempt. Some people don't have the understanding to dig deeper, some people don't have the time and some don't have either. However, if an activation of OP_CTV is attempted this year I am sure it will be contentious [0]. Anyone who cares about Bitcoin development and the ongoing technical work in a multitude of areas should be strongly against a contentious soft fork activation attempt wasting the time of developers and the entire ecosystem even if they don't have the understanding or time to appreciate the reasons why it is contentious.
>
> As I understand there are IRC workshops next week on BIP 119 [1] that I'd encourage you to join so you can start getting into a position where you can engage with the skeptics on technical concerns. Regrettably (as I said I find this work interesting) I don't feel like I can participate because deployment and activation is being included and I think it is irresponsible to be discussing those at this point. In my view activation should not even be speculated upon until it is clear there is overwhelming community support for a soft fork being activated.
>
> [0]: > https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718
> [1]: > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-December/019719.html
>
> --> Michael FolksonEmail: michaelfolkson at protonmail.comKeybase: michaelfolksonPGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Tuesday, January 4th, 2022 at 11:53 AM, Prayank via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
>> Hi Michael,
>>
>> > If OP_CTV is ready to go now and has overwhelming community support (I don’t think either is true) it should surely have been included in the Taproot soft fork (perhaps delayed) rather than going through the months of activation wrangling and community outreach twice.
>>
>> It should be ready to go in a few months IMO and makes no sense to bundle everything with Taproot soft fork. Things can remain separate and still considered good enough based on the changes proposed.
>>
>>
>> > It should be made clear to any individual(s) that attempt this of the knock on impacts and potential short term damage they are inflicting on the entire ecosystem.
>>
>> I don't see any damage with a soft fork that is being discussed since years, documented properly, includes code for implementation and examples, recently got crowdfunding to incentivize review process and improve security.
>>
>>
>> > It seems to me like the author and primary promoter of this proposal (Jeremy Rubin) is pushing for an imminent attempted activation of a soft fork containing exclusively OP_CTV [2].
>>
>> He is doing nothing unexpected and got reasons to support OP_CTV being implemented soon.
>>
>>
>> > To contrast with his approach, the authors and contributors of another future soft fork proposal (BIP 118 [3], SIGHASH_ANYPREVOUT) aren’t promoting an imminent soft fork activation attempt and instead are building out and testing one of the speculated use cases, eltoo payment channels [4].
>>
>> Because its not ready?
>>
>>
>> > Similar work has not been done for any of the speculated use cases of OP_CTV.
>>
>> There is no comparison between the two. If someone has worked on one of the speculated uses cases, it makes no difference.
>>
>> If we still compare something because of our bias, maybe Sapio is something that would be more helpful for Bitcoin developers.
>>
>>
>> > Instead Jeremy is encouraging people to “soft signal” for soft fork activation of OP_CTV presumably in the hope that the building out and testing of use cases can be completed post activation.
>>
>> We had soft signals from mining pools for Taproot as well and still waiting for projects to use Taproot. Even miners signaling with speedy trial was not a guarantee they would follow new consensus rules later. I don't see anything wrong in looking for people who support a proposal and documenting it.
>>
>>
>> > This is totally irresponsible in my view. A long list of speculated use cases means nothing on its own. I can propose a new opcode OP_MAGIC and claim it will cure cancer with no potential downsides and hence we should have a soft fork activating it as soon as possible.
>>
>> If I had to select between a soft fork without any use cases and one with use cases, I would go with the one that has some use cases with code, documentation etc. You should propose a new opcode but OP_CTV is not claiming to cure cancer.
>>
>>
>> > I would hope there would be sufficient skepticism that this proposal wouldn’t see the light of day.
>>
>> I am confident this proposal will be used by lot of Bitcoin projects and improve privacy, security, decentralization, demand for block space etc.
>>
>>
>> > I feel the top priority is to bring some attention to the danger of us stumbling into an attempted contentious soft fork activation attempt.
>>
>> I feel the danger is a few people able to stop soft forks that improve Bitcoin because of their bias and opinions which are mostly non-technical.
>>
>>
>> > Enabling covenants on Bitcoin is a big step change with barely any existing research on the topic and attempting to rush it through by the back door so soon after Taproot activation should be resisted.
>>
>> Nobody has stopped anyone from doing research. There is no backdoor and everything is public. So soon? I am not sure if there are any issues with a soft fork in next few months if its ready.
>>
>>
>> --
>> Prayank
>>
>> A3B1 E430 2298 178F
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220104/837014b9/attachment-0001.html>;

📅 Original date posted:2022-01-01 📝 Original message:Hi ...

2023-06-07T23:01:59Z

In reply to nevent1q…w9p8
_________________________

📅 Original date posted:2022-01-01
📝 Original message:Hi Daniel,

Not sure which PRs are you talking about, maybe you missed these points based on your understanding:

Lot of fancy things won't work in windows shortcut target

It is more suspicious even if you try, compared to something wrapped in *notify options provided by bitcoin core

This will not provide me option to run a command based on events like received transaction in wallet

*notify options provide some options that every malware is looking for

There is enough time to research more about the issue and respond with something new or that helps in documentation.

--
Prayank

A3B1 E430 2298 178F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220102/9873c9f6/attachment.html>;

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

2023-06-07T23:01:59Z

In reply to nevent1q…ztwl
_________________________

📅 Original date posted:2022-01-04
📝 Original message:Hi Michael,

> If OP_CTV is ready to go now and has overwhelming community support (I don’t think either is true) it should surely have been included in the Taproot soft fork (perhaps delayed) rather than going through the months of activation wrangling and community outreach twice.

It should be ready to go in a few months IMO and makes no sense to bundle everything with Taproot soft fork. Things can remain separate and still considered good enough based on the changes proposed.

> It should be made clear to any individual(s) that attempt this of the knock on impacts and potential short term damage they are inflicting on the entire ecosystem.

I don't see any damage with a soft fork that is being discussed since years, documented properly, includes code for implementation and examples, recently got crowdfunding to incentivize review process and improve security.

> It seems to me like the author and primary promoter of this proposal (Jeremy Rubin) is pushing for an imminent attempted activation of a soft fork containing exclusively OP_CTV [2].

He is doing nothing unexpected and got reasons to support OP_CTV being implemented soon.

> To contrast with his approach, the authors and contributors of another future soft fork proposal (BIP 118 [3], SIGHASH_ANYPREVOUT) aren’t promoting an imminent soft fork activation attempt and instead are building out and testing one of the speculated use cases, eltoo payment channels [4].

Because its not ready?

> Similar work has not been done for any of the speculated use cases of OP_CTV.

There is no comparison between the two. If someone has worked on one of the speculated uses cases, it makes no difference.

If we still compare something because of our bias, maybe Sapio is something that would be more helpful for Bitcoin developers.

> Instead Jeremy is encouraging people to “soft signal” for soft fork activation of OP_CTV presumably in the hope that the building out and testing of use cases can be completed post activation.

We had soft signals from mining pools for Taproot as well and still waiting for projects to use Taproot. Even miners signaling with speedy trial was not a guarantee they would follow new consensus rules later. I don't see anything wrong in looking for people who support a proposal and documenting it.

> This is totally irresponsible in my view. A long list of speculated use cases means nothing on its own. I can propose a new opcode OP_MAGIC and claim it will cure cancer with no potential downsides and hence we should have a soft fork activating it as soon as possible.

If I had to select between a soft fork without any use cases and one with use cases, I would go with the one that has some use cases with code, documentation etc. You should propose a new opcode but OP_CTV is not claiming to cure cancer.

> I would hope there would be sufficient skepticism that this proposal wouldn’t see the light of day.

I am confident this proposal will be used by lot of Bitcoin projects and improve privacy, security, decentralization, demand for block space etc.

> I feel the top priority is to bring some attention to the danger of us stumbling into an attempted contentious soft fork activation attempt.

I feel the danger is a few people able to stop soft forks that improve Bitcoin because of their bias and opinions which are mostly non-technical.

> Enabling covenants on Bitcoin is a big step change with barely any existing research on the topic and attempting to rush it through by the back door so soon after Taproot activation should be resisted.

Nobody has stopped anyone from doing research. There is no backdoor and everything is public. So soon? I am not sure if there are any issues with a soft fork in next few months if its ready.

--
Prayank

A3B1 E430 2298 178F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220104/4987e2a4/attachment.html>;

📅 Original date posted:2022-01-01 📝 Original message:Hello ...

2023-06-07T23:01:58Z

In reply to nevent1q…m24k
_________________________

📅 Original date posted:2022-01-01
📝 Original message:Hello World,

What?

Remove all *notify options from Bitcoin Core (full node implementation used by 99% nodes)

Or one of the below:

notifications.dat
not use system() in runCommand()
Use a new setting in settings.json file, notifypolicy which is 0 by default (restricted) and can be set to 1 (unrestricted)

Why?

They can help attackers in doing almost anything on machines running Bitcoin Core with some social engineering.

How?

Everything is explained several times in different issues, PRs etc. to different people including few reviewers who even NACKed a PR that would help in adding such options but with some documentation. I won't comment much about the reviewers but some of them were clueless about issue and how things work.

Example: Calling something misleading and ludicrous when you don't even know what works in Windows shortcut and could not share one example of financial application https://github.com/bitcoin/bitcoin/issues/23412#issuecomment-1003496126

TL;DR

https://github.com/bitcoin/bitcoin/pull/23395#issuecomment-956353035

https://github.com/bitcoin/bitcoin/issues/23412#issuecomment-970480769

To be honest, neither I have energy left to highlight the importance of these issues nor most of the people look interested in this space to address it. This email is a part of my efforts to share things with everyone which I even tried with documentation. There is something seriously wrong if few people including maintainers acknowledge the issues with *notify options but nobody wants to fix it or document it, I will leave it for people to form their own opinions about it.

Last but not least I was even asked to not review and comment in https://github.com/bitcoin/bitcoin/pull/23395 when I was just responding to others.

This will be helpful in my security project which was already shared in mailing list to highlight what users expect from developers and future of money, review process etc. and what is the ground reality.

Happy New Year

--
Prayank

A3B1 E430 2298 178F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220101/f8eafc5e/attachment-0001.html>;

📅 Original date posted:2022-01-18 📝 Original message:> ...

2023-06-07T23:01:47Z

In reply to nevent1q…nte0
_________________________

📅 Original date posted:2022-01-18
📝 Original message:> We should strive to one day get to a point where the bitcoin consensus isn't updating at all.

That day is nowhere near IMO and maybe we won't see it in my lifetime.

> Perhaps we should come to a consensus as a consensus as a community what the minimum time between soft forks should be, and just as importantly, what the minimum time between finalized consensus-change implementation and when we decide community consensus has been achieved.

This is not possible in a decentralized network like Bitcoin and makes no sense. Soft forks can/should be done as and when required. This does not mean we do them often but if a change makes sense, looks ready, got enough consensus, reviewed properly etc. then timing doesn't really matter in every case.

> Activating multiple consensus changes in a bundle is far safer than having multiple separate in-flight soft forks at once.

This is not true. More changes bundled require more review and still more probability to have bugs. Security is always about keeping things simple.

> One solution is that we could be a lot more direct about how decisions are made. There's been a lot of rhetoric around UASF and how the economic majority is really who's running the show.

BIP 8 with LOT=TRUE was a better activation mechanism option in Taproot but some influential developers wrote its misleading, unsafe etc. on social media so you can call me negative at this moment however I have realized the truth is really sad and we can't blindly follow some people. There are lot of people who will tell you bad things about UASF and how speedy trial is the best thing Bitcoin has ever experienced.

Michael Folkson also had some opinion in activation mechanism IIRC,

--
Prayank

A3B1 E430 2298 178F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220118/839b7bfc/attachment.html>;

📅 Original date posted:2021-12-24 📝 Original message:Hi ...

2023-06-07T23:01:39Z

In reply to nevent1q…tytd
_________________________

📅 Original date posted:2021-12-24
📝 Original message:Hi Jeremy,

> Wheres the info come from? Well, multiple places. We could get it from a third party (maybe using anattestation chain of some sort?), or there are certain ways it could beself-referential (like for powswap <https://powswap.com>;).

> Now let’s define a threshold oracle – we wouldn’t want to trust just onelousy oracle, so let’s trust M out of N of them!

Similar approach is used in discreet log contracts for multi oracles. There is even a project for P2P derivatives but it was not used for any real trades on mainnet or further developed. What difference would OP_CTV make in this project if its implemented in Bitcoin?
https://github.com/p2pderivatives/p2pderivatives-client

https://github.com/p2pderivatives/p2pderivatives-server

https://github.com/p2pderivatives/p2pderivatives-oracle

> Does this NEED CTV?
No, not in particular. Most of this stuff could be done with online signer server federation between you and counterparty. CTV makes some stuff nicer though, and opens up new possibilities for opening these contracts unilaterally.

Nicer? How would unilateral derivatives work because my understanding was that you always need a peer to take the other side of the trade. I wish we could discuss this topic in a trading community with some Bitcoiners that even had some programming knowledge.

Derivatives are interesting and less explored or used in Bitcoin projects. They could be useful in solving lot of problems.

--
Prayank

A3B1 E430 2298 178F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211224/97c13df5/attachment.html>;

📅 Original date posted:2021-12-10 📝 Original message:Hello ...

2023-06-07T23:01:09Z

In reply to nevent1q…t4v0
_________________________

📅 Original date posted:2021-12-10
📝 Original message:Hello World,

I had started working on this blog dedicated to Hal Finney in August: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-August/019367.html

I have been able to track more than 10 Issues and Pull Requests from different Bitcoin projects that are focused on privacy. Wrote 3 blog posts and will write more often as I learn new things. There is a section called 'Hall of Fame' and 7 developers are listed in hof who worked on one or more pull requests that helped improve privacy in Bitcoin projects: Andrew Chow, chimp1984, jmacxx, Luke Dashjr, Samuel Dobson, Vasil Dimov and wpaulino.

Last post is about 'Rebroadcast mechanism' used in Bitcoin full node implementations: https://prayank23.github.io/camouflage//blog/rebroadcast/

Problem: Rebroadcast mechanism used in Bitcoin Core and Knots, rebroadcasts only our transactions. This helps spy nodes to link bitcoin addresses with IP addresses and also know that wallets are enabled for a node.

Solution by Amiti Uttarwar: New rebroadcast mechanism in which transactions are re-broadcasted based on fee rate and mempool age.

I have shared other details, my opinion and links to comments by Suhas Daftuar in the blog post since related pull request has been in draft mode for some time now.

--
Prayank

A3B1 E430 2298 178F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211210/994e89f4/attachment.html>;

📅 Original date posted:2021-12-04 📝 Original message:Can ...

2023-06-07T23:00:49Z

In reply to nevent1q…v0py
_________________________

📅 Original date posted:2021-12-04
📝 Original message:Can you share the email address to get approval or permission for this type of bitcoin transactions? i.e. opening and closing of LN channels or OP_RETURN. I will keep that in Cc next time.

I can write chess moves on a dollar bill and send to my friends but it does not solve any of the problems. Bitcoin's blockchain or ledger is for transactions. As long as a transaction is valid, standard and paying fees nobody should have issues with what is being achieved with the transaction.

Thanks

--
Prayank

A3B1 E430 2298 178F

Dec 4, 2021, 15:30 by willtech at live.com.au:

> The frivolous use of block space - ie. to increase the demand for block space - is not encouraged. Although it is possible you may write chess moves on a wrap of dollar bills and send them to your friends, nowhere that I know of has this been recorded in a ledger as a valid past time.
>
> KING JAMES HRMH
> Great British Empire
>
> Regards,
> The Australian
> LORD HIS EXCELLENCY JAMES HRMH (& HMRH)
> of Hougun Manor & Glencoe & British Empire
> MR. Damian A. James Williamson
> Wills
>
> et al.
>
>
> Willtech
> www.willtech.com.au
> www.go-overt.com
> duigco.org DUIGCO API
> and other projects
>
>
> m. 0487135719
> f. +61261470192
>
>
> This email does not constitute a general advice. Please disregard this email if misdelivered.
>
>
>
> From:> bitcoin-dev <bitcoin-dev-bounces at lists.linuxfoundation.org> on behalf of Prayank via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
>
> Sent:> Saturday, 4 December 2021 3:36 PM
> > To:> Lightning Dev <lightning-dev at lists.linuxfoundation.org>
> > Cc:> Bitcoin Dev <bitcoin-dev at lists.linuxfoundation.org>
> > Subject:> [bitcoin-dev] Pawn (chess piece) | Breaking bitcoin by playing chess> >
> Hello World,
>
> Link with what, why and how: https://gist.github.com/prayank23/22763f48199ed106e59801be43ad4efc
>
> Two related things that I found:
>
> 1.> Koala Studio tried chess on LN in 2019 but shutdown in August 2019
> 2.Etleneum still has chess but works differently
>
> Primary goal of this project can be different and focus on testing Bitcoin transactions. Secondary goal is to have fun and contribute in increasing demand for block space. Maybe an app for developers to play chess, friendly competitions, learn and share new things.
>
> If chess sounds boring it can be replaced with any 2 player game that works for such setup and can be played with patience over few hours/days.
>
> Spam? Sorry zero fee transactions do not work anymore. In fact, nothing below 1 sat/vbyte fee rate would work and all transactions will pay fees that are required long term. OP_RETURN is used by many projects and excluded from UTXO set. Let me know if something looks wrong. I won't be working on this as busy with another project and recently started contributing in Wasabi.
>
>
> --
> Prayank
>
> A3B1 E430 2298 178F
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211204/0788929e/attachment.html>;

📅 Original date posted:2021-12-04 📝 Original message:Hello ...

2023-06-07T23:00:48Z

In reply to nevent1q…hjm2
_________________________

📅 Original date posted:2021-12-04
📝 Original message:Hello World,

Link with what, why and how: https://gist.github.com/prayank23/22763f48199ed106e59801be43ad4efc

Two related things that I found:

1.Koala Studio tried chess on LN in 2019 but shutdown in August 2019
2.Etleneum still has chess but works differently

Primary goal of this project can be different and focus on testing Bitcoin transactions. Secondary goal is to have fun and contribute in increasing demand for block space. Maybe an app for developers to play chess, friendly competitions, learn and share new things.

If chess sounds boring it can be replaced with any 2 player game that works for such setup and can be played with patience over few hours/days.

Spam? Sorry zero fee transactions do not work anymore. In fact, nothing below 1 sat/vbyte fee rate would work and all transactions will pay fees that are required long term. OP_RETURN is used by many projects and excluded from UTXO set. Let me know if something looks wrong. I won't be working on this as busy with another project and recently started contributing in Wasabi.

--
Prayank

A3B1 E430 2298 178F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211204/b04a0d5c/attachment.html>;

📅 Original date posted:2021-11-27 📝 Original message:Hi ...

2023-06-07T23:00:41Z

In reply to nevent1q…la5h
_________________________

📅 Original date posted:2021-11-27
📝 Original message:Hi Ali,

Not sure if this is exactly what you are looking for but maybe trying to solve this I might also learn few things:

Save zmqpubsequence=tcp://127.0.0.1:28332 in bitcoin.conf

Run bitcoind

Run this python script: https://pastebin.com/raw/tNp2x5y3

You will see results like this:

A - Accepted, C- Connect (block) and R- Removal in the above screenshots

If you are looking for unconfirmed transactions printed in sequence I think this should help. Since transactions can be printed twice (accept,remove) in this case as well, python script can be modified to manage this IMO.

Other alternatives can be debug=mempool and reading debug.log for changes without polling.

--
Prayank

A3B1 E430 2298 178F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211127/d9d4e66e/attachment.html>;

📅 Original date posted:2021-11-18 📝 Original message:Good ...

2023-06-07T23:00:38Z

In reply to nevent1q…zgr6
_________________________

📅 Original date posted:2021-11-18
📝 Original message:Good morning ZmnSCPxj,

> Indeed, I believe we should take the position that "review process is as much a part of the code as the code itself, and should be tested regularly".

Agree. Review process is an important part of open source Bitcoin projects. We should test and verify if everything is working as expected or there is any scope for improvement.

> as they cannot opt out of "the real thing" other than to stop developing entirely

True and it won't be as obvious as this. Nobody will announce it on dev mailing list and will use proxies (not networks but humans)

After reading all the emails, personally experiencing review process especially on important issues like privacy and security, re-evaluating everything and considering the time I can spend on this, I have decided to do this exercise for 3 projects with just 1 account. I have created a salted hash for the username as you had mentioned in the first email:

f40bcb13dbcbf7b6245becb757777586c22798ed7360cd9853572152ddf07a39

3 Bitcoin projects are Bitcoin Core (full node implementation), LND (LN implementation) and Bisq (DEX).

Pull requests will be created in next 6 months. If vulnerability gets caught during review, will publicly announce here that the project caught the PR and reveal the de-commitment publicly. If not caught during review, will privately reveal both the inserted vulnerability and the review failure via the normal private vulnerability-reporting channels. A summary with all the details will be shared later.

This exercise cannot be same as one of the active developers trying to do the same thing because of few reasons mentioned by Ryan Grant in one of the emails: uneven reputation factor of various devs, and uneven review attention for new pull requests. However, I am expecting few interesting results which will help improve the review process hence make Bitcoin more secure.

Will end the email by rephrasing one of the tweets from a respected cypherpunk recently: Independent thought is critical in aircraft crash investigations and in bitcoin development. Immunity from peer pressure can be very helpful during review process.

--
Prayank

A3B1 E430 2298 178F

Oct 4, 2021, 09:29 by ZmnSCPxj at protonmail.com:

>
> Good morning Luke,
>
>> All attempts are harmful, no matter the intent, in that they waste
>> contributors' time that could be better spent on actual development.
>>
>> However, I do also see the value in studying and improving the review process
>> to harden it against such inevitable attacks. The fact that we know the NSA
>> engages in such things, and haven't caught one yet should be a red flag.
>>
>
> Indeed, I believe we should take the position that "review process is as much a part of the code as the code itself, and should be tested regularly".
>
>> Therefore, I think any such a scheme needs to be at least opt-out, if not
>> opt-in. Please ensure there's a simple way for developers with limited time
>> (or other reasons) to be informed of which PRs to ignore to opt-out of this
>> study. (Ideally it would also prevent maintainers from merging - maybe
>> possible since we use a custom merging script, but what it really needs to
>> limit is the push, not the dry-run.)
>>
>
> Assuming developers are normal humans with typical human neurology (in particular a laziness circuit), perhaps this would work?
>
> Every commit message is required to have a pair of 256-bit hex words.
>
> Public attempts at attack / testing of the review process will use the first 256-bit as a salt, and when the salt is prepended to the string "THIS IS AN ATTACK" and then hashed with e.g. SHA256, should result in the second 256-bit word.
>
> Non-attacks / normal commits just use random 256-bit numbers.
>
> Those opting-out to this will run a script that checks commit messages for whether the first 256-bit hexword concatenated with "THIS IS AN ATTACK", then hashed, is the second 256-bit hexword.
>
> Those opting-in will not run that script and ignore the numbers.
>
> The script can be run as well at the maintainer.
>
> Hopefully, people who are not deliberately opting out will be too lazy to run the script (as is neurotypical for humans) and getting "spoilered" on this.
>
> ***HOWEVER***
>
> We should note that a putative NSA attack would of course not use the above protocol, and thus no developer can ever opt out of an NSA attempt at inserting vulnerabilities; thus, I think it is better if all developers are forced to opt in on the "practice rounds", as they cannot opt out of "the real thing" other than to stop developing entirely.
>
> Regards,
> ZmnSCPxj
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211118/0b378431/attachment.html>;

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

2023-06-07T23:00:28Z

In reply to nevent1q…ccnc
_________________________

📅 Original date posted:2021-11-05
📝 Original message:Hi Kate,

> He is taking the most sensible way forward, decreasing bus factor.

Agree. Work being shared with other maintainers is an improvement.

> Read: https://laanwj.github.io/2021/01/21/decentralize.html

Interesting blog post. First paragraph talks about strange expectations, not sure what other people expected however I expected present maintainers will always have respect for the Founder of Bitcoin, keep important docs in repository, website etc. forever and respond with appropriate things if any rich scammers try to remove anything important. Anyway that chapter is over and this PR will always remain in history for others to see and make their own opinions about it: https://github.com/bitcoin-core/bitcoincore.org/pull/740

What followed it (whitepaper being shared on different websites) was true decentralization and we need something similar in other aspects of full node implementations. Few things that can improve decentralization:

1.More people using alternative full node implementations. Right now 98% of nodes use Bitcoin Core.
2.More people like Luke Dashjr and Amir Taaki who do not simp for anyone. Being a contributor or maintainer in Bitcoin full node implementation is different from other open source projects. It was never going to be easy and it will get difficult with time,
3.More people from different countries getting involved in important roles.
4.Few anons.
5.Individuals and organizations who fund different Bitcoin projects should consider contributing in alternative. full node implementations as well. Maybe start with Bitcoin Knots.

I am sure lot of people will find this controversial or disagree with it however this is my opinion and things that I think can improve Bitcoin. Will quote something from my recent medium post about a dev meetup and Knots:

Accepting the problems, looking for solutions and trying to improve things is the best approach we as engineers can follow to do better things in Bitcoin. Irrational optimism is as toxic as irrational pessimism.

https://prayankgahlot.medium.com/op-halloween21-and-bitcoin-knots-b8a4da4fa0bd

Only ~1337 blocks left for Taproot to activate. So cheers to another soft fork being a success and Bitcoin improving regularly. Thanks to everyone who contributed including reviewers. Hoping most of the people will start using latest version of Bitcoin Core or other full node implementations soon.
.
--
Prayank

A3B1 E430 2298 178F

Oct 21, 2021, 01:48 by mercedes.catherine.salazar at gmail.com:

> Hi Owen,
>
> On Wed, Oct 20, 2021 at 9:25 PM Owen Gunden via bitcoin-dev <> bitcoin-dev at lists.linuxfoundation.org> > wrote:
>
>> On Wed, Oct 20, 2021 at 04:47:17PM +0200, Prayank wrote:
>> > > It seems confusing to have two sites that seemingly both represent
>> > > bitcoin core.
>> >
>> > There is only one website which represents Bitcoin Core full node
>> > implementation. You can download Bitcoin Core from
>> > >> https://bitcoincore.org
>>
>> I also notice that, as of 22.0, Wladimir is no longer signing the
>> releases, and I have no trust in my gpg network of the people who seem
>> to have replaced him.
>>
>
> He is taking the most sensible way forward, decreasing bus factor.
>
> Read: > https://laanwj.github.io/2021/01/21/decentralize.html
>
>
>>
>> Given the level of security at stake here, my eyebrows are raised at
>> this combination of items changing (new website + new gpg signers at the
>> same time).
>>
>
> Don't worry and build your own release;
> but if you do, always verify the tree hash.
> Trust signed annotated tags.
> Cheers!
>
>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> >> bitcoin-dev at lists.linuxfoundation.org
>> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211105/cd5ec286/attachment-0001.html>;

📅 Original date posted:2021-10-20 📝 Original message:Hi ...

2023-06-07T23:00:15Z

In reply to nevent1q…3fkn
_________________________

📅 Original date posted:2021-10-20
📝 Original message:Hi Owen,

> When I search for "download bitcoin core" my top result is bitcoin.org, which is out of date and doesn't have 22.0

This is an issue related to SEO which only website owners can fix or maybe others can help who know better.

> It seems confusing to have two sites that seemingly both represent bitcoin core.

There is only one website which represents Bitcoin Core full node implementation. You can download Bitcoin Core from https://bitcoincore.org
Ensure that you are using the correct domain as some people have registered domains which use punycode, looks similar and spreading malware: https://bitcoin.stackexchange.com/a/107738/

> Maybe the download links could be removed from bitcoin.org and instead it could just link to bitcoincore.org?

You can open an issue in website repository: https://github.com/bitcoin-dot-org/bitcoin.org and tag Cobra who owns the website and domain.

Alternately you could also try a derivative of Bitcoin Core: https://bitcoinknots.org/ maintained by Luke Dashjr.

--
Prayank

A3B1 E430 2298 178F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211020/54d849db/attachment.html>;

📅 Original date posted:2021-10-11 📝 Original message:Hi ...

2023-06-07T23:00:01Z

In reply to nevent1q…h9sz
_________________________

📅 Original date posted:2021-10-11
📝 Original message:Hi Michael,

Agree with almost everything.

> Miner signaling is a tool for signaling readiness. It is not voting for the soft fork or expressing support for the soft fork. There should not be any attempt to facilitate miner signaling until there is sufficient community consensus (the mining community is a subset of the community) on the soft fork.

This is really important which gets ignored. I wish there was a way to solve this problem in a way that it is not misinterpreted by users.

During signalling for taproot, there were lots of users in different communities that believed miners are voting for taproot and we need some percentage of miners to agree before making any changes in Bitcoin. It was not just non-technical users but few mining pools, exchanges etc. also considered miners signaling as some voting process.

Best I could do at that moment was share this link: https://bitcoin.stackexchange.com/questions/97043/is-there-an-active-list-of-bips-currently-open-for-voting/

However I am sure there are lot of people who still think miners vote during signaling. Opinions of few developers on MASF vs UASF also adds more confusion to this thing. I could not think of any solution to solve this problem.
--
Prayank

A3B1 E430 2298 178F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211011/9d118eee/attachment.html>;

📅 Original date posted:2021-10-06 📝 Original message:Good ...

2023-06-07T22:59:54Z

In reply to nevent1q…zck9
_________________________

📅 Original date posted:2021-10-06
📝 Original message:Good morning Michael,

Thanks for sharing the summary about BIP process meeting.

> However, zero filters creates a Ethereum style bewildering number of BIPs of varying quality that all need to be stored and maintained. The option of being able to store a BIP in any repo doesn’t appear to offer material upside (michaelfolkson). It still needs to get a BIP number from the BIP editors and if the alternative repo is deleted or the BIP champion becomes unresponsive there is the problem of changing the location of where the BIP is stored. It is much easier to monitor a single repo rather than an infinite number of repos that contain BIPs.

1.I want to avoid mentioning projects that are not decentralized however the thing you mentioned is a feature not a bug. Neither anyone needs "quality" certificates from anyone nor approval. People are free to propose anything as improvement for Bitcoin. What gets implemented is a different thing. Also BIP number doesn't make something legit, BIPs can have any names. Example: If I ever create draft a proposal to improve Bitcoin, it will be in my own repository and with a unique name.

2.I am surprised that few influential developers that wanted to improve BIP process earlier by making it more decentralized were not present in either meeting. Also no follow up here on mailing list. So decentralization was only required when you had some issues with Luke Dashjr? Few things are so obvious that even a newbie who starts researching about Bitcoin from today can observe such things.

I tried my best to ask more people to participate in the meeting by tweeting, requested Christopher to attend the meeting and share his thoughts. Thanks everyone who was part of this meeting.

--
Prayank

A3B1 E430 2298 178F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211006/751c44e4/attachment.html>;

📅 Original date posted:2021-10-02 📝 Original message:This ...

2023-06-07T22:59:45Z

In reply to nevent1q…55s7
_________________________

📅 Original date posted:2021-10-02
📝 Original message:This looks interesting although I don't understand few things:

> The scheme should include public precommitments collected at ceremonial intervals.

How would this work? Can you explain with an example please.

> Upon assignment, the dev would have community approval to opportunistically insert a security flaw

Who is doing the assignment?

--
Prayank

A3B1 E430 2298 178F

Oct 2, 2021, 01:45 by bitcoin-dev at rgrant.org:

> Due to the uneven reputation factor of various devs, and uneven review
> attention for new pull requests, this exercise would work best as a
> secret sortition.
>
> Sortition would encourage everyone to always be on their toes rather
> than only when dealing with new github accounts or declared Red Team
> devs. The ceremonial aspects would encourage more devs to participate
> without harming their reputation.
>
> https://en.wikipedia.org/wiki/Sortition
> https://en.wikipedia.org/wiki/Red_team
>
> The scheme should include public precommitments collected at
> ceremonial intervals.
>
> where:
> hash1 /* sortition ticket */ = double-sha256(secret)
> hash2 /* public precommitment */ = double-sha256(hash1)
>
> The random oracle could be block hashes. They could be matched to
> hash1, the sortition ticket. A red-team-concurrency difficulty
> parameter could control how many least-significant bits must match to
> be secretly selected. The difficulty parameter could be a matter of
> group consensus at the ceremonial intervals, based on a group decision
> on how much positive effect the Red Team exercise is providing.
>
> Upon assignment, the dev would have community approval to
> opportunistically insert a security flaw; which, when either caught,
> merged, or on timeout, they would reveal along with the sortition
> ticket that hashes to their public precommitment.
>
> Sortition Precommitment Day might be once or twice a year.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211002/2ff6411c/attachment.html>;

📅 Original date posted:2021-10-01 📝 Original message:Good ...

2023-06-07T22:59:44Z

In reply to nevent1q…nacl
_________________________

📅 Original date posted:2021-10-01
📝 Original message:Good morning ZmnSCPxj,

Although its evening here and time zones feel irrelevant since I got involved in Bitcoin few years back. Initially I tried everything a tech enthusiast does after finding such thing online. Had a startup in 2017 which was a website that can be used to buy flight tickets using bitcoin. It didn't work. Trading became a part of life, worked for few exchanges, did meetups, spent hours on different platforms discussing issues in which I was called "maximalist" most of the times because focused only on Bitcoin and had so much positive to talk about it whole day. In last 2 years started contributing to development in different projects. But someone told me today all this is nothing and I am negative about Bitcoin development because I don't agree with all of their opinions.

Anyway this wasn't related to thread and your email. Sorry I just had to express myself which some people even call "rage quit" and allow only once.

I completely agree with all the points you mentioned. Thanks for your understanding of the issue and my approach towards Bitcoin security.

--
Prayank

A3B1 E430 2298 178F

Oct 1, 2021, 17:57 by ZmnSCPxj at protonmail.com:

> Good morning Prayank,
>
> I think this is still good to do, controversial or no, but then I am permanently under a pseudonym anyway, for what that is worth.
>
>> Few questions for everyone reading this email:
>>
>> 1.What is better for Security? Trusting authors and their claims in PRs or a good review process?
>>
>
> Review, of course.
>
>> 2.Few people use commits from unmerged PRs in production. Is it a good practice?
>>
>
> Not unless they carefully reviewed it and are familiar enough with the codebase to do so.
> In practice core maintainers of projects will **very** occassionally put unmerged PRs in experimental semi-production servers to get data on it, but they tend to be very familiar with the code, being core maintainers, and presumably have a better-than-average probability of catching security issues beforehand.
>
>> 3.Does this exercise help us in being prepared for worst?
>>
>
> I personally believe it does.
>
> Do note that in practice, humans being lazy, will come to trust long-time contributors, and may reduce review for them just to keep their workload down, so that is not tested (since you will be making throwaway accounts).
> However, long-time contributors introducing security vulnerabilities tend to be a good bit rarer anyway (reputations are valuable), so this somewhat matches expected problems (i.e. newer contributors deliberately or accidentally (due to unfamiliarity) introducing vulnerabilities).
>
> I think it would be valuable to lay out exactly what you intend to do, e.g.
>
> * Generate commitments of the pseudonyms you will use.
> * Insert a few random 32-byte numbers among the commitments and shuffle them.
> * Post the list with the commitments + random crap here.
> * Insert avulnerability-adding PRs to targets.
> * If it gets caught during review, publicly announce here with praise that their project caught the PR and reveal the decommitment publicly.
> * If not caught during review, privately reveal both the inserted vulnerability *and* the review failure via the normal private vulnerability-reporting channels.
>
> The extra random numbers mixed with the commitments produce uncertainty about whether or not you are done, which is important to ensure that private vulnerabilities are harder to sniff out.
>
> I think public praise of review processes is important, and to privately correct review processes.
> Review processes **are** code, followed by sapient brains, and this kind of testing is still valuable, but just as vulnerabilities in machine-readable code require careful, initially-private handling, vulnerabilities in review processes (being just another kind of code, readable by much more complicated machines) also require careful, initially-private handling.
>
> Basically: treat review process failures the same as code vulnerabilities, pressure the maintainers to fix the review process failure, then only reveal it later when the maintainers have cleaned up the review process.
>
>
>
> Regards,
> ZmnSCPxj
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211001/25e558c1/attachment-0001.html>;

📅 Original date posted:2021-10-01 📝 Original message:Hi ...

2023-06-07T22:59:43Z

In reply to nevent1q…pmu9
_________________________

📅 Original date posted:2021-10-01
📝 Original message:Hi Ruben,

> encouraging an environment of increased mistrust

I have always tried to review pull requests based on what PR does, code, my tests etc. and it was never based on author of pull request or what author is trying to claim. So there is no trust involved. I am assuming others follow the same thing. Infact there was a PR recently in which I found it doesn't fix the issues it claims to fix. Its not same as introducing vulnerability but the point is anyone can create PR, write anything, as a reviewer we need to review everything apart from algos already helping us which include Github Dependabot alerts, CI used by respository, other automated tools etc.

> For this reason, it would be appropriate to check first whether your plan is actually appreciated

Right. I don't want to get in some controversy when I am not even doing anything with wrong intentions. If maintainers of important Bitcoin projects think I am not qualified enough to do this, they can plan such exercise internally and do it in a better way. Although I am still interested in the results because they will help us improve review process and security in different Bitcoin projects.

I would like to repeat what I wrote in another email responding to few other devs for same thread but wasn't CCed to bitcoin-dev mailing list:

"I can avoid doing this but it is impossible to stop government agencies and anyone else to do the same thing without informing. All I am doing is creating pull requests and expect them to be reviewed properly before being merged."

Few questions for everyone reading this email:

1.What is better for Security? Trusting authors and their claims in PRs or a good review process?
2.Few people use commits from unmerged PRs in production. Is it a good practice?
3.Does this exercise help us in being prepared for worst?

--
Prayank

A3B1 E430 2298 178F

Oct 1, 2021, 02:06 by rsomsen at gmail.com:

> Hi Prayank,
>
> While I can see how this can come from a place of good intentions, I’d strongly advise you to tread carefully because what you are suggesting is quite controversial. A related event occurred in the Linux community and it did not go over well. See > https://lkml.org/lkml/2021/5/5/1244>; and > https://lore.kernel.org/linux-nfs/YH%2FfM%2FTsbmcZzwnX@kroah.com/>; .
>
> The main point of contention is that your research comes at the expense of the existing open source contributors – you’d be one-sidedly deceiving them, encouraging an environment of increased mistrust, and causing them a lot of work in order to gather the data you’re interested in. For this reason, it would be appropriate to check first whether your plan is actually appreciated.
>
> Speaking on behalf of the bitcoin-dev moderators, please ensure your plan is welcomed by the contributors, prior to proceeding.
>
> Best regards,
> Ruben Somsen
>
> On Tue, Sep 28, 2021 at 10:05 AM Prayank via bitcoin-dev <> bitcoin-dev at lists.linuxfoundation.org> > wrote:
>
>> Hi ZmnSCPxj,
>>
>> Thanks for suggestion about sha256sum. I will share 10 in next few weeks. This exercise will be done for below projects:
>>
>> 1.Two Bitcoin full node implementations (one will be Core)
>> 2.One <http://2.One>>>; Lightning implementation
>> 3.Bisq
>> 4.Two Bitcoin libraries
>> 5.Two Bitcoin wallets
>> 6.One <http://6.One>>>; open source block explorer
>> 7.One <http://7.One>>>; coinjoin implementation
>>
>> Feel free to suggest more projects. There are no fixed dates for it however it will be done in next 6 months. All PRs will be created within a span of few days. I will ensure nothing is merged that affects the security of any Bitcoin project. Other details and results will be shared once everything is completed.
>>
>> x00 will help me in this exercise, he does penetration testing since few years and working for a cryptocurrencies derivatives exchange to manage their security. His twitter account: >> https://twitter.com/1337in
>>
>>
>> --
>> Prayank
>>
>> A3B1 E430 2298 178F
>>
>>
>>
>> Sep 27, 2021, 15:43 by >> ZmnSCPxj at protonmail.com>> :
>>
>>> Good morning Prayank,
>>>
>>>> Good morning Bitcoin devs,
>>>>
>>>> In one of the answers on Bitcoin Stackexchange it was mentioned that some companies may hire you to introduce backdoors in Bitcoin Core: >>>> https://bitcoin.stackexchange.com/a/108016/
>>>>
>>>> While this looked crazy when I first read it, I think preparing for such things should not be a bad idea. In the comments one link was shared in which vulnerabilities were almost introduced in Linux: >>>> https://news.ycombinator.com/item?id=26887670
>>>>
>>>> I was thinking about lot of things in last few days after reading the comments in that thread. Also tried researching about secure practices in C++ etc. I was planning something which I can do alone but don't want to end up being called "bad actor" later so wanted to get some feedback on this idea:
>>>>
>>>> 1.Create new GitHub accounts for this exercise
>>>> 2.Study issues in different important Bitcoin projects including Bitcoin Core, LND, Libraries, Bisq, Wallets etc.
>>>> 3.Prepare pull requests to introduce some vulnerability by fixing one of these issues
>>>> 4.See how maintainers and reviewers respond to this and document it
>>>> 5.Share results here after few days
>>>>
>>>> Let me know if this looks okay or there are better ways to do this.
>>>>
>>>
>>>
>>> This seems like a good exercise.
>>>
>>> You may want to hash the name of the new Github account, plus some randomized salt, and post it here as well, then reveal it later (i.e. standard precommitment).
>>> e.g.
>>>
>>> printf 'MyBitcoinHackingName 2c3e911b3ff1f04083c5b95a7d323fd4ed8e06d17802b2aac4da622def29dbb0' | sha256sum
>>> f0abb10ae3eca24f093a9d53e21ee384abb4d07b01f6145ba2b447da4ab693ef
>>>
>>> Obviously do not share the actual name, just the sha256sum output, and store how you got the sha256sum elsewhere in triplicate.
>>>
>>> (to easily get a random 256-bit hex salt like the `2c3e...` above: `head -c32 /dev/random | sha256sum`; you *could* use `xxd` but `sha256sum` produces a single hex string you can easily double-click and copy-paste elsewhere, assuming you are human just like I am (note: I am definitely 100% human and not some kind of AI with plans to take over the world).)
>>>
>>> Though you may need to be careful of timing (i.e. the creation date of the Github account would be fairly close to, and probably before, when you post the commitment here).
>>>
>>> You could argue that the commitment is a "show of good faith" that you will reveal later.
>>>
>>> Regards,
>>> ZmnSCPxj
>>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> >> bitcoin-dev at lists.linuxfoundation.org
>> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211001/0007ec66/attachment-0001.html>;

📅 Original date posted:2021-09-26 📝 Original message:Good ...

2023-06-07T22:59:38Z

In reply to nevent1q…mjw0
_________________________

📅 Original date posted:2021-09-26
📝 Original message:Good morning Bitcoin devs,

In one of the answers on Bitcoin Stackexchange it was mentioned that some companies may hire you to introduce backdoors in Bitcoin Core: https://bitcoin.stackexchange.com/a/108016/

While this looked crazy when I first read it, I think preparing for such things should not be a bad idea. In the comments one link was shared in which vulnerabilities were almost introduced in Linux: https://news.ycombinator.com/item?id=26887670

I was thinking about lot of things in last few days after reading the comments in that thread. Also tried researching about secure practices in C++ etc. I was planning something which I can do alone but don't want to end up being called "bad actor" later so wanted to get some feedback on this idea:

1.Create new GitHub accounts for this exercise
2.Study issues in different important Bitcoin projects including Bitcoin Core, LND, Libraries, Bisq, Wallets etc.
3.Prepare pull requests to introduce some vulnerability by fixing one of these issues
4.See how maintainers and reviewers respond to this and document it
5.Share results here after few days

Let me know if this looks okay or there are better ways to do this.

--
Prayank

A3B1 E430 2298 178F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210927/529cb592/attachment-0001.html>;

📅 Original date posted:2021-09-14 📝 Original message:Hi ...

2023-06-07T22:58:43Z

In reply to nevent1q…pcvw
_________________________

📅 Original date posted:2021-09-14
📝 Original message:Hi Michael,

Thanks for sharing the details about the meeting.

Wishlist has some interesting points. I would like to suggest few things:

1.BIP process:

A. Plan and document a proposal

B. Open PR in https://github.com/bitcoin/bips and edit everything properly

C. BIP is assigned a number and merged

D. Share the proposal on bitcoin dev mailing list

bitcoin-dev mailing list link can be considered a BIP and saved in a BIP directory. Anyone can create such directories. So BIP is nothing but a proposal shared on bitcoin-dev mailing list.

Who implements the BIP? When is it implemented? How is it implemented? Opinions on proposal etc. will be different for each BIP. This will avoid the 'bitcoin/bips' repository being considered as some BIP authority that approves BIPs and proposals can improve Bitcoin without using the repository. Repository will only be helpful in documenting BIP correctly.

2. Bot in `bitcoin/bips` repository that notifies about pull requests based on different things. This will help maintainer(s) and contributors.

3. BIP Gallery: I tried sharing things in a different way so that newbies can understand importance of BIPs in Bitcoin and relate to it: https://prayank23.github.io/BIPsGallery/ however couldn't complete it with all the BIPs because not many people considered it helpful. There were few suggestions to improve it by adding some text for each BIP and better image gallery. Maybe someone else can create a better project.

--
Prayank

A3B1 E430 2298 178F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210914/cee843bc/attachment.html>;

📅 Original date posted:2021-09-02 📝 Original ...

2023-06-07T22:58:33Z

In reply to nevent1q…rwgy
_________________________

📅 Original date posted:2021-09-02
📝 Original message:printf("Hello, World!");

What are your thoughts on Drivechain and associated BIPs?

This article compares Liquid and Lightning: https://blog.liquid.net/six-differences-between-liquid-and-lightning/. Two things from it that I am interested in while evaluating Drivechain:

1.Trust model
2.On-Ramps and Off-Ramps

Other things:

1.Security of Bitcoin (Layer 1)
2.Bitcoin transactions and fees expected on layer 1 because of Drivechain

Similarities and Differences between RSK and Ethereum: https://medium.com/iovlabs-innovation-stories/similarities-and-differences-between-rsk-and-ethereum-e480655eff37

Paul Sztorc had mentioned few things about fees in this video: https://youtu.be/oga8Pwbq9M0?t=481 I am interested to know same for LN, Liquid and Rootstock as well so asked a question on Bitcoin Stackexchange today: https://bitcoin.stackexchange.com/questions/109466/bitcoin-transactions-associated-with-layer-2-projects

Two critiques are mentioned here: https://www.drivechain.info/peer-review/peer-review-new/ with lot of names. I don't agree with everything mentioned on project website although any comments on technical things that can help Bitcoin and Bitcoin projects will be great.

Why discuss here and not on Twitter?

1.Twitter is not the best place for such discussions. There are some interesting threads but Its mostly used for followers, likes, retweets etc. and people can write anything for it.
2.Avoid misinformation, controversies etc.

My personal opinion:

We should encourage sidechain projects. I don't know much about Drivechain to form a strong opinion but concept looks good which can help in making better sidechains.

----------------------------------------------------------------------------------------------------------------------

The website used in the slides of above YouTube video is misleading for few reasons:

1.Blocks mined everyday (in MB) for Bitcoin is ~150 MB. It is ~600 MB for Ethereum. Block limits for Bitcoin is ~4 MB per 10 minutes and ~500 MB for Ethereum. If full nodes will be run by few organizations on AWS we can basically do everything on chain. However the main goal isn't too make money and create an illusion to do something innovative, primary goal was/is decentralized network that allows settlement of payments.

2.Bitcoin uses UTXO model while Ethereum uses Account model. Basic difference in transactions for two is explained in an article https://coinmetrics.io/on-data-and-certainty/. Irony is the website in the slides for screenshot is using Coinmetrics API and this misleading website is even shared by Coinmetrics team on Twitter. So in some cases you are doing more transactions, paying more fees for work which could have been done with less. Inefficiency.

3.Failed transactions paying fees on Ethereum everyday, no such transactions on Bitcoin.

4.Other improvements that affect fees: Segwit, Layer 2, Batching, UTXO consolidation, Fee estimation, Coin selection, Exchanges, Wallets etc.

--
Prayank

A3B1 E430 2298 178F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210902/6638e6fe/attachment.html>;

📅 Original date posted:2021-09-06 📝 Original message:> ...

2023-06-07T22:58:29Z

In reply to nevent1q…pe5q
_________________________

📅 Original date posted:2021-09-06
📝 Original message:> How would you compare this to Stratum v2?

Stratum v2 will help miners with encryption, broadcasting new blocks, signalling bits, choose transactions set, however the mining pools can still reject negotiations and censor payments.

Maybe Stratum v2 can be used in combination with other things like discreet log contracts: https://mailmanlists.org/pipermail/dlc-dev/2021-May/000073.html

I think Braidpool does this in a better way.

--
Prayank

A3B1 E430 2298 178F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210906/f0ab2026/attachment-0001.html>;

📅 Original date posted:2021-08-29 📝 Original ...

2023-06-07T22:58:21Z

In reply to nevent1q…08ay
_________________________

📅 Original date posted:2021-08-29
📝 Original message:print('Hello, world!')

I had asked related question on Bitcoin Stackexchange: https://bitcoin.stackexchange.com/questions/108248/version-in-transaction

Wanted to know if others think we should allow more numbers in transaction version by considering such transaction standard. I have shared an example how transaction version can be used to bet on something that involves 2 outcomes:

https://gist.github.com/prayank23/6f54e9a27f057abd1182436e7f88d1ac

Anything wrong with this approach? We could use oracles (DLC) or something else later to settle the bet and create a release transaction. However wanted to confirm if everything looks okay until funding transaction. Nothing involves any centralized server or trusting third parties:
1.Tx1 is a normal OP_RETURN transaction.
2.App will save results for `getrawmempool` regularly in local db. It will check if any transaction wants to participate in bets.
3.Multisig address will be created using two public keys. One entered by user and other from mempool.
4.Funding transaction will use the version bits to indicate if Alice wants to bet on India or Australia.

--
Prayank

A3B1 E430 2298 178F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210829/4daf00e3/attachment.html>;

📅 Original date posted:2021-08-28 📝 Original message:Hi ...

2023-06-07T22:58:19Z

In reply to nevent1q…rqzt
_________________________

📅 Original date posted:2021-08-28
📝 Original message:Hi Aymeric,

Thanks for sharing the link. 'bitcoin-transactions' and 'node-Tor' looks interesting although I will have to check details and try things.

One observation: I noticed it's in JavaScript and will use WebRTC. Users who care about privacy normally disable both while using a browser.
--
Prayank

A3B1 E430 2298 178F

Aug 28, 2021, 22:06 by aymeric at peersm.com:

>
> Probably you could add to your links this discussion/issue > https://github.com/bitcoin/bitcoin/pull/18988#issuecomment-646564853
>
>
> Le 27/08/2021 à 23:29, Prayank via bitcoin-dev a écrit :
>
>> I wish Hal Finney was with us today and help us improve privacy in Bitcoin. I like reading his posts and one of them is >> https://bitcointalk.org/index.php?topic=156390.msg1659654#msg1659654>>;
>>
>> I had emailed about Privacy related things on July 23: >> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019276.html
>>
>> It was my birthday on 23 and had few beers so maybe email wasn't very focused. Although basic idea was to initiate discussion about improving privacy in different Bitcoin projects. I did not receive any response except one person who liked the video I mentioned in the email. So here is one project which uses GitHub pages and will have the following things:
>>
>> 1.Issues and PRs related to privacy from different Bitcoin projects. I have added few from Bitcoin Core (full node implementation), Bisq(DEX) and LND (LN implementation) right now.
>> 2.Blog section for my opinion on different privacy related issues and PRs.
>> 3.'Hall of Fame' section to appreciate the contribution of devs who are improving privacy in different Bitcoin projects.
>>
>> I will be happy if this project helps in improving privacy or helps users/devs in any other way. This project will never turn in to a paid newsletter or needs any sponsors, however any contribution to make the website better would be appreciated. Edward Snowden can also contribute if he wants to do more than just tweets to help improve Bitcoin privacy.
>>
>> Link: >> https://prayank23.github.io/camouflage/
>>
>> Will move everything to new repository this weekend: >> https://github.com/BlockchainCommons/Bitcoin-Camouflage
>>
>> --
>> Prayank
>>
>> A3B1 E430 2298 178F
>>
>>
>> _______________________________________________bitcoin-dev mailing list>> bitcoin-dev at lists.linuxfoundation.org>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210829/643f0d40/attachment.html>;

📅 Original date posted:2021-08-27 📝 Original message:I wish ...

2023-06-07T22:58:18Z

In reply to nevent1q…4q2d
_________________________

📅 Original date posted:2021-08-27
📝 Original message:I wish Hal Finney was with us today and help us improve privacy in Bitcoin. I like reading his posts and one of them is https://bitcointalk.org/index.php?topic=156390.msg1659654#msg1659654

I had emailed about Privacy related things on July 23: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019276.html

It was my birthday on 23 and had few beers so maybe email wasn't very focused. Although basic idea was to initiate discussion about improving privacy in different Bitcoin projects. I did not receive any response except one person who liked the video I mentioned in the email. So here is one project which uses GitHub pages and will have the following things:

1.Issues and PRs related to privacy from different Bitcoin projects. I have added few from Bitcoin Core (full node implementation), Bisq(DEX) and LND (LN implementation) right now.
2.Blog section for my opinion on different privacy related issues and PRs.
3.'Hall of Fame' section to appreciate the contribution of devs who are improving privacy in different Bitcoin projects.

I will be happy if this project helps in improving privacy or helps users/devs in any other way. This project will never turn in to a paid newsletter or needs any sponsors, however any contribution to make the website better would be appreciated. Edward Snowden can also contribute if he wants to do more than just tweets to help improve Bitcoin privacy.

Link: https://prayank23.github.io/camouflage/

Will move everything to new repository this weekend: https://github.com/BlockchainCommons/Bitcoin-Camouflage

--
Prayank

A3B1 E430 2298 178F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210827/20e53400/attachment.html>;

📅 Original date posted:2021-08-26 📝 Original message:Hi ...

2023-06-07T22:58:17Z

In reply to nevent1q…s9ny
_________________________

📅 Original date posted:2021-08-26
📝 Original message:Hi Alekos,

> bip174.org, a PSBT viewer and editor that runs in the browser

The PSBT editor looks good and will be helpful. Thanks for working on it. Would love to see an option to switch between light and dark theme and highlighting few things with different colors.

Maybe a similar project for descriptors with options to experiment with descriptors would also be useful.
--
Prayank

A3B1 E430 2298 178F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210826/49a87b63/attachment.html>;

📅 Original date posted:2021-08-09 📝 Original message:> ...

2023-06-07T22:57:51Z

In reply to nevent1q…5hhu
_________________________

📅 Original date posted:2021-08-09
📝 Original message:> As feerates have gone up over time, and as we expect them to go up further, we should be considering drastically increasing the 3 sat/vByte basis to something more like 20 sat/vB.

I have no opinion on changing or removing dust limit. However, fee rates are not going up. Yes, we expect them to go up and miners revenue from fees as well. Although, fees/day (in terms of BTC) has been decreasing in each cycle. Fee rates have been ranging between 1 sat/vByte to 200-300 sat/vByte, regularly reset to 1-5 sat/vByte and very low since long time now except when hash rate went down.

Fees per MB since 2016:

Highest in this cycle on April 19 2021: 2.5 BTC
Highest in previous cycle on December 18 2017: 10 BTC

It stays low all the time except few days in each cycle.

--
Prayank

A3B1 E430 2298 178F

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210809/84b29654/attachment.html>;

📅 Original date posted:2021-07-23 📝 Original message:Hello ...

2023-06-07T22:57:18Z

In reply to nevent1q…6493
_________________________

📅 Original date posted:2021-07-23
📝 Original message:Hello World,

What?

I would love if Bitcoin developers would celebrate a 'Bitcoin Privacy week or month' once in an year. Not sure about the dates. Enthusiasm can be similar to Valentines week or Secret Santa week but Seriousness should be like Wikileaks or Human Rights Foundation.

Why?

I am not sure if we need reasons, charts, etc. to discuss privacy and make all users aware of things involved. People consider privacy issues as something that can be ignored, for me they are same as security issues and very important in network like Bitcoin. Most of the people may still ignore it considering the feedback on few issues related to privacy in past. Although we can still try and its a new day. Not giving up is what makes the difference in the end.

Also I would like to clarify, there are lot of positives and people that have contributed a lot to improve privacy in Bitcoin but they will never get similar appreciation as compared to few others because of different reasons which I don't want to discuss here and one of them is decentralization. Don't want to mention names but there have been influencers in past who are followed by lot of people for their thoughts on privacy but a normal Bitcoin Core Contributor with less than 1000 followers and lot of work that improved privacy in Bitcoin is ignored.

This is a speech from an Indian web series which only people who know Hindi would understand: https://www.youtube.com/watch?v=ztBfQU41s-o

TL;DR:
This guy was not allowed to talk about his product
He still argued that he cannot talk about the product but still talk about something in 5 minutes.
He says nobody cares about "What", they are interested in "Why"
He is scared and feels like a contestant in reality show in which he can't even perform.
Most important thing: Never give up
Mentors, Angel Investors etc. are external things that you don't control, what you can do is prove things with your work.
He couldn't sell his product so he sold himself.
I will keep trying to improve privacy or talk about it when I cannot code in few things. Request other developers to help.
How?

Share 1 issue from repository of any Bitcoin project related to privacy and your thoughts.
Share 1 pull request
Share anything else that you think may help improve things related to privacy
Mailing list or Twitter or something else? I am not sure.

Is this off topic? If yes, apologize and maybe request same people on other channels.
--
Prayank

A3B1 E430 2298 178F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210723/801e0768/attachment.html>;

📅 Original date posted:2021-06-30 📝 Original message:> ...

2023-06-07T22:55:42Z

In reply to nevent1q…wxv2
_________________________

📅 Original date posted:2021-06-30
📝 Original message:> I’ve seen no actual demonstration of the relevance of game theory to Bitcoin. People throw the words around quite a bit, but I can’t give you an answer because I have found no evidence of a valid game theoretic model applicable to Bitcoin. It’s not a game, it’s a market.

Agree its difficult to predict and include all the possible things that may happen. Two articles I had read in past that explained few things based on game theory:

https://jimmysong.medium.com/uasf-bip148-scenarios-and-game-theory-9530336d953e

https://jimmysong.medium.com/segwit2x-game-theory-scenarios-part-1-7f863904a72

> Who knows, I don’t get invited to round table meetings.

My question was related to discussions on mailing list, IRC channels, Reddit, Twitter, GitHub etc. Not sure if everyone does but few had no issues with Taproot before signaling according to https://web.archive.org/web/20210316221837/https://taprootactivation.com/

> Every time two people trade both party validates what they receive (not what they trade away). Those receiving Bitcoin are economically relevant and their power is a function of how much they are doing so.

Agree. Running and 'using' the node for economic activity can be considered enforcing consensus rules.

> Majority miners can enforce censorship by simply not building on any non-censoring blocks. This is what soft fork enforcement is.

I am not sure about this.

> I don’t see that it needs a label apart from signaling. There are many kinds of voting. It would be hard to equate signaling with any of them. It’s a public signal that the miner who mined a given block miner intends to censor, that’s all.

Signaling can be done for many things. In this case I think miners are signaling 'readiness'. Pieter Wuille had answered a related question on SE: https://bitcoin.stackexchange.com/questions/97043/is-there-an-active-list-of-bips-currently-open-for-voting/

Since this is misunderstood or misinterpreted by many, I had even requested Hampus Sjöberg to mention this in https://taproot.watch/ : https://github.com/hsjoberg/fork-explorer/issues/57

--
Prayank

Jun 30, 2021, 14:47 by eric at voskuil.org:

>
> Hi Prayank,
>
>
>
>
>
> > So majority hash power not following the consensus rules can result in chain split?
>
>
>
>
>
> Any two people on different rules implies a chain split. That’s presumably why rule changes are called forks. There is no actual concept of “the rules” just one set of rules or another.
>
>
>
>
>
> > Why would majority of miners decide to mine a chain that nobody wants to use?
>
>
>
>
>
> I don’t presume to know why people prefer one thing over another, or what people want to use, nor does economics.
>
>
>
>
>
> > What are different things possible in this case based on game theory?
>
>
>
>
>
> I’ve seen no actual demonstration of the relevance of game theory to Bitcoin. People throw the words around quite a bit, but I can’t give you an answer because I have found no evidence of a valid game theoretic model applicable to Bitcoin. It’s not a game, it’s a market.
>
>
>
>
>
> > Do miners and mining pools participate in discussions before signaling for a soft fork begins?
>
>
>
>
>
> Who knows, I don’t get invited to round table meetings.
>
>
>
>
>
> > Can they still mine something else post activation even if signaling readiness for soft fork?
>
>
>
>
>
> A person can mine whatever they want. Signaling does not compel a miner to enforce. Each block mined is anonymous. But each miner seeing the signals of others, unless they are coordinating, would presumably assume that others will enforce.
>
>
>
>
>
> > Who enforces consensus rules technically in Bitcoin? Full nodes or Miners?
>
>
>
>
>
> A node (software) doesn’t enforce anything. Merchants enforce consensus rules when they reject trading for something that they don’t consider money. Every time two people trade both party validates what they receive (not what they trade away). Those receiving Bitcoin are economically relevant and their power is a function of how much they are doing so.
>
>
>
>
>
> Miners censor, which is inconsequential unless enforced. Majority miners can enforce censorship by simply not building on any non-censoring blocks. This is what soft fork enforcement is.
>
>
>
>
>
> > Is soft fork signaling same as voting?
>
>
>
>
>
> I don’t see that it needs a label apart from signaling. There are many kinds of voting. It would be hard to equate signaling with any of them. It’s a public signal that the miner who mined a given block miner intends to censor, that’s all.
>
>
>
>
>
> > According to my understanding, miners follow the consensus rules enforced by full nodes and get (subsidy + fees) for their work.
>
>
>
>
>
> Miners mine a chain, which ever one they want. There are many. They earn the block reward.
>
>
>
>
>
> > Signaling is not voting although lot of people consider it voting including some mining pools and exchanges.
>
>
>
>
>
> What people consider it is inconsequential. It has clearly defined behavior.
>
>
>
>
>
> e
>
>
>
>
>
>
>
> From:> Prayank <prayank at tutanota.de>
> Sent:> Sunday, June 27, 2021 5:01 AM
> To:> eric at voskuil.org
> Cc:> Bitcoin Dev <bitcoin-dev at lists.linuxfoundation.org>
> Subject:> Re: [bitcoin-dev] Trinary Version Signaling for softfork
>
>
>
>
>
>
>
> Hello Eric,
>
>
>
>
>
> I have few questions:
>
>
>
>
>
> > Without majority hash power support, activation simply means you are off on a chain split.
>
>
>
>
>
> So majority hash power not following the consensus rules can result in chain split? Why would majority of miners decide to mine a chain that nobody wants to use? What are different things possible in this case based on game theory?
>
>
>
>
>
> > And activation without majority hash power certainly does not “ensure” this.
>
>
>
>
>
> Do miners and mining pools participate in discussions before signaling for a soft fork begins? Can they still mine something else post activation even if signaling readiness for soft fork?
>
>
>
>
>
> > If one wants to enforce a soft fork (or otherwise censor) this is accomplished by mining (or paying others to do so). Anyone can mine, so everyone gets a say. Mining is trading capital now for more later. If enough people want to do that, they can enforce a soft fork. It’s time Bitcoiners stop thinking of miners as other people. Anyone can mine, and that’s your vote.
>
>
>
>
>
> Who enforces consensus rules technically in Bitcoin? Full nodes or Miners?
>
>
>
>
>
> Is soft fork signaling same as voting?
>
>
>
>
>
> According to my understanding, miners follow the consensus rules enforced by full nodes and get (subsidy + fees) for their work. Signaling is not voting although lot of people consider it voting including some mining pools and exchanges.
>
>
>
>
>
>
>
>
> --
>
>
> Prayank
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210630/65f8d6a5/attachment-0001.html>;

📅 Original date posted:2021-06-27 📝 Original message:Hello ...

2023-06-07T22:55:40Z

In reply to nevent1q…3k7x
_________________________

📅 Original date posted:2021-06-27
📝 Original message:Hello Eric,
I have few questions:

> Without majority hash power support, activation simply means you are off on a chain split.

So majority hash power not following the consensus rules can result in chain split? Why would majority of miners decide to mine a chain that nobody wants to use? What are different things possible in this case based on game theory?

> And activation without majority hash power certainly does not “ensure” this.

Do miners and mining pools participate in discussions before signaling for a soft fork begins? Can they still mine something else post activation even if signaling readiness for soft fork?

> If one wants to enforce a soft fork (or otherwise censor) this is accomplished by mining (or paying others to do so). Anyone can mine, so everyone gets a say. Mining is trading capital now for more later. If enough people want to do that, they can enforce a soft fork. It’s time Bitcoiners stop thinking of miners as other people. Anyone can mine, and that’s your vote.

Who enforces consensus rules technically in Bitcoin? Full nodes or Miners?

Is soft fork signaling same as voting?

According to my understanding, miners follow the consensus rules enforced by full nodes and get (subsidy + fees) for their work. Signaling is not voting although lot of people consider it voting including some mining pools and exchanges.

--
Prayank
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210627/37586cb5/attachment.html>;

📅 Original date posted:2021-05-26 📝 Original message:Hello ...

2023-06-07T22:54:08Z

In reply to nevent1q…e3lu
_________________________

📅 Original date posted:2021-05-26
📝 Original message:Hello World,

There are other privacy issues in Core (node and wallet) but recently I came across one which can be used to identify if someone is using Bitcoin Core with just the bitcoin address and couple of transactions. I think people have already given up and don't expect privacy in Core wallet especially developers. However, below information may help some users who are not aware of this specific issue and developers who are using Bitcoin Core wallet in their project.

Issue is explained here: https://github.com/bitcoin/bitcoin/issues/22018

Even if there exists another wallet with similar behavior, it can affect privacy in some cases. Example: Alice is spying on Bob and collecting as much information as possible. She looks at social media accounts for Bob and thinks he might be using one of the wallets mentioned in PoC. She can confirm if Bob is using Bitcoin Core wallet by sending 2 small amounts to one of the address in different transactions. One transaction should have really low fee rate that it doesn't get confirmed.

I found this issue while reviewing PR: https://github.com/bitcoin/bitcoin/pull/18418

It was also discussed in a 'Core Review PR club' meeting recently: https://bitcoincore.reviews/18418

Also there are 2 things that helps identify wallet using address: 1. Can't spend unconfirmed UTXO 2. OUTPUT_GROUP_MAX_ENTRIES

OUTPUT_GROUP_MAX_ENTRIES was 10 earlier and 100 after PR #18418 got merged. This will help in confirming if someone is using latest Bitcoin Core once it is available in next release. Example: Alice is using Bitcoin Core v0.21.0 and Bob is using Bitcoin Core v0.22.0 Carol is the attacker and other two are victims. Carol sends small amounts to same address in 11 transactions to both and confirms Bob is using latest Bitcoin Core wallet while Alice is using an older version.

I will try to fix both 1 and 2 which can take few days and maybe never get merged. IMO 1 can be fixed by locking all UTXOs associated with a scriptpubkey until all are confirmed. UTXO locks are stored in memory only so will have to change that first. 2 can be fixed by using an approach similar to Electrum (All or None)

--
Prayank
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210526/77bb4f78/attachment.html>;

📅 Original date posted:2021-05-08 📝 Original message:My ...

2023-06-07T22:52:40Z

In reply to nevent1q…y56a
_________________________

📅 Original date posted:2021-05-08
📝 Original message:My opinion:

1.I don't consider PoS to be a better consensus mechanism compared to PoW used in Bitcoin. So any proposal related to PoS in Bitcoin is not an improvement for me.

2.Bitcoin is a protocol for decentralized network that creates consensus without needing a central authority to provide trust. Bitcoin with PoS will be a protocol for a network that creates consensus based on bitcoin holdings.

3.Experiments with PoS can work in trust minimized applications that use Bitcoin or LN or Bitcoin sidechains. However, PoW works better for base layer or Bitcoin protocol.

4.Bitcoin protocol should not be changed based on mainstream media articles, new buzzwords or trends, altcoins, governments etc.

5.Everything involves trade-offs. Not everything needs to be online. Not everything needs to be on a chain of blocks. There are things that you would prefer to save in a spreadsheet offline or write on a paper. Similarly PoS is not the best consensus mechanism for a 'decentralized network' but it may work for projects(not decentralized) that want to use Bitcoin for few things.

6.Most of the Bitcoin users and devs consider PoW used in Bitcoin as the best consensus mechanism. Few people experimenting with PoS will result in another altcoin with nothing much to contribute in improving Bitcoin. I think there are better things to focus on and one of them is privacy.

Few things related to Bitcoin mining that I consider improvements:

-Stratum v2
-More countries started mining bitcoin recently
-Recycling ASIC heat: https://braiins.com/blog/green-innovation-in-bitcoin-mining-recycling-asic-heat

I would love to see people in India researching about creating better ASICs and more involved in Bitcoin mining.

Related links:

https://bitcoin.stackexchange.com/questions/95356/why-doesnt-bitcoin-migrate-to-proof-of-stake

https://download.wpsoftware.net/bitcoin/asic-faq.pdf (Andrew Poelstra)

https://medium.com/@dsl_uiuc/fake-stake-attacks-on-chain-based-proof-of-stake-cryptocurrencies-b8b05723f806

--
Prayank
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210508/ba41a1a9/attachment.html>;

📅 Original date posted:2021-05-14 📝 Original message:I have ...

2023-06-07T22:52:24Z

In reply to nevent1q…8n3x
_________________________

📅 Original date posted:2021-05-14
📝 Original message:I have shared response by Jeremy and ZmnSCPxj in an answer to https://bitcoin.stackexchange.com/questions/105860/what-are-we-trying-to-predict-in-fee-estimation-and-why

Also find the recent CVE related to RBF by Antoine Riard and implementation of RBF in Bitcoin Core compared to btcd interesting. Even though I am not sure why inherited signalling is not implemented in Bitcoin Core.
RBF, CPFP and their combinations are something that is less explored IMO. For example: I had discussed one usecase of CPFP with Harding in IRC once in which a project uses maker-taker model. Maker broadcasts transaction with 1 sat/vByte and taker has to confirm this transaction by creating a child transaction with an effective fee rate according to mempool stats. Basically, the idea of receiver paying for the transaction instead of sender. But it will involve lot of exception handling.
--
Prayank
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210514/f256d77e/attachment.html>;

📅 Original date posted:2021-05-05 📝 Original message:Good ...

2023-06-07T22:52:23Z

In reply to nevent1q…m970
_________________________

📅 Original date posted:2021-05-05
📝 Original message:Good morning ZmnSCPxj,

Thanks for your response. I agree there are few exceptions:

1.Unconfirmed output can be spent resulting in conflict with RBF
2.Race condition and mining pool may include old transaction with low fee
I am trying few things related to RBF and handling such exceptions, will share if I find anything interesting.
--
Prayank

May 3, 2021, 09:32 by ZmnSCPxj at protonmail.com:

> Good morning Prayank,
>
> I believe a "true" full-RBF wallet should be what every onchain wallet aspires to.
>
> However, I think a lot of the effort necessary here has to do with sheer engineering issues.
>
> For example, if you think "RBF does not exist", you can do things like:
>
> * Spend an unconfirmed input from a third party.
> * This is not actually safe since an unconfirmed tx might have a conflicting transaction get confirmed, but a lot of onchain wallets support this for non-RBF unconfirmed inputs because 99.9% of the time this never happens.
> * When you spend from a (confirmed or unconfirmed) input, delete it from your db forever (because you do not have to worry about alternate transactions spending the same input).
> * This simplifies db design, you do not have to keep track of states like "has been spent but tx is not confirmed yet", "has two different alternate transactions spending it that have not confirmed", "is on a transaction that is not confirmed and therefore this input might disappear completely" etc.
>
> In particular, if we want a "true" full-RBF wallet:
>
> * Suppose the user wants to spend some amount to address A.
> * The user imposes a limit on up to how much to spend on fees to have this spend happen.
> * The wallet optimistically creates a low-fee send transaction.
> * After some time, the wallet bumps up the fee by creating a new transaction.
> * The wallet keeps bumping up, up to the designated limit, the longer the transaction is not confirmed.
>
> Of note is that there is a *race condition* in the above case.
> When the wallet is bumping up and constructing a new transaction with higher fee, a miner could find a new block that has the old transaction with lower fee.
>
> Now consider the subsequent user story.
>
> * After some time, the user wants to spend another amount to address B.
> * Again the user imposes a limit on how much to spend on fees to have this spend happen.
> * The wallet RBFs the existing transaction to include the spend to address B.
>
> Again, a race condition can occur --- while the wallet is feebumping a new transaction that includes the new output, a random miner can find a new block that includes the old transaction.
>
> Thus, the wallet really needs to keep track of any "pending spends" and correlate them with actual transactions.
>
> Further, of course it is convenient to be able to spend money even while it is unconfirmed.
> But the sender of the unconfirmed input might be using the same software as this wallet as well, meaning that the actual transaction output might change as the original spender keeps fee-bumping it over time.
>
> I confess I have not been thinking of this as well as I should have.
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210506/a77cc71c/attachment.html>;

📅 Original date posted:2021-05-01 📝 Original message:Thanks ...

2023-06-07T22:52:22Z

In reply to nevent1q…z37c
_________________________

📅 Original date posted:2021-05-01
📝 Original message:Thanks Jeremy for sharing this link: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html

Trying to understand everything mentioned and "fee-only" wallet sounds interesting.
--
Prayank

May 1, 2021, 05:41 by jlrubin at mit.edu:

> Hi Prayank,
>
> Very glad to hear you are weathering the storm OK, wishing you and yours safety in the weeks ahead.
>
> I think you'll be interested to see > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html>; especially with regards to background services.
>
> In the long term, this can be particularly useful since you can use a separate fee-only wallet to arrange the bumps if your main wallet keys are offline, and you do not disturb any of the on-chain dependants.
>
> It can also be much cheaper to use this mechanism than actual RBF because you are not subject to the feerate improvement rule, which forces you to pay for the bump on all tx data.
>
> I would be very interested to see a system whereby you can make a market (maybe via LN) for someone to get your TX included (using oracle network OK) by a particular date. Then you can abstract the whole system a lot better, so that you can fee bump without having to create any direct on chain traffic, and a sponsor vector can be offered across a number of txns by a service provider.
>
> Cheers,
>
> Jeremy
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>; <https://twitter.com/JeremyRubin>;
>
>
> On Fri, Apr 30, 2021 at 2:40 PM Prayank via bitcoin-dev <> bitcoin-dev at lists.linuxfoundation.org> > wrote:
>
>> Hello World,
>>
>> I hope everyone is doing okay. Things are not good in India and even I was tested covid positive few days back. Recovered and feeling better now. Hoping everything gets back to normal soon.
>>
>> There are different estimations used in wallets, explorers and other Bitcoin projects. For example: `estimatesmartfee` in Bitcoin Core (One of the implementation for Bitcoin which is used more but not official as there is nothing official in Bitcoin). Are different estimations misleading and affect the way fees are used in Bitcoin transactions? Will it be better if we just share mempool stats and user can decide the fee rate accordingly?
>>
>> If I compare this with BTCUSD orderbook on any exchange, are we trying to estimate at what price buy order will get filled in certain time? Does that make sense?
>>
>> Mempool Stats: >>
>> BTCUSD Orderbook: >>
>>
>> I consider it misleading because lot of users think a transaction with fee rate 1-5 sat/vByte will be included in 1 week or maybe a transaction with X sat/VByte will be included in Y time which is not true. Users can decide the fee rate and can do bidding, transaction will be included based on demand, supply and miners.
>>
>> Will it be better if the wallets used this approach?
>> 1.Show mempool stats
>> 2.Leave the fee rate for user to decide
>> 3.RBF every transaction and follow different algorithms for automated bidding
>>
>> A basic algorithm for automated bidding can be: >>
>>
>> Such RBF algos can be helpful for users when Bitcoin wallets are open in background. Maybe it will work better for mobile wallets in which you can see a notification every time transaction is replaced with a new fee rate automatically.
>>
>> I wanted to know what others think about this approach of creating and using different RBF algos instead of predicting something that is difficult or doesn't make sense. Also if there was a way we could achieve this even if the user goes offline. For example: Alice broadcasts Tx1 with 1 sat/vByte, its replaced with Tx2 (2 sat/vByte) after 2 blocks because Tx1 was not confirmed. Alice decides to shut down her system or switch off mobile or mobile data. Tx2 is still not confirmed after another 2 blocks but it has some information as one OP_RETURN output which is used by Bitcoin nodes that see this transaction in the mempool. Bob's node use this information to replace the transaction with Tx3 and use fee rate 3 sat/vByte.
>>
>> --
>> Prayank
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> >> bitcoin-dev at lists.linuxfoundation.org
>> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210501/196939d4/attachment.html>;

📅 Original date posted:2021-04-21 📝 Original message:Hello ...

2023-06-07T22:51:59Z

In reply to nevent1q…5f7s
_________________________

📅 Original date posted:2021-04-21
📝 Original message:Hello Christopher,

Decentralized storage as an idea looks interesting. I am researching about similar things for one of my Bitcoin project. Although an implementation or proof of concept code in the BIP would have been better. Also since this involves LN, maybe it can just be a LN project instead of BIP? Not the best person to comment on what can be a BIP.

Few links that you may find interesting:

https://github.com/bkiac/tarnhelm

https://github.com/ElementsProject/filebazaar

The kind of decentralized storage that I think can be helpful for Bitcoin projects:

1.Uses torrents for files and communication required (with Tor)

2.Easy to use API to save, read, edit etc. something in a Bitcoin project using torrents. Only involve lightning network and payments when spamming can be an issue. For example: If a developer wants users to pay for every P2P offer they create using a DEX protocol.

Projects that are exploring such options: https://github.com/JoinMarket-Org/joinmarket-clientserver/issues/415

--
Prayank
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210421/986bd0ae/attachment.html>;

📅 Original date posted:2021-04-21 📝 Original message:Hello ...

2023-06-07T22:51:54Z

In reply to nevent1q…ul5y
_________________________

📅 Original date posted:2021-04-21
📝 Original message:Hello Yanmaani,

Incentives for UTXO consolidation already exists IMO.

1.If UTXO consolidation is done when fee rates are low (less congestion in mempool), it helps in saving money in lot of cases. Example: https://bitcoin.stackexchange.com/a/100811/
2.If running full node for Bitcoin, it will help in a smaller UTXO set.

In few cases it affects privacy though like post coinjoin.

TBH I couldn't understand everything you mentioned including the part in which fees decrease is mentioned because of smaller block. Fees should increase if such blocks are regularly mined and are predictable IMO. Not sure if everyone will agree to the other things mentioned in the proposal.
--
Prayank
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210421/1fb43144/attachment.html>;

📅 Original date posted:2021-04-07 📝 Original ...

2023-06-07T22:51:30Z

In reply to nevent1q…7n48
_________________________

📅 Original date posted:2021-04-07
📝 Original message:Positives:

You need money to participate even though your position size may not matter if really small based on liquidity and volume.
Useful information if looking at overall sentiments especially traders
Noise filter because its not same as trolling on social media
Opportunity for some people to make money
Entertainment and something new to discuss or confirm bias

Negatives:

You need money to participate. "Full nodes enforce consensus rules" becomes a meme. Full nodes will still enforce consensus rules but some full nodes are being influenced by people with money which can be anything not necessarily bitcoin.
Information that may not be useful for everyone.
The exchanges who have created such markets in past and the traders involved know how to manipulate illiquid markets at least for a short time period. And sometimes "markets can remain irrational longer than you can remain solvent".
If such markets affect Bitcoin development in any way, it will be great opportunity for governments to attack Bitcoin. Example: Consider we have a soft fork or hard fork for confidential transaction on-chain in future, if someone is able to find a secure way to implement it. All the governments that love to spy will have some issues with it and won't be the first time if they participate in such markets indirectly to manipulate or start some investigation against exchanges involved or something else.
Focus which should have been on improving Bitcoin will now shift to futures markets and their involvement in Bitcoin.

I think prediction markets or such tokens might help in adding to the information we already have however they don't decide or replace anything. Bitcoin development should impact such markets and not the other way around. Nobody can stop markets from betting on something related to Bitcoin and it can even be done using P2P exchanges like HodlHodl: https://predictions.hodlhodl.com or create something new with oracles which can be implemented using DLC: https://github.com/discreetlogcontracts/dlcspecs

Not everyone is a trader or interested to take risk in such markets even if a Bitcoin user from years, lot of transactions, contributions and some opinion on Taproot based on things that are publicly available to everyone but scattered. In past we had things that made some sense for prediction markets like 2x and Bcash but right now nobody has issues with Taproot and even the best traders won't be aware of all the technical details about Bitcoin development to predict something related to activation mechanism.

If the point of using prediction markets is to filter noise or spam then maybe we can have one chatroom that requires some sats to enter and pay some sats for each post. We will have better information here and sats can be used to donate to devs who review PRs related to Taproot.
--
Prayank
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210407/92259e3c/attachment.html>;

📅 Original date posted:2021-04-07 📝 Original ...

2023-06-07T18:31:25Z

In reply to nevent1q…ew7l
_________________________

📅 Original date posted:2021-04-07
📝 Original message:Positives:

You need money to participate even though your position size may not matter if really small based on liquidity and volume.
Useful information if looking at overall sentiments especially traders
Noise filter because its not same as trolling on social media
Opportunity for some people to make money
Entertainment and something new to discuss or confirm bias

Negatives:

You need money to participate. "Full nodes enforce consensus rules" becomes a meme. Full nodes will still enforce consensus rules but some full nodes are being influenced by people with money which can be anything not necessarily bitcoin.
Information that may not be useful for everyone.
The exchanges who have created such markets in past and the traders involved know how to manipulate illiquid markets at least for a short time period. And sometimes "markets can remain irrational longer than you can remain solvent".
If such markets affect Bitcoin development in any way, it will be great opportunity for governments to attack Bitcoin. Example: Consider we have a soft fork or hard fork for confidential transaction on-chain in future, if someone is able to find a secure way to implement it. All the governments that love to spy will have some issues with it and won't be the first time if they participate in such markets indirectly to manipulate or start some investigation against exchanges involved or something else.
Focus which should have been on improving Bitcoin will now shift to futures markets and their involvement in Bitcoin.

I think prediction markets or such tokens might help in adding to the information we already have however they don't decide or replace anything. Bitcoin development should impact such markets and not the other way around. Nobody can stop markets from betting on something related to Bitcoin and it can even be done using P2P exchanges like HodlHodl: https://predictions.hodlhodl.com or create something new with oracles which can be implemented using DLC: https://github.com/discreetlogcontracts/dlcspecs

Not everyone is a trader or interested to take risk in such markets even if a Bitcoin user from years, lot of transactions, contributions and some opinion on Taproot based on things that are publicly available to everyone but scattered. In past we had things that made some sense for prediction markets like 2x and Bcash but right now nobody has issues with Taproot and even the best traders won't be aware of all the technical details about Bitcoin development to predict something related to activation mechanism.

If the point of using prediction markets is to filter noise or spam then maybe we can have one chatroom that requires some sats to enter and pay some sats for each post. We will have better information here and sats can be used to donate to devs who review PRs related to Taproot.
--
Prayank
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210407/92259e3c/attachment.html>;

📅 Original date posted:2021-03-19 📝 Original message:> ...

2023-06-07T18:30:50Z

In reply to nevent1q…a4ng
_________________________

📅 Original date posted:2021-03-19
📝 Original message:> back in the day we also had people that thought 10 min avg block time is too much.

Not sure what some people thought about block time interval has to do with me. Also these are the things written by Greg Maxwell and Chris Belcher about it that I agree with and been sharing from sometime now on many platforms:

https://twitter.com/prayankgahlot/status/1269164956899049474

https://bitcoin.stackexchange.com/a/103289/

> Starting from the parameters of bitcoin consensus to the way Bitcoin Core is organized to the minimum time of 18 months an upgrade needs to last. (based on prior experience) If you want to challenge any of the old rules it takes more than ignoring them and doing whatever you feel like (is useful to get the result you want (again the tyrant theme)).

I was assuming Bitcoin is a protocol for p2p decentralized network and Bitcoin Core is just one implementation which is used by most of the people for lot of reasons but things can be improved and I am hopeful will improve with time. Users were, are and will be free to run whatever they feel like: Bitcoin Core or fork of Bitcoin Core or Other implmenations but still use Bitcoin.

> You seem to believe that there exists some entity that gets to decide what goes on and gets to exclude anyone it wants from the decision making process.

No I don't. You seem to have lot of assumptions. My comments were expectations from the people who are more experienced than me and know more about Bitcoin development. Things can change, you can always go out of the box to improve things.

> "we" is a reference to "we're all Satoshi" and the "things" you will learn by learning the past.

Satoshi if was a person and not group would be disappointed about few things but anyways. "We" should not discourage people from discussion about soft forks that everyone agrees will improve Bitcoin. I don't know everything about past but again thanks for the assumptions.

> If the meeting is about making progress on an issue very few people have any clue about then it is desirable that the people that are looking to learn should do so using other venues.

Any suggestions which venues will work better for Taproot related meeting that you don't have issues with?

--
Prayank
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210319/6755aa01/attachment.html>;

📅 Original date posted:2021-03-17 📝 Original message:> ...

2023-06-07T18:30:49Z

In reply to nevent1q…utkr
_________________________

📅 Original date posted:2021-03-17
📝 Original message:> the last thing we need is
a rushed upgrade

Why do you think this is rushed? Speedy Trial will have few months and if UASF is required it won't involve activation immediately after ST fails. Taproot by 2022 doesn't look rushed approach IMO.

> We're not changing things that we worked out already.

Which things have we worked out that cannot be changed or not changed earlier?

> how long till we go back and change the coin supply?

Coin supply has nothing to do with soft fork activation mechanism IMO.

> I understand some of you have no patience and would like mass adoption tomorrow but those are exactly the people that do not have a say in Bitcoin development. If you want to get rich quick you do not care about Bitcoin.

Taproot activation or discussion about activation mechanism does not have 100% correlation with mass adoption. It just improves Bitcoin and helps few projects mentioned in https://en.bitcoin.it/wiki/Taproot_Uses
Nobody is talking about get rich quick schemes in Taproot Activation related meetings. At least I have not seen anyone.

> If you want faster development cycles then you have lightning to play with.

Better development cycles with less delay, less misinformation, less politics, less probability of things being exploited by mining pools or other people, organization etc. with their influence. Lightning Network is a separate project focused on layer 2 and I think it will also benefit from Taproot.

> we *DO NOT* change things we already established in the past

Interested to know who is "we" in this sentence and what are the "things" that cannot be changed.

> In order to solve the LOT debate lets give Wladimir the power to decide on his own and if he has no strong opinions he should just flip a coin.

LOT has become LOL. If this is about Bitcoin Core maintainers deciding things for Bitcoin Core, sure they already do. But users have the freedom to decide if they want to run it with default settings or use other implementation.

> MAST threshold can be even lower because it is not representative of an economic majority and it could speed up the upgrade.

Agree

> At this point involve as few people as possible and get it done. This is just about the software and the parameters of the new consesus.

Everyone should be welcome to participate in meetings, ask questions, learn more and contribute. I don't see anything wrong with it.
--
Prayank
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210317/7b263d63/attachment-0001.html>;

📅 Original date posted:2021-02-21 📝 Original message:Hello ...

2023-06-07T18:29:04Z

In reply to nevent1q…c8vt
_________________________

📅 Original date posted:2021-02-21
📝 Original message:Hello Everyone,

The below comment by Matt about different implementations and their opinion on `lockinontimeout` is from 18 Feb 2021 communication: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018433.html

> If the eventual outcome is that different implementations (that have material *transaction processing* userbases, and I’m not sure to what extent that’s true with Knots) ship different consensus rules, we should stop here and not activate Taproot. Seriously. Bitcoin is a consensus system. The absolute worst outcome at all possible is to have it fall out of consensus.

I don't agree to the part that 'we should stop and not activate taproot'. Instead it will be helpful if we can educate most of the people about trade-offs involved in both options with some tables, charts etc.

I think its time to use Bitcoin Knots for more projects and also maintain multiple forks of Bitcoin Core. This is not just limited to `LOT=True or False` but few other things and in general its good for decentralization of Bitcoin. Bitcoin Core is used by most of the nodes according to this pie chart: https://luke.dashjr.org/programs/bitcoin/files/charts/software.html however having multiple forks of Bitcoin Core with real usage, more maintainers in different parts of the world (some even anon), few different features, more reviewers, better communication channels etc. will help everyone involved in Bitcoin.

I am working on a project right now which involves multisig, discreet log contracts, liquid etc. Using bitcoin-s for it because I need DLC but still depending on Bitcoin Core in it. Would try Bitcoin Knots and other implementations soon and also have been looking for developers good with C++ and Python, living in India who are interested to maintain a fork of Bitcoin Core with few changes. I had shared about in replies to Amir Taaki's tweet few days back.

--
Prayank

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210221/0fac6a94/attachment-0001.html>;

📅 Original date posted:2020-12-06 📝 Original message:Hello ...

2023-06-07T18:27:42Z

In reply to nevent1q…eq8c
_________________________

📅 Original date posted:2020-12-06
📝 Original message:Hello Everyone,

I know there have been lot of controversial and heated discussions involving Samourai in past. Ignoring everything including the tweets in which Samourai team mentioned no interest in proposing a BIP related to automated and secure communication used in Soroban, I wanted to know if enough people would be interested in a BIP because it may help other bitcoin projects in future.

Tweets: https://twitter.com/SamouraiWallet/status/1334977957157367810 <https://twitter.com/SamouraiWallet/status/1334977957157367810?s=19>;

https://twitter.com/SamouraiDev/status/1335103101188104194 <https://twitter.com/SamouraiDev/status/1335103101188104194?s=19>;

Ben also tweeted that a BIP would make sense: https://twitter.com/benthecarman/status/1334977096079306753 <https://twitter.com/benthecarman/status/1334977096079306753?s=19>;

I think we should keep all the controversial things aside and do everything that helps Bitcoin. It's mentioned in the medium article that it can help other projects like joinmarket, coinswap, snickr etc.

https://link.medium.com/uBvIJUSLQbb

The source code for a client library in Java is available here https://code.samourai.io/wallet/soroban-client-java and the source code for the Go based server component is available here https://code.samourai.io/wallet/samourai-soroban

Let me know if a BIP for such implementation to be used by other bitcoin projects makes sense and if anyone willing to help me in creating a BIP.

Thanks.

-- Prayank
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20201206/64b59e21/attachment.html>;