Re: [bitcoin-dev] BIP process friction

[alicexbt via bitcoin-dev]

Hi AJ,

I like the idea and agree with everything you shared in the email except one 
thing:

> So I'm switching inquisition over to having a dedicated "IANA"-ish
> thing that's independent of BIP process nonsense. It's at:
> 
> * https://github.com/bitcoin-inquisition/binana

I think "authority" is a strong word especially in bitcoin and this process 
could even work with BINN (Bitcoin Inquisition Numbers And Names). IANA (a 
function of ICANN) is different thing altogether which was founded by US 
government.

/dev/fd0
floppy disk guy

Sent with Proton Mail secure email.

On Wednesday, January 17th, 2024 at 2:42 AM, Anthony Towns via bitcoin-dev 
 wrote:


> Hi all,
> 
> Just under three years ago there was some discussion about the BIPs repo,
> with the result that Kalle became a BIPs editor in addition to Luke, eg:
> 
> * https://gnusha.org/bitcoin-core-dev/2021-04-22.log
> * 
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018859.html
> 
> It remains, however, quite hard to get BIPs merged into the repo, eg
> the following PRs have been open for quite some time:
> 
> * #1408: Ordinal Numbers; opened 2023-01-21, editors comments:
> Kalle:
> https://github.com/bitcoin/bips/pull/1408#issuecomment-1421641390
> https://github.com/bitcoin/bips/pull/1408#issuecomment-1435389476
> 
> Luke:
> https://github.com/bitcoin/bips/pull/1408#issuecomment-1429146796
> https://github.com/bitcoin/bips/pull/1408#issuecomment-1438831607
> https://github.com/bitcoin/bips/pull/1408#issuecomment-1465016571
> 
> * #1489: Taproot Assets Protocol; opened 2023-09-07, editors comments:
> Kalle: https://github.com/bitcoin/bips/pull/1489#issuecomment-1855079626
> Luke: https://github.com/bitcoin/bips/pull/1489#issuecomment-1869721535j
> 
> * #1500: OP_TXHASH; opened 2023-09-30, editors comments:
> Luke:
> https://github.com/bitcoin/bips/pull/1500#pullrequestreview-1796550166
> https://twitter.com/LukeDashjr/status/1735701932520382839
> 
> The range of acceptable BIPs seems to also be becoming more limited,
> such that mempool/relay policy is out of scope:
> 
> * https://github.com/bitcoin/bips/pull/1524#issuecomment-1869734387
> 
> Despite having two editors, only Luke seems to be able to assign new
> numbers to BIPs, eg:
> 
> * https://github.com/bitcoin/bips/pull/1458#issuecomment-1597917780
> 
> There's also been some not very productive delays due to the editors
> wanting backwards compatibility sections even if authors don't think
> that's necessary, eg:
> 
> * https://github.com/bitcoin/bips/pull/1372#issuecomment-1439132867
> 
> Even working out whether to go back to allowing markdown as a text format
> is a multi-month slog due to process confusion:
> 
> * https://github.com/bitcoin/bips/pull/1504
> 
> Anyway, while it's not totally dysfunctional, it's very high friction.
> 
> There are a variety of recent proposals that have PRs open against
> inquisition; up until now I've been suggesting people write a BIP, and
> have been keying off the BIP number to signal activation. But that just
> seems to be introducing friction, when all I need is a way of linking
> an arbitrary number to a spec.
> 
> So I'm switching inquisition over to having a dedicated "IANA"-ish
> thing that's independent of BIP process nonsense. It's at:
> 
> * https://github.com/bitcoin-inquisition/binana
> 
> If people want to use it for bitcoin-related proposals that don't have
> anything to do with inquisition, that's fine; I'm intending to apply the
> policies I think the BIPs repo should be using, so feel free to open a PR,
> even if you already know I think your idea is BS on its merits. If someone
> wants to write an automatic-merge-bot for me, that'd also be great.
> 
> If someone wants to reform the BIPs repo itself so it works better,
> that'd be even better, but I'm not volunteering for that fight.
> 
> Cheers,
> aj
> 
> (It's called "numbers and names" primarily because that way the acronym
> amuses me, but also in case inquisition eventually needs an authoritative
> dictionary for what "cat" or "txhash" or similar terms refer to)
> ___
> 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] Swift Activation - CTV

[alicexbt via bitcoin-dev]

> Your knowledge is incorrect. As far as I know in the getting on for 2 years 
> since the first CTV activation talk/attempt literally no one has built out a 
> CTV use case and demonstrated it on signet with the possible exception of 
> James O'Beirne's OP_VAULT which requires other new opcodes in addition to 
> CTV. 

This is not true.

https://github.com/AdamISZ/pathcoin-poc

/dev/fd0
floppy disk guy

Sent with Proton Mail secure email.

On Tuesday, January 2nd, 2024 at 1:52 PM, Michael Folkson via bitcoin-dev 
 wrote:


> In the interests of time I'll just pick two to respond to but I don't agree 
> with any of your points.
> 
> > Covenants allow trustless utxos sharing and also are needed for vaulting. 
> > The numerous use cases are documented, built out and on signet to my 
> > knowledge. Check out utxos.org for a good list
> 
> Your knowledge is incorrect. As far as I know in the getting on for 2 years 
> since the first CTV activation talk/attempt literally no one has built out a 
> CTV use case and demonstrated it on signet with the possible exception of 
> James O'Beirne's OP_VAULT which requires other new opcodes in addition to 
> CTV. I wish this wasn't the case. It is pitiful that we have these 
> individuals (such as yourself) that are so convinced CTV should be activated 
> but refuse to address any concerns raised by others and refuse to work on any 
> of the speculated use cases, instead choosing to just beat the activation 
> drum over and over again.
> 
> > 4. "Best tool for the job" is not the bar. "Safe for all" and "useful for 
> >some" is the bar. Like any opcodes or tech Bitcoin has deployed in the past. 
> >Changing the bar is not up for discussion.
> 
> If you want to avoid a chain split with an activation attempt (it is possible 
> you don't care but if you do) you have to address concerns others have with a 
> particular proposal. Just because Satoshi was able to make whatever changes 
> he liked in the early days of Bitcoin's history and smaller groups of 
> contributors then were able to activate changes without much scrutiny 
> (Bitcoin was worth a fraction of what it is today and was only supporting a 
> tiny ecosystem back then) doesn't mean we can do the same today. Appointing 
> Erik as the new Satoshi who can make whatever changes he likes, who defines 
> the bar with ultimate certainty and decides what is and what isn't up for 
> discussion also isn't a viable option.
> 
> Thanks
> Michael
> 
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
> 
> 
> Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
> 
> 
> On Monday, 1 January 2024 at 17:11, Erik Aronesty  wrote:
> 
> 
> > 1. Claiming that something that isn't activated (unusable) isn't used as a 
> > non-argument
> > 2. Talking about activation methods is orthogonal. Bip8 is fine.
> > 
> > 3. Covenants allow trustless utxos sharing and also are needed for 
> > vaulting. The numerous use cases are documented, built out and on signet to 
> > my knowledge. Check out utxos.org for a good list
> > 
> > 3. No need to discuss wild extremes that are unrelated to ctvs well 
> > documented utility. Plus multi-sig allows governments to encumber (or 
> > accidentally ruin) destination addresses just like covenants.
> > 
> > 4. "Best tool for the job" is not the bar. "Safe for all" and "useful for 
> > some" is the bar. Like any opcodes or tech Bitcoin has deployed in the 
> > past. Changing the bar is not up for discussion.
> > 
> > 
> > CTV has already been demonstrated "useful for some". The question that 
> > needs to be answered is whether there are any specific objections to safety.
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > On Mon, Jan 1, 2024, 11:37 AM Michael Folkson 
> >  wrote:
> > 
> > > Hi Erik
> > > 
> > > 
> > > > So what exactly are the risks of CTV over multi-sig?
> > > 
> > > 
> > > It is a strange comparison. Multisig is active onchain and is being used 
> > > today for all sorts of things including Lightning and setups that address 
> > > risk of single key loss or malicious signing. When discussing risks of 
> > > CTV there are all sorts of risks that don't apply to multisig. These 
> > > include that it is never used for any of its speculated use cases 
> > > (multisig is being used today), other proposals end up being used instead 
> > > of it (I'm not sure there were or are competing proposals so that 
> > > multisig stops being used, MuSig2 maybe?), chain split risks with 
> > > activation if there isn't consensus to activate it etc. Plus usage of 
> > > complex (non covenant) scripts that fully utilize Taproot trees is still 
> > > low today. Going straight to covenants (imposing restrictions on where 
> > > funds can be sent) and not bothering with imposing all the restrictions 
> > > you'd like on how funds can be spent in the first place seems to me to be 
> > > putting the cart before the horse. Covenants don't ultimately s

Re: [bitcoin-dev] Swift Activation - CTV

[alicexbt via bitcoin-dev]

Hi Bitcoin Developers,

I think CTV is not ready for activation yet. Although I want it to be activated 
and use payment pools, we still have some work to do and AJ is correct that we 
need to build more apps that use CTV on signet.

Reasons:

- Apart from a few PoCs that do not achieve anything big on mainnet, nobody has 
tried to build PoC for a use case that solves real problems
- There is a bounty of 0.01 BTC to 1 BTC for creating such PoCs: 
https://bipbounty.org/bounties/1e101655-bad8-5147-82f7-f03145d567af/
- Some developers think TXHASH fixes all the issues although it doesn't so they 
need to be reviewed, tested and discussed
- There is no clarity on activation method for CTV
- Many users and developers believe timeline for activation is too aggressive, 
we should be patient and give more time for start and delay activation for 2 
years

_reardencode_ is working on something which might improve things for CTV and 
covenants in general.

I have created an issue and if someone could close it with a PR that would be 
helpful: https://github.com/bitcoin-inquisition/bitcoin/issues/44

I apologize if my email caused any drama although most personal attacks were 
targeted towards people supporting CTV including me. Maybe one day we will have 
covenants on bitcoin to improve scaling and privacy.

/dev/fd0
floppy disk guy

Sent with Proton Mail secure email.

On Friday, December 22nd, 2023 at 1:56 AM, alicexbt via bitcoin-dev 
 wrote:


> Hi Luke,
> 
> This is not the first time I am writing this but you keep ignoring it and 
> threaten with URSF. Please build BIP 8 client with LOT=TRUE if you think its 
> the best way to activate and share it so that users can run it.
> 
> I had created this branch specifically for it but needed help which I didn't 
> get: https://github.com/xbtactivation/bitcoin/tree/bip8-ctv
> 
> Discussing trade-offs involved in different activation methods and providing 
> options to users is not an attack.
> 
> /dev/fd0
> floppy disk guy
> 
> Sent with Proton Mail secure email.
> 
> 
> On Friday, December 22nd, 2023 at 1:05 AM, Luke Dashjr l...@dashjr.org wrote:
> 
> 
> 
> > This IS INDEED an attack on Bitcoin. It does not activate CTV - it would
> > (if users are fooled into using it) give MINERS the OPTION to activate
> > CTV. Nobody should run this, and if it gets any traction, it would
> > behoove the community to develop and run a "URSF" making blocks
> > signalling for it invalid.
> > 
> > Luke
> > 
> > On 12/19/23 20:44, alicexbt via bitcoin-dev wrote:
> > 
> > > Hello World,
> > > 
> > > Note: This is not an attack on bitcoin. This is an email with some text 
> > > and links. Users can decide what works best for themselves. There is also 
> > > scope for discussion about changing method or params.
> > > 
> > > I want to keep it short and no energy left. I have explored different 
> > > options for activation and this feels the safest at this point in 2023. I 
> > > have not done any magic or innovation but updated activation params. If 
> > > you agree with them, please run this client else build your own. Anyone 
> > > who calls this attack and do not build alternative option is an attack in 
> > > itself.
> > > 
> > > It activates CTV which is simple covenant proposal and achieves what we 
> > > expect it to. It is upgradeable. I like simple things, at least to start 
> > > with.
> > > 
> > > Activation parameters:
> > > 
> > > `consensus.vDeployments[Consensus::DEPLOYMENT_COVTOOLS].nStartTime = 
> > > 1704067200; 
> > > consensus.vDeployments[Consensus::DEPLOYMENT_COVTOOLS].nTimeout = 
> > > 1727740800; 
> > > consensus.vDeployments[Consensus::DEPLOYMENT_COVTOOLS].min_activation_height
> > >  = 874874;`
> > > 
> > > I need payment pools and it does it for me. Apart from that it enables 
> > > vaults, congestion control etc. We have more PoCs for CTV than we had for 
> > > taproot and I understand it better.
> > > 
> > > If you agree with me, please build and run this client before 01 Jan 2024 
> > > else we can discuss ordinals for next 5 years and activate something in 
> > > 2028.
> > > 
> > > Cheers
> > > 
> > > /dev/fd0
> > > floppy disk guy
> > > 
> > > Sent with Proton Mail secure email.
> > > 
> > > ___
> > > 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 mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Swift Activation - CTV

[alicexbt via bitcoin-dev]

Hi Luke,

This is not the first time I am writing this but you keep ignoring it and 
threaten with URSF. Please build BIP 8 client with LOT=TRUE if you think its 
the best way to activate and share it so that users can run it.

I had created this branch specifically for it but needed help which I didn't 
get: https://github.com/xbtactivation/bitcoin/tree/bip8-ctv

Discussing trade-offs involved in different activation methods and providing 
options to users is not an attack.

/dev/fd0
floppy disk guy

Sent with Proton Mail secure email.

On Friday, December 22nd, 2023 at 1:05 AM, Luke Dashjr  wrote:


> This IS INDEED an attack on Bitcoin. It does not activate CTV - it would
> (if users are fooled into using it) give MINERS the OPTION to activate
> CTV. Nobody should run this, and if it gets any traction, it would
> behoove the community to develop and run a "URSF" making blocks
> signalling for it invalid.
> 
> Luke
> 
> 
> On 12/19/23 20:44, alicexbt via bitcoin-dev wrote:
> 
> > Hello World,
> > 
> > Note: This is not an attack on bitcoin. This is an email with some text and 
> > links. Users can decide what works best for themselves. There is also scope 
> > for discussion about changing method or params.
> > 
> > I want to keep it short and no energy left. I have explored different 
> > options for activation and this feels the safest at this point in 2023. I 
> > have not done any magic or innovation but updated activation params. If you 
> > agree with them, please run this client else build your own. Anyone who 
> > calls this attack and do not build alternative option is an attack in 
> > itself.
> > 
> > It activates CTV which is simple covenant proposal and achieves what we 
> > expect it to. It is upgradeable. I like simple things, at least to start 
> > with.
> > 
> > Activation parameters:
> > 
> > `consensus.vDeployments[Consensus::DEPLOYMENT_COVTOOLS].nStartTime = 
> > 1704067200; consensus.vDeployments[Consensus::DEPLOYMENT_COVTOOLS].nTimeout 
> > = 1727740800; 
> > consensus.vDeployments[Consensus::DEPLOYMENT_COVTOOLS].min_activation_height
> >  = 874874;`
> > 
> > I need payment pools and it does it for me. Apart from that it enables 
> > vaults, congestion control etc. We have more PoCs for CTV than we had for 
> > taproot and I understand it better.
> > 
> > If you agree with me, please build and run this client before 01 Jan 2024 
> > else we can discuss ordinals for next 5 years and activate something in 
> > 2028.
> > 
> > Cheers
> > 
> > /dev/fd0
> > floppy disk guy
> > 
> > Sent with Proton Mail secure email.
> > 
> > ___
> > 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] Swift Activation - CTV

[alicexbt via bitcoin-dev]

Hello World,

Note: This is not an attack on bitcoin. This is an email with some text and 
links. Users can decide what works best for themselves. There is also scope for 
discussion about changing method or params.

I want to keep it short and no energy left. I have explored different options 
for activation and this feels the safest at this point in 2023. I have not done 
any magic or innovation but updated activation params. If you agree with them, 
please run this client else build your own. Anyone who calls this attack and do 
not build alternative option is an attack in itself.

It activates CTV which is simple covenant proposal and achieves what we expect 
it to. It is upgradeable.  I like simple things, at least to start with.

Activation parameters: 

```
consensus.vDeployments[Consensus::DEPLOYMENT_COVTOOLS].nStartTime = 
1704067200;
consensus.vDeployments[Consensus::DEPLOYMENT_COVTOOLS].nTimeout = 
1727740800;

consensus.vDeployments[Consensus::DEPLOYMENT_COVTOOLS].min_activation_height = 
874874; 
```

I need payment pools and it does it for me. Apart from that it enables vaults, 
congestion control etc. We have more PoCs for CTV than we had for taproot and I 
understand it better.

If you agree with me, please build and run this client before 01 Jan 2024 else 
we can discuss ordinals for next 5 years and activate something in 2028.

Cheers

/dev/fd0
floppy disk guy

Sent with Proton Mail secure email.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Addressing the possibility of profitable fee manipulation attacks

[alicexbt via bitcoin-dev]

Hi ArmchairCryptologist,

Bitcoin is working as expected and I don't see any 'manipulation' attacks in 
the bidding for block space. Maybe we aren't used to such demand for blockspace 
on bitcoin. Additionally, fingerprinting based on fee rates and timing to 
attribute transactions to a single person is inaccurate. Various services, such 
as unisat, are used for deploying and minting BRC20 tokens based on region, 
community etc. Consequently, a service broadcasting Bitcoin transactions might 
appear as a single individual.

With regards to UTXO set, IBD for machines with enough RAM seems to be 
unaffected, however I have not done benchmarking to compare IBD before and 
after inscriptions with less dbcache. Also the number of full nodes have 
increased in last one year.

> However, in practice, the attack appears to rely on exploiting the inherent 
> decay used by fee estimation algorithms that are based on historical fee 
> data. This causes many wallets to create transactions that overpay the 
> necessarily next-block fee by a significant amount - for example, the morning 
> after the 700 sat/vB flood on December 16th, Bitcoin Core was still giving a 
> six-block estimate of 529 sat/vB even though <250 sat/vB transactions were 
> being mined. 

Bitcoin Core fee estimation has known issues since years, and I would not 
recommended it for actual use, except for testing purposes.

Related discussion: https://github.com/bitcoin/bitcoin/issues/27995

> My proposed solution to this would be to add partial transaction fee burning. 

NACK

/dev/fd0
floppy disk guy

Sent with Proton Mail secure email.

On Sunday, December 17th, 2023 at 11:11 AM, ArmchairCryptologist via 
bitcoin-dev  wrote:


> ** Motivation **
> As everyone already knows, over the last seven months or so, the size of the 
> mempool as well as transaction fees of on the bitcoin network have both been 
> abnormally high. This tend has generally been ascribed to the introduction of 
> ordinals, and while this may be both technically and actually true, 
> disregarding the debate of whether ordinals is a "valid use" or the 
> blockchain or not, the specific patterns we are seeing for some of these 
> transactions have been making me somewhat suspicious that there could be 
> other underlying motivations for this trend.
> 
> Crucially, as other people have noted, the dust UTXOs these ordinals 
> transactions leave behind combined with the fact that consolidation 
> transactions are being priced out due to persistent high fees is also causing 
> the size of the UTXO set to blow up. As you can see on the chart below, on 
> April 30 2023 there were roughly 90M UTXOs, while as of this writing roughly 
> 7 months later, there are more than 140M. Practically, this means that over 
> the course of the last year, the chainstate as stored by Bitcoin Core has 
> increased from ~5GB to ~9GB.
> 
> See https://www.blockchain.com/explorer/charts/utxo-count - the 3Y chart 
> makes the sudden change in the rate of increase very obvious. More than twice 
> the number of UTXOs has been added in the last six months than in the 
> preceding two and a half years.
> 
> While it is certainly not constant, if you watch the fee rates and timing of 
> when transactions are broadcast using a live view of the mempool like 
> mempool.space, you can see that especially during periods of low mempool 
> influx like early mornings on weekends, there tends to be large bursts (often 
> several hundred kvB worth) of tiny ordinals/BRC-20 transactions with a single 
> dust UTXO broadcast right after each block is found, with a fee set 
> moderately higher than the current average of the top of the mempool, which 
> makes it highly likely that this is done by a single actor. There may of 
> course be legitimate explanations for these patterns, like that they are 
> simply taking advantage of the lower fees, but the impression they leave me 
> is that they seem deliberately timed and priced to pad blocks during such 
> periods to prevent the mempool from draining, under the guise of "minting" 
> BRC-20 tokens.
> 
> For example, in the two-minute span between blocks #820562 and #820563 from 
> Sunday December 10th, over a thousand of these transactions were broadcast:
> 
> https://mempool.space/block/00015d5065ea2ade8bfd0bb9483835c907e34dd969854345
> https://mempool.space/block/1ae267367ade834627df7b119a2710091b3f5d8c1a88
> 
> Most of these transactions have been in the 30-60 sat/vB range, with 
> occasional periods of increasingly higher-fee transactions going higher. The 
> morning of Saturday December 16th is a good example of the latter, where 
> there was an ~8 hour flood where the fees were pushed all the way up to 700 
> sat/vB. These are particularly suspicious, seeing as it would not make much 
> sense to "take advantage of lower fees" by flooding transactions with fees 
> increasingly and systematically set this much higher than the best next-bloc

Re: [bitcoin-dev] Future of the bitcoin-dev mailing list

[alicexbt via bitcoin-dev]

Hi Overthefalls,

+1

Using google for bitcoin mailing list is not good. It feels embarrassing that 
some developers that built and maintained the only decentralized network used 
to settle uncensored payments and some of them even working on nostr, can't 
build their own mailing list which is better than present mailing list. I have 
some ideas but it seems the influential developers have already decided and 
wont accept anything.

Nostr can be used to build a mailing list which also allows anyone to send 
emails apart from publishing events from different clients. We just need a new 
NIP so that nostr relays understand its a different event. There can be 
multiple front end with different levels of moderation to hide some emails and 
ultimately one will be used the most. It can use multiple relays and relays 
share some information in NIP 11 which can include an email address.

/dev/fd0
floppy disk guy

Sent with [Proton Mail](https://proton.me/) secure email.

On Monday, November 13th, 2023 at 8:35 PM, Overthefalls via bitcoin-dev 
 wrote:

> On Tue, 2023-11-07 at 09:37 -0600, Bryan Bishop via bitcoin-dev wrote:
>
>> Google Groups is another interesting option,
>
> I don't think I'm the only person on this list that is strongly opposed to 
> using google for anything. They are too big and they have their hand in 
> everything, and their eyes (and analytics) on everything.
>
> I remember when there were virtually no gmail email addresses that posted to 
> this list. Suddenly in 2020 or 2021, we had an influx of gmail subscribers 
> and posters. That didn't escape me then and it is not lost on me now.
>
> Email is great for public discussion for many reasons. The fact that everyone 
> gets a copy of the data, there is no single central authority that can edit 
> emails once they have been sent out. Anyone can archive email messages, they 
> can generally store or publish the data anywhere they like. That is not the 
> case with web forum content.
>
> I like the lightning anti-spam fee idea. That would encourage me to finally 
> adopt lightning, and it would, I'm sure, produce some interesting results for 
> the list.
>
> I don't think email should be out of the question. Does anyone besides 
> kanz...@gmail.com think that sticking with email is out of the question?
>
> Let's do what's necessary to stick with email.___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] ossification and misaligned incentive concerns

[alicexbt via bitcoin-dev]

Hi Erik,

> currently, there are providers of anonymity services, scaling services, 
> custody, and other services layered on top of bitcoin using trust-based and 
> federated models.
> 
> as bitcoin becomes more popular, these service providers have increasingly 
> had a louder "voice" in development and maintenance of the protocol

> is anyone else worried about this?

Yes. I share your concerns about the growing influence of centralized service 
providers on Bitcoin's development. Although there is nothing much we can do 
about it especially 
when trusted, centralized, custodial, federated etc. projects keep getting 
funded. Only solution is to build better things and be positive.

Example: Everyone is aware of the risks involved in a project that takes 
custody of funds, provide privacy without KYC. There are several examples from 
past in which similar 
projects with some volume ended up getting shutdown by governments. With 
[covenants and statechains][0], it is possible to use bitcoin (p2p ecash) with 
privacy and involves no custody.

There are other [benefits][1] of payment pools (w/ covenants) in terms of 
privacy. Hopefully we agree to do soft fork in next year or so.

[0]: https://github.com/AdamISZ/pathcoin-poc
[1]: https://gnusha.org/bitcoin-wizards/2019-05-21.log

/dev/fd0
floppy disk guy

Sent with Proton Mail secure email.

--- Original Message ---
On Friday, November 3rd, 2023 at 11:54 PM, Erik Aronesty via bitcoin-dev 
 wrote:


> currently, there are providers of anonymity services, scaling services, 
> custody, and other services layered on top of bitcoin using trust-based and 
> federated models.
> 
> as bitcoin becomes more popular, these service providers have increasingly 
> had a louder "voice" in development and maintenance of the protocol
> 
> holders generally want these features
> 
> but service providers have an incentive to maintain a "moat" around their 
> services
> 
> in summary, making privacy, scaling and vaulting "hard" for regular users, 
> keeping it off-chain and federated... is now incentivised among a vocal, but 
> highly technical, minority
> 
> is anyone else worried about this?
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Ordinals BIP PR

[alicexbt via bitcoin-dev]

Hi Peter,

> At that point, why are we bothering with numbers at all? If BIP #'s aren't
memorable, what is their purpose? Why not just let people publish ideas on
their own web pages and figure out what we're going to call those ideas on a
case-by-case basis.

I agree people can maintain BIPs in their own repositories. I will list all the 
BIPs that are not maintained in https://github.com/bitcoin/bips repository on 
https://bips.wiki

/dev/fd0
floppy disk guy

Sent with Proton Mail secure email.

--- Original Message ---
On Friday, October 27th, 2023 at 3:41 AM, Peter Todd via bitcoin-dev 
 wrote:


> On Tue, Oct 24, 2023 at 03:56:55PM -0700, Olaoluwa Osuntokun via bitcoin-dev 
> wrote:
> 
> > TL;DR: let's just use an automated system to assign BIP numbers, so we can
> > spend time on more impactful things.
> 
> 
> Yes, an easy way to do that is to use a mathematical function, like 
> SHA256()
> 
> or Pubkey().
> 
> 
> Of course, that's also silly, as we might as well use URLs at that point...
> 
> > IIUC, one the primary roles of the dedicated BIP maintainers is just to hand
> > out BIP numbers for documents. Supposedly with this privilege, the BIP
> > maintainer is able to tastefully assign related BIPs to consecutive numbers,
> > and also reserve certain BIP number ranges for broad categories, like 3xx
> > for p2p changes (just an example).
> > 
> > To my knowledge, the methodology for such BIP number selection isn't
> > published anywhere, and is mostly arbitrary. As motioned in this thread,
> > some perceive this manual process as a gatekeeping mechanism, and often
> > ascribe favoritism as the reason why PR X got a number immediately, but PR Y
> > has waited N months w/o an answer.
> > 
> > Every few years we go through an episode where someone is rightfully upset
> > that they haven't been assigned a BIP number after following the requisite
> > process. Most recently, another BIP maintainer was appointed, with the hope
> > that the second maintainer would help to alleviate some of the subjective
> > load of the position. Fast forward to this email thread, and it doesn't
> > seem like adding more BIP maintainers will actually help with the issue of
> > BIP number assignment.
> > 
> > Instead, what if we just removed the subjective human element from the
> > process, and switched to using PR numbers to assign BIPs? Now instead of
> > attempting to track down a BIP maintainer at the end of a potentially
> > involved review+iteration period, PRs are assigned BIP numbers as soon as
> > they're opened and we have one less thing to bikeshed and gatekeep.
> > 
> > One down side of this is that assuming the policy is adopted, we'll sorta
> > sky rocket the BIP number space. At the time of writing of this email, the
> > next PR number looks to be 1508. That doesn't seem like a big deal to me,
> > but we could offset that by some value, starting at the highest currently
> > manually assigned BIP number. BIP numbers would no longer always be
> > contiguous, but that's sort of already the case.
> > 
> > There's also the matter of related BIPs, like the segwit series (BIPs 141,
> > 142, 143, 144, and 145). For these, we can use a suffix scheme to indicate
> > the BIP lineage. So if BIP 141 was the first PR, then BIP 142 was opened
> > later, the OP can declare the BIP 142 is BIP 141.2 or BIP 141-2. I don't
> > think it would be too difficult to find a workable scheme.
> 
> 
> At that point, why are we bothering with numbers at all? If BIP #'s aren't
> memorable, what is their purpose? Why not just let people publish ideas on
> their own web pages and figure out what we're going to call those ideas on a
> case-by-case basis.
> 
> All this gets back to my original point: a functioning BIP system is
> inherently centralized and involves human gatekeepers who inevitably have to
> apply standards to approve BIPs. You can't avoid this as long as you want a 
> BIP
> system.
> 
> --
> 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] Ordinals BIP PR

[alicexbt via bitcoin-dev]

Hi Luke,

> Maybe we need a 3rd BIP editor. Both Kalle and myself haven't had time
> to keep up. There are several PRs far more important than Ordinals
> nonsense that need to be triaged and probably merged.

I don't think adding another editor solves the problem discussed in this 
thread. 
Last time we had similar situation and Kalle was added as editor instead of 
making BIP
process decentralized. It was discussed in this [thread][0].

BIP editors can have personal opinions and bias but if it affects PRs getting 
merged,
then repo has no use except for a few developers.

> The issue with Ordinals is that it is actually unclear if it's eligible
> to be a BIP at all, since it is an attack on Bitcoin rather than a
> proposed improvement. 

What makes it an attack on bitcoin? Some users want to use their money in a 
different way.
How is it different from taproot assets and other standards to achieve similar 
goals?

Some users and developers believe drivechain is an attack on bitcoin, BIP 47 is 
considered bad,
use of OP_RETURN in colored coins is controversial, increasing blocksize is not 
an improvement etc.
Still these BIPs exist in the same repository.

> proposed improvement. There is a debate on the PR whether the
> "technically unsound, ..., or not in keeping with the Bitcoin
> philosophy." or "must represent a net improvement." clauses (BIP 2) are
> relevant. Those issues need to be resolved somehow before it could be
> merged.

Can we remove terms like "philosophy", "net improvement" etc. from BIP 2? 
Because they could mean different
things for different people.

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


/dev/fd0
floppy disk guy

Sent with Proton Mail secure email.

--- Original Message ---
On Monday, October 23rd, 2023 at 11:59 PM, Luke Dashjr via bitcoin-dev 
 wrote:


> Everything standardized between Bitcoin software is eligible to be and
> should be a BIP. I completely disagree with the claim that it's used for
> too many things.
> 
> SLIPs exist for altcoin stuff. They shouldn't be used for things related
> to Bitcoin.
> 
> BOLTs also shouldn't have ever been a separate process and should really
> just get merged into BIPs. But at this point, that will probably take
> quite a bit of effort, and obviously cooperation and active involvement
> from the Lightning development community.
> 
> Maybe we need a 3rd BIP editor. Both Kalle and myself haven't had time
> to keep up. There are several PRs far more important than Ordinals
> nonsense that need to be triaged and probably merged.
> 
> The issue with Ordinals is that it is actually unclear if it's eligible
> to be a BIP at all, since it is an attack on Bitcoin rather than a
> proposed improvement. There is a debate on the PR whether the
> "technically unsound, ..., or not in keeping with the Bitcoin
> philosophy." or "must represent a net improvement." clauses (BIP 2) are
> relevant. Those issues need to be resolved somehow before it could be
> merged. I have already commented to this effect and given my own
> opinions on the PR, and simply pretending the issues don't exist won't
> make them go away. (Nor is it worth the time of honest people to help
> Casey resolve this just so he can further try to harm/destroy Bitcoin.)
> 
> Luke
> 
> 
> On 10/23/23 13:43, Andrew Poelstra via bitcoin-dev wrote:
> 
> > On Mon, Oct 23, 2023 at 03:35:30PM +, Peter Todd via bitcoin-dev wrote:
> > 
> > > I have not requested a BIP for OpenTimestamps, even though it is of much
> > > wider relevance to Bitcoin users than Ordinals by virtue of the fact that 
> > > much
> > > of the commonly used software, including Bitcoin Core, is timestamped 
> > > with OTS.
> > > I have not, because there is no need to document every single little 
> > > protocol
> > > that happens to use Bitcoin with a BIP.
> > > 
> > > Frankly we've been using BIPs for too many things. There is no avoiding 
> > > the act
> > > that BIP assignment and acceptance is a mark of approval for a protocol. 
> > > Thus
> > > we should limit BIP assignment to the minimum possible: extremely 
> > > widespread
> > > standards used by the entire Bitcoin community, for the core mission of
> > > Bitcoin.
> > 
> > This would eliminate most wallet-related protocols e.g. BIP69 (sorted
> > keys), ypubs, zpubs, etc. I don't particularly like any of those but if
> > they can't be BIPs then they'd need to find another spec repository
> > where they wouldn't be lost and where updates could be tracked.
> > 
> > The SLIP repo could serve this purpose, and I think e.g. SLIP39 is not a BIP
> > in part because of perceived friction and exclusivity of the BIPs repo.
> > But I'm not thrilled with this situation.
> > 
> > In fact, I would prefer that OpenTimestamps were a BIP :).
> > 
> > > It's notable that Lightning is not standardized via the BIP process. I 
> > > think
> > > that's a good thing. While it's arguably of wide enough use to warrent 
> > > BIPs,
> > > 

Re: [bitcoin-dev] Proposed BIP for OP_CAT

[alicexbt via bitcoin-dev]

Hi Ethan,

> [2]: P. Wuille, "Multisig on steroids using tree signatures", 2015,
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019233.html

Correct link for "Multisig on steroids using tree signatures": 
https://blog.blockstream.com/en-treesignatures/

/dev/fd0
floppy disk guy

Sent with Proton Mail secure email.

--- Original Message ---
On Saturday, October 21st, 2023 at 10:38 AM, Ethan Heilman via bitcoin-dev 
 wrote:


> Hi everyone,
> 
> We've posted a draft BIP to propose enabling OP_CAT as Tapscript opcode.
> https://github.com/EthanHeilman/op_cat_draft/blob/main/cat.mediawiki
> 
> OP_CAT was available in early versions of Bitcoin. It was disabled as
> it allowed the construction of a script whose evaluation could create
> stack elements exponential in the size of the script. This is no
> longer an issue in the current age as tapscript enforces a maximum
> stack element size of 520 Bytes.
> 
> Thanks,
> Ethan
> 
> ==Abstract==
> 
> This BIP defines OP_CAT a new tapscript opcode which allows the
> concatenation of two values on the stack. This opcode would be
> activated via a soft fork by redefining the opcode OP_SUCCESS80.
> 
> When evaluated the OP_CAT instruction:
> # Pops the top two values off the stack,
> # concatenate the popped values together,
> # and then pushes the concatenated value on the top of the stack.
> 
> OP_CAT fails if there are less than two values on the stack or if a
> concatenated value would have a combined size of greater than the
> maximum script element size of 520 Bytes.
> 
> ==Motivation==
> Bitcoin tapscript lacks a general purpose way of combining objects on
> the stack restricting the expressiveness and power of tapscript. For
> instance this prevents among many other things the ability to
> construct and evaluate merkle trees and other hashed data structures
> in tapscript. OP_CAT by adding a general purpose way to concatenate
> stack values would overcome this limitation and greatly increase the
> functionality of tapscript.
> 
> OP_CAT aims to expand the toolbox of the tapscript developer with a
> simple, modular and useful opcode in the spirit of Unix[1]. To
> demonstrate the usefulness of OP_CAT below we provide a non-exhaustive
> list of some usecases that OP_CAT would enable:
> 
> * Tree Signatures provide a multisignature script whose size can be
> logarithmic in the number of public keys and can encode spend
> conditions beyond n-of-m. For instance a transaction less than 1KB in
> size could support tree signatures with a thousand public keys. This
> also enables generalized logical spend conditions. [2]
> * Post-Quantum Lamport Signatures in Bitcoin transactions. Lamport
> signatures merely requires the ability to hash and concatenate values
> on the stack. [3]
> * Non-equivocation contracts [4] in tapscript provide a mechanism to
> punish equivocation/double spending in Bitcoin payment channels.
> OP_CAT enables this by enforcing rules on the spending transaction's
> nonce. The capability is a useful building block for payment channels
> and other Bitcoin protocols.
> * Vaults [5] which are a specialized covenant that allows a user to
> block a malicious party who has compromised the user's secret key from
> stealing the funds in that output. As shown in A. Poelstra, "CAT
> 
> and Schnorr Tricks II", 2021,
> https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-ii.html
> 
> OP_CAT is sufficent to build vaults in Bitcoin.
> * Replicating CheckSigFromStack  A. Poelstra, "CAT and Schnorr
> 
> Tricks I", 2021,
> https://medium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298
>  which would allow the creation of simple covenants and other
> 
> advanced contracts without having to presign spending transactions,
> possibly reducing complexity and the amount of data that needs to be
> stored. Originally shown to work with Schnorr signatures, this result
> has been extended to ECDSA signatures. [6]
> 
> The opcode OP_CAT was available in early versions of Bitcoin. However
> OP_CAT was removed because it enabled the construction of a script for
> which an evaluation could have memory usage exponential in the size of
> the script.
> For instance a script which pushed an 1 Byte value on the stack then
> repeated the opcodes OP_DUP, OP_CAT 40 times would result in a stack
> value whose size was greater than 1 Terabyte. This is no longer an
> issue because tapscript enforces a maximum stack element size of 520
> Bytes.
> 
> ==Specification==
> 
> Implementation
> 
> 
> if (stack.size() < 2)
> return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);
> valtype vch1 = stacktop(-2);
> valtype vch2 = stacktop(-1);
> 
> if (vch1.size() + vch2.size() > MAX_SCRIPT_ELEMENT_SIZE)
> 
> return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);
> 
> valtype vch3;
> vch3.reserve(vch1.size() + vch2.size());
> vch3.insert(vch3.end(), vch1.begin(), vch1.end());
> vch3.insert(vch3.end(), vch2.begin(), vch2.end());
> 
> popstack(stack);

[bitcoin-dev] Goldfish: Spoofing wallet fingerprints to improve privacy

[alicexbt via bitcoin-dev]

Hi Bitcoin Developers,


### Problem

Wallet fingerprinting: Identifying the bitcoin wallet used to create the 
transaction

### Previous research

A) 0xB10C wrote a [blog post][0] in 2020 about wallet fingerprinting.

   Most transactions followed the fee rate recommendations provided by 
Blockchain.com and had same characteristics, including 
   using P2PKH outputs, having either one or two outputs created, a transaction 
version 1, and BIP-69 compliance.

   Suggested solutions: 
   
   1. Randomness in fee rates
   2. Broadening fingerprint
  - Support receiving to and spending from different address types
  - Time-lock some of the created transactions to the current block height
  - Set a random transaction version when constructing the transaction
   3. Spoofing

B) achow101 created a [tool][1] in 2022 to identify wallet from a bitcoin 
transaction

   This tool focused on 2 fingerprints (bitcoin core and electrum) although lot 
of other bitcoin wallets are used.
   It is good proof of concept which can be improved further by adding more 
fingerprints in it.

C) I wrote a [blog post][2] about wallet fingerprinting based on nLocktime, 
nVersion used by different wallets.

D) ishaanam wrote a [blog post][3] recently based on her research about wallet 
fingerprinting which covers lot of things.

   1. Fingerprints categorized into 4 types: Independent, Probabilistic, 
Dependent, and Temporal
   2. Observations based on 8 bitcoin wallets:
  - Bitcoin Core (v. 25.0)
  - Electrum (v. 4.4.5)
  - Blue Wallet (v. 6.4.6 iOS)
  - Exodus (v. 23.7.2 iOS)
  - Trust Wallet (v. 9. 0 iOS)
  - Coinbase Wallet (v. 28.53 iOS)
  - Trezor Suite (v. 23.7.2)
  - Ledger Live (v. 2.64.2)
   3. Fingerprints [table][4]
   4. [Wallet Fingerprint Detector][5]

  Conclusion: 

  > There is no clear cut solution to the issues discussed here. While some 
fingerprints would be trivial to eliminate,
  > it will be difficult to eliminate fingerprinting entirely. Just because 
something is a fingerprint does not 
  > automatically mean that it should not be done by a wallet. For 
instance, all transactions of a wallet having a 
  > certain input order or change index should definitely be modified, but 
things like anti-fee-sniping and the spending
  > of taproot UTXOs are still worthwhile.

### Solution 

A [tool][6] for spoofing wallet fingerprint. It is a proof of concept which can 
be improved further if everyone finds it useful.
It supports nLocktime, nVersion and BIP 69 ordering for 2 bitcoin wallets 
(electrum and blue). Users can enter PSBT and spoof its
wallet fingerprint based on the option selected in dropdown list.


### Rationale

 - As protocol developers continue to introduce changes that impact user 
privacy, such as the upcoming version 3 transactions,
   identifying wallets based on transaction becomes easier.
 - All wallets will never have same fingerprint.
 - For users who prioritize privacy, spoofing presents a viable solution.
 - While similar techniques have been applied in the context of browser 
fingerprinting, they can also be adapted for bitcoin
   transactions.

 Comparison with browser fingerprinting:

 A browser fingerprint typically comprises various things such as the user 
agent, IP address, canvas fingerprint, WebGL information,
 installed fonts, timezone, screen resolution, cookie data, system info etc. In 
contrast, a wallet fingerprint for bitcoin transactions
 includes RBF signaling, transaction version, BIP 69 ordering, fee rate, change 
position and type etc.

 If a tool can effectively spoof a browser fingerprint, same concept could be 
applied to bitcoin transactions as well. [Tor browser][7] 
 protects against fingerprinting by making fingerprints of all users same 
irrespective of their device or OS. It's important
 to note that existing tools attempting to identify wallets from transactions 
include lot of false positives, and the introduction of 
 spoofing could further increase their prevalence. This increased uncertainty 
in identifying wallet can make chain analysis difficult, 
 ultimately enhancing privacy. Some privacy-focused wallets may even consider 
implementing this feature in wallets.

### Acknowledgement
 
 0xB10C, achow101, ishaanam, pythcoiner and statusquont

[0]: https://b10c.me/observations/03-blockchaincom-recommendations/
[1]: https://github.com/achow101/wallet-fingerprinting
[2]: https://consentonchain.github.io/blog/posts/fingerprinting/
[3]: https://ishaana.com/blog/wallet_fingerprinting/
[4]: https://ishaana.com/blog/wallet_fingerprinting/fingerprints_final.png
[5]: https://github.com/ishaanam/wallet-fingerprinting
[6]: https://gitlab.com/144bytes/goldfish
[7]: 
https://blog.torproject.org/browser-fingerprinting-introduction-and-challenges-ahead/


/dev/fd0
floppy disk guy

Sent with Proton Mail secure email.
___
bitcoin-dev mailing list
bitcoin-dev@lists.

[bitcoin-dev] BIP-119 UASF

[alicexbt via bitcoin-dev]

Hi Bitcoin Developers,

Note: This email is inspired from 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018538.html 
written by Chris Belcher

Lets compare all covenant proposals:

https://docs.google.com/spreadsheets/d/1YL5ttNb6-SHS6-C8-1tHwao1_19zNQ-31YWPAHDZgfo/edit#gid=0

Why general and recursive covenants are controversial:

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019976.html

Why I prefer CTV over APO?

- LN symmetry can be achieved with CSFS later if there is really a demand apart 
from twitter
- CTV improves LN
- CTV does not change how sighash works still we get covenants
- Less bytes
- More tooling
- Not recursive
- Not limited to taproot
- Other differences

MASF or speedy trial allows miners to coordinate and signal "readiness". This 
is misunderstood by lot of users as miners can always refuse to follow new 
consensus rules even after signaling or economics nodes can reject blocks with 
new consensus rules later.

Instead of doing this we could do a UASF in which things are clear that 
economic nodes enforce consensus rules and miners or majority of miners at this 
point wont go against bitcoin communities including nodes with some economic 
activity.

If there is a positive feedback, we could work on building UASF client for 
activation and bitcoin core can follow.

/dev/fd0

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

Re: [bitcoin-dev] Serverless Payjoin

[alicexbt via bitcoin-dev]

Hi Dan,

May be too late to reply. Sorry.

Based on our last communication, I wanted to share these points after reading 
https://payjoin.substack.com/p/serverless-payjoin-gets-its-wings so that other 
can also evaluate them:

1) I don't think NIP 4 has any security issues. Maybe privacy issues. Its just 
metadata leak which should be okay if a new npub is used every time users do 
payjoin. Message itself will remain secret because it's encrypted.
2) Backwards compatibility due to npub, relay etc. shared in payjoin URI as 
implemented by Kukks. Not sure how to fix this.
3) Relays have no incentive to anything malicious if multiple relays are used. 
Although I am still not clear what malicious activity can they do with 
encrypted messages.
4) IP address is an issues with lot of projects and this can be managed by 
users or wallet implementation with the use of RiseupVPN, Tor, i2p etc.
5) Random padding suggested by a few senior devs makes sense.

/dev/fd0

floppy disk guy

--- Original Message ---
On Monday, January 23rd, 2023 at 2:20 AM, Dan Gould via bitcoin-dev 
 wrote:


> Hi all,
> 
> I'm publishing a payjoin upgrade in response to a request from this list. The 
> payjoin receiver no longer has to run a public server. They lean on a relay 
> for the connection and share a symmetric-key for security rather than a TLS 
> certificate or a Tor hidden service.
> 
> I think this work raises a greater problem which is that payjoin assumes 
> synchronous communication while it’s an asynchronous world.
> 
> I added the full write-up in plain text below, though I recommend reading the 
> gist for improved formatting and in order to benefit from future edits:
> https://gist.github.com/DanGould/243e418752fff760c9f6b23bba8a32f9
> 
> Best regards,
> Dan
> 
> 
> 
> Serverless Payjoin
> 
> 
> Receive surveillance-busting bitcoin transfers without hosting a secure 
> endpoint
> 
> 
> 
> OVERVIEW
> 
> 
> Payjoin[1] solves the sole privacy problem left open in the bitcoin paper, 
> that transactions with multiple inputs "necessarily reveal that their inputs 
> were owned by the same owner."[2] Breaking that common-input ownership 
> assumption requires contributions from multiple owners via interaction, 
> namely hosting a server endpoint secured by a certificate on the receiving 
> side. This problem has been singled out on this list as a barrier to greater 
> payjoin adoption.[3]
> 
> Instead of a peer-hosted endpoint, this scheme weilds a TURN[4] relay for 
> connectivity and symmetric cryptography for security. Without a replacement 
> for secured networking, the relay could steal funds. Aside from a pre-shared 
> secret and relayed networking, the protocol takes the same form as the 
> existing BIP 78 payjoin spec.
> 
> 
> 
> BASIC SCHEME
> 
> 
> The recipient requests that the relay allocate them an endpoint at which they 
> may be reached by UDP. Once allocated, they listen on it. They then generate 
> a 256-bit key, psk. Out of band, they share a BIP 21[5] payjoin uri including 
> their unique relay allocation endpoint in the pj query parameter and psk in a 
> new psk query parameter.
> 
> The sender constructs their request containing an original PSBT as in BIP 78. 
> Instead of sending it over TLS or Tor, they follow noise framework NNpsk0[6] 
> pattern. They encrypt the request using psk alongside an ephemeral sender key 
> and MAC. The resulting ciphertext ensures message secrecy and integrity when 
> relayed to the recipient by the pj endpoint.
> 
> The pay-to-endpoint protocol proceeds to produce a payjoin as in BIP 78 
> except that messages are secured by the noise NNpsk0 pattern rather than TLS 
> or Tor.
> 
> 
> 
> IMPROVEMENTS
> 
> 
> HTTP/3
> 
> TURN defaults to UDP. In order to adhere to the BIP 78 protocol HTTP 
> messaging, HTTP/3 should be used on top of TURN/UDP.
> Offline Asynchronous Payjoins
> 
> It may be possible for a relay to hold a requeust for an offline payjoin peer 
> until that peer comes online. However, the BIP 78 spec recommends 
> broadcasting request PSBTs in the case of an offline counterparty. Doing so 
> exposes a naïve, surveillance-vulnerable transaction which payjoin intends to 
> avoid. More research needs to be done before such a protocol can be 
> recommended.
> 
> 
> Nostr
> 
> While a custom Nostr relay could in theory replace the TURN relay while 
> sharing shnorr crypto with bitcoin, it would require another protocol to 
> synchronize networking, since Nostr makes no assumptions about whether a peer 
> is online or not, and a careful cryptography audit to secure. TURN and Noise 
> are already well understood, tested, and have production library support 
> across multiple popular languages and other bitcoin-related projects. Noise 
> even has tooling for formal verification. Nostr relays may prove more likely 
> to allow public access and more robust if we figure out async payjoin, 
> however.
> 
> 
> 
> NOTEWORTHY DETAILS
> 
> 
> Attack vectors
> 
> Since TUR

[bitcoin-dev] Denial of Service using Package Relay

[alicexbt via bitcoin-dev]

Hi Bitcoin Developers,

I think its possible to use [package relay][0] for DoS attack in coinjoin. A 
few other projects could also be affected by packages. Since its a proposal 
that adds new P2P messages, transaction relay etc. its as important as any soft 
fork. Let me know if I am missing something.

Consider there are 2 coinjoin implementations: A and B

1) Register input in A
2) Double spend same input with zero fee to your own address
3) Register unconfirmed UTXO from 2 in B
4) B relays a package in which coinjoin transaction (child) pays for 2 (parent)

Users and coinjoin implementation B, both are incentivized to attack in this 
case.

Attacker could also use a different approach and register same input in A, B 
although there are some tradeoffs:

- If input gets included in a coinjoin transaction broadcasted by A, there is 
nothing much B can do about it. RBF with multiple users isn't easy and costly.
- Implementation with less users participating in a round would have an 
advantage.

[0]: https://gist.github.com/sdaftuar/8756699bfcad4d3806ba9f3396d4e66a


/dev/fd0
floppy disk guy

Sent with Proton Mail secure email.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] postr: p2n payjoin using nostr

[alicexbt via bitcoin-dev]

Hi Symphonic,

> I'm a bit confused as to what exactly this is a proof of concept for.

This is a proof of concept for using nostr npub and relays for payjoin.

> Your use of SIGHASH_NONE does in fact make it possible for the reciever to do 
> whatever they want with your funds (which I see you acknowledge in your brief 
> description, but still, not very practical).

SIGHASH_NONE can be used when there is no change in the transaction and sender 
wants to spend whole UTXO for the payment. Recipient is free to decide the 
outputs and extra input for the transaction.

> However, it is also possible for anyone who sees the final broadcasted 
> transaction to extract the sender's input and use it for any purpose they 
> wish; game theoretically miners would just steal your funds, but it's 
> possible for any user to RBF and send those funds wherever they like.

- Based on my understanding of SIGHASH flags and a [blog post][0] by Raghav 
Sood, use of SIGHASH_ALL by recipient will secure all outputs. However I have 
realized it is still vulnerable in a [tweet thread][1] as you mentioned. While 
writing this email, poll was still 50-50 so I guess its a learning thing. We 
have less docs about SIGHASH flags, maybe an e-book with all experiments would 
improve this.
- Since this was just a PoC to use nostr, use of specific SIGHASH flags can be 
ignored and developers can use other flags or default. I will improve/change it 
as well. I wanted to use SIGHASH_NONE to improve privacy and less UX issues.
- There are no incentives for sender or recipient to use RBF and double spend 
in a payjoin transaction.

[0]: https://raghavsood.com/blog/2018/06/10/bitcoin-signature-types-sighash
[1]: https://twitter.com/144bytes/status/1668261886884708352

/dev/fd0
flopyy disk guy

Sent with Proton Mail secure email.

--- Original Message ---
On Sunday, June 11th, 2023 at 8:02 AM, symphonicbtc  
wrote:


> Hey alicexbt,
> I'm a bit confused as to what exactly this is a proof of concept for. Your 
> use of SIGHASH_NONE does in fact make it possible for the reciever to do 
> whatever they want with your funds (which I see you acknowledge in your brief 
> description, but still, not very practical). However, it is also possible for 
> anyone who sees the final broadcasted transaction to extract the sender's 
> input and use it for any purpose they wish; game theoretically miners would 
> just steal your funds, but it's possible for any user to RBF and send those 
> funds wherever they like.
> 
> As is the case with any work-in-progress software, but especially in this 
> instance, I urge you to disable the ability to use mainnet coins directly in 
> your code. This is highly irresponsible to post in this state.
> 
> Moreover, a bit redundantly considering the glaring and severe security 
> issues, this is not a proper implemenation of a payjoin, even in a 
> theoretical scenario, as it is trivial to discern which inputs belong to the 
> sender and reciever respectively in the final transaction.
> 
> Symphonic
> 
> 
> Sent with Proton Mail secure email.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] postr: p2n payjoin using nostr

[alicexbt via bitcoin-dev]

Hello Bitcoin Developers,

Since I learnt about payjoin(p2ep), there was always discussion of it not being 
adopted because of need for sever. This proposal needs no personal sever 
however I am doubtful it still gets any adoption.

Note: Even stowaway (used by samourai) uses servers in fact two: 
soroban.samouraiwallet.com and paynym.is

I am sharing a proof of concept that does not need any server however there 
need to be some common nostr relays between sender and recipient:

Repository: https://gitlab.com/144bytes/postr
Demo Video: https://www.youtube.com/watch?v=O5qbexzO37c

/dev/fd0
floppy disk guy

Sent with [Proton Mail](https://proton.me/) secure email.___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin mail list needs an explicit moderation policy

[alicexbt via bitcoin-dev]

Hi Maxim,

> In this regard, I’d like to propose the following:
> 
> 1.  The bitcoin-dev mail list must have a clear moderation (or 
> pre-publication peer-review policy). It can be proposed and discussed in this 
> mail list and, upon agreement, must become public and obligatory.
> 2.  Bryan Bishop, who was acting for a long time as moderator, must be 
> appreciated for many years of unpaid work, and replaced with the new 
> moderator who should be selected from a list of potential candidates (again 
> in this mail list) using the criteria “least votes against”.
> 3.  The role of the moderator(s) must be purely executive of the policies, 
> without any personal preferences.
> 4.  A dedicated mail list should be created (“bitcoin-dev-unmoderated”) which 
> will publish all submissions without moderation. It may contain spam and only 
> people interested in the auditing bitcoin-dev main mal list non-censorship 
> will be reading it. However, if they will notice that some non-spam e-mails 
> were censored, they can announce that publicly. In this case, the failing 
> moderator(s) should be removed and replaced.
> 5.  The incentive to work as a moderator should be reputation-based.

- I doubt moderation policy would change anything as it could be interpreted 
differently by everyone and misused. We have seen this in [BIPs repository][0] 
recently.

- We should change moderators regularly since everyone has their bias and 
mailing list is important part of discussions related to bitcoin development.

- Unmoderated mailing list front end could be created using all the emails from 
archives and moderated section. Moderated emails have attachments that would 
need some [EML parser][1].

I don't even know who are the present moderators or people with access to 
moderation queue. There should be some transparency about it.

[0]: https://github.com/bitcoin/bips/pull/1408
[1]: 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020213.html

/dev/fd0
floppy disk guy

Sent with Proton Mail secure email.

--- Original Message ---
On Saturday, June 3rd, 2023 at 5:13 AM, Dr Maxim Orlovsky via bitcoin-dev 
 wrote:


> Dear community,
> 
> 
> I am writing this list to bitcoin-dev mail list, but to prevent potential 
> censorship I am sending CC to lightning-dev mail list, in order to leave the 
> current moderator(s) without an option not to publish the letter and not to 
> leave the topic “under the cover” (sorry Lightning friends for spamming your 
> list with this off-topic).
> 
> 
> 
> A day before yesterday I sent a post to bitcoin-dev referencing the 
> publication of the new Bitcoin scalability and privacy protocol, which had 
> already received a broad reaction across the bitcoin community with literally 
> no critical/negative responses after ~25k of reads [1]. I am not the 
> first-time writer to the mail list and had developed things like RGB smart 
> contracts [2], rust lightning implementation named LNP [3], multiple bitcoin 
> libraries and software [4], [5], during three years was a main contributor to 
> rust-bitcoin [6] etc, etc. The post was clearly not spam and received support 
> from known community members like Giacomo Zucco [7]. Bryan Bishop knows me 
> since 2019 when I was presenting Storm protocol on the stage on Scaling 
> Bitcoin in Tel Aviv - and he was writing a transcript of it [8]. Thus, I am 
> not a random unknown guy or a known spammer - and the post can be easily 
> checked for not containing any scam promotion.
> 
> 
> 
> Nevertheless, I next day I see other e-mails getting released to bitcoin-dev, 
> while mine - was not. It is not a problem, but since we already had an 
> incident in the past where Bryan reported the failure of his software, me and 
> my colleagues from LNP/BP Standards Association started asking questions 
> about whether this post ever got to Bryan.
> 
> 
> 
> What happened next was very unexpected. I am giving the core of the 
> conversation over Twitter after in Annex A - with the purpose to showcase the 
> problem I’d like to address in this e-mail. From the discussion, it is clear 
> that bitcoin-dev mail list lacks clear explicit moderation (or peer-review) 
> policies, which must be applied on a non-selective basis. Also, Bryan Bishop, 
> as the current moderator, had abused his powers in achieving his agenda based 
> on personal likes or dislikes. The conversation went nowhere, and the post 
> got published only after a requirement from Peter Todd [9].
> 
> 
> 
> In this regard, I’d like to propose the following:
> 
> 1.  The bitcoin-dev mail list must have a clear moderation (or 
> pre-publication peer-review policy). It can be proposed and discussed in this 
> mail list and, upon agreement, must become public and obligatory.
> 2.  Bryan Bishop, who was acting for a long time as moderator, must be 
> appreciated for many years of unpaid work, and replaced with the new 
> moderator who should be selected from a list of potential candida

Re: [bitcoin-dev] Responsible disclosures and Bitcoin development

[alicexbt via bitcoin-dev]

gt; > > > its not clear to some "open source" devs:
> > > > 
> > > > Impact of this vulnerability:
> > > > 
> > > > - Denial of Service
> > > > - Stale blocks affecting mining pool revenue
> > > > 
> > > > Why it should have been reported privately to secur...@bitcoincore.org, 
> > > > even if initially found affecting only debug build?
> > > > 
> > > > Example: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3129
> > > > 
> > > > CVE is a different process and I am aware of it. It would be good for 
> > > > certain developers in the core team to reflect on their own approach to 
> > > > security, regardless of whether their work receives CVE recognition or 
> > > > not.
> > > > 
> > > > /dev/fd0
> > > > floppy disk guy
> > > > 
> > > > Sent with Proton Mail secure email.
> > > > 
> > > > --- Original Message ---
> > > > On Friday, May 12th, 2023 at 1:14 AM, Michael Folkson 
> > > > michaelfolk...@protonmail.com wrote:
> > > > 
> > > > > Hi alicexbt
> > > > > 
> > > > > The vulnerability reporting process requires communication and 
> > > > > resolution via a small group of individuals 0 rather than through 
> > > > > open collaboration between any contributors on the repo. There are 
> > > > > clearly examples where the process is critically needed, the most 
> > > > > obvious past example being the 2018 inflation bug 1. However, it 
> > > > > doesn't scale for all bug reports and investigations to go through 
> > > > > this tiny funnel. For an issue that isn't going to result in loss of 
> > > > > onchain funds and doesn't seem to present a systemic issue (e.g. 
> > > > > network DoS attack, inflation bug) I'm of the view that opening a 
> > > > > public issue was appropriate in this case especially as the issue 
> > > > > initially assumed it was only impacting nodes running in debug mode 
> > > > > (not a mode a node in production is likely to be running in).
> > > > > 
> > > > > An interesting question though and I'm certainly happy to be 
> > > > > corrected by those who have been investigating the issue. Some 
> > > > > delicate trade-offs involved including understanding and resolving 
> > > > > the issue faster through wider collaboration versus keeping knowledge 
> > > > > of the issue within a smaller group.
> > > > > 
> > > > > Thanks
> > > > > Michael
> > > > > 
> > > > > --
> > > > > Michael Folkson
> > > > > Email: michaelfolkson at protonmail.com
> > > > > GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
> > > > > 
> > > > > Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
> > > > > 
> > > > > --- Original Message ---
> > > > > On Tuesday, May 9th, 2023 at 03:47, alicexbt via bitcoin-dev 
> > > > > bitcoin-dev@lists.linuxfoundation.org wrote:
> > > > > 
> > > > > > Hi Bitcoin Developers,
> > > > > > 
> > > > > > There is an open issue in bitcoin core repository which was created 
> > > > > > last week: https://github.com/bitcoin/bitcoin/issues/27586
> > > > > > 
> > > > > > I think this should have been reported privately as vulnerability 
> > > > > > instead of creating a GitHub issue even if it worked only in debug 
> > > > > > mode. Some users in the comments have also experienced similar 
> > > > > > issues without debug build used for bitcoind. I have not noticed 
> > > > > > any decline in the number of listening nodes on bitnodes.io in last 
> > > > > > 24 hours so I am assuming this is not an issue with majority of 
> > > > > > bitcoin core nodes. However, things could have been worse and there 
> > > > > > is nothing wrong in reporting something privately if there is even 
> > > > > > 1% possibility of it being a vulnerability. I had recently reported 
> > > > > > something to LND security team based on a closed issue on GitHub 
> > > > > > which eventually was not considered a vulnerability: 
> > > > > > https://github.com/lightningnetwork/lnd/issues/7449
> > > > > > 
> > > > > > In the CPU usage issue, maybe the users can run bitcoind with 
> > > > > > bigger mempool or try other things shared in the issue by everyone.
> > > > > > 
> > > > > > This isn't the first time either when vulnerability was reported 
> > > > > > publicly: 
> > > > > > https://gist.github.com/chjj/4ff628f3a0d42823a90edf47340f0db9 and 
> > > > > > this was even exploited on mainnet which affected some projects.
> > > > > > 
> > > > > > This email is just a request to consider the impact of any 
> > > > > > vulnerability if gets exploited could affect lot of things. Even 
> > > > > > the projects with no financial activity involved follow better 
> > > > > > practices.
> > > > > > 
> > > > > > /dev/fd0
> > > > > > floppy disk guy
> > > > > > 
> > > > > > Sent with Proton Mail secure email.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Transaction Relay over Nostr

[alicexbt via bitcoin-dev]

Hi Joost,

Transaction relay over nostr sounds interesting. I have 2 suggestions:

- Transactions could be encrypted when published as nostr events initially 
except size, fee rate and offer. This can be used by different clients to show 
them as external mempool with transactions sorted by fee rate without affecting 
privacy of users.
- Mining pools will be incentivized to include these transaction in their 
blocks if they are using a higher fee rate compared to transactions in normal 
mempool used by bitcoin nodes or there is a mechanism to accept published 
offers, NIP4 is used to privately coordinate everything between user and pool. 
User can lock some sats in a 2of2 multisig and release it to mining pool on 
confirmation.

/dev/fd0
floppy disk guy

Sent with Proton Mail secure email.

--- Original Message ---
On Tuesday, May 23rd, 2023 at 12:49 PM, Joost Jager via bitcoin-dev 
 wrote:


> Hi,
> 
> 
> 
> I write to get your thoughts on an alternative approach for Bitcoin 
> transaction relay, addressing some of the limitations in the current 
> peer-to-peer transaction relay system. To the best of my knowledge, the 
> credit for the original concept goes to Ben Carman. I felt it would be 
> beneficial to share the idea on this list to garner wider perspectives and 
> feedback.
> 
> 
> 
> The existing peer-to-peer (P2P) transaction relay system comes with a set of 
> limitations that may negatively impact applications, notably those like 
> Lightning that make extensive use of pre-signed transactions. A key 
> limitation lies in the system's inability to relay transaction packages. This 
> constraint can lead to HTLCs expiring before being swept, thereby risking 
> fund losses. In addition, the P2P system falls short in supporting 
> non-standard transactions, despite an established demand for such 
> transactions in the marketplace.
> 
> 
> 
> Nostr, an open and decentralized network of relays for public and ephemeral 
> messages between pseudonymous entities, could help address these 
> shortcomings. With the standards defined in NIP-89 [1], it becomes possible 
> to broadcast arbitrary Bitcoin transaction packages, overcoming one of the 
> key hurdles in the current relay system.
> 
> 
> 
> In this proposed alternative relay mechanism, miners would listen for these 
> broadcasted transaction packages and insert the packages into their local 
> mempool. They can take advantage of the `submitpackage` RPC, limited to safe 
> topologies only - specifically child and direct parents, tree only [2]. This 
> feature could serve as an interim solution for package relay until it becomes 
> available through the traditional P2P method.
> 
> 
> 
> A notable advantage of this approach is that it delegates the responsibility 
> of dealing with Denial-of-Service (DoS) threats to the relays themselves. 
> They could, for example, require a payment to mitigate such concerns. There 
> are in fact paid nostr relays already in operation. This partitioning would 
> result in a clear separation between the Bitcoin transaction layer and DoS 
> protection, introducing more flexibility in the system and potentially 
> boosting its resilience.
> 
> 
> 
> Implementing Nostr as a relay mechanism also has the potential to democratize 
> access to miner mempools, thus leveling the playing field in the Bitcoin 
> network. In the current state, those with direct connections or certain 
> privileges can more readily submit transactions to miners, perhaps even 
> through means as informal as email.
> 
> 
> 
> I have been working on a prototype of this concept (based on [3]) and have 
> captured its workings in a demonstration video [4].
> 
> 
> 
> Joost
> 
> 
> 
> [1] https://github.com/nostr-protocol/nips/pull/476
> 
> [2] https://github.com/bitcoin/bitcoin/pull/27609#issuecomment-1544414801
> 
> [3] https://github.com/benthecarman/nostr-tx-broadcast
> 
> [4] https://twitter.com/joostjgr/status/1658487013237211155
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Coinjoin with less steps using ALL|ANYONECANPAY

[alicexbt via bitcoin-dev]

Hi Lucas,

> In some coinjoin implementations inputs are registered first because in that 
> way, if the user fails or refuses to sign the transaction the input is banned 
> and denial of service is made a bit more expensive, in the sense that an 
> attacker needs more and more utxos to keep the attack going.

DoS attacks are even possible in later stages of a coinjoin round. Example: 
Double spend inputs after signing

Inputs could be banned in second step if ALL|ANYONECANPAY sighash flag is used 
and outputs are registered initially.

/dev/fd0
floppy disk guy

Sent with Proton Mail secure email.

--- Original Message ---
On Tuesday, May 23rd, 2023 at 5:47 PM, Lucas Ontivero  
wrote:


> Hi all,
> In some coinjoin implementations inputs are registered first because in that 
> way, if the user fails or refuses to sign the transaction the input is banned 
> and denial of service is made a bit more expensive, in the sense that an 
> attacker needs more and more utxos to keep the attack going.
> 
> Your proposal can work if you find an alternative mechanism for mitigating 
> the DoS attacks or when DoS attacks are not a problem (I can imagine there 
> are scenarios where it is not really important).
> Best
> - Lucas
> 
> 
> 
> On Mon, May 22, 2023 at 7:53 PM Ben Carman via bitcoin-dev 
>  wrote:
> 
> > The problem with using ALL|ANYONECANPAY is that you cannot verify 
> > beforehand that the other inputs are the inputs you want added to the 
> > transaction.
> > 
> > Some examples of bad things that could happen:
> > 
> > 
> > -   Coordinator adds its own inputs, you still get your outputs but 
> > effectively paid fees for no privacy gain
> > -   The inputs added could be paying at a lower fee rate than expected, 
> > causing the tx to take longer than what you paid for
> > -   Different input types or amount are added so you no longer have the 
> > same uniformity across the inputs
> > -   (if you care) An input from a sanctioned address is added, causing you 
> > to get "tainted" coins.
> > 
> > 
> > This is the code in ln-vortex that verifies the psbt on the client side if 
> > you are curious
> > 
> > https://github.com/ln-vortex/ln-vortex/blob/master/client/src/main/scala/com/lnvortex/client/VortexClient.scala#L616
> > 
> > 
> > Best,
> > 
> > benthecarman
> > 
> > 
> > 
> > From: bitcoin-dev  on behalf 
> > of alicexbt via bitcoin-dev 
> > Sent: Monday, May 22, 2023 7:51 AM
> > To: Bitcoin Protocol Discussion 
> > Subject: [bitcoin-dev] Coinjoin with less steps using ALL|ANYONECANPAY
> > 
> > Hi Bitcoin Developers,
> > 
> > I recently experimented with different sighash flags, PSBTs and realized 
> > ALL|ANYONECANPAY could be used to reduce some steps in coinjoin.
> > 
> > Steps:
> > 
> > - Register outputs.
> > - One user creates a signed PSBT with 1 input, all registered outputs and 
> > ALL|ANYONECANPAY sighash flag. Other participants keep adding their inputs 
> > to PSBT.
> > - Finalize and broadcast the transaction.
> > 
> > Proof of Concept (Aice and Bob): https://gitlab.com/-/snippets/2542297
> > 
> > Tx: 
> > https://mempool.space/testnet/tx/c6dd626591dca7e25bbd516f01b23171eb0f2b623471fcf8e073c87c1179c492
> > 
> > I plan to use this in joinstr if there are no major drawbacks and it can 
> > even be implemented by other coinjoin implementations.
> > 
> > /dev/fd0
> > floppy disk guy
> > 
> > Sent with Proton Mail secure email.
> > ___
> > 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 mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Coinjoin with less steps using ALL|ANYONECANPAY

[alicexbt via bitcoin-dev]

Hi Ben,

Thanks for the feedback.

> -   Coordinator adds its own inputs, you still get your outputs but 
> effectively paid fees for no privacy gain

What will be the incentive for a coordinator to add its inputs in coinjoin? Is 
this possible without ALL|ANYONECANPAY as well? Even if there is an incentive 
its unlikely to work in joinstr as there is no centralized coordinator. 
Multiple common relays are used to coordinate a coinjoin round.

> -   The inputs added could be paying at a lower fee rate than expected, 
> causing the tx to take longer than what you paid for
> -   Different input types or amount are added so you no longer have the same 
> uniformity across the inputs

> This is the code in ln-vortex that verifies the psbt on the client side if 
> you are curious
> 
> https://github.com/ln-vortex/ln-vortex/blob/master/client/src/main/scala/com/lnvortex/client/VortexClient.scala#L616

These 2 are important things and could be managed with client side validation 
by keeping min-max amounts for inputs in a round and disallow different types 
of inputs. Thanks for sharing the code that validates PSBT.

Joinstr will also use NIP38/48 channels for coinjoin rounds so that only 
participants in a coinjoin round are aware of details.

/dev/fd0
floppy disk guy

Sent with Proton Mail secure email.

--- Original Message ---
On Tuesday, May 23rd, 2023 at 4:21 AM, Ben Carman  wrote:


> The problem with using ALL|ANYONECANPAY is that you cannot verify beforehand 
> that the other inputs are the inputs you want added to the transaction.
> 
> Some examples of bad things that could happen:
> 
> 
> -   Coordinator adds its own inputs, you still get your outputs but 
> effectively paid fees for no privacy gain
> -   The inputs added could be paying at a lower fee rate than expected, 
> causing the tx to take longer than what you paid for
> -   Different input types or amount are added so you no longer have the same 
> uniformity across the inputs
> -   (if you care) An input from a sanctioned address is added, causing you to 
> get "tainted" coins.
> 
> 
> This is the code in ln-vortex that verifies the psbt on the client side if 
> you are curious
> 
> https://github.com/ln-vortex/ln-vortex/blob/master/client/src/main/scala/com/lnvortex/client/VortexClient.scala#L616
> 
> 
> Best,
> 
> benthecarman
> 
> 
> 
> From: bitcoin-dev  on behalf 
> of alicexbt via bitcoin-dev 
> Sent: Monday, May 22, 2023 7:51 AM
> To: Bitcoin Protocol Discussion 
> Subject: [bitcoin-dev] Coinjoin with less steps using ALL|ANYONECANPAY
> 
> Hi Bitcoin Developers,
> 
> I recently experimented with different sighash flags, PSBTs and realized 
> ALL|ANYONECANPAY could be used to reduce some steps in coinjoin.
> 
> Steps:
> 
> - Register outputs.
> - One user creates a signed PSBT with 1 input, all registered outputs and 
> ALL|ANYONECANPAY sighash flag. Other participants keep adding their inputs to 
> PSBT.
> - Finalize and broadcast the transaction.
> 
> Proof of Concept (Aice and Bob): https://gitlab.com/-/snippets/2542297
> 
> Tx: 
> https://mempool.space/testnet/tx/c6dd626591dca7e25bbd516f01b23171eb0f2b623471fcf8e073c87c1179c492
> 
> I plan to use this in joinstr if there are no major drawbacks and it can even 
> be implemented by other coinjoin implementations.
> 
> /dev/fd0
> floppy disk guy
> 
> Sent with Proton Mail secure email.
> ___
> 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] Responsible disclosures and Bitcoin development

[alicexbt via bitcoin-dev]

Hi Michael,

> Now that's not to say you may not have a point about better documentation and 
> guidance on what should go through the vulnerability reporting process and 
> what shouldn't.

Yes, this can be improved.

> Or even that this particular issue could ultimately end up being classed a 
> CVE.

It has been assigned CVE-2023-33297


/dev/fd0
floppy disk guy

Sent with Proton Mail secure email.

--- Original Message ---
On Wednesday, May 17th, 2023 at 6:14 PM, Michael Folkson 
 wrote:


> Hi alicexbt
> 
> "Open source" has the word "open" in it. Pushing everything into closed, 
> private channels of communication and select groups of individuals is what 
> I've been trying to push back upon. As I said in my initial response "it 
> doesn't scale for all bug reports and investigations to go through this tiny 
> funnel" though "there are clearly examples where the process is critically 
> needed".
> 
> 
> Now that's not to say you may not have a point about better documentation and 
> guidance on what should go through the vulnerability reporting process and 
> what shouldn't. Or even that this particular issue could ultimately end up 
> being classed a CVE. But rather than merely complaining and putting "open 
> source" into quote marks perhaps suggest what class of bug reports should go 
> through the tiny funnel and what shouldn't. Unless you think everything 
> should go through the funnel in which case you are advocating for less 
> openness whilst simultaneously complaining it isn't "open source". Square 
> that circle.
> 
> 
> Thanks
> Michael
> 
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
> 
> 
> Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
> 
> 
> --- Original Message ---
> On Tuesday, May 16th, 2023 at 23:39, alicexbt  wrote:
> 
> 
> > Hi Michael,
> > 
> > A disagreement and some thoughts already shared in an email although its 
> > not clear to some "open source" devs:
> > 
> > Impact of this vulnerability:
> > 
> > - Denial of Service
> > - Stale blocks affecting mining pool revenue
> > 
> > Why it should have been reported privately to secur...@bitcoincore.org, 
> > even if initially found affecting only debug build?
> > 
> > 
> > Example: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3129
> > 
> > 
> > CVE is a different process and I am aware of it. It would be good for 
> > certain developers in the core team to reflect on their own approach to 
> > security, regardless of whether their work receives CVE recognition or not.
> > 
> > /dev/fd0
> > floppy disk guy
> > 
> > 
> > Sent with Proton Mail secure email.
> > 
> > --- Original Message ---
> > On Friday, May 12th, 2023 at 1:14 AM, Michael Folkson 
> >  wrote:
> > 
> > 
> > > Hi alicexbt
> > > 
> > > The vulnerability reporting process requires communication and resolution 
> > > via a small group of individuals [0] rather than through open 
> > > collaboration between any contributors on the repo. There are clearly 
> > > examples where the process is critically needed, the most obvious past 
> > > example being the 2018 inflation bug [1]. However, it doesn't scale for 
> > > all bug reports and investigations to go through this tiny funnel. For an 
> > > issue that isn't going to result in loss of onchain funds and doesn't 
> > > seem to present a systemic issue (e.g. network DoS attack, inflation bug) 
> > > I'm of the view that opening a public issue was appropriate in this case 
> > > especially as the issue initially assumed it was only impacting nodes 
> > > running in debug mode (not a mode a node in production is likely to be 
> > > running in).
> > > 
> > > An interesting question though and I'm certainly happy to be corrected by 
> > > those who have been investigating the issue. Some delicate trade-offs 
> > > involved including understanding and resolving the issue faster through 
> > > wider collaboration versus keeping knowledge of the issue within a 
> > > smaller group.
> > > 
> > > Thanks
> > > Michael
> > > 
> > > [0]: https://github.com/bitcoin/bitcoin/blob/master/SECURITY.md
> > > [1]: https://bitcoincore.org/en/2018/09/20/notice/
> > > 
> > > --
> > > Michael Folkson
> > > Email: micha

[bitcoin-dev] Coinjoin with less steps using ALL|ANYONECANPAY

[alicexbt via bitcoin-dev]

Hi Bitcoin Developers,

I recently experimented with different sighash flags, PSBTs and realized 
ALL|ANYONECANPAY could be used to reduce some steps in coinjoin.

Steps:

- Register outputs.
- One user creates a signed PSBT with 1 input, all registered outputs and 
ALL|ANYONECANPAY sighash flag. Other participants keep adding their inputs to 
PSBT.
- Finalize and broadcast the transaction.

Proof of Concept (Aice and Bob): https://gitlab.com/-/snippets/2542297

Tx: 
https://mempool.space/testnet/tx/c6dd626591dca7e25bbd516f01b23171eb0f2b623471fcf8e073c87c1179c492

I plan to use this in joinstr if there are no major drawbacks and it can even 
be implemented by other coinjoin implementations. 

/dev/fd0
floppy disk guy

Sent with Proton Mail secure email.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Responsible disclosures and Bitcoin development

[alicexbt via bitcoin-dev]

Hi Michael,

A disagreement and some thoughts already shared in an email although its not 
clear to some "open source" devs:

Impact of this vulnerability:

- Denial of Service
- Stale blocks affecting mining pool revenue
Why it should have been reported privately to secur...@bitcoincore.org, even if 
initially found affecting only debug build?

Example: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3129

CVE is a different process and I am aware of it. It would be good for certain 
developers in the core team to reflect on their own approach to security, 
regardless of whether their work receives CVE recognition or not.

/dev/fd0
floppy disk guy

Sent with [Proton Mail](https://proton.me/) secure email.

--- Original Message ---
On Friday, May 12th, 2023 at 1:14 AM, Michael Folkson 
 wrote:

> Hi alicexbt
>
> The vulnerability reporting process requires communication and resolution via 
> a small group of individuals [0] rather than through open collaboration 
> between any contributors on the repo. There are clearly examples where the 
> process is critically needed, the most obvious past example being the 2018 
> inflation bug [1]. However, it doesn't scale for all bug reports and 
> investigations to go through this tiny funnel. For an issue that isn't going 
> to result in loss of onchain funds and doesn't seem to present a systemic 
> issue (e.g. network DoS attack, inflation bug) I'm of the view that opening a 
> public issue was appropriate in this case especially as the issue initially 
> assumed it was only impacting nodes running in debug mode (not a mode a node 
> in production is likely to be running in).
>
> An interesting question though and I'm certainly happy to be corrected by 
> those who have been investigating the issue. Some delicate trade-offs 
> involved including understanding and resolving the issue faster through wider 
> collaboration versus keeping knowledge of the issue within a smaller group.
>
> Thanks
> Michael
>
> [0]: https://github.com/bitcoin/bitcoin/blob/master/SECURITY.md
> [1]: https://bitcoincore.org/en/2018/09/20/notice/
>
> --
> Michael Folkson
> Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
> GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
>
> Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
>
> --- Original Message ---
> On Tuesday, May 9th, 2023 at 03:47, alicexbt via bitcoin-dev 
>  wrote:
>
>> Hi Bitcoin Developers,
>>
>> There is an open issue in bitcoin core repository which was created last 
>> week: https://github.com/bitcoin/bitcoin/issues/27586
>>
>> I think this should have been reported privately as vulnerability instead of 
>> creating a GitHub issue even if it worked only in debug mode. Some users in 
>> the comments have also experienced similar issues without debug build used 
>> for bitcoind. I have not noticed any decline in the number of listening 
>> nodes on bitnodes.io in last 24 hours so I am assuming this is not an issue 
>> with majority of bitcoin core nodes. However, things could have been worse 
>> and there is nothing wrong in reporting something privately if there is even 
>> 1% possibility of it being a vulnerability. I had recently reported 
>> something to LND security team based on a closed issue on GitHub which 
>> eventually was not considered a vulnerability: 
>> https://github.com/lightningnetwork/lnd/issues/7449
>>
>> In the CPU usage issue, maybe the users can run bitcoind with bigger mempool 
>> or try other things shared in the issue by everyone.
>>
>> This isn't the first time either when vulnerability was reported publicly: 
>> https://gist.github.com/chjj/4ff628f3a0d42823a90edf47340f0db9 and this was 
>> even exploited on mainnet which affected some projects.
>>
>> This email is just a request to consider the impact of any vulnerability if 
>> gets exploited could affect lot of things. Even the projects with no 
>> financial activity involved follow better practices.
>>
>> /dev/fd0
>> floppy disk guy
>>
>> Sent with [Proton Mail](https://proton.me/) secure email.___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions

[alicexbt via bitcoin-dev]

Hi Andrew,

> We can take a look at how previous maintainers were added to see how this has 
> played out in the past.

Can we learn something from past?

Bitcoin's initial release was in 2009 with one developer and few others 
experimenting with it. It is considered decentralized in 2023 however we have 
99% of nodes using bitcoin core, 5 developers deciding what's merged or not and 
this includes some trying to implement their ideas without soft fork using 
mempool policies.

We need better process to add maintainers. I am disappointed with the way last 
last pull request was merged. It says more about maintainers and leader Michael 
Ford. If you are so scared about opinions on a pull request why not just make 
him maintainer without pull request?

Maybe you will understand this if your PR to add maintainer was kept open for 4 
months.

/dev/fd0
floppy disk

Sent with [Proton Mail](https://proton.me/) secure email.

--- Original Message ---
On Thursday, May 11th, 2023 at 2:54 AM, Andrew Chow via bitcoin-dev 
 wrote:

> On 05/07/23 03:03 AM, Michael Folkson via bitcoin-dev wrote:
>
>> The decision process for adding a new maintainer was according to the IRC 
>> meeting that the maintainers decided privately there was a need for a 
>> maintainer “who understood our interfaces and modularization efforts well” 
>> and that ryanofsky was a “good fit for that”. I don’t know whether this was 
>> decided in a private IRC channel or was decided at the recent in person Core 
>> Dev meeting. Regardless, many have had no input into the discussion on what 
>> kind of maintainer the project needs going forward and it seems the 
>> maintainers do not want to discuss that aspect of the decision.
>
> Since the project began, the decision to seek out and then add a maintainer 
> has always been made by existing maintainers. When the maintainers feel that 
> there is a need for additional maintainers, they may have an open call for 
> volunteers, or may have a candidate already in mind and suggest that specific 
> person for maintainership. Contributors generally are not consulted in the 
> decision to seek a new maintainer as they would not know whether there are 
> things that are being overlooked or that there is maintainership load that 
> needs to be distributed. Even so, it wouldn't be appropriate to add a 
> maintainer if many contributors disagreed with it, just as with any other PR.
>
> We can take a look at how previous maintainers were added to see how this has 
> played out in the past. I think our modern concept of maintainers with 
> nominal scopes began in 2015 with Jonas Schnelli. Both Jonas Schnelli and 
> Marco Falke were simply announced by Wladimir. There was no public 
> discussion, and some IRC logs refer to private emails between the them and 
> the current maintainers at that time. After that, meshcollider was added as a 
> maintainer after a public "call for maintainers" where a recurring topic for 
> a while was finding a maintainer for the wallet. He had volunteered to do it 
> by contacting Wladimir privately before it was discussed during an IRC 
> meeting and then on Github. Fanquake was added as a maintainer during a 
> CoreDev event in Amsterdam during a discussion initiated and led by the 
> maintainers. This was also "private" insofar as the discussion was limited to 
> those in attendance, although there was some opportunity for public 
> discussion in the PR opened on Github. For myself, it was also initially 
> private as I messaged Wladimir to volunteer for it after meshcollider stepped 
> down. There was some discussion on IRC and on Github, but it was also obvious 
> that many already expected me to be the wallet maintainer after meshcollider. 
> Hebasto was added with basically no fanfare or discussion - the only mention 
> I can find is the PR itself. My understanding is that the maintainers asked 
> him he wanted to do it before the PR was opened. Glozow was nominated to be a 
> maintainer by some of the current maintainers, and her nomination was really 
> the first time that there was significant public discussion about it.
>
> Of the past 7 maintainer additions, 5 were nominations/announcements from the 
> current maintainers, one was volunteering following an actual "call for 
> maintainer", and one was an obvious successor. It's obvious and common sense 
> that the maintainers decide when they need help shouldering the load, and 
> then find somebody to help them. There was and always will be some level of 
> private communication prior to any public announcement of the nomination or 
> volunteering of a maintainer. It doesn't make sense to blindside somebody 
> with a nomination without talking to them beforehand. The fact that most of 
> these were non-controversial speaks to how well the maintainers were 
> considering their nominations before publicly announcing them.
>
> It's also clear that we have been moving towards more open discussion about 
> maintainership

[bitcoin-dev] Responsible disclosures and Bitcoin development

[alicexbt via bitcoin-dev]

Hi Bitcoin Developers,

There is an open issue in bitcoin core repository which was created last week: 
https://github.com/bitcoin/bitcoin/issues/27586

I think this should have been reported privately as vulnerability instead of 
creating a GitHub issue even if it worked only in debug mode. Some users in the 
comments have also experienced similar issues without debug build used for 
bitcoind. I have not noticed any decline in the number of listening nodes on 
bitnodes.io in last 24 hours so I am assuming this is not an issue with 
majority of bitcoin core nodes. However, things could have been worse and there 
is nothing wrong in reporting something privately if there is even 1% 
possibility of it being a vulnerability. I had recently reported something to 
LND security team based on a closed issue on GitHub which eventually was not 
considered a vulnerability: https://github.com/lightningnetwork/lnd/issues/7449

In the CPU usage issue, maybe the users can run bitcoind with bigger mempool or 
try other things shared in the issue by everyone.

This isn't the first time either when vulnerability was reported publicly: 
https://gist.github.com/chjj/4ff628f3a0d42823a90edf47340f0db9 and this was even 
exploited on mainnet which affected some projects.

This email is just a request to consider the impact of any vulnerability if 
gets exploited could affect lot of things. Even the projects with no financial 
activity involved follow better practices.

/dev/fd0
floppy disk guy

Sent with [Proton Mail](https://proton.me/) secure email.___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions

[alicexbt via bitcoin-dev]

Hi Michael,

I will share something even though you didn't let me write things on several 
occasions on github, twitter etc.

Try this:

- As Gloria said (respect people you don't like and shared something against), 
create a competition for Brink. Fund bitcoin developers.
- Do more reviews personally and devs you train even if they are neglected.
- Acknowledge some reviewer know more than you. Try to learn and test things.
- After some time you will achieve the power you crave.

Its not possible to satisfy everyone even if you were bitcoin core maintainer 
now, some people would have issues. Closing a pull request hurt more so I 
respect them if they kept open something.

Note: Do not disrespect people who are new and say something. Do not try to 
harass them. Do not try to be boss.

/dev/fd0
floppy disk guy

Sent with Proton Mail secure email.

--- Original Message ---
On Wednesday, April 19th, 2023 at 7:03 PM, Michael Folkson 
 wrote:


> Hi alicexbt
> 
> > I don't think commentary is required for each pull request that gets merged 
> > with enough reviews, ACKs and no controversy.
> 
> 
> The problem is defining what is "enough". "Enough" is determined by the 
> quality of the review, the expertise of the reviewer(s), the complexity of 
> the pull request and most importantly what risks a merge of the pull request 
> poses. When there is zero communication on merge decisions (both merging and 
> not merging over a long period of time) it creates frustration and worse 
> vacuums and soft fork activation chaos. It is a complete black box. The vast 
> majority of merge decisions are uncontroversial but it would still be nice to 
> have a comment saying something like:
> 
> "This pull request only has 2 ACKs but it is low risk, relatively simple and 
> is unlikely to be reviewed by anybody else in the near term"
> 
> "This pull request is a consensus change, extremely high risk and is unlikely 
> to be merged in the near term"
> 
> On the rare occasions when merge decisions are controversial communication 
> becomes a lot more important. If some maintainers aren't responsive on IRC 
> and refuse to discuss merge decisions what can we expect in future? We wake 
> up one day, a contentious consensus change has been merged with little review 
> in advance of a release window and the maintainer won't discuss why they have 
> merged it. This isn't a toy anymore, it is supporting hundreds of billions of 
> dollars of value and could end up supporting a lot more. It is surely 
> completely unreasonable to let maintainers merge or not merge whatever they 
> like with no explanation and no willingness to discuss their merge decisions.
> 
> > So I'll add that if you wish to have more decentralization in Bitcoin Core 
> > funding, you can start by creating a nonprofit, gathering donations, and 
> > funding somebody who works on Bitcoin Core."
> 
> 
> As I responded on the pull request if any long term contributor from this 
> alternative nonprofit is blocked from being a maintainer and current 
> maintainers refuse to discuss merge decisions it is irrelevant. To contribute 
> you need a maintainer to merge your pull request(s) and to spend your review 
> time wisely you need to know what pull request(s) could viably be merged by a 
> maintainer. Otherwise you're just wasting your time. We not only have opacity 
> on merge decisions for normal pull requests (e.g. code) we also now have 
> opacity on decisions for the addition of new maintainers. I was always under 
> the impression that any long term contributor who demonstrated over time that 
> they were sufficiently competent, qualified and able to contribute both 
> through opening pull requests and reviewing other people's pull requests 
> could become a maintainer. To me and many others (until it was blocked by two 
> maintainers for 5 months) Vasil met this criteria. This not only impacts 
> Vasil's and others' commitment to the project but it impacts what pull 
> requests are ultimately reviewed and merged. What is the point of spending 
> time opening or reviewing a pull request if the current maintainers won't 
> look at it or are unqualified to review it and hence won't merge it?
> 
> Gloria's advice effectively boils down to spend months setting up a 
> non-profit, spend years becoming a long term contributor to the project and 
> then you can have the honor of being blocked from becoming a maintainer and 
> have your contributions stunted by the current maintainers with no recourse 
> or ability to discuss their merge decisions. So yeah thanks for repeating 
> that advice but I'm sure most would rather pass and do something else.
> 
> Thanks
> Michael
> 
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
> 
> 
> --- Original Message ---
> On Wednesday, April 19th, 2023 at 13:24, alicexbt alice...@protonmail.com 
> wrote:
> 
> 
> 
> > Hi Michael

Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions

[alicexbt via bitcoin-dev]

Hi Michael,

I was initially sad about the politics in Vasil's pull request, written about 
it and also tried to document the process. Still think he deserves to be a 
maintainer. Although I have some counter arguments:

> Maintainers merge a pull request and provide no commentary on why they’ve 
> merged it.

I don't think commentary is required for each pull request that gets merged 
with enough reviews, ACKs and no controversy.

> Maintainers leave a pull request with many ACKs and few (if any) NACKs for 
> months and provide no commentary on why they haven't merged it

This could be considered normal in pull requests that involve code changes.

> The difference between say previous maintainers like Wladimir and some of the 
> current maintainers is that previous maintainers were extremely responsive on 
> IRC.

Unfair to expect every human to behave the same or work similarly. Sometimes 
the unresponsiveness could be to avoid controversies and heated debates that go 
off-topic.

> One farcical recent example [0] was the pull request to add Vasil Dimov as a 
> maintainer where despite many ACKs from other maintainers and other long term 
> contributors two maintainers (fanquake and Gloria) refused to discuss it on 
> the pull request or on IRC. It took almost 5 months for Gloria to comment on 
> the pull request despite many requests from me on the PR and on IRC. I even 
> requested that they attend the weekly Core Dev IRC meeting to discuss it 
> which they didn’t attend.

- Maintainers should be free to avoid involvement in a pull request. As long as 
a subset of maintainers have an opinion on the pull request, things should be 
fine. 
- I agree with Gloria's [comment][0]: "I had not NACKed this either because my 
opinion could change over time, NACKs are sometimes needlessly interpreted as 
personal attacks, and Brink has been antagonized on Twitter each time multiple 
grantees have similar opinions about this. So I'll add that if you wish to have 
more decentralization in Bitcoin Core funding, you can start by creating a 
nonprofit, gathering donations, and funding somebody who works on Bitcoin 
Core." Last part of this comment also solves the problem shared in other thread 
related to new bitcoin implementation. Brink needs some competition and bitcoin 
core needs more reviewers. 
- I also agree with Andrew's [comment][1]: "frankly, I think opinions aren't 
being shared because of potential backlash from aggressive users such as 
yourself and bytes144"

> Maintainers and long term contributors (if they commented at all) were gently 
> enthusiastic (Concept ACKing etc) without ACKing that it was ready to merge. 
> A long term observer of the Core repo would have known that it wasn’t ready 
> to merge or ready to attempt to activate (especially given it was a consensus 
> change) but a casual observer would have only seen Concept ACKs and ACKs with 
> 3 stray NACKs. Many of these casual observers inflated the numbers on the 
> utxos.org site [4] signalling support for a soft fork activation attempt.

- I don't see anything wrong with sharing honest opinion if someone agrees with 
the concept. It does not make a pull request ready to get merged.
- utxos.org is an external site maintained by Jeremy with opinions on BIP 119. 
Everyone is free to maintain such lists and I think you had also created one as 
GitHub gist.

>  I will probably write about bitcoin-inquisition/default signet in a future 
> email as I do think the perception that it is “the one and only” staging 
> ground for consensus changes is dangerous [6] if the maintainer(s) on that 
> project have the same inclinations as a subset of the Core maintainers.

This perception (if exists) can be killed by creating a custom signet, 
maintaining it differently, get more reviews, testing and share details with 
community regularly.

/dev/fd0
floppy disk guy

[0]: https://github.com/bitcoin/bitcoin/pull/25871#issuecomment-1381654564
[1]: https://bitcoin-irc.chaincode.com/bitcoin-core-dev/2023-01-12#883748


Sent with Proton Mail secure email.

--- Original Message ---
On Tuesday, April 18th, 2023 at 6:10 PM, Michael Folkson via bitcoin-dev 
 wrote:


> Communication has been a challenge on Bitcoin Core for what I can tell the 
> entire history of the project. Maintainers merge a pull request and provide 
> no commentary on why they’ve merged it. Maintainers leave a pull request with 
> many ACKs and few (if any) NACKs for months and provide no commentary on why 
> they haven't merged it. I can only speculate on why and it probably depends 
> on the individual maintainer. Sometimes it will be poor communication skills, 
> sometimes it will be a desire to avoid accountability, sometimes it will be 
> fear of unreasonable and spiteful legal action if they mistakenly merge a 
> pull request that ends up containing a bug. But search through the pull 
> requests on Bitcoin Core and you will rarely see a rationale for a merge 
> decision. The

[bitcoin-dev] Bitcoin fungibility and inscribed sats

[alicexbt via bitcoin-dev]

Hi Steve and Bitcoin Developers,

I have created a new thread as requested by one of the developers. I respect 
him and the readers of this list.

> "want bitcoin to be money and money means different things for people in
this world"

> I think we can all agree that a property of money is fungibility, and by
its very definition NFTs are not fungible and thus not money.

Inscriptions do not affect fungibility of bitcoin:

- There is no token standard being used. These are just sats being considered 
as inscription in an external protocol or explorer. Bitcoin nodes do not 
consider them as something special.
- Users can always sell those inscribed sats or UTXO as normal bitcoin on bisq 
or any exchange.
- They can use different amounts for it using tools like 
https://raritygarden.inscribetheplanet.com/ which is created by super testnet 
who is active dev in bitcoin and ln.
- Inscribed sats are different from Ethereum tokens because they will never go 
to zero and you can always consolidate lot of them to use as normal bitcoin.

Bitcoin fungibility is anyways debatable and I cannot change anything about it 
even though working on a coinjoin implmentation as some post mix UTXOs are 
censored on some exchanges and its easy to identify them. Some coinjoin 
implementation themselves work with chain analysis companies to censor inputs 
used for rounds.

Ordinals theory is a parallel universe in which some users believe in and they 
have been trying to learn how bitcoin works. Example: I did call with someone 
this evening to explain how PSBT and multisig works who never used bitcoin 
before

Developers are interested to build things and they have tried to create BIP, 
DEX, look for libraries, ask questions, projects implementing PSBT etc.

I do not live in first world country and do not attend bitdevs but always 
wanted bitcoin to be here. I have tried my best but failed. Please let people 
do what they want with bitcoin without changing consensus rules. It will help 
Bitcoin.

/dev/fd0
floppy disk guy


Sent with Proton Mail secure email.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP for OP_VAULT

[alicexbt via bitcoin-dev]

Hi Zac,

> Regarding “Fees paid: 150 BTC” (uh, *citation needed*):

https://dune.com/queries/2008613/3326984

> Your other arguments are nonsensical so excuse me for ignoring them.

There were zero browser extensions that could sign PSBT to be used in different 
bitcoin projects that have web interface earlier. Now there are several open 
source extensions that could be used to sign PSBT. If such development and 
interest by developers from other chains to build things on bitcoin makes no 
sense to you that there is nothing much to debate here.

Humans have inscribed things on money since thousands of years when bitcoin 
didn't even exist. Trying to fight this and going against market wont work.

I do not agree with other things mentioned in your email.

/dev/fd0
floppy disk guy

Sent with Proton Mail secure email.

--- Original Message ---
On Thursday, March 30th, 2023 at 4:09 PM, Zac Greenwood  
wrote:


> Hi alicexbtc,
> 
> Under no circumstance should Bitcoin add any functionality intended to 
> support private businesses that rely on on-chain storage for their business 
> model.
> 
> Regarding “Fees paid: 150 BTC” (uh, *citation needed*):
> 
> To optimize for profitability a business would generally attempt to operate 
> using zero- or low-fee transactions. Therefore they tend to contribute 
> comparatively little fees but are depriving public use of these cheap 
> transactions. Worse, they exert a constant upward pressure on fee levels, 
> making it more expensive for everyone else to transact.
> 
> Unlike miners, node operators do not receive any compensation. They however 
> incur additional cost for bandwidth, electricity and processing time to not 
> only support some current business but all businesses in the past that ever 
> tried to turn a profit at their expense, so also after such business failed 
> and has been long gone. They foot the bill.
> 
> Lastly, I don’t believe there is any value in having for instance Ordinals 
> spam the blockchain with images of wojaks, bored apes and other crap but 
> perhaps you wish to clarify why this might be something to be “excited about”.
> 
> Your other arguments are nonsensical so excuse me for ignoring them.
> 
> 
> Zac
> 
> 
> On Thu, 30 Mar 2023 at 03:57, alicexbt  wrote:
> 
> > Hi Zac,
> > 
> > Let me share what those parasites achieved:
> > 
> > - Fees paid: 150 BTC
> > - Lot of users and developers trying bitcoin that either never tried or 
> > gave up early in 2013-15
> > - Mempools of nodes of being busy on weekends and got lots of transactions
> > - PSBT became cool and application devs are trying their best to use it in 
> > different ways
> > - Some developers exploring taproot and multisig
> > - AJ shared things how covenants could help in fair, non-custodial, 
> > on-chain auction of ordinals that is MEV resistant although I had shared it 
> > earlier which involves more steps: 
> > https://twitter.com/144bytes/status/1634368411760476161
> > - Investors exploring about funding projects
> > - Bitcoin more than Bitcoin and people excited about it
> > 
> > We can have difference of opinion, however I want bitcoin to be money and 
> > money means different things for people in this world. Please respect that 
> > else it will become like Linux, something used by 1% of world.
> > 
> > /dev/fd0
> > floppy disk guy
> > 
> > Sent with Proton Mail secure email.
> > 
> > --- Original Message ---
> > On Wednesday, March 29th, 2023 at 12:40 PM, Zac Greenwood via bitcoin-dev 
> >  wrote:
> > 
> > 
> > > I’m not sure why any effort should be spent on theorizing how new opcodes 
> > > might be used to facilitate parasitical use cases of the blockchain.
> > >
> > > If anything, business models relying on the ability to abuse the 
> > > blockchain as a data store must be made less feasible, not more.
> > >
> > > Zac
> > >
> > >
> > > On Fri, 24 Mar 2023 at 20:10, Anthony Towns via bitcoin-dev 
> > >  wrote:
> > >
> > > > On Tue, Mar 07, 2023 at 10:45:34PM +1000, Anthony Towns via bitcoin-dev 
> > > > wrote:
> > > > > I think there are perhaps four opcodes that are interesting in this 
> > > > > class:
> > > > >
> > > > > idx sPK OP_FORWARD_TARGET
> > > > > -- sends the value to a particular output (given by idx), and
> > > > > requires that output have a particular scriptPubKey (given
> > > > > by sPK).
> > > > >
> > > > > idx [...] n script OP_FORWARD_LEAF_UPDATE
> > > > > -- sends the value to a particular output (given by idx), and
> > > > > requires that output to have almost the same scriptPubKey as this
> > > > > input, _except_ that the current leaf is replaced by "script",
> > > > > with that script prefixed by "n" pushes (of values given by [...])
> > > > >
> > > > > idx OP_FORWARD_SELF
> > > > > -- sends the value to a particular output (given by idx), and
> > > > > requires that output to have the same scriptPubKey as this input
> > > > >
> > > > > amt OP_FORWARD_PARTIAL
> > > > > -- modifies the next OP_FORWARD_* opcode to 

Re: [bitcoin-dev] BIP for OP_VAULT

[alicexbt via bitcoin-dev]

Hi Zac,

Let me share what those parasites achieved:

- Fees paid: 150 BTC
- Lot of users and developers trying bitcoin that either never tried or gave up 
early in 2013-15
- Mempools of nodes of being busy on weekends and got lots of transactions
- PSBT became cool and application devs are trying their best to use it in 
different ways
- Some developers exploring taproot and multisig
- AJ shared things how covenants could help in fair, non-custodial, on-chain 
auction of ordinals that is MEV resistant although I had shared it earlier 
which involves more steps: 
https://twitter.com/144bytes/status/1634368411760476161
- Investors exploring about funding projects
- Bitcoin more than Bitcoin and people excited about it 

We can have difference of opinion, however I want bitcoin to be money and money 
means different things for people in this world. Please respect that else it 
will become like Linux, something used by 1% of world. 

/dev/fd0
floppy disk guy

Sent with Proton Mail secure email.

--- Original Message ---
On Wednesday, March 29th, 2023 at 12:40 PM, Zac Greenwood via bitcoin-dev 
 wrote:


> I’m not sure why any effort should be spent on theorizing how new opcodes 
> might be used to facilitate parasitical use cases of the blockchain.
>
> If anything, business models relying on the ability to abuse the blockchain 
> as a data store must be made less feasible, not more.
>
> Zac
>
>
> On Fri, 24 Mar 2023 at 20:10, Anthony Towns via bitcoin-dev 
>  wrote:
>
> > On Tue, Mar 07, 2023 at 10:45:34PM +1000, Anthony Towns via bitcoin-dev 
> > wrote:
> > > I think there are perhaps four opcodes that are interesting in this class:
> > >
> > > idx sPK OP_FORWARD_TARGET
> > > -- sends the value to a particular output (given by idx), and
> > > requires that output have a particular scriptPubKey (given
> > > by sPK).
> > >
> > > idx [...] n script OP_FORWARD_LEAF_UPDATE
> > > -- sends the value to a particular output (given by idx), and
> > > requires that output to have almost the same scriptPubKey as this
> > > input, _except_ that the current leaf is replaced by "script",
> > > with that script prefixed by "n" pushes (of values given by [...])
> > >
> > > idx OP_FORWARD_SELF
> > > -- sends the value to a particular output (given by idx), and
> > > requires that output to have the same scriptPubKey as this input
> > >
> > > amt OP_FORWARD_PARTIAL
> > > -- modifies the next OP_FORWARD_* opcode to only affect "amt",
> > > rather than the entire balance. opcodes after that affect the
> > > remaining balance, after "amt" has been subtracted. if "amt" is
> > > 0, the next OP_FORWARD_* becomes a no-op.
> >
> > The BIP 345 draft has been updated [0] [1] and now pretty much defines
> > OP_VAULT to have the behaviour specced for OP_FORWARD_LEAF_UPDATE above,
> > and OP_VAULT_RECOVER to behave as OP_FORWARD_TARGET above. Despite
> > that, for this email I'm going to continue using the OP_FORWARD_*
> > naming convention.
> >
> > Given the recent controversy over the Yuga labs ordinal auction [2],
> > perhaps it's interesting to consider that these proposed opcodes come
> > close to making it possible to do a fair, non-custodial, on-chain auction
> > of ordinals [3].
> >
> > The idea here is that you create a utxo on chain that contains the ordinal
> > in question, which commits to the address of the current leading bidder,
> > and can be spent in two ways:
> >
> > 1) it can be updated to a new bidder, if the bid is raised by at least
> > K satoshis, in which case the previous bidder is refunded their
> > bid; or,
> >
> > 2) if there have been no new bids for a day, the current high bidder
> > wins, and the ordinal is moved to their address, while the funds
> > from their winning bid are sent to the original vendor's address.
> >
> > I believe this can be implemented in script as follows,
> > assuming the opcodes OP_FORWARD_TARGET(OP_VAULT_RECOVER),
> > OP_FORWARD_LEAF_UPDATE(OP_VAULT), OP_FORWARD_PARTIAL (as specced above),
> > and OP_PUSHCURRENTINPUTINDEX (as implemented in liquid/elements [4])
> > are all available.
> >
> > First, figure out the parameters:
> >
> > * Set VENDOR to the scriptPubKey corresponding to the vendor's address.
> > * Set K to the minimum bid increment [5].
> > * Initially, set X equal to VENDOR.
> > * Initially, set V to just below the reserve price (V+K is the
> > minimum initial bid).
> >
> > Then construct the following script:
> >
> > [X] [V] [SSS] TOALT TOALT TOALT
> > 0 PUSHCURRENTINPUTINDEX EQUALVERIFY
> > DEPTH NOT IF
> > 0 1 FORWARD_PARTIAL
> > 0 FROMALT FORWARD_TARGET
> > 1 [VENDOR] FWD_TARGET
> > 144
> > ELSE
> > FROMALT SWAP TUCK FROMALT
> > [K] ADD GREATERTHANOREQUAL VERIFY
> > 1 SWAP FORWARD_TARGET
> > DUP FORWARD_PARTIAL
> > 0 ROT ROT
> > FROMALT DUP 3 SWAP FORWARD_LEAF_UPDATE
> > 0
> > ENDIF
> > CSV
> > 1ADD
> >
> > where "SSS" is a pushdata of the rest of the script ("TOALT TOALT TOALT
> > .. 1ADD").
> >
> > Finally, make that script the sole tapleaf, accompan

[bitcoin-dev] BIP: Trust minimized swaps using PSBT, SINGLE|ANYONECANPAY and nostr

[alicexbt via bitcoin-dev]

Hi Bitcoin Developers,

I have written a BIP that describes the process to swap inscriptions however 
there can be other use cases for it as well: 
https://gist.github.com/144bytes/a7deeb3f1740bc533a61fbcc1fe58d77

Feel free to share your opinion or feedback to improve the usage of PSBTs in 
swaps.

BIP: 2023-ordswap
Layer: Applications
Title: Trust minimized swaps using PSBTs
Author: /dev/fd0
Status: Draft
Created: 2023-03-02
License: Public Domain
  
  
### Introduction

This BIP describes a process for creating offers using PSBTs to swap 
inscriptions. It was originally shared by 
[Casey](https://github.com/casey/ord/issues/802). There are two other 
approaches (`joinpsbts` and coinswap) to swap inscriptions however they degrade 
the UX and use of SINGLE|ANYONECANPAY works better.

### Specification

[SINGLE|ANYONECANPAY](https://en.bitcoin.it/wiki/Contract#SIGHASH_flags) is 
used for creating a PSBT by the seller. It is signed and published as offer. 
Buyer updates the PSBT with appropriate inputs and outputs. Order of inputs and 
outputs in the PSBT is very important as wrong ordering can burn inscriptions. 
[Ordinal 
theory](https://docs.ordinals.com/faq.html?#how-does-ordinal-theory-work) uses 
an algorithm to determine how satoshis hop from the inputs of a transaction to 
its outputs.

### Protocol

Sequence diagram:

```mermaid
sequenceDiagram
Note right of Seller: Create and Sign PSBT
Seller->>+Nostr relays: Publish offer
Buyer->>+Nostr relays: Accept offer
Note left of Buyer: Add inputs, outputs, sign and broadcast PSBT
```

Seller:

- Create PSBT with inscription UTXO input and a new address with sell amount as 
output
- Sign PSBT
- Publish PSBT as defined in 
[NIP](https://github.com/orenyomtov/openordex/blob/main/NIP.md)

Buyer:

- Add new address as output in PSBT to receive inscription
- Create [dummy UTXO](https://i.imgur.com/8Rw3TFX.png) if not available in 
wallet (Less than 1000 sats)
- Add UTXO to pay seller and dummy UTXO as inputs in PSBT
- Sign and broadcast transaction. 

Example tx: 
https://mempool.space/signet/tx/ee7032f08ed18113c16ab8759d294c09f57492d8d255b5dbd16326df53bbdcac

This transaction has 3 inputs (dummy, inscription, UTXO used for paying seller) 
and 4 outputs (inscription, payment, new dummy for future, change)

Note: Openordex creates a dummy UTXO and reuses address if there is no dummy 
UTXO found for the address entered by buyer. Example: 
https://mempool.space/signet/tx/388942887f79358a1deba3aae86e97b982a923566b2ef2249eab42288efc5abf

Pseudocode or Implementation (2 functions used by openordex for creating PSBTs)

```js

async function generatePSBTListingInscriptionForSale(ordinalOutput, price, 
paymentAddress) {
let psbt = new bitcoin.Psbt({ network });

const [ordinalUtxoTxId, ordinalUtxoVout] = ordinalOutput.split(':')
const tx = bitcoin.Transaction.fromHex(await getTxHexById(ordinalUtxoTxId))
for (const output in tx.outs) {
try { tx.setWitness(output, []) } catch { }
}

psbt.addInput({
hash: ordinalUtxoTxId,
index: parseInt(ordinalUtxoVout),
nonWitnessUtxo: tx.toBuffer(),
// witnessUtxo: tx.outs[ordinalUtxoVout],
sighashType: bitcoin.Transaction.SIGHASH_SINGLE | 
bitcoin.Transaction.SIGHASH_ANYONECANPAY,
});

psbt.addOutput({
address: paymentAddress,
value: price,
});

return psbt.toBase64();
}

```

```js

generatePSBTBuyingInscription = async (payerAddress, receiverAddress, 
price, paymentUtxos, dummyUtxo) => {
const psbt = new bitcoin.Psbt({ network });
let totalValue = 0
let totalPaymentValue = 0

// Add dummy utxo input
const tx = bitcoin.Transaction.fromHex(await 
getTxHexById(dummyUtxo.txid))
for (const output in tx.outs) {
try { tx.setWitness(output, []) } catch { }
}
psbt.addInput({
hash: dummyUtxo.txid,
index: dummyUtxo.vout,
nonWitnessUtxo: tx.toBuffer(),
// witnessUtxo: tx.outs[dummyUtxo.vout],
});

// Add inscription output
psbt.addOutput({
address: receiverAddress,
value: dummyUtxo.value + Number(inscription['output value']),
});

// Add payer signed input
psbt.addInput({
...sellerSignedPsbt.data.globalMap.unsignedTx.tx.ins[0],
...sellerSignedPsbt.data.inputs[0]
})
// Add payer output
psbt.addOutput({
...sellerSignedPsbt.data.globalMap.unsignedTx.tx.outs[0],
})

// Add payment utxo inputs
for (const utxo of paymentUtxos) {
const tx = bitcoin.Transaction.fromHex(await 
getTxHexById(utxo.txid))
for (const output in tx.outs) {
try { tx.setWitness(output, []) } catch { }
}

psbt.addInput({
hash: utxo.txid,
index: utxo.v

Re: [bitcoin-dev] Testing censorship resistance of bitcoin p2p network

[alicexbt via bitcoin-dev]

, is 
> converting R-value of a signature into the Taproot address, and then checking 
> if a given commitment matches such key.
> 
> > I agree with Peter that, given that users have found ways to store 
> > arbitrary amounts of data on-chain if they really want, we might as well 
> > just make OP_RETURN a free-for-all.
> 
> 
> I think we should go in the opposite direction. Using OP_RETURN means that 
> all nodes will store such data. Using witness means that only witness nodes 
> will keep that. So, if it is already possible to have a node that cannot see 
> witness data, and still remain in the network, I think commitments should be 
> stored only by nodes that will enable them explicitly. So, from that point of 
> view, commitment is "a witness of a signature", it is additional information 
> that can be skipped if needed.
> 
> On 2023-02-13 14:08:21 user alicexbt via bitcoin-dev 
> bitcoin-dev@lists.linuxfoundation.org wrote:
> 
> > Hi Bitcoin Developers,
> 
> 
> There is a famous quote attributed to Evelyn Beatrice Hall in her biography 
> of Voltaire: "I disapprove of what you say, but I will defend to the death 
> your right to say it." I'm curious to know how many Bitcoin developers share 
> this sentiment.
> 
> Recently there was a lot of enthusiasm on social media to run bitcoin core 
> with a patch that would reject some transactions in mempool. Bitcoin Knots 
> already has an option to reject transactions that reuse addresses. What if 
> such practices become common and some projects that provide easy to use node 
> software start censoring transactions? How would government agencies take 
> advantage of this whole drama?
> 
> I understand it is difficult to censor different type of transaction because 
> there will be some nodes relaying them and miners including in blocks. It is 
> still important to discuss this and different ways to test censorship 
> resistance.
> 
> - Peter Todd had written a [blog post][1] in which counting number of INVs 
> (step 5,6,7 and 8) helps in testing if your transactions are getting relayed 
> by the connected peers.
> - I had tried broadcasting transaction to specific nodes using [libbtc][2]. 
> Based on my understanding it uses GETDATA to confirm your transaction was 
> seen on other nodes after broadcasting.
> 
> What would an ideal tool for testing censorship resistance look like?
> 
> - Allows user to construct different types of transactions that might be 
> considered "bad" by some people. Example: OFAC address in output, 
> Inscription, OP_RETURN, Address reuse etc.
> - Option to broadcast transaction to specific nodes
> - Verify if the transaction was relayed successfully or rejected
> - Ban such peers using [setban][3] RPC as it would increase the probability 
> of tx getting propagated to miners
> 
> There was even some discussion about an [external mempool][4] that could be 
> used for non-standard transactions. It could also help in avoiding censorship 
> in some cases. I welcome your thoughts and feedback on this topic.
> 
> 0: https://gist.github.com/luke-jr/4c022839584020444915c84bdd825831
> [1]: https://petertodd.org/2022/bitcoin-core-nodes-running-fullrbf
> [2]: https://twitter.com/144bytes/status/1574225052240777216
> [3]: https://bitcoincore.org/en/doc/24.0.0/rpc/network/setban/
> [4]: https://twitter.com/jamesob/status/1623827708168863747
> 
> /dev/fd0
> floppy disc guy
> 
> Sent with Proton Mail secure email.
> 
> ___
> 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 mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Testing censorship resistance of bitcoin p2p network

[alicexbt via bitcoin-dev]

Hi Bitcoin Developers,

There is a famous quote attributed to Evelyn Beatrice Hall in her biography of 
Voltaire: "I disapprove of what you say, but I will defend to the death your 
right to say it." I'm curious to know how many Bitcoin developers share this 
sentiment.

Recently there was a lot of enthusiasm on social media to run bitcoin core with 
a [patch][0] that would reject some transactions in mempool. Bitcoin Knots 
already has an option to reject transactions that reuse addresses. What if such 
practices become common and some projects that provide easy to use node 
software start censoring transactions? How would government agencies take 
advantage of this whole drama?

I understand it is difficult to censor different type of transaction because 
there will be some nodes relaying them and miners including in blocks. It is 
still important to discuss this and different ways to test censorship 
resistance.

- Peter Todd had written a [blog post][1] in which counting number of INVs 
(step 5,6,7 and 8) helps in testing if your transactions are getting relayed by 
the connected peers. 
- I had tried broadcasting transaction to specific nodes using [libbtc][2]. 
Based on my understanding it uses GETDATA to confirm your transaction was seen 
on other nodes after broadcasting.

What would an ideal tool for testing censorship resistance look like?

- Allows user to construct different types of transactions that might be 
considered "bad" by some people. Example: OFAC address in output, Inscription, 
OP_RETURN, Address reuse etc.
- Option to broadcast transaction to specific nodes
- Verify if the transaction was relayed successfully or rejected
- Ban such peers using [setban][3] RPC as it would increase the probability of 
tx getting propagated to miners

There was even some discussion about an [external mempool][4] that could be 
used for non-standard transactions. It could also help in avoiding censorship 
in some cases. I welcome your thoughts and feedback on this topic.

[0]: https://gist.github.com/luke-jr/4c022839584020444915c84bdd825831
[1]: https://petertodd.org/2022/bitcoin-core-nodes-running-fullrbf
[2]: https://twitter.com/144bytes/status/1574225052240777216
[3]: https://bitcoincore.org/en/doc/24.0.0/rpc/network/setban/
[4]: https://twitter.com/jamesob/status/1623827708168863747

/dev/fd0
floppy disc guy

Sent with Proton Mail secure email.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Purely off-chain coin colouring

[alicexbt via bitcoin-dev]

Hi Anthony,

> As far as salience/notability goes, personally, I'd see ownership of
inscriptions as a negative indicator; "hey, when I was young and foolish I
wasted x-thousand bytes on the bitcoin blockchain, pointlessly creating a
permanent cost for everyone trying to use bitcoin in future". That's not
unforgivable; people do all sorts of foolish things, and bitcoin's meant
to survive attacks, not just foolish pranks. But it doesn't seem like
something to brag about or encourage, either, at least if you want bitcoin
to be a monetary network that's usable in practice by many/most people.

Moving transactions off-chain because of emotions or personal opinions does not 
make sense. 
Everyone running a bitcoin node is aware of block limits and they could be 
filled with different type of transactions including [non-inscription txs][0] 
that use witness for complex scripts.

> And if
a public site like ordinals.net is willing to store all the inscriptions
that might be on the blockchain, they could just as easily store the
same amount of off-chain digital assets.

[Ord explorer][1] is open source and gets inscriptions from blockchain.

> Obviously blockchains aren't the only "scarce" good out there. If scarcity
is your goal, there's two very easy ways to make your own scarcity. 

Using pow doesn't make nostr relays "scarce". Its mainly used to avoid spam but 
some spammers on nostr have proved it isn't enough. 

> then in the off-chain world, they would look like two events:

Nostr relays do not guarantee that these events will be stored [forever][2].

> As I've said above, the off-chain approach seems
much better aligned with incentives to me, with the people who gain the
benefit from that association paying the cost of preserving it.

Cost for running bitcoin node do not change with inscriptions and do not depend 
on the content or intent of any bitcoin transaction. It is a permissionless 
network and users can decide how to use money and blockspace.

Campaigns to censor such transactions or other efforts to move them off-chain 
are creating a slippery slope that could affect bitcoin more than some 
inscriptions. If Casey is harassed enough on social media and ord project moves 
inscriptions off-chain, there would be forks of it doing it on-chain.


[0]: https://twitter.com/mononautical/status/1621663167582437376
[1]: https://github.com/casey/ord
[2]: https://twitter.com/damusapp/status/1621431556048035841


dev/fd0
floppy disc guy

Sent with Proton Mail secure email.

--- Original Message ---
On Saturday, February 4th, 2023 at 4:08 PM, Anthony Towns via bitcoin-dev 
 wrote:


> On Thu, Feb 02, 2023 at 10:39:21PM -0800, Casey Rodarmor via bitcoin-dev 
> wrote:
> 
> > Apologies for posting! I've tried to keep discussion of ordinals and
> > inscriptions off-list, because I consider it to be of little relevance to
> > general Bitcoin development.
> 
> 
> Anything that potentially uses up a large percentage of blockspace seems
> pretty relevant to general Bitcoin development to me...
> 
> > AJ Towns writes:
> > 
> > > I think, however, that you can move inscriptions entirely off-chain. I
> > > wrote a little on this idea on twitter already [1], but after a bit more
> > > thought, I think pushing things even further off-chain would be plausible.
> 
> 
> I guess I should have explained why I think moving things off-chain is
> a worthwhile goal. Riffing off:
> 
> > Another issue is salience and scarcity, as has been mentioned. Off-chain
> > content is unbounded, and thus less scarce. Usually, we design for
> > efficiency, volume, and scale. For NFT designs, which are intended to be
> > collectable, this is in some ways counterproductive.
> 
> 
> "scarce" has two meanings -- one is that there's not much of it, the
> other is that it's highly valued (or a third, where it's is consistently
> underpriced and unavailable even for people who'd pay more, but that
> hopefully doesn't apply).
> 
> I think for bitcoin's blockspace, we ideally only want the first of
> these to be true. We want small blocks because that makes it cheap to
> verify bitcoin, which reduces the need to trust third parties and aids in
> decentralisation. But we don't want blockspace to be especially valuable,
> as that makes it expensive to use bitcoin, which then limits who can
> use it.
> 
> Moving things off-chain helps with both these goals: it doesn't make it
> harder to validate bitcoin, and it also decreases demand for blockspace,
> making it cheaper for those cases where things can't be moved off-chain.
> 
> As a result of this approach, bitcoin blockspace is currently quite
> cheap -- so inscribing at 100kB jpeg at 25kvB might cost perhaps $60 in
> a peak period, or $6 if you wait for 1sat/vb to confirm. Not exactly a
> luxury purchase.
> 
> If you keep jpegs on-chain, as far as I can see, there's three outcomes:
> 
> * blockspace stays relatively cheap, and there's no "scarcity" benefit to
> minting via on-chain inscriptions; it's

Re: [bitcoin-dev] Purely off-chain coin colouring

[alicexbt via bitcoin-dev]

Hi Anthony,

> I think, however, that you can move inscriptions entirely off-chain. I
wrote a little on this idea on twitter already [1], but after a bit more
thought, I think pushing things even further off-chain would be plausible.

Whole point of inscriptions is to keep something on-chain associated with your 
sats so this approach goes against the concept and what makes them interesting 
in the first place.

> Implementing that is fairly straightforward: you just need a protocol
for creating an asset offchain and associating it with an ordinal --
nothing needs to happen on-chain at all. That is, you can do something
as simple as posting a single nostr message:

All events may not be permanently stored by Nostr relays. In addition to 
rendering inscriptions meaningless, this creates a dependency.

> The "inscription" approach might still be desirable for broadcasting
information that might otherwise be subject to heavy censorship; presuming
that the censoring entity isn't also willing and able to censor bitcoin
itself.

If bitcoin transactions can be censored then we have bigger problems to care 
about as bitcoin will have no value without censorship resistance.

Lastly, I would add that inscriptions involve "financial" transactions, 
associating sats with image is freedom and got historical reasons for it. 
Writing something on paper or drawing an image on copper is not same as doing 
it on gold.

Disclaimer: My opinion on inscriptions can be biased because I am working on a 
startup that will use inscriptions and satscard(coinkite)


/dev/fd0
floppy disc guy

Sent with Proton Mail secure email.

--- Original Message ---
On Thursday, February 2nd, 2023 at 2:45 PM, Anthony Towns via bitcoin-dev 
 wrote:


> Hi *,
> 
> Casey Rodarmor's ordinals use the technique of tracking the identity of
> individual satoshis throughout their lifetime:
> 
> On Tue, Feb 22, 2022 at 04:43:52PM -0800, Casey Rodarmor via bitcoin-dev 
> wrote:
> 
> > Briefly, newly mined satoshis are sequentially numbered in the order in
> > which they are mined. These numbers are called "ordinal numbers" or
> > "ordinals". When satoshis are spent in a transaction, the input satoshi
> > ordinal numbers are assigned to output satoshis using a simple
> > first-in-first-out algorithm.
> 
> 
> This is proposed as a BIP at https://github.com/bitcoin/bips/pull/1408
> 
> When accompanied by a standard for associating some data or right with
> such an identity, this allows the creation of non-fungible tokens (or
> semi-fungible tokens) whose ownership can be transferred by a bitcoin
> transaction.
> 
> The proposed BIP doesn't document any method for associating data or a
> right with an ordinal, but the "ord" tool defines "inscriptions" to fill
> this gap [0], providing a way of including mime-encoded data in a taproot
> witness. To make such an inscription, two transactions are required:
> one paying some sats to a special scriptPubKey that commits to the
> inscribed data, and a second that spends those sats to the owner of the
> newly inscribed ordinal, and in so doing revealing the full inscription.
> 
> [0] https://docs.ordinals.com/inscriptions.html
> 
> I think, however, that you can move inscriptions entirely off-chain. I
> wrote a little on this idea on twitter already [1], but after a bit more
> thought, I think pushing things even further off-chain would be plausible.
> 
> [1] https://twitter.com/ajtowns/status/1619554871166013441
> 
> In particular, rather than looking at it as being the owner of the sats
> that inscribes some content on those sats (analogously to signing a $100
> bill [2]), you could look at it as saying "the owner of this thing is
> whoever owns this particular sat" (eg instead of "whoever owns this
> share certificate is a shareholder", it's "whoever owns the $1 bill with
> serial number X is a shareholder").
> 
> [2] 
> https://www.espn.com/nfl/story/_/id/14375536/owner-100-bill-autograph-cleveland-browns-qb-johnny-manziel-getting-offers
> 
> Implementing that is fairly straightforward: you just need a protocol
> for creating an asset offchain and associating it with an ordinal --
> nothing needs to happen on-chain at all. That is, you can do something
> as simple as posting a single nostr message:
> 
> {
> "pubkey": 
> 
> "kind": 0,
> "tags": [
> ["ord", "txid:vout:sat"]
> ],
> "content": [jpeg goes here],
> "id": 
> 
> "sig": 
> 
> }
> 
> You can prove current ownership of the message by showing a custody
> chain, that is the transaction specified by "txid" in the "ord" tag,
> then every transaction that spent the given sat, until you get to one
> that's still in the utxo set [3]. You don't need to provide witness
> data or validate any of these tx's signatures, as that is already
> implicit in that you end up at a tx in the utxo set. Just calculating
> the txids and comparing against the output containing the sat you're
> interested in is sufficient.
> 
> [3] If the satoshi was lost to fees at some point,

Re: [bitcoin-dev] Ordinal Inscription Size Limits

[alicexbt via bitcoin-dev]

Hi Bitcoin Developers,

> Anyone who runs an unpruned bitcoin node should be capacity-planning their 
> disk space assuming that in the future blocks will be more full - as demand 
> for blockspace increases, people will make better use of the space that we 
> already have and average block weight will trend upwards. If you’re thinking 
> about how much disk you will need when we have consistently full blocks, 
> ordinal inscriptions don’t change that number. 

I completely agree with this.

> If we ban "useless data" then it would be easy for would-be data storers
to instead embed their data inside "useful" data such as dummy
signatures or public keys.

> There's a reasonable argument that this sort of data is toxic to the
network, since even though "the market is willing to bear" the price of
scares blockspace, if people were storing NFTs and other crap on the
chain, then the Bitcoin fee market would become entangled with random
pump&dump markets, undermining legitimate use cases and potentially
preventing new technology like LN from gaining a strong foothold.

Initially I considered ordinals and the use of witness for inscriptions useless 
and harmful. However I have changed my opinion after looking at different 
things and reading several comments. I do not consider such things 'useless' or 
'crap' and it won't affect bitcoin fee market negatively. There is no threat to 
LN as well.

I consider every bitcoin transaction a legit use case and would like to share 
an example and different perspective of how such inscriptions might be used at 
different places:

During the festival of Diwali, it is a common tradition among many Indian 
families to buy gold coins with the image of the goddess Laxmi, the goddess of 
wealth and prosperity. The coins are often bought as a symbol of good luck and 
prosperity for the upcoming year. They may also be given as gifts to family and 
friends or used as a form of investment. The coins can be purchased from a 
variety of sources, including jewelry stores and online retailers.

If people start buying bitcoin during Diwali, and sellers use the witness to 
include the image of Laxmi in the inputs used, it would be an innovative way of 
combining traditional customs with modern technology. Since some users consider 
bitcoin as digital gold, I won't be surprised if this really happens in future 
and won't consider it bad as the transactions are paying for block space used.

/dev/fd0
floppy disc guy

Sent with Proton Mail secure email.

--- Original Message ---
On Friday, January 27th, 2023 at 6:28 PM, rot13maxi via bitcoin-dev 
 wrote:


> Hello,
> 
> “Unlimited storage” isn’t really accurate. It’s witness data in a taproot 
> transaction, so the block size limit still applies. Anyone who runs an 
> unpruned bitcoin node should be capacity-planning their disk space assuming 
> that in the future blocks will be more full - as demand for blockspace 
> increases, people will make better use of the space that we already have and 
> average block weight will trend upwards. If you’re thinking about how much 
> disk you will need when we have consistently full blocks, ordinal 
> inscriptions don’t change that number. 
> 
> - rijndael
> 
> On Fri, Jan 27, 2023 at 7:44 AM, Robert Dickinson via bitcoin-dev 
>  wrote:
> 
> > I'm curious what opinions exist and what actions might be taken by core 
> > developers regarding storing unlimited amounts of NFT (or other?) content 
> > as witness data (https://docs.ordinals.com/inscriptions.html). The ordinal 
> > scheme is elegant and genius IMHO, but when I think about the future disk 
> > use of all unpruned nodes, I question whether unlimited storage is wise to 
> > allow for such use cases. Wouldn't it be better to find a way to impose a 
> > size limit similar to OP_RETURN for such inscriptions?
> > 
> > I think it would be useful to link a sat to a deed or other legal construct 
> > for proof of ownership in the real world, so that real property can be 
> > transferred on the blockchain using ordinals, but storing the property 
> > itself on the blockchain seems nonsensical to me.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] A new Bitcoin implementation integrated with Core Lightning

[alicexbt via bitcoin-dev]

Hi Michael,

If I were to fork bitcoin core and maintain an implementation, I wouldn't 
integrate any lightning implementation with it. Instead remove some things from 
bitcoin core and keep it simple. There is also scope for improving privacy. 
Example: https://github.com/bitcoinknots/bitcoin/issues/50

You might find the commits in this branch interesting if you are looking to 
remove things from bitcoin core and maintain an implementation with no gui, 
wallet, less RPCs etc.

https://github.com/jeremyRubin/bitcoin/commits/delete-it-all


/dev/fd0
floppy disc guy


Sent with Proton Mail secure email.

--- Original Message ---
On Sunday, January 15th, 2023 at 1:56 AM, Michael Folkson via bitcoin-dev 
 wrote:


> I tweeted this [0] back in November 2022.
> 
> "With the btcd bugs and the analysis paralysis on a RBF policy option in Core 
> increasingly thinking @BitcoinKnots and consensus compatible forks of Core 
> are the future. Gonna chalk that one up to another thing @LukeDashjr was 
> right about all along."
> 
> A new bare bones Knots style Bitcoin implementation (in C++/C) integrated 
> with Core Lightning was a long term idea I had (and presumably many others 
> have had) but the dysfunction on the Bitcoin Core project this week (if 
> anything it has been getting worse over time, not better) has made me start 
> to take the idea more seriously. It is clear to me that the current way the 
> Bitcoin Core project is being managed is not how I would like an open source 
> project to be managed. Very little discussion is public anymore and decisions 
> seem to be increasingly made behind closed doors or in private IRC channels 
> (to the extent that decisions are made at all). Core Lightning seems to have 
> the opposite problem. It is managed effectively in the open (admittedly with 
> fewer contributors) but doesn't have the eyeballs or the usage that Bitcoin 
> Core does. Regardless, selfishly I at some point would like a bare bones 
> Bitcoin and Lightning implementation integrated in one codebase. The Bitcoin 
> Core codebase has collected a lot of cruft over time and the ultra 
> conservatism that is needed when treating (potential) consensus code seems to 
> permeate into parts of the codebase that no one is using, definitely isn't 
> consensus code and should probably just be removed.
> 
> The libbitcoinkernel project was (is?) an attempt to extract the consensus 
> engine out of Core but it seems like it won't achieve that as consensus is 
> just too slippery a concept and Knots style consensus compatible codebase 
> forks of Bitcoin Core seem to still the model. To what extent you can safely 
> chop off this cruft and effectively maintain this less crufty fork of Bitcoin 
> Core also isn't clear to me yet.
> 
> Then there is the question of whether it makes sense to mix C and C++ code 
> that people have different views on. C++ is obviously a superset of C but 
> assuming this merging of Bitcoin Core and Core Lightning is/was the optimal 
> final destination it surely would have been better if Core Lightning was 
> written in the same language (i.e. with classes) as Bitcoin Core.
> 
> I'm just floating the idea to (hopefully) hear from people who are much more 
> familiar with the entirety of the Bitcoin Core and Core Lightning codebases. 
> It would be an ambitious long term project but it would be nice to focus on 
> some ambitious project(s) (even if just conceptually) for a while given 
> (thankfully) there seems to be a lull in soft fork activation chaos.
> 
> Thanks
> Michael
> 
> [0]: 
> https://twitter.com/michaelfolkson/status/1589220155006910464?s=20&t=GbPm7w5BqS7rS3kiVFTNcw
> 
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Why Full-RBF Makes DoS Attacks on Multiparty Protocols Significantly More Expensive

[alicexbt via bitcoin-dev]

Hi Peter,

> Bringing up Whirlpool here is silly. Everyone knows Samourai has made, at 
> best,
> some rather insane technical decisions. Quite likely downright malicious with
> their xpub collection. Their opinion isn't relevant. Cite reputable sources.

I didn't want this thread to become a wasabi vs samourai debate instead wanted 
to focus on full-rbf and how it affects different coinjoin implementations. 
Samourai wallet can be used with [dojo][0] that includes full node and 
Whirlpool can be used in [sparrow Wallet][1] as well. There are several reasons 
to not use wasabi and consider their opinion irrelevant. Wasabi has many 
privacy issues including address reuse and consolidation in a coinjoin tx. They 
completely lost their reputation after deciding to work with chain analysis 
firms that help governments for censorship of some UTXOs.

Even _nothingmuch_ who has contributed to Wasabi's coinjoin implementation has 
[no major issues][2] with whirlpool if used properly. Some [tweets][3] in this 
thread even show their incompetence and major issues with wabisabi.

Anyway thanks for responding to other things I mentioned in last email.


[0]: https://code.samourai.io/dojo/samourai-dojo
[1]: https://sparrowwallet.com/docs/mixing-whirlpool.html
[2]: 
https://twitter.com/search?lang=en&q=whirlpool%20(from%3AmHaGqnOACyFm0h5)&src=typed_query
[3]: https://twitter.com/mHaGqnOACyFm0h5/status/1538748210210013184


/dev/fd0
floppy disc guy

Sent with Proton Mail secure email.

--- Original Message ---
On Tuesday, January 10th, 2023 at 3:33 PM, Peter Todd  
wrote:


> On Tue, Jan 10, 2023 at 09:19:39AM +, alicexbt wrote:
> 
> > Hi Peter,
> > 
> > > ## How Full-RBF Mitigates the Double-Spend DoS Attack
> > > 
> > > Modulo tx-pinning, full-rbf mitigates the double-spend DoS attack in a 
> > > very
> > > straightforward way: the low fee transaction is replaced by the higher fee
> > > transaction, resulting in the latter getting mined in a reasonable amount 
> > > of
> > > time and the protocol making forward progress.
> > 
> > Asking this question based on a discussion on twitter. How would you get 
> > extra sats to increase the fees?
> 
> 
> You're misunderstanding the issue. There is no need for extra sats to increase
> fees. Coinjoin transactions already have fees set at a level at which you'd
> expect them to be mined in a reasonable amount of time. Full-RBF ensures that,
> modulo tx pinning, either the coinjoin gets mined, or any double-spend has to
> have a high enough feerate that it will be mined in a reasonable amount of 
> time
> as well.
> 
> > It seems this would be possible with Joinmarket, Wasabi and even joinstr 
> > although things would get worse for Whirlpool. Whirlpool coinjoin 
> > transactions do not signal BIP 125 RBF so they were not replaceable earlier
> 
> 
> Bringing up Whirlpool here is silly. Everyone knows Samourai has made, at 
> best,
> some rather insane technical decisions. Quite likely downright malicious with
> their xpub collection. Their opinion isn't relevant. Cite reputable sources.
> 
> Anyway, Wasabi would like to move to making coinjoins opt-in to RBF. Though
> full-rbf may come sooner; for technical reasons opt-in RBF is ugly to 
> implement
> now as activation needs to be coordinated accross all clients:
> 
> https://github.com/zkSNACKs/WalletWasabi/issues/9041#issuecomment-1376653020
> 
> > however attacker would be able to perform DoS attacks now by double 
> > spending their inputs used in coinjoin.
> 
> 
> As I explained, attackers can already do this with or without full-rbf simply
> by picking the right time to broadcast the double spend. It's not an effective
> attack anyway: with a UTXO you can already hold up a coinjoin round by simply
> failing to complete stage #2 of the coinjoin. Actually doing a double-spend
> simply guarantees that you're spending money on it. It's only effective with
> low-fee double-spends in the absence of full-rbf.
> 
> 
> This tweet is nuts. Eg "Gives well connected mining pools an added advantage"
> is simply false. Full-RBF does the exact opposite.
> 
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Why Full-RBF Makes DoS Attacks on Multiparty Protocols Significantly More Expensive

[alicexbt via bitcoin-dev]

Hi Peter,

> ## How Full-RBF Mitigates the Double-Spend DoS Attack
> 
> Modulo tx-pinning, full-rbf mitigates the double-spend DoS attack in a very
> straightforward way: the low fee transaction is replaced by the higher fee
> transaction, resulting in the latter getting mined in a reasonable amount of
> time and the protocol making forward progress.

Asking this question based on a [discussion on twitter][0]. How would you get 
extra sats to increase the fees? It seems this would be possible with 
Joinmarket, Wasabi and even joinstr although things would get worse for 
Whirlpool. Whirlpool coinjoin transactions do not signal BIP 125 RBF so they 
were not replaceable earlier, however attacker would be able to perform DoS 
attacks now by double spending their inputs used in coinjoin.

[0]: https://twitter.com/dammkewl/status/1599692908860706818

/dev/fd0
floppy disc guy

Sent with Proton Mail secure email.

--- Original Message ---
On Tuesday, January 10th, 2023 at 3:48 AM, Peter Todd via bitcoin-dev 
 wrote:


> I was reminded recently that while Suhas Daftuar cited tx-pinning as a reason
> to remove full-rbf, he neglected to mention that tx-pinning greatly increases
> the cost of attacks on multi-party protocols. Him (rhetorically?) asking(4):
> 
> "Does fullrbf offer any benefits other than breaking zeroconf business
> practices?"
> 
> ...has caused a lot of confusion by implying that there were no benefits. So
> I'm writing this to set the record straight and provide an easily cited
> explanation as to why full-rbf - even with tx-pinning - is a valuable
> improvement for multi-party protocols like coinjoins that rely on transactions
> containing multiple inputs exclusively controlled(1) by different parties.
> 
> tl;dr: without full-rbf people can intentionally and unintentionally DoS 
> attack
> multi-party protocols by double-spending their inputs with low-fee txs, 
> holding
> up progress until that low-fee tx gets mined. This could take days, weeks, or
> even worse. Modulo intentional tx-pinning, full-RBF fixes this by ensuring 
> that
> a higher fee transaction gets mined in a reasonable amount of time so the
> protocol makes forward progress. And as for tx-pinning, exploiting it is very
> expensive, so full-rbf still makes the situation much better than the status
> quo.
> 
> 
> # The Double-Spend DoS Attack on Multi-Party, Multi-Input, Transactions
> 
> If a protocol constructs transactions containing multiple inputs exclusively
> controlled by different parties, those parties can intentionally and
> unintentionally double-spend those inputs in alternate transactions. For
> example, in a Wasabi coinjoin any one of the hundreds of participants could
> sign and broadcast a transaction spending their input. If they do that at the
> right time, as much as ~100% of the hashing power may see the double-spend
> first, prior to the intended coinjoin transaction. This in fact does happen
> regularly in production to Wasabi coinjoins, probably due to people
> accidentally running different wallets at the same time using the same seed, 
> as
> well as people importing their seeds into alternative wallets.
> 
> By itself this isn't a significant problem: Wasabi coinjoins are a two phase
> protocol, and, like any multi-step, multi-party protocol, they have to deal
> with the fact that participants in the protocol may fail to complete all the
> steps necessary for a transaction to be completed. It's very common for one or
> more parties in a Wasabi coinjoin to fail to complete both steps of the
> protocol, and a majority of Wasabi coinjoin rounds fail. Wasabi deals with 
> this
> economically by (temporarily or ~permanently) blacklisting UTXOs that failed 
> to
> complete a round, making DoS attacks expensive by forcing the attacker to tie
> up funds/create new UTXOs.
> 
> Similarly, in use-cases such as multi-party-funded Lightning channels(5), an
> attacker can always DoS attack the protocol by participating in a channel 
> open,
> and then failing to allow payments to be routed through it. The solution is
> again to use economics to ensure the attack is sufficiently costly.
> 
> However, under the right circumstances double-spends are an unusually powerful
> DoS attack on multi-party, multi-input, transaction. When mempool demand is
> high, low fee transactions can take arbitrarily long to get mined. Bitcoin has
> seen periods of mempool demand where low-fee transactions would take months
> to get mined. Transaction expiry does not solve this problem, as anyone can
> rebroadcast transactions at any time. In these circumstances without
> transaction replacement a multi-party transaction such as a Wasabi coinjoin
> could be held up indefinitely by a low-fee double-spend.
> 
> 
> ## How Full-RBF Mitigates the Double-Spend DoS Attack
> 
> Modulo tx-pinning, full-rbf mitigates the double-spend DoS attack in a very
> straightforward way: the low fee transaction is replaced by the higher fee
> transaction,

Re: [bitcoin-dev] Roles and procedures around adding a bitcoin core maintainer

[alicexbt via bitcoin-dev]

Hi Michael,

> I don't think ranting and raving or throwing toys out the pram on the mailing 
> list is the productive way to go though.

It was the best possible way I found to summarize everything, look for opinions 
to improve the process, feedback about PR #25871 open since 140 days and 
includes no raving.

> I'll chat to some people offline and see what the confusion is and hopefully 
> this can be resolved without unnecessary drama. 

I like all my Bitcoin and Bitcoin Core communication to be public for 
transparency and documentation purposes. Except reporting vulnerabilities 
although some bitcoin core developers even post vulns in public as GitHub issue 
when it involves other implementations.


/dev/fd0
floppy disc guy

Sent with Proton Mail secure email.


--- Original Message ---
On Wednesday, December 21st, 2022 at 12:14 AM, Michael Folkson 
michaelfolk...@protonmail.com wrote:



> Hi alicexbt
> 
> There does seem to be some confusion on this which I'm going to look into. I 
> don't think ranting and raving or throwing toys out the pram on the mailing 
> list is the productive way to go though. I'll chat to some people offline and 
> see what the confusion is and hopefully this can be resolved without 
> unnecessary drama. I'll respond in the new year. I don't know if you 
> celebrate but if you do Happy Holidays.
> 
> Thanks
> Michael
> 
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
> 
> --- Original Message ---
> On Monday, December 19th, 2022 at 23:58, alicexbt via bitcoin-dev 
> bitcoin-dev@lists.linuxfoundation.org wrote:
> 
> > Hi Bitcoin Developers,
> > 
> > List of present bitcoin core maintainers:
> > 
> > Username
> > 
> > Focus Area
> > 
> > MarcoFalke
> > 
> > General, QA
> > 
> > fanquake
> > 
> > General, Build
> > 
> > hebasto
> > 
> > General, UI/UX
> > 
> > achow101
> > 
> > General, Wallet
> > 
> > glozow
> > 
> > General, Mempool
> > 
> > Last 2 developers that stepped down as bitcoin core maintainer:
> > 
> > Username
> > 
> > -
> > 
> > sipa
> > 
> > laanwj
> > 
> > Process followed in adding last maintainer:
> > 
> > 1) fanquake nominated glowzow as rbf/mempool/validation maintainer.
> > 
> > 2) It was discussed in an IRC meeting and most of the developers agreed to 
> > add her as new maintainer except mild NACK from Jeremy Rubin. Some 
> > contributors did not like different opinions being shared in the meeting.
> > 
> > 3) A pull request was opened by glowzow to add keys. There were several 
> > ACKs, 2 NACKs and 1 meta concept NACK.
> > 
> > My NACK: 
> > https://github.com/bitcoin/bitcoin/pull/25524#issuecomment-1172518409
> > 
> > NACK by jamesob: 
> > https://github.com/bitcoin/bitcoin/pull/25524#issuecomment-1172570635
> > 
> > Meta concept NACK by luke-jr: 
> > https://github.com/bitcoin/bitcoin/pull/25524#issuecomment-1175625779
> > 
> > Eventually everyone agreed to add glowzow as maintainer and improve the 
> > process of adding maintainers. Pull request was merged by MarcoFalke.
> > 
> > Initiatives to improve the process and documentation:
> > 
> > 1) Jeremy opened a pull request and there were lot of disagreements with 
> > the documentation. It was closed since a related PR with less changes could 
> > be easy to agree upon.
> > 
> > 2) Related pull request with minimal documentation was also closed by 
> > Jeremy with a comment that desire to improve docs seems to be missing based 
> > on reviews.
> > 
> > 3) Jeremy opened an issue with title 'Call for Maintainer: P2P & Networking 
> > + Privacy' which was changed later and 'Privacy' was removed. He nominated 
> > jonatack and vasild was already self nominated so mentioned in the pull 
> > request. Nobody appreciated this effort to nominate self or others for a 
> > new maintainer. Later this was closed.
> > 
> > 4) I had opened an issue with title Call for Maintainer: Privacy'. This 
> > even involved privacy of contributors and not just bitcoin core. It 
> > received some comments that made no sense and I eventually closed the issue.
> > 
> > Process being followed for adding vasild as maintainer:
> > 
> > 1) vasild volunteered to be a new maintainer on IRC
> > 
> > 2) It was discussed in IRC meeting, some developers ACKed 

[bitcoin-dev] Roles and procedures around adding a bitcoin core maintainer

[alicexbt via bitcoin-dev]

Hi Bitcoin Developers,

List of present bitcoin core maintainers:

|   Username|Focus Area   |
| - | -   |
|  MarcoFalke   | General, QA | 
|  fanquake | General, Build  |
|  hebasto  | General, UI/UX  |
|  achow101 | General, Wallet |
|  glozow   | General, Mempool|

Last 2 developers that stepped down as bitcoin core maintainer:

|   Username| 
| - | 
| sipa  | 
| laanwj| 

Process followed in adding last maintainer:

1) fanquake [nominated][0] glowzow as rbf/mempool/validation maintainer. 
2) It was discussed in an IRC [meeting][1] and most of the developers agreed to 
add her as new maintainer except mild NACK from Jeremy Rubin. Some contributors 
did not like different opinions being shared in the meeting.
3) A [pull request][2] was opened by glowzow to add keys. There were several 
ACKs, 2 NACKs and 1 meta concept NACK.
   My NACK: 
https://github.com/bitcoin/bitcoin/pull/25524#issuecomment-1172518409
   NACK by jamesob: 
https://github.com/bitcoin/bitcoin/pull/25524#issuecomment-1172570635
   Meta concept NACK by luke-jr: 
https://github.com/bitcoin/bitcoin/pull/25524#issuecomment-1175625779

   Eventually everyone agreed to add glowzow as maintainer and improve the 
process of adding maintainers. Pull request was merged by MarcoFalke.

Initiatives to improve the process and documentation:

1) Jeremy opened a [pull request][3] and there were lot of disagreements with 
the documentation. It was closed since a related PR with less changes could be 
easy to agree upon. 
2) Related [pull request][4] with minimal documentation was also closed by 
Jeremy with a comment that desire to improve docs seems to be missing based on 
reviews.
3) Jeremy opened an [issue][5] with title 'Call for Maintainer: P2P & 
Networking + Privacy' which was changed later and 'Privacy' was removed. He 
nominated jonatack and vasild was already self nominated so mentioned in the 
pull request. Nobody appreciated this effort to nominate self or others for a 
new maintainer. Later this was closed.
4) I had opened an [issue][6] with title Call for Maintainer: Privacy'. This 
even involved privacy of contributors and not just bitcoin core. It received 
some comments that made no sense and I eventually closed the issue. 

Process being followed for adding vasild as maintainer:

1) vasild volunteered to be a new maintainer on [IRC][7]
2) It was discussed in IRC [meeting][8], some developers ACKed it and there 
were no issues.
3) A [pull request][9] was opened by vasild to add keys which is still open and 
its been 4 months. There were already some ACKs from the IRC meeting and pull 
request also received some ACKs (16 until now). fanquake, dergoegge and 
JeremyRubin had some disagreements. Jeremy had recently withdrawn all ACK/NACK 
from bitcoin core repository for some reasons, fanquake has not replied yet and 
dergoegge had some new disagreements although don't mind if the pull request is 
merged.
4) Earlier disagreements were related to scoping and it was changed by vasild
4) There was even a comment that disrespected vasild's contributions in bitcoin 
core and we had to literally share pull requests in which vasild has improved 
bitcoin core.
5) I tried adding the topic for a bitcoin core dev weekly meeting but did not 
achieve anything.


Since Bitcoin Core is the reference implementation for Bitcoin and used by 90% 
nodes, what should be the ideal process or changes you would expect in roles, 
procedures etc.?

- 'Call for maintainers' issue should be opened if contributors or maintainers 
need a new maintainer.
- Discussion about nominated contributors in an IRC meeting where everyone is 
allowed to share their opinion.
- One of the nominated contributor that gets most ACKs could open pull request 
to add keys. Everyone can ACK/NACK this PR with reasons.
- Maintainers should be unbiased in merging these pull requests.
- New maintainer should not be funded by the organization that already does it 
for most of the maintainers.
- Long term contributors that are not living in a first world country should be 
encouraged.
- Either we should agree every maintainer is a general maintainer that can 
merge pull request from different modules or define scope for present and new 
maintainers. We can't do both.
- Self merging pull requests should be avoided.

Let me know if you have any thoughts that could improve this process and 
involve less politics. 
   

[0]: https://bitcoin-irc.chaincode.com/bitcoin-core-dev/2022-06-28#826651
[1]: https://bitcoin-irc.chaincode.com/bitcoin-core-dev/2022-06-30#827695
[2]: https://github.com/bitcoin/bitcoin/pull/25524
[3]: https://github.com/bitcoin/bitcoin/pull/25560
[4]: https://github.com/bitcoin/bitcoin/pull/25839
[5]: https://github.com/bitcoin/bitcoin/issues/25870
[6]: https://github.com/bitcoin/bitcoin/issues/25875
[7]: https://bitcoin-irc.chaincode.com/bitcoin-core-dev/2022-08-12#842847;
[8]: https://bitcoin-irc.

[bitcoin-dev] Use of OP_CTV in p2p exchanges that use 2of3 multisig

[alicexbt via bitcoin-dev]

Hi Bitcoin Developers,

Problem: In p2p exchanges that use 2of3 multisig (example: hodlhodl[0]), there 
is a possibility of buyer and seller settling the trade without involving 
exchange. Lets consider Alice (buyer), Bob (seller) and Carol (exchange). Once 
bitcoin is locked in multisig, Alice and Bob could create and sign a 
transaction which does not include trading fees output that goes to exchange.

Solution: I was wondering if OP_CTV fixes this because we could use a template 
that specifies the release transaction must have two outputs: one output that 
sends small amount to the exchange for fees, and another output that sends 
bitcoin to the buyer.

I am not good at writing bitcoin script with opcodes so did not test this 
however I wanted to confirm with others if this makes sense and can there be 
other advantages of using OP_CTV for a p2p exchange.

If this setup is considered a vault maybe [simple vault[1] which uses 2of2 
multisig can be modified for proof of concept or a [normal poc][2] if there are 
RPC commands available to test OP_CTV in bitcoin-inquistion.

[0]: https://gitlab.com/hodlhodl-public/public_docs/blob/master/multisig_spec.md
[1]: https://github.com/jamesob/simple-ctv-vault
[2]: https://github.com/144bytes/p2p


/dev/fd0

Sent with Proton Mail secure email.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Custom signet for testing full RBF

[alicexbt via bitcoin-dev]

Hi Michael,

> In this particular case the -mempoolfullrbf configuration option is in the 
> recent Bitcoin Core 24.0 release and so can be used both on mainnet and the 
> default signet, testnet etc. What could be tested on this custom signet that 
> can't be tested on the default signet with Bitcoin Core 24.0? Perhaps there 
> are some things that are easier to test with a smaller custom signet network 
> starting from scratch?

1. Signet miners and dictators are not interested to use full RBF
2. Testnet is weird and I only use it when a project doesn't support signet
3. Mainnet v24.0 is not released yet although Peter Todd is trying few things, 
I am not even sure if it will be available, testing should not depend on 
politics.
4. Main/Default Signet miners and dictators did not respond or agree to use 
full RBF.

Testing is important and I love it. I do not care about others.

> I know a number of people have struggled (e.g. [0], [1]) to get a custom 
> signet set up. I think the CTV signet took a while to get set up too. It 
> seems you followed the instructions on the Bitcoin wiki [2] for setting this 
> one up? Was there anything you found difficult or was counterintuitive 
> getting this custom signet set up? You are the sole block signer on this 
> custom signet. How regularly are you mining blocks (e.g. strictly every 10 
> minutes, replicating the Poisson process on mainnet, adhoc etc?) Are you 
> running this custom signet node on the same machine as a default signet, 
> mainnet, testnet full node? I'm a little tentative to start joining custom 
> signet networks on the same machine that is already running other nodes but 
> perhaps there are no problems. 

I had no issues except this command:

``
$ ../contrib/signet/miner --cli="./bitcoin-cli" calibrate 
--grind-cmd="./bitcoin-util grind" --seconds=600
```

I had no clue we need to wait for some seconds/minutes for output. Although its 
okay.

I used default settings and it should mine with it forever or my AWS 
subscription is cancelled. 

I am trying to help Bitcoin. Although not a big influencer. If most of the 
developers think its okay to test it directly on mainnet, there is nothing 
wrong with it. You will get some insights/bugs from this experiment if enough 
users try it.


Sent with Proton Mail secure email.ichael

/dev/fd0

--- Original Message ---
On Tuesday, November 22nd, 2022 at 4:50 PM, Michael Folkson 
 wrote:


> Hi alicexbt
> 
> Thanks for setting this up. Generally it seems to me like an excellent idea 
> to set up custom signets (and/or get proposals enabled on the default signet) 
> for testing and experimenting with new proposals.
> 
> I have two questions.
> 
> 1) In this particular case the -mempoolfullrbf configuration option is in the 
> recent Bitcoin Core 24.0 release and so can be used both on mainnet and the 
> default signet, testnet etc. What could be tested on this custom signet that 
> can't be tested on the default signet with Bitcoin Core 24.0? Perhaps there 
> are some things that are easier to test with a smaller custom signet network 
> starting from scratch?
> 
> 2) I know a number of people have struggled (e.g. 0, 1) to get a custom 
> signet set up. I think the CTV signet took a while to get set up too. It 
> seems you followed the instructions on the Bitcoin wiki 2 for setting this 
> one up? Was there anything you found difficult or was counterintuitive 
> getting this custom signet set up? You are the sole block signer on this 
> custom signet. How regularly are you mining blocks (e.g. strictly every 10 
> minutes, replicating the Poisson process on mainnet, adhoc etc?) Are you 
> running this custom signet node on the same machine as a default signet, 
> mainnet, testnet full node? I'm a little tentative to start joining custom 
> signet networks on the same machine that is already running other nodes but 
> perhaps there are no problems.
> 
> I'm not sure yet if I have a use case in mind for this particular custom 
> signet but I'm very interested in custom signet setup generally and the 
> docs/resources to make this as easy as possible so thanks again for posting 
> about this.
> 
> Thanks
> Michael
> 
> 0: 
> https://bitcoin.stackexchange.com/questions/114477/could-someone-share-with-me-some-documentations-or-sites-on-how-to-set-up-a-cust
> 1: 
> https://bitcoin.stackexchange.com/questions/114724/peer-discovery-on-a-custom-signet-custom-signetchallenge
> 2: 0: https://en.bitcoin.it/wiki/Signet#Custom_Signet
> 
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
> 
> 
> --- Original Message ---
> On Sunday, November

[bitcoin-dev] Custom signet for testing full RBF

[alicexbt via bitcoin-dev]

Hi Bitcoin Developers,

I have setup a [custom signet][0] for testing full RBF. You can connect to one 
or more of these nodes using `addnode`:

13.115.34.55 (issuer, full-rbf)
kfupbqwb2yvzzqjomfq5pkem553a6uzp2k73seqn4d46smy7azua.b32.i2p (rbf-optin)
luvczzzppiqnc2b7poivkxlugafe3uqaj245ebjqxtceio7poaorqcyd.onion (full-rbf)

Example config:

```
signet=1
signetchallenge=5121035daaa313aada6310340a242af17238cc1fd8849e875940bce65a60ac7e0e0ff751ae
proxy=127.0.0.1:9050

[signet]
addnode=luvczzzppiqnc2b7poivkxlugafe3uqaj245ebjqxtceio7poaorqcyd.onion

mempoolfullrbf=1
```

Example for a simple test case:

- Run 2 nodes
- Connect node 1 with i2p node and use default opt-in rbf
- Connect node 2 with node 1 and onion node. This node should use 
`mempoolfullrbf=1` in config and compile bitcoind using PR [#26454][1] branch
- Broadcast Tx1 using node 2 and replace with Tx2 using `bumpfee` RPC

It will be fun to test with more nodes joining this custom signet. If anyone 
interested to test, please post your bitcoin address in [full-rbf room][2]. We 
can even setup an explorer if this experiment makes sense.

[0]: https://en.bitcoin.it/wiki/Signet#Custom_Signet
[1]: https://github.com/bitcoin/bitcoin/pull/26454
[2]: #full-rbf:matrix.org

Sent with Proton Mail secure email.

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

Re: [bitcoin-dev] Bitcoin Contracting Primitives WG 1st Meeting, Tuesday 15 Nov. 18:00 UTC

[alicexbt via bitcoin-dev]

Hi Bitcoin Developers,

> Looking forward to the first session, listening to everyone's thoughts about 
> what could be the scope discussed by this new community process: anyprevout, 
> recursive covenants, introspection, new malleability flags, ZK rollups, new 
> contracting protocols and many more ideas!

Wanted to add CTV: BIP-119 OP_CHECKTEMPLATEVERIFY if OP missed it. Easiest and 
best possible way to get covenants aka tx introspection with lot of research 
and development.

/dev/fd0

Sent with [Proton Mail](https://proton.me/) secure email.

--- Original Message ---
On Monday, November 14th, 2022 at 7:51 AM, Antoine Riard via bitcoin-dev 
 wrote:

> Reminder: this is happening this _upcoming_ Tuesday.
> Looking forward to the first session, listening to everyone's thoughts about 
> what could be the scope discussed by this new community process: anyprevout, 
> recursive covenants, introspection, new malleability flags, ZK rollups, new 
> contracting protocols and many more ideas!
> Best,
> Antoine
>
> Le lun. 31 oct. 2022 à 20:47, Antoine Riard  a écrit 
> :
>
>> Hi list,
>>
>> After I have been asked offline the exact date when those meetings were 
>> actually starting, I'm proposing Tuesday 15th November at 18:00 UTC, i.e 2 
>> weeks from now. Thinking about a monthly frequency for now (from my 
>> experience attending dlcspecs/lighnting specs meetings/core dev meetings in 
>> the past, weekly sounds too much, biweekly/monthly sounds better though 
>> dunno yet good frequency).
>>
>> If there is an incompatibility with another public engineering meeting in 
>> the Bitcoin space, let it know. We can talk about a better schedule during 
>> the 1st session [0].
>>
>> Communication venue is #bitcoin-contracting-primitives-wg on Libera Chat 
>> [1]. Feel free to lurk already and ask questions.
>>
>> No consistent agenda beyond listening to every attendee their expectations, 
>> ideas, subjects of interests they would like to see happening with this new 
>> covenants/contracting primitives R&D process.
>>
>> If you have been working on a contracting 
>> protocols/side-chains/rollups/other use-cases that could benefit from 
>> extended Bitcoin contracting primitives, feel free to open an issue there: 
>> https://github.com/ariard/bitcoin-contracting-primitives-wg/issues
>>
>> Let it know if you have more questions or feedback.
>>
>> Cheers,
>> Antoine
>>
>> [0] It would be great to have a schedule inclusive of most timezones we can, 
>> 18:00 UTC might be too early for Asian and Oceanic ones. Later, we start to 
>> be exclusive towards contributors in Eastern Europe.
>>
>> [1] There have been more voices suggesting jitsi/audio-based meetings rather 
>> than IRC. It's a cool format too, though coming with trade-offs.___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Announcement: Full-RBF Miner Bounty

[alicexbt via bitcoin-dev]

Hi Peter,

> tl;dr: I'm broadcasting full-RBF replacements paying extremely high fees to
> reward miners that turn on full-RBF. I'm starting small, just ~$100/block in
> times of congestion. Miner and pool profit margins are pretty small, on the
> order of $1k/block in many cases, so I know it doesn't take that much more
> money to make a difference.

I appreciate this effort and perhaps this was all that was needed in addition 
to Bitcoin Core's inclusion of full rbf support. Making it default right away 
or enabling preferential peering with service flag in a bitcoin core release 
was unnecessary.

> If you'd like to donate to this effort, send BTC to
> bc1qagmufdn6rf80kj3faw4d0pnhxyr47sevp3nj9m

Sorry, I don't trust you based on some of the things you support on Twitter. 
Hopefully, others will donate and help this bounty.

/dev/fd0

Sent with Proton Mail secure email.

--- Original Message ---
On Wednesday, November 2nd, 2022 at 2:56 PM, Peter Todd via bitcoin-dev 
 wrote:


> I'm now running a full-RBf bounty program for miners.
> 
> tl;dr: I'm broadcasting full-RBF replacements paying extremely high fees to
> reward miners that turn on full-RBF. I'm starting small, just ~$100/block in
> times of congestion. Miner and pool profit margins are pretty small, on the
> order of $1k/block in many cases, so I know it doesn't take that much more
> money to make a difference.
> 
> Why should you do this? Full-RBF/zeroconf has been discussed to death. But
> tl;dr: You'll earn more money, and help transition Bitcoin to a more secure
> mempool policy based on economic incentives rather than trust.
> 
> 
> If you're a miner and want to participate, the easiest way to so is to use the
> mempoolfullrbf=1 option in the upcoming Bitcoin Core v24 release (eg the
> 24.0rc3 tag), or use the mempoolreplacement=fee option in Bitcoin Knots.
> 
> You can also just modify the code yourself by removing the opt-in RBF check.
> For example against the v23.0 tag:
> 
> $ git diff
> diff --git a/src/validation.cpp b/src/validation.cpp
> index 214112e2b..44c364623 100644
> --- a/src/validation.cpp
> +++ b/src/validation.cpp
> @@ -736,7 +736,7 @@ bool MemPoolAccept::PreChecks(ATMPArgs& args, Workspace& 
> ws)
> // check all unconfirmed ancestors; otherwise an opt-in ancestor
> // might be replaced, causing removal of this descendant.
> if (!SignalsOptInRBF(*ptxConflicting)) {
> - return state.Invalid(TxValidationResult::TX_MEMPOOL_POLICY, 
> "txn-mempool-conflict");
> + // return state.Invalid(TxValidationResult::TX_MEMPOOL_POLICY, 
> "txn-mempool-conflict");
> }
> 
> ws.m_conflicts.insert(ptxConflicting->GetHash());
> 
> 
> Once you've enabled full-RBF, you need a full-RBF peer. I'm running a few of
> them:
> 
> cup.nop.lol
> mug.nop.lol
> jar.nop.lol
> jug.nop.lol
> 
> These nodes run a preferential peering patch 
> (https://github.com/bitcoin/bitcoin/pull/25600)
> to ensure that full-RBF nodes are interconnected to each other and 
> replacements
> can easily propagate. Also feel free to contact me if you'd like to peer with 
> a
> private node.
> 
> 
> If you'd like to donate to this effort, send BTC to
> bc1qagmufdn6rf80kj3faw4d0pnhxyr47sevp3nj9m
> 
> 
> ...and yes, I'm well aware that miners could collect this bounty in other 
> ways,
> eg by raising minimum fees. Doing that also breaks zeroconf, so I'm not too
> concerned.
> 
> --
> 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] Silent Payment v4 (coinjoin support added)

[alicexbt via bitcoin-dev]

Hi woltx,

Thanks for the response.

> Using all inputs, it becomes possible to use SP addresses in coinjoins as 
> long as all participants agree.
> More information:
> https://gist.github.com/RubenSomsen/c43b79517e7cb701ebf77eec6dbb46b8#variant-using-all-inputs

Using new addresses and SP address would be same in my opinion in coinjoin.

> I think Andrew Poelstra is referring to a multi-party scheme.
> This is not the case with the Silent Payments scheme, which only relies on 
> transaction data, which is publicly available on the blockchain.

Sounds good.

> This warning was suggested by Aurèle Oulès in 
> https://github.com/bitcoin/bitcoin/pull/24897#issuecomment-1276160738 and the 
> reason was a discussion in PR about users thinking that each address would 
> come from a different key and not the same key.

It makes sense although could be rephrased.

/dev/fd0


Sent with Proton Mail secure email.

--- Original Message ---
On Sunday, October 23rd, 2022 at 12:30 PM, woltx  wrote:


> Hi /dev/fd0
> 
> I haven't accessed ML for a while.
> 
> 1) All inputs being used sounds good although I do not understand how it 
> would benefit coinjoin.
> 
> Using all inputs, it becomes possible to use SP addresses in coinjoins as 
> long as all participants agree.
> More information:
> https://gist.github.com/RubenSomsen/c43b79517e7cb701ebf77eec6dbb46b8#variant-using-all-inputs
> 
> 2) Not sure about the concerns expressed by Andrew Poelstra in the pull 
> request related to rogue-key attacks.
> 
> I think Andrew Poelstra is referring to a multi-party scheme.
> This is not the case with the Silent Payments scheme, which only relies on 
> transaction data, which is publicly available on the blockchain.
> 
> 3) I could not understand the warning in the output for `getsilentaddress` 
> RPC when used with a label.
> 
> This warning was suggested by Aurèle Oulès in 
> https://github.com/bitcoin/bitcoin/pull/24897#issuecomment-1276160738 and the 
> reason was a discussion in PR about users thinking that each address would 
> come from a different key and not the same key.
> 
> 
> 
> 
> Sent with Proton Mail secure email.
> 
> 
> --- Original Message ---
> On Wednesday, October 12th, 2022 at 6:04 AM, alicexbt alice...@protonmail.com 
> wrote:
> 
> 
> 
> > Hi woltx,
> > 
> > Thanks for working on silent payments improving it in each version.
> > 
> > 1) All inputs being used sounds good although I do not understand how it 
> > would benefit coinjoin.
> > 2) New RPC command name is better.
> > 
> > > I opened a new PR (#1143) to add a function to convert from x-only to 
> > > compressed public key with even y.
> > 
> > Not sure about the concerns expressed by Andrew Poelstra in the pull 
> > request related to rogue-key attacks.
> > 
> > > Tutorial updated: 
> > > https://gist.github.com/w0xlt/c81277ae8677b6c0d3dd073893210875
> > > "warnings": "This address is not a new identity. It is a re-use of an 
> > > existing identity with a different label."
> > 
> > I could not understand the warning in the output for `getsilentaddress` RPC 
> > when used with a label.
> > 
> > /dev/fd0
> > 
> > Sent with Proton Mail secure email.
> > 
> > --- Original Message ---
> > On Tuesday, October 11th, 2022 at 12:32 PM, woltx via bitcoin-dev 
> > bitcoin-dev@lists.linuxfoundation.org wrote:
> > 
> > > Silent Payment v4 (coinjoin support added)
> > > Changes:
> > > 
> > > . Silent payments now use all inputs to create transactions. Previously, 
> > > they only used the first input. This change increases privacy and makes 
> > > silent payments compatible with coinjoin.
> > > 
> > > . `getspaddress` RPC renamed to `getsilentaddress` for clarity
> > > 
> > > . Added support for silent payment in PSBT via `walletcreatefundedpsbt` 
> > > RPC.
> > > 
> > > . Added a new index scheme (which stores the sum of input public keys for 
> > > each transaction). The previous index 
> > > `bitcoin/signet/indexes/silentpaymentindex` should be removed as it is no 
> > > longer compatible with this new version.
> > > 
> > > For reviewers:
> > > 
> > > Now, silent payments use the scheme `hash(i1*X + i2*X + i3*X + ...)*G + X 
> > > == hash(x*(I1+I2+I3+...))*G + X`, as described here: 
> > > https://gist.github.com/RubenSomsen/c43b79517e7cb701ebf77eec6dbb46b8#variant-using-all-inputs
> > > 
> > > As inputs can be Taproot, this introduced a new issue as 
> > > `bitcoin-core/secp256k1` does not support x-only public key sum (perhaps 
> > > due to missing prefix byte).
> > > 
> > > I opened a new PR (#1143) to add a function to convert from x-only to 
> > > compressed public key with even y. This is the solution being used by the 
> > > current silent payment implementation.
> > > 
> > > Tutorial updated: 
> > > https://gist.github.com/w0xlt/c81277ae8677b6c0d3dd073893210875
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin

Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger

[alicexbt via bitcoin-dev]

Hi Dave,

> One way to address this risk is by turning it into a certainty.  If the 
price of BTC increases between when the invoice is generated and when a 
transaction is included in a block, give the customer a future purchase 
credit equal in value to the difference between the price they paid and 
the value of the purchase at confirmation time.  Now there's no benefit 
to the customer from canceling their transaction.

There are several methods to approach this issue, one of which is by using 
multiple exchanges from different countries as there are always possibilities 
for arbitrage. Example:

The user purchases a gift card on Bitrefill for 0.01 BTC, and then Bitrefill 
cash it out at one of the three exchanges where the price of bitcoin is 19000, 
19100, or 19500. However, price used for gift card payment was average of all 
3. This should never be solved at protocol level as speculation of price is 
irrelevant when making RBF policy default in bitcoin core.

There are different types of businesses that accept bitcoin payments and its 
good for bitcoin. However, everyone has their own way to deal with the issues. 
Example:

In a website for booking flights, you may cancel a user's ticket if they 
couldn't make a payment within a certain amount of time and confirmations. I'm 
not sure how gift cards operate, but they are used for carding, fraud etc. 
frequently.

Its important to give priority to bitcoin projects that could improve demand 
for block space even if opening and closing channels. I would [quote][0] 
something from a pull request by Michael Folkson although I do not agree with 
everything he writes:

"I don't believe in added code (complexity) for issues that can be resolved in 
alternative repos and through communication with the ecosystem."

Things that could help improve business for companies that accept bitcoin 
payments could be done in other ways. Zero conf is old school but we can try 
new ways and do partnerships with more organizations (outside North America and 
Europe). I work for an exchange as developer although CTO won't write an email 
and CEO don't want to spam the mailing list with non technical things. I 
request on their behalf that we consider all businesses and some are not even 
aware of fullRBF. Example: Lolli or Gosats

TL;DR

Full RBF should be tried and if default is an issue, devs should convince some 
nodes and miners or agree on one of the pull requests. I prefer [AJ's pull 
request][1] because it gives time for review and testing. It is important to 
test as many websites, apps, projects etc. as possible before making something 
default and also consider the percent of usage.

[0]: https://github.com/bitcoin/bitcoin/pull/26323#issuecomment-1280742475
[1]: https://github.com/bitcoin/bitcoin/pull/26323


/dev/fd0


Sent with Proton Mail secure email.

--- Original Message ---
On Monday, October 24th, 2022 at 12:50 AM, David A. Harding via bitcoin-dev 
 wrote:


> On 2022-10-19 04:29, Sergej Kotliar via bitcoin-dev wrote:
> 
> > The biggest risk
> > in accepting bitcoin payments is in fact not zeroconf risk (it's
> > actually quite easily managed), it's FX risk as the merchant must
> > commit to a certain BTCUSD rate ahead of time for a purchase. Over
> > time some transactions lose money to FX and others earn money - that
> > evens out in the end. But if there is an easily accessible in the
> > wallet feature to "cancel transaction" that means it will eventually
> > get systematically abused.
> 
> 
> One way to address this risk is by turning it into a certainty. If the
> price of BTC increases between when the invoice is generated and when a
> transaction is included in a block, give the customer a future purchase
> credit equal in value to the difference between the price they paid and
> the value of the purchase at confirmation time. Now there's no benefit
> to the customer from canceling their transaction.
> 
> Of course, this means that the merchant will always either break even or
> lose money on the exchange rate part of the transaction and will need to
> raise their prices accordingly. I can see how that would be unappealing
> to implement, but it seems better to me to address the incentive
> incompatibility you've raised rather than hope no large miners ever
> start performing full RBF. Plus, maybe the future credit feature is
> something customers would like: I know I've been sad several times when
> the exchange rate changed significantly while I was waiting for one of
> my transactions to confirm.
> 
> The above mitigation is also compatible with LN payments. For example,
> a merchant today might issue an LN invoice that expires in 10 minutes.
> The customer can wait for most of that time to elapse to see how the
> exchange rate changes before deciding to pay, obtaining the same
> American call option. If they are instead offered a future purchase
> credit for any gains, the customer doesn't suffer any opportunity cost
> by paying immediat

Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger

[alicexbt via bitcoin-dev]

Hi aj,

> I mean, I guess I can understand wanting to reduce that responsibility
> for maintainers of the github repo, even if for no other reason than to
> avoid frivolous lawsuits, but where do you expect people to find better
> advice about what things are a good/bad idea if core devs as a whole
> are avoiding that responsibility?

Bitcoin Core contributors and maintainers should provide the options, 
recommendations etc. about mempool policies. If these policies are kept for 
users to change based on their needs, why force anything or change defaults 
ignoring feedback?

> Core devs are supposedly top technical experts at bitcoin -- which means
> they're the ones that should have the best understanding of all the
> implications of policy changes like this.

Why even provide options for users to change RBF policy in that case? Option to 
disable was already [removed][1] ignoring NACKs and MarcoFalke prefers users 
try the [workaround][2] if there is ever a need to disable it. Are we going to 
remove all the options to switch RBF policies in future because fullrbf has 
been suggested by leading technical experts? Is there a possibility of experts 
going wrong and has it ever happened in past?

> It's a bit disappointing that the people that's a problem for didn't
> engage earlier -- though looking back, I guess there wasn't all that
> much effort made to reach out, either.

To be fair, John Carvalho did [comment][3] about this in a pull request 
although it was wrong PR and never going to be merged.

> And I mean: all this is only about drawing a line in sand; if people
> think core devs are wrong, they can still let that line blow away in
> the wind, by running different software, configuring core differently,
> patching core, or whatever else.

I think this is the best option for users at this point. Keep running older 
versions of Core and use Knots or other implementations until technical experts 
in core repository, other bitcoin projects and users are on the same page.

> And the
> impression I got from the PR review club discussion more seemed like
> devs making assumptions about businesses rather than having talked to
> them (eg "[I] think there are fewer and fewer businesses who absolutely
> cannot survive without relying on zeroconf. Or at least hope so").

Even I noticed this since I don't recall the developers of the 3 main coinjoin 
implementations that are claimed to be impacted by opt-in RBF making any 
remarks.

[1]: https://github.com/bitcoin/bitcoin/pull/16171
[2]: https://github.com/bitcoin/bitcoin/pull/25373#issuecomment-1157846575
[3]: https://github.com/bitcoin/bitcoin/pull/25373#issuecomment-1163422654

/dev/fd0

Sent with Proton Mail secure email.

--- Original Message ---
On Tuesday, October 18th, 2022 at 12:30 PM, Anthony Towns via bitcoin-dev 
 wrote:


> On Mon, Oct 17, 2022 at 05:41:48PM -0400, Antoine Riard via bitcoin-dev wrote:
> 
> > > 1) Continue supporting and encouraging accepting unconfirmed "on-chain"
> > > payments indefinitely
> > > 2) Draw a line in the sand now, but give people who are currently
> > > accepting unconfirmed txs time to update their software and business
> > > model
> > > 3) Encourage mainnet miners and relay nodes to support unconditional
> > > RBF immediately, no matter how much that increases the risk to
> > > existing businesses that are still accepting unconfirmed txs
> > > To give more context, the initial approach of enabling full RBF through
> > > #25353 + #25600 wasn't making the assumption the enablement itself would
> > > reach agreement of the economic majority or unanimity.
> 
> 
> Full RBF doesn't need a majority or unanimity to have an impact; it needs
> adoption by perhaps 10% of hashrate (so a low fee tx at the bottom of
> a 10MvB mempool can be replaced before being mined naturally), and some
> way of finding a working path to relay txs to that hashrate.
> 
> Having a majority of nodes/hashrate support it makes the upsides better,
> but doesn't change the downsides to the people who are relying on it
> not being available.
> 
> > Without denying that such equilibrium would be unstable, it was designed to
> > remove the responsibility of the Core project itself to "draw a hard line"
> > on the subject.
> 
> 
> Removing responsibility from core developers seems like it's very much
> optimising for the wrong thing to me.
> 
> I mean, I guess I can understand wanting to reduce that responsibility
> for maintainers of the github repo, even if for no other reason than to
> avoid frivolous lawsuits, but where do you expect people to find better
> advice about what things are a good/bad idea if core devs as a whole
> are avoiding that responsibility?
> 
> Core devs are supposedly top technical experts at bitcoin -- which means
> they're the ones that should have the best understanding of all the
> implications of policy changes like this. Is opt-in RBF only fine? If
> you look at the network today, it sure seems like it; it takes 

Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger

[alicexbt via bitcoin-dev]

Hi cndm1,

> Bitrefill already supports lightning, so for them it would be easy to
> solve by displaying the lightning transfer by default and only show
> the on-chain payment as a fallback. Currently the on-chain payment at
> Bitrefill and other similar providers is really a drop-down where you
> select your wallet and then they display a tutorial to you on how to
> create the on-chain transaction (fee rate, RBF flag, etc). I don't
> have insights into Bitrefill, but one might suspect that encouraging a
> lightning payment might be a win-win situation for them and their
> users.

Lightning is only used for 4% payments compared to 32% on-chain payments 
according to a [tweet][1] from Jan 2022 by Sergej Kotliar and stats are similar 
based on the slides shared in a [presentation][2] in Pizza Day Prague 2022.

By EUR:

onchain - 30%
lightning - 5%

By unique users:

onchain - 40%
lightning - 9%

> Relay of fullrbf transactions works reasonable well
> already, unless you get unlucky with your selected peers. The only
> missing piece is a few percent of hashrate that will accept fullrbf
> replacement transactions. 

I don't believe relay of fullrbf transactions works well right now. The missing 
piece you mentioned is important and a real need for all full node users to try 
fullrbf.

> While this will certainly happen if a
> Bitcoin Core release ships with the flag on by default, it still may
> happen at any time even if Bitcoin Core doesn't ship with the flag at
> all.

Changing default at this moment does not make sense as v24.0 could give some 
insights about usage of fullrbf and we could wait for a few months before 
changing default for users that run latest version of bitcoin core.

I will quote Antoine Riard's comment from PR [#25353][3]:

"_I know I've advocated in the past to turn RBF support by default in the past. 
Though after gathering a lot of feedbacks, this approach of offering the policy 
flexiblity to the interested users only and favoring a full-rbf gradual 
deployment sounds better to me. As a follow-up, if we add p2p logic to connect 
to few "full-rbf" service-bit signaling peers and recommend to the ~17000 LN 
nodes operators, likely (hopefully!) running bitcoind as a backend, that should 
be okay to guarantee a good propagation to miners (and yes reaching out to few 
mining pools ops to explain the income increase brought by full-rbf). Unless we 
observe a significant impact on compact blocks reconstruction, personally I'm 
really fine waiting another multi-years development cycle before to propose a 
default change, or even let opt-in forever the default as it is._"

"_Once again, the proposed change is only targeting educated users aiming to 
deploy full RBF for their application specific needs. If the majority of 
Bitcoin users is not interested, that's okay. It's a policy rule, not a 
consensus one._"

Although Antoine has opened another [pull request][4] to make fullrbf default a 
few hours ago, so I am not sure what is the new motivation or discussion that I 
am missing.

[1]: https://twitter.com/ziggamon/status/1481307334068641795
[2]: https://youtu.be/bkjEcSmZKfc?t=463
[3]: https://github.com/bitcoin/bitcoin/pull/25353
[4]: https://github.com/bitcoin/bitcoin/pull/26305

/dev/fd0

Sent with Proton Mail secure email.

--- Original Message ---
On Thursday, October 13th, 2022 at 9:37 PM, linuxfoundation.cndm1--- via 
bitcoin-dev  wrote:


> > - Bitrefill's on-chain payments for gift cards and phone top-ups
> 
> 
> Bitrefill already supports lightning, so for them it would be easy to
> solve by displaying the lightning transfer by default and only show
> the on-chain payment as a fallback. Currently the on-chain payment at
> Bitrefill and other similar providers is really a drop-down where you
> select your wallet and then they display a tutorial to you on how to
> create the on-chain transaction (fee rate, RBF flag, etc). I don't
> have insights into Bitrefill, but one might suspect that encouraging a
> lightning payment might be a win-win situation for them and their
> users.
> 
> It would be interesting to know if there are any obstacles that
> Bitrefill and other services face, or if they don't agree that
> lightning is an improvement over accepting unconfirmed on-chain
> transactions from untrusted parties.
> 
> > - Many bitcoin ATMs' on-chain deposits for selling bitcoin for cash (at 
> > least
> 
> 
> I haven't tried them yet, but I suspect they could benefit in a
> similar by showing lightning transfers more prominently. Moreover, any
> UX improvement they can offer to users that intentionally or
> accidentally selected RBF opt-in, will also benefit users once fullrbf
> is widespread. To give an example, ATMs could immediately give out a
> voucher for the cash amount that can be redeemed as soon as the
> transaction is confirmed on-chain, to allow (untrusted) users to leave
> the ATM and go for a walk in the meantime.
> 
> > With full-RBF, wallets should make it extre

Re: [bitcoin-dev] Silent Payment v4 (coinjoin support added)

[alicexbt via bitcoin-dev]

Hi woltx,

Thanks for working on silent payments improving it in each version.

1) All inputs being used sounds good although I do not understand how it would 
benefit coinjoin.
2) New RPC command name is better.

> I opened a new PR (#1143) to add a function to convert from x-only to 
> compressed public key with even y. 

Not sure about the concerns expressed by Andrew Poelstra in the pull request 
related to rogue-key attacks.

> Tutorial updated: 
> https://gist.github.com/w0xlt/c81277ae8677b6c0d3dd073893210875
> "warnings": "This address is not a new identity. It is a re-use of an 
> existing identity with a different label."

I could not understand the warning in the output for `getsilentaddress` RPC 
when used with a label.

/dev/fd0

Sent with Proton Mail secure email.

--- Original Message ---
On Tuesday, October 11th, 2022 at 12:32 PM, woltx via bitcoin-dev 
 wrote:


> Silent Payment v4 (coinjoin support added)
> Changes:
> 
> . Silent payments now use all inputs to create transactions. Previously, they 
> only used the first input. This change increases privacy and makes silent 
> payments compatible with coinjoin.
> 
> . `getspaddress` RPC renamed to `getsilentaddress` for clarity
> 
> . Added support for silent payment in PSBT via `walletcreatefundedpsbt` RPC.
> 
> . Added a new index scheme (which stores the sum of input public keys for 
> each transaction). The previous index 
> `bitcoin/signet/indexes/silentpaymentindex` should be removed as it is no 
> longer compatible with this new version.
> 
> For reviewers:
> 
> Now, silent payments use the scheme `hash(i1*X + i2*X + i3*X + ...)*G + X == 
> hash(x*(I1+I2+I3+...))*G + X`, as described here: 
> https://gist.github.com/RubenSomsen/c43b79517e7cb701ebf77eec6dbb46b8#variant-using-all-inputs
> 
> As inputs can be Taproot, this introduced a new issue as 
> `bitcoin-core/secp256k1` does not support x-only public key sum (perhaps due 
> to missing prefix byte).
> 
> I opened a new PR (#1143) to add a function to convert from x-only to 
> compressed public key with even y. This is the solution being used by the 
> current silent payment implementation.
> 
> Tutorial updated: 
> https://gist.github.com/w0xlt/c81277ae8677b6c0d3dd073893210875
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Wallet Fingerprinting with nLocktime and nVersion

[alicexbt via bitcoin-dev]

Hi Bitcoin Developers,

I did some research about nLocktime and nVersion used by some open source 
Bitcoin wallets. I have written a [blog post][0] co-authored with 'nothingmuch' 
and this is the first post for the privacy focused blog 'consent':

Most wallets use nVersion 2. nLocktime for Bitcoin Core, Knots, Electrum, 
Sparrow and Specter is nearest block height. However, nLocktime for Bitcoin 
Core/Knots is zero by default if the transaction is created manually using RPC 
commands like createpsbt​ or createrawtransaction​. Peter Todd had implemented 
nLocktime based on anti-fee sniping in [#2340][1] and [#24128][2] implements 
BIP 326 sequence based anti-fee-snipe for taproot inputs.
'0xb10c' has written about wallet [fingerprinting with fee rate][3]. However, 
nLocktime and nVersion are also important. There may be other factors that 
might help if a fingerprint matches more than one wallet. Andrew Chow has build 
a [tool][4] to check if a transaction was created using Bitcoin Core or 
Electrum.

### Why is wallet fingerprinting important?

Consider the following scenario: Alice is spying on Bob and Carol. She suspects 
one of them is participating in an activity based on a transaction, but she 
cannot confirm it. She recognizes that one of the wallets that claims to 
improve privacy was used for these transactions and examines the nVersion and 
nLocktime. This makes it simpler to identify Bob, who used Wasabi wallet for 
the transaction with version 1 and nLocktime 0.

### How to fix it?

If more wallets have the same nVersion and nLocktime, it will be difficult to 
identify the wallets used for a transaction. nLocktime could be any nearest 
block height however version needs to be 2 as most of the wallets use it and it 
is used for transactions that follow new consensus rules.

Please let me know if something incorrect is mentioned or anything important 
missing about wallet fingerprinting with nLocktime and nVersion.

### Acknowledgements

- achow101
- 0xb10c
- nothingmuch- RedGrittyBrick

[0]: https://consentonchain.github.io/blog/posts/fingerprinting/
[1]: https://github.com/bitcoin/bitcoin/pull/2340
[2]: https://github.com/bitcoin/bitcoin/pull/24128
[3]: https://b10c.me/observations/03-blockchaincom-recommendations/
[4]: https://github.com/achow101/wallet-fingerprinting

/dev/fd0

Sent with [Proton Mail](https://proton.me/) secure email.___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger

[alicexbt via bitcoin-dev]

Hi Dario,

There aren't any risks with latest release of bitcoin core. However its not 
just munn or other things mentioned, even other bitcoin projects could be 
affected if [#25600][1] is merged.

Anyway I cannot comment anymore, neither in the PR or repository. I tried my 
best. Peter Todd has ACKed it and it would affect his favorite coinjoin 
implementation that works with governments.

Replacement policies are a per-node decision as Luke Dashjr said and projects 
should build upon it.

[1]: https://github.com/bitcoin/bitcoin/pull/25600

/dev/fd0

Sent with [Proton Mail](https://proton.me/) secure email.

--- Original Message ---
On Friday, October 7th, 2022 at 9:50 PM, Dario Sneidermanis via bitcoin-dev 
 wrote:

> Hello list,
>
> I'm Dario, from Muun wallet, a mobile non-custodial bitcoin wallet. For the 
> past
> few days we've been reviewing the latest bitcoin core release candidate, and 
> we
> found some troubling facts related to the opt-in full-RBF deployment.
>
> We first learned about the opt-in full-RBF proposal last June when it was
> announced on the mailing list. Closing the gap between the protocol's relay
> policies and the miner incentives is inevitable, so it was a welcomed 
> addition.
> Furthermore, allowing transaction replacements that remove the opt-in RBF flag
> was deeply problematic.
>
> At the time, we understood we had at least a year from the initial opt-in
> deployment until opt-out was deployed, giving us enough time to adapt Muun to
> the new policies. However, when reviewing the 24.0 release candidate just a 
> few
> days ago, we realized that zero-conf apps (like Muun) must *immediately turn
> off* their zero-conf features.
>
> I understand this wasn't the intention when designing the opt-in deployment
> mechanism. Given this new information, do you see a path where we can delay 
> the
> opt-in deployment and find a safer way to deploy full-RBF?
>
> It'd be great for this deployment to be a success so that we can continue 
> fixing
> the remaining relay policy problems, such as package relay and the RBF rules.
> Maybe we could go straight to an opt-out deployment locked by code at a 
> certain
> height in the future to give time to everyone and, at the same time, avoid a
> huge mempool divergence event?
>
> Below is our analysis of how zero-conf apps break with opt-in full-RBF. I hope
> it helps.
>
> Cheers,
> Dario
>
> # How do zero-conf apps work
>
> While the workings and trade-offs of zero-conf applications might be known by
> many in this list, it's useful to define precisely how they work to understand
> how they break.
>
> We call zero-conf applications to entities that accept on-chain payments from
> *untrusted parties* and will sometimes deliver the paid-for product or service
> without waiting for the transaction to be included in a block.
>
> Some examples of zero-conf apps:
>
> - Muun's submarine swaps for outgoing lightning payments
> - Bitrefill's on-chain payments for gift cards and phone top-ups
> - Many bitcoin ATMs' on-chain deposits for selling bitcoin for cash (at least
> the two biggest bitcoin ATM manufacturers support this: Genesis Coin and
> General Byte)
>
> All of these applications are receiving incoming on-chain transactions for 
> which
> they don't control the inputs, and performing a risk analysis to decide 
> whether
> they are ok with accepting the payment without confirmation.
>
> In practice, this works because once the bitcoin P2P network has fully
> propagated a non-RBF transaction, you need the collaboration of a miner to
> replace it, which isn't easy to get today. Even though many of the biggest
> miners offer off-band transaction broadcasting services, they currently won't
> process conflicting transactions.
>
> Roughly, the risk analysis goes like this:
>
> 1. if an incoming transaction is RBF (direct or inherited)
> --> too risky, wait for 1 conf (or more) since it can be replaced at any time
> 2. if the payment is for an amount greater than X
> --> too risky, wait for 1 conf (or more), since the amount is worthy of a
> sophisticated attacker
> 3. wait for full(ish) propagation of the incoming transaction
> 4. if there's no double-spend attempt
> --> accept 0-conf
>
> As with any other risk analysis, there's always a false-negative detection 
> rate,
> leading to an expected loss, which the zero-conf app should be willing to 
> bear.
> Notice that the expected loss is tunable via the amount X in the above 
> analysis.
>
> # Why are zero-conf apps not protected with an opt-in deployment
>
> Full-RBF adoption works on three different layers:
>
> - The transaction application layer
> - The transaction relaying layer
> - The transaction mining layer
>
> If an application wants to replace with full-RBF an *outgoing* transaction, it
> will need:
>
> - An upgraded node that opted into full-RBF, from which it can broadcast the
> replacement transaction
> - A connected component of upgraded nodes that opted into full-RBF, that

Re: [bitcoin-dev] bitcoin-inquistion: evaluating soft forks on signet

[alicexbt via bitcoin-dev]

Hi Michael,

> We then get into the situation where the block signers (currently AJ and 
> Kalle) are the gatekeepers on what soft fork proposals are added.

Things that could solve the gatekeeping issue:

1) Adding more maintainers that are experienced enough to review consensus 
code. 
2) Every soft fork that is implemented on signet should be discussed on mailing 
list before merging the pull request.
3) Pull request that implements a soft fork should have at least 2 ACKs from 
the maintainers, 3 ACKs from developers who have either authored or reviewed 
enough consensus related pull requests in bitcoin core and 1 ACK from 
maintainers of other implementations (knots, btcd, libbitcoin, bcoin etc.)
4) Every technical NACK from any developer or user in the pull request should 
be resolved/answered before merging the pull request.

This was not the case in [implementing BIP][1] 119 however it could be used in 
future or something similar that everyone agrees upon including AJ and Kalle. 
Pull request implementing BIP 119 in bitcoin core is already reviewed by lot of 
developers and I think AJ found a [bug][2] recently.

Gatekeeping at several levels already exists in bitcoin development and 
difficult to solve. If some developers believe a soft fork should have been 
implemented on global signet but it was not, there is always the possibility of 
running custom signet with certain trade-offs.

> The default signet is directly supported with the -signet flag in Bitcoin 
> Core. Even if we are moving the proposed soft fork code to an external repo 
> (to avoid it being merged into Core prematurely) it is still determining what 
> soft forks are accessible from the signet flag in Bitcoin Core. I don't think 
> it is fair on the signet block signers to put them in that position and I 
> don't think it is wise to put other Bitcoin Core contributors/maintainers in 
> the position of having to defend why some proposed soft forks are accessible 
> on the default signet while others aren't.

Mainnet and Testnet have already been [removed][3] from the 
'bitcoin-inquisition/bitcoin' repository, and signet in bitcoin core is largely 
used by developers or power users, thus it should not be a problem. Signet 
could also be removed from bitcoin core binaries that are released regularly 
while being available if built from source.

Since signet coins have no value, utilizing this chain to experiment with soft 
forks will only help the bitcoin development process. If we can't even agree to 
implement something on a network used for testing then it will be nearly 
impossible to do any soft forks on mainnet. This experiment has several 
advantages. We can implement many consensus changes and compare alternatives in 
a better way. Pre-baked ability to abandon the soft fork isn't implemented yet 
AFAIK, however that could further improve things.


[1]: https://github.com/bitcoin-inquisition/bitcoin/pull/3
[2]: https://github.com/bitcoin/bitcoin/pull/21702#discussion_r979273387
[3]: https://github.com/bitcoin-inquisition/bitcoin/pull/1

/dev/fd0

Sent with Proton Mail secure email.


--- Original Message ---
On Wednesday, September 28th, 2022 at 5:18 PM, Michael Folkson via bitcoin-dev 
 wrote:


> I've given this some extra thought and discussed with others who may later 
> chime in on this thread. I'm now convinced this should be done on a custom 
> public signet rather than on the default signet. SegWit was added to a new 
> testnet (Segnet) for testing rather than the pre-existing testnet and I think 
> future soft fork proposals should follow a similar approach.
> 
> Even if there is community consensus on what soft fork proposals should be 
> added to the default signet today (which may or may not be case) I find it 
> highly unlikely this will always be the case. We then get into the situation 
> where the block signers (currently AJ and Kalle) are the gatekeepers on what 
> soft fork proposals are added. The default signet is directly supported with 
> the -signet flag in Bitcoin Core. Even if we are moving the proposed soft 
> fork code to an external repo (to avoid it being merged into Core 
> prematurely) it is still determining what soft forks are accessible from the 
> signet flag in Bitcoin Core. I don't think it is fair on the signet block 
> signers to put them in that position and I don't think it is wise to put 
> other Bitcoin Core contributors/maintainers in the position of having to 
> defend why some proposed soft forks are accessible on the default signet 
> while others aren't.
> 
> The default signet was a long term project to address the unreliability and 
> weaknesses of testnet. Many default signet users won't be interested in 
> testing soft fork proposals and it is not reasonable for them to be subject 
> to a stalling or forked blockchain because changes to a soft fork proposal or 
> a buggy soft fork proposal pushed to the default signet makes previous 
> valid/invalid transactions inval

Re: [bitcoin-dev] Packaged Transaction Relay

[alicexbt via bitcoin-dev]

Hi Eric,


> If by "range" you mean a connected tx subgraph, I don't see why not. But note 
> that nodes only operate over signed txs. PSBT is a wallet workflow.

Matt Corallo mentioned that pre-signed transactions created with low fee rate 
become an issue when they are broadcasted after a long time and there is a high 
demand for block space at that moment.

Example: 

Bob created PSBT1 in a multi party contract with fee rate 5 sat/vbyte however 
its taking hours/days to confirm the transaction with such low fee rate.

Carol created PSBT1 (5 sat/vbyte), PSBT2 (10 sat/vbyte) and PSBT3 (20 
sat/vbyte) for spending same inputs. She broadcasted PSBT3 which got confirmed 
in a few minutes. 


> Always. Only signed transactions are accepted. But assuming you are referring 
> to a transaction that has been produced by a pre-signing workflow, I'm not 
> sure how this would be distinct from any other tx.


`minfeefilter` for all peers of my node was 0.1000 at the time of writing 
this email. I am assuming nobody creates pre-signed transaction with fee rate 
below 1 sat/vbyte. How often does it happen that `minfeefilter` is above this 
default value?


> I'm not sure I follow this, maybe you could reword it. But it seems that you 
> are saying that CPFP fee-bumping is a problem scenario and the complexity of 
> the proposed solutions are not justified by such scenarios.


Sorry that sentence was confusing. Yes complexity isn't justified for CPFP 
fee-bumping txs below minimum fee rate.


> There are many node implementations used presently. And of course these are 
> protocol proposals, which presumes more than one implementation.


Yes, a few implementations exist (knots, libbitcoin, btcd, bcoin etc.) however 
they aren't used by lot of nodes. Based on this [chart][1] 98% nodes use 
bitcoin core. Lot of bitcoin protocol proposals are influenced by bitcoin core 
contributors and things could be different if even 30% nodes used other 
implementations.


> I don't consider this relevant to any protocol considerations. Miners should 
> always be expected to select the most optimal set of txs available in the 
> time available to do so.


Agree, miners should be expected to select most optimal set of txs. However, 
according to one [comment][2] by Pieter Wuille, miners could affect the 
security of some bitcoin projects with MEV.


> Over time we are likely to see that the only policies that remain in 
> widespread application are those that are necessary for DOS protection (fee 
> rate), as other restrictions are not economically rational and cannot be 
> enforced. We've seen recent debate regarding dust policy, and op_return 
> policy. "non-standard" txs are perfectly valid but get stuck very easily. 
> I'll reiterate, any policy beyond what is published via the protocol will 
> cause the above problems.

I completely agree with this.


[1]: https://luke.dashjr.org/programs/bitcoin/files/charts/software.html
[2]: 
https://bitcoin.stackexchange.com/questions/107787/front-running-in-bitcoin#comment123441_107796


/dev/fd0

Sent with Proton Mail secure email.

--- Original Message ---
On Tuesday, September 27th, 2022 at 2:49 AM,  wrote:


> > Hi Eric,
> > 
> > This email wasn't answered by anyone on mailing list however I did some
> > research about packages yesterday including this email and below are my
> > observations, questions etc.
> 
> 
> Hello, thanks for the reply.
> 
> > > The sole objective, as expressed in the OP proposal, is to:
> > > 
> > > "Propagate transactions that are incentive-compatible to mine, even if 
> > > they
> > > don't meet minimum feerate alone."
> > 
> > According to bitcoinops: Without package relay, it’s not possible to
> > effectively CPFP fee bump a transaction that’s below the minimum feerate
> > nodes accept.
> 
> 
> Yes, the problem statement is not in question, just the mechanism of 
> resolution. The problem of stuck txs arises from minimum fee rate policy, 
> which is a necessary DOS guard.
> 
> A secondary issue is that of orphan relay. As a node must allow receipt of 
> orphans, it has no means to differentiate a flood of unconfirmable txs from 
> those that are confirmable.
> 
> > Matt Corallo's thoughts in a bitcoin core issue:
> > 
> > "Matt Corallo recently wrote about an example on the bitcoin-dev mailing 
> > list
> > involving lightning transactions, where pre-signed transactions might be
> > broadcast to the blockchain long after they were generated, and thus not
> > have been created with a fee that is sufficient to be confirmed quickly (or
> > even be accepted to node mempools). In such situations, channel
> > participants may need to use chained transactions (CPFP) in order to 
> > increase
> > the confirmation speed of such transactions, and that implies we may need
> > to introduce a mechanism for those parent transactions to be relayed along
> > with their higher feerate children, even if the parent transaction would be
> > rejected by itself."
> 
> 

Re: [bitcoin-dev] Packaged Transaction Relay

[alicexbt via bitcoin-dev]

Hi Eric,


This email wasn't answered by anyone on mailing list however I did some 
research about packages yesterday including this email and below are my 
observations, questions etc.

> The sole objective, as expressed in the OP proposal, is to:
> 
> "Propagate transactions that are incentive-compatible to mine, even if they 
> don't meet minimum feerate alone."


According to [bitcoinops][1]: Without package relay, it’s not possible to 
effectively CPFP fee bump a transaction that’s below the minimum feerate nodes 
accept.

Matt Corallo's thoughts in a bitcoin core [issue][2]:

"Matt Corallo recently wrote about an example on the bitcoin-dev mailing list 
involving lightning transactions, where pre-signed transactions might be 
broadcast to the blockchain long after they were generated, and thus not have 
been created with a fee that is sufficient to be confirmed quickly (or even be 
accepted to node mempools). In such situations, channel participants may need 
to use chained transactions (CPFP) in order to increase the confirmation speed 
of such transactions, and that implies we may need to introduce a mechanism for 
those parent transactions to be relayed along with their higher feerate 
children, even if the parent transaction would be rejected by itself."

1)Is it possible to have multiple pre-signed transactions with different fee 
rates in a range? Example: PSBT1: 5 sat/vbyte, PSBT2: 10 sat/vbyte, PSBT3: 20 
sat/vbyte and PSBT4: 100 sat/vbyte
2)How would covenants affect this problem?
3)How often does it happen that a pre-signed tx gets rejected by nodes because 
it did not meet the minimum fee rate? Is it predictable and could be managed in 
a different way?

After reading several links related to packages and bitcoin core pull requests, 
I found it anti-bitcoin to introduce so much complexity because its not 
possible to CPFP fee bump a tx below minimum fee rate. 


> Furthermore any tx that is "stuck" can be freed by simply sending another tx. 
> The nodes at which the tx has become stuck will just package it up and relay 
> it to peers. In other words, there is no impact on wallet implementation 
> apart from raising the aggregate fee using a descendant transaction.

It is easy to send another tx if there is only one user involved however 
packages are trying to fix issues in which multiple users and transaction 
pre-signed between them are involved. So, it will be difficult to coordinate 
and create new pre-signed transactions in some cases although it is possible 
for some use cases.


> This is barely a protocol change - it's primarily implementation. All that 
> should be required is an additional INV element type, such as MSG_TX_PACKAGE.

> * All elements of MSG_TX_PACKAGE in one INV message MUST to be of the same 
> package.
> * A package MUST must define a set that can be mined into one block 
> (size/sigops constraint).
> * A package SHOULD not contain confirmed txs (a race may cause this).
> * A package MUST minimally satisfy peer.feerate.
> * A partial tx order, as in the manner of the block.txs ordering, MUST be 
> imposed.
> * A node SHOULD drop a peer that sends a package (or tx) below node.feerate.
> * A node MAY drop a peer that sends a non-minimal package according to 
> node.feerate.

This makes sense particularly if multiple node implementations are used in 
future. 

My other questions:

a)If a package has tx1, tx2, tx3, tx4 and tx5 and miner just include tx1 and 
tx2 in the block, how does this affect the projects considered for packages 
proposal?

b)How does changing the order of txs in a package affect these transactions?

c)Do packages introduce more attack vectors in bitcoin for front running or 
MEV? MEV in bitcoin currently only affects the projects that are considered in 
packages proposal.

d)What if the package contains a transactions with sanctioned address?

e)Why would miners use packages if the existing scenario in terms of fees per 
block is beneficial for them?


/dev/fd0

[1]: https://bitcoinops.org/en/topics/package-relay/
[2]: https://github.com/bitcoin/bitcoin/issues/14895

Sent with Proton Mail secure email.

--- Original Message ---
On Thursday, June 9th, 2022 at 4:13 AM, Eric Voskuil via bitcoin-dev 
 wrote:


> Hi Suhas/Gloria,
> 
> Good questions. I've started a new thread because it became something else...
> 
> Various ideas about packaging seem to be focused on the idea of an atomic 
> message that is gossiped around the network like a transaction or block. From 
> my perspective that seems to create a set of problems without good solutions, 
> and it is not a proper analogy to those atomic structures. It may be worth 
> taking the time to step back and take a close look at the underlying 
> objective.
> 
> The sole objective, as expressed in the OP proposal, is to:
> 
> "Propagate transactions that are incentive-compatible to mine, even if they 
> don't meet minimum feerate alone."
> 
> Effectively producing this outcome with an atomic

Re: [bitcoin-dev] bitcoin-inquistion: evaluating soft forks on signet

[alicexbt via bitcoin-dev]

Hi Michael,

> I agree with Matt. The less said about the "Aw shucks Jeremy didn't know that 
> CTV didn't have community consensus at the time" [0] and "it was the lack of 
> process that was the problem" the better. 

The linked gist cannot be taken seriously and I am not sure why you keep 
sharing it as some document to prove there was no technical consensus for BIP 
119. Nadav has already mentioned this in the comments. If you care about 
community consensus, maybe feedback about the links in that gist should also be 
respected. There was chaos, misinformation and lot of drama on twitter. Some 
people that opposed CTV on twitter still have no clue what CTV actually does 
and a few were super enthusiastic because of the author for BIP 119.

> I'm not convinced by the name (bitcoin-inquisition, shedpaint, shedpaint, 
> let's park that for the moment) but I do like the idea of signet having soft 
> fork proposals enabled on it [1] whether that be CTV, APO etc and if that 
> requires more of the signet code to be moved out of the Core repo so be it.

Good to see some positivity, finally. Because tx introspection aka covenants 
would help everyone involved in bitcoin. This idea of experimenting with soft 
forks on signet together with research and meetings suggested by Antoine should 
help in better evaluation phase with less drama, politics etc. and more 
technical discussions to reach a goal.

> I'm surprised more isn't being done on Liquid already with what possible 
> future functionality is (and could be) enabled [2] there but maybe there is 
> more happening than I'm aware of. 

1)Nobody uses Liquid. Signet has more activity than Liquid.
2)Testing something on Liquid will be completely different as its a separate 
blockchain with some similarities.

I have summarized a few other positives of testing soft forks on signet based 
on AJ's email:

a)Better evaluation
b)PR implementing soft fork could be reviewed and merged outside core
c)Testing on signet with pre-existing signet infrastructure
d)Can deploy multiple consensus changes so easier to compare alternative 
approaches (eg CTV vs ANYPREVOUT vs OP_TXHASH vs OP_TX, etc)
e)Pre-baked ability to abandon the soft fork
f)No need to regularly rebase consensus changes against bitcoin core's master 
branch

/dev/fd0

Sent with Proton Mail secure email.

--- Original Message ---
On Saturday, September 17th, 2022 at 3:53 PM, Michael Folkson via bitcoin-dev 
 wrote:


> I agree with Matt. The less said about the "Aw shucks Jeremy didn't know that 
> CTV didn't have community consensus at the time" [0] and "it was the lack of 
> process that was the problem" the better. If people don't care about lack of 
> community consensus there is no process in a permissionless, open source 
> community that can stop them or direct them down a more patient, productive 
> path (I tried). I think it is a shame because I think (maybe I'm wrong) at 
> least in the technical community there is an understanding that long term 
> Bitcoin is far from finished in exhausting its potential and we do need 
> people who will work on changes that we'll need in the long term.
> 
> There are a few interesting things in here though. I'm not convinced by the 
> name (bitcoin-inquisition, shedpaint, shedpaint, let's park that for the 
> moment) but I do like the idea of signet having soft fork proposals enabled 
> on it [1] whether that be CTV, APO etc and if that requires more of the 
> signet code to be moved out of the Core repo so be it. I'm surprised more 
> isn't being done on Liquid already with what possible future functionality is 
> (and could be) enabled [2] there but maybe there is more happening than I'm 
> aware of. Protocols or use cases built out and demonstrated on signet (and/or 
> Liquid/sidechains) seem an obvious stepping stone to me for convincing the 
> community that it is potentially worth taking the chain split risk for a 
> particular upgrade. It is a long slog to get community consensus on an 
> upgrade (Taproot certainly was a slog) but I think the vast majority of us 
> think Taproot was worth that slog and Bitcoin would be poorer today without 
> it.
> 
> The Great Consensus Cleanup is an interesting example in that I get Matt 
> doesn't have time to champion it or focus on it with his LDK commitments but 
> I have no idea where it would rank on his long term priority list if he 
> wasn't working on LDK. Similarly I have no idea what people who understand 
> this evolving system much better than I do are thinking with regards to say 
> adding new opcodes, sighash flags versus say waiting on Simplicity and 
> possibly adding new functionality within that potential upgrade. For people 
> like me who are extremely unlikely to propose their own consensus change(s) 
> getting some signal on what to spend time digging into would be useful rather 
> than second guessing what people are thinking. There is a danger that you 
> flirt with perceived public roadmap

Re: [bitcoin-dev] Full Disclosure: Denial of Service in STONEWALLx2 (p2p coinjoin)

[alicexbt via bitcoin-dev]

This has been assigned CVE-2022-35913: 
https://www.cve.org/CVERecord?id=CVE-2022-35913

/dev/fd0

Sent with Proton Mail secure email.

--- Original Message ---
On Thursday, July 14th, 2022 at 9:25 AM, alicexbt via bitcoin-dev 
 wrote:


> Hi bitcoin-dev list members,
> 
> 
> STONEWALLx2[1] is a p2p coinjoin transaction in Samourai wallet. The miner 
> fee is split between both participants of the transaction.
> 
> 
> ==
> Problem
> ==
> 
> Antoine Riard shared the details of DoS attack in an [email][2] on 21 June 
> 2022.
> 
> Proof of Concept:
> 
> 1) Download Samourai APK, create testnet wallet, get some coins from faucet 
> and claim a paynym in 2 android devices. Consider Bob and Carol are using 
> these devices.
> 
> 2) Bob and Carol follow each other's paynyms. Carol is the attacker in this 
> case and she could make several paynyms.
> 
> 3) Bob initiates a Stonewallx2 transaction that requires collaboration with 
> Carol.
> 
> 4) Carol confirms this request in the app.
> 
> 5) Carol spends the UTXO from wallet configured in electrum with same seed 
> before Bob could complete the last step and broadcast STONEWALLx2 
> transaction. It was non RBF [transaction][3] with 1 sat/vbyte fee rate and 
> was unconfirmed during testing.
> 
> 6) Bob receives an [error][4] in the app when trying to broadcast Stonewallx2 
> transaction which disappears in a few seconds. The [progress bar][5] appears 
> as if wallet is still trying to broadcast the transaction until Bob manually 
> go back or close the app.
> 
> 
> ==
> Solution
> ==
> 
> Suggestions:
> 
> a) Error message that states collaborator spent her UTXO used in STONEWALLx2, 
> end the p2p coinjoin process, unfollow collaborator's paynym and suggest user 
> to do such transactions with trusted users only for a while.
> 
> b) Once full RBF is used by some nodes and miners, attacker's transaction 
> could be replaced with a higher fee rate.
> 
> Conclusions by Samourai:
> 
> a) As the threat involves the collaborator attacking the spender. We strongly 
> advise that collab spends be done w/ counterparties with which some measure 
> of trust is shared. As such, this does not seem to have an important threat 
> surface.
> 
> b) Bumping fee won't be simple as fees are shared 50/50 for STONEWALLx2 
> spends. Change would have to be recalculated for both spender and 
> collaborator. Collab would either have had already authorized a possible fee 
> bump beforehand or would have to be prompted before broadcast.
> 
> 
> ==
> Timeline
> ==
> 
> 22 June 2022: I emailed Antoine after testing STONEWALLx2
> 
> 23 June 2022: I shared the details of attack in a confidential issue in 
> Samourai wallet [repository][6]
> 
> 07 July 2022: TDevD (Samourai) acknowledged the issue and wanted to discuss 
> it internally with team
> 
> 14 July 2022: TDevD shared the conclusions
> 
> 
> ==
> Credits
> ==
> 
> Antoine Riard discovered DoS vector in p2p coinjoin transactions and helped 
> by responding to emails during testing.
> 
> 
> [1]: https://docs.samourai.io/spend-tools
> [2]: 
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020595.html
> [3]: 
> https://mempool.space/testnet/tx/42db696460a46f196f457779d60acbf46b31accc5414b9eac54b2e785d4c1cbb
> [4]: https://i.imgur.com/6uf3VJn.png
> [5]: https://i.imgur.com/W6ITl4G.gif
> [6]: https://code.samourai.io/wallet/samourai-wallet-android
> 
> 
> /dev/fd0
> 
> 
> Sent with Proton Mail secure email.
> 
> ___
> 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] joinstr: coinjoin implementation using nostr

[alicexbt via bitcoin-dev]

Hi woltx,

> I've been reviewing joinstr, and if I understand the code correctly, the 
> cryptographic scheme mentioned as an alternative to blind signatures isn't 
> implemented yet, is it? Currently, it seems that anyone can submit unrelated 
> inputs and outputs.

Thanks for reviewing joinstr. Yes, its not implemented right now as it requires 
a NIP and at least one relay using it.

> Instead of clients sending descriptors to the relay and then verifying them 
> using `scantxoutset`, it can send `txid:out` with a message signed with the 
> address, verify using `verifymessage` and then use `gettxout` to retrieve the 
> value. That way, only the owner can send the UTXO.

`scantxoutset` is only used to get UTXO details (txid, vout and amount) as I 
thought its easier for users to just share a descriptor for coinjoin. 

If a user sends `txid:out` with a message signed with the address, this would 
be publicly available to everyone connected to same relay and links an input 
with output. Responding with a secret shared by relay for the round confirms 
user owns one of the input but does not reveal exact input.


/dev/fd0


Sent with Proton Mail secure email.

--- Original Message ---
On Friday, September 9th, 2022 at 9:05 PM, woltx  wrote:


> Hi /dev/fd0,
> 
> I've been reviewing joinstr, and if I understand the code correctly, the 
> cryptographic scheme mentioned as an alternative to blind signatures isn't 
> implemented yet, is it? Currently, it seems that anyone can submit unrelated 
> inputs and outputs.
> 
> Perhaps PR #24058 (https://github.com/bitcoin/bitcoin/pull/24058) (basic 
> support BIP-322) can improve this scheme as it implements proof of ownership.
> 
> Instead of clients sending descriptors to the relay and then verifying them 
> using `scantxoutset`, it can send `txid:out` with a message signed with the 
> address, verify using `verifymessage` and then use `gettxout` to retrieve the 
> value. That way, only the owner can send the UTXO.
> 
> I've done some tests connected to a node with BIP322 enabled:
> 
> # to send
> input_txt: str = json.dumps(input)
> result = core.signmessage(wallet, input['address'], input_txt)
> input['signature'] = result['result']
> nostr_interface.publish_input(input)
> 
> # to receive
> def validate_input(input: dict[str, int, str, str]) -> bool:
> 
> # ...
> result = core.verifymessage(address=input['address'], 
> message=json.dumps(message), signature=input['signature'])
> return result['error'] == None and result['result'] == True
> 
> 
> 
> 
> 
> --- Original Message ---
> On Saturday, August 20th, 2022 at 1:52 PM, alicexbt via bitcoin-dev 
> bitcoin-dev@lists.linuxfoundation.org wrote:
> 
> 
> 
> > Hi Max,
> > 
> > There a few DoS vectors that need to be fixed. Its just a proof of concept 
> > that I wanted to share with everyone to get feedback which could be 
> > improved over time. There is also a warning at the bottom of README to not 
> > use this on mainnet as it might have bugs.
> > 
> > I will continue the development with coinjoin transactions on signet for a 
> > few weeks until there is a stable release with no bugs.
> > 
> > I have a few ideas in mind for various relay types that might be used 
> > concurrently to prevent numerous problems. Custom relays are supported by 
> > Nostr. Examples include paying a fee to register for a round, subscribing 
> > with a time limit, or using invite-only relays. I will run a free and open 
> > nostr relay for this project and try to fix the Dos issues before a mainnet 
> > version is released for python script(for nerds) and android app (for all 
> > users).
> > 
> > Related links:
> > 
> > https://github.com/fiatjaf/relayer
> > https://github.com/fiatjaf/expensive-relay
> > https://github.com/fiatjaf/relayer/tree/master/whitelisted
> > 
> > /dev/fd0
> > 
> > Sent with Proton Mail secure email.
> > 
> > --- Original Message ---
> > On Saturday, August 20th, 2022 at 10:04 AM, Max Hillebrand 
> > m...@towardsliberty.com wrote:
> > 
> > > Great to see an implementation of the idea.
> > > 
> > > Maybe I misunderstand, but isn't there a vulnerability of denial of 
> > > service here?
> > > 
> > > A user who registers one input will receive the round secret identifier, 
> > > and this is all the information required for output registration. 
> > > However, that malicious user can now register multiple outputs, providing 
> > > the same secret, and nobody can l

Re: [bitcoin-dev] joinstr: coinjoin implementation using nostr

[alicexbt via bitcoin-dev]

Hi Max,

There a few DoS vectors that need to be fixed. Its just a proof of concept that 
I wanted to share with everyone to get feedback which could be improved over 
time. There is also a warning at the bottom of README to not use this on 
mainnet as it might have bugs.

I will continue the development with coinjoin transactions on signet for a few 
weeks until there is a stable release with no bugs. 

I have a few ideas in mind for various relay types that might be used 
concurrently to prevent numerous problems. Custom relays are supported by 
Nostr. Examples include paying a fee to register for a round, subscribing with 
a time limit, or using invite-only relays. I will run a free and open nostr 
relay for this project and try to fix the Dos issues before a mainnet version 
is released for python script(for nerds) and android app (for all users).

Related links: 

https://github.com/fiatjaf/relayer
https://github.com/fiatjaf/expensive-relay
https://github.com/fiatjaf/relayer/tree/master/whitelisted

/dev/fd0


Sent with Proton Mail secure email.

--- Original Message ---
On Saturday, August 20th, 2022 at 10:04 AM, Max Hillebrand 
 wrote:


> Great to see an implementation of the idea.
> 
> Maybe I misunderstand, but isn't there a vulnerability of denial of service 
> here?
> 
> A user who registers one input will receive the round secret identifier, and 
> this is all the information required for output registration. However, that 
> malicious user can now register multiple outputs, providing the same secret, 
> and nobody can link the malicious outputs to any specific input. Therefor 
> there cannot be a blame round where the malicious input is removed, and thus 
> there can be a ongoing free denial of service attack without attribution or 
> defense.
> 
> Skol
> Max
> 
> 
> On August 20, 2022 10:20:00 AM GMT+02:00, alicexbt via bitcoin-dev 
>  wrote:
> 
> > Hi Bitcoin Developers,
> > 
> > I have written a python script as proof of concept for the [coinjoin 
> > implementation][1] using [nostr][2]. I used a lot of Python scripts created 
> > by others in school, so it feels nice to offer something that could be 
> > useful to others.
> > 
> > The implementation uses Bitcoin Core wallet and RPCs: `listunspent`, 
> > `getnewaddress`, `scantxoutset`, `createpsbt`, `combinepsbt`, 
> > `finalizepsbt` and `sendrawtransaction`. It requires python-nostr library 
> > because nostr is used for coordination between peers. Nostr is a 
> > decentralized network based on cryptographic keypairs. It is not 
> > peer-to-peer however simple and scalable.
> > 
> > Every step is published as an event using a nostr relay and 5 peers 
> > coordinate to create, sign and broadcast a coinjoin transaction.  I need to 
> > write a NIP that would be an alternative to blind signatures. Relay will 
> > share a random secret with clients for one round which should be present in 
> > output registration request although never gets published. If someone tries 
> > to register an output without registering any inputs, request would not 
> > have the number initially shared with inputs so request would get rejected 
> > or published as unverified. Relay would not be able to link inputs and 
> > outputs as the number is same for all inputs in a round and they get 
> > registered at different times with new keys and IP address. Clients can use 
> > multiple relays at the same time to avoid trusting one relay. This would 
> > result in different shared secret number but same process. If a relay tries 
> > to cheat, users will not sign the transaction and avoid using it in future.
> > 
> > Usage:
> > 
> >  1)Run `python coinjoin.py` and enter descriptor for one of the inputs.
> >  2)Script will check inputs for this round in every 30 seconds and register 
> > a new adddress for output once 5 inputs are registered.
> >  3)Similar check happens every 30 seconds for outputs. Last peer should 
> > create a PSBT.
> >  4)Unsigned PSBT will be printed and signed by wallet with 
> > `walletprocesspsbt` RPC.
> >  5)Script will check signed PSBTs and last peer to sign should finalize 
> > coinjoin transaction once 5 signed PSBTs are received.
> >  6)Coinjoin transaction will be broadcasted and txid will printed.
> > 
> > Example:
> > 
> > ```
> > List of utxos in wallet:
> > 
> > wpkh([53830dca/84'/1'/0'/0/0]02449be5fb74725255eeeb50eba930fa87705f21e99d13cd710cf2c1f21153c808)#x2hyyeg5
> > 
> > Enter descriptor for the input registration: 
> > wpkh([53830dca/84'/1'/0'/0/0]02449be5fb74725255eeeb50eba930fa87705f21e99d13cd710

[bitcoin-dev] joinstr: coinjoin implementation using nostr

[alicexbt via bitcoin-dev]

Hi Bitcoin Developers,

I have written a python script as proof of concept for the [coinjoin 
implementation][1] using [nostr][2]. I used a lot of Python scripts created by 
others in school, so it feels nice to offer something that could be useful to 
others.

The implementation uses Bitcoin Core wallet and RPCs: `listunspent`, 
`getnewaddress`, `scantxoutset`, `createpsbt`, `combinepsbt`, `finalizepsbt` 
and `sendrawtransaction`. It requires python-nostr library because nostr is 
used for coordination between peers. Nostr is a decentralized network based on 
cryptographic keypairs. It is not peer-to-peer however simple and scalable.

Every step is published as an event using a nostr relay and 5 peers coordinate 
to create, sign and broadcast a coinjoin transaction.  I need to write a NIP 
that would be an alternative to blind signatures. Relay will share a random 
secret with clients for one round which should be present in output 
registration request although never gets published. If someone tries to 
register an output without registering any inputs, request would not have the 
number initially shared with inputs so request would get rejected or published 
as unverified. Relay would not be able to link inputs and outputs as the number 
is same for all inputs in a round and they get registered at different times 
with new keys and IP address. Clients can use multiple relays at the same time 
to avoid trusting one relay. This would result in different shared secret 
number but same process. If a relay tries to cheat, users will not sign the 
transaction and avoid using it in future.

Usage:

 1)Run `python coinjoin.py` and enter descriptor for one of the inputs.
 2)Script will check inputs for this round in every 30 seconds and register a 
new adddress for output once 5 inputs are registered.
 3)Similar check happens every 30 seconds for outputs. Last peer should create 
a PSBT.
 4)Unsigned PSBT will be printed and signed by wallet with `walletprocesspsbt` 
RPC.
 5)Script will check signed PSBTs and last peer to sign should finalize 
coinjoin transaction once 5 signed PSBTs are received.
 6)Coinjoin transaction will be broadcasted and txid will printed.

Example:

```
List of utxos in wallet:

wpkh([53830dca/84'/1'/0'/0/0]02449be5fb74725255eeeb50eba930fa87705f21e99d13cd710cf2c1f21153c808)#x2hyyeg5

Enter descriptor for the input registration: 
wpkh([53830dca/84'/1'/0'/0/0]02449be5fb74725255eeeb50eba930fa87705f21e99d13cd710cf2c1f21153c808)#x2hyyeg5

event id:  bcbbe62d75d99fed73f1e50ac58a38d1840b658951893e63c0322b378d7d56f0

```
```
tb1qhxrp4zl54ul0twtyz0gury5399q7z0kvqqrl6m registered for output

event id: 9449c9065bef356d21507a98f88b028b17fc1c49eb195c8d4420604fcaaef041
```
```
Unsigned PSBT: 
cHNidP8BAP1yAQIFtMaoJYcXvOG5L3Yaz3YyS7gIt4h5/zzOrRRS3hrVvwoAAP+o83geaSm4L76KToIUl5MiZqLAUbIDJLq6DWrjP/3b8AEA/zEF3CXIvVHpIa7No1s1yg+KtyOfXTRSyWnOdXMfzcDwAQD/wMa4XAgnU+39Ien+KG9rYtv8bLMNYakmZyY/QFfwLRcAAP/5M42ID6uLmQTb2tnFHnN7UMpnDD25uN8ZX7A+GNSM3QEA/wV4xwEAABYAFLmGGov0rz71uWQT0cGSkSlB4T7MeMcBAAAWABSc0/FM6Hdbdxh10IJkYOklVFWqjnjHAQAAFgAUPSZKe/w6PT6qIF+WhL4wHaFymjd4xwEAABYAFMx0rxYlpPWB3NFry4Ctk2eVi/UNeMcBAAAWABSzc4xK0VTfvjK0MHXrAUFLYgYnOg==

event id: 976744b38fa9343fb79e1b5215512ead6ee08e5890d79a201fc5b872f6de4eba
```
```
Signed PSBT: 
cHNidP8BAP1yAQIFtMaoJYcXvOG5L3Yaz3YyS7gIt4h5/zzOrRRS3hrVvwoAAP+o83geaSm4L76KToIUl5MiZqLAUbIDJLq6DWrjP/3b8AEA/zEF3CXIvVHpIa7No1s1yg+KtyOfXTRSyWnOdXMfzcDwAQD/wMa4XAgnU+39Ien+KG9rYtv8bLMNYakmZyY/QFfwLRcAAP/5M42ID6uLmQTb2tnFHnN7UMpnDD25uN8ZX7A+GNSM3QEA/wV4xwEAABYAFLmGGov0rz71uWQT0cGSkSlB4T7MeMcBAAAWABSc0/FM6Hdbdxh10IJkYOklVFWqjnjHAQAAFgAUPSZKe/w6PT6qIF+WhL4wHaFymjd4xwEAABYAFMx0rxYlpPWB3NFry4Ctk2eVi/UNeMcBAAAWABSzc4xK0VTfvjK0MHXrAUFLYgYnOgAAAQBxAgG+qpMXZCy6tBuUlgo8JD0GVXKp60FkhwDeg2sF1fkFkwMA/f///wLo9wEAABYAFFfLA5xarC/w/SxeMDQ5tuXrYJLUWwMWABRfPf//hwMjHB4OKj87cU19XOSh7yOWAQABAR/o9wEAABYAFFfLA5xarC/w/SxeMDQ5tuXrYJLUAQhrAkcwRAIgOIhLoC5348U8YkEr4GU1K4yWskIOEXgW4Wsk/W2cR7ICIEJXqtOuDJ5CkwrSuwJLWtzab4dslbN3KuL/pyooMnOCASECRJvl+3RyUlXu61DrqTD6h3BfIemdE81xDPLB8hFTyAgAACICA77Cnd6o3kr0yc+91eabpOn5igs/MUMbudNYSS6oyMWMGFODDcpUAACAAQAAgIAAFAAA

event id: 5846b6e6902f3c5a43496d7d9785ed62444aa74963f03c33d637d8b09ee7a139
```
```
Coinjoin tx: 75e490b10b15a6a0422f25ff66ad98ef70390c8fecaac02712705dce8cc3564b

event id: 9b5d4bf279b59e2b6e539e683fba83da72dce2b640360aa95db1b1400be93190
```

There are lot of things that could be improved and a few suggestions are in the 
gist that described the [idea][3]. I would love read to any opinions about this 
experiment and will start working on creating an Android app for joinstr next 
week.

Credits:

- fiatjaf (Nostr)
- Andrew Chow (PSBT)
- Jeff Thibault (python-nostr)
- Existing coinjoin implmentations

[1]: https://github.com/144bytes/joinstr
[2]: https://github.com/nostr

Re: [bitcoin-dev] P2P trading replacement transactions

[alicexbt via bitcoin-dev]

Hi Ali,

> It would probably only work out if each output got their own private keys, 
> since otherwise Alice can't share any outputs with Bob and vice versa.
> The whole thing sounds like an HTLC with an additional trading of private 
> keys for the actual trades instead of in the HLTC. How are they going to 
> share their private keys securely, with PGP?

Alice and Bob can share outputs and these are swapped in the replacement 
transactions. A 2of3 multisig and Carol is required so that nobody cheats. 
Trading of private keys is not required. I have explained things in a different 
way in my [last email][1] sent to Michael Folkson.

[1]: 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-August/020841.html

/dev/fd0

Sent with Proton Mail secure email.

--- Original Message ---
On Saturday, August 6th, 2022 at 7:46 PM, Ali Sherief  
wrote:


> It would probably only work out if each output got their own private keys, 
> since otherwise Alice can't share any outputs with Bob and vice versa.
>
> The whole thing sounds like an HTLC with an additional trading of private 
> keys for the actual trades instead of in the HLTC. How are they going to 
> share their private keys securely, with PGP?
> Perhaps Taproot with its selective revealing of certain script branches can 
> help here, but I'm not sure about details.
> - Ali
>
>
> > Hi Bitcoin Developers,
> >
> > Does it make sense to trade replacement transactions for privacy? I have 
> > shared basic details to implement this and would love to read opinions 
> > about it or ways to improve it:
> >
> > =
> > alice
> > =
> >
> > tx1: input a (0.01) -> output b1 (0.008)
> > -> change c1 (0.001)
> >
> > tx2: input a (0.01) -> output e2 (0.007)
> > -> output f2 (0.001)
> >
> > =
> >
> > bob
> > =
> >
> > tx1: input d (0.011) -> output e1 (0.007)
> > -> change f1 (0.003)
> >
> > tx2: input d (0.011) -> output b2 (0.008)
> > -> output c2 (0.001)
> >
> > =
> >
> > carol
> > =
> >
> > - creates an API to manage trades that will use 2 of 3 multisig
> > - alice and bob create orders for replacement
> > - either they could be matched automatically using some algorithm or bob 
> > manually accepts the offer
> > - 2 of 3 multisig is created with Alice, Bob and Carol keys
> > - bob locks 0.01 BTC in it and shares outputs e2,f2 with alice
> > - alice signs tx2 and shares tx with bob
> > - alice locks 0.011 BTC in it and shares outputs b2,c2 with bob
> > - bob signs tx2 and shares with alice
> > - both replacement txs can be broadcasted
> > - funds are released from 2 of 3 multisig with a tx having 3 outputs (one 
> > to pay fee which goes to carol)
> >
> > positives:
> >
> > - privacy
> >
> > negatives:
> >
> > - extra fees
> > - will take some time although everything will be managed by wallet with 
> > API provided by carol
> > - need to lock bitcoin with same amount as used in tx1
> > - amounts could still be used to link txs in some cases- carol and other 
> > peer knows the details
>
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] P2P trading replacement transactions

[alicexbt via bitcoin-dev]

Hi Michael,


> What do you mean by "replacement transaction"? Replacing or swapping outputs 
> with a counterparty's?

User broadcasts tx1 which is in mempool, wants to replace transaction with 
higher fee rate however changes outputs and they are replaced with 
counterparty's outputs in tx2.


> I guess I'm struggling to understand exactly what you are attempting to 
> achieve here with regards to privacy and if this additional protocol 
> complexity is worth it. Recall a 2 (or n) party coinjoin would get you an 
> output where it isn't clear to blockchain observers which output you control 
> and a coinswap [0] would have you taking the coin history of your 
> counterparty. What does this scheme offer with regards to privacy that those 
> don't? This seems to have more complexity too though I maybe misunderstanding 
> something.

Coinjoin and Coinswap offer different levels of privacy. This method just aims 
to break the assumption that tx2 (replacement transaction) is done to use a 
higher fee rate with same sender and recipient. It looks complex in the way I 
wrote in the last email or maybe because of implementation details although UX 
will be simple and something like this:

- user sends bitcoin in tx1 which is unconfirmed
- tries to bump fee
- wallet offer an extra privacy option
- if user selects it, everything happens in the background and user just needs 
to approve in between
- user broadcasts tx2 to replace tx1 which has outputs shared by counterparty
- counterparty does the same for this user

If this method makes sense or we have a similar market to trade replacements in 
future, it could be helpful in creating a process in which a chain of 
replacements happen before bitcoin reaches the destination similar to tor 
circuit.

Example:

- tx1 enters a pool
- gets replaced by tx2 (different outputs)
- tx3 replaces tx2 (different outputs)

We could look at the logs and see tx3 originated at tx1 but no clue if original 
recipient received it in the end. There would be normal replacements done by 
other users so it would make analysis difficult.


/dev/fd0

Sent with Proton Mail secure email.

--- Original Message ---
On Saturday, August 6th, 2022 at 6:25 PM, Michael Folkson 
 wrote:


> Hi alicexbt
>
> What do you mean by "replacement transaction"? Replacing or swapping outputs 
> with a counterparty's?
>
> I guess I'm struggling to understand exactly what you are attempting to 
> achieve here with regards to privacy and if this additional protocol 
> complexity is worth it. Recall a 2 (or n) party coinjoin would get you an 
> output where it isn't clear to blockchain observers which output you control 
> and a coinswap [0] would have you taking the coin history of your 
> counterparty. What does this scheme offer with regards to privacy that those 
> don't? This seems to have more complexity too though I maybe misunderstanding 
> something.
>
> Thanks
> Michael
>
> [0]: https://bitcoinops.org/en/topics/coinswap/
>
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>
>
> --- Original Message ---
> On Friday, August 5th, 2022 at 15:44, alicexbt via bitcoin-dev 
>  wrote:
>
>
> > Hi Bitcoin Developers,
> >
> >
> > Does it make sense to trade replacement transactions for privacy? I have 
> > shared basic details to implement this and would love to read opinions 
> > about it or ways to improve it:
> >
> >
> > =
> > alice=
> >
> > tx1: input a (0.01) -> output b1 (0.008)
> >                              -> change c1 (0.001)
> >
> > tx2: input a (0.01) -> output e2 (0.007)
> >                              -> output f2 (0.001)
> >
> >
> > =
> >
> > bob
> > =
> >
> >
> > tx1: input d (0.011) -> output e1 (0.007)
> >                               -> change f1 (0.003)
> >
> > tx2: input d (0.011) -> output b2 (0.008)
> >                                -> output c2 (0.001)
> >
> >
> > =
> >
> > carol
> > =
> >
> >
> > - creates an API to manage trades that will use 2 of 3 multisig
> > - alice and bob create orders for replacement
> > - either they could be matched automatically using some algorithm or bob 
> > manually accepts the offer
> > - 2 of 3 multisig is created with Alice, Bob and Carol keys
> > - bob locks 0.01 BTC in it and shares outputs e2,f2 with alice
&g

[bitcoin-dev] P2P trading replacement transactions

[alicexbt via bitcoin-dev]

Hi Bitcoin Developers,

Does it make sense to trade replacement transactions for privacy? I have shared 
basic details to implement this and would love to read opinions about it or 
ways to improve it:

=
alice
=

tx1: input a (0.01) -> output b1 (0.008)
-> change c1 (0.001)

tx2: input a (0.01) -> output e2 (0.007)
-> output f2 (0.001)

=

bob
=

tx1: input d (0.011) -> output e1 (0.007)
-> change f1 (0.003)

tx2: input d (0.011) -> output b2 (0.008)
-> output c2 (0.001)

=

carol
=

- creates an API to manage trades that will use 2 of 3 multisig
- alice and bob create orders for replacement
- either they could be matched automatically using some algorithm or bob 
manually accepts the offer
- 2 of 3 multisig is created with Alice, Bob and Carol keys
- bob locks 0.01 BTC in it and shares outputs e2,f2 with alice
- alice signs tx2 and shares tx with bob
- alice locks 0.011 BTC in it and shares outputs b2,c2 with bob
- bob signs tx2 and shares with alice
- both replacement txs can be broadcasted
- funds are released from 2 of 3 multisig with a tx having 3 outputs (one to 
pay fee which goes to carol)

positives:

- privacy

negatives:

- extra fees
- will take some time although everything will be managed by wallet with API 
provided by carol
- need to lock bitcoin with same amount as used in tx1
- amounts could still be used to link txs in some cases- carol and other peer 
knows the details

/dev/fd0

Sent with [Proton Mail](https://proton.me/) secure email.___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Regarding setting a lower minrelaytxfee

[alicexbt via bitcoin-dev]

Hi Aaradhya,

> I discussed this on the Bitcoin subreddit and some suggested that the 
> developers, in the future, have to just change the "default minimum relay tx 
> fee" from 1000 today to 500 at that time.

>

There are several issues and pull requests (open and closed) in which 
developers tried to decrease the default minimum relay tx fee rate. Even I had 
opened an issue after reading this thread:

https://github.com/bitcoin/bitcoin/issues/25716

However, I think developers should not make any changes in the default minimum 
fee rate required for relay. If there are incentives for users and miners to 
change it, they should use non-default value. In case, miners want to 
experiment with lower fee rate and see if this increases revenue they could try 
using it on odd dates (even dates remain default) for a month. We all could 
analyze how this worked for different mining pools and non-default value (lower 
or higher) could become normal in the future.

/dev/fd0

Sent with [Proton Mail](https://proton.me/) secure email.

--- Original Message ---
On Saturday, July 30th, 2022 at 1:25 PM, Aaradhya Chauhan via bitcoin-dev 
 wrote:

> I'm not suggesting to initiate it anytime soon. But suppose, let's take a 
> situation where Bitcoin reaches and oscillates above 200k to 500k USD, then 1 
> sat/vB could be equivalent to 10 sat/vB of today, hampering the "dust 
> requirement" (ignoring inflation). I discussed this on the Bitcoin subreddit 
> and some suggested that the developers, in the future, have to just change 
> the "default minimum relay tx fee" from 1000 today to 500 at that time. 
> Obviously it's gonna be a little above 500, if we count inflation. That would 
> simply equate to the current situation. Do you think that would be a problem?
>
> On Fri, 29 Jul 2022 at 09:08, David A. Harding via bitcoin-dev 
>  wrote:
>
>> On 2022-07-26 02:45, Peter Todd via bitcoin-dev wrote:
>>> On Tue, Jul 26, 2022 at 01:56:05PM +0530, Aaradhya Chauhan via
>>> bitcoin-dev wrote:
 [...] in its early days, 1 sat/vB was a good dust protection
 measure. But now, I think it's a bit high [...] I think it can be done
 easily [...]
>>>
>>> [...] lowering the dust limit now is a good way to ensure
>>> the entire ecosystem is ready to deal with those conditions.
>>
>> I don't have anything new to add to the conversation at this time, but I
>> did want to suggest a clarification and summarize some previous
>> discussion that might be useful.
>>
>> I think the phrasing by Aaradhya Chauhan and Peter Todd above are
>> conflating the minimum output amount policy ("dust limit") with the
>> minimum transaction relay feerate policy ("min tx relay fee"). Any
>> transaction with an output amount below a node's configured dust limit
>> (a few hundred sat by default) will not be relayed by that node no
>> matter how high of a feerate it pays. Any transaction with feerate
>> below a nodes's minimum relay feerate (1 sat/vbyte by default) will not
>> be relayed by that node even if the node has unused space in its mempool
>> and peers that use BIP133 feefilters to advertise that they would accept
>> low feerates.
>>
>> Removing the dust limit was discussed extensively a year ago[1] with
>> additional follow-up discussion about eight months ago.[2]
>>
>> Lowering the minimum relay feerate was seriously proposed in a patch to
>> Bitcoin Core four years ago[3] with additional related PRs being opened
>> to ease the change. Not all of the related PRs have been merged yet,
>> and the original PR was closed. I can't easily find some of the
>> discussions I remember related to that change, but IIRC part of the
>> challenge was that lower minimum relay fees reduce the cost of a variety
>> of DoS attacks which could impact BIP152 compact blocks and erlay
>> efficiency, could worsen transaction pinning, may increase IBD time due
>> to more block chain data, and have other adverse effects. Additionally,
>> we've found in the past that some people who build systems that take
>> advantage of low feerates become upset when feerates rise, sometimes
>> creating problems even for people who prepared for eventual feerate
>> rises.
>>
>> Compared to the complexity of lowering the minimum feerate, the
>> challenges of preventing denial/degregation-of-service attacks, and
>> dealing with a fragmented userbase, the economic benefit of reducing the
>> feerates for the bottom of the mempool seems small---if we lower min
>> feerates to 1/10th their current values and that results in the
>> equivalent of an extra 10 blocks of transactions getting mined a day,
>> then users save a total of 0.09 BTC (~$1,800 USD) per day and miners
>> earn an extra 0.01 BTC ($200 USD) per day (assuming all other things
>> remain equal).[4]
>>
>> -Dave
>>
>> [1]
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-August/019307.html
>> [2]
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-December/019635.html
>> [3] https://github.com/bitco

Re: [bitcoin-dev] Regarding setting a lower minrelaytxfee

[alicexbt via bitcoin-dev]

Hi Peter,

> But to a first approximation, at any fee above zero failing to mine a tx you 
> know about is leaving money on the table

Let's assume 1 people go from A to B every day in flight. They buy tickets 
for different prices and some of them are looking to pay the minimum even if 
it's a morning flight, not preferred seat etc. If the minimum price for ticket 
drops, will this increase the revenue for airlines?

Some people who avoided flight earlier might book with new minimum although 
most of them already figured out other ways to travel or paid the old minimum. 
Maximum people or weight for a flight would still remain the same.

/dev/fd0

Sent with Proton Mail secure email.

--- Original Message ---
On Tuesday, July 26th, 2022 at 7:57 PM, Peter Todd  wrote:


>
> On July 26, 2022 2:19:32 PM GMT+02:00, alicexbt via bitcoin-dev 
> bitcoin-dev@lists.linuxfoundation.org wrote:
>
> > Hi Aaradhya,
> >
> > > As it's not a consensus rule, I think it can be done easily, just needing 
> > > support from full node operators
> >
> > A few miners will need to use a lower minrelaytxfee for this to work. I 
> > don't think miners would want to lower their profits.
>
>
> Whether or not this lowers profits for a particular miner is complex:
>
> https://petertodd.org/2016/block-publication-incentives-for-miners
>
> But to a first approximation, at any fee above zero failing to mine a tx you 
> know about is leaving money on the table.
>
> Anyway even if miners don't actually mine these txs by themselves, with 
> Child-Pays-For-Parent, allowing near-zero txs into your mempool potentially 
> allows you to mine more fees.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Regarding setting a lower minrelaytxfee

[alicexbt via bitcoin-dev]

Hi Aaradhya,

> As it's not a consensus rule, I think it can be done easily, just needing 
> support from full node operators

A few miners will need to use a lower minrelaytxfee for this to work. I don't 
think miners would want to lower their profits.

/dev/fd0

Sent with [Proton Mail](https://proton.me/) secure email.

--- Original Message ---
On Tuesday, July 26th, 2022 at 1:56 PM, Aaradhya Chauhan via bitcoin-dev 
 wrote:

I know this might be a sort of repetition for a previous question, but I do 
want to know from enthusiasts in this group that while Bitcoin was trading at 
much lower price in its early days, 1 sat/vB was a good dust protection 
measure. But now, I think it's a bit high for merely a dust protection measure, 
and should be lowered slightly. Even if not, it should be lowered to half when 
prices go double than today and keeps oscillating at that point. As it's not a 
consensus rule, I think it can be done easily, just needing support from full 
node operators. I support LN but I think transaction affordability should 
remain constant in the future. If I'm okay to wait in a queue, I should have 
the option for same affordability for minimum fees in the future as it is 
today. (Like we still have posts today while email still exists).

Awaiting your response.

Regards
Aaradhya Chauhan___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin covenants are inevitable

[alicexbt via bitcoin-dev]

Hi Anthony,


> The issue is whether we should allow such
> soft forks, or if the danger of losing coins to covenants and thus
> losing fungibility and the freedom to transact is too much of a risk,
> compared to whatever benefits the soft fork would bring.

There are so many ways to lose coins and [fungibility][1] of bitcoin is 
debatable. Most UTXOs are already distinguishable from another.

> that. Presumably we at least don't need to worry about somehow introducing
> racist opcodes in bitcoin, but if you're wondering why covenants are
> controversial, their historical use is relevant.

Could rebranding the term 'covenants' help in sharing the benefits of related 
proposals for bitcoin? According to Greg Maxwell's [comment][2] on reddit, he 
came up with the term as applied in bitcoin.

> But that isn't what anyone's trying to do here. What we're trying to
> do is add temporary conditions that allow us to do smarter things than
> we currently can while the coin remains in our ownership -- for example
> protecting our own money by putting it in a "vault", or pooling funds
> with people we don't entirely trust.

Agree.

> In particular, when purchasing real estate, you
> may have to do numerous legal searches to be sure that there isn't a
> covenant, easement or other encumbrance on your property; in bitcoin,
> you decide the exact set of encumbrances that will be placed on your
> coins when you create the receiving address that you use, and once the
> address is chosen, those conditions are fixed.

Agree and users should be free to add conditions to the coins they own.

> I think I'm going to go with talking about these features as enabling
> "transaction introspection" [4] [5] [6] (or "output introspection")
> instead -- that is, the ability for a script or witness from the input of
> a transaction to specify that the validator needs to examine components
> of the transaction itself (particularly its own outputs -- the value
> or the scriptPubKey or both), and ensure that some set of requirements
> imposed by the script/witness is fulfilled.

Interesting perspective and maybe this is the rebranding I was thinking about.


[1]: https://en.wikipedia.org/wiki/Fungibility
[2]: https://www.reddit.com/r/Bitcoin/comments/uim560/comment/i7dhfpb/


/dev/fd0


Sent with Proton Mail secure email.

--- Original Message ---
On Tuesday, July 19th, 2022 at 10:14 AM, Anthony Towns via bitcoin-dev 
 wrote:


> On Fri, Jun 03, 2022 at 06:39:34PM +, alicexbt via bitcoin-dev wrote:
>
> > Covenants on bitcoin will eventually be implemented with a soft fork.
>
>
> That's begging the question. The issue is whether we should allow such
> soft forks, or if the danger of losing coins to covenants and thus
> losing fungibility and the freedom to transact is too much of a risk,
> compared to whatever benefits the soft fork would bring.
>
> > Why covenants are not contentious?
>
>
> I think this actually misses the point: covenants are "contentious"
> because that term is usually used to describe a concept that's utterly
> counter to the point of bitcoin as a monetary instrument. We've taken
> the term and applied it for something that's different in key ways,
> which just ends up confusing and misleading.
>
> Using a traditional meaning, a "covenant" is an "agreement" but with
> an implication of permanency: whether that's because you're making a
> covenant with God that will bind your children and their children, or
> you're putting a covenant on your property that "runs with the land", eg:
>
> """A covenant is said to run with the land in the event that the covenant
> is annexed to the estate and cannot be separated from the land or the land
> transferred without it. Such a covenant exists if the original owner as
> well as each successive owner of the property is either subject to its
> burden or entitled to its benefit.""" [0]
>
> [0] https://legal-dictionary.thefreedictionary.com/covenant
>
> Sometimes people talk about "recursive covenants" in bitcoin, which
> I think is intended to imply something similar to the "runs with the
> land" concept above. But recursion in programming generally terminates
> (calculating "Fib(n) := if (n <= 1) then 1 else Fib(n-1) + Fib(n-2)"
> eg), while covenants that run with the land are often unable to be
> removed. I think a better programming analogy would be "non-terminating";
> so for example, CTV is "recursive" in the sense that you can nest one
> CTV commitment inside another, but it does terminate, because you can
> only nest a fin

[bitcoin-dev] Full Disclosure: Denial of Service in STONEWALLx2 (p2p coinjoin)

[alicexbt via bitcoin-dev]

Hi bitcoin-dev list members,


STONEWALLx2[1] is a p2p coinjoin transaction in Samourai wallet. The miner fee 
is split between both participants of the transaction.


==
Problem
==

Antoine Riard shared the details of DoS attack in an [email][2] on 21 June 2022.

Proof of Concept:

1) Download Samourai APK, create testnet wallet, get some coins from faucet and 
claim a paynym in 2 android devices. Consider Bob and Carol are using these 
devices.

2) Bob and Carol follow each other's paynyms. Carol is the attacker in this 
case and she could make several paynyms.

3) Bob initiates a Stonewallx2 transaction that requires collaboration with 
Carol.

4) Carol confirms this request in the app.

5) Carol spends the UTXO from wallet configured in electrum with same seed 
before Bob could complete the last step and broadcast STONEWALLx2 transaction. 
It was non RBF [transaction][3] with 1 sat/vbyte fee rate and was unconfirmed 
during testing.

6) Bob receives an [error][4] in the app when trying to broadcast Stonewallx2 
transaction which disappears in a few seconds. The [progress bar][5] appears as 
if wallet is still trying to broadcast the transaction until Bob manually go 
back or close the app.


==
Solution
==

Suggestions:

a) Error message that states collaborator spent her UTXO used in STONEWALLx2, 
end the p2p coinjoin process, unfollow collaborator's paynym and suggest user 
to do such transactions with trusted users only for a while.

b) Once full RBF is used by some nodes and miners, attacker's transaction could 
be replaced with a higher fee rate.

Conclusions by Samourai:

a) As the threat involves the collaborator attacking the spender. We strongly 
advise that collab spends be done w/ counterparties with which some measure of 
trust is shared. As such, this does not seem to have an important threat 
surface.

b) Bumping fee won't be simple as fees are shared 50/50 for STONEWALLx2 spends. 
Change would have to be recalculated for both spender and collaborator. Collab 
would either have had already authorized a possible fee bump beforehand or 
would have to be prompted before broadcast.


==
Timeline
==

22 June 2022: I emailed Antoine after testing STONEWALLx2

23 June 2022: I shared the details of attack in a confidential issue in 
Samourai wallet [repository][6]

07 July 2022: TDevD (Samourai) acknowledged the issue and wanted to discuss it 
internally with team

14 July 2022: TDevD shared the conclusions


==
Credits
==

Antoine Riard discovered DoS vector in p2p coinjoin transactions and helped by 
responding to emails during testing.


[1]: https://docs.samourai.io/spend-tools
[2]: 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020595.html
[3]: 
https://mempool.space/testnet/tx/42db696460a46f196f457779d60acbf46b31accc5414b9eac54b2e785d4c1cbb
[4]: https://i.imgur.com/6uf3VJn.png
[5]: https://i.imgur.com/W6ITl4G.gif
[6]: https://code.samourai.io/wallet/samourai-wallet-android


/dev/fd0

Sent with Proton Mail secure email.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Surprisingly, Tail Emission Is Not Inflationary

[alicexbt via bitcoin-dev]

Sorry, I made some wrong calculations in the last email. I think the change 
would just be required in validation.cpp:

https://github.com/bitcoin/bitcoin/blob/a7f3479ba3fda4c9fb29bd7080165744c02ee921/src/validation.cpp#L1472

/dev/fd0

Sent with Proton Mail secure email.

--- Original Message ---
On Sunday, July 10th, 2022 at 2:17 PM, alicexbt via bitcoin-dev 
 wrote:


> Hi ZmnSCPxj,
>
> > Thus, we should instead prepare for a future where the block subsidy must 
> > be removed, possibly before the existing schedule removes it, in case a 
> > majority coalition of miner ever decides to censor particular transactions 
> > without community consensus.
> > Fortunately forcing the block subsidy to 0 is a softfork and thus easier to 
> > deploy.
>
>
> `consensus.nSubsidyHalvingInterval` for mainnet in [chainparams.cpp][1] can 
> be decreased to 195000. This will reduce the number of halvings from 34 to 14 
> and subsidy will be 0 when it becomes less than 0.01 although not sure if 
> this will be a soft fork.
>
> I doubt there will be consensus for it because all the [projections and 
> predictability][2] about bitcoin(currency) would be affected by this change. 
> Maybe everyone can agree with this change if most of the miners start being 
> 'compliant' like one of the coinjoin implementation.
>
> [1]: https://github.com/bitcoin/bitcoin/blob/master/src/chainparams.cpp#L66
> [2]: https://en.bitcoin.it/wiki/Controlled_supply
>
>
> /dev/fd0
>
> Sent with Proton Mail secure email.
>
>
> --- Original Message ---
> On Saturday, July 9th, 2022 at 9:59 PM, ZmnSCPxj via bitcoin-dev 
> bitcoin-dev@lists.linuxfoundation.org wrote:
>
>
>
> > Good morning e, and list,
> >
> > > Yet you posted several links which made that specific correlation, to 
> > > which I was responding.
> > >
> > > Math cannot prove how much coin is “lost”, and even if it was provable 
> > > that the amount of coin lost converges to the amount produced, it is of 
> > > no consequence - for the reasons I’ve already pointed out. The amount of 
> > > market production has no impact on market price, just as it does not with 
> > > any other good.
> > >
> > > The reason to object to perpetual issuance is the impact on censorship 
> > > resistance, not on price.
> >
> > To clarify about censorship resistance and perpetual issuance ("tail 
> > emission"):
> >
> > * Suppose I have two blockchains, one with a constant block subsidy, and 
> > one which had a block subsidy but the block subsidy has become negligible 
> > or zero.
> > * Now consider a censoring miner.
> > * If the miner rejects particular transactions (i.e. "censors") the miner 
> > loses out on the fees of those transactions.
> > * Presumably, the miner does this because it gains other benefits from the 
> > censorship, economically equal or better to the earnings lost.
> > * If the blockchain had a block subsidy, then the loss the miner incurs is 
> > small relative to the total earnings of each block.
> > * If the blockchain had 0 block subsidy, then the loss the miner incurs is 
> > large relative to the total earnings of each block.
> > * Thus, in the latter situation, the external benefit the miner gains from 
> > the censorship has to be proportionately larger than in the first situation.
> >
> > Basically, the block subsidy is a market distortion: the block subsidy 
> > erodes the value of held coins to pay for the security of coins being moved.
> > But the block subsidy is still issued whether or not coins being moved are 
> > censored or not censored.
> > Thus, there is no incentive, considering only the block subsidy, to not 
> > censor coin movements.
> > Only per-transaction fees have an incentive to not censor coin movements.
> >
> > Thus, we should instead prepare for a future where the block subsidy must 
> > be removed, possibly before the existing schedule removes it, in case a 
> > majority coalition of miner ever decides to censor particular transactions 
> > without community consensus.
> > Fortunately forcing the block subsidy to 0 is a softfork and thus easier to 
> > deploy.
> >
> > Regards,
> > ZmnSCPxj
> > ___
> > 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 mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Surprisingly, Tail Emission Is Not Inflationary

[alicexbt via bitcoin-dev]

Hi ZmnSCPxj,


> Thus, we should instead prepare for a future where the block subsidy must be 
> removed, possibly before the existing schedule removes it, in case a majority 
> coalition of miner ever decides to censor particular transactions without 
> community consensus.
> Fortunately forcing the block subsidy to 0 is a softfork and thus easier to 
> deploy.

`consensus.nSubsidyHalvingInterval` for mainnet in [chainparams.cpp][1] can be 
decreased to 195000. This will reduce the number of halvings from 34 to 14 and 
subsidy will be 0 when it becomes less than 0.01 although not sure if this will 
be a soft fork.

I doubt there will be consensus for it because all the [projections and 
predictability][2] about bitcoin(currency) would be affected by this change. 
Maybe everyone can agree with this change if most of the miners start being 
'compliant' like one of the coinjoin implementation.

[1]: https://github.com/bitcoin/bitcoin/blob/master/src/chainparams.cpp#L66
[2]: https://en.bitcoin.it/wiki/Controlled_supply


/dev/fd0

Sent with Proton Mail secure email.

--- Original Message ---
On Saturday, July 9th, 2022 at 9:59 PM, ZmnSCPxj via bitcoin-dev 
 wrote:


> Good morning e, and list,
>
> > Yet you posted several links which made that specific correlation, to which 
> > I was responding.
> >
> > Math cannot prove how much coin is “lost”, and even if it was provable that 
> > the amount of coin lost converges to the amount produced, it is of no 
> > consequence - for the reasons I’ve already pointed out. The amount of 
> > market production has no impact on market price, just as it does not with 
> > any other good.
> >
> > The reason to object to perpetual issuance is the impact on censorship 
> > resistance, not on price.
>
>
> To clarify about censorship resistance and perpetual issuance ("tail 
> emission"):
>
> * Suppose I have two blockchains, one with a constant block subsidy, and one 
> which had a block subsidy but the block subsidy has become negligible or zero.
> * Now consider a censoring miner.
> * If the miner rejects particular transactions (i.e. "censors") the miner 
> loses out on the fees of those transactions.
> * Presumably, the miner does this because it gains other benefits from the 
> censorship, economically equal or better to the earnings lost.
> * If the blockchain had a block subsidy, then the loss the miner incurs is 
> small relative to the total earnings of each block.
> * If the blockchain had 0 block subsidy, then the loss the miner incurs is 
> large relative to the total earnings of each block.
> * Thus, in the latter situation, the external benefit the miner gains from 
> the censorship has to be proportionately larger than in the first situation.
>
> Basically, the block subsidy is a market distortion: the block subsidy erodes 
> the value of held coins to pay for the security of coins being moved.
> But the block subsidy is still issued whether or not coins being moved are 
> censored or not censored.
> Thus, there is no incentive, considering only the block subsidy, to not 
> censor coin movements.
> Only per-transaction fees have an incentive to not censor coin movements.
>
>
> Thus, we should instead prepare for a future where the block subsidy must be 
> removed, possibly before the existing schedule removes it, in case a majority 
> coalition of miner ever decides to censor particular transactions without 
> community consensus.
> Fortunately forcing the block subsidy to 0 is a softfork and thus easier to 
> deploy.
>
>
> Regards,
> ZmnSCPxj
> ___
> 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] Playing with full-rbf peers for fun and L2s security

[alicexbt via bitcoin-dev]

Hi Peter,

> Point is, the attacker is thousands of UTXOs can also DoS rounds by simply
> failing to complete the round. In fact, the double-spend DoS attack requires
> more resources, because for a double-spend to be succesful, BTC has to be 
> spent
> on fees.
>
> It's just a fact of life that a motivated attacker can DoS attack Wasabi by
> spending money. That's a design choice that's serving them well so far.


There are 2 things:

1) Based on my understanding, round will not be aborted if a threshold is met 
for inputs and will continue irrespective of attacker trying different things 
in the initial phases of round. I need to confirm this by testing although not 
feeling well today so it can take a few days.

2) Points mentioned by Greg Sanders are reasonable: There can be a different 
'mempool view' for coordinator, users and attacker. Attacker could use minimum 
fee rate required for relay and this works differently when there is enough 
demand for blockspace.

Double spend attack requires only one laptop and a few UTXOs. Even if spent in 
some cases, would pay a few sats per transaction which won't be an issue for 
governments or competitors that normally perform such attacks.

The vulnerability reported is different from the things being discussed and 
hopefully I will do a public disclosure this month. I observed some interesting 
things which I wanted to discuss. Full RBF pull request is already merged in 
bitcoin core and available in bitcoin knots if some users want to experiment.


/dev/fd0

Sent with Proton Mail secure email.

--- Original Message ---
On Friday, July 8th, 2022 at 2:53 PM, Peter Todd  wrote:


> On Tue, Jul 05, 2022 at 08:46:51PM +, alicexbt wrote:
>
> > Hi Peter,
> >
> > > Note that Wasabi already has a DoS attack vector in that a participant 
> > > can stop
> > > participating after the first phase of the round, with the result that the
> > > coinjoin fails. Wasabi mitigates that by punishing participating in future
> > > rounds. Double-spends only create additional types of DoS attack that 
> > > need to
> > > be detected and punished as well - they don't create a fundamentally new
> > > vulerability.
> >
> > I agree some DoS vectors are already mitigated however punishment in this 
> > case will be difficult because the transaction is broadcasted after signing 
> > and before coinjoin tx broadcast.
> >
> > Inputs are already checked multiple times for double spend during coinjoin 
> > round: https://github.com/zkSNACKs/WalletWasabi/pull/6460
> >
> > If all the inputs in the coinjoin transaction that failed to relay are 
> > checked and one or more are found to be spent later, what will be punished 
> > and how does this affect the attacker with thousands of UTXOs or normal 
> > users?
>
>
> Point is, the attacker is thousands of UTXOs can also DoS rounds by simply
> failing to complete the round. In fact, the double-spend DoS attack requires
> more resources, because for a double-spend to be succesful, BTC has to be 
> spent
> on fees.
>
> It's just a fact of life that a motivated attacker can DoS attack Wasabi by
> spending money. That's a design choice that's serving them well so far.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Playing with full-rbf peers for fun and L2s security

[alicexbt via bitcoin-dev]

Hi Peter,

> Note that Wasabi already has a DoS attack vector in that a participant can 
> stop
> participating after the first phase of the round, with the result that the
> coinjoin fails. Wasabi mitigates that by punishing participating in future
> rounds. Double-spends only create additional types of DoS attack that need to
> be detected and punished as well - they don't create a fundamentally new
> vulerability.

I agree some DoS vectors are already mitigated however punishment in this case 
will be difficult because the transaction is broadcasted after signing and 
before coinjoin tx broadcast.

Inputs are already checked multiple times for double spend during coinjoin 
round: https://github.com/zkSNACKs/WalletWasabi/pull/6460

If all the inputs in the coinjoin transaction that failed to relay are checked 
and one or more are found to be spent later, what will be punished and how does 
this affect the attacker with thousands of UTXOs or normal users?

/dev/fd0

Sent with Proton Mail secure email.

--- Original Message ---
On Monday, June 27th, 2022 at 12:43 AM, Peter Todd  wrote:


> On Sun, Jun 26, 2022 at 04:40:24PM +0000, alicexbt via bitcoin-dev wrote:
>
> > Hi Antoine,
> >
> > Thanks for sharing the DoS attack example with alternatives.
> >
> > > - Caroll broadcasts a double-spend of her own input C, the double-spend 
> > > is attached with a low-fee (1sat/vb) and it does not signal opt-in RBF
> > > - Alice broadcasts the multi-party transaction, it is rejected by the 
> > > network mempools because Alice double-spend is already present
> >
> > I think this affects almost all types of coinjoin transaction including 
> > coordinator based implementations. I tried a few things and have already 
> > reported details for an example DoS attack to one of the team but there is 
> > no response yet.
> >
> > It was fun playing with RBF, DoS and Coinjoin. Affected projects should 
> > share their opinion about full-rbf as it seems it might improve things.
> >
> > Example:
> >
> > In Wasabi an attacker can broadcast a transaction spending input used in 
> > coinjoin after sending signature in the round. This would result in a 
> > coinjoin tx which never gets relayed: 
> > https://nitter.net/144bytes/status/1540727534093905920
>
>
> Note that Wasabi already has a DoS attack vector in that a participant can 
> stop
> participating after the first phase of the round, with the result that the
> coinjoin fails. Wasabi mitigates that by punishing participating in future
> rounds. Double-spends only create additional types of DoS attack that need to
> be detected and punished as well - they don't create a fundamentally new
> vulerability.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BGP hijacking on Bitcoin p2p network

[alicexbt via bitcoin-dev]

Hi Elias,

Thanks for sharing the links.

I have also started working on a simple chrome extension which connects to 
local bitcoin core and checks IP address of all peers for prefix length and 
other things. I would highlight peers with different colors based on certain 
things in this extension.

https://github.com/144bytes/bitcoin-core-extension

/dev/fd0


Sent with Proton Mail secure email.

--- Original Message ---
On Friday, June 10th, 2022 at 6:44 AM, Elias Rohrer  wrote:


> Hi alicexbt,
>
> Routing attacks have actually been studied quite a bit in literature.
>
> You may be interested in the research articles of Maria Apostolaki et 
> al.[1,2], Muoi Tran et al.[3], and related works.
>
> Best,
>
> Elias
>
> 1: https://arxiv.org/pdf/1605.07524.pdf
> [2]: https://arxiv.org/pdf/1808.06254.pdf
> [3]: https://allquantor.at/blockchainbib/pdf/tran2020stealthier.pdf
>
> On 9 Jun 2022, at 20:24, alicexbt via bitcoin-dev wrote:
>
> > Hi Bitcoin Developers,
> >
> > Based on this answer from 2014, bitcoin nodes are vulnerable to BGP 
> > hijacking. There was an incident in March 2022, twitter prefix was hijacked 
> > and details are shared in 2 blog posts:
> >
> > https://isc.sans.edu/diary/rss/28488
> >
> > https://www.manrs.org/2022/03/lesson-learned-twitter-shored-up-its-routing-security/
> >
> > 'nusenu' had written an article about Tor network being vulnerable to BGP 
> > hijacking attacks: 
> > https://nusenu.medium.com/how-vulnerable-is-the-tor-network-to-bgp-hijacking-attacks-56d3b2ebfd92
> >
> > After doing some research I found that RPKI ROA and BGP prefix length can 
> > help against BGP hijacking attacks. I checked BGP prefix length and RPKI 
> > ROA for first 10 IP addresses returned in `getnodeaddresses` in bitcoin 
> > core and it had vulnerable results.
> >
> > https://i.stack.imgur.com/KD7jH.png
> >
> > Has anyone written a detailed blog post or research article like nusenu? If 
> > not I would be interested to write one in next couple of weeks?
> > Looking for some "technical" feedback, links if this was already discussed 
> > in past with some solutions.
> >
> > /dev/fd0
> >
> > Sent with Proton Mail secure email.
> >
> > ___
> > 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] Playing with full-rbf peers for fun and L2s security

[alicexbt via bitcoin-dev]

Hi Antoine,

Thanks for sharing the DoS attack example with alternatives.

> - Caroll broadcasts a double-spend of her own input C, the double-spend is 
> attached with a low-fee (1sat/vb) and it does _not_ signal opt-in RBF
> - Alice broadcasts the multi-party transaction, it is rejected by the network 
> mempools because Alice double-spend is already present

I think this affects almost all types of coinjoin transaction including 
coordinator based implementations. I tried a few things and have already 
reported details for an example DoS attack to one of the team but there is no 
response yet.

It was fun playing with RBF, DoS and Coinjoin. Affected projects should share 
their opinion about full-rbf as it seems it might improve things.

Example:

In Wasabi an attacker can broadcast a transaction spending input used in 
coinjoin after sending signature in the round. This would result in a coinjoin 
tx which never gets relayed: 
https://nitter.net/144bytes/status/1540727534093905920

/dev/fd0

Sent with Proton Mail secure email.

--- Original Message ---
On Tuesday, June 21st, 2022 at 11:43 PM, Antoine Riard 
 wrote:


> HI alicexbt,
>
> > Lets consider there are 2 users with name Bob (normal LN user) and Carol 
> > (attacker running LN node) which I will use in this email for examples. In 
> > this case Bob and Carol can manage security of their OS and it is not 
> > affected by others using vulnerable systems or OS.
>
> Yes, I believe my argument was the set of components making the security of 
> your LN node is far beyond Bitcoin softwares. Of course, you might review by 
> yourself the millions lines of code entering in the trusted computing base 
> (OS, bootloader, BIOS, device firmwares, essential utilities, ...) on which 
> your cryptocurrency software stack lays out, and as such exercise an extended 
> span of control on your personal computation. Though, while I hope we'll have 
> more LN node operators doing so, I'm not sure it's realistic to expect it 
> will be the behavior standard among them..
>
> > The odds are low as you said, this can be managed by Bob and Carol because 
> > they can use a better ISP. Others using ISP with some issues may not affect 
> > their LN usage.
>
> Sure, though as I would like to underscore being dependent on a Bitcoin node 
> policy and being dependent on a ISP internet traffic routing policy could be 
> analyzed as logically equivalent, all things are equal. That said, if your 
> personal risk aversion is too high for the Lightning security model, once 
> it's well-understood there is a strong reliance on a censorship-resistant 
> tx-relay network back to economically-rational miners, you're free to not use 
> it and satisfy yourself with the Bitcoin base layer.
>
> > Bob might use full-rbf as its suggested by LN developers for secure LN 
> > usage and better for miners. Carol could use a different RBF policy for 
> > some nodes and mining. In this case Bob may get affected at some point 
> > because of Carol's choice to use a different RBF policy which was not true 
> > above.
>
> Indeed, your secure LN usage is going to be dependent of the number of p2p 
> network nodes running an economically-rational policy like full-rbf. That 
> said, I think it's reasonable to assume that the players of the Bitcoin game 
> are economically-rational, and as such incentived to pick up a policy such as 
> full-rbf. I know the term "economically-rational" is poorly defined here, and 
> I think it could be interesting for any academic with an economic background 
> to study the incentives of Bitcoin actors.
>
> > Allowing users to create different mempool policies is great. My thought 
> > process is to code for happy path, where X policy is expected for 
> > replacement and edge cases where Y policy or no policy would be used. Users 
> > can try out different policies and even act as attackers. This is also true 
> > for other things in mempool, 'spkreuse=conflict' prevents address reuse in 
> > the mempool when using knots. If I assume that address reuse is always 
> > relayed, this could become a problem if some users and miners adopt this 
> > setting in their mempool.
>
> Agree, I'm all in for people to experiment with mempool policies. Though at 
> the end it's a software engineering resource question. If users are 
> interested in more features, they're always free to implement themselves. 
> Really, the binary distinction developers-vs-users doesn't make sense and if 
> we would like Bitcoin to be successful in the long-term, we should promote 
> high degree of software literacy among bitcoiners.
>
> > This makes sense and I would be interested to follow two things once 
> > full-rbf is available in a bitcoin core release: 1. Percentage of 
> > transaction getting replaced 2. Miners profit (Fee for replaced Tx - Fee 
> > for original Tx)
>
> Yes, I would be interested too to have those metrics once full-rbf is 
> available in a bitcoin core release. I thi

[bitcoin-dev] Mempool and Privacy

[alicexbt via bitcoin-dev]

Hi Bitcoin Developers,

Bitcoin knots has a config option to disallow address reuse in mempool: 
spkreuse=conflict or GUI -> Settings -> Options -> Mempool. I tried 
experimenting with it and running 2 nodes(signet) for which anyone can check 
'getrawmempool' at a given time using:

GET /mempool?node=1 HTTP/1.1
Host: api.spkreuse.funContent-Type: application/json

Node 2 has 'spkreuse=conflict' saved in bitcoin_rw.conf and it will reject all 
transaction reusing addresses in mempool. I have tried testing it on signet and 
it works as expected. Replacement transactions are exceptions and ignored even 
if address appears twice in mempool. I could not find any issues however 
debug=mempool did not print logs that could be helpful to know which 
transactions are getting rejected in mempool for address re-use. So running 2 
nodes and comparing mempool transactions.

What other things could affect privacy in mempool and not explored yet? I could 
think of 3:

- RBF policies
- Rebroadcasting mechanism- Different types of relay fee

This could be used by lot of bitcoin nodes, not sure about miners. I do not 
believe mempool policies only rely on miner incentives, minimum fee rate won't 
be be 1 sat/vbyte if that was the case. Even if its never used by lot of nodes 
and some miners, it was fun to play with and I like knots for providing such 
options.

/dev/fd0

Sent with [Proton Mail](https://proton.me/) secure email.___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Playing with full-rbf peers for fun and L2s security

[alicexbt via bitcoin-dev]

Hi Antoine,

> One could list the operating system on which is running your Lightning 
> process or the compiler toolchain turning outyour Lightning source code in a 
> binary artifact. Some weird kernel's memory mapping change could allow access 
> toyour channel funding keys, _without_ breaking the Bitcoin consensus rules 
> [0].

Lets consider there are 2 users with name Bob (normal LN user) and Carol 
(attacker running LN node) which I will use in this email for examples. In this 
case Bob and Carol can manage security of their OS and it is not affected by 
others using vulnerable systems or OS.

> Moreover, your Lightning node is alsorelying on the existence of a global 
> Internet allowing your HTLC transaction to flow from your physical hostto the 
> crowd of transactions confirming in the blockchain. Due to this "protocol 
> assumption" your channel balancewould be vulnerable to any change in your ISP 
> routing policy, e.g refusing to accept your IPV4 traffic by a 
> suddendesiderata to impose an IPV6 supremacy. Still _without_ breaking the 
> Bitcoin consensus rules. Of course, the odds ofyour ISP operator adopting 
> this behavior are really low, mostly because your operator has to bind to 
> social andeconomic constraints to stay in business.

The odds are low as you said, this can be managed by Bob and Carol because they 
can use a better ISP. Others using ISP with some issues may not affect their LN 
usage.

> And I believe this imperative to stay in business is certainly not absent in 
> the incentives of the Bitcoin nodeoperators. You're free to run any policy on 
> your node, especially one hardening the safety of your operationsbeyond the 
> default one. However, if you start to a transaction-relay non-compatible with 
> miner incentives, youwon't have an efficient view of the blockspace demand, 
> and from then won't be able to offer compelling feeratesto execute your 
> business transactions to satisfy your client needs. Or you won't consolidate 
> yourwallet UTXOs attimesof low-demand. Indeed, a sane visibility of the 
> mempools might not be critical now foryour Bitcoin operations, but this is 
> not likely to become true with miner's coinbase reward lowering with timeand 
> the system securityrelyingon a fruitful fee market.

Bob might use full-rbf as its suggested by LN developers for secure LN usage 
and better for miners. Carol could use a different RBF policy for some nodes 
and mining. In this case Bob may get affected at some point because of Carol's 
choice to use a different RBF policy which was not true above.

> So assuming there is a significant number of economically rational entities 
> running p2p nodes, I think it's areasonable assumption for Lightning 
> developers that a policy maximizing miner's income and economic 
> nodesoperations will be widely run on the p2p network, and therefore lay its 
> security model on that. When there is agap between the economically optimal 
> policy (full-rbf) and the effectively deployed one (optin), and this 
> gapconstitutes a flaw for exploitation, I believe it's better to fix it.

Agree with the assumption there is nothing wrong in experimenting with a new 
RBF policy (non-default) if that helps some users and projects.

> If you have a different mode of thinking w.r.t how we should design protocol 
> in a trust-minimized, open,adversarialenvironment such as Bitcoin, I'm 
> curious to listen to it.

Allowing users to create different mempool policies is great. My thought 
process is to code for happy path, where X policy is expected for replacement 
and edge cases where Y policy or no policy would be used. Users can try out 
different policies and even act as attackers. This is also true for other 
things in mempool, 'spkreuse=conflict' prevents address reuse in the mempool 
when using knots. If I assume that address reuse is always relayed, this could 
become a problem if some users and miners adopt this setting in their mempool.

> Of course not. If you deliver any critical software, you should attach a 
> solid manual explaining all thecorner cases and rough edges. Even better 
> would be to enshrine the manual directly in your software APIto minimize the 
> footgunish behaviors. E.g, with any ECC library, forbidding to reuse nonces. 
> If youruserstill ignores or misread the manual and provides an insecure 
> input, there isnot thatmuch you can do.

Agree with the documentation as it helps users.

> Given there are like 17000 public LN nodes, if half of them adopt full-rbf it 
> should givealready a good number of full-rbf transaction-relay routes across 
> the p2p network graph.When we're there, we can measure and think more about 
> how to tune the full-rbf sub-topology.

Sounds good.

> Because it's breaking the reliability and security of their use-cases. 
> Use-cases which didn't exista few years ago. The mempool DoS vector is 
> described here [4]. To the best of my understanding, it mightaffect a bunch 
> of use-cases,

Re: [bitcoin-dev] Playing with full-rbf peers for fun and L2s security

[alicexbt via bitcoin-dev]

Hi cndm1,

> If you see a "lack of basic options" and no one has opened a pull request for 
> it, it may be for two reasons.

The basic option to disable all RBF policies in a node's mempool if required 
was removed in [PR #16171][1]. No one has opened a pull request to revert this 
because most of the maintainers and a few reviewers agreed with this change. It 
wasn't required, PR had weak rationale, 2 NACKS and was reopened to merge 
because some reviewers/maintainers believe its a policy that cannot be 
maintained. One of the reviewers who NACKed it already maintains the config 
option to disable all RBF policies in Bitcoin Knots which is a derivative of 
Bitcoin Core.

> However, repeatedly demanding others to do it for you is not helpful in open 
> source software development.

I am not demanding anyone to add a few lines of code and open a pull request. I 
am _reviewing_ a pull request in an open source project and sharing my 
feedback. Even Antoine and Luke agreed to add it if other reviewers have no 
issues or I can do it. This option in context with another being added for a 
new RBF policy was being discussed in [PR #25353][2] and my earlier emails in 
this thread.

Other 'basic options' will be easier to accommodate with `-mempoolreplacement` 
used in [PR #25373] which is unlikely to be merged.

[1]: https://github.com/bitcoin/bitcoin/pull/16171
[2]: https://github.com/bitcoin/bitcoin/pull/25353
[3]: https://github.com/bitcoin/bitcoin/pull/25373


/dev/fd0

Sent with Proton Mail secure email.

--- Original Message ---
On Thursday, June 16th, 2022 at 11:13 AM, linuxfoundation.cndm1--- via 
bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote:



> alicexbt wrote:
>
> > I do not have issues with multiple RBF policies being tried out and 
> > full-rbf being one of them. My disagreements are with rationale, lack of 
> > basic options in Bitcoin Core to employ/disable different RBF policies and 
> > a few arguments made in support for full-rbf. Whether it appears strawman 
> > or offtopic on github, there should be a place to share these disagreements.
>
> Bitcoin Core is open source software, where developers open pull
> requests to try to get them merged after review. If you see a "lack of
> basic options" and no one has opened a pull request for it, it may be
> for two reasons. First, it could be that it just doesn't make sense,
> so no one sees a point in implementing it. Secondly, it may be that it
> isn't on anyone's list of priorities. In the second case, you are
> welcome to share your preference once. Moreover, no one is holding you
> back to implement it yourself and suggest a pull request. However,
> repeatedly demanding others to do it for you is not helpful in open
> source software development.
>
> cndm1
>
> ___
> 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] Playing with full-rbf peers for fun and L2s security

[alicexbt via bitcoin-dev]

Hi Greg,

> The security of LN and other related systems are something like: "given 
> proper fees offered, can a transaction be mined within N blocks?" You're 
> simply not allowed to out-bid your attacker in certain circumstances due to 
> today's miner incentive-incompatible relay policies.

It is not possible to guarantee that a transaction will be mined within N 
blocks irrespective of fees. It is vulnerable if a project's security relies on 
it,and should fix it by changing the security assumptions. Miners can try 
full-rbf or other policy without core so I won't consider opt-in as 
incentive-incompatible.

>> ... arguments about how many people RBF being sufficient or not ...
>
> The idea that we should only build robust systems after the broken ones are 
> attacked is not a serious argument.

Its true and was even mentioned in PR #16171 that a policy is only useful if 
enough nodes and miners follow it. We should build robust systems but I don't 
think this change will help in doing it.

> This is a strawman.
>
> Full-RBF is a simple, obvious, incentive-compatible step to getting closer to 
> more robust layer two systems.Fixing the rest of the holes is for future 
> proposals which are a bit more involved and definitely less mature.

I do not have issues with multiple RBF policies being tried out and full-rbf 
being one of them. My disagreements are with rationale, lack of basic options 
in Bitcoin Core to employ/disable different RBF policies and a few arguments 
made in support for full-rbf. Whether it appears strawman or offtopic on 
github, there should be a place to share these disagreements.

> If Knots has these knobs, just use Knots rather than lobby all 
> implementations to have miner incentive incompatible knobs?

Everyone can share options that would help users in the bitcoin implementation 
used by 90% nodes. I don't think this is reserved only for a few developers. I 
would personally use Knots and others are free to try the suggestion or 
continue using Bitcoin Core.

/dev/fd0

Sent with [Proton Mail](https://proton.me/) secure email.

--- Original Message ---
On Thursday, June 16th, 2022 at 6:32 AM, Greg Sanders  
wrote:

>> If something relies on a policy which can be changed without breaking 
>> consensus rules, how is it secure in any case with or without full rbf?
>
> The security of LN and other related systems are something like: "given 
> proper fees offered, can a transaction be mined within N blocks?" You're 
> simply not allowed to out-bid your attacker in certain circumstances due to 
> today's miner incentive-incompatible relay policies.
>
> There is also a time-value dimension to this with other simpler systems where 
> your funds can be locked up for potentially weeks for similar reasons.
>
>> ... arguments about how many people RBF being sufficient or not ...
>
> The idea that we should only build robust systems after the broken ones are 
> attacked is not a serious argument.
>
>> I am not opposed to full-rbf; rather, I am opposed to the notion that 
>> full-rbf will solve all problems
>
> This is a strawman.
>
> Full-RBF is a simple, obvious, incentive-compatible step to getting closer to 
> more robust layer two systems. Fixing the rest of the holes is for future 
> proposals which are a bit more involved and definitely less mature.
>
>> would suggest users to try Bitcoin Knots instead
>> Developers should provide basic RBF policy options rather than attempting to 
>> define what constitutes a good policy and removing the ability to disable 
>> something when necessary.
>
> If Knots has these knobs, just use Knots rather than lobby all 
> implementations to have miner incentive incompatible knobs?
>
> Cheers,
> Greg
>
> On Wed, Jun 15, 2022 at 8:27 PM alicexbt via bitcoin-dev 
>  wrote:
>
>> Hi Antoine,
>>
>> Thanks for opening the pull request to add support for full-rbf in Bitcoin 
>> Core. I have a few disagreements with the approach and questions.
>>
>>> Recent discussions among LN devs have brought back on the surface concerns 
>>> about the security of multi-party funded transactions (coinjoins, 
>>> dual-funded LN channels, on-chain DLCs, ...). It turns out there is a 
>>> low-fruit, naive DoS vector playable against the funding flow of any such 
>>> construction due to the lack of existent full-rbf transaction-relay 
>>> topology on today's p2p network [0] [1].
>>
>> 1)If something relies on a policy which can be changed without breaking 
>> consensus rules, how is it secure in any case with or without full rbf? If I 
>> write a python script that expects user to enter char 'a'

Re: [bitcoin-dev] Playing with full-rbf peers for fun and L2s security

[alicexbt via bitcoin-dev]

Hi Antoine,

Thanks for opening the pull request to add support for full-rbf in Bitcoin 
Core. I have a few disagreements with the approach and questions.

> Recent discussions among LN devs have brought back on the surface concerns 
> about the security of multi-party funded transactions (coinjoins, dual-funded 
> LN channels, on-chain DLCs, ...). It turns out there is a low-fruit, naive 
> DoS vector playable against the funding flow of any such construction due to 
> the lack of existent full-rbf transaction-relay topology on today's p2p 
> network [0] [1].

1)If something relies on a policy which can be changed without breaking 
consensus rules, how is it secure in any case with or without full rbf? If I 
write a python script that expects user to enter char 'a' or 'b' but user can 
enter 'c' and there is no code to handle exceptions or other chars, will it be 
secure?

2)full-rbf is not default in the 2 open pull requests, so this experiment still 
relies on users changing RBF policies manually. If majority of nodes use 
default opt-in policy, how would this affect vulnerable projects?

> If you're a mining operator looking to increase your income, you might be 
> interested to experiment with full-rbf as a policy.

Miners can only increase their income if users replace transactions. 2-3% 
transactions are replaced with opt-in RBF, if someone did not replace earlier 
why would they do it with full RBF? Or even if we add some users in it who 
could not signal for some reasons, do you think it would be anything above 5%?

> If you're a Bitcoin user or business and you don't like full-rbf, please 
> express an opinion on how it might affect your software/operations. I'm 
> always interested to learn more about mempool and transaction-relay 
> interactions with upper-layers and applications and to listen to feedback in 
> those areas, and I guess a lot of other Bitcoin researchers/devs too. I know 
> there have been a lot of concerns about full-rbf in the past, however I 
> believe the Bitcoin ecosystem has matured a lot since then.

I am not opposed to full-rbf; rather, I am opposed to the notion that full-rbf 
will solve all problems and the lack of basic options in Bitcoin Core to 
employ/disable different RBF policies. There is also a speculation about making 
full RBF default in an year which isn't relevant to discuss at this point 
without trying different RBF policies.

I would suggest users to try Bitcoin Knots instead which already has an option 
to disable all RBF policies if required, opt-in and full RBF policy. This can 
also be done using GUI if not familiar with config optionmempoolreplacement​.

The rationale in PR #16171 was insufficient to justify removing it in the first 
place, had 2 NACKs and was reopened to merge it. Why bother with a few lines of 
code that may allow someone disable it if required in local mempool since it's 
only useful when a big percentage of miners utilize it and essentially 
underused according to the PR author? Developers should provide basic RBF 
policy options rather than attempting to define what constitutes a good policy 
and removing the ability to disable something when necessary.

/dev/fd0

Sent with [Proton Mail](https://proton.me/) secure email.

--- Original Message ---
On Tuesday, June 14th, 2022 at 5:55 AM, Antoine Riard via bitcoin-dev 
 wrote:

> Hi list,
>
> Recent discussions among LN devs have brought back on the surface concerns 
> about the security of multi-party funded transactions (coinjoins, dual-funded 
> LN channels, on-chain DLCs, ...). It turns out there is a low-fruit, naive 
> DoS vector playable against the funding flow of any such construction due to 
> the lack of existent full-rbf transaction-relay topology on today's p2p 
> network [0] [1]. While it does not consist in a direct loss of funds, if 
> exploited well I think it's annoying enough to inflict significant timevalue 
> loss or fee-bumping waste
> to the future providers or distributed swarm of users doing multi-party 
> funded transactions. Of course, it can be fixed one layer above by 
> introducing either fidelity bonds or a reliable centralized coordinator, 
> though at the price of an overhead per-participant ressources cost and loss 
> in system openness [1].
>
> For that reason, I believe it would be beneficial to the flourishing of 
> multi-party funded transactions to fix the Dos vector by seeing a subset of 
> the network running full-rbf and enabling propagation of honest multi-party 
> transactions to the interested miners, replacing potential non-signaling 
> double-spend from a malicious counterparty. Moving towards that direction, 
> I've submitted a small patch against Bitcoin Core enabling it to turn on 
> full-rbf as a policy, still under review [3]. The default setting stays 
> **false**, i.e keeping opt-in RBF as a default replacement policy. I've 
> started to run the patch on a public node at 146.190.224.15.
>
> If you're a node operator cur

Re: [bitcoin-dev] Bitcoin covenants are inevitable

[alicexbt via bitcoin-dev]

Hi Peter,

> Only because the block reward goes away. If it was made to continue
> indefinitely - most likely with an inflation hard fork - demand for block 
> space
> would not be critical to Bitcoin's security.


I am not completely against your proposal although 100% sure this will not have 
"consensus" to be implemented. I think if bitcoin doesn't have enough demand 
for block space, it should die. I will be sad if bitcoin doesn't exist but it 
should be a lesson for all the people opposing soft forks based on drama and 
politics instead of technical review.

I don't see anything wrong with users paying 100x fees for opening and closing 
LN channels.

/dev/fd0

Sent with Proton Mail secure email.

--- Original Message ---
On Sunday, June 12th, 2022 at 9:06 AM, Peter Todd via bitcoin-dev 
 wrote:


> On Mon, Jun 06, 2022 at 09:02:18AM -0400, Erik Aronesty via bitcoin-dev wrote:
>
> > Maintaining the security of the protocol is squarely the responsibility of
> > the Bitcoin software and the core developers
> >
> > Continued demand for block space is critical for Bitcoin's security.
>
>
> Only because the block reward goes away. If it was made to continue
> indefinitely - most likely with an inflation hard fork - demand for block 
> space
> would not be critical to Bitcoin's security.
>
> --
> 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

[bitcoin-dev] BGP hijacking on Bitcoin p2p network

[alicexbt via bitcoin-dev]

Hi Bitcoin Developers,

Based on this [answer][1] from 2014, bitcoin nodes are vulnerable to BGP 
hijacking. There was an incident in March 2022, twitter prefix was hijacked and 
details are shared in 2 blog posts:

https://isc.sans.edu/diary/rss/28488

https://www.manrs.org/2022/03/lesson-learned-twitter-shored-up-its-routing-security/

'nusenu' had written an article about Tor network being vulnerable to BGP 
hijacking attacks: 
https://nusenu.medium.com/how-vulnerable-is-the-tor-network-to-bgp-hijacking-attacks-56d3b2ebfd92

After doing some research I found that RPKI ROA and BGP prefix length can help 
against BGP hijacking attacks. I checked BGP prefix length and RPKI ROA for 
first 10 IP addresses returned in `getnodeaddresses` in bitcoin core and it had 
vulnerable results.

https://i.stack.imgur.com/KD7jH.png

Has anyone written a detailed blog post or research article like nusenu? If not 
I would be interested to write one in next couple of weeks?
Looking for some "technical" feedback, links if this was already discussed in 
past with some solutions.

  [1]: https://bitcoin.stackexchange.com/a/30305/133407


/dev/fd0

Sent with Proton Mail secure email.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin covenants are inevitable

[alicexbt via bitcoin-dev]

Hi Jorge,


Misinformation is false or inaccurate information, especially that which is 
deliberately intended to deceive. A combination of 'misleading' and 
'information'. Here are a few examples and I am sure I missed a lot of others 
but its difficult for me to keep a track of everything:


1) Sapio is open source and everything mentioned in tweet is false: 
https://web.archive.org/web/20220503050140/https://twitter.com/coinableS/status/1521354192434073602

2) Personal attacks on author of BIP 119 with false information: 
https://nitter.net/s3cp256k1/status/1521238634111770624

3) Andreas Antonopoulos shared false things about CTV and explained by Ryan in 
this email: 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020414.html

4) Misleading things shared in these emails by Michael Folkson:


https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019728.html


https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020235.html


https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020286.html


https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020343.html


https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020386.html

5) Peter Todd and Zac shared misleading things about BIP 119, bitcoin and L2. I 
replied in this email: 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020322.html

6) Social media influencers like Peter McCormack tweeted they don't understand 
BIP 119 but its an attack (this was even retweeted by developers like Peter 
Todd): https://nitter.net/PeterMcCormack/status/1521253840963653632

7) Some misconceptions about BIP 119 cleared by Bitcoin Magazine: 
https://bitcoinmagazine.com/technical/what-is-bip-119-bitcoin-controversy-explained

8) There were lies and misinformation about BIP 119 on social media according 
to this Bitcoin Magazine article: 
https://bitcoinmagazine.com/technical/analyzing-bip119-and-the-controversy-surrounding-it

9) John Carvalho tweeting false things:

https://nitter.net/BitcoinErrorLog/status/1468599535538745359

https://nitter.net/BitcoinErrorLog/status/1522652884218822658

https://nitter.net/BitcoinErrorLog/status/1442554615967354880

https://nitter.net/search?q=MIT%20(from%3ABitcoinErrorLog)

10) Greg Maxwell responding to misinformation related to BIP 119 but adding 
false things in the comments: 
https://www.reddit.com/r/Bitcoin/comments/uim560/bip_119/i7dhfpb/


I am not surprised by your email but it would be better if the people who are 
interested in reviewing BIP 119 could raise the bar and not share misleading 
information.


/dev/fd0


Sent with Proton Mail secure email.
--- Original Message ---
On Sunday, June 5th, 2022 at 12:12 AM, Jorge Timón  wrote:


> "Some people say CTV is contentious, but they're spreading misinformation"? 
> Really? Seriously?Come on, guys, we can do better than nina jankovich and the 
> "fact checkers".
> Please, rise the bar.
> On Fri, Jun 3, 2022, 19:44 alicexbt via bitcoin-dev 
>  wrote:
>
> > Note: This email is an opinion and not an attack on bitcoin
> >
> > Covenants on bitcoin will eventually be implemented with a soft fork. CTV 
> > is the easiest and best possible way OP_TX looks good as well. Apart from 
> > the technical merits, covenants will improve a few other things:
> >
> > - Developers can build interesting projects with real demand in market.
> > - Students learn Sapio and not just solidity.
> > - Better tooling could be available for application developers.
> > - Maybe we see bitcoin developer hackathons in different countries.
> > - Demand for block space might increase, it wont be just exchanges and 
> > coinjoin.
> > - Funding of bitcoin developers and projects might improve. Wont need to 
> > convince a few people for grants.
> >
> > **Why covenants are not contentious?**
> >
> > Some people may write paragraphs about CTV being contentious, spread 
> > misinformation and do all types of drama, politics etc. on social media but 
> > there are zero technical NACKs for CTV. We have discussed other covenant 
> > proposals in detail on mailing list and IRC meetings with an open minded 
> > approach.
> >
> > All the developers that participated in the discussion are either okay with 
> > CTV or OP_TX or covenants in general.
> >
> > **How and when should covenants be implemented in Bitcoin?**
> >
> > I don't think we should wait for years anticipating a proposal that 
> > everyone will agree on or argue for years to pretend changes are hard in 
> > Bitcoin. We should improve the review process for soft fork BIPs and share 
> > honest opinions with agreement, disagreement on technical m

Re: [bitcoin-dev] Bitcoin covenants are inevitable

[alicexbt via bitcoin-dev]

Hi John,

> Core development is not a hackathon project.
>
> None of the quoted following items are features or responsibilities of the 
> Bitcoin software, nor Core developers

Core development was never listed as a hackathon project. Although I did not 
share responsibilities, they will improve bitcoin development. Bitcoin isn't 
only about "core developers" and I contribute to that repository.

> Whether you are a child or an attacker, none of us should care, but CTV, nor 
> any change to Bitcoin software, will never be justifiable simply because you 
> and some of your friends think it is totally cool and might make more people 
> like you or give your friends funding.

These are not my friends and I don't know any of them in real life:

https://utxos.org/signals/

Also the developers who are competent enough to understand code and soft forks 
that participated in CTV meetings are not my friends. Funding is a real issue 
for bitcoin developers, you would know if were a developer and these 
opportunities won't be available for me and my friends but everyone.

> Please stop making noise about CTV, this is not a place for spamming.

Let me share one example of spamming and noise:

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020409.html

I am aware of the things that you post on twitter and your thoughts about 
developers, author of BIP 119 and the way you would propose changes although 
not interested to debate anything related to bitcoin development with you as 
its a waste of time:

https://nitter.net/BitcoinErrorLog/status/1407312037408038919

/dev/fd0

Sent with [Proton Mail](https://proton.me/) secure email.

--- Original Message ---
On Saturday, June 4th, 2022 at 5:57 PM, John Carvalho via bitcoin-dev 
 wrote:

> Core development is not a hackathon project.
>
> None of the quoted following items are features or responsibilities of the 
> Bitcoin software, nor Core developers.
>
> Quoted:
> "- Developers can build interesting projects with real demand in market.
> - Students learn Sapio and not just solidity.
> - Better tooling could be available for application developers.
> - Maybe we see bitcoin developer hackathons in different countries.
> - Demand for block space might increase, it wont be just exchanges and 
> coinjoin.
> - Funding of bitcoin developers and projects might improve. Wont need to 
> convince a few people for grants."
>
> Whether you are a child or an attacker, none of us should care, but CTV, nor 
> any change to Bitcoin software, will never be justifiable simply because you 
> and some of your friends think it is totally cool and might make more people 
> like you or give your friends funding.
>
> Please stop making noise about CTV, this is not a place for spamming.
>
> --
>
> John Carvalho
>
> On Sat, Jun 4, 2022 at 1:00 PM 
>  wrote:
>
>> Date: Fri, 03 Jun 2022 18:39:34 +
>> From: alicexbt 
>> To: Bitcoin Protocol Discussion
>> 
>> Subject: [bitcoin-dev] Bitcoin covenants are inevitable
>> Message-ID:
>> 
>>
>> Content-Type: text/plain; charset=utf-8
>>
>> Note: This email is an opinion and not an attack on bitcoin
>>
>> Covenants on bitcoin will eventually be implemented with a soft fork. CTV is 
>> the easiest and best possible way OP_TX looks good as well. Apart from the 
>> technical merits, covenants will improve a few other things:
>>
>> - Developers can build interesting projects with real demand in market.
>> - Students learn Sapio and not just solidity.
>> - Better tooling could be available for application developers.
>> - Maybe we see bitcoin developer hackathons in different countries.
>> - Demand for block space might increase, it wont be just exchanges and 
>> coinjoin.
>> - Funding of bitcoin developers and projects might improve. Wont need to 
>> convince a few people for grants.
>>
>> **Why covenants are not contentious?**
>>
>> Some people may write paragraphs about CTV being contentious, spread 
>> misinformation and do all types of drama, politics etc. on social media but 
>> there are zero technical NACKs for CTV. We have discussed other covenant 
>> proposals in detail on mailing list and IRC meetings with an open minded 
>> approach.
>>
>> All the developers that participated in the discussion are either okay with 
>> CTV or OP_TX or covenants in general.
>>
>> **How and when should covenants be implemented in Bitcoin?**
>>
>> I don't think we should wait for years anticipating a proposal that everyone 
>> will agree on or argue for years to pretend changes are hard in Bitcoin. We 
>> should improve the review process for soft fork BIPs and share honest 
>> opinions with agreement, disagreement on technical merits.
>>
>> I prefer BIP 8 or improved BIP 8 for soft fork but I won't mind anything 
>> else being used if that improves Bitcoin. Covenants implemented in Bitcoin 
>> before the next cycle would provide opportunity for developers to build 
>> interesting things during the bear market. Ossification supporters also 
>

[bitcoin-dev] Bitcoin covenants are inevitable

[alicexbt via bitcoin-dev]

Note: This email is an opinion and not an attack on bitcoin

Covenants on bitcoin will eventually be implemented with a soft fork. CTV is 
the easiest and best possible way OP_TX looks good as well. Apart from the 
technical merits, covenants will improve a few other things:

- Developers can build interesting projects with real demand in market.
- Students learn Sapio and not just solidity.
- Better tooling could be available for application developers.
- Maybe we see bitcoin developer hackathons in different countries.
- Demand for block space might increase, it wont be just exchanges and coinjoin.
- Funding of bitcoin developers and projects might improve. Wont need to 
convince a few people for grants.

**Why covenants are not contentious?**

Some people may write paragraphs about CTV being contentious, spread 
misinformation and do all types of drama, politics etc. on social media but 
there are zero technical NACKs for CTV. We have discussed other covenant 
proposals in detail on mailing list and IRC meetings with an open minded 
approach.

All the developers that participated in the discussion are either okay with CTV 
or OP_TX or covenants in general.

**How and when should covenants be implemented in Bitcoin?**

I don't think we should wait for years anticipating a proposal that everyone 
will agree on or argue for years to pretend changes are hard in Bitcoin. We 
should improve the review process for soft fork BIPs and share honest opinions 
with agreement, disagreement on technical merits.

I prefer BIP 8 or improved BIP 8 for soft fork but I won't mind anything else 
being used if that improves Bitcoin. Covenants implemented in Bitcoin before 
the next cycle would provide opportunity for developers to build interesting 
things during the bear market. Ossification supporters also believe there is 
some window that will close soon, maybe doing changes considering each case 
individually will be a better approach. CTV is not a rushed soft fork, less 
people followed the research and it was not mentioned on social media 
repeatedly by the respected developers like other soft forks.

/dev/fd0


Sent with Proton Mail secure email.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Silent Payments – Non-interactive private payments with no on-chain overhead

[alicexbt via bitcoin-dev]

Hi woltx,

Thanks for implementing silent payments in Bitcoin Core. I tried the steps 
shared in tutorial and everything works as expected.

I have updated the silent payment address (signet) as TXT record for domain 
alice.silentbitco.in

$ dig -t txt alice.silentbitco.in +short
"tb1px3kma8e8y8z9l7e640v0x2chzrzww9cu06mqvwyrz805ffletu3s067sgh"

I have also added basic information about silent payments proposal, 
implementation and tutorial on https://silentbitco.in

I had no issues with performance of the UTXO Set and the blocks scan. I don't 
mind using flag but a new address/descriptor format should be a better 
approach. I could not review the code in detail or test edge cases however 
these suggestions by Pavol Rusnak make sense: 
https://gist.github.com/RubenSomsen/c43b79517e7cb701ebf77eec6dbb46b8?permalink_comment_id=4177027#gistcomment-4177027

/dev/fd0

Sent with [ProtonMail](https://protonmail.com/) secure email.

--- Original Message ---
On Tuesday, May 24th, 2022 at 7:01 AM, woltx via bitcoin-dev 
 wrote:

> I created a short and simple tutorial on how to make silent payments on 
> signet.
> https://gist.github.com/w0xlt/72390ded95dd797594f80baba5d2e6ee
> In this tutorial, the user will generate an address, publish it, receive and 
> spend coins from it and still no transactions are shown from this address in 
> a blockchain explorer.___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] CTV BIP Meeting #9 Notes

[alicexbt via bitcoin-dev]

Hi ZmnSCPxj,


> TLDR: MEV = Miner-extractable value, basically if your contracts are complex 
> enough, miners can analyze which of the possible contract executions are most 
> profitable for them, and order transactions on the block they are building in 
> such a way that it is the most profitable path that gets executed.
> (do correct me if that summary is inaccurate or incomplete)

Yes its elaborated as Miner Extractable Value and also referred as Maximal 
Extractable Value sometimes because value could be extracted by validators, 
sequencers and others in some chains. MEV is basically frontrunning some 
transactions based on mempool activity for profit. Profit could be achieved by 
order or include/exclude some transactions in block. Normally such 
opportunities are only found in complex smart contracts that allow trades being 
settled on-chain.

In this (IRC logs) context, Jeremy mentioned sandwich attack. An attacker looks 
for buy orders in mempool, buy before others and profit from selling at higher 
price.

> Now, having thought of this problem for no more than 5 minutes, it seems to 
> me, naively, that a mechanism with privacy would be helpful, i.e. the 
> contract details should be as little-revealed as possible, to reduce the 
> scope of miner-extractable value.

This makes sense and Tarun has shared similar ideas for AMMs in this pdf: 
https://drive.google.com/file/d/1W6PtJhGgqlNTCENE7I5pO5Brh2oqasVc/view?usp=sharing

> Probably, it is best if our covenants systems take full advantage of the 
> linearity of Schnorr signing, in that case, if there is at all some kind of 
> branch involved; for example, a previous transaction may reveal, if you have 
> the proper adaptor signature, some scalar, and that scalar is actually the 
> `s` component for a signature of a different transaction.
> Without knowledge of the adaptor signature, and without knowledge of the link 
> between this previous transaction and some other one, a miner cannot extract 
> additional value by messing with the ordering the transactions get confirmed 
> on the blockchain, or whatever.

I am assuming this is possible using all the bitcoin covenant proposals 
including CTV.

> In addition, covenant mechanisms that require large witness data are probably 
> more vulnerable to MEV.

Which covenant mechanisms require large witness data?


/dev/fd0

Sent with ProtonMail secure email.
--- Original Message ---
On Friday, May 20th, 2022 at 6:33 AM, ZmnSCPxj  wrote:


> Good morning fd0,
>
> > MEV could be one the issues associated with general covenants. There are 
> > some resources on https://mev.day if anyone interested to read more about 
> > it.
> > 13:06 <@jeremyrubin> the covenants are "self executing" and can be e.g. 
> > sandwiched13:07 <@jeremyrubin> so given that bitmatrix is sandwich 
> > attackable, you'd see similar types of MEV as Eth sees13:07 <@jeremyrubin> 
> > v.s. the MEV of e.g. lightning channels
> > 13:14 < aj> i guess i'd rather not have that sort of MEV available, because 
> > then it makes complicated MEV extraction profitable, which then makes 
> > "smart" miners more profitable than "Dumb" ones, which is maybe centralising
>
>
> Well that was interesting
>
> TLDR: MEV = Miner-extractable value, basically if your contracts are complex 
> enough, miners can analyze which of the possible contract executions are most 
> profitable for them, and order transactions on the block they are building in 
> such a way that it is the most profitable path that gets executed.
> (do correct me if that summary is inaccurate or incomplete)
>
> As a concrete example: in a LN channel breach condition, the revocation 
> transaction must be confirmed within the CSV timeout, or else the theft will 
> be accepted and confirmed.
> Now, some software will be aware of this timeout and will continually raise 
> the fee of the revocation transaction per block.
> A rational miner which sees a channel breach condition might prefer to not 
> mine such a transaction, since if it is not confirmed, the software will bump 
> up the fees and the miner could try again on the next block with the higher 
> feerates.
> Depending on the channel size and how the software behaves exactly, the miner 
> may be able to make a decision on whether it should or should not work on the 
> revocation transaction and instead hold out for a later higher fee.
>
> Now, having thought of this problem for no more than 5 minutes, it seems to 
> me, naively, that a mechanism with privacy would be helpful, i.e. the 
> contract details should be as little-revealed as possible, to reduce the 
> scope of miner-extractable value.
> For instance, Taproot is good since only one branch at a time can be 
> revealed, however, in case of a dispute, multiple competing branches of the 
> Taproot may be revealed by the disputants, and the miners may now be able to 
> make a choice.
>
> Probably, it is best if our covenants systems take full advantage of the 
> linea

[bitcoin-dev] CTV BIP Meeting #9 Notes

[alicexbt via bitcoin-dev]

Hi Bitcoin Developers,

Summary for the last CTV meeting:

Topics:

1)OP_TX
2)OP_CAT / CSFS / General Covenants
3)Script interpreter flags

===
OP_TX
===

Jeremy Rubin thinks that if folks believe OP_TX is a superior upgrading path, 
he would be delighted to shift focus. Although prefers more thorough evaluation 
of CTV / NOP upgradability vs the multibyte op-success.

Anthony Towns doesn't find OP_TX interesting if it just does CTV from start. He 
prefers adding SEPARATELY, UNHASHED and maybe things to do APO equivalent 
behavior.

Harding considers OP_TX==OP_CTV only somewhat more interesting than just OP_CTV 
because it provides a very clear upgrade path. He would be more interested if 
it came with a few more initial features.

===
OP_CAT / CSFS / General Covenants
===

Harding believes that concerns regarding general covenants are unfounded. He 
indicated an interest in learning more about one of ZmnSCPxj's criticisms, 
which is the only one about which he is personally concerned. It has to do with 
general covenants making scripts more difficult to evaluate.

Harding's thoughts on CAT+CSFS:

13:01 < harding> Without regard to the generalized covenants concern, I think 
CAT+CSFS add the smallest amount of consensus complexity to enable the greatest 
amount of experimentation with covenants and other features (like signature 
delegation), which can provide significant data about real-world usage for 
informing future soft fork designs. There'd still be lots of question marks, 
plus chances for abuse (e.g. the sort of tx spamming we saw during the block
13:01 < harding> size debates), but I think it's worth giving devs the tools to 
experiment onchain (with only their and their supporters' money) and allowing 
economic full node operators to evualuate actual use before agreeing to enforce 
future soft forks whose code will need to be maintained in perpetuitity.
13:02 < harding> Consensus stability is a reference to, for example, being able 
to implement something like drivechains on top of CAT+CSFS?

Jeremy Rubin shared some issues that are being discussed on mailing list and 
social media related to general bitcoin covenants:

- Scripts harder to analyze
- Fungibility
- MEV & consensus stability
- Whitelist/Blacklist

Anthony Towns and TechMiX added that some users think covenants can be imposed 
on their coins without consent or everyone will accept covenants so unable to 
pay them. Some bitcoin users in Iran are afraid that a generalized form of the 
covenants would enable some kind of censorship.

MEV could be one the issues associated with general covenants. There are some 
resources on https://mev.day if anyone interested to read more about it.

13:06 <@jeremyrubin> the covenants are "self executing" and can be e.g. 
sandwiched
13:07 <@jeremyrubin> so given that bitmatrix is sandwich attackable, you'd see 
similar types of MEV as Eth sees
13:07 <@jeremyrubin> v.s. the MEV of e.g. lightning channels

13:14 < _aj_> i guess i'd rather not have that sort of MEV available, because 
then it makes complicated MEV extraction profitable, which then makes "smart" 
miners more profitable than "Dumb" ones, which is maybe centralising

===
Script interpreter flags
===

Anthony Towns likes the idea of documenting exactly what rules the flags are 
meant to enforce (associated BIPs).

13:54 <@jeremyrubin> The test flags infrastructure relies on some particular 
features of validity/invalidity and flagging, which has previously been avoided 
surfacing because upgrades were at the output type level. The way the flagging 
works is a not quite the right thing for testability and simple consensus code, 
it's worth re-evaluating?
13:55 < _aj_> we changed how "things are done" with taproot, and need to 
re-evaluate how we do script enforcement in light of wanting to keep doing 
things that way?
13:56 < _aj_> we don't really have to do things the way we did for taproot, but 
i thought it was kind-of nice, i guess
13:56 <@jeremyrubin> Well taproot just sidestepped the issue because it was an 
outputtype
13:56 < _aj_> taproot had it easy because it was an outputtype
13:57 <@jeremyrubin> yes

IRC Logs: https://gnusha.org/ctv-bip-review/2022-05-17.log

/dev/fd0

Sent with [ProtonMail](https://protonmail.com/) secure email.___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Improving BIP 8 soft fork activation

[alicexbt via bitcoin-dev]

Hi Russell,

> As far as I understand things, I believe the whole notion of a MUST_SIGNAL 
> state is misguided today. Please correct me if I'm misunderstanding something 
> here.
> Back when BIP8 was first proposed by Shaolin Fry, we were in a situation 
> where many existing clients waiting for segwit signalling had already been 
> deployed. The purpose of mandatory signaling at that point in time was to 
> ensure all these existing clients would be activated together with any BIP8 
> clients.

I won't consider it misguided. Not using MUST_SIGNAL gives opportunity for 
drama and politics during signaling. MUST_SIGNAL phase is initiated when height 
+ 2016 >= timeoutheight and if a mining pool is still not sure about signaling 
at that point, maybe they are not interested in mining bitcoin anymore.

Rephrasing 'motivation' section in BIP 8:

BIP 9 activation is dependent on near unanimous hashrate signaling which may be 
impractical and result in veto by a small minority of non-signaling hashrate. 
All consensus rules are ultimately enforced by full nodes, eventually any new 
soft fork will be enforced by the economy. BIP 8 provides optional flag day 
activation after a reasonable time, as well as for accelerated activation by 
majority of hash rate before the flag date.

> We also don't need such a signal span over multiple blocks. Indeed, using 
> version bits and signaling over multiple blocks is quite bad because it risks 
> losing mining power if miners don't conform, or are unable to conform, to the 
> version bits signal. (Recall at the time taproot's signaling period started, 
> the firmware needed for many miners to signal version bits did not even exist 
> yet!).

Solutions to these problems:

1)Developers plan and ship the binaries with activation code in time.
2)Mining pools pay attention, participate in soft fork discussions, hire 
competent developers and reach out to developers in community if require help.
3)Mining pools understand the loss involved in mining invalid blocks and 
upgrade during the first month of signaling.

If some mining pools still mine invalid blocks, Bitcoin should still work 
normally as it did during May-June 2021 when 50% hashrate went down due to some 
issues in China.

/dev/fd0

Sent with [ProtonMail](https://protonmail.com/) secure email.

--- Original Message ---
On Thursday, May 12th, 2022 at 12:52 AM, Russell O'Connor via bitcoin-dev 
 wrote:

> Hi alicexbt,
>
> As far as I understand things, I believe the whole notion of a MUST_SIGNAL 
> state is misguided today. Please correct me if I'm misunderstanding something 
> here.
>
> Back when BIP8 was first proposed by Shaolin Fry, we were in a situation 
> where many existing clients waiting for segwit signalling had already been 
> deployed. The purpose of mandatory signaling at that point in time was to 
> ensure all these existing clients would be activated together with any BIP8 
> clients.
>
> However, if such other clients do not exist, the MUST_SIGNAL state no longer 
> accomplishes its purpose. Going forward, I think there is little reason to 
> expect such other clients to exist alongside a BIP8 deployment. If everyone 
> uses a BIP8 deployment, then there are no other clients to activate. 
> Alternatively, Speedy Trial was specifically designed to avoid this parallel 
> deployment for the reason that several people object to allowing their 
> client's non-BIP8 activation logic to be hijacked in this manner.
>
> Now I understand that some people would like *some* signal on the chain that 
> indicates a soft-fork activation in order to allow people who object to the 
> fork to make an "anti-fork" that rejects blocks containing the soft-fork 
> signal. And while some sort of mandatory version bit signaling *could* be 
> used for this purpose, we do not *have* to use version bits. We also don't 
> need such a signal span over multiple blocks. Indeed, using version bits and 
> signaling over multiple blocks is quite bad because it risks losing mining 
> power if miners don't conform, or are unable to conform, to the version bits 
> signal. (Recall at the time taproot's signaling period started, the firmware 
> needed for many miners to signal version bits did not even exist yet!).
>
> A soft-fork signal to enable an "anti-fork" only needs to be on a single 
> block and it can be almost anything. For example we could have a signal that 
> at the block at lockin or perhaps the block at activation requires that the 
> coinbase must *not* contain the suffix "taproot sucks!". This suffices to 
> prepare an "anti-fork" which would simply require that the specified block 
> must contain the suffix "taproot sucks!".
>
> Anyway, I'm

Re: [bitcoin-dev] Speedy covenants (OP_CAT2)

[alicexbt via bitcoin-dev]

Hi vjudeu,

> It can be changed by using different sighashes, for example, it is possible 
> to create a "negative fee transaction", where all transaction costs are paid 
> by receiver. Using SIGHASH_SINGLE | SIGHASH_ANYONECANPAY with a higher amount 
> in outputs than inputs is enough to do that, see testnet3 transaction 
> 495d2007ae8b741c70c3d278c02ce03702223b9675e954ecabbb634c6cd5bf40.

This transaction has 2 inputs: 0.00074 tBTC and 0.00073 tBTC (0.00074 + 0.00073 
= 0.00147) which is more than output amount 0.001 tBTC

/dev/fd0

Sent with [ProtonMail](https://protonmail.com/) secure email.
--- Original Message ---
On Saturday, May 7th, 2022 at 9:22 AM, vjudeu via bitcoin-dev 
bitcoin-dev@lists.linuxfoundation.org wrote:

>> Re-enabling OP_CAT with the exact same OP would be a hardfork, but creating 
>> a new OP_CAT2 that does the same would be a softfork.
>
> We have TapScript for that. OP_CAT is defined as OP_SUCCESS, it can be 
> re-enabled in a soft-fork way. For now, OP_CAT in TapScript simply means 
> "anyone can move those coins", so adding some restrictions is all we need to 
> re-enable this opcode. Introducing OP_CAT2 is not needed at all, unless it 
> will be totally different, but then it should not be named as OP_CAT2, but 
> rather as OP_SOMETHING_ELSE, it depends how different it will be from OP_CAT.
>
>> OP_1 OP_DUP OP_CAT OP_DUP OP_CAT OP_DUP OP_CAT OP_DUP OP_CAT OP_DUP OP_CAT 
>> OP_DUP OP_CAT ...
>
> So we can use OP_SUBSTR instead. Maybe even OP_SPLIT will be enough, if data 
> expansion is the only problem, then we can focus on getting it smaller. Or 
> better, we could use OP_FIND that would return true/false answer if element A 
> is a part of element B, when we do byte-to-byte comparison. In general, we 
> can use many different string-based functions to do the same things, we can 
> choose something that will not exponentially explode as OP_CAT.
>
>> It was considered unfair that the sender is paying for the security of the 
>> receiver.
>
> It can be changed by using different sighashes, for example, it is possible 
> to create a "negative fee transaction", where all transaction costs are paid 
> by receiver. Using SIGHASH_SINGLE | SIGHASH_ANYONECANPAY with a higher amount 
> in outputs than inputs is enough to do that, see testnet3 transaction 
> 495d2007ae8b741c70c3d278c02ce03702223b9675e954ecabbb634c6cd5bf40.
>
> On 2022-05-07 05:06:46 user ZmnSCPxj via bitcoin-dev 
> bitcoin-dev@lists.linuxfoundation.org wrote:
>
>> Good morning Jorge,
>
>> OP_CAT was removed. If I remember correctly, some speculated that perhaps it 
>> was removed because it could allow covenants.I don't remember any technical 
>> concern about the OP besides enabling covenants.Before it was a common 
>> opinion that covenants shouldn't be enabled in bitcoin because, despite 
>> having good use case, there are some nasty attacks that are enabled with 
>> them too. These days it seems the opinion of the benefits being worth the 
>> dangers is quite generalized. Which is quite understandable given that more 
>> use cases have been thought since then.
>
> I think the more accurate reason for why it was removed is because the 
> following SCRIPT of N size would lead to 2^N memory usage:
>
> OP_1 OP_DUP OP_CAT OP_DUP OP_CAT OP_DUP OP_CAT OP_DUP OP_CAT OP_DUP OP_CAT 
> OP_DUP OP_CAT ...
>
> In particular it was removed at about the same time as OP_MUL, which has 
> similar behavior (consider that multiplying two 32-bit numbers results in a 
> 64-bit number, similar to OP_CATting a vector to itself).
>
> OP_CAT was removed long before covenants were even expressed as a possibility.
>
> Covenants were first expressed as a possibility, I believe, during 
> discussions around P2SH.
> Basically, at the time, the problem was this:
>
> * Some receivers wanted to use k-of-n multisignature for improved security.
> * The only way to implement this, pre-P2SH, was by putting in the 
> scriptPubKey all the public keys.
> * The sender is the one paying for the size of the scriptPubKey.
> * It was considered unfair that the sender is paying for the security of the 
> receiver.
>
> Thus, OP_EVAL and the P2SH concept was conceived.
> Instead of the scriptPubKey containing the k-of-n multisignature, you create 
> a separate script containing the public keys, then hash it, and the 
> scriptPubKey would contain the hash of the script.
> By symmetry with the P2PKH template:
>
> OP_DUP OP_HASH160  OP_EQUALVERIFY OP_CHECKSIG
>
> The P2SH template would be:
>
> OP_DUP OP_HASH160  OP_EQUALVERIFY OP_EVAL
>
> OP_EVAL would take the stack top vector and treat it as a Bitcoin SCRIPT.
>
> It was then pointed out that OP_EVAL could be used to create recursive 
> SCRIPTs by quining using OP_CAT.
> OP_CAT was already disabled by then, but people were talking about 
> re-enabling it somehow by restricting the output size of OP_CAT to limit the 
> O(2^N) behavior.
>
> Thus, since then, OP_CAT has been associated with recursive covenants

Re: [bitcoin-dev] Improving BIP 8 soft fork activation

[alicexbt via bitcoin-dev]

Hi Billy,

Thanks for the feedback. I agree with everything and 
bip-trinary-version-signaling looks interesting.

> A primary difference from both BIP8 and BIP9 is that this proposal uses 
> tri-state version signaling (rather than binary version bits) that can encode 
> both active support as well as active opposition to an active soft fork.


I think 'support' and 'opposition' can be replaced with readiness. Miners 
should not consider signaling as voting.

> The meaning for each ternary value is as follows:


0 - No signal
1 - Ready for new consensus rules
2 - Not ready for new consensus rules

The concept of a minimum and maximum threshold sounds intriguing, and I'm 
interested to read what other developers have to say about it.

Concept ACK on removing LOT, using tri-state version signaling, min/max 
threshold and required threshold calculation.


/dev/fd0

Sent with ProtonMail secure email.
--- Original Message ---
On Tuesday, May 10th, 2022 at 9:01 PM, Billy Tetrud billy.tet...@gmail.com 
wrote:



> I think this is a useful proposal. There are certainly things about BIP9 that 
> BIP8 fixes. I believe taproot's speedy trial did kind of a hybrid, but a BIP 
> spec was never produced for it afaik. A possibly unhelpful comment:
>
> > minimum_activation_height
> > I think a minor improvement would be to specify this as 
> > minimum_activation_blocks, ie a number of blocks passed the start_height. 
> > Slightly easier to reason about and change when necessary. I proposed 
> > semantics like that here.
> > In any case, I'll give this a concept ACK. I would very much like future 
> > soft forks to use a previously specified activation mechanism rather than 
> > rolling out a rushed unspeced thing as part of the (very orthogonal) soft 
> > fork implementation.
> > On Tue, May 10, 2022 at 9:02 AM alicexbt via bitcoin-dev 
> > bitcoin-dev@lists.linuxfoundation.org wrote:
>
> > Hi Bitcoin Developers,
> >
> > There were some disagreements with speedy trial activation method recently 
> > and BIP 8 became controversial because of LOT earlier. I have tried to 
> > solve these two problems after reading some arguments for/against different 
> > activation methods by removing LOT from BIP 8 and calculating MUST_SIGNAL 
> > state based on threshold reached.
> >
> > BIP draft with no code and some changes in BIP 8: 
> > https://gist.github.com/144bytes/5e58cad7ba9d9c1a7000d304920fe6f1
> >
> > State transitions diagram: https://i.imgur.com/dj4bFVK.png
> >
> > This proposal removes lockinontimeout flag, activation never fails although 
> > MUST_SIGNAL can be longer if miners signaling does not reach the threshold. 
> > Longer period for MUST_SIGNAL state is useful for coordination if LOCKED_IN 
> > was not reached.
> >
> > MUST_SIGNAL = ((100-t)/10)*2016 blocks, where t is threshold reached and 
> > blocks that fail to signal in MUST_SIGNAL phase are invalid.
> >
> > Example:
> >
> > - This activation method is used for a soft fork
> > - Only 60% miners signaled readiness and timeout height was reached
> > - MUST_SIGNAL phase starts and will last for 4*2016 blocks
> > - LOCKED_IN and ACTIVE states remain same as BIP 8
> > - Soft fork is activated with a delay of 2 months
> >
> > /dev/fd0
> >
> > Sent with ProtonMail secure 
> > email.___
> > 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] Improving BIP 8 soft fork activation

[alicexbt via bitcoin-dev]

Hi Bitcoin Developers,

There were some disagreements with speedy trial activation method recently and 
BIP 8 became controversial because of LOT earlier. I have tried to solve these 
two problems after reading some arguments for/against different activation 
methods by removing LOT from BIP 8 and calculating MUST_SIGNAL state based on 
threshold reached.

BIP draft with no code and some changes in BIP 8: 
https://gist.github.com/144bytes/5e58cad7ba9d9c1a7000d304920fe6f1

State transitions diagram: https://i.imgur.com/dj4bFVK.png

This proposal removes lockinontimeout flag, activation never fails although 
MUST_SIGNAL can be longer if miners signaling does not reach the threshold. 
Longer period for MUST_SIGNAL state is useful for coordination if LOCKED_IN was 
not reached.

MUST_SIGNAL = ((100-t)/10)*2016 blocks, where t is threshold reached and blocks 
that fail to signal in MUST_SIGNAL phase are invalid.

Example:

- This activation method is used for a soft fork
- Only 60% miners signaled readiness and timeout height was reached
- MUST_SIGNAL phase starts and will last for 4*2016 blocks
- LOCKED_IN and ACTIVE states remain same as BIP 8
- Soft fork is activated with a delay of 2 months

/dev/fd0

Sent with [ProtonMail](https://protonmail.com/) secure email.___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] CTV BIP Meeting #8 Notes

[alicexbt via bitcoin-dev]

Hi Bitcoin Developers,

Summary for the last CTV meeting:

Topics:

1)APO version of the simple vault
2)APO as alternative to CTV
3)fiatjaf's CTV spacechain demo
4)Compare CTV with other covenant proposals
5)Recursive covenants
6)Responding to FUD

===
APO version of the simple vault
===

- It is vulnerable to the half-spend problem, where multiple vaulted outputs 
(of the same denomination) can be spent together, burning all but the first to 
fees. Fixing this requires amending APOAS to cover the current input index.
- The unvault transaction is third-party malleable (it can have more inputs 
added to it). One practical implication is that you can't hand a list of the 
unvault txids to a watchtower, you have to tell them which outpoints to watch 
which is less privacy-preserving. Fixing this requires amending APOAS to cover 
the number of inputs.
Both of these issues are fixed by the BIP 118 changes suggested by darosior 
(although they still not officially spec'd afaik), which would basically make 
APO have a CTV-equivalent hash mode (minus scriptSig of other inputs)
- simple-apo-vault could use APO-as-spec'd with 
SIGHASH_SINGLE|SIGHASH_ANYONECANPAY, which would solve the half-spend problem 
(but not malleability) and have some other interesting properties, like more 
natural dynamic fees (add inputs+change) and the ability spend multiple vaulted 
outputs together. This would, however, introduce a tx pinning attack vector and 
prevent rate-limited vaults.

===
APO as alternative to CTV
===

- Current APO is unusable as a CTV alternative, (revised)APO seems to be as 
useful as CTV is (plus some extra flexibility from existing sighash flags)
- Main drawbacks being the additional witness satisfaction cost, the 
network-side full-node validation costs of checking a signature instead of just 
a hash, and not being segwit0-compatible (meaning, among others, not 
quantumphobic-friendly)
- Its about 3x for APO-in-taproot vs CTV-in-taproot. CTV-in-segwitv0 and 
CTV-in-bare-spk get you even more savings
- APO is far from being ready, let alone (revised)APO
- APOv2 would be both better for Eltoo and better for CTV, since you can use a 
trick to make the signatures smaller
- "layered commitments" is essential for eltoo to be usable or not is unclear. 
AJ Towns thinks it is required while Christian Decker thinks it is not.

===
fiatjaf's CTV spacechain demo
===

https://github.com/fiatjaf/simple-ctv-spacechain

===
Compare CTV with other covenant proposals
===

Unlike crypto primitves (e.g., BLS vs Schnorr), there's not really actually a 
defined way to compare them. So one exercise of value would be if everyone 
tries to actually either agree to or come up with their own framework for 
comparing covenants.

Billy Tetrud's email: 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020402.html

- Prefers CTV for several reasons. Mainly because of being simple, 
documentation, code, tools, review and testing.
- Everything else either introduces malleability, infinite recursion, or has 
interactions with other proposed opcodes that could introduce potentially 
undesirable effects like those.
- Anything involving OP_CAT is out for the time being. There are so many things 
it can enable that it seems most people aren't comfortable adding it at the 
moment.
- APO wallet vaults seem rather hacky, inefficient, and limited.
- TLUV is built for evictions, TLUV + IN_OUT_AMOUNT and OP_CHECKOUTPUTVERIFY 
allows recursive covenants

===
Recursive covenants
===

jamesob:
I don't particularly understand the aversion to infinite recursion, which seems 
no different than the risk of potentially burning your coins. It's not like 
infinite recursion on bitcoin is some kind of DoS vector or poses execution 
overhead like an Ethereum VM bug might.

rgrant:
i think people who want recursion for cool stuff are worried that pedestrian 
stuff will prevent it.

jeremyrubin:
i think people are afraid of weird shit happening, less so of recursion in 
particular

hsjoberg:
"Recursive covenants" is the boogie man

shesek:
"recursion" translates to "complex black magic" for nondevs' -- recursion is 
the new turing completeness

===
Responding to FUD
===

- It could be a good idea to include showing a way to do blacklists in the bug 
bounty offer
- The potential concerns about recursive covenants have to clearly explained so 
they can be properly examined.
- An article 

Re: [bitcoin-dev] What to do when contentious soft fork activations are attempted

[alicexbt via bitcoin-dev]

Hi Michael,

> Maybe the whole thing worked as designed. Some users identified what was 
> going on, well known Bitcoin educators such as Andreas Antonopoulos, Jimmy 
> Song etc brought additional attention to the dangers, a URSF movement started 
> to gain momentum and those attempting a contentious soft fork activation 
> backed off. (Disappointingly Bitcoin Optech didn't cover my previous posts to 
> this mailing list 
> [1](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-October/019535.html),
>  
> [2](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019728.html),
>  
> [3](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020235.html)
>  highlighting the dangers many months ago or recent posts. Normally Optech is 
> very high signal.)

Some users have been misled and there is nothing great being achieved by doing 
this on social media. Andreas is clueless about BIP 119 and other covenant 
proposals. He is spreading misinformation and some of the URSF enthusiasts do 
not understand what are they even opposing or going to run with risks involved.

Answering the subject of this email: "What to do when contentious soft forks 
activations are attempted?"

- Do not consider something contentious because someone said it on mailing list
- Do not spread misinformation
- Read all posts in detail with different opinions
- Avoid personal attacks
- Look at the technical details, code etc. and comment on things that could be 
improved

/dev/fd0

Sent with [ProtonMail](https://protonmail.com/) secure email.
--- Original Message ---
On Saturday, April 30th, 2022 at 3:23 PM, Michael Folkson via bitcoin-dev 
bitcoin-dev@lists.linuxfoundation.org wrote:

> I’ve been in two minds on whether to completely move on to other topics or to 
> formulate some thoughts on the recent attempt to activate a contentious soft 
> fork. In the interests of those of us who have wasted days/weeks/months of 
> our time on this (with no personal upside) and who don’t want to repeat this 
> exercise again I thought I should at least raise the issue for discussion of 
> what should be done differently if this is tried again in future.
>
> This could be Jeremy with OP_CTV at a later point (assuming it is still 
> contentious) or anyone who wants to pick up a single opcode that is not yet 
> activated on Bitcoin and try to get miners to signal for it bypassing 
> technical concerns from many developers, bypassing Bitcoin Core and bypassing 
> users.
>
> Maybe the whole thing worked as designed. Some users identified what was 
> going on, well known Bitcoin educators such as Andreas Antonopoulos, Jimmy 
> Song etc brought additional attention to the dangers, a URSF movement started 
> to gain momentum and those attempting a contentious soft fork activation 
> backed off. (Disappointingly Bitcoin Optech didn't cover my previous posts to 
> this mailing list 
> [1](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-October/019535.html),
>  
> [2](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019728.html),
>  
> [3](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020235.html)
>  highlighting the dangers many months ago or recent posts. Normally Optech is 
> very high signal.)
>
> Alternatively this was the first time a contentious soft fork activation was 
> attempted, we were all woefully unprepared for it and none of us knew what we 
> were doing.
>
> I’m unsure on the above. I’d be interested to hear thoughts. What I am sure 
> of is that it is totally unacceptable for one individual to bring the entire 
> Bitcoin network to the brink of a chain split. There has to be a personal 
> cost to that individual dissuading them from trying it again otherwise 
> they’re motivated to try it again every week/month. Perhaps the personal cost 
> that the community is now prepared if that individual tries it again is 
> sufficient. I’m not sure. Obviously Bitcoin is a permissionless network, 
> Bitcoin Core and other open source projects are easily forked and no 
> authority (I’m certainly no authority) can stop things like this happening 
> again.
>
> I’ll follow the responses if people have thoughts (I won't be responding to 
> the instigators of this contentious soft fork activation attempt) but other 
> than that I’d like to move on to other things than contentious soft fork 
> activations. Thanks to those who have expressed concerns publicly (too many 
> to name, Bob McElrath was often wording arguments better than I could) and 
> who were willing to engage with the URSF conversation. If an individual can 
> go directly to miners to get soft forks activated bypassing technical 
> concerns from many developers, bypassing Bitcoin Core and bypassing users 
> Bitcoin is fundamentally broken. The reason I still have hope that it isn't 
> is that during a period of general apathy some people were willing to stand 
> up and actively resist it.
>
> --
>

[bitcoin-dev] Multiple ways to do bitcoin covenants

[alicexbt via bitcoin-dev]

CTV and other covenant proposals, tradeoffs, and overlapping features are among 
the topics being explored recently. I had some views and questions on this 
subject.:

a) Does bitcoin already have opcodes with overlapping features? Yes

b) Can we have multiple ways with some overlapping features to do bitcoin 
covenants with some tradeoffs? Yes
_
c) What are these tradeoffs if we compare CTV, APO, TLUV and TXHASH+CSFS?

I am sure about a) because it was already answered in CTV chat by Jeremy and 
sheshek. Example: CHECKSIG and CHECKSIGADD is redundant with OP_IF and OP_ADD

Not sure if we have "consensus" on b) but I don't see anything wrong with it.

For c) I would prefer CTV because:

- Simpler
- Blockspace effient
- Can be used even without taproot

Covering bare script, as in segwit v0, is necessary. Exposing a pubkey in case 
of an EC break will be a disaster, and vaults imply very long lived storage. 
Root CA offline certificates can often have shelf life measured in decades. 
However, NSA has issued warnings, NIST has issued guidelines, and executive 
order to prepare for the quantum shift. As a result, forcing everyone into a 
quantum-unsafe position is unsustainable.

Other developers might use a different way to do bitcoin covenant for other 
reasons. Example: Russel O'Connor would prefer general OP_TXHASH design
/dev/fd0

Sent with [ProtonMail](https://protonmail.com/) secure email.___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] What to expect in the next few weeks

[alicexbt via bitcoin-dev]

Hi Michael,

> Doesn't sound to me that this was being "offered up for discussion". A week 
> from April 17th would have been Sunday April 24th (2 days ago). Readers of 
> this mailing list would have had no idea of these plans.

I'm quoting 5 points from the blog post and putting some words in capital :

- EVALUATE the software PROPOSED above and find any bugs (claim 5.5 BTC 
Bounties?)
- DISCUSS vociferously through the next few months if BIP-119 SHOULD BE 
ACTIVATED OR NOT (that means you should e.g. POST PUBLICLY if you/your org 
ENDORSES this particular path, cover it in your news org, etc).
- Before the end of July, Miners should signal IF the speedy trial should 
succeed
- Before November, IF Speedy Trial passes, then all users should ensure they 
upgrade to validate CTV
- IF Speedy Trial FAILS, at least we were at the ball, and we can either TRY 
AGAIN NEXT YEAR, meaning CTV would be available for use in at minimum 1.5 
years, or we can RE-EVALUATE the design of CTV against ALTERNATIVES that would 
take more time to prepare engineering wise (e.g., more general covenants, small 
tweaks to CTV).

> I'll let readers assess from the above who is accurately informing the 
> mailing list and who is using personal blog posts and messaging apps to give 
> a completely different impression to one set of people versus readers of this 
> mailing list.

People are free to discuss things on different apps and websites. Not everyone 
enjoys spamming the mailing list every day with the same message repeated in 
many threads. Instead of trusting a group, I would ask them to verify 
everything and think critically and independently.

> I like to give people the benefit of the doubt and assume incompetence rather 
> than malice but when it comes to potential chain splits it doesn't really 
> matter which it is. It has the same effect and poses the same network risk. 
> If and when you try something like this again I hope this is remembered.

You should assume good faith not incompetence for a developer who has 
contributed to bitcoin for years as suggested earlier: 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020303.html

Chain splits are discussed during each soft fork and nothing wrong in a 
conversation that is looking for solutions. Personal attacks will not stop 
chain split but they might derail the covenants research and development. 
Jeremy will be remembered for his contributions in bitcoin covenants and others 
can help him improve bitcoin with code. Some developers have already started 
reviewing, testing and even writing code for use cases of other covenant 
proposals.

> The Binance hack rollback suggestion, the NACKing then coin flip suggestion 
> on Taproot activation and now this. It seems like this trillion dollar 
> industry is a joke to you. I know we aren't supposed to get personal on this 
> mailing list but honestly if you are going to continue with these stunts I'd 
> rather you do them on a different blockchain.

- Developers have discussed, suggested and wrote lot of things during Binance 
and Bitfinex hack. This includes lot of respected core developers and 
co-authors of previous soft forks. I would not rehash and go in to the details 
of each event, comments etc. as this has nothing to do with BIP 119.

https://www.reddit.com/r/Bitcoin/comments/4vupa6/p2shinfo_shows_movement_out_of_multisig_wallets/d61qyaj/

- Coin flip was neither proposed by Jeremy nor used for anything during Taproot

Bitcoin developers care about bitcoin, despite our differing viewpoints on some 
issues. I'm sure we can accuse others of being irresponsible about a lot of 
things, and breaking bitcoin doesn't always require a soft fork. Nobody needs 
anyone's permission to suggest improvements to Bitcoin or to contribute in 
other ways, the most common of which is coding.

Please don't use personal insults to deter bitcoin contributors.

/dev/fd0

Sent with [ProtonMail](https://protonmail.com/) secure email.
--- Original Message ---
On Tuesday, April 26th, 2022 at 7:23 PM, Michael Folkson via bitcoin-dev 
bitcoin-dev@lists.linuxfoundation.org wrote:

> Jeremy
>
>> The reason there was not a mailing list post is because that's not a 
>> committed plan, it was offered up for discussion to a public working group 
>> for feedback as a potential plan.
>> In the interests of posterity from your personal blog on April 17th 1:
>> "Within a week from today, you’ll find software builds for a CTV Bitcoin 
>> Client for all platforms linked here:
>
> - Mac OSX TODO:
> - Windows TODO:
> - Linux TODO:
>
> These will be built using GUIX, which are reproducible for verification."
>
> Doesn't sound to me that this was being "offered up for discussion". A week 
> from April 17th would have been Sunday April 24th (2 days ago). Readers of 
> this mailing list would have had no idea of these plans.
>
>> You've inaccurately informed the list on something no one has communicated 
>> committed intent for.
>
> I'

Re: [bitcoin-dev] User Resisted Soft Fork for CTV

[alicexbt via bitcoin-dev]

Hi Peter and Zac,

> I like the maxim of Peter Todd: any change of Bitcoin must benefit all
> users. This means that every change must have well-defined and transparent
> benefits. Personally I believe that the only additions to the protocol that
> would still be acceptable are those that clearly benefit layer 2 solutions
> such as LN and do not carry the dangerous potential of getting abused by
> freeloaders selling commercial services on top of “free” eternal storage on
> the blockchain.
>
> To strengthen your point: benefiting "all users" can only be done by 
> benefiting layer 2 solutions in some way, because it's inevitable that the 
> vast majority of users will use layer 2 because that's the only known way 
> that Bitcoin can scale.

- CTV does not allow bitcoin blockchain to be used as storage
- CTV will benefit layer 2 solutions: lightning, sidechains, spacechain etc.
- Every L2 is dependent on L1 and soft forks could improve things that benefit 
both

There are a few emails with information that could be interpreted in a wrong 
way on this mailing list related to CTV or creating contentious environment. I 
had expected better things from bitcoin developers. This is not just the 
opinion of someone who supports CTV but even people who are trying to read 
things and form an opinion: 
https://nitter.net/NicolasDorier/status/1518407535480705024

I am sure there are lot of positives if we look at things differently and will 
end the email on a good note:

You might like Jeremy or hate him, however he took some real efforts in working 
on CTV, Sapio etc. and even if BIP 119 never gets activated his contribution in 
bitcoin covenants will always be appreciated.

/dev/fd0

Sent with [ProtonMail](https://protonmail.com/) secure email.___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV

[alicexbt via bitcoin-dev]

Hi TheBlueMatt,

>> There are at least three or four separate covenants designs that have
>>> been posted to this list, and I don't see why we're even remotely
>>> talking about a specific one as something to move forward with at
>>> this point.
>>
>>> To my knowledge none of these other proposals (drafts, really) have
>>> actual implementations let alone the many sample usages that exist for
>> CTV.

> You can fix this! Don't point to something you can easily remedy in the > 
> short-term as an argument
> for or against something in the long-term.

How can we fix this? If a proposal already fixed it, does it have some 
consensus or it was fixed in a different way?

/dev/fd0

Sent with [ProtonMail](https://protonmail.com/) secure email.___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev