[bitcoin-dev] Alternative chain support for payment protocol

[bitcoin-dev] Alternative chain support for payment protocol

[Ross Nicoll]

BIP 70 currently lists two networks, main and test (inferred as 
testnet3) for payment protocol requests. This means that different 
testnets cannot be supported trivially, and the protocol cannot be used 
for alternative coins (or, lacks context to indicate which coin the 
request applies to, which is particularly dangerous in cases where coins 
share address prefixes).

I propose adding a new optional "genesis" field as a 16 byte sequence 
containing the SHA-256 hash of the genesis block of the network the 
request belongs to, uniquely identifying chains without any requirement 
for a central registry. For backwards compatibility, the "network" field 
would contain "main" for Bitcoin main net, "test" for Bitcoin testnet3, 
and "other" for other networks apart from those two.

I'd appreciate initial feedback on the idea, and if there's no major 
objections I'll raise this as a BIP.

Ross

Re: [bitcoin-dev] Alternative chain support for payment protocol

[Mike Hearn]

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

>
> I'd appreciate initial feedback on the idea, and if there's no major
> objections I'll raise this as a BIP.
>

The reason BIP 70 doesn't do this is the assumption that alt coins are ...
well .... alt. They can vary in arbitrary ways from Bitcoin, and so things
in BIP70 that work for Bitcoin may or may not work for other coins.

If your alt coin is close enough to BIP 70 that you can reuse it "as is"
then IMO we should just define a new network string for your alt. network =
"dogecoin-main" or whatever.

You could also use the genesis hash as the network name. That works too.
But it's less clear and would involve lookups to figure out what the
request is for, if you find such a request in the wild. I don't care much
either way.

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

Re: [bitcoin-dev] Alternative chain support for payment protocol

[Ross Nicoll]

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

I'm cautious of using human-meaningful identifiers, especially any that 
might require a central repository, due to name collisions. Examples 
that could be complicated include BitcoinDark, Litedoge, and other names 
that base on existing coins. I think the ability to differentiate 
between test networks is also useful.

Could certainly just use the genesis hash as network ID, that would 
work. Bit long, but suspect 64 bytes isn't the end of the world! I'll 
see if any more responses come in then raise a BIP for using genesis 
hash as an alternative to short names.

Ross

On 09/08/2015 15:29, Mike Hearn wrote:
>
>     I'd appreciate initial feedback on the idea, and if there's no
>     major objections I'll raise this as a BIP.
>
>
> The reason BIP 70 doesn't do this is the assumption that alt coins are 
> ... well .... alt. They can vary in arbitrary ways from Bitcoin, and 
> so things in BIP70 that work for Bitcoin may or may not work for other 
> coins.
>
> If your alt coin is close enough to BIP 70 that you can reuse it "as 
> is" then IMO we should just define a new network string for your alt. 
> network = "dogecoin-main" or whatever.
>
> You could also use the genesis hash as the network name. That works 
> too. But it's less clear and would involve lookups to figure out what 
> the request is for, if you find such a request in the wild. I don't 
> care much either way.


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

Re: [bitcoin-dev] Alternative chain support for payment protocol

[John L. Jegutanis]

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

Another possibility to support side|alt-chains is the bip44 coin type
registry.

A problem that hasn't been mentioned is that a coin can extend the protocol
in an incompatible way (different protocol buffer format) so just changing
the network field in the PaymentDetails message will not work. A better
approach is to add an optional coin type field to the PaymentRequest and
serialize the incompatible PaymentDetails to the serialized_payment_details
field.

To support a future testnet4 in PaymentDetails we only need to add a new
network string like "test4".
On Aug 9, 2015 18:23, "Ross Nicoll via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

I'm cautious of using human-meaningful identifiers, especially any that
might require a central repository, due to name collisions. Examples that
could be complicated include BitcoinDark, Litedoge, and other names that
base on existing coins. I think the ability to differentiate between test
networks is also useful.

Could certainly just use the genesis hash as network ID, that would work.
Bit long, but suspect 64 bytes isn't the end of the world! I'll see if any
more responses come in then raise a BIP for using genesis hash as an
alternative to short names.

Ross


On 09/08/2015 15:29, Mike Hearn wrote:

I'd appreciate initial feedback on the idea, and if there's no major
> objections I'll raise this as a BIP.
>

The reason BIP 70 doesn't do this is the assumption that alt coins are ...
well .... alt. They can vary in arbitrary ways from Bitcoin, and so things
in BIP70 that work for Bitcoin may or may not work for other coins.

If your alt coin is close enough to BIP 70 that you can reuse it "as is"
then IMO we should just define a new network string for your alt. network =
"dogecoin-main" or whatever.

You could also use the genesis hash as the network name. That works too.
But it's less clear and would involve lookups to figure out what the
request is for, if you find such a request in the wild. I don't care much
either way.



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

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

Re: [bitcoin-dev] Alternative chain support for payment protocol

[Jorge Timón]

Here's some related commits from #6382 :

https://github.com/jtimon/bitcoin/commit/1a4e8d8637ced45e8785ddb95b0fc20a5b8365d1
https://github.com/jtimon/bitcoin/commit/a6941e318a7028ce3d8919d50825762ca9c0c74c
https://github.com/jtimon/bitcoin/commit/1754928d3ceeb26b2491ad1384095058e456fa9b
https://github.com/jtimon/bitcoin/commit/d5fe6b62e3e983b35f9e8e61cfce16d7cd091699

And a related PR (closed for now, at least until #6235 is merged) :
https://github.com/bitcoin/bitcoin/pull/6229

I definitely add the chainID field, and support regtest in bip70 too
(code is more complex by not supporting it that it could be while
supporting it). And if we want to maintain the chain petname, I would
change "test" to "testnet3".

While "main" and "regtest" are always used for those chains, we
currently have 3 different strings for testnet3:

"testnet3": for the default data directory.
"testnet": for the GUI style, and strings showed to the user.
"test": for bip70

I really want to simplify this and I think the simplest way to do so
is by unifying everything to always use "testnet3", although that
would require modifying bip70.

> On 09/08/2015 15:29, Mike Hearn wrote:
> The reason BIP 70 doesn't do this is the assumption that alt coins are ...
> well .... alt. They can vary in arbitrary ways from Bitcoin, and so things
> in BIP70 that work for Bitcoin may or may not work for other coins.
>
> If your alt coin is close enough to BIP 70 that you can reuse it "as is"
> then IMO we should just define a new network string for your alt. network =
> "dogecoin-main" or whatever.

Altchains aren't just altcoins and sidechains: there's also testchains
like testnet3, regtest and sizetestN ( #6382 ). Since there's so many
possible instances for sizetest, testchains are already more numerous
than altcoins (not that this last thing matters much for anything).
Just forget about altcoins and sidechains: do it for the testchains
(that's the reason why bitcoin has chainparams and multi-chain support
in the first place).

We should make things easier to add new testchains, not harder.
It is sad to see that some times things are "the wrong way" because
doing them "the right way" could "simplify things to altcoins too
much".
Such a design criterion seems so ridiculous and sad to me...

> You could also use the genesis hash as the network name. That works too. But
> it's less clear and would involve lookups to figure out what the request is
> for, if you find such a request in the wild. I don't care much either way.

Those lookups can but just to a map in memory, like in
https://github.com/jtimon/bitcoin/commit/1a4e8d8637ced45e8785ddb95b0fc20a5b8365d1#diff-64cbe1ad5465e13bc59ee8bb6f3de2e7R20

Alternatively we can maintain the chain petname field, but those are
just "standard petnames", not unique and immutable ids like the
genesis hash.

Re: [bitcoin-dev] Alternative chain support for payment protocol

[Mike Hearn]

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

We're not modifying BIP 70, it's now immutable and can only be extended.

There's really not much point in having a dedicated chain ID for regtest
mode. You shouldn't be finding BIP70 requests for regtest outside of your
own developer machine, where the id doesn't matter.

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

Re: [bitcoin-dev] Alternative chain support for payment protocol

[Jorge Timón]

On Mon, Aug 10, 2015 at 2:53 PM, Mike Hearn <hearn@vinumeris.com> wrote:
> We're not modifying BIP 70, it's now immutable and can only be extended.

Well, yes, I guess it's modifying that in the extension BIP.

> There's really not much point in having a dedicated chain ID for regtest
> mode. You shouldn't be finding BIP70 requests for regtest outside of your
> own developer machine, where the id doesn't matter.

The point is not having exceptions and treating all supported chains
in the same way in the code.
Having a special case for regtest makes the code more complex, not simpler.

Re: [bitcoin-dev] Alternative chain support for payment protocol

[odinn]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I thought this would be a helpful visualization in the discussion:

http://mapofcoins.com/

Of note are the differences between alts which were derived from BTC
(Proof-of-work algorithm: SHA-256), vs. those which were developed in
a different fashion such as BCN (Proof-of-work algorithm: CryptoNight)
and its alts.

On 08/09/2015 11:42 AM, John L. Jegutanis via bitcoin-dev wrote:
> Another possibility to support side|alt-chains is the bip44 coin
> type registry.
> 
> A problem that hasn't been mentioned is that a coin can extend the 
> protocol in an incompatible way (different protocol buffer format)
> so just changing the network field in the PaymentDetails message
> will not work. A better approach is to add an optional coin type
> field to the PaymentRequest and serialize the incompatible
> PaymentDetails to the serialized_payment_details field.
> 
> To support a future testnet4 in PaymentDetails we only need to add
> a new network string like "test4".
> 
> On Aug 9, 2015 18:23, "Ross Nicoll via bitcoin-dev" 
> <bitcoin-dev@lists.linuxfoundation.org 
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
> 
> I'm cautious of using human-meaningful identifiers, especially any 
> that might require a central repository, due to name collisions. 
> Examples that could be complicated include BitcoinDark, Litedoge, 
> and other names that base on existing coins. I think the ability
> to differentiate between test networks is also useful.
> 
> Could certainly just use the genesis hash as network ID, that
> would work. Bit long, but suspect 64 bytes isn't the end of the
> world! I'll see if any more responses come in then raise a BIP for
> using genesis hash as an alternative to short names.
> 
> Ross
> 
> 
> On 09/08/2015 15:29, Mike Hearn wrote:
>> 
>> I'd appreciate initial feedback on the idea, and if there's no 
>> major objections I'll raise this as a BIP.
>> 
>> 
>> The reason BIP 70 doesn't do this is the assumption that alt
>> coins are ... well .... alt. They can vary in arbitrary ways
>> from Bitcoin, and so things in BIP70 that work for Bitcoin may or
>> may not work for other coins.
>> 
>> If your alt coin is close enough to BIP 70 that you can reuse it 
>> "as is" then IMO we should just define a new network string for 
>> your alt. network = "dogecoin-main" or whatever.
>> 
>> You could also use the genesis hash as the network name. That 
>> works too. But it's less clear and would involve lookups to
>> figure out what the request is for, if you find such a request in
>> the wild. I don't care much either way.
> 
> 
> _______________________________________________ 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
> 

- -- 
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVyMViAAoJEGxwq/inSG8ChpsIAKcNoOuzisnfhcOchoqCxQ9d
dRNr3LNnVYT64Gcw8O88vX8Drijq5vxU/qqNVx66wPU5+mn7iBltDfuckV5+9KNU
AyOM56CHC//xT8aXcw2jZgKXIPhW7fpjIrhn4Eg/Pra77DSBTTdqNuxQbII2WLB8
HFcahawnRElro6/OZFwjyyTrHE9oEes/u/EiUYB4P0hiZ0m3Yh0Xm1GrmVMLoxc0
HH30ZztHrl5/wzx4t4+qcOpXXvffjO+5n9hssyil8qUgI72HeBxz5C84P7VhYMXj
b2xm+LC2c0pFtjM/oqIMp6R7UgXa1MfQq8Kb5/uuIJ9JGFbwhebrN/61K7S5EiE=
=R32m
-----END PGP SIGNATURE-----

Re: [bitcoin-dev] Alternative chain support for payment protocol

[Mark Friedenbach]

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

A sha256 hash is 32 bytes, but otherwise I agree with this proposal.
Genesis block hash is the logical way to identify chains, moving forward.
On Aug 9, 2015 7:12 AM, "Ross Nicoll via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> BIP 70 currently lists two networks, main and test (inferred as testnet3)
> for payment protocol requests. This means that different testnets cannot be
> supported trivially, and the protocol cannot be used for alternative coins
> (or, lacks context to indicate which coin the request applies to, which is
> particularly dangerous in cases where coins share address prefixes).
>
> I propose adding a new optional "genesis" field as a 16 byte sequence
> containing the SHA-256 hash of the genesis block of the network the request
> belongs to, uniquely identifying chains without any requirement for a
> central registry. For backwards compatibility, the "network" field would
> contain "main" for Bitcoin main net, "test" for Bitcoin testnet3, and
> "other" for other networks apart from those two.
>
> I'd appreciate initial feedback on the idea, and if there's no major
> objections I'll raise this as a BIP.
>
> Ross
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

Re: [bitcoin-dev] Alternative chain support for payment protocol

[Luke Dashjr]

On Monday, August 10, 2015 6:32:10 PM Ross Nicoll wrote:
> BTW, did you mean to take this off-list?

No, accidental. I'll re-CC it on this email.

> On 10/08/2015 00:46, Luke Dashjr wrote:
> > On Sunday, August 09, 2015 2:12:24 PM Ross Nicoll via bitcoin-dev wrote:
> >> BIP 70 currently lists two networks, main and test (inferred as
> >> testnet3) for payment protocol requests. This means that different
> >> testnets cannot be supported trivially, and the protocol cannot be used
> >> for alternative coins (or, lacks context to indicate which coin the
> >> request applies to, which is particularly dangerous in cases where coins
> >> share address prefixes).
> > 
> > I don't see how address prefixes are relevant - the payment protocol
> > doesn't use addresses at all...
> 
> Good point, trying to hard to preempt questions.
> 
> >> I propose adding a new optional "genesis" field as a 16 byte sequence
> >> containing the SHA-256 hash of the genesis block of the network the
> >> request belongs to, uniquely identifying chains without any requirement
> >> for a central registry.
> > 
> > Genesis blocks are not necessarily unique. For example, Litecoin and
> > Feathercoin share the same one.
> 
> Had missed that, and there's no easy alternatives. BIP 44 chain IDs
> don't identify different testnets, and do not cover regtest at all.

Regtest isn't really a network at all, just a testing mode of Bitcoin Core...

> Most recent block hash could be used and also provides fork
> detection, but in doing so advertises if a merchant is on the wrong
> fork. Will think about it.

Is that a bad thing?

> > I'd appreciate initial feedback on the idea, and if there's no major
> > objections I'll raise this as a BIP.
>
> I don't see how this is related to improving Bitcoin...
> 
> Well, mostly I'm trying not to avoid the situation where any accidental
> mixing of files is dangerous (funds can easily be sent on the wrong
> blockchain), nor with multiple standards (which is where we are at the
> moment). It improves things in avoiding future problems, rather than in
> the immediate term.

Sorry, I meant to stress that BIPs are for *Bitcoin* improvements 
specifically. Things which only improve altcoins, while a perfectly fine thing 
to standardise, are outside the scope of what belongs in a BIP.

Perhaps, however, this could be made to kill 2 birds with one stone, by 
ensuring it addresses the need for payments made of bitcoins on a sidechain?
For this, a merchant who wants a sidechain payment would presumably be able to 
provide a script from the main chain already, but an extension allowing 
payment directly on the sidechain (at the customer's choice) avoids the need 
to round-trip it...

Luke

Re: [bitcoin-dev] Alternative chain support for payment protocol

[Ross Nicoll]

Trimmed some of the thread to clarity

On 10/08/2015 19:40, Luke Dashjr wrote:
>>>> I propose adding a new optional "genesis" field as a 16 byte sequence
>>>> containing the SHA-256 hash of the genesis block of the network the
>>>> request belongs to, uniquely identifying chains without any requirement
>>>> for a central registry.
>>> Genesis blocks are not necessarily unique. For example, Litecoin and
>>> Feathercoin share the same one.
>> Had missed that, and there's no easy alternatives. BIP 44 chain IDs
>> don't identify different testnets, and do not cover regtest at all.
> Regtest isn't really a network at all, just a testing mode of Bitcoin Core...
True, but as Jorge points out, it's generally better not to have special 
cases.

>> Most recent block hash could be used and also provides fork
>> detection, but in doing so advertises if a merchant is on the wrong
>> fork. Will think about it.
> Is that a bad thing?
It was something I was thinking about with the BIP 66 fork, that it 
could be used as a safety measure, but could also be used to find 
merchants & exchanges who are accepting coins on the wrong branch of a 
fork (and therefore are susceptible to double-spend attacks). For fork 
detection it's probably safer for the client to provide a recent block 
hash with the payment response.

I think genesis hash collisions are probably acceptable; or, the 
duplicate coins are so far rarely long-lived and it's therefore not a 
major concern at least. The server should reject any attempt to pay on 
the wrong chain, in hindsight, as it will try to relay on the network it 
expects and the transaction will be rejected.

>>> I'd appreciate initial feedback on the idea, and if there's no major
>>> objections I'll raise this as a BIP.
>> I don't see how this is related to improving Bitcoin...
>>
>> Well, mostly I'm trying not to avoid the situation where any accidental
>> mixing of files is dangerous (funds can easily be sent on the wrong
>> blockchain), nor with multiple standards (which is where we are at the
>> moment). It improves things in avoiding future problems, rather than in
>> the immediate term.
> Sorry, I meant to stress that BIPs are for *Bitcoin* improvements
> specifically. Things which only improve altcoins, while a perfectly fine thing
> to standardise, are outside the scope of what belongs in a BIP.
>
> Perhaps, however, this could be made to kill 2 birds with one stone, by
> ensuring it addresses the need for payments made of bitcoins on a sidechain?
> For this, a merchant who wants a sidechain payment would presumably be able to
> provide a script from the main chain already, but an extension allowing
> payment directly on the sidechain (at the customer's choice) avoids the need
> to round-trip it...

That could definitely be done, for example by making the genesis field 
"repeated", so it specifies all potential networks. The response would 
need to indicate which hash it used, but that could be chain tip (with 
height in a further field), and provide fork detection.

Ross

Re: [bitcoin-dev] Alternative chain support for payment protocol

[Jorge Timón]

On Mon, Aug 10, 2015 at 9:19 PM, Ross Nicoll via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> That could definitely be done, for example by making the genesis field
> "repeated", so it specifies all potential networks. The response would need
> to indicate which hash it used, but that could be chain tip (with height in
> a further field), and provide fork detection.

No, the chain ID needs to be unique, that's the whole point.

Re: [bitcoin-dev] Alternative chain support for payment protocol

[Jorge Timón]

On Mon, Aug 10, 2015 at 8:40 PM, Luke Dashjr via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>> > Genesis blocks are not necessarily unique. For example, Litecoin and
>> > Feathercoin share the same one.

That's a fatal design in Feathercoin, not a mistake all altchains have
done and certainly irrelevant to Bitcoin.

> Regtest isn't really a network at all, just a testing mode of Bitcoin Core...

Regtest is a testchain just like testnet2 and testnet3. Testchains are
the only reason why Bitcoin Core supports multiple chains using
CChainParams.

> Sorry, I meant to stress that BIPs are for *Bitcoin* improvements
> specifically. Things which only improve altcoins, while a perfectly fine thing
> to standardise, are outside the scope of what belongs in a BIP.
>
> Perhaps, however, this could be made to kill 2 birds with one stone, by
> ensuring it addresses the need for payments made of bitcoins on a sidechain?
> For this, a merchant who wants a sidechain payment would presumably be able to
> provide a script from the main chain already, but an extension allowing
> payment directly on the sidechain (at the customer's choice) avoids the need
> to round-trip it...

For the payment protocol testchains, sidechains and altcoins are all
quite similar.
But it is fine to just focus on testchains if sidechains and altcoins
are out of scope.