<unnamed>

Public Key

npub13adulxazm6ydmpm6vuhk9xjudfa7h0k687j3xfzjrcpcv0v0uz2qz9uc29

Profile Code

nprofile1qqsg7k70nw3dazxasaaxwtmznfwx57lthmdrlfgny3fpuqux8k87p9qpzemhxue69uhhyetvv9ujuurjd9kkzmpwdejhgqg5waehxw309aex2mrp0yhxgctdw4eju6t0qyxhwumn8ghj7mn0wvhxcmmv9gars7

Publishing to

relay.primal.net

relay.damus.io

nos.lol

Last Notes

2023-06-07 23:00:09 UTC

- reply

📅 Original date posted:2021-10-17
📝 Original message:Well, it's the right word. If you're going to do a hardfork by changing
the timestamp definition, you're already doing a hardfork. At that
point, you've already crossed the Rubicon and might as well put in any
other necessary changes (e.g. to transaction locking), because it will
be as much of a hardfork either way.
The important bit here is "as long as it doesn't change anything now" -
this is indeed a hardfork, but it's a timestamp-activated hardfork that
triggers in 2106. Until that point, it has absolutely no bearing on
consensus rules (as opposed to the other proposals, which are at least a
soft-fork today).
I understand that there's some problems in getting consensus for forks,
but surely we can agree that everyone will update their Bitcoin at least
once in the next 85 years? (If they don't, they're doomed anyway.)
On 2021-10-17 15:46, Kate Salazar wrote:
> Hi yanmaani
>
...
>> This is a hardfork, yes, but it's a hardfork that kicks in way into
>> the
>> future. And because it's a hardfork, you might as well do anything,
>> as
>> long as it doesn't change anything now.
>
> "Anything" is quite a word.
> Ideally, hard fork requires upgrading every node that can be upgraded,
>
> or at least have the node operator's consent to lose the node (for
> every
> node that can't be upgraded).
>
...
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 23:00:09 UTC

- reply

📅 Original date posted:2021-10-17
📝 Original message:What, no. The `k` value is calculated implicitly, because there's only
one value of it that could ever be valid - if `k` is 1 too small, we're
70 years too far back, and then the block will violate median of last
11. If `k` is 1 too large, we're 70 years too far in the future, then
the block will violate 2 hour rule. Nothing is added to coinbase or
anywhere else.
It's possible that you'd need some extra logic for locktime, yes, but it
would only be a problem in very special cases. Worst-case, you'll have
to use block time locking in the years around the switch, or softfork in
64-bit locking.
But unless I'm missing something, 32-bit would be enough, you just
wouldn't be able to locktime something past the timestamp for the
switch. After the switchover, everything would be back to normal.
This is a hardfork, yes, but it's a hardfork that kicks in way into the
future. And because it's a hardfork, you might as well do anything, as
long as it doesn't change anything now.
On 2021-10-15 22:22, vjudeu at gazeta.pl wrote:
> Your solution seems to solve the problem of chain halting, but there
> are more issues. For example: if you have some time modulo 2^32, then
> you no longer know if timestamp zero is related to 1970 or 2106 or
> some higher year. Your "k" value representing in fact the most
> significant 32 bits of 64-bit timestamp has to be stored in all cases
> where time is used. If there is no "k", then zero should be used for
> backward compatibility. Skipping "k" could cause problems related to
> OP_CHECKLOCKTIMEVERIFY or nLockTime, because if some transaction was
> timestamped to 0xbadc0ded, then that transaction will be valid in
> 0x00000000badc0ded, invalid in 0x0000000100000000, and valid again in
> 0x00000001badc0ded, the same for timelocked outputs.
>
> So, I think your "k" value should be added to the coinbase
> transaction, then you can combine two 32-bit values, the lower bits
> from the block header and the higher bits from the coinbase
> transaction. Also, adding your "k" value transaction nLockTime field
> is needed (maybe in a similar way as transaction witness was added in
> Segwit), because in other case after reaching 0x0000000100000000 all
> off-chain transactions with timelocks around 0x00000000ffffffff will
> be additionally timelocked for the next N years. The same is needed
> for each OP_CHECKLOCKTIMEVERIFY, maybe pushing high 32 bits before the
> currently used value will solve that (and assuming zero if there is
> only some 32-bit value).

2023-06-07 23:00:07 UTC

- reply

📅 Original date posted:2021-10-15
📝 Original message:It's well-known. Nobody really cares, because it's so far off. Not
possible to do by softfork, no. It is possible to do by something that
becomes a hardfork in 80 years, though, which is probably good enough.
I proposed a solution, but nobody was really interested. Let's see if
anyone bites now.
---
Subject: Suggestion: Solve year 2106 problem by taking timestamps mod
2^32
To Bitcoin Protocol Discussion
Date 2020-09-19 12:36
Message Body
Currently, Bitcoin's timestamp rules are as follows:
1. The block timestamp may not be lower than the median of the last 11
blocks'
2. The block timestamp may not be greater than the current time plus two
hours
3. The block timestamp may not be greater than 2^32 (Sun, 07 Feb 2106
06:28:16 +0000)
Thus, Bitcoin will "die" on or about 2106-02-07, when there is no
timestamp below 2^32 that exceeds the median of the last 11 blocks.
If the rules were changed to the following, this problem would be
solved:
1. The block timestamp plus k*2^32 may not be lower than the median of
the last 11 blocks'
2. The block timestamp plus k*2^32 may not be greater than the current
time plus two hours
3. k is an integer, whose value must be the same for the calculations of
Rule 1 and Rule 2
This would cause a hardfork in the year 2106, which is approximately
85.5 years from now, by which time 95% of nodes would hopefully have
updated.
Another proposed solution is 64-bit timestamps. They would break
compatibility with other software that has specific expectations of
header fields, like ASICs' firmware. They would also cause a hardfork
before the date of timestamp overflow. I thus believe them to be a less
appropriate solution.
What do you think of this idea? Is it worth a BIP?
On 2021-10-13 19:16, vjudeu via bitcoin-dev wrote:
> It seems that Bitcoin Core will stop working in 2038 because of
> assertion checking if the current time is non-negative. Also, the
> whole chain will halt after reaching median time 0xffffffff in 2106.
> More information: https://bitcointalk.org/index.php?topic=5365359.0
>
> I wonder if that kind of issues are possible to fix in a soft-fork
> way.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 22:54:18 UTC

- reply

📅 Original date posted:2021-06-24
📝 Original message:No, 51% of the *coin holders* can't do diddly squat. 51% of miners can,
but in PoW, that's a different set to the coin holders.
The basic problem with PoS, anyway, is that it's not actually a
consensus system ("weak subjectivity"). Either you allow long reorgs,
and then you open the door to long-range attacks, or you don't, and then
you're not guaranteed that all nodes agree on the state of the chain,
which was the purpose of the system to begin with.
To put it more plainly: for PoS to work, you need a consensus on which
block was seen first. But if you had that, you could presumably apply
that method to determine which *transaction* was seen first, in which
case you could do away with the blockchain entirely. (Real-world
implementations of PoS, such that they are, do away with this
requirement, scrapping the global consensus on ordering in favor of
having each node decide for itself which block came first.)
In other words, even if you solved all the incentive problems, the fact
remains that PoS is not suitable for use as a consensus system, because
it is constitutionally incapable of producing a consensus.
On 2021-06-24 00:14, Billy Tetrud via bitcoin-dev wrote:
>> This is not true in a Proof of Work system and this difference
> absolutely should not be trivialized.
>
> That is in fact true of Proof of Work as well. If a colluding
> coalition of miners with more than 50% of the hashrate want to censor
> transactions, they absolutely can do that by orphaning blocks that
> contain transactions they want to censor. This is not different in
> proof of stake.
>
> On Wed, Jun 23, 2021 at 11:14 AM Keagan McClelland
> <keagan.mcclelland at gmail.com> wrote:
>
>>> Premise: There is a healthy exchange market for PoS Coin X with
>> tens of thousands of participants bidding to buy and sell the coin
>> for other currencies on the market.
>>
>> The difference here though is that Proof of Stake allows the quorum
>> of coin holders to block the exchange of said coins if they are
>> going to a particular destination. Nothing requires these staking
>> nodes to include particular transactions into a block. With that in
>> mind, it isn't just that you require the permission of the person
>> who sold you the coins, which I can agree is a less dangerous form
>> of permission, but you must also require the permission of at least
>> 51% of the coin holders to even receive those coins in the first
>> place. This is not true in a Proof of Work system and this
>> difference absolutely should not be trivialized.
>>
>> Keagan
>>
>> On Wed, Jun 23, 2021 at 2:30 AM Billy Tetrud via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> Barrier to entry in PoS is being given permission by the previous
>> owner of a token
>>
>> The idea that proof of stake is not permissionless is completely
>> invalid. It pains me to see such an argument here. Perhaps we can
>> come to an agreement by being more specific. I'd like to propose the
>> following:
>>
>> Premise: There is a healthy exchange market for PoS Coin X with tens
>> of thousands of participants bidding to buy and sell the coin for
>> other currencies on the market.
>>
>> If the premise above is true, then there is no significant
>> permission needed to enter the market for minting blocks for PoS
>> Coin X. If you make a bid on someone's coins and they don't like you
>> and refuse, you can move on to any one of the other tens of
>> thousands of people in that marketplace. Would you agree, Cloud
>> Strife, that this situation couldn't be considered "permissioned"?
>>
>> If not, consider that participation in *any* decentralized system
>> requires the permission of at least one user in that system. If
>> there are thousands of bitcoin public nodes, you require the
>> permission of at least one of them to participate in bitcoin. No one
>> considers bitcoin "permissioned" because of this. Do you agree?
>>
>> On Thu, Jun 17, 2021 at 1:15 PM Cloud Strife via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> Barrier to entry in PoW is matter for hardware and energy is
>> permissionless and exist all over the universe, permissionless cost
>> which exists for everyone no matter who because it's unforgeable.
>>
>> Barrier to entry in PoS is being given permission by the previous
>> owner of a token for you to have it via transfer or sale, both
>> choices they never have to make since there are no continuous costs
>> with producing blocks forcing it. A permission is an infinitely high
>> barrier to entry if the previous owner, like the premining party,
>> refuses to give up the token they control.
>>
>> You're skipping the part where you depend on a permission of a
>> central party in control of the authority token before you can
>> produce blocks on your rasberry Pi.
>>
>> Proof of stake is not in any possible way relevant to permissionless
>> protocols, and thus not possibly relevant to decentralized protocols
>> where control must be distributed to independent (i.e.
>> permissionless) parties.
>>
>> There's nothing of relevance to discuss and this has been figured
>> out long long ago.
>>
>>
> https://github.com/libbitcoin/libbitcoin-system/wiki/Proof-of-Stake-Fallacy
>>
>>
> https://medium.com/@factchecker9000/nothing-is-worse-than-proof-of-stake-e70b12b988ca
>>
>> On Tue, Jun 15, 2021 at 7:13 AM James MacWhyte via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> @Lloyd wrote:
>>
>> Of course in reality no one wants to keep their coin holding keys
>> online so in Alogorand you can authorize a set of "participation
>> keys"[1] that will be used to create blocks on your coin holding
>> key's behalf.
>> Hopefully you've spotted the problem.
>> You can send your participation keys to any malicious party with a
>> nice website (see random example [2]) offering you a good return.
>> Damn it's still Proof-of-SquareSpace!
>>
>> I believe we are talking about a comparison to PoW, correct? If you
>> want to mine PoW, you need to buy expensive hardware and configure
>> it to work, and wait a long time to get any return by solo mining.
>> Or you can join a mining pool, which might use your hashing power
>> for nefarious purposes. Or you might skip the hardware all together
>> and fall for some "cloud mining" scheme with a pretty website and a
>> high rate of advertised return. So as you can see,
>> Proof-of-SquareSpace exists in PoW as well!
>>
>> The PoS equivalent of buying mining hardware is setting up your own
>> validator and not outsourcing that to anyone else. So both PoW and
>> PoS have the professional/expert way of participating, and the
>> fraud-prone, amateur way of participating. The only difference is,
>> with PoS the professional/expert way is accessible to anyone with a
>> raspberry Pi and a web connection, which is a much lower barrier to
>> entry than PoW. _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 18:29:55 UTC

- reply

📅 Original date posted:2021-03-03
📝 Original message:On 2021-03-03 14:39, Chris Belcher via bitcoin-dev wrote:
> Enter flag day activation. With a flag day there can be no
> brinksmanship. A social media blitz cant do anything except have its
> own
> followers fork away. Crucially, miner signalling cant be used to change
> the activation date for nodes that didn't choose to and just passively
> follow signalling. Changing the activation date requires all those
> users
> to actually run different node software.
Is that supposed to be a good thing? "We should do X because it'll work"
doesn't prove X is actually good. These things can be evil, but they can
also be legitimate opposition to a change. Taking away the power of a
"social media blitz" is not guaranteed to be a good thing!
> What if one day the Core developer team uses the flag
> day method to do something bad? The bitcoin user
> community who wants to resist this can create their own
> counter-soft-fork full node. This forces a chain
> split. The real bitcoin which most people follow will be
> the chain without censorship.
[edited for brevity]
That will only work for really egregious changes. In practice, most
people will trust Core on all other (non-egregious) decisions, because
of the inertia inherent in disobeying them.
What you suggest may be an efficient way to ram taproot through, but is
it inherently good? Nothing is free. This seems like de-facto forcing
people to go along with you, because you're convinced you're right. In
this case, you are, but you'd be convinced you'd be right even if you
weren't so.
You're right in suggesting that it will work, but the reason why it will
work is because nobody wants to disobey Core. It seems immoral to
exploit this fact.
At least you shouldn't hard-code it and require dissenters to fork away.
I exhort you to consider making all this controversial stuff settings
that can be changed by RPC command or command-line flag; set the default
value sure, but requiring a fork to change it is, in my opinion,
oppressive.
(Also consider some compromise, such as ">95% miner support before flag
day or >33% on flag day")
Best wishes
Yanmaani

2023-06-07 18:29:43 UTC

- reply

📅 Original date posted:2021-03-03
📝 Original message:No, it's not the same. This approach is not guaranteed to activate. On
flag day, it'd check for (say) 20% miner support, and activate if so. If
>80% of miners oppose, it'd fail. LOT=true (and declining percentage) will activate unconditionally.
Also, the day before lock-in, this would still have 95% as the limit,
not a linear interpolation between 95% and the lock-in limit.
This checks: if miner support > 95% support it (ever) or miner support >
X% (on flag day), activate
DP checks: if miner support > lerp(95%, 0%) (ever), activate
LOT=true checks: on flag day, activate unconditionally
(Erik: I forgot to hit reply all on my last e-mail, that's why you're
seeing this twice)
On 2021-03-02 06:11, Erik Aronesty wrote:
> This is the declining percentage of signaling activation.
>
> It has all the benefits of both.
>
> Eventually it becomes a LOT=true, so any argument for LOT=true holds
>
> And all of the arguments for LOT=false are satisfied by the cool down
> period.
>
> On Mon, Mar 1, 2021, 12:05 PM yanmaani--- via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> How about a compromise?
>>
>> With LOT=false, taproot will be activated if at least 95% of the
>> miners
>> vote yes.
>> With LOT=true, taproot will be activated if at least 0% of the
>> miners
>> vote yes.
>> ...with LOT=maybe, taproot will be activated if at least ~some% of
>> the
>> miners vote yes?
>>
>> If you want the 'emergency cancel' feature without binding yourself
>> to
>> it, couldn't you have some middle-of-the-road solution? "Taproot
>> will be
>> enabled if miner support ever goes above 95%, or on flag day if
>> miner
>> support is >20% then". That would prevent obstreperous miners from
>> doing
>> too much damage, while still hopefully making it possible to bail
>> out of
>> a disaster.
>>
>> On 2021-03-01 15:06, Anthony Towns via bitcoin-dev wrote:
>>> On Sun, Feb 28, 2021 at 07:33:30PM +0000, Luke Dashjr via
>> bitcoin-dev
>>> wrote:
>>>> As we saw in 2017 with BIP 9, coordinating activation by miner
>> signal
>>>> alone,
>>>> despite its potential benefits, also leaves open the door to a
>> miner
>>>> veto.
>>>
>>> To the contrary, we saw in 2017 that miners could *not*
>> successfully
>>> veto a BIP 9 activation. It was certainly more effort and risk
>> than was
>>> desirable to override the attempted veto, but the attempt at
>> vetoing
>>> nevertheless failed.
>>>
>>>> It wouldn't be much different than adding back the inflation bug
>>>> (CVE-2018-17144) and trusting miners not to exploit it.
>>>
>>> That is ridiculous FUD.
>>>
>>>> With LOT=False in the picture, however, things can get messy:
>>>
>>> LOT=false is always in the picture if we are talking about a
>> soft-fork:
>>> the defining feature of a soft-fork is that old node software
>> continues
>>> to work, and old node software will be entirely indifferent to
>> whether
>>> activation is signalled or not.
>>>
>>>> some users will
>>>> enforce Taproot(eg) (those running LOT=True), while others will
>> not
>>>> (those
>>>> with LOT=False)
>>>
>>> If you are following bip8 with lockinontimeout=false, you will
>> enforce
>>> taproot rules if activation occurs, you will simply not reject
>> blocks
>>> if
>>> activation does not occur.
>>>
>>>> Users with LOT=True will still get all the safety thereof,
>>>> but those with LOT=False will (in the event of miners deciding to
>>
>>>> produce a
>>>> chain split) face an unreliable chain, being replaced by the
>> LOT=True
>>>> chain
>>>> every time it overtakes the LOT=False chain in work.
>>>
>>> This assumes anyone mining the chain where taproot does not
>> activate is
>>> not able to avoid a reorg, despite having majority hashpower (as
>>> implied
>>> by the lot=true chain having to overtake them repeatedly). That's
>>> absurd;
>>> avoiding a reorg is trivially achieved via running
>> "invalidateblock",
>>> or
>>> via pool software examining block headers, or via a patch along
>> the
>>> lines
>>> of MUST_SIGNAL enforcement, but doing the opposite. For
>> concreteness,
>>> here's a sketch of such a patch:
>>>
>>>
>>
> https://github.com/ajtowns/bitcoin/commit/f195688bd1eff3780f200e7a049e23b30ca4fe2f
>>>
>>>> For 2 weeks, users with LOT=False would not have a usable
>> network.
>>>
>>> That's also ridiculous FUD.
>>>
>>> If it were true, it would mean the activation mechanism was not
>>> acceptable, as non-upgraded nodes would also not have a usable
>> network
>>> for the same reason.
>>>
>>> Fortunately, it's not true.
>>>
>>> More generally, if miners are willing to lose significant amounts
>> of
>>> money mining orphan blocks, they can do that at any time. If
>> they're
>>> not inclined to do so, it's incredibly straightforward for them to
>>
>>> avoid
>>> doing so, whatever a minority of other miners might do.
>>>
>>>> The overall risk is maximally reduced by LOT=True being the only
>>>> deployed
>>>> parameter, and any introduction of LOT=False only increases risk
>>>> probability
>>>> and severity.
>>>
>>> LOT=false is the default behaviour of everything single piece of
>> node
>>> software out there. That behaviour doesn't need to be introduced,
>> it's
>>> already universal.
>>>
>>> Cheers,
>>> aj
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 18:29:42 UTC

- reply

📅 Original date posted:2021-03-01
📝 Original message:How about a compromise?
With LOT=false, taproot will be activated if at least 95% of the miners
vote yes.
With LOT=true, taproot will be activated if at least 0% of the miners
vote yes.
...with LOT=maybe, taproot will be activated if at least ~some% of the
miners vote yes?
If you want the 'emergency cancel' feature without binding yourself to
it, couldn't you have some middle-of-the-road solution? "Taproot will be
enabled if miner support ever goes above 95%, or on flag day if miner
support is >20% then". That would prevent obstreperous miners from doing
too much damage, while still hopefully making it possible to bail out of
a disaster.
On 2021-03-01 15:06, Anthony Towns via bitcoin-dev wrote:
> On Sun, Feb 28, 2021 at 07:33:30PM +0000, Luke Dashjr via bitcoin-dev
> wrote:
>> As we saw in 2017 with BIP 9, coordinating activation by miner signal
>> alone,
>> despite its potential benefits, also leaves open the door to a miner
>> veto.
>
> To the contrary, we saw in 2017 that miners could *not* successfully
> veto a BIP 9 activation. It was certainly more effort and risk than was
> desirable to override the attempted veto, but the attempt at vetoing
> nevertheless failed.
>
>> It wouldn't be much different than adding back the inflation bug
>> (CVE-2018-17144) and trusting miners not to exploit it.
>
> That is ridiculous FUD.
>
>> With LOT=False in the picture, however, things can get messy:
>
> LOT=false is always in the picture if we are talking about a soft-fork:
> the defining feature of a soft-fork is that old node software continues
> to work, and old node software will be entirely indifferent to whether
> activation is signalled or not.
>
>> some users will
>> enforce Taproot(eg) (those running LOT=True), while others will not
>> (those
>> with LOT=False)
>
> If you are following bip8 with lockinontimeout=false, you will enforce
> taproot rules if activation occurs, you will simply not reject blocks
> if
> activation does not occur.
>
>> Users with LOT=True will still get all the safety thereof,
>> but those with LOT=False will (in the event of miners deciding to
>> produce a
>> chain split) face an unreliable chain, being replaced by the LOT=True
>> chain
>> every time it overtakes the LOT=False chain in work.
>
> This assumes anyone mining the chain where taproot does not activate is
> not able to avoid a reorg, despite having majority hashpower (as
> implied
> by the lot=true chain having to overtake them repeatedly). That's
> absurd;
> avoiding a reorg is trivially achieved via running "invalidateblock",
> or
> via pool software examining block headers, or via a patch along the
> lines
> of MUST_SIGNAL enforcement, but doing the opposite. For concreteness,
> here's a sketch of such a patch:
>
> https://github.com/ajtowns/bitcoin/commit/f195688bd1eff3780f200e7a049e23b30ca4fe2f
>
>> For 2 weeks, users with LOT=False would not have a usable network.
>
> That's also ridiculous FUD.
>
> If it were true, it would mean the activation mechanism was not
> acceptable, as non-upgraded nodes would also not have a usable network
> for the same reason.
>
> Fortunately, it's not true.
>
> More generally, if miners are willing to lose significant amounts of
> money mining orphan blocks, they can do that at any time. If they're
> not inclined to do so, it's incredibly straightforward for them to
> avoid
> doing so, whatever a minority of other miners might do.
>
>> The overall risk is maximally reduced by LOT=True being the only
>> deployed
>> parameter, and any introduction of LOT=False only increases risk
>> probability
>> and severity.
>
> LOT=false is the default behaviour of everything single piece of node
> software out there. That behaviour doesn't need to be introduced, it's
> already universal.
>
> Cheers,
> aj
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev