Re: [bitcoin-dev] Decentralized BIP 47 payment code directory

[Prayank via bitcoin-dev]

Hi Peter,

> Regarding to BIP47 there's a newer version (v3 and v4) proposed here: 
> https://github.com/OpenBitcoinPrivacyProject/rfc/blob/master/obpp-05.mediawiki

> Now the notification from Alice to Bob is a transaction from Alice to Alice 
> as a bare 1 of 3 multisig. The other 2 pubkeys represent Alice's payment code 
> and Bob's payment identifier. Eliminating the toxic change issue.

Thanks for sharing the link. Removing toxic change sounds good and certainly an 
improvement.

> An xpub doesn't accomplish this because if you have your xpub in a 
> crowdfunding platform the platform or anyone who hacks it can identify your 
> payments. With the payment code you can associate yourself publicly with your 
> payment code and no one (who is not the sender) will know if you received 
> funds as your payment code is not visible in the blockchain.

Crowdfunding platform can also be self hosted like BTCPay server. In this case 
XPUB is not shared with anyone as long as machine running BTCPay is secure. 
Problem with this setup is users need to setup BTCPay, running all the time and 
manage gap limit. No such thing is required in using BIP 47 payment codes.

There is also a [rust library][1] to use BIP 47 and I found the link on twitter 
yesterday. I think this can be helpful for application developers to implement 
BIP 47 payment codes in different bitcoin projects.

[1]: https://github.com/rust-bitcoin/rust-bip47


-- 
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] Wasabi Wallet 2.0 Testnet Release

[Prayank via bitcoin-dev]

Hi Max,

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

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

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

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

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

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

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

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

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

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

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

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


[1]: https://i.imgur.com/Gxjmhau.png
[2]: https://github.com/bitcoin/bitcoin/pull/23789


-- 
Prayank

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

[bitcoin-dev] Decentralized BIP 47 payment code directory

[Prayank via bitcoin-dev]

Hello World,

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

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

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

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

```

Payment code for Alice: 
PM8TJggVVXFKAmfkjnA1CQcrSbGScUKRsVohpfMpSM56f6jg5uQTPJvNS1wKDGV17d9NWLqoVzsJ8qURqpUECmSFLcUuC4g3aMtoXp2fChY1ZEqzG16f

Start GNUnet: 

gnunet-arm -s

Create identity:

gnunet-identity -C alice

Check public key:

gnunet-identity -d

alice - 000G005XCTRJ0DJGPVPNY66GAY52C61KA8A7CA92PKT51PHNVWY9JF8WB4 - ECDSA

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

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

Check payment code:

gnunet-gns -t TXT -u pay.alice

pay.alice:
Got `TXT' record: 
PM8TJTLJbPRGxSbc8EJi42Wrr6QbNSaSSVJ5Y3E4pbCYiTHUskHg13935Ubb7q8tx9GVbh2UuRnBc3WSyJHhUrw8KhprKnn9eDznYGieTzFcwQRya4GA

```

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

Related:

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


-- 
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] Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

[Prayank via bitcoin-dev]

Good morning ZmnSCPxj,

> Of course, I know of no such technique, but given that a technique 
> (Drivechains) which before would have required its own consensus change, 
> turns out to be implementable inside recursive covenants, then I wonder if 
> there are other things that would have required their own consensus change 
> that are now *also* implementable purely in recursive covenants.


Agree. I would be interested to know what is NOT possible once we have 
recursive covenants.

> if there is *now* consensus that Drivechains are not bad, go ahead, add 
> recursive covenants (but please can we add `SIGHASH_NOINPUT` and `OP_CTV` 
> first?)


Agree and I think everything can be done in separate soft forks.



-- 
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] Stumbling into a contentious soft fork activation attempt

[Prayank via bitcoin-dev]

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

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

Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt

[Prayank via bitcoin-dev]

> 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 e...@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@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 
>> 
>>  ___
>>  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

Re: [bitcoin-dev] Thoughts on fee bumping

[Prayank via bitcoin-dev]

> If anyone has any indication that there are miners running forks of bitcoind 
> that change this behavior, I'd be curious to know it.
It is possible because some mining pools use bitcoind with custom patches. 

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

-- 
Prayank

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

Re: [bitcoin-dev] Thoughts on fee bumping

[Prayank via bitcoin-dev]

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

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

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

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

-- 
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] [Lightning-dev] Lightning and other layer 2 projects with multiple RBF policies

[Prayank via bitcoin-dev]

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

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

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

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

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

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


-- 
Prayank

A3B1 E430 2298 178F



Feb 14, 2022, 22:32 by michaelfolk...@protonmail.com:

> > This is the assumption which I don't agree with and hence asked some 
> > questions in my email. A new RBF policy used by default in Core will not 
> > improve the security of projects that are vulnerable to multiple RBF 
> > policies or rely on these policies in a way that affects their security. 
>
> Right, not immediately. If and when new policy rules are included in a 
> Bitcoin Core release it would take a while before a significant majority of 
> the network were running those new policy rules (barring some kind of 
> urgency, an attacker exploiting a systemic security flaw etc). That's not an 
> argument not to do it though if you take a longer term perspective on 
> building the strongest possible foundation for Lightning or other Layer 2 
> projects. The security benefit would just be delayed until a significant 
> majority of Bitcoin Core users upgraded to a version including those new 
> policy rules.
>
> > > Bitcoin Core with different versions are used at any point and not sure 
> >if this will ever change.
>
> Sure there will always be some stray full nodes running extremely old 
> versions but the general direction of travel is more and more full nodes 
> upgrading to newer versions. A network where *all* full nodes are running the 
> same policy rules is clearly not an option available to us without making 
> policy rules effective consensus rules and forking/kicking those old versions 
> off the network.
>
> > > Maybe some experiments on signet might help in knowing more issues 
> >associated with multiple RBF policies.
>
> Definitely agree. It is a really interesting research area and lots of 
> opportunities for simulations and experiments on the default or custom signet 
> networks. Especially if we fill blocks with auto-generated transactions 
> and/or reduce block sizes and create an artificial fee market.
>
> --
> Michael Folkson
> Email: michaelfolkson at > protonmail.com > Keybase: 
> michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>
>
>
> --- Original Message ---
>  On Monday, February 14th, 2022 at 5:18 AM, Prayank  
> wrote:
>  
>
>> > I suspect as with defaults generally most users will run whatever the 
>> > defaults are as they won't care to change them (or even be capable of 
>> > changing them if they are very non-technical).
>>
>>
>> 30% nodes are using 0.21.1 right now whereas latest version was 22.0 and 
>> some are even running lower versions. Different versions in future with 
>> defaults might be running RBF v1 and RBF v2.
>>
>> > But users who have a stake in the security of Lightning (or other Layer 2 
>> > projects) will clearly want to run whatever policy rules are beneficial to 
>> > those protocols.
>>
>>
>> Agree and attackers will want to run the nodes with policy that helps them 
>> exploit bitcoin projects. Miners can run nodes with policy that helps them 
>> get more fees. 
>>
>> > As you know the vast majority of the full nodes on the network currently 
>> > run Bitcoin Core. Whether that will change in future and whether this a 
>> > good thing or not is a whole other discussion. But the reality is that 
>> > with such strong dominance there is the option to set defaults that are 
>> > widely used.
>>
>>
>> Bitcoin Core with different versions are used at any point and not sure if 
>> this will ever change.
>>
>> https://luke.dashjr.org/programs/bitcoin/files/charts/security.html
>>
>> https://www.shodan.io/search/facet.png?query=User-Agent%3A%2FSatoshi%2F+port%3A%228333%22=product
>>
>> > I think if certain defaults 

Re: [bitcoin-dev] [Lightning-dev] Lightning and other layer 2 projects with multiple RBF policies

[Prayank via bitcoin-dev]

> I suspect as with defaults generally most users will run whatever the 
> defaults are as they won't care to change them (or even be capable of 
> changing them if they are very non-technical).
 

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


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

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

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

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

https://www.shodan.io/search/facet.png?query=User-Agent%3A%2FSatoshi%2F+port%3A%228333%22=product
> I think if certain defaults can bolster the security of Lightning (and 
> possibly other Layer 2 projects) at no cost to full node users with no 
> interest in those protocols we should discuss what those defaults should be.


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

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

-- 
Prayank

A3B1 E430 2298 178F



Feb 13, 2022, 21:16 by michaelfolk...@protonmail.com:

> Hi Prayank
>
> > 1.Is Lightning Network and a few other layer 2 projects vulnerable to 
> > multiple RBF policies being used?
>
> Clearly the security of the Lightning Network and some other Layer 2 projects 
> are at least impacted or partly dependent on policy rules in a way that the 
> base blockchain/network isn't. As I (and others) have said on many occasions 
> ideally this wouldn't be the case but it is best we can do with current 
> designs. I (and others) take the view that this is not a reason to abandon 
> those designs in the absence of an alternative that offers a strictly 
> superior security model. Going back to a model where *all* activity is 
> onchain (or even in less trust minimized protocols than Lightning) doesn't 
> seem like the right approach to me.
>
> > 2.With recent discussion to change things in default RBF policy used by 
> > Core, will we have multiple versions using different policies? Are users 
> > and especially miners incentivized to use different versions and policies? 
> > Do they have freedom to use different RBF policy?
>
> Without making policy rules effective consensus rules users (including 
> miners) are free to run different policy rules. I think it is too early to 
> say what the final incentives will be to run the same or differing policies. 
> Research into Lightning security is still nascent and we have no idea whether 
> alternative Layer 2 projects will thrive and whether they will have the same 
> or conflicting security considerations to Lightning. 
>
> As you know the vast majority of the full nodes on the network currently run 
> Bitcoin Core. Whether that will change in future and whether this a good 
> thing or not is a whole other discussion. But the reality is that with such 
> strong dominance there is the option to set defaults that are widely used. I 
> think if certain defaults can bolster the security of Lightning (and possibly 
> other Layer 2 projects) at no cost to full node users with no interest in 
> those protocols we should discuss what those defaults should be.
>
> > 3.Are the recent improvements suggested for RBF policy only focused on 
> > Lightning Network and its security which will anyway remain same or become 
> > worse with multiple RBF policies?
>
> I think by nature of the Lightning Network being the most widely adopted 
> Layer 2 project most of the focus has been on Lightning security. But 
> contributors to other Layer 2 projects are free to flag and discuss security 
> considerations that aren't Lightning specific.
>
> > Note: Bitcoin Knots policy is fully configurable, even in the GUI - users 
> > can readily choose whatever policy *they* want.
>
> The maintainer(s) and contributors to Bitcoin Knots are free to determine 
> what default policy rules they want to implement (and make it easier for 
> users to change those defaults) in the absence of those policy rules being 
> made effective consensus rules. I suspect there 

[bitcoin-dev] Lightning and other layer 2 projects with multiple RBF policies

[Prayank via bitcoin-dev]

Hello World,

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

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

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

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

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

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

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

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

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

-- 
Prayank

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

Re: [bitcoin-dev] Improving RBF Policy

[Prayank via bitcoin-dev]

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

[bitcoin-dev] non-default ports for automatic connections in Bitcoin P2P network

[Prayank via bitcoin-dev]

## Using non-default ports for automatic connections in Bitcoin P2P network


ISPs can block default port 8333 used by Bitcoin nodes. One example:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-September/010798.html

While it would still be possible for crawlers and scanners to know about 
bitcoin nodes listening on non-default ports using other methods, it can be 
helpful in lot of countries that use basic things to block: domain, port etc.

In October 2021 a [pull request][1] was merged in Bitcoin Core in which lot of 
contributors
agreed to allow non default ports for automatic connections. It did not 
implement everything,
was limited to discussing the concept and allow AddrMan to support multiple 
ports per IP.

It was followed by another [pull request][2] in November 2021 which is still 
open and makes most
of the changes required for non-default ports to work with automatic 
connections.

I could not find any major issues with the changes however had some nits 
including a discussion on
mailing list which was even requested by a few other reviewers.


===Things that I found during my review, research and testing===

1.One user had posted about issues with default port 8333 on [bitcointalk][3] 
in July 2010. VMWare server
also used port 8333 so an option was requested to change port. This option was 
added in [May 2011][4] by Gavin Andresen. Gavin has discussed this option and 
related issues in detail with others on [bitcointalk][5].

2.I tried running signet for 1 hour v22.0 and 1 hour PR branch with debug=net. 
v22.0 had only 38333 port with different IPs in debug.log for connections. PR 
branch had 2 feeler connections with non-default ports 38331 and 13833.

Note: Default ports used in Bitcoin Core are 8333(mainnet), 18333(testnet), 
18444(regtest) and 38333(signet)

3.Wrote a [PowerShell script][6] and tested it on v22.0 and PR branch which 
bans all peers every 100 seconds using default port. It works as expected and I 
could see one peer using port 3111 on signet.

4.I am not sure about the 'bad ports' list in Bitcoin Core added in PR #23542


8333 in leet becomes 'beee' in plain text. Not sure if this was considered by 
Satoshi to hardcode 8333 for Bitcoin.


  [1]: https://github.com/bitcoin/bitcoin/pull/23306
  [2]: https://github.com/bitcoin/bitcoin/pull/23542
  [3]: https://bitcointalk.org/index.php?topic=322.0
  [4]: https://github.com/bitcoin/bitcoin/pull/221
  [5]: https://bitcointalk.org/index.php?topic=589.0
  [6]: 
https://github.com/prayank23/bitcoin-ps-scripts/blob/main/Scripts/Node/ban_default_peers.ps1

-- 
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] CTV BIP review

[Prayank via bitcoin-dev]

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

Re: [bitcoin-dev] On the regularity of soft forks

[Prayank via bitcoin-dev]

> We should strive to one day get to a point where the bitcoin consensus isn't 
> updating at all.

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

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

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

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

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

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

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

Michael Folkson also had some opinion in activation mechanism IIRC,


-- 
Prayank

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

Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt

[Prayank via bitcoin-dev]

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/

> I don't think CTV in its current form makes that case sufficiently, and the 
> technical details are lacking.
CTV cannot be compared to segwit or taproot. We are expecting different things 
in that case. CTV is trying to do add basic covenants in Bitcoin that would 
help all Bitcoin users. Most important thing missing in lot of conversations is 
the low demand for block space which affects everyone who understands 
importance of fees in long term. Right now fee rates only spike during peak 
bull markets which indicate the only use case is speculation and this can be 
improved if developers could do better things with Bitcoin smart contracts.

This would also ensure that we don't end up with something really contentious 
in future that changes supply.

> DoS Attacks

I think this was already answered by Jeremy and pull request to add related 
information is also merged:

https://github.com/bitcoin/bips/pull/1272


-- 
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] Bitcoin Legal Defense Fund

[Prayank via bitcoin-dev]

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

Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt

[Prayank via bitcoin-dev]

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

Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt

[Prayank via bitcoin-dev]

lized 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 
>  wrote:
>  
>
>>

Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt

[Prayank via bitcoin-dev]

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.christ...@gmail.com:

> Prayank via bitcoin-dev  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

Re: [bitcoin-dev] Nuke *notify options from Bitcoin Core

[Prayank via bitcoin-dev]

Hi Daniel,

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

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

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

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

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

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

-- 
Prayank

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

[bitcoin-dev] Nuke *notify options from Bitcoin Core

[Prayank via bitcoin-dev]

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

Re: [bitcoin-dev] [Bitcoin Advent Calendar] Derivatives and Options

[Prayank via bitcoin-dev]

Hi Jeremy,

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

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

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

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

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

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

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

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


-- 
Prayank

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

Re: [bitcoin-dev] [Bitcoin Advent Calendar] A Defense of Having Fun (and maybe staying poor)

[Prayank via bitcoin-dev]

Hi Jeremy,

> Eugene just dropped a project he’s been working on, and it’s really freakin’ 
> cool. He basically implemented a human v. chess engine in Solidity that mints 
> beautiful interactive NFTs of representations of the contract’s internal 
> states.

Not sure why NFT is involved here but experiment looks interesting. Maybe 
Eugene should try few things on Lightning as well: 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-December/019619.html

> Why isn’t Eugene working on Bitcoin?

There can be many reasons however Eugene can answer this question better.

> Working on Bitcoin is can be fun. But mostly it’s not. My post yesterday? 
> Theone describing new techniques to make Bitcoin more decentralized? I had a 
> lotof fun writing it. And then someone claimed that my work is “very 
> dangerous” toBitcoin.

I don't support what someone said about you in IRC however people do say crazy 
things online which has nothing to do with Bitcoin. Bitcoin can be different 
things for everyone.

> Bitcoin development has a bit of a burnout problem, with multiple 
> contributors stepping down their engagement recently. A likely cause is the 
> struggle it takes to ship even the smallest features, not to mention the 
> monumental effort it takes to ship a single large project.

I am not sure if this is the reason for people who will be less active in 
Bitcoin development now. And its a part of life, people will come and go. Show 
must go on. There will always be another developer who is more passionate and 
got more ideas to contribute. Funding in open source projects is an issue which 
exists outside Bitcoin as well and it is being addresses by several individuals 
and organizations.
> It’s hard to tell people, especially younger folk just entering the space, to 
> work on Bitcoin full-time. What I say is as follows:

It is hard but not impossible. I tried recently in a meetup in India. Ethereum 
is not the answer to all the problems in the worlds. If someone has issues with 
Bitcoin development, they can be solved.

> I don’t think I’m going to convince you here to care about NFTs. But I am 
> –hopefully – going to convince you to care about NFTs the phenomenon.

To be honest, its the trend right now and people care about it to get rich. 
There is nothing new or innovative about it. 

> For example, scaling challenge in Ethereum have led to the development of 
> Zero Knowledge Roll-Ups, privacy issues things like Tornado Cash, and more.

Rollups are memes and there are several articles, threads, research etc. to 
read about this. Most of their implementations are not even decentralized. 
Tornado Cash is not good privacy and even became worse after their governance 
token.


-- 
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] [Bitcoin Advent Calendar] Review of Smart Contract Concepts

[Prayank via bitcoin-dev]

Hi Jeremy,

> This post covers some high-level smart contract concepts that different
opcodes or proposals could have (or not).
https://rubin.io/bitcoin/2021/12/04/advent-7/

Interesting post. I love the concept of recursion in programming. There is one 
Indian movie called 'Karthik calling Karthik' which is one of the ways I 
remember this concept. 

> Recursive is pretty much just a fancy way of saying “loops”. This is 
> sometimesalso called “Turing Complete”.

Recently asked one dumb question on Stakexchange after reading a comment on 
reddit, maybe you can add anything new in this:

https://bitcoin.stackexchange.com/questions/111337/loops-in-bitcoin-scripting

> Here, the contract terminates after one canceled request by moving the 
> coinelsewhere.  It’s possible to emulate recursive behavior a limited amount 
> by“unrolling” a loop.

I think this is what I did in the above link where for loop was replaced with 
if-else statements.

> However, unrolling has it’s limits. When choices(action A or B) are 
> introduced, unrolling can be less effective since you haveand exponential 
> blowup (that means unrolling even like 32 steps might be toomany). However, 
> there are some tricks that can be employed by a clever andcareful programmer 
> to reduce this complexity through, for example, memoization.

Agree with limits and possibility of optimization.

> The key difference being that in the fully enumerated case we must know the 
> exact specifics of the contract and how it will execute, and in the open 
> ended contract case there are bits and pieces we can dynamically specify. If 
> Alice is paid 1 BTC by December 25th, 2021 Midnight, then transfer 100 
> tokensto one of Bob’s Address B1, B2, or B3 at Bob’s discretion.

Interesting

> Signing the transaction fee rate as a function of locktime

TIL


-- 
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] [Bitcoin Advent Calendar] What's Smart about Smart Contracts

[Prayank via bitcoin-dev]

Hi Jeremy,

> Here's the day 6 post: https://rubin.io/bitcoin/2021/12/03/advent-6/, the
topic is why smart contracts (in extended form) may be a critical precursor
to securing Bitcoin's future rather than something we should do after
making the base layer more robust.

There are few comparisons in this post and links that I consider misleading or 
incomplete. I had already tweeted this but such discussions are better archived 
here:

Difference between Bitcoin and Ethereum that is not mentioned on the website 
which should be considered while looking at fees: 1. Size of blocks added to 
chain everyday (600 MB) 2. Block limit (500 MB per 10 mins) 3. UTXO vs Account 
model 4. Failed transactions that pay fees (50k per day) 5. Will these fancy 
smart contracts work without nodes? No. Where are these nodes running? AWS and 
Infura has nice articles to highlight their importance 6. Who is paying the 
fees? Stablecoins, DEX, NFT platforms, CEX and VCs

There can be lot of other differences that affect the fee market including lot 
of users in Bitcoin obsessed with supply and hodling. Things that have changed 
in last few years: 1. Darknet markets using Monero 2. Stablecoins stopped using 
Omni and lot of alternatives exist right now 3. Most of the transactions are 
related to exchanges. They have started using their own tokens, less exchanges 
support layer 2 for Bitcoin and users are forced to withdraw some altcoin even 
if they need bitcoin. 4. Newbies are reading influencers like Elon Musk and 
happy with their doggy coins to get rich quick/rekt. 5. Bitcoin users or 
influencers declared DeFi a scam and even sidechains like Liquid, Rootstock do 
not qualify their purity tests. Projects like DLCs are still not used in any 
projects with good volume.


-- 
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] Rebroadcast mechanism in Bitcoin P2P network

[Prayank via bitcoin-dev]

Hi Aymeric,
> What I am proposing since years, not only to bitcoin, is to use the Tor
protocol independently of the Tor network, and from the browsers alsoacting as 
nodes (not to be misunderstood with the Tor Browser, this hasnothing to do) 
probably someone one day will understand it
I understand the concept and like it. However had some issues with use of 
JavaScript and WebRTC which were partially answered in 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-August/019373.html

I like that you don't give up, passionate about privacy, nodes and contributing 
to Bitcoin. Not sure if you have commits in Bitcoin Core repository which is 
one of the weird requirements to get free tickets for open source stage of 
https://b.tc/conference/

I think presenting your idea with some demo, talking to other developers in 
community IRL would help your project. If you agree and interested to 
participate, please apply here: https://b.tc/conference/open-source

I have already requested few people and recommend you to share things about 
your project in conference. Let me know if you need sponsors for flight tickets 
as well.

Happy Weekend!
-- 
Prayank

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

[bitcoin-dev] Rebroadcast mechanism in Bitcoin P2P network

[Prayank via bitcoin-dev]

Hello World,

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

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

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

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

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

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

-- 
Prayank

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

Re: [bitcoin-dev] Pawn (chess piece) | Breaking bitcoin by playing chess

[Prayank via bitcoin-dev]

Can you share the email address to get approval or permission for this type of 
bitcoin transactions? i.e. opening and closing of LN channels or OP_RETURN. I 
will keep that in Cc next time.

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

Thanks

-- 
Prayank

A3B1 E430 2298 178F



Dec 4, 2021, 15:30 by willt...@live.com.au:

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

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

[bitcoin-dev] Pawn (chess piece) | Breaking bitcoin by playing chess

[Prayank via bitcoin-dev]

Hello World,

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

Two related things that I found: 

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

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

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

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


-- 
Prayank

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

Re: [bitcoin-dev] A fee-bumping model

[Prayank via bitcoin-dev]

Good morning darosior,

Subject of the email looks interesting and I have few comments on the things 
shared:

> The part of Revault we are interested in for this study is the delegation 
> process, and more specifically the application of spending policies by 
> network monitors (watchtowers). Participants regularly exchange the Cancel 
> transaction signatures for each deposit, sharing the signatures with the 
> watchtowers they operate.Watchtowers can enforce spending policies (say, 
> can't Unvault outside of business hours) by having the Cancel transaction be 
> confirmed before the expiration of the timelock.

What are the privacy issues associated with such watchtowers?

> ## 4. We are still betting on future feerate
The problem is still missing one more constraint. "Ensuring confirmation at any 
time" involves ensuring confirmation at *any* feerate, which you *cannot* do.

Agree

> historical feerate: We currently use the maximum of the 95th percentiles over 
> 90-days windows over historical block chain
feerates.

Disagree that fee rates used in past should matter.

> Apart from judging that 500sat/vb is probably more reasonable than 
> 10sat/vbyte, this unfortunately sounds pretty much crystal-ball-driven.

Agree

> ## 7. Bumping and re-bumping
First of all, when to fee-bump? At fixed time intervals? At each block 
connection? It sounds like, given a large enough timelock, you could try to 
greed by "trying your luck" at a lower feerate and only re-bumping every N 
blocks. You would then start aggressively bumping at every block after M blocks 
have passed.

Agree

> You probably want to base your estimates on `estimatesmartfee`

Disagree. `estimatesmartfee` RPC has few issues: 
https://github.com/bitcoin/bitcoin/pull/22722#issuecomment-901907447

> ## 9. Insurances
there is definitely room for an insurance market.

Agree. I think its possible using discreet log contracts with some trust 
assumptions and use of multi oracles.

I had one idea about creating insurance project for LGBTQ community in India as 
they don't have enough options like others. Have shared the details here: 
https://gist.github.com/prayank23/f30ab1ab68bffe6bcb2ceacec599cd36 
As final point, I guess you already know about this presentation by Jack 
Mallers in which he has described how we could create derivatives for users to 
hedge fees: https://youtu.be/rBCG0btUlTw

-- 
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] Trying to patch Core ZMQ "rawtx" topic to only publish unconfirmed transactions: How?

[Prayank via bitcoin-dev]

Hi Ali,

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

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

Run bitcoind

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

You will see results like this: 
https://i.imgur.com/xKzFJbl.png
https://i.imgur.com/gpsTTHZ.png

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

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

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

-- 
Prayank

A3B1 E430 2298 178F
___
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,

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

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

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

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

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

f40bcb13dbcbf7b6245becb75586c22798ed7360cd9853572152ddf07a39

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

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

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

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


-- 
Prayank

A3B1 E430 2298 178F



Oct 4, 2021, 09:29 by zmnsc...@protonmail.com:

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

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

Re: [bitcoin-dev] bitcoin.org missing bitcoin core version 22.0

[Prayank via bitcoin-dev]

Hi Yanmaani,

> Unfortunately, this isn't really possible. If they did that, you could get 
> consensus splits. This is why all the other stuff is so important - if 
> Bitcoin is subverted via soft-fork, you *can't* just run your own fork.

I am aware of this problem however looking for solutions or workarounds. Is it 
possible to have one library for things related to consensus which is used by 
all full node implementations? There are lot of other things in any full node 
implementation apart from consensus related code.

> This is all about the money - it's easy to have people be independent when 
> their source of money is independent. But nobody's crazy enough to bite the 
> hand that feeds them, and you couldn't really build a system on that basis. 
> Our best hope is gentle hands, or contributors wealthy enough not to have to 
> care.

Sorry neither I agree with this nor its "all about money" for me. I am assuming 
there are few others as well with similar thoughts.

I had shared few reasons why someone might contribute to Bitcoin Core: 
https://bitcoin.stackexchange.com/a/108017/

> Isn't Bitcoin already plenty distributed? Funding people in under-represented 
> countries seems to me like a textbook exercise in 'box-ticking, but moreover, 
> I'd frankly rather have reasonably well-off guys from Western Europe/America 
> who have the financial backbone to not worry that much about attacks to their 
> funding, than mercenaries who have to follow orders or get fired. Even if 
> they're from West Uzbekistan.

Sorry I don't agree with this approach. Its not about 'box-ticking' textbook 
exercise but to make the attacks more difficult by any governments or people 
with malicious intent. Few years back when I was in college and Tor wasn't as 
famous as it is now, we used normal socks proxies for pentesting. My mentor 
Godzilla had suggested us to use IP of different countries not because it is 
some textbook exercise but it helps when someone tries to trace your requests. 
Similarly, if we have people from different countries in different full node 
implementations as maintainers it will be difficult for people to try crazy 
things.

> See above. Bitcoin Knots isn't really independent.

I understand there are other implementations like btcd, bcoin, gocoin, 
libbitcoin, bitcore etc. and Knots is a derivative of Core. However there are 
lot of differences and it changes your experience as a user while running node 
and using it for different things. I have mentioned few things in the medium 
post shared in last email.

> You could also look into a system like Monero's CCS.

Yes I like it and suggested once in bitcoin.org repository even though it can 
be done by anyone as there is no official website for Bitcoin: 
https://github.com/bitcoin-dot-org/Bitcoin.org/issues/3545


-- 
Prayank

A3B1 E430 2298 178F



Nov 5, 2021, 20:15 by yanma...@cock.li:

> On 2021-11-05 08:17, Prayank via bitcoin-dev wrote:
>
>> 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.
>>
>
> Unfortunately, this isn't really possible. If they did that, you could get 
> consensus splits. This is why all the other stuff is so important - if 
> Bitcoin is subverted via soft-fork, you *can't* just run your own fork.
>
> Theoretically, I suppose you could run two implementations and do something 
> if they differ, but what?
> 1. Bitcoin Core and  both say block is valid -> valid
> 2. Bitcoin Core and  both say block is invalid -> invalid
> 3. Bitcoin Core says valid,  says invalid -> valid (or get forked 
> off)
> 4. Bitcoin Core says invalid,  says valid -> invalid (or hardfork)
>
>> 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,
>>
>
> This is all about the money - it's easy to have people be independent when 
> their source of money is independent. But nobody's crazy enough to bite the 
> hand that feeds them, and you couldn't really build a system on that basis. 
> Our best hope is gentle hands, or contributors wealthy enough not to have to 
> care.
>
> (Whatever happened to Amir Taaki, by the way?)
>
>> 3.More people from different countries getting involved in important
>> roles.
>>
>
> Isn't Bitcoin already plenty distributed? Funding people in under-represented 
> countries seems to me like a 

Re: [bitcoin-dev] bitcoin.org missing bitcoin core version 22.0

[Prayank via bitcoin-dev]

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.sala...@gmail.com:

> Hi Owen,
>
> On Wed, Oct 20, 2021 at 9:25 PM Owen Gunden via bitcoin-dev <> 
> bitcoin-dev@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@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

Re: [bitcoin-dev] bitcoin.org missing bitcoin core version 22.0

[Prayank via bitcoin-dev]

Hi Owen,

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

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

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

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

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

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

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

-- 
Prayank

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

Re: [bitcoin-dev] Taproot testnet wallet

[Prayank via bitcoin-dev]

Hi Andreas,

> I'm trying to finish off bitcoinj's implementation for sending to 
taproot addresses. For this, I'd like to test against a wallet that can
receive to P2TR and spend back.

I did this transaction few days back which creates a P2TR output while 
answering a question on Bitcoin Stackexchange: 
https://blockstream.info/testnet/tx/2035ead4a9d0c8e2da1184924abc9034d26f2a7093371183ef12891623b235d1

Pieter Wuille and Anthony Towns already shared things that would be helpful. 
Still wanted to share the steps I did for above transaction:

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

TL;DR - 

1.Create a blank descriptor wallet with private keys disabled

2.Import TPUB descriptor in wallet

3.Create new bech32m address

4.Send some bitcoin from another wallet

The answer could be improved if test vectors are added in BIP 86 for TPRV for 
follow things suggested by Anthony Towns in last email.

-- 
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] On the regularity of soft forks

[Prayank via bitcoin-dev]

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

Re: [bitcoin-dev] Wednesday’s second BIP process meeting

[Prayank via bitcoin-dev]

Good morning Michael,

Thanks for sharing the summary about BIP process meeting. 

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

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

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

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


-- 
Prayank

A3B1 E430 2298 178F
___
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]

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

___
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

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

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

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

[Prayank via bitcoin-dev]

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

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

[Prayank via bitcoin-dev]

Good morning Bitcoin devs,

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

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

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

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

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

-- 
Prayank

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

Re: [bitcoin-dev] Reminder on the Purpose of BIPs

[Prayank via bitcoin-dev]

> I like the idea of decentralizing the BIPs process. It is a historical 
> artifact that the bips repository is part of the same organization that 
> bitcoin core is part of. But there shouldn't be the perception that 
> standardization is driven by that, or that there is any kind of (non-trivial) 
> gatekeeping.

I had suggested few changes in BIP process and repository yesterday. Meeting 
was disappointing because of few reasons: 

1.Its been 12 years since Bitcoin came in to existence and I am surprised that 
during such important conversations I still see only 4 people out of which 2 
are maintainers.

2.None of the people who participated in meeting agree that we need to create 
multiple BIP directories and let people decide what works best for them. Reduce 
dependency on one repository or few people. At the end of the day these are 
just proposals, implementations are more important and there are so many ways 
to document things online, archive etc.

Playing ACK/NACK game in 'bitcoin/bips' repository will be a waste of time so I 
created this as an example:

https://github.com/prayank23/bips/blob/master/README.md

https://prayank23.github.io/bips/

I respect everyone involved in Bitcoin development however neither I trust 
anyone nor I expect anyone to trust me. Bitcoin is not just another open source 
software. Its a protocol for decentralized network which can be used to settle 
payments. We are trying to redefine MONEY, many cypherpunks, activists, 
hacktivists, privacy advocates etc. are involved and trying to separate money 
from state. The same money that is needed for almost everything you do in this 
world from birth to death, love to war and same money that makes some people 
more powerful. So, I won't be surprised with anything in future and will be 
prepared for everything.

-- 
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] BIP process meeting - Tuesday September 14th 23:00 UTC on #bitcoin-dev Libera IRC

[Prayank via bitcoin-dev]

> A mailing list post is static and a BIP will go normally go through multiple 
> edits and revisions so you do need to take advantage of the Git version 
> control system. It gets quite unwieldy to attempt to do that via a mailing 
> list with every minor suggested edit getting sent to all subscribers.

 Mailing list post will have the link to BIP documentation. Post itself doesn't 
need to be updated but same link can be used to share updated information. 
Example: https://gist.github.com/prayank23/95b4804777fefd015d7cc4f847675d7f 
(Image can be changed in gist when required or add new information)
Mailing list post will help in reading discussions related to proposal.

>Also allowing the entire global population
(billions of people) to be able to create a directory doesn't sound
like a good idea to me :)

There is nothing to allow/disallow. That's the whole point. People are free to 
save links and organize things which can be called a BIP directory.

> I can only speak for myself here but I am not particularly concerned about 
> this perception of authority. 

This perception affects Bitcoin. 

> In the same way as there are limits on the ability of Core maintainers to 
> unilaterally merge in contentious code changes there are similar limits on 
> the ability of BIP editors. Ultimately anyone merging a PR has to consider 
> process/consensus and concerns can (and have been in the past) be raised on 
> this mailing list or elsewhere.

Bitcoin Core is an implementation (used by most of the nodes right now). BIPs 
are proposals for Bitcoin. Using same organization on GitHub and such 
comparisons can be misleading for many. I don't think we need ACKs/NACKs in 
BIPs repository and I feel weird to be a part of discussions, ACKing this pull 
request: https://github.com/bitcoin/bips/pull/1104. Not sure any Bitcoin 
project needs a pull request merged in this repository to implement a proposal.

> I'm not sure where you are suggesting a bot should be.

A bot similar to DrahtBot in Bitcoin Core repository. 
Few other developers had suggested similar thing earlier:

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018859.html

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018868.html

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018869.html

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018871.html

-- 
Prayank

A3B1 E430 2298 178F



Sep 14, 2021, 19:37 by michaelfolk...@gmail.com:

> Hey Prayank
>
> Thanks for the suggestions.
>
>> bitcoin-dev mailing list link can be considered a BIP and saved in a BIP 
>> directory. Anyone can create such directories. So BIP is nothing but a 
>> proposal shared on bitcoin-dev mailing list.
>>
>
> A mailing list post is static and a BIP will go normally go through
> multiple edits and revisions so you do need to take advantage of the
> Git version control system. It gets quite unwieldy to attempt to do
> that via a mailing list with every minor suggested edit getting sent
> to all subscribers. Also allowing the entire global population
> (billions of people) to be able to create a directory doesn't sound
> like a good idea to me :)
>
>> This will avoid the 'bitcoin/bips' repository being considered as some BIP 
>> authority that approves BIPs and proposals can improve Bitcoin without using 
>> the repository. Repository will only be helpful in documenting BIP correctly.
>>
>
> I can only speak for myself here but I am not particularly concerned
> about this perception of authority. We need a central repo that we can
> all refer to (rather than BIPs being distributed across a large number
> of repos) and that central repo needs to managed and maintained by
> somebody (in this case the two BIP editors Kalle and Luke). In the
> same way as there are limits on the ability of Core maintainers to
> unilaterally merge in contentious code changes there are similar
> limits on the ability of BIP editors. Ultimately anyone merging a PR
> has to consider process/consensus and concerns can (and have been in
> the past) be raised on this mailing list or elsewhere.
>
>> 2. Bot in `bitcoin/bips` repository that notifies about pull requests based 
>> on different things. This will help maintainer(s) and contributors.
>>
>
> I'm not sure where you are suggesting a bot should be. On IRC? There
> is a BIP merges bot on Mastodon[0] that I'm aware of and obviously you
> can subscribe to GitHub repo notification emails.
>
>> 3. BIP Gallery: I tried sharing things in a different way so that newbies 
>> can understand importance of BIPs in Bitcoin and relate to it: 
>> https://prayank23.github.io/BIPsGallery/ however couldn't complete it with 
>> all the BIPs because not many people considered it helpful. There were few 
>> suggestions to improve it by adding some text for each BIP and better image 
>> gallery. Maybe someone else can create a better project.
>>
>
> This looks cool. I think we can definitely do better 

Re: [bitcoin-dev] BIP process meeting - Tuesday September 14th 23:00 UTC on #bitcoin-dev Libera IRC

[Prayank via bitcoin-dev]

Hi Michael,

Thanks for sharing the details about the meeting.

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

1.BIP process: 

A. Plan and document a proposal

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

 C. BIP is assigned a number and merged

 D. Share the proposal on bitcoin dev mailing list

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

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

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

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


-- 
Prayank

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

Re: [bitcoin-dev] Braidpool: Proposal for a decentralised mining pool

[Prayank via bitcoin-dev]

> How would you compare this to Stratum v2?

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

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

I think Braidpool does this in a better way.


-- 
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] Drivechain: BIP 300 and 301

[Prayank via bitcoin-dev]

> of course stacks can do this even without drivechain, so not sure whatwe're 
> hiding from there

Stacks is not a Bitcoin sidechain IMO. It has its own native token which isn't 
pegged to BTC. Premined.  It uses Bitcoin as a storage and broadcast medium for 
recording all blocks. Marketing with lot of misinformation. None of these 
things really help Bitcoin.

-- 
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] Drivechain: BIP 300 and 301

[Prayank via bitcoin-dev]

Good morning ZmnSCPxj,

Thanks for sharing all the details. One thing that I am not sure about:

> * We already ***know*** that blockchains cannot scale
> * Your plan for scaling is to make ***more*** blockchains?

Scaling Bitcoin can be different from scaling Bitcoin sidechains. You can 
experiment with lot of things on sidechains to scale which isn't true for 
Bitcoin. Most important thing is requirements for running a node differ. Its 
easy to run a node for LN, Liquid and Rootstock right now. Will it remain the 
same? I am not sure.

LND: https://github.com/lightningnetwork/lnd/blob/master/docs/INSTALL.md

Liquid: 
https://help.blockstream.com/hc/en-us/articles/92026026-How-do-I-set-up-a-Liquid-node-

Rootstock: https://developers.rsk.co/rsk/node/install/

> More to the point: what are sidechains **for**?

Smart contracts are possible on Bitcoin but with limited functionality so lot 
of applications are not possible using Bitcoin (Layer1). Some of these don't 
even make sense on Layer 1 and create other issues like MEV however deploying 
them on sidechains should not affect base layer.

> Increasing the Drivechain security parameter leads to slower 
>sidechain->mainchin withdrawals, effectively a bottleneck on how much can be 
>transferred sidechain->mainchain.

I think 'withdrawals' is the part which can be improved in Drivechain. Not sure 
about any solution at this point or trade-offs involved but making few changes 
can help Drivechain and Bitcoin.
I agree with everything else you explained and emails like these will be 
helpful for everyone trying to understand what's going on with Layer 2 on 
Bitcoin.

-- 
Prayank

A3B1 E430 2298 178F



Sep 3, 2021, 02:32 by zmnsc...@protonmail.com:

> Good morning Prayank,
>
> Just to be clear, neither Liquid nor RSK, as of my current knowledge, are 
> Drivechain systems.
>
> Instead, they are both federated sidechains.
> The money owned by a federated sidechain is, as far s the Bitcoin blockchain 
> is concerned, really owned by the federation that.runs the sidechain.
>
> Basically, a mainchain->sidechain transfer is done by paying to a federation 
> k-of-n address and a coordination signal of some kind (details depending on 
> federated sidechain) to create the equivalent coins on the sidechain.
> A sidechain->mainchain transfer is done by requesting some coins on the 
> sidechain to be destroyed, and then the federation will send some of its 
> mainchain k-of-n coins into whatever address you indicate you want to use on 
> the mainchain.
>
> In theory, a sufficient quorum of the federation can decide to ignore the 
> sidechain data entirely and spend the mainchain money arbitrarily, and the 
> mainchain layer will allow this (being completely ignorant of he sidechain).
>
> In such federated sidechains, the federation is often a fixed predetermined 
> signing set, and changes to that federation are expected to be rare.
>
> Federated sidechains are ultimately custodial; as noted above, the federation 
> could in theory abscond with the funds completely, and the mainchain would 
> not care if the sidechain federation executes its final exit strategy and you 
> lose your funds.
> One can consider federated sidechains to be a custodian with multiple 
> personality disorder, that happens to use a blockchain to keep its individual 
> sub-personalities coordinated with each other, but ultimately control of the 
> money is contingent on the custodian following the dictates of the supposed 
> owners of the coin.
> From a certain point of view, it is actually immaterial that there is a 
> separate blockchain called the "sidechain" --- it is simply that a blockchain 
> is used to coordinate the custodians of the coin, but in principle any other 
> coordination mechanism can be used between them, including a plain database.
>
>
> With Drivechains, custody of the sidechain funds is held by mainchain miners.
> Again, this is still a custodial setup.
> A potential issue here is that the mainchain miners cannot be identified (the 
> entire point is anonymity of miners is possible), which may be of concern.
>
> In particular, note that solely on mainchain, all that miners determine is 
> the *ordering* and *timing* of transactions.
> Let us suppose that there is a major 51% attack attempt on the Bitcoin 
> blockchain.
> We expect that such an attack will be temporary --- individuals currently not 
> mining may find that their HODLings are under threat of the 51% attack, and 
> may find it more economic to run miners at a loss, in order to protect their 
> stacks rather than lose it.
> Thus, we expect that a 51% attack will be temporary, as other miners will 
> arise inevitably to take back control of transaction processing.
> https://github.com/libbitcoin/libbitcoin-system/wiki/Threat-Level-Paradox
>
> In particular, on the mainchain, 51% miners cannot reverse deep history.
> If you have coins you have not moved since 2017, for example, the 51% attack 
> is expected to 

[bitcoin-dev] Drivechain: BIP 300 and 301

[Prayank via bitcoin-dev]

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

[bitcoin-dev] Using transaction version number in different projects

[Prayank via bitcoin-dev]

print('Hello, world!')

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

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

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

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


-- 
Prayank

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

Re: [bitcoin-dev] Camouflage: A project dedicated to Hal Finney

[Prayank via bitcoin-dev]

Hi Aymeric,

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

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

A3B1 E430 2298 178F



Aug 28, 2021, 22:06 by ayme...@peersm.com:

>
> Probably you could add to your links this discussion/issue > 
> https://github.com/bitcoin/bitcoin/pull/18988#issuecomment-646564853
>
>
> Le 27/08/2021 à 23:29, Prayank via  bitcoin-dev a écrit :
>
>> I wish Hal Finney was with us today and help us improveprivacy in 
>> Bitcoin. I like reading his posts and one of them is >> 
>> https://bitcointalk.org/index.php?topic=156390.msg1659654#msg1659654>>  
>>
>> I had emailed about Privacy related things on July23: >> 
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019276.html
>>
>> It was my birthday on 23 and had few beers somaybe email wasn't very 
>> focused. Although basic idea was toinitiate discussion about 
>> improving privacy in different Bitcoinprojects. I did not receive 
>> any response except one person wholiked the video I mentioned in the 
>> email. So here is one projectwhich uses GitHub pages and will have 
>> the following things:
>>
>> 1.Issues and PRs related to privacy from differentBitcoin projects. 
>> I have added few from Bitcoin Core (full nodeimplementation), 
>> Bisq(DEX) and LND (LN implementation) rightnow.
>> 2.Blog section for my opinion on different privacyrelated issues and 
>> PRs.
>> 3.'Hall of Fame' section to appreciate thecontribution of devs who 
>> are improving privacy in differentBitcoin projects.
>>
>> I will be happy if this project helps in improvingprivacy or helps 
>> users/devs in any other way. This project willnever turn in to a 
>> paid newsletter or needs any sponsors,however any contribution to 
>> make the website better would beappreciated. Edward Snowden can also 
>> contribute if he wants todo more than just tweets to help improve 
>> Bitcoin privacy.
>>
>> Link: >> https://prayank23.github.io/camouflage/
>>
>> Will move everything to new repository thisweekend: >> 
>> https://github.com/BlockchainCommons/Bitcoin-Camouflage
>>
>> -- 
>> Prayank
>>
>> A3B1 E430 2298 178F
>>
>>
>> ___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] Camouflage: A project dedicated to Hal Finney

[Prayank via bitcoin-dev]

I wish Hal Finney was with us today and help us improve privacy in Bitcoin. I 
like reading his posts and one of them is 
https://bitcointalk.org/index.php?topic=156390.msg1659654#msg1659654 

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

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

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

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

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

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

-- 
Prayank

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

Re: [bitcoin-dev] Announcing bip174.org, a web-based PSBT viewer and editor

[Prayank via bitcoin-dev]

Hi Alekos,

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

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

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

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

[bitcoin-dev] bitcoin-ps | Desktop application to test Bitcoin Core using PowerShell scripts

[Prayank via bitcoin-dev]

Hello World,

I was working on an intern project in last few weeks which is almost ready for 
first release. Will be helpful if devs working on Bitcoin Core and .NET 
projects related to Bitcoin can share feedback. Pieter Wuille and Luke Dashjr 
had already shared few things before I started working on this project which 
wasn't really positive considering the use of .NET and PowerShell in this 
project. I respect their opinion and agree we could make better applications 
however I have tried my best to express the goal I am trying to achieve with 
this project below.

Project repository: https://github.com/prayank23/bitcoin-ps

Other details about related milestones: 
https://github.com/BlockchainCommons/Community/discussions/51

Project is inspired by Burp Suite and I want to create a similar application 
which is only used to test privacy and security of Bitcoin Core RPC using GUI. 
I used WPF instead of Avalonia right now to save time. I will use it in future 
to make bitcoin-ps cross platform, most of the code will remain same and I have 
shared a proof of concept in milestones link above in which application works 
fine on Ubuntu with no pwsh installed. Hopefully this issue will also be 
resolved soon: https://github.com/AvaloniaUI/Avalonia/issues/4361

Default scripts:

1.CPU_RAM_sendtoaddress.ps1 : Check CPU and RAM usage while using some wallet 
RPCs multiple times. Results for Ubuntu and Windows were interesting. For some 
reason it almost used 100% CPU in Ubuntu.

2.onlynet_i2p.ps1 : Outbound connections are made to onion peers while 
onlynet=i2p is used without any proxy

3.lock_unspent.ps1 : Check if locked UTXOs are unlocked on restart

4.custom_change_rbf.ps1: Compares the inputs for Tx1 and Tx2 where Tx1 is RBF 
transaction with 1 input, 2 ouputs (custom change address with label), Tx2 is 
replacement transaction

Why PowerShell?

1.I have worked on 2 similar projects in past: A basic application for Office 
365 admins and support engineers and One project related to Infosec.
2.Testing using different languages locally doesn't impact Bitcoin Core or 
require any changes.
3.Easier to write and devs who use PowerShell scripts in their projects could 
relate to it, find interesting and maybe start contributing to Bitcoin Core.
4.It can be done using bash or maybe python scripts as well. For me using 
PowerShell in this project is like meeting a college friend and exploring new 
places.
5.PowerShell Core is open source and works on Linux, Mac etc.

Last but not least, I would like to thank Christopher, Vinay, guests in 
meetings, other interns and everyone involved in Blockchain Commons. I have 
learnt lot of new things during internship. Would suggest everyone to start 
with 'Learning Bitcoin from the Command Line' if they have recently started 
reading about Bitcoin. I wish I could do more projects, will work on DEX and 
OfflineTx even after internship ends to complete by end of this year.
-- 
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] Removing the Dust Limit

[Prayank via bitcoin-dev]

> As feerates have gone up over time, and as we expect them to go up further, 
>we should be considering drastically increasing the 3 sat/vByte basis to 
>something more like 20 sat/vB.

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

Fees per MB since 2016: https://i.imgur.com/XEkkf99.png 

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

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

-- 
Prayank
 
A3B1 E430 2298 178F

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

[bitcoin-dev] Bitcoin Privacy Week/Month

[Prayank via bitcoin-dev]

Hello World,

What?

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

Why?

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

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

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

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

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

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

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

Re: [bitcoin-dev] Trinary Version Signaling for softfork

[Prayank via bitcoin-dev]

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

Re: [bitcoin-dev] Trinary Version Signaling for softfork

[Prayank via bitcoin-dev]

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

[bitcoin-dev] Wallet fingerprinting and other privacy issues in Bitcoin Core

[Prayank via bitcoin-dev]

Hello World,

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

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

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

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

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

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

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

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

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

Re: [bitcoin-dev] Fee estimates and RBF

[Prayank via bitcoin-dev]

I have shared response by Jeremy and ZmnSCPxj in an answer to 
https://bitcoin.stackexchange.com/questions/105860/what-are-we-trying-to-predict-in-fee-estimation-and-why

Also find the recent CVE related to RBF by Antoine Riard and implementation of 
RBF in Bitcoin Core compared to btcd interesting. Even though I am not sure why 
inherited signalling is not implemented in Bitcoin Core.
RBF, CPFP and their combinations are something that is less explored IMO. For 
example: I had discussed one usecase of CPFP with Harding in IRC once in which 
a project uses maker-taker model. Maker broadcasts transaction with 1 sat/vByte 
and taker has to confirm this transaction by creating a child transaction with 
an effective fee rate according to mempool stats. Basically, the idea of 
receiver paying for the transaction instead of sender. But it will involve lot 
of exception handling.
-- 
Prayank___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Prediction Markets and Bitcoin

[Prayank via bitcoin-dev]

Good morning ZmnSCPxj,

This will be a long email because I want to cover all the things and difficult 
to express them in few sentences or respond to the tweets about use of futures 
markets in Bitcoin.

TL;DR: Prediction markets or futures markets can be helpful in collecting more 
information and hedging however, if used incorrectly can become a reason for 
failure of Bitcoin.

===

> Of course development must be free to do what is best technically, and to 
>experiment and see what other techniques are possible or workable. Thus the 
>market must follow development.

Agree.

> Of course the people ultimately funding the development must impose what 
>direction that development goes to, after all, it is their money that is being 
>modified. Thus development must follow the market.

Disagree. 

1.A position in a futures market about possible outcomes of an event is not 
equivalent to funding Bitcoin development.

2.People or organizations funding Bitcoin developers or projects can always 
have some opinion, influence and disagreements. They can never impose or force 
something at least in Bitcoin protocol.

> what is unclear is what the market wants, thus I think prediction markets are 
> something that are needed in order for the negotiation

Partially agree. Yes, its not clear what the market wants and sometimes its 
unclear even after expiry of futures contract because two people can look at 
the same data and share different analysis. Prediction markets are not needed 
for negotiation but can be helpful sometimes.

===

3 things I mentioned in TL;DR: Hedging, Collecting information and Incorrect 
usage

1.Hedging:
Futures market can be useful in hedging few things in Bitcoin. Jack Mallers had 
shared the idea of using futures markets for 'fees' in Lightning Conference: 
https://www.youtube.com/watch?v=rBCG0btUlTw

Summary of the presentation(Hedging the chain): Derivatives contracts are used 
to hedge financial exposure.  Projects and businesses that use bitcoin 
transactions regularly prefer paying less transaction fees. Miners revenue 
increases if transaction fees goes up and subsidy is reduced after every 
210,000 blocks so miners prefer high transaction fees or more fees per block.

Examples:

A)Zap expects $1000/month on-chain operating costs. Longs(1x) on-chain fee 
futures. If bitcoin transaction fees for the month costs more than $1000, the 
loss will be covered with profits from long position. If long position is in 
loss because fees are low, it will be covered by paying less than $1000 for the 
month in transaction fees.

Miner expects $1000/month on-chain fee profits. Shorts(1x) on-chain fee 
futures. If short position is in loss because fees go up, loss will be covered 
with more profits from mining. If profits are less from mining because fees was 
low, loss will be covered with profits in short position,

B)Hashrate Derivatives: https://onthebrink-podcast.com/tim-kelly-bitooda/

C)Consider there is a futures contract for Taproot soft fork. Alice has done 
enough research and thinks Taproot will be activated. She opens a long 
position. Bob thinks miners signaling will not reach the required threshold, so 
Taproot will not be activated with MASF. Bob opens a short position. Carol is 
working on a project that will work better with taproot activated. She is not 
interested in speculating but wants to hedge the financial exposure. Carol 
expects her project will receive $1 funding and make $1000 profits per 
month. She opens a short position (1x) which will cover the loss incase taproot 
is not activated. If taproot is not activated, UASF can take another year which 
will delay her funding and profits but she can cover this loss with the profits 
from short position. This futures contract will expire on 2021-08-11 00:00 UTC 
and settlement is based on multiple oracles that broadcast results for 
`getblockchaininfo` regularly for their nodes. Start date can be before or 
after signaling. Trade-offs: If the futures contract starts before signaling, 
miners are likely to follow the market (not necessary). If the futures contract 
starts after a week of signaling, traders can use this information while 
opening a position. In this example, futures contract starts from 2021-05-01 
00:00 UTC.

Similarly if we improve privacy in Bitcoin with a soft fork that includes 
confidential transactions, Chainalysis can use such futures contract to open a 
long position because it affects their business. If CT-SF is activated, they 
can cover some loss with the profits from long position. 

2.Collecting more information:
a - Bitcoin Dev Mailing List
b - Different PRs: GitHub repository for Bitcoin Core and other implementations
c - IRC channels
d - Bitcoin Stackexchange (If not sure about some technical things involved in 
a soft fork)
e - Reddit posts
f - Twitter (Not the best 

Re: [bitcoin-dev] Opinion on proof of stake in future

[Prayank via bitcoin-dev]

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

Re: [bitcoin-dev] Fee estimates and RBF

[Prayank via bitcoin-dev]

Good morning ZmnSCPxj,

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

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

May 3, 2021, 09:32 by zmnsc...@protonmail.com:

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

Re: [bitcoin-dev] Fee estimates and RBF

[Prayank via bitcoin-dev]

Thanks Jeremy for sharing this link: 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html

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

May 1, 2021, 05:41 by jlru...@mit.edu:

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

[Prayank via bitcoin-dev]

Hello World, 

I hope everyone is doing okay. Things are not good in India and even I was 
tested covid positive few days back. Recovered and feeling better now. Hoping 
everything gets back to normal soon.

There are different estimations used in wallets, explorers and other Bitcoin 
projects. For example: `estimatesmartfee` in Bitcoin Core (One of the 
implementation for Bitcoin which is used more but not official as there is 
nothing official in Bitcoin).  Are different estimations misleading and affect 
the way fees are used in Bitcoin transactions? Will it be better if we just 
share mempool stats and user can decide the fee rate accordingly?

If I compare this with BTCUSD orderbook on any exchange, are we trying to 
estimate at what price buy order will get filled in certain time? Does that 
make sense?

Mempool Stats: https://i.imgur.com/r4XKk2p.png
BTCUSD Orderbook: https://i.imgur.com/ylGVHJB.png

I consider it misleading because lot of users think a transaction with fee rate 
1-5 sat/vByte will be included in 1 week or maybe a transaction with X 
sat/VByte will be included in Y time which is not true. Users can decide the 
fee rate and can do bidding, transaction will be included based on demand, 
supply and miners.

Will it be better if the wallets used this approach?
1.Show mempool stats
2.Leave the fee rate for user to decide
3.RBF every transaction and follow different algorithms for automated bidding

A basic algorithm for automated bidding can be: 
https://i.stack.imgur.com/1SlPv.png

Such RBF algos can be helpful for users when Bitcoin wallets are open in 
background. Maybe it will work better for mobile wallets in which you can see a 
notification every time transaction is replaced with a new fee rate 
automatically.

I wanted to know what others think about this approach of creating and using 
different RBF algos instead of predicting something that is difficult or 
doesn't make sense. Also if there was a way we could achieve this even if the 
user goes offline. For example: Alice broadcasts Tx1 with 1 sat/vByte, its 
replaced with Tx2 (2 sat/vByte) after 2 blocks because Tx1 was not confirmed. 
Alice decides to shut down her system or switch off mobile or mobile data. Tx2 
is still not confirmed after another 2 blocks but it has some information as 
one OP_RETURN output which is used by Bitcoin nodes that see this transaction 
in the mempool. Bob's node use this information to replace the transaction with 
Tx3 and use fee rate 3 sat/vByte.

--
Prayank

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

Re: [bitcoin-dev] Block weight penalty for UTXO set growth

[Prayank via bitcoin-dev]

Hello Yanmaani,

Incentives for UTXO consolidation already exists IMO.

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

In few cases it affects privacy though like post coinjoin.

TBH I couldn't understand everything you mentioned including the part in which 
fees decrease is mentioned because of smaller block. Fees should increase if 
such blocks are regularly mined and are predictable IMO. Not sure if everyone 
will agree to the other things mentioned in the proposal.
-- 
Prayank___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIPs - notarization protocol and decentralized storage

[Prayank via bitcoin-dev]

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

[bitcoin-dev] Prediction Markets and Bitcoin

[Prayank via bitcoin-dev]

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

Re: [bitcoin-dev] Taproot activation meeting on IRC - Tuesday 16th March 19:00 UTC

[Prayank via bitcoin-dev]

> back in the day we also had people that thought 10 min avg block time is too 
> much.

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

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

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

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

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

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

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

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

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

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

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


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

Re: [bitcoin-dev] Taproot activation meeting on IRC - Tuesday 16th March 19:00 UTC

[Prayank via bitcoin-dev]

> the last thing we need is
a rushed upgrade

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Agree

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

Everyone should be welcome to participate in meetings, ask questions, learn 
more and contribute. I don't see anything wrong with it.
-- 
Prayank___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Mining Pools in Bitcoin and their involvement in Bitcoin development

[Prayank via bitcoin-dev]

Hello World,

Lets start with facts instead of opinion. Mining pool distribution in last 24 
hours:

Binance - 16%
F2Pool - 15%
Huobi - 11%
AntPool - 10%
ViaBTC - 10%
Poolin - 9%
BTC.com - 8%

This is 80% and things are not really different even if look at last 2 weeks. 
Most of the pools have been reusing address for coinbase transaction and 
sharing name in coinbase text. 

Their opinion on "Taproot": https://taprootactivation.com/

I won't comment on the origin of these mining pools or history. Maybe things 
will improve with Stratum v2, lets look at miners but its difficult to know the 
exact location of miners considering no such details in protocol and people can 
use Tor, VPN, proxy etc. Mining pools can be non-KYC or have their own 
understanding with miners. Few countries increased their involvement in Bitcoin 
mining recently and governments:

Russia
Iran
Venezuela
Pakistan

China, US and few others are already involved from  years. Maybe others that we 
don't know and were not highlighted in mainstream media. What are the risks and 
rewards involved in bitcoin mining:

Rewards:

 Block reward (6.25 BTC right now) + transaction fees
Freedom to include transactions (can censor few transactions if they want)
Involved in signaling for soft forks (Bitcoin Development)

Risks:

BTCUSD (Can be hedged)
Hashrate and Difficulty (Can be hedged)

What are the opportunities we provide when mining pools (businesses) are asked 
to agree/disagree on some soft fork, follow with communication and then 
signaling?

Politics and misinformation for few months or years
Forked coin as add-on in some cases
Delay Bitcoin development
Maybe convince everyone Bitcoin needs no improvement
Others
Who can sponsor for the above mentioned things?

Government
Scammers with money and time who were even able to remove whitepaper
Altcoin foundations
Is this FUD? No. These are possible issues related to mining pools and we need 
to plan accordingly. Many people are concerned about UASF and prefer future 
markets. I don't agree with them and reasons are simple. Changes in Bitcoin 
Protocol doesn't need futures markets or tokens, both can be easily manipulated 
by traders and exchanges to make profits. Where is the "Adversarial Thinking" 
involved in changing Bitcoin Protocol and considering involvement of mining 
pools?

Already a long email so will share the link to a recent question I asked on 
"Bitcoin" Stackexchange about identifying which mining pool mined a block: 
https://bitcoin.stackexchange.com/questions/103409/identify-which-mining-pool-mined-a-block

I am hopeful things will improve and interested to contribute more. Will be 
helpful if someone could also answer why do we have 30% vulnerable nodes in 
Bitcoin network?

https://www.reddit.com/r/Bitcoin/comments/lb6dpi/vulnerable_bitcoin_nodes/

Thanks.

Will end the email on a positive note with something that inspires me a lot:

Satoshi's lesson is that you don't need to be the next Einstein in order to 
change the world. Nor do you need to have much money, or influence with the 
world's "movers & shakers". You just need to put in the effort. Satoshi, 
probably just an ordinary hobbyist like anyone here, saw that something was 
lacking in the Universe, and he fought tooth-and-nail for 2+ years until this 
imperfection was corrected. This is what makes Satoshi and his work my greatest 
inspiration.
 
https://bitcointalk.org/index.php?topic=5092492.0
-- 
 Prayank___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

[Prayank via bitcoin-dev]

Hello Everyone,

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

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

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

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

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

--
Prayank

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

[bitcoin-dev] BIP - Automated and Secure Communication

[Prayank via bitcoin-dev]

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/SamouraiDev/status/1335103101188104194 


Ben also tweeted that a BIP would make sense: 
https://twitter.com/benthecarman/status/1334977096079306753 


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

[bitcoin-dev] bips.txt format for all Bitcoin projects

[Prayank via bitcoin-dev]

Hello Everyone,

What?

Can we request all Bitcoin projects to create a file 'bips.txt' with a format 
that describes all the BIPs used in the project?

How?

The file can be uploaded to the root of website used for the project. For 
example: BTCPay can have this file at:  https://btcpayserver.org/bips.txt in 
below format:

BIP78
https://docs.btcpayserver.org/Payjoin/

BIP Number:
Details:

BIP Number
Details:

Why?

Bitcoin Improvement Proposals play an important role in Bitcoin and this will 
make it easier for users, other devs, journalists, researchers, crawlers etc. 
to understand all BIPs used in different Bitcoin Projects, their implementation 
and importance. 

Every BIP with details is mentioned here already: 
https://github.com/bitcoin/bips however I don't think all the devs who 
initially start researching about Bitcoin or the users really understand their 
importance, usage etc. So I am also trying to create BIPs gallery which has 
basic images for each BIP right now and later will include a page to have video 
links, usage, issues, history, other helpful links etc. later for each.

The discussion started with this question on stackexchange: 
https://bitcoin.stackexchange.com/questions/98543/any-website-that-explains-most-of-the-bips-in-a-different-way-that-newbies-can-u/
 


Website that I am working on: https://bips.gallery/ 
Github repository for it: https://github.com/prayank23/BIPsGallery

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

Re: [bitcoin-dev] Post-mix(coinjoin) usage with multisig and cpfp in bitcoin core wallet

[Prayank via bitcoin-dev]

Hello ZmnSCPxj,

Thanks for your response.

The spending tx of multisig can be decided earlier and all three can review the 
outputs involved in it. All 3 txs involved in the system if we consider only 
one mixer and not a chain will get confirmed in the same block as we are using 
CPFP so child pays for 2 parent txs. However, disputes are possible and to 
manage it we will have to make the system complex with things like Peer 1 
locking some amount in a 2 of 2 multisig with Peer 2 or some other incentives 
structure. Initially we can try to keep it simple and a way to spend coins 
after coinjoin with the help of another person you trust.
Yes, you described coinjoin in joinmarket but the problem I am trying to solve 
is: spend coins after coinjoin because post-mix usage is as important as 
coinjoin. Some users dont follow the best practices after coinjoin and it makes 
coinjoin useless or less effective in that case and sometimes for others 
involved in the process as well.
Samourai has few options for users to do this and one of them is: Stonewallx2 
which is a mini coinjoin and similar to what I was trying with this idea.
End goal is to create more options for users to spend UTXOs easily in different 
ways after coinjoin which makes it difficult for people trying to analyze 
transactions or algorithms monitoring, flagging, reporting txs 24/7
Its just an idea for now and maybe I might find better ways to solve this 
problem once I start working on it. For me it makes sense to experiment with 
things and provide more options for users but I wanted to see what others think 
about it who are more experienced and skilled to develop bitcoin related 
projects.
Thanks for this link: https://zmnscpxj.github.io/offchain/generalized.html 

Looks interesting.
Prayank

May 26, 2020, 08:16 by zmnsc...@protonmail.com:

> Good morning Prayank,
>
>
>> 1. Peer 1 doesn't need to be a trusted third party, it can be implemented in 
>> a way that some peers involved in this system can provide liquidity for 
>> others and incentives can be a small fee.
>>
>
> It is not clear in the article, but you mention using a 2-of-3, and show 3 
> participants.
> It seems to me that Peer 1 and Peer 3 (2-of-3) can simply sign to spend the 
> funds coming from Peer 2, and split the funds of Peer 2 among them, without 
> getting input from Peer 2.
>
> That is the reason why I consider this tr\*sted --- Peer 2 has to trust Peer 
> 1 does not collude with Peer 3 to steal the funds of Peer 2.
>
> Unless I have misunderstood your article, which is why I asked for 
> clarification.
>
>> 2. Yes joinmarket is awesome and its payjoin will be better to achieve the 
>> same but I was trying to contribute and add more options for people to 
>> improve privacy on Bitcoin. If we have different ways to mix it will be 
>> harder for spy companies to analyze of some of the transactions.
>>
>
> * While JoinMarket has *a* PayJoin implementation, what I described in the 
> previous email was not a PayJoin, it is standard CoinJoin where one of the 
> equal-valued outputs is to the payee.
>  * In particular, PayJoin requires the cooperation of the payee, what I 
> described does *not* require anything from the payee other than a destination 
> address and an amount to pay.
> * Your described technique (as I understand it) is not too different from 
> what JoinMarket already does for normal sends, with the JoinMarket technique 
> having the advantage that it works with the current paradigm of "send payment 
> to this address" without reconnecting to the payee.
>  The advantage you describe is largely had only if the technique is 
> significantly different.
>  For instance, CoinSwap and CoinJoinXT are different enough from CoinJoin to 
> be valuable in this respect.
>
>> 3. Also one such setup might not make a huge difference but a chain of such 
>> mixers will surely work better if everything done correctly. 
>>
>> 4. Maybe multisig usage is not ideal for such things right now and I am not 
>> the best person when it comes to coding but think that better privacy for 
>> multisig will make it possible for lot of ideas to be implemented on Bitcoin 
>> using different multisig setups and combination of other things that we 
>> already have.
>>
>
> Schnorr (which is introduced as a package deal with Taproot) already makes 
> all n-of-n look the same as 1-of-1 without tr\*sted setup, and makes hidden 
> m-of-n possible with some kind of setup (possibly untrusted I think, but I am 
> not enough of a mathist to describe this, in any case my base understanding 
> is that the setup for m-of-n Schnorr requires a complex ritual involving a 
> number of communication rounds).
> Taproot allows to hide explicit m-of-n in a script behind some kind of n-of-n 
> or m-of-m.
>
> So multisignature usage would automatically gain such advantage once Taproot 
> gets deployed.
>
> In any case, if you are still interested in protocol design with some amount 
> of focus on privacy, 

Re: [bitcoin-dev] Post-mix(coinjoin) usage with multisig and cpfp in bitcoin core wallet

[prayank via bitcoin-dev]

Hello ZmnSCPxj, 


Thanks for the feedback.


1. Peer 1 doesn't need to be a trusted third party, it can be implemented in a 
way that some peers involved in this system can provide liquidity for others 
and incentives can be a small fee.

2. Yes joinmarket is awesome and its payjoin will be better to achieve the same 
but I was trying to contribute and add more options for people to improve 
privacy on Bitcoin. If we have different ways to mix it will be harder for spy 
companies to analyze of some of the transactions.

3. Also one such setup might not make a huge difference but a chain of such 
mixers will surely work better if everything done correctly. 

4. Maybe multisig usage is not ideal for such things right now and I am not the 
best person when it comes to coding but think that better privacy for multisig 
will make it possible for lot of ideas to be implemented on Bitcoin using 
different multisig setups and combination of other things that we already have. 


Prayank


May 25, 2020, 12:24 by zmnsc...@protonmail.com:

> Good morning Prayank
>
>> I have explained the whole idea with a proof of concept in this link: 
>> https://medium.com/@prayankgahlot/post-mix-usage-using-multisig-and-cpfp-e6ce1fdd57a1
>>
>
> The article is not clear I think, so please confirm my understanding below.
>
> Participants:
>
> * "Peer 3" - Payee
> * "Peer 2" - Payer
> * "Peer 1" - Enabling tr\*sted third party
>
> Goal: Payer wants to pay to the payee 0.006BTC
>
> Current Conditions:
>
> * Payer owns 0.01 BTC in a single UTXO
> * Third Party owns 0.05 BTC in a single UTXO
>
> Protocol:
>
> 1.  Payer and Third Party compute a 2-of-3 address with the public keys of 
> Payer, Payee, and Third Party.
> 2.  Payer and Third Party individually pay their owned funds to the 2-of-3 
> address.
> 3.  After confirmation, they consume the new outputs into another transaction 
> with equal-valued outputs, hiding who owns which coins.
>
> Is my understanding correct?
>
> If so, I believe JoinMarket has a superior technology, which does not require 
> a tr\*sted third party; it simply requires one or more UNtrusted third 
> parties to participate in signing a single transaction that does not require 
> paying to an intermediate m-of-n address (thus all inputs are singlesig).
>
> Basically JoinMarket allows the market taker to decide how much the 
> equal-value outputs are, and to define the address it goes to.
> The destination address need not be one the market taker controls, it can be 
> to a payee.
> This technique is the only out-of-the-box way that a JoinMarket wallet can 
> spend funds from a JoinMarket wallet.
>
> JoinMarket as well already includes how to get in touch with enabling third 
> parties (called "market makers").
>
>
> Regards,
> ZmnSCPxj
>

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

[bitcoin-dev] Post-mix(coinjoin) usage with multisig and cpfp in bitcoin core wallet

[prayank via bitcoin-dev]

I have explained the whole idea with a proof of concept in this link: 
https://medium.com/@prayankgahlot/post-mix-usage-using-multisig-and-cpfp-e6ce1fdd57a1

Does it make sense to add such options in bitcoin core wallet and how is the 
overall idea once we have taproot because for now people can check if the tx 
involves a multisig address?

Reading Peter Wuille's reply here it seems taproot will improve privacy for 
multisig: 
https://www.reddit.com/r/Bitcoin/comments/etagx4/please_explain_taproot_and_schnorr_signatures/fffljnl/

Looking for some feedback to work on this idea and don't want it to just remain 
an article on medium. 

Thanks

Prayank

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