Re: [bitcoin-dev] Bitcoin Cash's new difficulty algorithm

[Jacob Eliosoff via bitcoin-dev]

I'm no BCH fan, but I agree with Scott that changes to the DAA may be of
more than purely theoretical interest for BTC.  Anyway just for those
interested, below is an algo I've been playing with that adjusts difficulty
every block, based only on the previous block's time and difficulty.  I
tested it a bit and it seems to adapt to hashrate swings pretty well.

weight_n = 1 - e^-(blocktime_n / 1 hr)# 1 hr = exp moving avg window -
too short?
adj_n = (10 min / blocktime_n) - 1
difficulty_(n+1) = difficulty_n * (1 + weight_n * adj_n)

It could also be tweaked to make the *historical* avg block time ~exactly
10 minutes, ie, to target > 10 min if past blocks were < 10 min.  This
would, eg, make mapping future block numbers to calendar times much more
exact.


On Nov 3, 2017 7:24 AM, "Scott Roberts via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> The current DA is only sufficient if the coin has the highest
> hashpower. It's also just really slow.  If miners somehow stick with
> SegWit2x despite the higher rewards in defecting back to bitcoin, then
> bitcoin will have long block delays. High transaction fees will
> probably help them defect back to us. But if SegWit2x manages to be
> more comparable in price than BCH (despite the futures), hashpower
> could very well oscillate back and forth between the two coins,
> causing delays in both of them. The first one to hard fork to fix the
> difficulty problem will have a large advantage, as evidenced by what
> happens in alts.   In any event someday BTC may not be the biggest kid
> on the block and will need a difficulty algorithm that alts would find
> acceptable. Few alts use anything like BTC's because they are not able
> to survive the resulting long delays.   I am recommending BTC
> developers watch what happens as BCH goes live with a much better
> algorithm, in case BTC needs to hard fork for the same reason and
> needs a similar fix. Ignore the trolls.
>
> On Thu, Nov 2, 2017 at 7:39 PM, CryptAxe  wrote:
> > Is there an issue with the current difficulty adjustment algorithm? It's
> > worked very well as far as I can tell. Introducing a new one seems pretty
> > risky, what would the benefit be?
> >
> > On Nov 2, 2017 4:34 PM, "Scott Roberts via bitcoin-dev"
> >  wrote:
> >>
> >> Bitcoin cash will hard fork on Nov 13 to implement a new difficulty
> >> algorithm.  Bitcoin itself might need to hard fork to employ a similar
> >> algorithm. It's about as good as they come because it followed the
> >> "simplest is best" route. Their averaging window is probably
> >> significantly too long (N=144). It's:
> >>
> >> next_D = sum (past 144 D's) * T / sum(past 144 solvetimes)
> >>
> >> They correctly did not use max(timestamp) - min(timestamp) in the
> >> denominator like others do.
> >>
> >> They've written the code and they're about to use it live, so Bitcoin
> >> will have a clear, simple, and tested path if it suddenly needs to
> >> hard fork due to having 20x delays for the next 2000 blocks (taking it
> >> a year to get unstuck).
> >>
> >> Details on it and the decision process:
> >> https://www.bitcoinabc.org/november
> >>
> >> It uses a nice median of 3 for the beginning and end of the window to
> >> help alleviate bad timestamp problems. It's nice, helps a little, but
> >> will also slow its response by 1 block.  They also have 2x and 1/2
> >> limits on the adjustment per block, which is a lot more than they will
> >> ever need.
> >>
> >> I recommend bitcoin consider using it and making it N=50 instead of 144.
> >>
> >> I have seen that any attempts to modify the above with things like a
> >> low pass filter, starting the window at MTP, or preventing negative
> >> timestamps will only reduce its effectiveness. Bitcoin's +12 and -6
> >> limits on the timestamps are sufficient and well chosen, although
> >> something a bit smaller than the +12 might have been better.
> >>
> >> One of the contenders to the above is new and actually better, devised
> >> by Degnr8 and they call it D622 or wt-144.It's a little better than
> >> they realize. It's the only real improvement in difficulty algorithms
> >> since the rolling average.  It gives a linearly higher weight to the
> >> more recent timestamps. Otherwise it is the same. Others have probably
> >> come across it, but there is too much noise in difficulty algorithms
> >> to find the good ones.
> >>
> >> # Degnr8's D622 difficulty algorithm
> >> # T=TargetTime, S=Solvetime
> >> # modified by zawy
> >> for i = 1 to N  (from oldest to most recent block)
> >> t += T[i] / D[i] * i
> >> j += i
> >> next i
> >> next_D = j / t * T
> >>
> >> I believe any modification to the above strict mathematical weighted
> >> average will reduce it's effectiveness. It does not oscillate anymore
> >> than regular algos and rises faster and drops faster, when needed.
> >> ___
> >> bitcoin-dev mailing list
> >> bitcoin-dev@lists.linuxfoundation.org
> >> https://lists.li

Re: [bitcoin-dev] Proposal: allocate Github issue instead of wiki page to BIP discussion

[Aymeric Vitte via bitcoin-dev]

+10k

Indeed, as any project Github issues should be enabled for BIPs,
wondering too since some time why this is not the case, and then if an
issue is worth discussing here it can be redirected to the list


Le 03/11/2017 à 10:50, Sjors Provoost via bitcoin-dev a écrit :
> I often find myself wanting to leave relatively small comments on BIP's that 
> are IMO not worth bothering this list.
>
> By default each BIP has a wiki page for discussion, e.g. 
> https://github.com/bitcoin/bips/wiki/Comments:BIP-0150
> This is linked to from the Comments-URI field in the BIP.
>
> In order to leave a comment, you have to edit the wiki page. This process 
> seems a bit clunky.
>
> I think it would be better to use Github issues, with one Github issue for 
> each BIP.
>
> One concern might be that the ease of use of Github issues would move 
> discussion away from this list. The issue could be temporarily locked to 
> prevent that. The issue description could contain a standard text explaining 
> what should be discussed there and what would be more appropriate to post on 
> the mailinglist.
>
> Another concern might be confusing between PR's which create and update a 
> BIP, and the discussion issue.
>
> If people think this a good idea, would the next step be to propose a change 
> to the process here?
> https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki#BIP_comments
>
> Or would this be a new BIP?
>
> Sjors
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

-- 
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms

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

Re: [bitcoin-dev] Simplicity proposal - Jets?

[Adán Sánchez de Pedro Crespo via bitcoin-dev]

If I did understand it right, you don't need to publish the Simplicity
code for the "jetable" expression.

That's the whole point of MAST. Each Simplicity expression can be
identified by its MAST root (the Merkle root of all branches in its
Abstract Syntax Tree).

Imagine you want to write a Simplicity script that is roughly equivalent
to P2PKH. Regardless of directly writing such script or using a higher
level smart contract language, you won't likely write for yourself the
part in which you compute the hash of the public key. Instead, you are
expected to include some external library providing hash functions or at
least copy and paste such function into your code.

As everyone is expected to use the same, let's say, RIPEMD160
implementation, it doesn't matter how you included such function in your
program. The point is that once you build the MAST for your program,
such function will be completely replaced by its MAST root---which is
nothing but a hash.

This way, when the Simplicity interpreter (the BitMachine) bumps into
the hash, it can look for it in a predefined jets dictionary and find
the binary for a precompiled, formally proven implementation of a
function that is perfectly equivalent to the original Simplicity code.


On 03.11.2017 13:59, Hampus Sjöberg via bitcoin-dev wrote:
> Thank you for your answer, Russel.
> 
> When a code path takes advantage of a jet, does the Simplicity code
> still need to be publicly available/visible in the blockchain? I imagine
> that for big algorithms (say for example EDCA verification/SHA256
> hashing etc), it would take up a lot of space in the blockchain.
> Is there any way to mitigate this?
> 
> I guess in a softfork for a jet, the Simplicity code for a jet could be
> defined as "consensus", instead of needed to be provided within every
> script output.
> When the Simplicity interpretor encounters an expression that has a jet,
> it would run the C/Assembly code instead of interpreting the Simplicity
> code. By formal verification we would be sure they match.
> 
> Greetings
> Hampus
> 
> 2017-11-03 2:10 GMT+01:00 Russell O'Connor via bitcoin-dev
>  >:
> 
> Hi Jose,
> 
> Jets are briefly discussed in section 3.4 of
> https://blockstream.com/simplicity.pdf
> 
> 
> The idea is that we can recognize some set of popular Simplicity
> expressions, and when the Simplicity interpreter encounters one of
> these expressions it can skip over the Simplicity interpreter and
> instead directly evaluate the function using specialized C or
> assembly code.
> 
> For example, when the Simplicity interpreter encounters the
> Simplicity expression for ECDSA verification, it might directly call
> into libsecp rather than continuing the ECDSA verification using
> interpreted Simplicity.
> 
> HTH.
> 
> 
> On Nov 2, 2017 18:35, "JOSE FEMENIAS CAÑUELO via bitcoin-dev"
>  > wrote:
> 
> Hi,
> 
> I am trying to follow this Simplicity proposal and I am seeing
> all over references to ‘jets’, but I haven’t been able to find
> any good reference to it.
> Can anyone give me a brief explanation and or a link pointing to
> this feature?
> Thanks
> 
>> On 31 Oct 2017, at 22:01,
>> bitcoin-dev-requ...@lists.linuxfoundation.org
>>  wrote:
>>
>> The plan is that discounted jets will be explicitly labeled as
>> jets in the
>> commitment.  If you can provide a Merkle path from the root to
>> a node that
>> is an explicit jet, but that jet isn't among the finite number
>> of known
>> discounted jets,
> 
> 
> ___
> 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
> 

-- 
Adán Sánchez de Pedro Crespo
CTO, Stampery Inc.
San Francisco - Madrid
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Simplicity proposal - Jets?

[Mark Friedenbach via bitcoin-dev]

To reiterate, none of the current work focuses on Bitcoin integration, and many 
architectures are possible.

However the Jets would have to be specified and agreed to upfront for costing 
reasons, and so they would be known to all validators. There would be no reason 
to include anything more then the identifying hash in any contract using the 
jet.

> On Nov 3, 2017, at 5:59 AM, Hampus Sjöberg via bitcoin-dev 
>  wrote:
> 
> Thank you for your answer, Russel.
> 
> When a code path takes advantage of a jet, does the Simplicity code still 
> need to be publicly available/visible in the blockchain? I imagine that for 
> big algorithms (say for example EDCA verification/SHA256 hashing etc), it 
> would take up a lot of space in the blockchain.
> Is there any way to mitigate this?
> 
> I guess in a softfork for a jet, the Simplicity code for a jet could be 
> defined as "consensus", instead of needed to be provided within every script 
> output.
> When the Simplicity interpretor encounters an expression that has a jet, it 
> would run the C/Assembly code instead of interpreting the Simplicity code. By 
> formal verification we would be sure they match.
> 
> Greetings
> Hampus
> 
> 2017-11-03 2:10 GMT+01:00 Russell O'Connor via bitcoin-dev 
> :
>> Hi Jose,
>> 
>> Jets are briefly discussed in section 3.4 of 
>> https://blockstream.com/simplicity.pdf
>> 
>> The idea is that we can recognize some set of popular Simplicity 
>> expressions, and when the Simplicity interpreter encounters one of these 
>> expressions it can skip over the Simplicity interpreter and instead directly 
>> evaluate the function using specialized C or assembly code.
>> 
>> For example, when the Simplicity interpreter encounters the Simplicity 
>> expression for ECDSA verification, it might directly call into libsecp 
>> rather than continuing the ECDSA verification using interpreted Simplicity.
>> 
>> HTH.
>> 
>> 
>> On Nov 2, 2017 18:35, "JOSE FEMENIAS CAÑUELO via bitcoin-dev" 
>>  wrote:
>> Hi,
>> 
>> I am trying to follow this Simplicity proposal and I am seeing all over 
>> references to ‘jets’, but I haven’t been able to find any good reference to 
>> it.
>> Can anyone give me a brief explanation and or a link pointing to this 
>> feature?
>> Thanks
>> 
>>> On 31 Oct 2017, at 22:01, bitcoin-dev-requ...@lists.linuxfoundation.org 
>>> wrote:
>>> 
>>> The plan is that discounted jets will be explicitly labeled as jets in the
>>> commitment.  If you can provide a Merkle path from the root to a node that
>>> is an explicit jet, but that jet isn't among the finite number of known
>>> discounted jets,
>> 
>> 
>> ___
>> 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 mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Simplicity proposal - Jets?

[Hampus Sjöberg via bitcoin-dev]

Thank you for your answer, Russel.

When a code path takes advantage of a jet, does the Simplicity code still
need to be publicly available/visible in the blockchain? I imagine that for
big algorithms (say for example EDCA verification/SHA256 hashing etc), it
would take up a lot of space in the blockchain.
Is there any way to mitigate this?

I guess in a softfork for a jet, the Simplicity code for a jet could be
defined as "consensus", instead of needed to be provided within every
script output.
When the Simplicity interpretor encounters an expression that has a jet, it
would run the C/Assembly code instead of interpreting the Simplicity code.
By formal verification we would be sure they match.

Greetings
Hampus

2017-11-03 2:10 GMT+01:00 Russell O'Connor via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org>:

> Hi Jose,
>
> Jets are briefly discussed in section 3.4 of https://blockstream.com/
> simplicity.pdf
>
> The idea is that we can recognize some set of popular Simplicity
> expressions, and when the Simplicity interpreter encounters one of these
> expressions it can skip over the Simplicity interpreter and instead
> directly evaluate the function using specialized C or assembly code.
>
> For example, when the Simplicity interpreter encounters the Simplicity
> expression for ECDSA verification, it might directly call into libsecp
> rather than continuing the ECDSA verification using interpreted Simplicity.
>
> HTH.
>
>
> On Nov 2, 2017 18:35, "JOSE FEMENIAS CAÑUELO via bitcoin-dev" <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Hi,
>
> I am trying to follow this Simplicity proposal and I am seeing all over
> references to ‘jets’, but I haven’t been able to find any good reference to
> it.
> Can anyone give me a brief explanation and or a link pointing to this
> feature?
> Thanks
>
> On 31 Oct 2017, at 22:01, bitcoin-dev-requ...@lists.linuxfoundation.org
> wrote:
>
> The plan is that discounted jets will be explicitly labeled as jets in the
> commitment.  If you can provide a Merkle path from the root to a node that
> is an explicit jet, but that jet isn't among the finite number of known
> discounted jets,
>
>
>
> ___
> 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] Bitcoin Cash's new difficulty algorithm

[Scott Roberts via bitcoin-dev]

The current DA is only sufficient if the coin has the highest
hashpower. It's also just really slow.  If miners somehow stick with
SegWit2x despite the higher rewards in defecting back to bitcoin, then
bitcoin will have long block delays. High transaction fees will
probably help them defect back to us. But if SegWit2x manages to be
more comparable in price than BCH (despite the futures), hashpower
could very well oscillate back and forth between the two coins,
causing delays in both of them. The first one to hard fork to fix the
difficulty problem will have a large advantage, as evidenced by what
happens in alts.   In any event someday BTC may not be the biggest kid
on the block and will need a difficulty algorithm that alts would find
acceptable. Few alts use anything like BTC's because they are not able
to survive the resulting long delays.   I am recommending BTC
developers watch what happens as BCH goes live with a much better
algorithm, in case BTC needs to hard fork for the same reason and
needs a similar fix. Ignore the trolls.

On Thu, Nov 2, 2017 at 7:39 PM, CryptAxe  wrote:
> Is there an issue with the current difficulty adjustment algorithm? It's
> worked very well as far as I can tell. Introducing a new one seems pretty
> risky, what would the benefit be?
>
> On Nov 2, 2017 4:34 PM, "Scott Roberts via bitcoin-dev"
>  wrote:
>>
>> Bitcoin cash will hard fork on Nov 13 to implement a new difficulty
>> algorithm.  Bitcoin itself might need to hard fork to employ a similar
>> algorithm. It's about as good as they come because it followed the
>> "simplest is best" route. Their averaging window is probably
>> significantly too long (N=144). It's:
>>
>> next_D = sum (past 144 D's) * T / sum(past 144 solvetimes)
>>
>> They correctly did not use max(timestamp) - min(timestamp) in the
>> denominator like others do.
>>
>> They've written the code and they're about to use it live, so Bitcoin
>> will have a clear, simple, and tested path if it suddenly needs to
>> hard fork due to having 20x delays for the next 2000 blocks (taking it
>> a year to get unstuck).
>>
>> Details on it and the decision process:
>> https://www.bitcoinabc.org/november
>>
>> It uses a nice median of 3 for the beginning and end of the window to
>> help alleviate bad timestamp problems. It's nice, helps a little, but
>> will also slow its response by 1 block.  They also have 2x and 1/2
>> limits on the adjustment per block, which is a lot more than they will
>> ever need.
>>
>> I recommend bitcoin consider using it and making it N=50 instead of 144.
>>
>> I have seen that any attempts to modify the above with things like a
>> low pass filter, starting the window at MTP, or preventing negative
>> timestamps will only reduce its effectiveness. Bitcoin's +12 and -6
>> limits on the timestamps are sufficient and well chosen, although
>> something a bit smaller than the +12 might have been better.
>>
>> One of the contenders to the above is new and actually better, devised
>> by Degnr8 and they call it D622 or wt-144.It's a little better than
>> they realize. It's the only real improvement in difficulty algorithms
>> since the rolling average.  It gives a linearly higher weight to the
>> more recent timestamps. Otherwise it is the same. Others have probably
>> come across it, but there is too much noise in difficulty algorithms
>> to find the good ones.
>>
>> # Degnr8's D622 difficulty algorithm
>> # T=TargetTime, S=Solvetime
>> # modified by zawy
>> for i = 1 to N  (from oldest to most recent block)
>> t += T[i] / D[i] * i
>> j += i
>> next i
>> next_D = j / t * T
>>
>> I believe any modification to the above strict mathematical weighted
>> average will reduce it's effectiveness. It does not oscillate anymore
>> than regular algos and rises faster and drops faster, when needed.
>> ___
>> 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] Proposal: allocate Github issue instead of wiki page to BIP discussion

[Sjors Provoost via bitcoin-dev]

I often find myself wanting to leave relatively small comments on BIP's that 
are IMO not worth bothering this list.

By default each BIP has a wiki page for discussion, e.g. 
https://github.com/bitcoin/bips/wiki/Comments:BIP-0150
This is linked to from the Comments-URI field in the BIP.

In order to leave a comment, you have to edit the wiki page. This process seems 
a bit clunky.

I think it would be better to use Github issues, with one Github issue for each 
BIP.

One concern might be that the ease of use of Github issues would move 
discussion away from this list. The issue could be temporarily locked to 
prevent that. The issue description could contain a standard text explaining 
what should be discussed there and what would be more appropriate to post on 
the mailinglist.

Another concern might be confusing between PR's which create and update a BIP, 
and the discussion issue.

If people think this a good idea, would the next step be to propose a change to 
the process here?
https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki#BIP_comments

Or would this be a new BIP?

Sjors


signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Simplicity proposal - Jets?

[Adán Sánchez de Pedro Crespo via bitcoin-dev]

Oops. That makes much more sense than what I said. Thanks a lot for the
clarification.

On 03.11.2017 02:10, Russell O'Connor via bitcoin-dev wrote:
> Hi Jose,
> 
> Jets are briefly discussed in section 3.4 of
> https://blockstream.com/simplicity.pdf
> 
> The idea is that we can recognize some set of popular Simplicity
> expressions, and when the Simplicity interpreter encounters one of these
> expressions it can skip over the Simplicity interpreter and instead
> directly evaluate the function using specialized C or assembly code.
> 
> For example, when the Simplicity interpreter encounters the Simplicity
> expression for ECDSA verification, it might directly call into libsecp
> rather than continuing the ECDSA verification using interpreted Simplicity.
> 
> HTH.
> 
> 
> On Nov 2, 2017 18:35, "JOSE FEMENIAS CAÑUELO via bitcoin-dev"
>  > wrote:
> 
> Hi,
> 
> I am trying to follow this Simplicity proposal and I am seeing all
> over references to ‘jets’, but I haven’t been able to find any good
> reference to it.
> Can anyone give me a brief explanation and or a link pointing to
> this feature?
> Thanks
> 
>> On 31 Oct 2017, at 22:01,
>> bitcoin-dev-requ...@lists.linuxfoundation.org
>>  wrote:
>>
>> The plan is that discounted jets will be explicitly labeled as
>> jets in the
>> commitment.  If you can provide a Merkle path from the root to a
>> node that
>> is an explicit jet, but that jet isn't among the finite number of
>> known
>> discounted jets,
> 
> 
> ___
> 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
> 

-- 
Adán Sánchez de Pedro Crespo
CTO, Stampery Inc.
San Francisco - Madrid
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev