<unnamed>

Public Key

npub1xwdym5sne88xldc5809azwrgasp60ze27easgew8e7p3vj7qr7ssjc2lxh

Profile Code

nprofile1qqsr8xjd6gfunnn0ku2rhj738p5wcqa83v40v7cyvhrulqckf0qplggprpmhxue69uhhyetvv9ujuumwdae8gtnnda3kjctvptghcu

Publishing to

relay.snort.social

Last Notes

2023-06-07 23:03:11 UTC

- reply

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

2023-06-07 23:02:11 UTC

- 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:00:01 UTC

- 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:44 UTC

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

- 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%[email protected]/> .
>
> 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:52:40 UTC

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