Re: [bitcoin-dev] Mock introducing vulnerability in important Bitcoin projects

[Prayank via bitcoin-dev]

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 rsom...@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%2ftsbmczz...@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@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 >>  Lightning implementation
>> 3.Bisq
>> 4.Two Bitcoin libraries
>> 5.Two Bitcoin wallets
>> 6.One >>  open source block explorer
>> 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 >> zmnsc...@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:

Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit

[Pieter Wuille via bitcoin-dev]

Jumping in late to this thread.

I very much agree with how David Harding presents things, with a few comments 
inline.

‐‐‐ Original Message ‐‐‐
On Sunday, August 8th, 2021 at 5:51 PM, David A. Harding via bitcoin-dev 
 wrote:

> > 1.  it's not our business what outputs people want to create
>
> Every additional output added to the UTXO set increases the amount of
> work full nodes need to do to validate new transactions. For miners
> for whom fast validation of new blocks can significantly affect their
> revenue, larger UTXO sets increase their costs and so contributes
> towards centralization of mining.
> Allowing 0-value or 1-sat outputs minimizes the cost for polluting the
> UTXO set during periods of low feerates.
> If your stuff is going to slow down my node and possibly reduce my
> censorship resistance, how is that not my business?

Indeed - UTXO set size is an externality that unfortunately Bitcoin's consensus 
rules fail to account
for. Having a relay policy that avoids at the very least economically 
irrational behavior makes
perfect sense to me.

It's also not obvious how consensus rules could deal with this, as you don't 
want consensus rules
with hardcoded prices/feerates. There are possibilities with designs like 
transactions getting
a size/weight bonus/penalty, but that's both very hardforky, and hard to get 
right without
introducing bad incentives.

> > 2.  dust outputs can be used in various authentication/delegation smart
> > contracts
>
> > 3.  dust sized htlcs in lightning (
> > 
> > https://bitcoin.stackexchange.com/questions/46730/can-you-send-amounts-that-would-typically-be-considered-dust-through-the-light)
> > force channels to operate in a semi-trusted mode
>
> > 4.  thinly divisible colored coin protocols might make use of sats as value
> > markers for transactions.

My personal, and possibly controversial, opinion is that colored coin protocols 
have no business being on the Bitcoin chain, possibly
beyond committing to an occasional batched state update or so. Both because 
there is little benefit for tokens with a trusted
issuer already, and because it competes with using Bitcoin for BTC - the token 
that pays for its security (at least as long as
the subsidy doesn't run out).

Of course, personal opinions are no reason to dictate what people should or can 
use the chain for, but I do think it's reason to
voice hesitancy to worsening the system's scalability properties only to 
benefit what I consider misguided use.

> > 5.  should we ever do confidential transactions we can't prevent it without
> > compromising privacy / allowed transfers
>
> I'm not an expert, but it seems to me that you can do that with range
> proofs. The range proof for >dust doesn't need to become part of the
> block chain, it can be relay only.

Yeah, range proofs have a non-hidden range; the lower bound can be nonzero, 
which could be required as part of a relay policy.

Cheers,

--
Pieter

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Mock introducing vulnerability in important Bitcoin projects

[ZmnSCPxj via bitcoin-dev]

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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit

[Erik Aronesty via bitcoin-dev]

mostly thinking out loud

suppose there is a "lightweight" node:

1. ignores utxo's below the dust limit
2. doesn't validate dust tx
3. still validates POW, other tx, etc.

these nodes could possibly get forked - accepting a series of valid,
mined blocks where there is an invalid but ignored dust tx, however
this attack seems every bit as expensive as a 51% attack

On Fri, Oct 1, 2021 at 3:45 AM Pieter Wuille via bitcoin-dev
 wrote:
>
> Jumping in late to this thread.
>
> I very much agree with how David Harding presents things, with a few comments 
> inline.
>
> ‐‐‐ Original Message ‐‐‐
> On Sunday, August 8th, 2021 at 5:51 PM, David A. Harding via bitcoin-dev 
>  wrote:
>
> > > 1.  it's not our business what outputs people want to create
> >
> > Every additional output added to the UTXO set increases the amount of
> > work full nodes need to do to validate new transactions. For miners
> > for whom fast validation of new blocks can significantly affect their
> > revenue, larger UTXO sets increase their costs and so contributes
> > towards centralization of mining.
> > Allowing 0-value or 1-sat outputs minimizes the cost for polluting the
> > UTXO set during periods of low feerates.
> > If your stuff is going to slow down my node and possibly reduce my
> > censorship resistance, how is that not my business?
>
> Indeed - UTXO set size is an externality that unfortunately Bitcoin's 
> consensus rules fail to account
> for. Having a relay policy that avoids at the very least economically 
> irrational behavior makes
> perfect sense to me.
>
> It's also not obvious how consensus rules could deal with this, as you don't 
> want consensus rules
> with hardcoded prices/feerates. There are possibilities with designs like 
> transactions getting
> a size/weight bonus/penalty, but that's both very hardforky, and hard to get 
> right without
> introducing bad incentives.
>
> > > 2.  dust outputs can be used in various authentication/delegation smart
> > > contracts
> >
> > > 3.  dust sized htlcs in lightning (
> > > 
> > > https://bitcoin.stackexchange.com/questions/46730/can-you-send-amounts-that-would-typically-be-considered-dust-through-the-light)
> > > force channels to operate in a semi-trusted mode
> >
> > > 4.  thinly divisible colored coin protocols might make use of sats as 
> > > value
> > > markers for transactions.
>
> My personal, and possibly controversial, opinion is that colored coin 
> protocols have no business being on the Bitcoin chain, possibly
> beyond committing to an occasional batched state update or so. Both because 
> there is little benefit for tokens with a trusted
> issuer already, and because it competes with using Bitcoin for BTC - the 
> token that pays for its security (at least as long as
> the subsidy doesn't run out).
>
> Of course, personal opinions are no reason to dictate what people should or 
> can use the chain for, but I do think it's reason to
> voice hesitancy to worsening the system's scalability properties only to 
> benefit what I consider misguided use.
>
> > > 5.  should we ever do confidential transactions we can't prevent it 
> > > without
> > > compromising privacy / allowed transfers
> >
> > I'm not an expert, but it seems to me that you can do that with range
> > proofs. The range proof for >dust doesn't need to become part of the
> > block chain, it can be relay only.
>
> Yeah, range proofs have a non-hidden range; the lower bound can be nonzero, 
> which could be required as part of a relay policy.
>
> Cheers,
>
> --
> Pieter
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Replacement transaction and ancestor score bug

[Prayank via bitcoin-dev]

This pull request was mentioned in the thread: "Proposal: Package Mempool 
Accept and Package RBF" however I am not sure if everyone would have read all 
the emails if they were not interested in packages. Also not possible to keep 
track of each pull request in Bitcoin Core repository.

PR: https://github.com/bitcoin/bitcoin/pull/23121

I came across this pull request while reviewing few others and found the 
details in comments interesting. I think everyone who is using Bitcoin and RBF 
should be aware of this bug. I won't add my opinions or comments, copying few 
lines from PR:

> However, Example N shows how this strategy can cause us to accept an 
> replacement transaction that is actually less economical to mine than the 
> original. Assume all transactions have a vsize of 100vB. A user wants to 
> replace A, which has an ancestor score of 10sat/vB, with transaction C. 
> Suppose they want to spend an unconfirmed output from transaction B, which 
> has an ancestor score of 1sat/vB (maybe their wallet doesn't have enough 
> funds to provide a higher fee using only confirmed inputs). BIP125#2 prevents 
> scenario N1, where the inclusion of another unconfirmed input means C has an 
> ancestor score of 8sat/vB and thus less economical to mine than A. However, 
> it does not prevent scenario M2, where the user splits off a 1-input 1-output 
> transaction, C*, in order to be able to include the output from B. This 
> causes us to incorrectly accept C (7.5sat/vB including its parent B) in favor 
> of A (10sat/vB).


-- 
Prayank

A3B1 E430 2298 178F
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Mock introducing vulnerability in important Bitcoin projects

[Prayank via bitcoin-dev]

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 zmnsc...@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
>

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Mock introducing vulnerability in important Bitcoin projects

[Ryan Grant via bitcoin-dev]

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.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev