Re: [bitcoin-dev] Capital Efficient Honeypots w/ "Scorched Earth" Doublespending Protection

[James MacWhyte via bitcoin-dev]

I've always assumed honeypots were meant to look like regular, yet
poorly-secured, assets. If the intruder could identify this as a honeypot
by the strange setup (presigned, non-standard transactions lying around)
and was aware that the creator intended to doublespend as soon as the
transaction was discovered, wouldn't they instead prefer to not touch
anything and wait for a non-bait target to appear? Is the assumption here
that the intruder wouldn't know this is a honeypot, or that they would know
and it's just assumed that they would rather take their chances on this
instead of causing some other trouble?

On Tue, Aug 23, 2016 at 6:47 PM Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Bitcoin-based honeypots incentivise intruders into revealing the fact they
> have
> broken into a server by allowing them to claim a reward based on secret
> information obtained during the intrusion. Spending a bitcoin can only be
> done
> by publishing data to a public place - the Bitcoin blockchain - allowing
> detection of the intrusion.
>
> The simplest way to achieve this is with one private key per server, with
> each
> server associated with one transaction output spendable by that key.
> However
> this isn't capital efficient if you have multiple servers to protect: if we
> have N servers and P bitcoins that we can afford to lose in the
> compromise, one
> key per server gives the intruder only N/P incentive.
>
> Previously Piete Wuille proposed(1) tree signatures for honeypots, with a
> single txout protected by a 1-N tree of keys, with each server assigned a
> specific key. Unfortunately though, tree signatures aren't yet implemented
> in
> the Bitcoin protocol.
>
> However with a 2-of-2 multisig and the SIGHASH_SINGLE feature we can
> implement
> this functionality with the existing Bitcoin protocol using the following
> script:
>
> 2   2 CHECKMULTISIG
>
> The honeypot secret key is shared among all N servers, and left on them.
> The
> distriminator secret key meanwhile is kept secret, however for each server
> a
> unique signature is created with SIGHASH_SINGLE, paying a token amount to a
> notification address. For each individual server a pre-signed signature
> created
> with the distriminator secret key is then left on the associated server
> along
> with the honeypot secret key.
>
> Recall the SIGHASH_SINGLE flag means that the signature only signs a single
> transaction input and transaction output; the transaction is allowed to
> have
> additional inputs and outputs added. This allows the thief to use the
> honeypot
> key to construct a claim transaction with an additional output added that
> pays
> an address that they own with the rest of the funds.
>
> Equally, we could also use SIGHASH_NONE, with the per-server discriminator
> being the K value used in the pre-signed transaction.
>
> Note that Jeff Coleman deserves credit as co-inventor of all the above.
>
>
> Censorship Resistance
> =
>
> A potential disadvantage of using non-standard SIGHASH flags is that the
> transactions involved are somewhat unusual, and may be flagged by
> risk analysis at exchanges and the like, a threat to the fungibility of the
> reward.
>
> We can improve on the above concept from Todd/Coleman by using a pre-signed
> standard transaction instead. The pre-signed transaction spends the
> honeypot
> txout to two addresses, a per-server canary address, and a change address.
> The
> private key associated with the change addres is also left on the server,
> and
> the intruder can then spend that change output to finally collect their
> reward.
>
> To any external observer the result looks like two normal transactions
> created
> in the process of someone with a standard wallet sending a small amount of
> funds to an address, followed by sending a larger amount.
>
>
> Doublespending
> ==
>
> A subtlety in the the two transactions concept is that the intruder doesn't
> have the necessary private keys to modify the first transaction, which
> means
> that the honeypot owner can respond to the compromise by doublespending
> that
> transaction, potentially recovering the honeypot while still learning
> about the
> compromise. While this is possible with all honeypots, if the first
> transaction
> is signed with the opt-in RBF flags, and CPFP-aware transaction
> replacement is
> not implemented by miners, the mechanics are particularly disadvantageous
> to
> the intruder, as the honeypot owner only needs to increase the first
> transaction's fee slightly to have a high chance of recovering their funds.
> With CPFP-aware transaction replacement the intruder could in-turn respond
> with
> a high-fee CPFP second transaction, but currently no such implementation is
> known.
>
>
> Scorched Earth
> ==
>
> We can use the "scorched earth" concept to improve the credibility of the
> honeypot reward by making it costly for the honeypot owner to doublespend.
> Here
> a 

Re: [bitcoin-dev] Capital Efficient Honeypots w/ "Scorched Earth" Doublespending Protection

[Chris Priest via bitcoin-dev]

How does your system prevent against insider attacks? How do you know
the money is stolen by someone who compromised server #4, and not
stolen by the person who set up server #4? It is my understanding
these days most attacks are inside jobs.

On 8/24/16, Peter Todd via bitcoin-dev
 wrote:
> On Thu, Aug 25, 2016 at 01:37:34AM +1000, Matthew Roberts wrote:
>> Really nice idea. So its like a smart contract that incentivizes
>> publication that a server has been hacked? I also really like how the
>> funding has been handled -- with all the coins stored in the same address
>> and then each server associated with a unique signature. That way, you
>> don't have to split up all the coins among every server and reduce the
>> incentive for an attacker yet you can still identify which server was
>> hacked.
>>
>> It would be nice if after the attacker broke into the server that they
>> were
>> also incentivized to act on the information as soon as possible
>> (revealing
>> early on when the server was compromised.) I suppose you could split up
>> the
>> coins into different outputs that could optimally be redeemed by the
>> owner
>> at different points in the future -- so they're incentivzed to act lest
>
> Remember that it's _always_ possible for the owner to redeem the coins at
> any
> time, and there's no way to prevent that.
>
> The incentive for the intruder to collect the honeypot in a timely manner
> is
> simple: once they've broken in, the moment the honeypot owner learns about
> the
> compromise they have every reason to attempt to recover the funds, so the
> intruder needs to act as fast as possible to maximize their chances of
> being
> rewarded.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Attack by modifying non-segwit transactions after segwit is accepted ?

[Sergio Demian Lerner via bitcoin-dev]

In a previous thread ("New BIP: Dealing with OP_IF and OP_NOTIF
malleability in P2WSH") it was briefly discussed what happens if someone
modifies segwit data during transmission. I think the discussion should
continue.

What worries me is what happens with non-segwit transactions after segwit
is activated. I've followed the code from transaction arrival to
transaction relay and it seems that a malicious node could receive a
non-segwit tx, and re-format it into a segwit tx having as high as 400
Kbytes of segwit witness program data, and then relay it. Both transaction
would have the same hash.

The MAX_SCRIPT_ELEMENT_SIZE limit is only enforced on segwit execution, not
in old non-segwit execution, so witness program stack elements could be as
large as 400 Kbytes (MAX_STANDARD_TX_WEIGHT prevents increasing more).
Such large modified transaction will probably not be properly relayed by
the network due too low fee/byte, so the honest miner will probably win and
forward the original transaction through the network.
But if the attacker has better connectivity with the network and he
modifies the original transaction adding segwit witness program data only
up to the point where the transaction is relayed but miners are discouraged
to include it in blocks due to low fees/byte, then the attacker has
successfully prevented a transaction from being mined (or at least it will
take much more).

Also an attacker can encode arbitrary data (such as virus signatures or
illegal content) into passing non-segwit transactions.

One solution would be to increase the transaction version to 3 for segwit
transactions, so a non-segwit transaction cannot be converted into a segwit
transaction without changing the transaction hash. But this seems not to be
a good solution, because it does not solve all the problems. Transactions
having a mixture of segwit and non-segwit inputs could suffer the same
attack (even if they are version 3).

I proposed that a rule is added to IsStandardTX() that prevents witness
programs of having a stack elements of length greater than
MAX_SCRIPT_ELEMENT_SIZE. (currently this is not a rule)

That's a simple check that prevents most of the problems.

A long term solution would be to add the maximum size of the witness stack
in bytes (maxWitnessSize) as a field for each input, or as a field of the
whole transaction.

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

Re: [bitcoin-dev] Capital Efficient Honeypots w/ "Scorched Earth" Doublespending Protection

[Peter Todd via bitcoin-dev]

On Thu, Aug 25, 2016 at 01:37:34AM +1000, Matthew Roberts wrote:
> Really nice idea. So its like a smart contract that incentivizes
> publication that a server has been hacked? I also really like how the
> funding has been handled -- with all the coins stored in the same address
> and then each server associated with a unique signature. That way, you
> don't have to split up all the coins among every server and reduce the
> incentive for an attacker yet you can still identify which server was
> hacked.
> 
> It would be nice if after the attacker broke into the server that they were
> also incentivized to act on the information as soon as possible (revealing
> early on when the server was compromised.) I suppose you could split up the
> coins into different outputs that could optimally be redeemed by the owner
> at different points in the future -- so they're incentivzed to act lest

Remember that it's _always_ possible for the owner to redeem the coins at any
time, and there's no way to prevent that.

The incentive for the intruder to collect the honeypot in a timely manner is
simple: once they've broken in, the moment the honeypot owner learns about the
compromise they have every reason to attempt to recover the funds, so the
intruder needs to act as fast as possible to maximize their chances of being
rewarded.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org


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

Re: [bitcoin-dev] Capital Efficient Honeypots w/ "Scorched Earth" Doublespending Protection

[Peter Todd via bitcoin-dev]

On Wed, Aug 24, 2016 at 04:29:19PM +, Jimmy wrote:
> Is this unrelated to Bitcoin Vigil idea published in 2014?
> 
> http://www.coindesk.com/bitcoin-vigil-program-guards-against-intrusion-coin-theft/

I think it's very related; to be absolutely clear the idea of a Bitcoin
honeypot is 100% not my idea! Also, if anyone else had previously invented the
techniques I (and Jeff Coleman) invented, I'd love to hear about it so I can
give appropriate credit.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org


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

Re: [bitcoin-dev] BIP Status updates (including to Active/Final Status) - BIP 39, BIP 43, BIP 44, BIP 67, BIP 111, BIP 125, BIP 130

[Luke Dashjr via bitcoin-dev]

On Wednesday, August 24, 2016 1:47:08 PM Andreas Schildbach via bitcoin-dev 
wrote:
> FWIW, BIP44 also doesn't encode a seed birthday. This needed so that SPV
> wallets do not need to scan from the beginning of the blockchain.
> 
> That doesn't mean BIP44 could not be final. There are some wallets that
> interoperate on that standard and that's fine.

Right. The Status doesn't depend on whether it is a good idea or not, only 
whether or not people are de facto using it.

BIP 2's BIP Comments would have provided a place for Thomas and yourself to 
criticise the BIP, but unfortunately this was too controversial.

> I think BIP43 should be made final as well, if it isn't already.

BIP 43 merely advises other BIPs how they might do things, so it goes into the 
Draft->Active Status flow rather than Draft->Accepted->Final.

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

Re: [bitcoin-dev] Capital Efficient Honeypots w/ "Scorched Earth" Doublespending Protection

[Jimmy via bitcoin-dev]

Is this unrelated to Bitcoin Vigil idea published in 2014?

http://www.coindesk.com/bitcoin-vigil-program-guards-against-intrusion-coin-theft/





On Wed, Aug 24, 2016 at 8:42 AM Matthew Roberts via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Really nice idea. So its like a smart contract that incentivizes
> publication that a server has been hacked? I also really like how the
> funding has been handled -- with all the coins stored in the same address
> and then each server associated with a unique signature. That way, you
> don't have to split up all the coins among every server and reduce the
> incentive for an attacker yet you can still identify which server was
> hacked.
>
> It would be nice if after the attacker broke into the server that they
> were also incentivized to act on the information as soon as possible
> (revealing early on when the server was compromised.) I suppose you could
> split up the coins into different outputs that could optimally be redeemed
> by the owner at different points in the future -- so they're incentivzed to
> act lest their reward decays even more (this is of course, assuming that
> the monetary reward for this is greater than any possible legal
> consequences for the attacker -- it might not be. Thinking about this some
> more: it would also be somewhat hard to deny that this -wasn't- a honeypot
> with such a complex and unique scheme required for transactions, and I for
> one wouldn't like to reveal that I'd hacked a server if I knew it was all a
> calculated ploy. Don't honeypots rely on subtly?)
>
> What about also proving to an attacker that by breaking into a server they
> would be guaranteed a reward? I know that the use-case for this is proof of
> compromise so incentivizing a security audit would kind of fall more into
> an active invitation to audit but couldn't you also make a cryptocurrency
> that allowed coins to be moved based on a service banner existing at a
> given IP address? Attackers could then break into the server, setup a
> service that broadcasts their public key hash, and then spend coins locked
> at this special contract address to that pub key hash which miners would
> check on redemption (putting aside malicious use-cases for now.)
>
>
> On Wed, Aug 24, 2016 at 11:46 AM, Peter Todd via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Bitcoin-based honeypots incentivise intruders into revealing the fact
>> they have
>> broken into a server by allowing them to claim a reward based on secret
>> information obtained during the intrusion. Spending a bitcoin can only be
>> done
>> by publishing data to a public place - the Bitcoin blockchain - allowing
>> detection of the intrusion.
>>
>> The simplest way to achieve this is with one private key per server, with
>> each
>> server associated with one transaction output spendable by that key.
>> However
>> this isn't capital efficient if you have multiple servers to protect: if
>> we
>> have N servers and P bitcoins that we can afford to lose in the
>> compromise, one
>> key per server gives the intruder only N/P incentive.
>>
>> Previously Piete Wuille proposed(1) tree signatures for honeypots, with a
>> single txout protected by a 1-N tree of keys, with each server assigned a
>> specific key. Unfortunately though, tree signatures aren't yet
>> implemented in
>> the Bitcoin protocol.
>>
>> However with a 2-of-2 multisig and the SIGHASH_SINGLE feature we can
>> implement
>> this functionality with the existing Bitcoin protocol using the following
>> script:
>>
>> 2   2 CHECKMULTISIG
>>
>> The honeypot secret key is shared among all N servers, and left on them.
>> The
>> distriminator secret key meanwhile is kept secret, however for each
>> server a
>> unique signature is created with SIGHASH_SINGLE, paying a token amount to
>> a
>> notification address. For each individual server a pre-signed signature
>> created
>> with the distriminator secret key is then left on the associated server
>> along
>> with the honeypot secret key.
>>
>> Recall the SIGHASH_SINGLE flag means that the signature only signs a
>> single
>> transaction input and transaction output; the transaction is allowed to
>> have
>> additional inputs and outputs added. This allows the thief to use the
>> honeypot
>> key to construct a claim transaction with an additional output added that
>> pays
>> an address that they own with the rest of the funds.
>>
>> Equally, we could also use SIGHASH_NONE, with the per-server discriminator
>> being the K value used in the pre-signed transaction.
>>
>> Note that Jeff Coleman deserves credit as co-inventor of all the above.
>>
>>
>> Censorship Resistance
>> =
>>
>> A potential disadvantage of using non-standard SIGHASH flags is that the
>> transactions involved are somewhat unusual, and may be flagged by
>> risk analysis at exchanges and the like, a threat to the fungibility of
>> the
>> reward.
>>
>> We can improve on the above concept 

Re: [bitcoin-dev] Capital Efficient Honeypots w/ "Scorched Earth" Doublespending Protection

[Matthew Roberts via bitcoin-dev]

Really nice idea. So its like a smart contract that incentivizes
publication that a server has been hacked? I also really like how the
funding has been handled -- with all the coins stored in the same address
and then each server associated with a unique signature. That way, you
don't have to split up all the coins among every server and reduce the
incentive for an attacker yet you can still identify which server was
hacked.

It would be nice if after the attacker broke into the server that they were
also incentivized to act on the information as soon as possible (revealing
early on when the server was compromised.) I suppose you could split up the
coins into different outputs that could optimally be redeemed by the owner
at different points in the future -- so they're incentivzed to act lest
their reward decays even more (this is of course, assuming that the
monetary reward for this is greater than any possible legal consequences
for the attacker -- it might not be. Thinking about this some more: it
would also be somewhat hard to deny that this -wasn't- a honeypot with such
a complex and unique scheme required for transactions, and I for one
wouldn't like to reveal that I'd hacked a server if I knew it was all a
calculated ploy. Don't honeypots rely on subtly?)

What about also proving to an attacker that by breaking into a server they
would be guaranteed a reward? I know that the use-case for this is proof of
compromise so incentivizing a security audit would kind of fall more into
an active invitation to audit but couldn't you also make a cryptocurrency
that allowed coins to be moved based on a service banner existing at a
given IP address? Attackers could then break into the server, setup a
service that broadcasts their public key hash, and then spend coins locked
at this special contract address to that pub key hash which miners would
check on redemption (putting aside malicious use-cases for now.)


On Wed, Aug 24, 2016 at 11:46 AM, Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Bitcoin-based honeypots incentivise intruders into revealing the fact they
> have
> broken into a server by allowing them to claim a reward based on secret
> information obtained during the intrusion. Spending a bitcoin can only be
> done
> by publishing data to a public place - the Bitcoin blockchain - allowing
> detection of the intrusion.
>
> The simplest way to achieve this is with one private key per server, with
> each
> server associated with one transaction output spendable by that key.
> However
> this isn't capital efficient if you have multiple servers to protect: if we
> have N servers and P bitcoins that we can afford to lose in the
> compromise, one
> key per server gives the intruder only N/P incentive.
>
> Previously Piete Wuille proposed(1) tree signatures for honeypots, with a
> single txout protected by a 1-N tree of keys, with each server assigned a
> specific key. Unfortunately though, tree signatures aren't yet implemented
> in
> the Bitcoin protocol.
>
> However with a 2-of-2 multisig and the SIGHASH_SINGLE feature we can
> implement
> this functionality with the existing Bitcoin protocol using the following
> script:
>
> 2   2 CHECKMULTISIG
>
> The honeypot secret key is shared among all N servers, and left on them.
> The
> distriminator secret key meanwhile is kept secret, however for each server
> a
> unique signature is created with SIGHASH_SINGLE, paying a token amount to a
> notification address. For each individual server a pre-signed signature
> created
> with the distriminator secret key is then left on the associated server
> along
> with the honeypot secret key.
>
> Recall the SIGHASH_SINGLE flag means that the signature only signs a single
> transaction input and transaction output; the transaction is allowed to
> have
> additional inputs and outputs added. This allows the thief to use the
> honeypot
> key to construct a claim transaction with an additional output added that
> pays
> an address that they own with the rest of the funds.
>
> Equally, we could also use SIGHASH_NONE, with the per-server discriminator
> being the K value used in the pre-signed transaction.
>
> Note that Jeff Coleman deserves credit as co-inventor of all the above.
>
>
> Censorship Resistance
> =
>
> A potential disadvantage of using non-standard SIGHASH flags is that the
> transactions involved are somewhat unusual, and may be flagged by
> risk analysis at exchanges and the like, a threat to the fungibility of the
> reward.
>
> We can improve on the above concept from Todd/Coleman by using a pre-signed
> standard transaction instead. The pre-signed transaction spends the
> honeypot
> txout to two addresses, a per-server canary address, and a change address.
> The
> private key associated with the change addres is also left on the server,
> and
> the intruder can then spend that change output to finally collect their
> reward.
>
> To any external observer the 

Re: [bitcoin-dev] Hardware Wallet Standard

[Thomas Kerin via bitcoin-dev]

I want to pitch a use-case that might have been ignored in this discussion:

I don't think this protocol is only useful for hardware wallets.
Technically any website that wants to request public keys/signatures and
offload the responsibility for managing keys and signing to the user
would also find this valuable.

I hope we can move forward with a protocol that suits both the hardware
people, and the people who find signing transactions in browsers
unsettling.

Maybe we the focus should move away from only servicing hardware, and
asking if the motivation is better captured by "allow users pick their
own ECDSA implementation, hardware or software", then working out what
we need to get us there.


On 08/18/2016 12:23 PM, Nicolas Bacca via bitcoin-dev wrote:
> On Thu, Aug 18, 2016 at 11:49 AM, Jonas Schnelli via bitcoin-dev
>  > wrote:
>
> Hi
>
> > I have some experience with hardware wallet development and its
> > integration and I know it's a mess. But it is too early to
> define such
> > rigid standards yet. Also, TREZOR concept (device as a server
> and the
> > primary source of workflow management) goes directly against your
> > proposal of wallet software as an workflow manager. So it is
> clear NACK
> > for me.
>
> The current question – as already mentioned – is we ACK to work
> together
> on a signing protocol or if we NACK this before we even have started.
>
>
> ACK for Ledger. What's necessary to sign a transaction is well known,
> I don't see how driving any hardware wallet from the wallet itself or
> from a third party daemon implementing that URL scheme would make any
> difference, other than providing better devices interoperability, as
> well as easier maintenance and update paths for the wallets.
>
> -- 
> Nicolas Bacca | CTO, Ledger
>
>
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev



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

Re: [bitcoin-dev] BIP Status updates (including to Active/Final Status) - BIP 39, BIP 43, BIP 44, BIP 67, BIP 111, BIP 125, BIP 130

[Jochen Hoenicke via bitcoin-dev]

On 24.08.2016 16:18, Jonas Schnelli via bitcoin-dev wrote:
> 
> Another thing that I think could be a BIP misdesign:
> 
> BIP44 Gap Limits
> From the BIP:
> 
> --
>   "Address gap limit is currently set to 20. If the software hits 20
> unused addresses in a row, it expects there are no used addresses beyond
> this point and stops searching the address chain."
> --
> 
> * Does that mean, we do a transaction rescan back to the genesis block
> for every 20 addresses?

As I understand it, you can scan sequentially starting with the genesis
block (or with a block at around the time when BIP44 was written).  Then
if you find a new transaction, which requires to generate new addresses,
you generate them and scan further from that point on.  This way you can
scan in a single pass if the scanning process calls you back when it
finds a transaction and allows you to change the set of addresses on the
fly.

  Jochen

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

Re: [bitcoin-dev] BIP Status updates (including to Active/Final Status) - BIP 39, BIP 43, BIP 44, BIP 67, BIP 111, BIP 125, BIP 130

[Jonas Schnelli via bitcoin-dev]

Hi

> 6 - Finally, and most importantly, BIP39 seed phrases do not have a
> version number. Without a version number, how are you going to derive
> addresses from a BIP39 seed phrase, when wallets start to use to new
> derivation methods (such as SegWit, or Schnorr signatures)? Does it mean
> that a BIP39 compatible wallet will have to check addresses from all the
> derivation methods that ever existed in the past, in order to ensure
> that all coins are correctly retrieved? Or will there be users that
> cannot access their coins because their BIP39 seed phrase is too old for
> newer software?

I totally agree with Thomas.

Another thing that I think could be a BIP misdesign:

BIP44 Gap Limits
From the BIP:

--
  "Address gap limit is currently set to 20. If the software hits 20
unused addresses in a row, it expects there are no used addresses beyond
this point and stops searching the address chain."
--

* Does that mean, we do a transaction rescan back to the genesis block
for every 20 addresses?
* Or is it a prerequirement to do a wallet recovery after BIP44's to
have access to a full address-indexed blockchain?

Or maybe I'm missing something.





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

Re: [bitcoin-dev] BIP Status updates (including to Active/Final Status) - BIP 39, BIP 43, BIP 44, BIP 67, BIP 111, BIP 125, BIP 130

[Andreas Schildbach via bitcoin-dev]

FWIW, BIP44 also doesn't encode a seed birthday. This needed so that SPV
wallets do not need to scan from the beginning of the blockchain.

That doesn't mean BIP44 could not be final. There are some wallets that
interoperate on that standard and that's fine. The whole reason I
insisted on separating BIP43 from BIP44 is that someone else can come up
with a better "BIP44+" standard and not get into the way of existing
standards. I think BIP43 should be made final as well, if it isn't already.


On 08/24/2016 02:51 PM, Thomas Voegtlin via bitcoin-dev wrote:
> Le 23/08/2016 à 22:12, Luke Dashjr via bitcoin-dev a écrit :
>> BIP 39: Mnemonic code for generating deterministic keys
>> - Used by many wallets and hundreds of thousands of users.
>>
>> BIP 44: Multi-Account Hierarchy for Deterministic Wallets
>> - Appears to be implemented by multiple wallets.
>>
> 
> I personally believe that BIP39/BIP44 is a bad design. There is limited
> support for these BIPs in Electrum, in order to provide compatibility
> with hardware wallets. However, I do not plan to use BIP39/BIP44 for
> default Electrum wallets, for the following reasons.
> 
> (Note that it does not make sense to consider BIP39 and BIP44
> independently. Any wallet that decides to implement one without the
> other would be considered as broken.)
> 
> Here is why I rejected this design:
> 
> 1 - BIP44 uses multiple accounts. This means that in order to be
> compatible with the standard, a wallet *must* implement multiple
> accounts. A wallet that decides to keep things simple and use only one
> account, will not allow users to recover all their funds when they
> restore from a BIP39 seed, and will be considered as broken.
> 
> 2 - An appealing feature of deterministic wallets is that you can use
> the same instance of your wallet on different devices. Two instances of
> your wallet can automatically synchronize their Bitcoin addresses, and
> display the same balance. The problem is that hardened derivations break
> this property. Indeed, with hardened derivations, software wallets need
> to ask the user's password in order to derive new accounts. Therefore,
> in order to implement automated detection of newly created accounts, a
> BIP44-compatible software wallets would need to ask the user's password
> whenever a new account is detected. This means that the wallet would ask
> the password without the user initiating any action. This seems to be an
> avenue for malware.
> 
> Of course, hardware wallets do not have that issue, because they can
> derive new accounts without requesting a password from the user. BIP44
> is a standard that has been designed for hardware wallets, but that
> makes things really difficult for software wallets.
> 
> 3 - Unneeded complexity. From an end user perspective, the multiple
> accounts in BIP44 achieve the same result as using different derivation
> passphrases with the same BIP39 seed phrase. The only real difference is
> that BIP44 accounts can be enumerated deterministically, while
> passphrases in general cannot. However, this property is of limited
> interest, because automatic synchronization of multiple accounts cannot
> be guaranteed for bip44 software wallets, as explained in 2.
> 
> 4 - BIP39 is inconsistent. It uses a hash of the utf8 encoded 'seed
> phrase' in order to derive the BIP32 seed. This hash-based derivation
> was added on my suggestion, in order to make the BIP independent from
> the particular wordlist used to generate the seed phrases. However,
> BIP39 also requires the implementation of a checksum, in order to verify
> that a seed phrase is valid. Suprisingly, the specification of the
> checksum involves wordlist indices. This means the checksum (and thus
> the BIP) requires a fixed wordlist. This defeats the purpose of using a
> hash for the derivation of the seed.
> 
> The authors of the BIP should either have used hash functions for both
> the seed AND the checksum (that is what Electrum does), or for none of
> them (in that case case, you can have a bidirectional function between
> seed phrases and entropy, which is nice if you want to perform Shamir
> secret sharing of seed phrases, at the expenses of a fixed wordlist). In
> its current state, BIP39 takes the worst of both worlds.
> 
> 5 - The fact that the wordlist must be part of BIP39, and cannot be
> changed in the future, seems a terrible idea to me. I believe that a
> specification should always try to be minimal. In that case, the
> specification includes a 2000+ words dictionary, when it could have
> avoided that.
> 
> Even if you decide that BIP39 is final, there will always be users
> requiring the addition of wordlists for new languages. So, in practice,
> this BIP will never be final.
> 
> 6 - Finally, and most importantly, BIP39 seed phrases do not have a
> version number. Without a version number, how are you going to derive
> addresses from a BIP39 seed phrase, when wallets start to use to new
> derivation methods (such as 

Re: [bitcoin-dev] BIP Status updates (including to Active/Final Status) - BIP 39, BIP 43, BIP 44, BIP 67, BIP 111, BIP 125, BIP 130

[Thomas Voegtlin via bitcoin-dev]

Le 23/08/2016 à 22:12, Luke Dashjr via bitcoin-dev a écrit :
> BIP 39: Mnemonic code for generating deterministic keys
> - Used by many wallets and hundreds of thousands of users.
> 
> BIP 44: Multi-Account Hierarchy for Deterministic Wallets
> - Appears to be implemented by multiple wallets.
> 

I personally believe that BIP39/BIP44 is a bad design. There is limited
support for these BIPs in Electrum, in order to provide compatibility
with hardware wallets. However, I do not plan to use BIP39/BIP44 for
default Electrum wallets, for the following reasons.

(Note that it does not make sense to consider BIP39 and BIP44
independently. Any wallet that decides to implement one without the
other would be considered as broken.)

Here is why I rejected this design:

1 - BIP44 uses multiple accounts. This means that in order to be
compatible with the standard, a wallet *must* implement multiple
accounts. A wallet that decides to keep things simple and use only one
account, will not allow users to recover all their funds when they
restore from a BIP39 seed, and will be considered as broken.

2 - An appealing feature of deterministic wallets is that you can use
the same instance of your wallet on different devices. Two instances of
your wallet can automatically synchronize their Bitcoin addresses, and
display the same balance. The problem is that hardened derivations break
this property. Indeed, with hardened derivations, software wallets need
to ask the user's password in order to derive new accounts. Therefore,
in order to implement automated detection of newly created accounts, a
BIP44-compatible software wallets would need to ask the user's password
whenever a new account is detected. This means that the wallet would ask
the password without the user initiating any action. This seems to be an
avenue for malware.

Of course, hardware wallets do not have that issue, because they can
derive new accounts without requesting a password from the user. BIP44
is a standard that has been designed for hardware wallets, but that
makes things really difficult for software wallets.

3 - Unneeded complexity. From an end user perspective, the multiple
accounts in BIP44 achieve the same result as using different derivation
passphrases with the same BIP39 seed phrase. The only real difference is
that BIP44 accounts can be enumerated deterministically, while
passphrases in general cannot. However, this property is of limited
interest, because automatic synchronization of multiple accounts cannot
be guaranteed for bip44 software wallets, as explained in 2.

4 - BIP39 is inconsistent. It uses a hash of the utf8 encoded 'seed
phrase' in order to derive the BIP32 seed. This hash-based derivation
was added on my suggestion, in order to make the BIP independent from
the particular wordlist used to generate the seed phrases. However,
BIP39 also requires the implementation of a checksum, in order to verify
that a seed phrase is valid. Suprisingly, the specification of the
checksum involves wordlist indices. This means the checksum (and thus
the BIP) requires a fixed wordlist. This defeats the purpose of using a
hash for the derivation of the seed.

The authors of the BIP should either have used hash functions for both
the seed AND the checksum (that is what Electrum does), or for none of
them (in that case case, you can have a bidirectional function between
seed phrases and entropy, which is nice if you want to perform Shamir
secret sharing of seed phrases, at the expenses of a fixed wordlist). In
its current state, BIP39 takes the worst of both worlds.

5 - The fact that the wordlist must be part of BIP39, and cannot be
changed in the future, seems a terrible idea to me. I believe that a
specification should always try to be minimal. In that case, the
specification includes a 2000+ words dictionary, when it could have
avoided that.

Even if you decide that BIP39 is final, there will always be users
requiring the addition of wordlists for new languages. So, in practice,
this BIP will never be final.

6 - Finally, and most importantly, BIP39 seed phrases do not have a
version number. Without a version number, how are you going to derive
addresses from a BIP39 seed phrase, when wallets start to use to new
derivation methods (such as SegWit, or Schnorr signatures)? Does it mean
that a BIP39 compatible wallet will have to check addresses from all the
derivation methods that ever existed in the past, in order to ensure
that all coins are correctly retrieved? Or will there be users that
cannot access their coins because their BIP39 seed phrase is too old for
newer software?



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

Re: [bitcoin-dev] BIP Status updates (including to Active/Final Status) - BIP 39, BIP 43, BIP 44, BIP 67, BIP 111, BIP 125, BIP 130

[Gregory Maxwell via bitcoin-dev]

On Tue, Aug 23, 2016 at 8:54 PM, Kenneth Heutmaker via bitcoin-dev
 wrote:
> SPV is kinda broken if the wallet doesn’t do this detection. If your wallet 
> connects only to nodes that don’t support bloom filtering, the wallet never 
> gets updates. We have had a spike in users reporting that their wallet isn't 
> getting updated. To compound the problem, they rescan the blockchain and lose 
> all of their transaction history. It has caused much panic among less 
> technical users.
>
> We believe that failing to detect the NODE_BLOOM bit is the culprit, although 
> it is non-deterministic, so we aren't certain.

There are almost no NODE_BLOOM supporting bloom-off nodes on the
network currently. So, while supporting this is important, I am
doubtful that its the current problem you've suffered.

There are a great many fake nodes which appear to exist purely to
monitor transactions. Many do not implement enough of the protocol to
support scanning or transaction relay. (and, in fact, relaying
transactions would make monitoring less effective).

You can't count on peers on a peer to peer network to be honest and
cooperative. Implementations need to work hard to be robust to abusive
peers. Unfortunately, the design of the bloom filtering is such that
it isn't always easy (or even possible) to be robust.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP Status updates (including to Active/Final Status) - BIP 39, BIP 43, BIP 44, BIP 67, BIP 111, BIP 125, BIP 130

[Jonas Schnelli via bitcoin-dev]

>> Additionally, BIP 111 (NODE_BLOOM service bit) has been implemented in 
>> Bitcoin
>> Core and derivatives; it is unclear if used by clients yet. Can developers of
>> such clients please comment and let me know: 1) if their software supports
>> this BIP already; 2) if not, do they intend to support it in the future?
>> If and only if there are any clients using this service bit already, I will
>> update BIP 111 to Final Status in 2 weeks also.
> 
> Multibit is adding detection of the NODE_BLOOM bit in the next 2-3 weeks.
> 
> SPV is kinda broken if the wallet doesn’t do this detection. If your wallet 
> connects only to nodes that don’t support bloom filtering, the wallet never 
> gets updates. We have had a spike in users reporting that their wallet isn't 
> getting updated. To compound the problem, they rescan the blockchain and lose 
> all of their transaction history. It has caused much panic among less 
> technical users.
> 
> We believe that failing to detect the NODE_BLOOM bit is the culprit, although 
> it is non-deterministic, so we aren't certain.
> 
> I imagine that other SPV wallets are having similar issues. BIP 111 really 
> isn’t optional at this point, so it should be marked final.

SPV Wallets should definitively update to respect NODE_BLOOM. Bloom
filtering is CPU and disk intense and some node operators have disabled
it (or will disabled it) because there is no direct p2p network-health
benefit.

SPV wallets should probably also make use of the new DNS seeder filter
option.
It is running at least on seed.bitcoin.sipa.be and
seed.bitcoin.jonasschnelli.ch.

The filter option allows SPV Wallets to only get nodes that signal
support for NODE_BLOOM.

The syntax is

   x.seed.bitcoin

Example for NODE_NETWORK together with NODE_BLOOM
dig x5.seed.bitcoin.jonasschnelli.ch
(NETWORK = (1 << 0), NODE_BLOOM = (1 << 2)) = (bin0101 = (int)5)






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