Prayank [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2020-05-26 to 2022-03-07
💬 Posted a total of 92 messages
📚 Participated in the following categories: bitcoin-dev, Bitcoin Advent Calendar, Lightning-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub1xwdym5sne88xldc5809azwrgasp60ze27easgew8e7p3vj7qr7ssjc2lxh

Profile Code

nprofile1qqsr8xjd6gfunnn0ku2rhj738p5wcqa83v40v7cyvhrulqckf0qplgg08dt54

Author Public Key

npub1xwdym5sne88xldc5809azwrgasp60ze27easgew8e7p3vj7qr7ssjc2lxh

Show more details

Last Notes

2023-06-07 23:04:41

- reply

📅 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>

2023-06-07 23:04:40

- reply

📅 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>

2023-06-07 23:02:34

- reply

📅 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>

2023-06-07 23:02:11

- reply

📅 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>

2023-06-07 23:02:04

- reply

📅 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>

2023-06-07 23:02:02

- reply

📅 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>

2023-06-07 23:02:01

- reply

📅 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>

2023-06-07 23:01:59

- reply

📅 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>

2023-06-07 23:01:58

- reply

📅 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>

2023-06-07 23:00:28

- reply

📅 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>

2023-06-07 23:00:01

- reply

📅 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>

2023-06-07 22:59:45

- reply

📅 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>

2023-06-07 22:59:44

- reply

📅 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>

2023-06-07 22:59:43

- reply

📅 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>

2023-06-07 22:58:33

- reply

📅 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>

2023-06-07 22:55:42

- reply

📅 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>

2023-06-07 22:52:40

- reply

📅 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>

2023-06-07 22:51:59

- reply

📅 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>

2023-06-07 22:51:30

- reply

📅 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>

2023-06-07 18:27:42

- reply

📅 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>