Re: [Bitcoin-development] Missing fRelayTxes in version message
It's a problem if you work with iterators to deserialize the byte stream. Even failing that, it's just sloppy programming. What happens in the future when new fields are added to the version message? It's not a big deal to say that this protocol version has X number of fields, that (higher) protocol version message has X + N number of fields. Deterministic number of fields per protocol version is sensical and how Bitcoin has been for a long time. And yes, it was a problem for me that caused a lot of confusion why this byte didn't exist in many version messages despite the standard saying it should and the code in bitcoind indicating it should. Nowhere was this written. It doesn't help other implementations to have an unclear behaviour that depends on some magic from one implementation. From: Mike Hearn m...@plan99.net To: Turkey Breast turkeybre...@yahoo.com Cc: bitcoin-development@lists.sourceforge.net bitcoin-development@lists.sourceforge.net Sent: Wednesday, June 19, 2013 11:39 AM Subject: Re: [Bitcoin-development] Missing fRelayTxes in version message It has to be optional because old clients don't send it, obviously. Why is this even an issue? There's no problem with variable length messages in any codebase that I'm aware of. Is this solving some actual problem? On Wed, Jun 19, 2013 at 12:30 AM, Turkey Breast turkeybre...@yahoo.com wrote: That's me. I never said to make all messages fixed length. I said to make a fixed number of fields per protocol. So given a protocol version number, you know the number of fields in a message. This is not only easier for parsing messages, but just good practice. I don't see why a 1 byte flag needs to be optional anyway. From: Mike Hearn m...@plan99.net To: Turkey Breast turkeybre...@yahoo.com Cc: Bitcoin Dev bitcoin-development@lists.sourceforge.net Sent: Tuesday, June 18, 2013 9:48 PM Subject: Re: [Bitcoin-development] Missing fRelayTxes in version message It's not a bug (although there was recently a change to make bitcoind/qt always send this field anyway). I don't know where Amir is going with BIP 60. Version messages have always been variable length. There's nothing inherent in the Bitcoin protocol that says all messages are fixed length, indeed, tx messages are allowed to have arbitrary data appended after them that gets relayed. On Tue, Jun 18, 2013 at 7:45 PM, Turkey Breast turkeybre...@yahoo.com wrote: See this BIP. I'm not sure if this is a bug or what, but it would be good if messages always had a fixed number of fields per protocol version. https://en.bitcoin.it/wiki/BIP_0060#Code_Updates This BIP details everything that needs to be done and proposes a protocol upgrade. -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Missing fRelayTxes in version message
Bitcoin-Qt on master does send it now although it doesn't affect anything,
but as old pre-filtering versions will continue to exist, you'll always
have to be able to deserialize version messages without it.
Bitcoin version messages have always had variable length, look at how the
code is written in main.cpp. If you didn't experience issues until now all
it means is that no sufficiently old nodes were talking to yours.
The standard does not say it should appear. Read it again - BIP 37 says
about the new version message field:
If false then broadcast transactions will not be announced until a
filter{load,add,clear} command is received. *If missing or true*, no change
in protocol behaviour occurs.
On Wed, Jun 19, 2013 at 12:33 PM, Turkey Breast turkeybre...@yahoo.comwrote:
It's a problem if you work with iterators to deserialize the byte stream.
Even failing that, it's just sloppy programming. What happens in the future
when new fields are added to the version message? It's not a big deal to
say that this protocol version has X number of fields, that (higher)
protocol version message has X + N number of fields. Deterministic number
of fields per protocol version is sensical and how Bitcoin has been for a
long time.
And yes, it was a problem for me that caused a lot of confusion why this
byte didn't exist in many version messages despite the standard saying it
should and the code in bitcoind indicating it should. Nowhere was this
written. It doesn't help other implementations to have an unclear behaviour
that depends on some magic from one implementation.
--
*From:* Mike Hearn m...@plan99.net
*To:* Turkey Breast turkeybre...@yahoo.com
*Cc:* bitcoin-development@lists.sourceforge.net
bitcoin-development@lists.sourceforge.net
*Sent:* Wednesday, June 19, 2013 11:39 AM
*Subject:* Re: [Bitcoin-development] Missing fRelayTxes in version message
It has to be optional because old clients don't send it, obviously.
Why is this even an issue? There's no problem with variable length
messages in any codebase that I'm aware of. Is this solving some actual
problem?
On Wed, Jun 19, 2013 at 12:30 AM, Turkey Breast turkeybre...@yahoo.comwrote:
That's me. I never said to make all messages fixed length. I said to make
a fixed number of fields per protocol. So given a protocol version number,
you know the number of fields in a message. This is not only easier for
parsing messages, but just good practice. I don't see why a 1 byte flag
needs to be optional anyway.
--
*From:* Mike Hearn m...@plan99.net
*To:* Turkey Breast turkeybre...@yahoo.com
*Cc:* Bitcoin Dev bitcoin-development@lists.sourceforge.net
*Sent:* Tuesday, June 18, 2013 9:48 PM
*Subject:* Re: [Bitcoin-development] Missing fRelayTxes in version message
It's not a bug (although there was recently a change to make bitcoind/qt
always send this field anyway).
I don't know where Amir is going with BIP 60. Version messages have always
been variable length. There's nothing inherent in the Bitcoin protocol that
says all messages are fixed length, indeed, tx messages are allowed to have
arbitrary data appended after them that gets relayed.
On Tue, Jun 18, 2013 at 7:45 PM, Turkey Breast turkeybre...@yahoo.comwrote:
See this BIP. I'm not sure if this is a bug or what, but it would be good
if messages always had a fixed number of fields per protocol version.
https://en.bitcoin.it/wiki/BIP_0060#Code_Updates
This BIP details everything that needs to be done and proposes a protocol
upgrade.
--
This SF.net http://sf.net/ email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
Re: [Bitcoin-development] Optional wallet-linkable address format - Payment Protocol
On 18 June 2013 05:48, Alan Reiner etothe...@gmail.com wrote:
*Goal*: An alternative address format made possible by BIP 32, which
allows one to specify a Wallet ID and One-time payment code, instead of
the standard one-use Base58-Hash160 addresses. This allows parties with a
persistent relationship to be able to prove that payment addresses they
provide each other are linked to a particular wallet, reducing exposure to
MitM attacks without the need for SSL or a web of trust, and without
compromising the privacy of either party.For instance, this could be
used between businesses that frequently do business, by exchanging and
verifying public keys beforehand, or could be used by an exchange to
identify if a customer withdrawal address is related to their last deposit
address, and if not enforce extra authentication measures.
*Background**:*
I haven't been following the payment protocol discussions/development
much, so I apologize if this has already been addressed. I'm calling it
wallet-linkable addresses, which would be an optional second form for
sending someone your address. With BIP 32, the address is computed by the
payee (the person sending the address to receive money):
Standard Address ~ Base58(0x00 || hash160(PubKeyParent * Multiplier[i])
|| checksum)
What I'd like to do is have the option, when specifying an address through
the payment protocol, to send *just* the {PublicKeyParent, Multiplier[i]}
and let the receiver of that address compute the address on their own.
This is no significant burden on the receiver, but it does provide the
useful property that they can recognize when addresses specified in this
way come from the same wallet -- because the PubKeyParent will be the
same. Remember, this is *optional* for the person providing the address.
One nice, accidental feature of BIP 32 is that the Multiplier[i] used
above does not actually reveal the chaincode (I think Pieter started
calling it the tweak). It is derived from the chaincode but doesn't
reveal it. Therefore, the payer sees the parent public key, but that's not
useful to derive any of the other addresses unless they also have the
chaincode. But they can verify that the PublicKeyParent is identical
between transactions, and thus is accessible only to that wallet. It
allows them validate a specific address provided by the payee, but not
generate or identify any other addresses.
*Use Cases:*
(1) So, just like with PGP/GPG, when two parties decide they will start a
relationship, they can start by exchanging the public keys of their wallet
and verify them in a reliable manner. After that, when one party requests
a payment address from the other, they can optionally send {PubKey,
Multiplier}, and the payer's software will identify the owner of that
address, or let you select who you think the address belongs to and it will
verify it. If the payee's system is compromised and address is replaced,
the address received by the payer won't validate. This doesn't help if the
side sending the money is compromised.
(2) When a customer first provides a deposit to an exchange, it will send
money from an address in their wallet and the software will provide the
exchange the {PubKey,Mult}. When the customer later provides a withdrawal
address, the site can automatically trust the address as long it is
provided in the alternate form and the public keys match. If they don't,
it might be the same customer just requesting a withdrawal to a different
wallet, which is fine, but they'll have to go through an extra verification
step to do so.
*Downsides:*
Multi-sig/P2SH - The only way this works with P2SH, violates one of the
goals of P2SH slightly, but may not matter much if it's all done under the
hood by the software. Instead of providing a 20-byte hash of a script, you
provide all the public keys and multipliers for the individual addresses.
The payer's software automatically verifies all addresses and creates the
P2SH script itself (after a divine decree that public keys will always be
sorted lexicographically in the multi-sig script). The blockchain still
benefits from the compression of moving the bulky scripts to the TxIn,
but it does require revealing more information than is necessary for the
payer to pay the payee. But it may not *really* be a problem, given the
benefits. It might just be slightly longer strings to exchange during
initialization and for each transaction.
I have various reasons I'd like to use this, and it'd be nice to have some
community backing, so I don't have to twist anyone's arm to trust me that
it's legit.
Generally in favour of hierarchical deterministic wallets.
Will this new style of address make it into the block chain? I'd be less
keen on that.
I'm finding BIP0032 quite hard to read right now, but perhaps that's
because I'm less familiar with the material than some. However, there's
little things like it
Re: [Bitcoin-development] Missing fRelayTxes in version message
If you want to criticise the Bitcoin protocol for sloppyness, the variable
length of some messages isn't where I'd start.
Note that ping has the same issue, its length has changed over time to
include the nonce.
If your parser can't handle that kind of thing, you need to fix it. The
protocol has always worked that way.
On Wed, Jun 19, 2013 at 3:03 PM, Paul Lyon pml...@hotmail.ca wrote:
I’m also running into this exact same issue with my parser, now I
understand why the relay field behavior I was seeing doesn’t match the wiki.
So to parse a version message, you can’t rely on the protocol version? You
have to know how long the payload is, and then parse the message
accordingly? I agree with Turkey Breast, this seems a bit sloppy to me.
Paul
P.S. I’ve never used a dev mailing list before and I want to get involved
with the Bitcoin dev community, so let me know if I’m horribly violating
any mailing list etiquette.
*From:* Mike Hearn
*Sent:* Wednesday, June 19, 2013 7:43 AM
*To:* Turkey Breast
*Cc:* bitcoin-development@lists.sourceforge.net
Bitcoin-Qt on master does send it now although it doesn't affect anything,
but as old pre-filtering versions will continue to exist, you'll always
have to be able to deserialize version messages without it.
Bitcoin version messages have always had variable length, look at how the
code is written in main.cpp. If you didn't experience issues until now all
it means is that no sufficiently old nodes were talking to yours.
The standard does not say it should appear. Read it again - BIP 37 says
about the new version message field:
If false then broadcast transactions will not be announced until a
filter{load,add,clear} command is received. *If missing or true*, no
change in protocol behaviour occurs.
On Wed, Jun 19, 2013 at 12:33 PM, Turkey Breast turkeybre...@yahoo.comwrote:
It's a problem if you work with iterators to deserialize the byte stream.
Even failing that, it's just sloppy programming. What happens in the future
when new fields are added to the version message? It's not a big deal to
say that this protocol version has X number of fields, that (higher)
protocol version message has X + N number of fields. Deterministic number
of fields per protocol version is sensical and how Bitcoin has been for a
long time.
And yes, it was a problem for me that caused a lot of confusion why this
byte didn't exist in many version messages despite the standard saying it
should and the code in bitcoind indicating it should. Nowhere was this
written. It doesn't help other implementations to have an unclear behaviour
that depends on some magic from one implementation.
--
*From:* Mike Hearn m...@plan99.net
*To:* Turkey Breast turkeybre...@yahoo.com
*Cc:* bitcoin-development@lists.sourceforge.net
bitcoin-development@lists.sourceforge.net
*Sent:* Wednesday, June 19, 2013 11:39 AM
*Subject:* Re: [Bitcoin-development] Missing fRelayTxes in version
message
It has to be optional because old clients don't send it, obviously.
Why is this even an issue? There's no problem with variable length
messages in any codebase that I'm aware of. Is this solving some actual
problem?
On Wed, Jun 19, 2013 at 12:30 AM, Turkey Breast
turkeybre...@yahoo.comwrote:
That's me. I never said to make all messages fixed length. I said to make
a fixed number of fields per protocol. So given a protocol version number,
you know the number of fields in a message. This is not only easier for
parsing messages, but just good practice. I don't see why a 1 byte flag
needs to be optional anyway.
--
*From:* Mike Hearn m...@plan99.net
*To:* Turkey Breast turkeybre...@yahoo.com
*Cc:* Bitcoin Dev bitcoin-development@lists.sourceforge.net
*Sent:* Tuesday, June 18, 2013 9:48 PM
*Subject:* Re: [Bitcoin-development] Missing fRelayTxes in version
message
It's not a bug (although there was recently a change to make bitcoind/qt
always send this field anyway).
I don't know where Amir is going with BIP 60. Version messages have
always been variable length. There's nothing inherent in the Bitcoin
protocol that says all messages are fixed length, indeed, tx messages are
allowed to have arbitrary data appended after them that gets relayed.
On Tue, Jun 18, 2013 at 7:45 PM, Turkey Breast turkeybre...@yahoo.comwrote:
See this BIP. I'm not sure if this is a bug or what, but it would be good
if messages always had a fixed number of fields per protocol version.
https://en.bitcoin.it/wiki/BIP_0060#Code_Updates
This BIP details everything that needs to be done and proposes a protocol
upgrade.
--
This SF.net http://sf.net/ email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
___
Bitcoin-development mailing
Re: [Bitcoin-development] Missing fRelayTxes in version message
I’m also running into this exact same issue with my parser, now I understand
why the relay field behavior I was seeing doesn’tmatch the wiki.
So to parse a version message, you can’t rely on the protocol version? You have
to know how long the payload is, and then parse the message accordingly? I
agree with Turkey Breast, this seems a bit sloppy to me.
Paul
P.S. I’ve never used a dev mailing list before and I want to get involved with
the Bitcoin dev community, so let me know if I’m horribly violating any mailing
list etiquette.
From: Mike Hearn
Sent: Wednesday, June 19, 2013 7:43 AM
To: Turkey Breast
Cc: bitcoin-development@lists.sourceforge.net
Bitcoin-Qt on master does send it now although it doesn't affect anything, but
as old pre-filtering versions will continue to exist, you'll always have to be
able to deserialize version messages without it.
Bitcoin version messages have always had variable length, look at how the code
is written in main.cpp. If you didn't experience issues until now all it means
is that no sufficiently old nodes were talking to yours.
The standard does not say it should appear. Read it again - BIP 37 says about
the new version message field:
If false then broadcast transactions will not be announced until a
filter{load,add,clear} command is received. If missing or true, no change in
protocol behaviour occurs.
On Wed, Jun 19, 2013 at 12:33 PM, Turkey Breast turkeybre...@yahoo.com wrote:
It's a problem if you work with iterators to deserialize the byte stream. Even
failing that, it's just sloppy programming. What happens in the future when new
fields are added to the version message? It's not a big deal to say that this
protocol version has X number of fields, that (higher) protocol version message
has X + N number of fields. Deterministic number of fields per protocol version
is sensical and how Bitcoin has been for a long time.
And yes, it was a problem for me that caused a lot of confusion why this byte
didn't exist in many version messages despite the standard saying it should and
the code in bitcoind indicating it should. Nowhere was this written. It doesn't
help other implementations to have an unclear behaviour that depends on some
magic from one implementation.
From: Mike Hearn m...@plan99.net
To: Turkey Breast turkeybre...@yahoo.com
Cc: bitcoin-development@lists.sourceforge.net
bitcoin-development@lists.sourceforge.net
Sent: Wednesday, June 19, 2013 11:39 AM
Subject: Re: [Bitcoin-development] Missing fRelayTxes in version message
It has to be optional because old clients don't send it, obviously.
Why is this even an issue? There's no problem with variable length messages in
any codebase that I'm aware of. Is this solving some actual problem?
On Wed, Jun 19, 2013 at 12:30 AM, Turkey Breast turkeybre...@yahoo.com wrote:
That's me. I never said to make all messages fixed length. I said to make a
fixed number of fields per protocol. So given a protocol version number, you
know the number of fields in a message. This is not only easier for parsing
messages, but just good practice. I don't see why a 1 byte flag needs to be
optional anyway.
From: Mike Hearn m...@plan99.net
To: Turkey Breast turkeybre...@yahoo.com
Cc: Bitcoin Dev bitcoin-development@lists.sourceforge.net
Sent: Tuesday, June 18, 2013 9:48 PM
Subject: Re: [Bitcoin-development] Missing fRelayTxes in version message
It's not a bug (although there was recently a change to make bitcoind/qt always
send this field anyway).
I don't know where Amir is going with BIP 60. Version messages have always been
variable length. There's nothing inherent in the Bitcoin protocol that says all
messages are fixed length, indeed, tx messages are allowed to have arbitrary
data appended after them that gets relayed.
On Tue, Jun 18, 2013 at 7:45 PM, Turkey Breast turkeybre...@yahoo.com wrote:
See this BIP. I'm not sure if this is a bug or what, but it would be good if
messages always had a fixed number of fields per protocol version.
https://en.bitcoin.it/wiki/BIP_0060#Code_Updates
This BIP details everything that needs to be done and proposes a protocol
upgrade.
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
Re: [Bitcoin-development] Optional wallet-linkable address format - Payment Protocol
On 06/19/2013 08:19 AM, Melvin Carvalho wrote:
Generally in favour of hierarchical deterministic wallets.
Will this new style of address make it into the block chain? I'd be
less keen on that.
I'm finding BIP0032 quite hard to read right now, but perhaps that's
because I'm less familiar with the material than some. However,
there's little things like it never actually defines a deterministic
wallet in the Abstract. But, I'll keep trying to understand and see
if I can use the test vectors.
This has nothing to do with the blockchain. This is simply an alternate
way to encode an address, in the event that you want to prove that this
address is linked to another address. The same thing ends up in the
blockchain, either way.
Either:
(1) I give you a Hash160 address which shows up in the blockchain
or
(2) I give you {PubKey, Mult}, then you compute PubKey*Mult then hash it
to get the same Hash160 I would've given you in (1)
I can always give you version #1, and that's what everyone does right
now. Version #2 is essentially the same, but used if you want to give
the other party extra information (such as the root public key, so that
the next time you send a version#2 address they can see they are from
the same root public key).
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Optional wallet-linkable address format - Payment Protocol
On Mon, Jun 17, 2013 at 11:48:22PM -0400, Alan Reiner wrote: _*Goal*_: An alternative address format made possible by BIP 32, which allows one to specify a Wallet ID and One-time payment code, instead of the standard one-use Base58-Hash160 addresses. This allows parties with a persistent relationship to be able to prove that payment addresses they provide each other are linked to a particular wallet, reducing exposure to MitM attacks without the need for SSL or a web of trust, and without compromising the privacy of either party.For instance, this could be used between businesses that frequently do business, by exchanging and verifying public keys beforehand, or could be used by an exchange to identify if a customer withdrawal address is related to their last deposit address, and if not enforce extra authentication measures. Have you seen Timo Hanke's pay-to-contract presentation at the San Jose conference? It seems very related: http://www.youtube.com/watch?v=qwyALGlG33Q -- Pieter -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Optional wallet-linkable address format - Payment Protocol
Since you mention to use this in conjunction with the payment protocol,
note the following subtlety. Suppose the payer has to paid this address
called destination:
Standard Address ~ Base58(0x00 || hash160(PubKeyParent * Multiplier[i]) ||
checksum)
Also suppose the payee has spent the output, i.e. the pubkey
corresponding to destination, which is PubKeyParent * Multiplier[i],
is publicly known. Then anybody can (in retrospect) create arbitrary
many pairs {PublicKeyParent, Multiplier} (in particular different
PublicKeyParent) that lead to the same destination.
Depending on what you have in mind that the transaction should prove
regarding its actual receiver or regarding the receiver's PubKeyParent,
this could be an unwanted feature (or it could be just fine). If it is
unwanted then I suggest replacing
PubKeyParent * Multiplier[i] by
PubKeyParent * HMAC(Multiplier[i],PubKeyParent)
which eliminates from the destination all ambiguity about PubKeyParent.
This modification would not be directly compatible with BIP32 anymore
(unfortunately), but seems to be better suited for use in conjunction
with a payment protocol.
Timo
On Mon, Jun 17, 2013 at 11:48:22PM -0400, Alan Reiner wrote:
Goal: An alternative address format made possible by BIP 32, which allows one
to specify a Wallet ID and One-time payment code, instead of the standard
one-use Base58-Hash160 addresses. This allows parties with a persistent
relationship to be able to prove that payment addresses they provide each
other
are linked to a particular wallet, reducing exposure to MitM attacks without
the need for SSL or a web of trust, and without compromising the privacy of
either party.For instance, this could be used between businesses that
frequently do business, by exchanging and verifying public keys beforehand, or
could be used by an exchange to identify if a customer withdrawal address is
related to their last deposit address, and if not enforce extra authentication
measures.
Background:
I haven't been following the payment protocol discussions/development much, so
I apologize if this has already been addressed. I'm calling it
wallet-linkable addresses, which would be an optional second form for
sending
someone your address. With BIP 32, the address is computed by the payee (the
person sending the address to receive money):
Standard Address ~ Base58(0x00 || hash160(PubKeyParent * Multiplier[i]) ||
checksum)
What I'd like to do is have the option, when specifying an address through the
payment protocol, to send *just* the {PublicKeyParent, Multiplier[i]} and let
the receiver of that address compute the address on their own. This is no
significant burden on the receiver, but it does provide the useful property
that they can recognize when addresses specified in this way come from the
same
wallet -- because the PubKeyParent will be the same. Remember, this is
optional for the person providing the address.
One nice, accidental feature of BIP 32 is that the Multiplier[i] used above
does not actually reveal the chaincode (I think Pieter started calling it
the
tweak). It is derived from the chaincode but doesn't reveal it.
Therefore,
the payer sees the parent public key, but that's not useful to derive any of
the other addresses unless they also have the chaincode. But they can verify
that the PublicKeyParent is identical between transactions, and thus is
accessible only to that wallet. It allows them validate a specific address
provided by the payee, but not generate or identify any other addresses.
Use Cases:
(1) So, just like with PGP/GPG, when two parties decide they will start a
relationship, they can start by exchanging the public keys of their wallet and
verify them in a reliable manner. After that, when one party requests a
payment address from the other, they can optionally send {PubKey, Multiplier},
and the payer's software will identify the owner of that address, or let you
select who you think the address belongs to and it will verify it. If the
payee's system is compromised and address is replaced, the address received by
the payer won't validate. This doesn't help if the side sending the money is
compromised.
(2) When a customer first provides a deposit to an exchange, it will send
money from an address in their wallet and the software will provide the
exchange the {PubKey,Mult}. When the customer later provides a withdrawal
address, the site can automatically trust the address as long it is provided
in
the alternate form and the public keys match. If they don't, it might be the
same customer just requesting a withdrawal to a different wallet, which is
fine, but they'll have to go through an extra verification step to do so.
Downsides:
Multi-sig/P2SH - The only way this works with P2SH, violates one of the goals
of P2SH slightly, but may not matter much if it's all done under the hood by
the software. Instead of
Re: [Bitcoin-development] Optional wallet-linkable address format - Payment Protocol
On 06/19/2013 10:25 AM, Timo Hanke wrote:
Since you mention to use this in conjunction with the payment protocol,
note the following subtlety. Suppose the payer has to paid this address
called destination:
Standard Address ~ Base58(0x00 || hash160(PubKeyParent * Multiplier[i]) ||
checksum)
Also suppose the payee has spent the output, i.e. the pubkey
corresponding to destination, which is PubKeyParent * Multiplier[i],
is publicly known. Then anybody can (in retrospect) create arbitrary
many pairs {PublicKeyParent, Multiplier} (in particular different
PublicKeyParent) that lead to the same destination.
Depending on what you have in mind that the transaction should prove
regarding its actual receiver or regarding the receiver's PubKeyParent,
this could be an unwanted feature (or it could be just fine). If it is
unwanted then I suggest replacing
PubKeyParent * Multiplier[i] by
PubKeyParent * HMAC(Multiplier[i],PubKeyParent)
which eliminates from the destination all ambiguity about PubKeyParent.
This modification would not be directly compatible with BIP32 anymore
(unfortunately), but seems to be better suited for use in conjunction
with a payment protocol.
Timo
It's an interesting observation, but it looks like the most-obvious
attack vector is discrete log problem: spoofing a relationship between
a target public key and one that you control. For instance, if you see
{PubA, Mult} produces PubB and you have PubC already in your control
that you want to prove [maliciously] is related to PubB, then you have
to find the multiplier, M that solves: M*PubC = PubB. That's a
discrete logarithm problem.
I'm not as familiar as you are, with the available operations on
elliptic curves, but it sounds like you can produce essentially-random
pairs of {PubX, Mult} pairs that give the same PubB, but you won't have
the private key associated with those public keys. It's an interesting
point, and there may be a reason to be concerned about it. Though, I
don't see it yet.
-Alan
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Optional wallet-linkable address format - Payment Protocol
This maybe simpler and trivially compatible with existing type2 public keys (ones that are multiples of a parent public key): send an ECDSA signature of the multiplier, and as we know you can compute (recover) the parent public key from an the ECDSA signature made using it. Adam On Wed, Jun 19, 2013 at 05:28:15PM +0200, Adam Back wrote: [q-th root with unknown no discrete log artefact] If it was a concern I guess you could require a proof of knowledge of discrete log. ie as well as public key parent, multiplier the address must include ECDSA sig or Schnorr proof of knowledge (which both demonstrate knowledge of the discrete log of Q to base G.) -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Optional wallet-linkable address format - Payment Protocol
On 06/19/2013 02:36 PM, Adam Back wrote:
This maybe simpler and trivially compatible with existing type2 public
keys
(ones that are multiples of a parent public key): send an ECDSA
signature of
the multiplier, and as we know you can compute (recover) the parent
public
key from an the ECDSA signature made using it.
Adam
On Wed, Jun 19, 2013 at 05:28:15PM +0200, Adam Back wrote:
[q-th root with unknown no discrete log artefact]
If it was a concern I guess you could require a proof of knowledge of
discrete log. ie as well as public key parent, multiplier the
address must
include ECDSA sig or Schnorr proof of knowledge (which both demonstrate
knowledge of the discrete log of Q to base G.)
It's a cool trick but requiring a signature on each multiplier defeats
one of the purposes of a deterministic wallet. I don't want to have to
explicitly export a whole bunch of signatures from my offline system
just to exercise this address option. The observer wallet should be
able to do anything it needs to on its own, without help from the
offline wallet.
Unless you mean that there is a one-time signature from the offline
computer that works for all addresses, that can be exported with the
observer wallet...? If all you want to do is prove that /someone/ owns
that private key, you could send {Sign(MagicString), Multiplier}. So
it becomes one signature operation *per wallet*, but creating new
wallets would require going back to the offline computer for that
one-time signature. That's better than the alternative, but it's still
extra bloat for the wallet apps.
Either way, I'm not convinced that these are a problem for the specified
use cases I outlined. In cases where you have a persistent business
relationship, they need to verify the parent public key exchange
anyway. After that, the software doesn't technically require the
transmission of the PubKey, it only needs the Name/ID of the party and
the multiplier and it will fetch the PubKey from its data store. Or it
is transmitted and the payer verifies it's correct. Computing an
alternate {PubKey', Mult'} that produces the same address and then using
it in a MitM attack doesn't work here if the two parties pre-verified
the public keys.
In the case that a business is checking whether the cashout address of a
customer is the same as the last time: if the first payout was not
replaced by an attacker, then the business already has the correct
public key in their DB and a replacement of further payout requests will
fail validation. If the first payout was replaced... well that could've
been done anyway (with or without this alternate form), and the customer
wouldn't have received their money and the whole process would be
flagged and terminated before further transactions.
-Alan
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Optional wallet-linkable address format - Payment Protocol
If you have two parties who want to form a persistent relationship, by
exchanging and verifying public keys beforehand, then I think the canonical way
to do this with BIP32 is for the parties to exchange PubKey and *ChainCode*.
I don’t understand the use case for handing out individual multipliers, if what
you desire is a persistent relationship. If each party dedicates a child-wallet
for receiving coins, and saves a PubKey/ChainCode for sending coins, the two
parties can transaction securely forever without ever exchanging any more
information, and without any address reuse.
I think ideally, the default behavior is that wallets always dedicate a new
child node {PubKey, ChainCode} to each party they transact with. At the
presentation layer, you have a “contact” and each contact has a transaction
history. You can send coins to a contact at any time, and internally the wallet
picks the next address in their sequence. Any funds received on pubkeys from
contact’s sequence are attributed to that contact. The wallet can organize the
contacts, and roll-up the transaction history into ‘ledgers’ and ‘balances’
however they want – it could be based on the underlying BIP32 hierarchy or
perhaps not. The cost of watching large a number of pubkeys, even if you ‘look
ahead’ 100 pubkeys for each contact, is relatively small versus the benefits.
What might be nice is a ‘Contact Request’ protocol, basically the same as a
PaymentRequest but no actual payments are sent, just child wallets created:
message Contact {
optional uint32 contact_version = 1 [default = 1];
optional string pki_type = 2 [default = none];
optional bytes pki_data = 3;
required bytes serialized_contact_details = 4;
optional bytes signature = 5;
}
message ContactDetails {
optional string network = 1 [default = main];
required bytes pubkey = 2;
required bytes chaincode = 3;
optional string memo = 4;
optional string response_url = 5;
}
Alice sends a Contact+ContactDetails to Bob. If Bob accepts, he sends his own
Contact+ContactDetails (without a response_url) back to Alice. Basically just
like adding a contact to your IM contacts.
Alice could send a Contact+ContactDetails to Bob without a response_url, in
which case after accepting the contact, Bob could send funds to Alice, but not
receive funds.
You could probably pack the whole message inside a bitcoin:// URI if you wanted
to.
Thanks,
--Jeremy--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Optional wallet-linkable address format - Payment Protocol
On Wed, Jun 19, 2013 at 10:39:04AM -0400, Alan Reiner wrote:
On 06/19/2013 10:25 AM, Timo Hanke wrote:
Since you mention to use this in conjunction with the payment protocol,
note the following subtlety. Suppose the payer has to paid this address
called destination:
Standard Address ~ Base58(0x00 || hash160(PubKeyParent * Multiplier[i])
||
checksum)
Also suppose the payee has spent the output, i.e. the pubkey
corresponding to destination, which is PubKeyParent * Multiplier[i],
is publicly known. Then anybody can (in retrospect) create arbitrary
many pairs {PublicKeyParent, Multiplier} (in particular different
PublicKeyParent) that lead to the same destination.
Depending on what you have in mind that the transaction should prove
regarding its actual receiver or regarding the receiver's PubKeyParent,
this could be an unwanted feature (or it could be just fine). If it is
unwanted then I suggest replacing
PubKeyParent * Multiplier[i] by
PubKeyParent * HMAC(Multiplier[i],PubKeyParent)
which eliminates from the destination all ambiguity about PubKeyParent.
This modification would not be directly compatible with BIP32 anymore
(unfortunately), but seems to be better suited for use in conjunction
with a payment protocol.
Timo
It's an interesting observation, but it looks like the most-obvious
attack vector is discrete log problem: spoofing a relationship between
a target public key and one that you control. For instance, if you see
{PubA, Mult} produces PubB and you have PubC already in your control
that you want to prove [maliciously] is related to PubB, then you have
to find the multiplier, M that solves: M*PubC = PubB. That's a
discrete logarithm problem.
Correct, for a given PubC in advance you can't create such a malicious
relation to PubB. You can only reversely construct new PubC from given
PubB.
I'm not as familiar as you are, with the available operations on
elliptic curves, but it sounds like you can produce essentially-random
pairs of {PubX, Mult} pairs that give the same PubB, but you won't have
the private key associated with those public keys.
Depends on who is you. The arbitrary person who produces {PubX, Mult}
won't have the private key, but the person who knows the private key for
PubA will have it (assuming that PubB was computed from {PubA, Mult} in
the first place).
In the end, it all depends on your application. What proves enough for
one party doing repeated transactions with another may not suffice for a
third party doing auditing. On the other hand, ambiguity about PubA may
just as well be a wanted feature for deniability reasons.
Timo
--
Timo Hanke
PGP 1EFF 69BC 6FB7 8744 14DB 631D 1BB5 D6E3 AB96 7DA8
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Optional wallet-linkable address format - Payment Protocol
On 06/19/2013 03:29 PM, Jeremy Spilman wrote:
If you have two parties who want to form a persistent relationship, by
exchanging and verifying public keys beforehand, then I think the
canonical way to do this with BIP32 is for the parties to exchange
PubKey and *ChainCode*.
I don't understand the use case for handing out individual
multipliers, if what you desire is a persistent relationship. If each
party dedicates a child-wallet for receiving coins, and saves a
PubKey/ChainCode for sending coins, the two parties can transaction
securely forever without ever exchanging any more information, and
without any address reuse.
I think ideally, the default behavior is that wallets always dedicate
a new child node {PubKey, ChainCode} to each party they transact with.
At the presentation layer, you have a contact and each contact has a
transaction history. You can send coins to a contact at any time, and
internally the wallet picks the next address in their sequence. Any
funds received on pubkeys from contact's sequence are attributed to
that contact. The wallet can organize the contacts, and roll-up the
transaction history into 'ledgers' and 'balances' however they want --
it could be based on the underlying BIP32 hierarchy or perhaps not.
The cost of watching large a number of pubkeys, even if you 'look
ahead' 100 pubkeys for each contact, is relatively small versus the
benefits.
What you just described is complimentary to what I am proposing. There
is nothing stopping you from doing it that way, except that it may be
inconvenient in some circumstances. BIP 32 does not prescribe a way to
use multiple chains like you described with the convenient type-2
derivation (though we could create a variant that does). And all
separate chains with their 100-address look-aheads may be fine for your
desktop or mobile device, but maybe not a HW signing device with 128 kB
of memory.
So, some use cases might prefer having a different parent public key
[and chaincode] per contact, some may prefer to synchronize across many
contacts. For instance, maybe there's a benefit to using the same
parent pubkey across multiple services, as a form of identity. If I
don't want that, I use your method. If I do want that, I use my
method. Given its simplicity, I don't know why both can't be options.
Actually, it doesn't have to be specific to the payment protocol, it can
just be alternative address encoding that some apps would use if they
have a need for it.
-Alan
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Optional wallet-linkable address format - Payment Protocol
Hi Alan, “BIP 32 does not prescribe a way to use multiple chains like you described with the convenient type-2 derivation (though we could create a variant that does)” What do you think is missing from BIP32 for this? A wallet creates a child-node using the public / type-2 CDF, hands out the PubKey/ChainCode, and then generally expects transactions to come in starting at /0 and incrementing monotonically. Also, I'm not sure I follow your point about the 128kB hardware wallet -- it's a signing device, so assuming it's even validating output amounts, at worst it cares about the number of inputs to the outputs being spent, but in many cases you're just handing it a sighash and the BIP32 path (/1/54/27/0) to generate the right private key for signing. The hardware wallet is not actually listening on the P2P network and detecting payments, so it's unaffected by dedicating child-nodes to each contact. Consider the benefits of gaining critical mass of support for a technique which [I think] can be used in all cases, and increases security and privacy for everyone. I think there are huge benefits to leaving the age of 'single address generation' behind us... Thanks, --Jeremy -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Optional wallet-linkable address format - Payment Protocol
On 06/19/2013 05:58 PM, Jeremy Spilman wrote: Hi Alan, “BIP 32 does not prescribe a way to use multiple chains like you described with the convenient type-2 derivation (though we could create a variant that does)” What do you think is missing from BIP32 for this? A wallet creates a child-node using the public / type-2 CDF, hands out the PubKey/ChainCode, and then generally expects transactions to come in starting at /0 and incrementing monotonically. You are suggesting that creating new wallet chains are the only operation needed to achieve the functionality I'm requesting. I disagree. I am okay with using different wallets for different parties */if the user wants to/*. But there are orthogonal use-cases to having a single wallet serve as a single identity that can be used across multiple transactions or services. And doing so is much simpler conceptually for the user, and simpler in implementation for the app developer. BIP 32 already specifies how to use the first three tree levels: M/i/j/k, i~wallet, j~Internal/External, k~address. The first level is actually type-1 derived, and thus we cannot create an arbitrary number of them without pre-computing them from the offline wallet. So it's not free to create new wallets unless we redefine how the levels work. Even if we assume the simplest case where the first level is actually type-2 derived and it costs nothing to create separate wallets for each contact/party: -- Do these extra wallet chains behave as different wallets, or sub-wallets? -- Should their balances be bundled into a single wallet or displayed separately? -- When a user tries to spend, does he have to specify which wallet(s) he's spending from? -- Should the app developer be required to implement a multiple-wallet interface, and handle cross-wallet spending just to achieve this simple mechanism? Sure, they could instead implement a tiered wallet hierarchy with primary wallets and sub-wallets... wait this just got complicated. All that complexity just to support this identity mechanism that can be included purely as an alternative address encoding with a single wallet. With my request, the user can't have one wallet and distribute most of his addresses the normal/anonymous way, but certain apps would choose to use the alternate encoding as a form of identity. If the user feels the need to create a separate wallet for certain operations to separate his identities, that is his option if the software supports multiple wallets. But it's not the only way. To achieve what I'm suggesting is useful and trivial to implement even in the simplest wallet applications. -Alan -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Optional wallet-linkable address format - Payment Protocol
BIP 32 already specifies how to use the first three tree levels: M/i/j/k,
i~wallet, j~Internal/External, k~address. The first level is actually
type-1 derived, and thus we cannot create an arbitrary number of them
without pre-computing them from the offline wallet. So it's not free to
create new wallets unless we redefine how the levels work.
Initially I was thinking that you would share the public key and chain code
from [m/i'/0] so that you can receive payments at [m/i'/0/k], for a unique
value of 'i' for each receive chain.
For the case of generating new receive chains from a *watch-only* wallet, as
you say, the options are to either keep a cache of PubKey/ChainCode for
unused [m/i'] or simply increment 'j' past 1 for an existing [m/i'/j] -- the
concept of 'internal/'external' and change addresses at Depth=2 don't make
sense for handing out receive chains to lots of people anyway, and certainly
BIP32 doesn't *require* 0 = j = 1. So I think incrementing 'j' is the way
to go here...
The default layout of BIP32 does NOT mean that implementations should not
check for transactions with j 1. That would be a useless constraint and
obviously self-limiting. It might be helpful to add to the 'Compatibility'
section some minimum expectations about how a wallet should be 'probed' when
imported. If you don't feel completely free to monotonically increment 'j'
to your hearts content to achieve major usability benefits, then I say BIP32
could use some clarifying.
BTW - the spec calls for addition not multiplication now, so we should call
it the 'Addend' not the 'Multiplier' :-)
Do these extra wallet chains behave as different wallets, or sub-wallets?
They could, but they certainly don't need to! A single-wallet
implementation treats this merely as an address-generation algorithm, and
does not expose any hierarchy to the user interface. The user just
“magically” gets the ability to send multiple payments to their contacts
without immediately sacrificing their privacy
(http://www.wired.com/wiredenterprise/2013/06/bitcoin_retai/). Everything
goes into the same ledger, balance, coin pool, etc. Most of the code base is
unaware BIP32 is even in use.
While it is *possible* to support separate ledgers, balances, etc. it is
certainly not required, and you get all the benefits either way.
I think, since your proposal generates and receives payments into
BIP32-style addresses, we both need similar underlying wallet code. The only
difference is that you are passing the Kpar for [m/i'/0/k] and the *result*
of CKD'((Kpar, cpar), k), and instead I proposed passing Kpar and cpar, and
leaving 'k' out of it, letting the receive choose 'k'.
For instance, maybe there's a benefit to using the same parent pubkey
across multiple services, as a form of identity. If I don't want that, I
use your method. If I do want that, I use my method.
I think it's a interesting idea using static public keys as a means for
persistent identity and hence security from MitM. If you want a shared
public key across multiple services we could just combine both ideas and get
all the benefits, by making the data structure { ParentPubKey, Addend,
ChainCode }:
ParentPubKey: Public key of m/i' -- 33 bytes
Addend: I[L]*G from CDK'(m/i', j) -- 33 bytes
ChainCode: I[R] from CDK'(m/i', j) -- 32 bytes
All that remains secret is the ChainCode from [m/i'] -- and of course the
private keys. The ParentPubKey is a common value across multiple services,
corresponding to user's identity rooted in [m/i']. Each service gets their
own 'j'. ParentPubKey + Addend gives you the PubKey of [m/i'/j]. With the
ChainCode, the receiver then can generate [m/i'/j/k] for monotonically
increasing 'k'. Again, from the user perspective all transactions under
[m/i'] can be presented in a single ledger, or not.
Anyway, fundamentally my feedback is if you are designing for persistent
long-term relationships, you could build in a mechanism for generating
address chains so you don't need any further communication after the initial
exchange, and it need not complicate the wallet.
Thanks,
--Jeremy
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
