Re: [bitcoin-dev] Consensus protocol immutability is a feature

[Raystonn . via bitcoin-dev]

None of these required a hard fork.  I should rephrase my previous email to 
clarify the intended topic as hard consensus changes, requiring a hard fork.  
"Soft" forks can be useful.

Raystonn


From: Jorge Timón 
Sent: Saturday, May 22, 2021 7:55 AM
To: Raystonn . ; Bitcoin Protocol Discussion 

Subject: Re: [bitcoin-dev] Consensus protocol immutability is a feature

That is clearly not true. People entretain making changes to the protocol all 
the time. Bitcoin is far from perfect and not improving it would be stupid in 
my opinion.
Some improvements require changes to the consensus rules.
Recent changes include relative lock time verify or segwit. These are important 
changes that made things like lightning much easier and efficient than they 
could possibly be without them.
Taproot, which is a recent proposal, could help simplify the lightning protocol 
even further, and make it more efficient and its usage more private. And there 
are more use cases.

There have been consensus rule changes since bitcoin started, and with good 
reason. As a user, you can always oppose new changes. And if enough users agree 
with you, you will be able to maintain your own chain with the old rules. At 
the same time, there's nothing you can do to stop other users who want those 
changes from coordinating with each other to adopt them.

Perhaps you're interested in bip99, which discusses consensus rule changes in 
more detail.



On Sat, May 22, 2021, 13:09 Raystonn . via bitcoin-dev 
mailto:bitcoin-dev@lists.linuxfoundation.org>>
 wrote:
Suggestions to make changes to Bitcoin's consensus protocol will only ever be 
entertained if Bitcoin is completely dead without such a change.  Any attempt 
to change consensus protocol without a clear and convincing demonstration to 
the entire network of participants that Bitcoin will die without that change is 
a waste of your own time.  Bitcoin's resistance to consensus changes is a 
feature that makes it resistant to being coopted and corrupted.  I recommend 
developers focus on making improvements that do not attempt to change the 
consensus protocol.  Otherwise, you are simply working on an altcoin, which is 
off-topic here.

Raystonn

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org<mailto: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] Consensus protocol immutability is a feature

[Raystonn . via bitcoin-dev]

Suggestions to make changes to Bitcoin's consensus protocol will only ever be 
entertained if Bitcoin is completely dead without such a change.  Any attempt 
to change consensus protocol without a clear and convincing demonstration to 
the entire network of participants that Bitcoin will die without that change is 
a waste of your own time.  Bitcoin's resistance to consensus changes is a 
feature that makes it resistant to being coopted and corrupted.  I recommend 
developers focus on making improvements that do not attempt to change the 
consensus protocol.  Otherwise, you are simply working on an altcoin, which is 
off-topic here.

Raystonn

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

[bitcoin-dev] Network-layer attacks

[Raystonn . via bitcoin-dev]

This study was released last week, detailing some attacks at the network layer: 
https://btc-hijack.ethz.ch/files/btc_hijack.pdf.  Of the countermeasures 
discussed in the paper, the use of encryption to secure communications between 
nodes looks like low hanging fruit.


Raystonn

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

Re: [bitcoin-dev] Hard fork proposal from last week's meeting

[Raystonn . via bitcoin-dev]

Low node costs are a good goal for nodes that handle transactions the node 
operator can afford.  Nobody is going to run a node for a network they do not 
use for their own transactions.  If transactions have fees that prohibit use 
for most economic activity, that means node count will drop until nodes are 
generally run by those who settle large amounts.  That is very centralizing.

Raystonn

On 29 Mar 2017 12:14 p.m., Jared Lee Richardson via bitcoin-dev 
 wrote:
In order for any blocksize increase to be agreed upon, more consensus is 
needed.  The proportion of users believing no blocksize increases are needed is 
larger than the hardfork target core wants(95% consensus).  The proportion of 
users believing in microtransactions for all is also larger than 5%, and both 
of those groups may be larger than 10% respectively.  I don't think either the 
Big-blocks faction nor the low-node-costs faction have even a simple majority 
of support.  Getting consensus is going to be a big mess, but it is critical 
that it is done.

On Wed, Mar 29, 2017 at 12:49 AM, Martin Lízner via bitcoin-dev 
>
 wrote:
If there should be a hard-fork, Core team should author the code. Other dev 
teams have marginal support among all BTC users.

Im tending to believe, that HF is necessary evil now. But lets do it in 
conservative approach:
- Fix historical BTC issues, improve code
- Plan HF activation date well ahead - 12 months+
- Allow increasing block size on year-year basis as Luke suggested
- Compromise with miners on initial block size bump (e.g. 2MB)
- SegWit

Martin Lizner

On Tue, Mar 28, 2017 at 6:59 PM, Wang Chun via bitcoin-dev 
>
 wrote:
I've proposed this hard fork approach last year in Hong Kong Consensus
but immediately rejected by coredevs at that meeting, after more than
one year it seems that lots of people haven't heard of it. So I would
post this here again for comment.

The basic idea is, as many of us agree, hard fork is risky and should
be well prepared. We need a long time to deploy it.

Despite spam tx on the network, the block capacity is approaching its
limit, and we must think ahead. Shall we code a patch right now, to
remove the block size limit of 1MB, but not activate it until far in
the future. I would propose to remove the 1MB limit at the next block
halving in spring 2020, only limit the block size to 32MiB which is
the maximum size the current p2p protocol allows. This patch must be
in the immediate next release of Bitcoin Core.

With this patch in core's next release, Bitcoin works just as before,
no fork will ever occur, until spring 2020. But everyone knows there
will be a fork scheduled. Third party services, libraries, wallets and
exchanges will have enough time to prepare for it over the next three
years.

We don't yet have an agreement on how to increase the block size
limit. There have been many proposals over the past years, like
BIP100, 101, 102, 103, 104, 105, 106, 107, 109, 148, 248, BU, and so
on. These hard fork proposals, with this patch already in Core's
release, they all become soft fork. We'll have enough time to discuss
all these proposals and decide which one to go. Take an example, if we
choose to fork to only 2MB, since 32MiB already scheduled, reduce it
from 32MiB to 2MB will be a soft fork.

Anyway, we must code something right now, before it becomes too late.
___
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] Why Satoshi's temporary anti-spam measure isn'ttemporary

[Raystonn . via bitcoin-dev]

Eric, any plans to correct your article at 
https://bitcoinmagazine.com/21377/settling-block-size-debate/?


From: Mike Hearn via bitcoin-dev 
Sent: Wednesday, July 29, 2015 4:15 AM
To: Eric Lombrozo 
Cc: Bitcoin Dev 
Subject: Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure 
isn'ttemporary

  Irrelevant what term was used - and as brilliant as Satoshi might have been 
at some things, he obviously got this one wrong.

I don't think it's obvious. You may disagree, but don't pretend any of this 
stuff is obvious.

Consider this:  the highest Bitcoin tx fees can possibly go is perhaps a little 
higher than what our competition charges. Too much higher than that, and people 
will just say, you know what  I'll make a bank transfer. It's cheaper and 
not much slower, sometimes no slower at all.

And now consider that in many parts of the world bank transfers are free.

They aren't actually free, of course, but they appear to be free because the 
infrastructure for doing them is cross subsidised by the fees on other products 
and services, or hidden in the prices of goods sold.

So that's a market reality Bitcoin has to handle. It's already more expensive 
than the competition sometimes, but luckily not much more, and anyway Bitcoin 
has some features those other systems lack (and vice versa). So it can still be 
competitive. 

But your extremely vague notion of a fee market neglects to consider that it 
already exists, and it's not a market of Bitcoin users buying space in Bitcoin 
blocks. It's users paying to move money.

You can argue with this sort of economic logic if you like, but don't claim 
this stuff is obvious.

  Nobody threatened to start mining huge blocks given how relatively 
inexpensive it was to mine back then?


Not that I recall. It wasn't a response to any actual event, I think, but 
rather a growing realisation that the code was full of DoS attacks.


  Guess what? SPV wallets are still not particularly widespread…and those that 
are out there are notoriously terrible at detecting network forks and making 
sure they are on the right one.

The most popular mobile wallet (measured by installs) on Android is SPV. It has 
between 500,000 and 1 million installs, whilst Coinbase has not yet crossed the 
500,000 mark. One of the most popular wallets on iOS is SPV. If we had SPV 
wallets with better user interfaces on desktops, they'd be more popular there 
too (perhaps MultiBit HD can recapture some lost ground).

So I would argue that they are in fact very widespread.

Likewise, they are not notoriously terrible at detecting chain forks. That's 
a spurious idea that you and Patrick have been pushing lately, but they detect 
them and follow reorgs across them according to the SPV algorithm, which is 
based on most work done. This is exactly what they are designed to do. 

Contrast this with other lightweight wallets which either don't examine the 
block chain or implement the algorithm incorrectly, and I fail to see how this 
can be described as notoriously terrible.


 
  I understand that initially it was desirable that transactions be free…but 
surely even Satoshi understood this couldn’t be perpetually self-sustaining…and 
that the ability to bid for inclusion in blocks would eventually become a 
crucial component of the network. Or were fees just added for decoration?


Fees were added as a way to get money to miners in a fair and decentralised way.

Attaching fees directly to all transactions is certainly one way to use that, 
but it's not the only way. As noted above, our competitors prefer a combination 
of price-hiding and cross subsidisation. Both of these can be implemented with 
tx fees, but not necessarily by trying to artificially limit supply, which is 
economically nonsensical.


  We’re already more than six years into this. When were these mechanisms going 
to be developed and tested? After 10 years? 20? Perhaps after 1024 
years?(https://github.com/bitcoin/bips/blob/master/bip-0042.mediawiki)


Maybe when there is a need? I already discussed this topic of need here:

https://medium.com/@octskyward/hashing-7d04a887acc8


  Right. Turns out the ledger structure is terrible for constructing the kinds 
of proofs that are most important to validators - i.e. whether an output 
exists, what its script and amounts are, whether it’s been spent, etc…


Validators don't require proofs. That's why they are validators.

I think you're trying to say the block chain doesn't provide the kinds of 
proofs that are most important to lightweight wallets. But I would disagree. 
Even with UTXO commitments, there can still be double spends out there in the 
networks memory pools you are unaware of. Merely being presented with a 
correctly signed transaction doesn't tell you a whole lot . if you wait for 
a block, you get the same level of proof regardless of whether there are UTXO 
commitments or not. If you don't then you still have to have some trust in your 
peers that you are 

Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn'ttemporary

[Raystonn . via bitcoin-dev]

Gregory, can you please speak to the following points.  I would like a 
better understanding of your positions.


1) Do you believe that Bitcoin's future is as a high-value settlement 
network?


2) Do you believe we need an artificial limit to transaction rate, perhaps 
implemented as a maximum block size limit?  If so, why?


3) Transaction fees will fluctuate with global economic conditions and 
technology.  Those free-market fluctuations should equally affect any 
blockchain.  However, if transaction fees on the Bitcoin network are pushed 
artificially high, such as with an artificial limit to transaction rate only 
applicable to Bitcoin, this will create a condition where some other 
blockchains will have lower fees.  How do you plan to address the bleeding 
of value from Bitcoin to alternative lower-fee blockchains created by the 
artificially-high bitcoin transaction fees when users begin looking for the 
cheapest way to send value?  Modern economic study has shown that liquidity 
moves to the location of least friction.


4) If you believe it's not a problem to allow alternative blockchains to 
leech some of Bitcoin's value, then:

   a) How much value is it acceptable to lose?
   b) How do you think this will affect Bitcoin miners, whose large 
investments in hardware do not transfer to other blockchains?
   c) How do you think this will affect the investors and holders of 
bitcoin in general?



-Original Message- 
From: Gregory Maxwell via bitcoin-dev

Sent: Wednesday, July 29, 2015 1:09 PM
To: Owen
Cc: Bitcoin Dev
Subject: Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure 
isn'ttemporary


On Wed, Jul 29, 2015 at 7:56 PM, Owen via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:

On July 29, 2015 7:15:49 AM EDT, Mike Hearn via bitcoin-dev:

Consider this:  the highest Bitcoin tx fees can possibly go is perhaps
a
little higher than what our competition charges. Too much higher than
that,
and people will just say, you know what  I'll make a bank transfer.
It's cheaper and not much slower, sometimes no slower at all.


I respectfully disagree with this analysis. The implication is that 
bitcoin is merely one of a number of payment technologies. It's much more 
than that. It's sound money, censorship resistance, personal control over 
money, programmable money, and more. Without these attributes it's merely 
a really inefficient way to do payments.


Given these advantages, there is no reason to believe the marginal cost of 
a transaction can't far surpass that of a PayPal or bank transfer. I 
personally would pay several multiples of the competitors' fees to 
continue using bitcoin.


Sure, some marginal use cases will drop off with greater fees, but that's 
normal and expected. These will be use cases where the user doesn't care 
about bitcoin's advantages. We must be willing to let these use cases go 
anyway, because we unfortunately don't have room on chain for everything 
anyone might want to do.


Therefore, bitcoin tx fees can go much higher than the competition.

Remember how Satoshi referenced the banking crisis in his early work? The 
2008 banking crisis was about a lot of things, but high credit card and 
paypal fees wasnt one of them. There's more going on here than just 
payments. Any speculative economic analysis would do better to include 
this fact.


Precisely.  And as just a payment system Bitcoin is not an
especially great one: The design requirements for decenteralization
impose considerable costs.  To the extent that the technology in
Bitcoin is useful at all for building just another payment system
this technology in in the process of being agressively copied by
parties with deep fiat relationships (including in partnership with
centeral banks).  If the focus for Bitcoin's competative advantage
becomes exclusively better payments then it will almost certinatly
fail in the market-place against competing systems which avoid the
Bitcoin currency adoption related obsticles (but also gain none of
Bitcoin's important social/political promise).

Also, critically, if Bitcoin's security properties are manintained and
enhanced then Bitcoin can be used to build secure systems which _also_
accomidate those applications and we can have both. But if Bitcoin's
security properties are not strong then then advanced tools cannot be
built for it.  E.g. atomic swaps make trustless trades with external
systems possible; but they are especially sensitive to long
reorginizations by miners... so they can only be securely used where
those reorgs are infeasable.  So while I agree that we must be willing
to tolerate not catching every conceivable use case; most of the time
all that means is addressing them via a less direct but more focused
solution rather than ignoring them completely.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev 

Re: [bitcoin-dev] Răspuns: Personal opinion on the fee market from a worried local trader

[Raystonn . via bitcoin-dev]

 When a category of users would get priced out because of the fee market, they 
 would be free to use any altcoin they want.

I believe that pretty well sums up where we’re headed if transaction rate is 
artificially limited, whether that be by maximum block size limit or something 
else.  A fee market will necessarily include more than just Bitcoin.  The 
reality is it’s very easy to trade value across different blockchains, and thus 
a fee market will bleed value from Bitcoin and give it to alternative 
blockchains.  If Bitcoin’s blocks are at maximum capacity, people will exchange 
for something that allows them to transact with a lesser fee, then make the 
desired payment.  This adds value to the alternative blockchain and removes it 
from Bitcoin.

Anyone thinking the fee market can be restrained to Bitcoin alone is mistaken.



From: Vali Zero via bitcoin-dev 
Sent: Wednesday, July 29, 2015 7:09 AM
To: bitcoin-dev@lists.linuxfoundation.org 
Subject: [bitcoin-dev] Răspuns: Personal opinion on the fee market from a 
worried local trader

I am disappointed that you did not understand my point of view. Let me rephrase 
it for you,

People tipping, buying 0.99$ products and gamblers that need Bitcoin 
transactions *more* than the rest of the people will afford the fees that 
establish the equilibrium between demand and supply of Bitcoin transactions. 
The people are free to use they money for whatever they like, but you should 
understand that Bitcoin transactions are not free.

I was merely attempting to point out that spammers and gamblers would be the 
first ones that would go away. They would be free to spam or gamble, but they 
would have to pay for it.

When a category of users would get priced out because of the fee market, they 
would be free to use any altcoin they want.


Please understand that not everyone will leave. The more important players will 
remain, those that need it the most. The other players are free to use whatever 
altcoin they wish.


În Miercuri, 29 Iulie 2015 16:47:57, Angel Leon gubat...@gmail.com a scris:




the gamblers and perhaps people transacting very low amounts. The people that 
actually need Bitcoin would remain.

so people tipping, buying $0.99 products, and gamblers actually don't need 
Bitcoin.
Who are you to say what people need to use money for? 
This statement goes against the freedom of decentralization and financial 
freedom Bitcoin should be able to provide.

It's an open network and it will be used as most users see fit, and that 
requires a blocksize increase wether you like it or not, it's simple physics, 
other time wait times will become unbearable for those not willing to pay the 
high fees, if people leave, then it only mean bitcoins isn't useful, and if 
bitcoin isn't useful, it's worthless.




http://twitter.com/gubatron


On Wed, Jul 29, 2015 at 9:27 AM, Vali Zero via bitcoin-dev 
bitcoin-dev@lists.linuxfoundation.org wrote:

  Hello,

  I have been reading an argument saying that paying higher fees would scare 
Bitcoin users and they would stop using it, preferring bank transfers or other 
payment methods. This does not make sense for me. If some users leave, then 
demand for bitcoin transactions goes down and so do the fees. The others remain.

  Fee market means that an equilibrium is found between the demand for bitcoin 
transactions and the available supply (given by the block size). The fee is the 
price that finds this equilibrium.

  If a fee market starts to exist, the first ones to leave are the spammers, 
probably followed by the gamblers and perhaps people transacting very low 
amounts. The people that actually need Bitcoin would remain.

  Please allow this fee market to form...

  In the absence of a functioning fee market, I will refuse to run Bitcoin code 
that increases the block size and will do my best to tell everyone I know not 
to upgrade towards running such code. If Bitcoin succombs to the free stuff 
army, I will sell all the coins and leave. Nothing is for free.

  I apologize for any exagerations, but I just felt strongly towards expressing 
my opinion here. I'm only a local Bitcoin trader, computer engineer, with a 
reasonable understanding of free markets. And I'm running only one full node.

  Kind regards,
  Valentin



  ___
  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] Why Satoshi's temporary anti-spam measureisn't temporary

[Raystonn . via bitcoin-dev]

All of the properties you describe are also properties of many of the 
alternative blockchains that currently exist.  In this space, Bitcoin gives 
up these advantages.  Much like anywhere else where liquidity moves within a 
system, value will move to the network of least friction.  The reality right 
now is it's very easy to move value from Bitcoin to another blockchain with 
less friction.  Because of this, there will never be a high value settlement 
network created by an artificially imposed limit on transaction rate.  The 
value will simply bleed out of Bitcoin to alternative blockchains offering 
lower fees if this is attempted.  This is basic economics.


-Original Message- 
From: Owen via bitcoin-dev

Sent: Wednesday, July 29, 2015 12:56 PM
To: Bitcoin Dev
Subject: Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measureisn't 
temporary




On July 29, 2015 7:15:49 AM EDT, Mike Hearn via bitcoin-dev:

Consider this:  the highest Bitcoin tx fees can possibly go is perhaps
a
little higher than what our competition charges. Too much higher than
that,
and people will just say, you know what  I'll make a bank transfer.
It's cheaper and not much slower, sometimes no slower at all.


I respectfully disagree with this analysis. The implication is that bitcoin 
is merely one of a number of payment technologies. It's much more than that. 
It's sound money, censorship resistance, personal control over money, 
programmable money, and more. Without these attributes it's merely a really 
inefficient way to do payments.


Given these advantages, there is no reason to believe the marginal cost of a 
transaction can't far surpass that of a PayPal or bank transfer. I 
personally would pay several multiples of the competitors' fees to continue 
using bitcoin.


Sure, some marginal use cases will drop off with greater fees, but that's 
normal and expected. These will be use cases where the user doesn't care 
about bitcoin's advantages. We must be willing to let these use cases go 
anyway, because we unfortunately don't have room on chain for everything 
anyone might want to do.


Therefore, bitcoin tx fees can go much higher than the competition.

Remember how Satoshi referenced the banking crisis in his early work? The 
2008 banking crisis was about a lot of things, but high credit card and 
paypal fees wasnt one of them. There's more going on here than just 
payments. Any speculative economic analysis would do better to include this 
fact.



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


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

Re: [bitcoin-dev] Bitcoin Core and hard forks

[Raystonn via bitcoin-dev]

 If the developers fail to reflect user consensus, the network will let us know.
This is true with the caveat that there must be more than one option present for the network to show it's preference. If developers discourage anything that forks from the rules enforced by Bitcoin Core, they harm the network's ability to inform us of a failure to reflect user consensus.
On 22 Jul 2015 3:31 pm, Jeff Garzik via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote:I wouldnt go quite that far.  The reality is somewhere in the middle, as Bryan Cheng noted in this thread:Quoting BC, Upgrading to a version of Bitcoin Core that is incompatible with your ideals is in no way a forced choice, as you have stated in your email; forks, alternative clients, or staying on an older version are all valid choices. If the majority of the network chooses not to endorse a specific change, then the majority of the network will continue to operate just fine without it, and properly structured consensus rules will pull the minority along as well.The developers propose a new version, by publishing a new release.  The individual network nodes choose to accept or reject that.So I respectfully disagree with core devs dont control the network and core devs control the network both.There are checks-and-balances that make the system work.  Consensus is most strongly measured by user actions after software release.  If the developers fail to reflect user consensus, the network will let us know.On Wed, Jul 22, 2015 at 2:43 PM, Mike Hearn via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote:Hi Pieter,I think a core area of disagreement is this:Bitcoin Core is not running the Bitcoin economy, and its developers have no authority to set its rules. In fact Bitcoin Core is running the Bitcoin economy, and its developers do have the authority to set its rules. This is enforced by the reality of ~100% market share and limited github commit access.You may not like this situation, but it is what it is. By refusing to make a release with different rules, people who disagree are faced with only two options:1. Swallow it even if they hate it2. Fork the project and fork the block chain with it (XT)There are no alternatives. People who object to (2) are inherently suggesting (1) is the only acceptable path, which not surprisingly, makes a lot of people very angry.
___
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