[bitcoin-dev] BIP70 is dead. What now?

[bitcoin-dev] BIP70 is dead. What now?

[Thomas Voegtlin]

I never liked BIP70. It was too complex, had too many features, and when
people discuss it, they do not even agree on what the main feature was.

Nevertheless, there is ONE feature of BIP70 that I find useful: the fact
that payment requests were signed. I am making this post to discuss this.

When I send bitcoins to an exchange, I would like to receive a signed
request. I want to have a proof that the exchange asked me to send coins
to that address, in case it has been hijacked by some intern working
there. If that feature was implemented by an exchange, it would guide my
decision to use that exchange over its competitors.

I do not think that a single exchange ever implemented that, but I guess
this is because BIP70 is a terrible standard. LN payment requests are
signed, do not require SSL, do not require interactivity, and therefore
exchanges use them. Can't we achieve the same for on-chain payments? Is
anyone working on that?

I would be more than happy to remove BIP70 support from Electrum, if
there was another standard for signed requests.

Thomas

-- 
Electrum Technologies GmbH / Paul-Lincke-Ufer 8d / 10999 Berlin / Germany
Sitz, Registergericht: Berlin, Amtsgericht Charlottenburg, HRB 164636
Geschäftsführer: Thomas Voegtlin

Re: [bitcoin-dev] BIP70 is dead. What now?

[Charles Hill]

Hi, Thomas,

I developed a URL signing scheme for use with LNURL as a method for 
authorizing payments on behalf of offline devices /applications. It's 
not specifically off-chain or on-chain related, but could be repurposed. 
The gist of the scheme is as follows:

Before any signing is done:

0) Generate an API key (ID/reference, secret, encoding) to be shared 
between a server and an offline device or application.

To generate a signature:

1) Generate a random nonce (unique per API key)

2) Build a query string with the `id`, `nonce`, `tag`, "Server 
parameters" (see [Subprotocols](#subprotocols) above), and any custom 
parameters. The `id` parameter should be equal to the API key's ID. 
Example: 
`id=b6cb8e81e3&nonce=d585674cf991dbbab42b&tag=withdrawRequest&minWithdrawable=5000&maxWithdrawable=7000&defaultDescription=example&custom1=CUSTOM1_PARAM_VALUE&custom2=CUSTOM2_PARAM_VALUE`. 
Note that both the keys and values for query parameters should be URL 
encoded. The following characters should be __unescaped__: `A-Z a-z 0-9 
- _ . ! ~ * ' ( )`. See 
[encodeURIComponent](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/encodeURIComponent#description) 
for more details.

3) Sort the query parameters by key (alphabetically). This is referred 
to as the "payload". Example: 
`custom1=CUSTOM1_PARAM_VALUE&custom2=CUSTOM2_PARAM_VALUE&defaultDescription=example&id=b6cb8e81e3&maxWithdrawable=7000&minWithdrawable=5000&nonce=d585674cf991dbbab42b&tag=withdrawRequest`

4) Sign the payload (the sorted query string) using the API key secret. 
Signatures are generated using HMAC-SHA256, where the API key secret is 
the key.

5) Append the signature to the payload as follows: 
`custom1=CUSTOM1_PARAM_VALUE&custom2=CUSTOM2_PARAM_VALUE&defaultDescription=example&id=b6cb8e81e3&maxWithdrawable=7000&minWithdrawable=5000&nonce=d585674cf991dbbab42b&tag=withdrawRequest&signature=HMAC_SHA256_SIGNATURE`.

You can find more details here:

https://github.com/chill117/lnurl-node#how-to-implement-url-signing-scheme


I would change a few things with this scheme to fit better with the 
use-case you describe. For example:

* Remove the "tag" and LNURL-specific parameters

* Instead of HMAC-SHA256 with a shared secret, it could use pub/priv key 
signing instead. The lnurl-auth subprotocol has an interesting approach 
to protecting user privacy while allowing verification of signatures. 
See for more details on that:

https://github.com/fiatjaf/lnurl-rfc/blob/master/lnurl-auth.md


- chill


On 2/19/21 10:14 AM, Thomas Voegtlin via bitcoin-dev wrote:
> I never liked BIP70. It was too complex, had too many features, and when
> people discuss it, they do not even agree on what the main feature was.
>
> Nevertheless, there is ONE feature of BIP70 that I find useful: the fact
> that payment requests were signed. I am making this post to discuss this.
>
> When I send bitcoins to an exchange, I would like to receive a signed
> request. I want to have a proof that the exchange asked me to send coins
> to that address, in case it has been hijacked by some intern working
> there. If that feature was implemented by an exchange, it would guide my
> decision to use that exchange over its competitors.
>
> I do not think that a single exchange ever implemented that, but I guess
> this is because BIP70 is a terrible standard. LN payment requests are
> signed, do not require SSL, do not require interactivity, and therefore
> exchanges use them. Can't we achieve the same for on-chain payments? Is
> anyone working on that?
>
> I would be more than happy to remove BIP70 support from Electrum, if
> there was another standard for signed requests.
>
> Thomas
>

Re: [bitcoin-dev] BIP70 is dead. What now?

[Andrew Kozlik]

[-- Attachment #1: Type: text/plain, Size: 5648 bytes --]

Hi Thomas,

I am working on an experimental implementation [1] of a new payment request
format in Trezor T. In some respects it's similar to BIP-70. The main
differences are:

1. There is no reliance on X.509, since that seems to have been the main
reason for BIP-70's downfall. The signature is mandatory, since for us the
main feature is protection against a man-in-the-middle attack. So in this
sense it's more similar to BOLT11.

2. It can be used to solve a similar problem with coin exchange. When you
are sending BTC to a trusted exchange service and expecting another
cryptocurrency in return, say LTC, you want to be sure that you not only
have the correct BTC address, but also that the exchange service has your
correct LTC address.

3. It uses an optional nonce for replay protection.

The two interesting parts in [1] are probably the `TxAckPaymentRequest`
protobuf message [2] and the signature verification [3]. The protobuf
message is only for communication between Trezor and the host software
running on the user's computer. It's not intended for interchange between
wallets. We haven't defined the interchange format yet. I intend to create
a SLIP documenting all this.

Andrew

[1] https://github.com/trezor/trezor-firmware/compare/andrewkozlik/payreq2
[2]
https://github.com/trezor/trezor-firmware/blob/andrewkozlik/payreq2/common/protob/messages-bitcoin.proto#L403-L427
[3]
https://github.com/trezor/trezor-firmware/blob/andrewkozlik/payreq2/core/src/apps/bitcoin/sign_tx/payment_request.py

On Fri, Feb 19, 2021 at 1:43 PM Charles Hill via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi, Thomas,
>
> I developed a URL signing scheme for use with LNURL as a method for
> authorizing payments on behalf of offline devices /applications. It's
> not specifically off-chain or on-chain related, but could be repurposed.
> The gist of the scheme is as follows:
>
> Before any signing is done:
>
> 0) Generate an API key (ID/reference, secret, encoding) to be shared
> between a server and an offline device or application.
>
> To generate a signature:
>
> 1) Generate a random nonce (unique per API key)
>
> 2) Build a query string with the `id`, `nonce`, `tag`, "Server
> parameters" (see [Subprotocols](#subprotocols) above), and any custom
> parameters. The `id` parameter should be equal to the API key's ID.
> Example:
> `id=b6cb8e81e3&nonce=d585674cf991dbbab42b&tag=withdrawRequest&minWithdrawable=5000&maxWithdrawable=7000&defaultDescription=example&custom1=CUSTOM1_PARAM_VALUE&custom2=CUSTOM2_PARAM_VALUE`.
>
> Note that both the keys and values for query parameters should be URL
> encoded. The following characters should be __unescaped__: `A-Z a-z 0-9
> - _ . ! ~ * ' ( )`. See
> [encodeURIComponent](
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/encodeURIComponent#description)
>
> for more details.
>
> 3) Sort the query parameters by key (alphabetically). This is referred
> to as the "payload". Example:
>
> `custom1=CUSTOM1_PARAM_VALUE&custom2=CUSTOM2_PARAM_VALUE&defaultDescription=example&id=b6cb8e81e3&maxWithdrawable=7000&minWithdrawable=5000&nonce=d585674cf991dbbab42b&tag=withdrawRequest`
>
> 4) Sign the payload (the sorted query string) using the API key secret.
> Signatures are generated using HMAC-SHA256, where the API key secret is
> the key.
>
> 5) Append the signature to the payload as follows:
>
> `custom1=CUSTOM1_PARAM_VALUE&custom2=CUSTOM2_PARAM_VALUE&defaultDescription=example&id=b6cb8e81e3&maxWithdrawable=7000&minWithdrawable=5000&nonce=d585674cf991dbbab42b&tag=withdrawRequest&signature=HMAC_SHA256_SIGNATURE`.
>
> You can find more details here:
>
> https://github.com/chill117/lnurl-node#how-to-implement-url-signing-scheme
>
>
> I would change a few things with this scheme to fit better with the
> use-case you describe. For example:
>
> * Remove the "tag" and LNURL-specific parameters
>
> * Instead of HMAC-SHA256 with a shared secret, it could use pub/priv key
> signing instead. The lnurl-auth subprotocol has an interesting approach
> to protecting user privacy while allowing verification of signatures.
> See for more details on that:
>
> https://github.com/fiatjaf/lnurl-rfc/blob/master/lnurl-auth.md
>
>
> - chill
>
>
> On 2/19/21 10:14 AM, Thomas Voegtlin via bitcoin-dev wrote:
> > I never liked BIP70. It was too complex, had too many features, and when
> > people discuss it, they do not even agree on what the main feature was.
> >
> > Nevertheless, there is ONE feature of BIP70 that I find useful: the fact
> > that payment requests were signed. I am making this post to discuss this.
> >
> > When I send bitcoins to an exchange, I would like to receive a signed
> > request. I want to have a proof that the exchange asked me to send coins
> > to that address, in case it has been hijacked by some intern working
> > there. If that feature was implemented by an exchange, it would guide my
> > decision to use that exchange over its competitors.
> >
> > I do not think that a single exchange ever implemented that, but I guess
> > this is because BIP70 is a terrible standard. LN payment requests are
> > signed, do not require SSL, do not require interactivity, and therefore
> > exchanges use them. Can't we achieve the same for on-chain payments? Is
> > anyone working on that?
> >
> > I would be more than happy to remove BIP70 support from Electrum, if
> > there was another standard for signed requests.
> >
> > Thomas
> >
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 7547 bytes --]

Re: [bitcoin-dev] BIP70 is dead. What now?

[Eoin McQuinn]

[-- Attachment #1: Type: text/plain, Size: 6155 bytes --]

What is a 'pull request'?

On Fri, Feb 19, 2021 at 1:49 PM Andrew Kozlik via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi Thomas,
>
> I am working on an experimental implementation [1] of a new payment
> request format in Trezor T. In some respects it's similar to BIP-70. The
> main differences are:
>
> 1. There is no reliance on X.509, since that seems to have been the main
> reason for BIP-70's downfall. The signature is mandatory, since for us the
> main feature is protection against a man-in-the-middle attack. So in this
> sense it's more similar to BOLT11.
>
> 2. It can be used to solve a similar problem with coin exchange. When you
> are sending BTC to a trusted exchange service and expecting another
> cryptocurrency in return, say LTC, you want to be sure that you not only
> have the correct BTC address, but also that the exchange service has your
> correct LTC address.
>
> 3. It uses an optional nonce for replay protection.
>
> The two interesting parts in [1] are probably the `TxAckPaymentRequest`
> protobuf message [2] and the signature verification [3]. The protobuf
> message is only for communication between Trezor and the host software
> running on the user's computer. It's not intended for interchange between
> wallets. We haven't defined the interchange format yet. I intend to create
> a SLIP documenting all this.
>
> Andrew
>
> [1] https://github.com/trezor/trezor-firmware/compare/andrewkozlik/payreq2
> [2]
> https://github.com/trezor/trezor-firmware/blob/andrewkozlik/payreq2/common/protob/messages-bitcoin.proto#L403-L427
> [3]
> https://github.com/trezor/trezor-firmware/blob/andrewkozlik/payreq2/core/src/apps/bitcoin/sign_tx/payment_request.py
>
> On Fri, Feb 19, 2021 at 1:43 PM Charles Hill via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Hi, Thomas,
>>
>> I developed a URL signing scheme for use with LNURL as a method for
>> authorizing payments on behalf of offline devices /applications. It's
>> not specifically off-chain or on-chain related, but could be repurposed.
>> The gist of the scheme is as follows:
>>
>> Before any signing is done:
>>
>> 0) Generate an API key (ID/reference, secret, encoding) to be shared
>> between a server and an offline device or application.
>>
>> To generate a signature:
>>
>> 1) Generate a random nonce (unique per API key)
>>
>> 2) Build a query string with the `id`, `nonce`, `tag`, "Server
>> parameters" (see [Subprotocols](#subprotocols) above), and any custom
>> parameters. The `id` parameter should be equal to the API key's ID.
>> Example:
>> `id=b6cb8e81e3&nonce=d585674cf991dbbab42b&tag=withdrawRequest&minWithdrawable=5000&maxWithdrawable=7000&defaultDescription=example&custom1=CUSTOM1_PARAM_VALUE&custom2=CUSTOM2_PARAM_VALUE`.
>>
>> Note that both the keys and values for query parameters should be URL
>> encoded. The following characters should be __unescaped__: `A-Z a-z 0-9
>> - _ . ! ~ * ' ( )`. See
>> [encodeURIComponent](
>> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/encodeURIComponent#description)
>>
>> for more details.
>>
>> 3) Sort the query parameters by key (alphabetically). This is referred
>> to as the "payload". Example:
>>
>> `custom1=CUSTOM1_PARAM_VALUE&custom2=CUSTOM2_PARAM_VALUE&defaultDescription=example&id=b6cb8e81e3&maxWithdrawable=7000&minWithdrawable=5000&nonce=d585674cf991dbbab42b&tag=withdrawRequest`
>>
>> 4) Sign the payload (the sorted query string) using the API key secret.
>> Signatures are generated using HMAC-SHA256, where the API key secret is
>> the key.
>>
>> 5) Append the signature to the payload as follows:
>>
>> `custom1=CUSTOM1_PARAM_VALUE&custom2=CUSTOM2_PARAM_VALUE&defaultDescription=example&id=b6cb8e81e3&maxWithdrawable=7000&minWithdrawable=5000&nonce=d585674cf991dbbab42b&tag=withdrawRequest&signature=HMAC_SHA256_SIGNATURE`.
>>
>> You can find more details here:
>>
>> https://github.com/chill117/lnurl-node#how-to-implement-url-signing-scheme
>>
>>
>> I would change a few things with this scheme to fit better with the
>> use-case you describe. For example:
>>
>> * Remove the "tag" and LNURL-specific parameters
>>
>> * Instead of HMAC-SHA256 with a shared secret, it could use pub/priv key
>> signing instead. The lnurl-auth subprotocol has an interesting approach
>> to protecting user privacy while allowing verification of signatures.
>> See for more details on that:
>>
>> https://github.com/fiatjaf/lnurl-rfc/blob/master/lnurl-auth.md
>>
>>
>> - chill
>>
>>
>> On 2/19/21 10:14 AM, Thomas Voegtlin via bitcoin-dev wrote:
>> > I never liked BIP70. It was too complex, had too many features, and when
>> > people discuss it, they do not even agree on what the main feature was.
>> >
>> > Nevertheless, there is ONE feature of BIP70 that I find useful: the fact
>> > that payment requests were signed. I am making this post to discuss
>> this.
>> >
>> > When I send bitcoins to an exchange, I would like to receive a signed
>> > request. I want to have a proof that the exchange asked me to send coins
>> > to that address, in case it has been hijacked by some intern working
>> > there. If that feature was implemented by an exchange, it would guide my
>> > decision to use that exchange over its competitors.
>> >
>> > I do not think that a single exchange ever implemented that, but I guess
>> > this is because BIP70 is a terrible standard. LN payment requests are
>> > signed, do not require SSL, do not require interactivity, and therefore
>> > exchanges use them. Can't we achieve the same for on-chain payments? Is
>> > anyone working on that?
>> >
>> > I would be more than happy to remove BIP70 support from Electrum, if
>> > there was another standard for signed requests.
>> >
>> > Thomas
>> >
>> _______________________________________________
>> 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
>


-- 
eoin.substack.com

[-- Attachment #2: Type: text/html, Size: 8608 bytes --]

Re: [bitcoin-dev] BIP70 is dead. What now?

[P G]

[-- Attachment #1: Type: text/plain, Size: 7368 bytes --]

Hi Thomas,

> Nevertheless, there is ONE feature of BIP70 that I find useful: the fact
that payment requests were signed.

In addition to signing the actual payment request, a nice addition to a new
payment protocol is an assurance that the receiving address can in fact
spend later on. Many users send "test" transactions to a wallet address
before sending their intended full amount. If the protocol includes a
response containing a signature using BIP322, there is better assurance for
the sender. Outside of the merchant context, a sender can use the protocol
to have peace of mind when sending between their own wallets. This should
likely be an optional parameter given cold storage setups cannot return a
signature quickly.

- Philip


On Sun, Feb 21, 2021 at 5:26 AM Eoin McQuinn via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> What is a 'pull request'?
>
> On Fri, Feb 19, 2021 at 1:49 PM Andrew Kozlik via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Hi Thomas,
>>
>> I am working on an experimental implementation [1] of a new payment
>> request format in Trezor T. In some respects it's similar to BIP-70. The
>> main differences are:
>>
>> 1. There is no reliance on X.509, since that seems to have been the main
>> reason for BIP-70's downfall. The signature is mandatory, since for us the
>> main feature is protection against a man-in-the-middle attack. So in this
>> sense it's more similar to BOLT11.
>>
>> 2. It can be used to solve a similar problem with coin exchange. When you
>> are sending BTC to a trusted exchange service and expecting another
>> cryptocurrency in return, say LTC, you want to be sure that you not only
>> have the correct BTC address, but also that the exchange service has your
>> correct LTC address.
>>
>> 3. It uses an optional nonce for replay protection.
>>
>> The two interesting parts in [1] are probably the `TxAckPaymentRequest`
>> protobuf message [2] and the signature verification [3]. The protobuf
>> message is only for communication between Trezor and the host software
>> running on the user's computer. It's not intended for interchange between
>> wallets. We haven't defined the interchange format yet. I intend to create
>> a SLIP documenting all this.
>>
>> Andrew
>>
>> [1]
>> https://github.com/trezor/trezor-firmware/compare/andrewkozlik/payreq2
>> [2]
>> https://github.com/trezor/trezor-firmware/blob/andrewkozlik/payreq2/common/protob/messages-bitcoin.proto#L403-L427
>> [3]
>> https://github.com/trezor/trezor-firmware/blob/andrewkozlik/payreq2/core/src/apps/bitcoin/sign_tx/payment_request.py
>>
>> On Fri, Feb 19, 2021 at 1:43 PM Charles Hill via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> Hi, Thomas,
>>>
>>> I developed a URL signing scheme for use with LNURL as a method for
>>> authorizing payments on behalf of offline devices /applications. It's
>>> not specifically off-chain or on-chain related, but could be repurposed.
>>> The gist of the scheme is as follows:
>>>
>>> Before any signing is done:
>>>
>>> 0) Generate an API key (ID/reference, secret, encoding) to be shared
>>> between a server and an offline device or application.
>>>
>>> To generate a signature:
>>>
>>> 1) Generate a random nonce (unique per API key)
>>>
>>> 2) Build a query string with the `id`, `nonce`, `tag`, "Server
>>> parameters" (see [Subprotocols](#subprotocols) above), and any custom
>>> parameters. The `id` parameter should be equal to the API key's ID.
>>> Example:
>>> `id=b6cb8e81e3&nonce=d585674cf991dbbab42b&tag=withdrawRequest&minWithdrawable=5000&maxWithdrawable=7000&defaultDescription=example&custom1=CUSTOM1_PARAM_VALUE&custom2=CUSTOM2_PARAM_VALUE`.
>>>
>>> Note that both the keys and values for query parameters should be URL
>>> encoded. The following characters should be __unescaped__: `A-Z a-z 0-9
>>> - _ . ! ~ * ' ( )`. See
>>> [encodeURIComponent](
>>> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/encodeURIComponent#description)
>>>
>>> for more details.
>>>
>>> 3) Sort the query parameters by key (alphabetically). This is referred
>>> to as the "payload". Example:
>>>
>>> `custom1=CUSTOM1_PARAM_VALUE&custom2=CUSTOM2_PARAM_VALUE&defaultDescription=example&id=b6cb8e81e3&maxWithdrawable=7000&minWithdrawable=5000&nonce=d585674cf991dbbab42b&tag=withdrawRequest`
>>>
>>> 4) Sign the payload (the sorted query string) using the API key secret.
>>> Signatures are generated using HMAC-SHA256, where the API key secret is
>>> the key.
>>>
>>> 5) Append the signature to the payload as follows:
>>>
>>> `custom1=CUSTOM1_PARAM_VALUE&custom2=CUSTOM2_PARAM_VALUE&defaultDescription=example&id=b6cb8e81e3&maxWithdrawable=7000&minWithdrawable=5000&nonce=d585674cf991dbbab42b&tag=withdrawRequest&signature=HMAC_SHA256_SIGNATURE`.
>>>
>>> You can find more details here:
>>>
>>>
>>> https://github.com/chill117/lnurl-node#how-to-implement-url-signing-scheme
>>>
>>>
>>> I would change a few things with this scheme to fit better with the
>>> use-case you describe. For example:
>>>
>>> * Remove the "tag" and LNURL-specific parameters
>>>
>>> * Instead of HMAC-SHA256 with a shared secret, it could use pub/priv key
>>> signing instead. The lnurl-auth subprotocol has an interesting approach
>>> to protecting user privacy while allowing verification of signatures.
>>> See for more details on that:
>>>
>>> https://github.com/fiatjaf/lnurl-rfc/blob/master/lnurl-auth.md
>>>
>>>
>>> - chill
>>>
>>>
>>> On 2/19/21 10:14 AM, Thomas Voegtlin via bitcoin-dev wrote:
>>> > I never liked BIP70. It was too complex, had too many features, and
>>> when
>>> > people discuss it, they do not even agree on what the main feature was.
>>> >
>>> > Nevertheless, there is ONE feature of BIP70 that I find useful: the
>>> fact
>>> > that payment requests were signed. I am making this post to discuss
>>> this.
>>> >
>>> > When I send bitcoins to an exchange, I would like to receive a signed
>>> > request. I want to have a proof that the exchange asked me to send
>>> coins
>>> > to that address, in case it has been hijacked by some intern working
>>> > there. If that feature was implemented by an exchange, it would guide
>>> my
>>> > decision to use that exchange over its competitors.
>>> >
>>> > I do not think that a single exchange ever implemented that, but I
>>> guess
>>> > this is because BIP70 is a terrible standard. LN payment requests are
>>> > signed, do not require SSL, do not require interactivity, and therefore
>>> > exchanges use them. Can't we achieve the same for on-chain payments? Is
>>> > anyone working on that?
>>> >
>>> > I would be more than happy to remove BIP70 support from Electrum, if
>>> > there was another standard for signed requests.
>>> >
>>> > Thomas
>>> >
>>> _______________________________________________
>>> 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
>>
>
>
> --
> eoin.substack.com
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 10273 bytes --]