Re: [Bitcoin-development] Proposal for extra nonce in block header

2014-10-18 Thread Timo Hanke
Greg,

I'd like to ask you to assign a BIP number to this proposal and open
another round of discussion.

There is now a reference implementation available as pull request #5102
(https://github.com/bitcoin/bitcoin/pull/5102).

It introduces a new version number (3) to properly distinguish the
interpretation of the version number and allow for a clean upgrade
process.

Unittests are included.

The updated BIP draft in .mediawiki format is available here:
https://github.com/BlockheaderNonce2/bitoin/wiki

Thanks,
Timo

On Sun, May 04, 2014 at 05:26:06PM +0200, Mike Hearn wrote:
 Although I agree 32 bits for a version is overkill, I really don't like the
 idea of you simply ignoring the protocol spec to try and reduce your own 
 costs.
 Especially because in future we should make unknown versions a validation 
 rule,
 so we can easily trigger hard forks.
 
 If this change was introduced through a proper process and software was
 properly upgraded to understand the new header format, that'd be one thing.
 Arbitrarily exploiting what is IMHO a missing rule in the rule set to shave a
 bit more profit is something else.
 
 
 On Sun, May 4, 2014 at 5:14 PM, Timo Hanke timo.ha...@web.de wrote:
 
  If changing the structure of the block header, wouldnt you also need to
  increment the version number to 3?
 
 No, in this case I don't think so. Incrementing the version number has
 two purposes:
 
 1. inform old clients that something new is going on
 2. be able to phase out old version numbers and block them once the new
 version number becomes a supermajority.
 
 None of these two is necessary here. Old clients already recognize the
 new block headers as something new because they look like very high
 version numbers to them. And there is no reason to ever phase out blocks
 that have zero in the MSBs of the version.
 
 On Sun, Apr 27, 2014 at 10:17:11AM +0200, Melvin Carvalho wrote:
  On 27 April 2014 09:07, Timo Hanke timo.ha...@web.de wrote:
 
      I'd like to put the following draft of a BIP up for discussion.
 
      Timo
 
      # Abstract
      There are incentives for miners to find cheap, non-standard ways to
      generate new work, which are not necessarily in the best interest of
 the
      protocol.
      In order to reduce these incentives this proposal re-assigns 2 bytes
 from
      the version field of the block header to a new extra nonce field.
      # Copyright
      # Specification
      The block version number field in the block header is reduced in 
 size
 from
      4 to 2 bytes.
      The third and fourth byte in the block header are assigned to the 
 new
 extra
      nonce field inside the block header.
      # Motivation
      The motivation of this proposal is to provide miners with a cheap
      constant-complexity method to create new work that does not require
      altering the transaction tree.
 
      Furthermore, the motivation is to protect the version and timestamp
 fields
      in the block header from abuse.
      # Rationale
      Traditionally, the extra nonce is part of the coinbase field of the
      generation transaction, which is always the very first transaction 
 of
 a
      block.
      After incrementing the extra nonce the minimum amount of work a 
 miner
 has
      to do to re-calculate the block header is a) to hash the coinbase
      transaction and b) to re-calculate the left-most branch of the 
 merkle
 tree
      all the way to the merkle root.
      This is necessary overhead a miner has to do besides hashing the
 block
      header itself.
      We shall call the process that leads to a new block header from the
 same
      transaction set the _pre-hashing_.
 
      First it should be noted that the relative cost of pre-hashing in 
 its
      traditional form depends
      on the block size, which may create an unwanted incentive for miners
      to keep the block size small. However, this is not the main
 motivation for
      the current proposal.
 
      While the block header is hashed by ASICs, pre-hashing typically
 happens on
      a CPU because of the greater flexibility required.
      Consequently, as ASIC cost per hash performance drops the relative
 cost of
      pre-hashing increases.
 
      This creates an incentive for miners to find cheaper ways to create
 new
      work than by means of pre-hashing.
      An example of this currently happening is the on-device rolling of
 the
      timestamp into the future.
      These ways of creating new work are unlikely to be in the best
 interest of
      the protocol.
      For example, rolling the timestamp faster than the real time is
 unwanted
      (more so

Re: [Bitcoin-development] Proposal for extra nonce in block header

2014-05-04 Thread Timo Hanke
 If changing the structure of the block header, wouldnt you also need to
 increment the version number to 3?

No, in this case I don't think so. Incrementing the version number has
two purposes:

1. inform old clients that something new is going on
2. be able to phase out old version numbers and block them once the new
version number becomes a supermajority.

None of these two is necessary here. Old clients already recognize the
new block headers as something new because they look like very high
version numbers to them. And there is no reason to ever phase out blocks
that have zero in the MSBs of the version.

On Sun, Apr 27, 2014 at 10:17:11AM +0200, Melvin Carvalho wrote:
 On 27 April 2014 09:07, Timo Hanke timo.ha...@web.de wrote:
 
 I'd like to put the following draft of a BIP up for discussion.
 
 Timo
 
 # Abstract
 There are incentives for miners to find cheap, non-standard ways to
 generate new work, which are not necessarily in the best interest of the
 protocol.
 In order to reduce these incentives this proposal re-assigns 2 bytes from
 the version field of the block header to a new extra nonce field.
 # Copyright
 # Specification
 The block version number field in the block header is reduced in size from
 4 to 2 bytes.
 The third and fourth byte in the block header are assigned to the new 
 extra
 nonce field inside the block header.
 # Motivation
 The motivation of this proposal is to provide miners with a cheap
 constant-complexity method to create new work that does not require
 altering the transaction tree.
 
 Furthermore, the motivation is to protect the version and timestamp fields
 in the block header from abuse.
 # Rationale
 Traditionally, the extra nonce is part of the coinbase field of the
 generation transaction, which is always the very first transaction of a
 block.
 After incrementing the extra nonce the minimum amount of work a miner has
 to do to re-calculate the block header is a) to hash the coinbase
 transaction and b) to re-calculate the left-most branch of the merkle tree
 all the way to the merkle root.
 This is necessary overhead a miner has to do besides hashing the block
 header itself.
 We shall call the process that leads to a new block header from the same
 transaction set the _pre-hashing_.
 
 First it should be noted that the relative cost of pre-hashing in its
 traditional form depends
 on the block size, which may create an unwanted incentive for miners
 to keep the block size small. However, this is not the main motivation for
 the current proposal.
 
 While the block header is hashed by ASICs, pre-hashing typically happens 
 on
 a CPU because of the greater flexibility required.
 Consequently, as ASIC cost per hash performance drops the relative cost of
 pre-hashing increases.
 
 This creates an incentive for miners to find cheaper ways to create new
 work than by means of pre-hashing.
 An example of this currently happening is the on-device rolling of the
 timestamp into the future.
 These ways of creating new work are unlikely to be in the best interest of
 the protocol.
 For example, rolling the timestamp faster than the real time is unwanted
 (more so on faster blockchains).
 
 The version number in the block header is a possible target for alteration
 with the goal of cheaply creating new work.
 Currently, blocks with arbitrarily large version numbers get relayed and
 accepted by the network.
 As this is unwanted behaviour, there should not exist any incentive for a
 miner to abuse the version number in this way.
 
 The solution is to reduce the range of version numbers from 2^32 to 2^16
 and to declare the third and forth bytes of the block header as legitimate
 space for an extra nonce.
 This will reduce the incentive for a miner to abuse the shortened version
 number by a factor in the order of 2^16.
 
 As a side effect, this proposal greatly reduces the bandwidth requirements
 of a blind pool protocol by only submitting the block header to the miner.
 # Backwards Compatibility
 Old versions of the client will accept blocks of this kind but will throw
 an alert at the user to upgrade.
 The only code change would be a cast of the version number to a short.
 Besides the upgrade alert, old and new versions of the client can co-exist
 and there is no need to introduce a new block version number or to
 phase-out old block versions.
 # Reference Implementation
 # Final implementation
 
 
 If changing the structure of the block header, wouldnt you also need to
 increment the version number to 3?

--
Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests

Re: [Bitcoin-development] Proposal for extra nonce in block header

2014-05-04 Thread Timo Hanke
On Sun, Apr 27, 2014 at 02:38:06AM -0700, Mark Friedenbach wrote:
 I'm not convinced of the necessity of this idea in general, but if it
 were to be implemented I would recommend serializing the nVersion field
 as a VarInt (Pieter Wuille's multi-byte serialization format) and using
 the remaining space of the 4 bytes as your extra nonce.
 
 That would allow serialization of numbers up to 0x1020407f (slightly
 over 28 bits) before the 4-byte field is exhausted. For version numbers
 less than 0x204080 there will be at least one byte of padding space left
 over for extra-nonce usage (two bytes if less than 0x4080, three bytes
 if less than 0x80). For version values up to 127, the format is exactly
 identical when the padding bytes are zero.

Neat idea. It might somewhat reduce the flexibility in which the version
field can be used in the future, though. 

For the sake of simplicity I lean towards a fixed length version field,
but would be ok with either. Keep in mind that version numbers can be
recycled after a couple of years. So there is effectively zero benefit
in allowing varints to extend beyond 2 bytes. For that reason personally
I think 1 byte of version number would be enough.

 On 04/27/2014 12:07 AM, Timo Hanke wrote:
  I'd like to put the following draft of a BIP up for discussion.
  
  Timo
  
  # Abstract
  There are incentives for miners to find cheap, non-standard ways to 
  generate new work, which are not necessarily in the best interest of the 
  protocol.
  In order to reduce these incentives this proposal re-assigns 2 bytes from 
  the version field of the block header to a new extra nonce field. 
  # Copyright
  # Specification
  The block version number field in the block header is reduced in size from 
  4 to 2 bytes. 
  The third and fourth byte in the block header are assigned to the new extra 
  nonce field inside the block header.
  # Motivation
  The motivation of this proposal is to provide miners with a cheap 
  constant-complexity method to create new work that does not require 
  altering the transaction tree.
  
  Furthermore, the motivation is to protect the version and timestamp fields 
  in the block header from abuse.
  # Rationale
  Traditionally, the extra nonce is part of the coinbase field of the 
  generation transaction, which is always the very first transaction of a 
  block.
  After incrementing the extra nonce the minimum amount of work a miner has 
  to do to re-calculate the block header is a) to hash the coinbase 
  transaction and b) to re-calculate the left-most branch of the merkle tree 
  all the way to the merkle root.
  This is necessary overhead a miner has to do besides hashing the block 
  header itself.
  We shall call the process that leads to a new block header from the same 
  transaction set the _pre-hashing_.
  
  First it should be noted that the relative cost of pre-hashing in its 
  traditional form depends
  on the block size, which may create an unwanted incentive for miners
  to keep the block size small. However, this is not the main motivation for
  the current proposal.
  
  While the block header is hashed by ASICs, pre-hashing typically happens on 
  a CPU because of the greater flexibility required.
  Consequently, as ASIC cost per hash performance drops the relative cost of 
  pre-hashing increases.
  
  This creates an incentive for miners to find cheaper ways to create new 
  work than by means of pre-hashing.
  An example of this currently happening is the on-device rolling of the 
  timestamp into the future.
  These ways of creating new work are unlikely to be in the best interest of 
  the protocol.
  For example, rolling the timestamp faster than the real time is unwanted 
  (more so on faster blockchains).
  
  The version number in the block header is a possible target for alteration 
  with the goal of cheaply creating new work.
  Currently, blocks with arbitrarily large version numbers get relayed and 
  accepted by the network.
  As this is unwanted behaviour, there should not exist any incentive for a 
  miner to abuse the version number in this way. 
  
  The solution is to reduce the range of version numbers from 2^32 to 2^16 
  and to declare the third and forth bytes of the block header as legitimate 
  space for an extra nonce.
  This will reduce the incentive for a miner to abuse the shortened version 
  number by a factor in the order of 2^16. 
  
  As a side effect, this proposal greatly reduces the bandwidth requirements 
  of a blind pool protocol by only submitting the block header to the miner.
  # Backwards Compatibility
  Old versions of the client will accept blocks of this kind but will throw 
  an alert at the user to upgrade.
  The only code change would be a cast of the version number to a short.
  Besides the upgrade alert, old and new versions of the client can co-exist 
  and there is no need to introduce a new block version number or to 
  phase-out old block versions.
  # Reference

Re: [Bitcoin-development] Proposal for extra nonce in block header

2014-05-04 Thread Timo Hanke
On Sun, May 04, 2014 at 05:26:06PM +0200, Mike Hearn wrote:
 Although I agree 32 bits for a version is overkill, I really don't like the
 idea of you simply ignoring the protocol spec to try and reduce your own 
 costs.

The purpose of the proposal is to change the protocol spec, not to
ignore it.

The argument for the proposal is explained in the Rationale section, and
in abstracted form means precisely to make everybody follow the protocol
spec by reducing incentives to ignore it. Specifically, it is about
protecting the timestamp field. 

I talked about relative costs involved in hashing, and how those will
change, and what incentives that creates. This development cannot be
ignored.

 Especially because in future we should make unknown versions a validation 
 rule,
 so we can easily trigger hard forks.

Why does it require 32 bits?

 If this change was introduced through a proper process and software was
 properly upgraded to understand the new header format, that'd be one thing.
 Arbitrarily exploiting what is IMHO a missing rule in the rule set to shave a
 bit more profit is something else.

Again, this is a BIP. I am proposing a software upgrade, which is
absolutely required. When I said that version 3 is not required I meant
that the software upgrade (which basically just turns the nonce into a
short) does not have to be accompanied by a new version number for any
technical reason. Is there another reason why it should be incremented?

 On Sun, May 4, 2014 at 5:14 PM, Timo Hanke timo.ha...@web.de wrote:
 
  If changing the structure of the block header, wouldnt you also need to
  increment the version number to 3?
 
 No, in this case I don't think so. Incrementing the version number has
 two purposes:
 
 1. inform old clients that something new is going on
 2. be able to phase out old version numbers and block them once the new
 version number becomes a supermajority.
 
 None of these two is necessary here. Old clients already recognize the
 new block headers as something new because they look like very high
 version numbers to them. And there is no reason to ever phase out blocks
 that have zero in the MSBs of the version.
 
 On Sun, Apr 27, 2014 at 10:17:11AM +0200, Melvin Carvalho wrote:
  On 27 April 2014 09:07, Timo Hanke timo.ha...@web.de wrote:
 
      I'd like to put the following draft of a BIP up for discussion.
 
      Timo
 
      # Abstract
      There are incentives for miners to find cheap, non-standard ways to
      generate new work, which are not necessarily in the best interest of
 the
      protocol.
      In order to reduce these incentives this proposal re-assigns 2 bytes
 from
      the version field of the block header to a new extra nonce field.
      # Copyright
      # Specification
      The block version number field in the block header is reduced in 
 size
 from
      4 to 2 bytes.
      The third and fourth byte in the block header are assigned to the 
 new
 extra
      nonce field inside the block header.
      # Motivation
      The motivation of this proposal is to provide miners with a cheap
      constant-complexity method to create new work that does not require
      altering the transaction tree.
 
      Furthermore, the motivation is to protect the version and timestamp
 fields
      in the block header from abuse.
      # Rationale
      Traditionally, the extra nonce is part of the coinbase field of the
      generation transaction, which is always the very first transaction 
 of
 a
      block.
      After incrementing the extra nonce the minimum amount of work a 
 miner
 has
      to do to re-calculate the block header is a) to hash the coinbase
      transaction and b) to re-calculate the left-most branch of the 
 merkle
 tree
      all the way to the merkle root.
      This is necessary overhead a miner has to do besides hashing the
 block
      header itself.
      We shall call the process that leads to a new block header from the
 same
      transaction set the _pre-hashing_.
 
      First it should be noted that the relative cost of pre-hashing in 
 its
      traditional form depends
      on the block size, which may create an unwanted incentive for miners
      to keep the block size small. However, this is not the main
 motivation for
      the current proposal.
 
      While the block header is hashed by ASICs, pre-hashing typically
 happens on
      a CPU because of the greater flexibility required.
      Consequently, as ASIC cost per hash performance drops the relative
 cost of
      pre-hashing increases.
 
      This creates an incentive for miners to find cheaper ways to create
 new
      work than by means of pre-hashing

[Bitcoin-development] Proposal for extra nonce in block header

2014-04-27 Thread Timo Hanke
I'd like to put the following draft of a BIP up for discussion.

Timo

# Abstract
There are incentives for miners to find cheap, non-standard ways to generate 
new work, which are not necessarily in the best interest of the protocol.
In order to reduce these incentives this proposal re-assigns 2 bytes from the 
version field of the block header to a new extra nonce field. 
# Copyright
# Specification
The block version number field in the block header is reduced in size from 4 to 
2 bytes. 
The third and fourth byte in the block header are assigned to the new extra 
nonce field inside the block header.
# Motivation
The motivation of this proposal is to provide miners with a cheap 
constant-complexity method to create new work that does not require altering 
the transaction tree.

Furthermore, the motivation is to protect the version and timestamp fields in 
the block header from abuse.
# Rationale
Traditionally, the extra nonce is part of the coinbase field of the generation 
transaction, which is always the very first transaction of a block.
After incrementing the extra nonce the minimum amount of work a miner has to do 
to re-calculate the block header is a) to hash the coinbase transaction and b) 
to re-calculate the left-most branch of the merkle tree all the way to the 
merkle root.
This is necessary overhead a miner has to do besides hashing the block header 
itself.
We shall call the process that leads to a new block header from the same 
transaction set the _pre-hashing_.

First it should be noted that the relative cost of pre-hashing in its 
traditional form depends
on the block size, which may create an unwanted incentive for miners
to keep the block size small. However, this is not the main motivation for
the current proposal.

While the block header is hashed by ASICs, pre-hashing typically happens on a 
CPU because of the greater flexibility required.
Consequently, as ASIC cost per hash performance drops the relative cost of 
pre-hashing increases.

This creates an incentive for miners to find cheaper ways to create new work 
than by means of pre-hashing.
An example of this currently happening is the on-device rolling of the 
timestamp into the future.
These ways of creating new work are unlikely to be in the best interest of the 
protocol.
For example, rolling the timestamp faster than the real time is unwanted (more 
so on faster blockchains).

The version number in the block header is a possible target for alteration with 
the goal of cheaply creating new work.
Currently, blocks with arbitrarily large version numbers get relayed and 
accepted by the network.
As this is unwanted behaviour, there should not exist any incentive for a miner 
to abuse the version number in this way. 

The solution is to reduce the range of version numbers from 2^32 to 2^16 and to 
declare the third and forth bytes of the block header as legitimate space for 
an extra nonce.
This will reduce the incentive for a miner to abuse the shortened version 
number by a factor in the order of 2^16. 

As a side effect, this proposal greatly reduces the bandwidth requirements of a 
blind pool protocol by only submitting the block header to the miner.
# Backwards Compatibility
Old versions of the client will accept blocks of this kind but will throw an 
alert at the user to upgrade.
The only code change would be a cast of the version number to a short.
Besides the upgrade alert, old and new versions of the client can co-exist and 
there is no need to introduce a new block version number or to phase-out old 
block versions.
# Reference Implementation
# Final implementation

-- 
Timo Hanke
PGP 1EFF 69BC 6FB7 8744 14DB  631D 1BB5 D6E3 AB96 7DA8

--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Proposal to replace BIP0039

2013-11-16 Thread Timo Hanke
On Sun, Nov 17, 2013 at 12:49:04AM +0100, Pavol Rusnak wrote:
 On 03/11/13 08:40, Timo Hanke wrote:
  Trezor picks random s and sends S=s*G to computer, keeping s secret.
 
 That's a really neat trick!
 
  One question remains: if you only write down the mnemonic how can you be
  sure that it is correct and corresponds to the secret in Trezor?
 
 Right. That's a problem. I'm not sure if this whole cryptomagic is
 benefitial at all.
 
 I'd suggest to go the easy way for now, i.e. prove that external entropy
 was used while generating the master seed. If the user does not trust
 our firmware, he can use his own built one.

No, this question of mine was regardless of any cryptomagic or neat
tricks like Thomas' suggestion. It has nothing do with auditing the
entropy. It was just a backup question.

I recently had an experience where I thought coins were lost because the
secrets I had didn't match the public keys that I thought they'd match.
From now on I will always recover my wallet first, from the backed up
secrets, before sending any coins to the pubkeys in the wallet. I will
never again generate a wallet, backup the secrets, and hope the secrets
indeed match the pubkeys.. without testing that. My question was how
Trezor allows me to verify my backup.

All this makes me think if having one device generating and displaying
the secret, and making a backing from the display, is the right way to
go. Since you would need a second device to verify your backup is sane,
you could have two devices to start with. One is your hardware wallet
and it only imports secrets (restores backups). The other is an entropy
generator and it only generates secrets.

Best regards,
Timo

p.s. The question about auditing entropy would only apply to the generator,
not the wallet. Is it yet documented how Trezor proves that external
entropy was used? 

-- 
Timo Hanke
PGP 1EFF 69BC 6FB7 8744 14DB  631D 1BB5 D6E3 AB96 7DA8

--
DreamFactory - Open Source REST  JSON Services for HTML5  Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Proposal to replace BIP0039

2013-11-03 Thread Timo Hanke
I think the communication would have to go the other way around. Trezor
has to commit to a value First. Like this:

Trezor picks random s and sends S=s*G to computer, keeping s secret.
Computer picks random t and sends t to Trezor.  Trezor makes r := s+t
its internal master private key with corresponding master public key 
R := (s+t)*G. Since R = S+t*G, the computer can verify the master
public key. As you say, the computer can then store R and can later
verify for each derived pubkey that it was indeed derived from R, hence
from his own entropy t.

However, Trezor could not use straight bip32 out of the box. The
chaincode would have to be something like SHA(R). And the seed (that
gets translated to mnemonic) would be r itself, making it 256 bit
instead of only 128 bit.

If the longer seed is bearable then this is a good way to do it.

One question remains: if you only write down the mnemonic how can you be
sure that it is correct and corresponds to the secret in Trezor? You
cannot verify that on paper. You would have to restore it on some
device, eg another empty Trezor, and see if it brings up the same master
pubkey. Right? 

Timo

On Sun, Nov 03, 2013 at 08:03:54AM +0100, Thomas Voegtlin wrote:
 
 Le 03/11/2013 07:41, Timo Hanke a écrit :
 No. You mean the computer would use B for this check? (k,K) could
 be rigged by Trezor, who computes b as k-a. Timo
 
 I was just asking a question, in order to understand how this device
 works, and what are its requirements.
 if you think you can help, please explain.
 
 

-- 
Timo Hanke
PGP 1EFF 69BC 6FB7 8744 14DB  631D 1BB5 D6E3 AB96 7DA8

--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk
___
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

2013-06-19 Thread Timo Hanke
 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.
 
 -Alan
 
 
 
 

-- 
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

2013-06-19 Thread Timo Hanke
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] Cold Signing Payment Requests

2013-04-25 Thread Timo Hanke
 So, I'm not a fan of weird hacks involving non-existent domain names.
 There's a clean way to implement this and we decided to punt on it for
 v1 in order to get something shippable, but if you're volunteering ...
 :) then indeed having a custom cert type that chains onto the end is
 the way to go.

Chaining a custom cert onto the end doesn't work, at least not if your
end is the SSL cert. Chaining it to the SSL cert defeats the OP's
intention of cold signing, as the SSL private key is usually kept
online, therefore can't be used to sign a pubkey that is supposed to
stay offline. Hence the idea of the hack, to get two independent
things signed by the CA in just one cert: 1) your SSL pubkey, 2) your
custom cert (by including its cryptograhic hash). This hack seems the
easiest possible solution.

It also seems the only solution if you want to stick with domain-names
as identifiers for the payment protocol (and I think you do). A cleaner
way would be to get a cert signed by your CA that contains an extended
bitcoin attribute in compliance with X.509, but this seems a little
far off.

So I am in favor of the hack (properly thought out where to place the
hash).

ps. In the long run I would of course like to see payee identities based
on alt-chains rather than domain-names plus CAs. But that's rather a
concern for v3 than v2. Of course, you can also chain custom certs to
non-SSL identities like PGP-keys. You probably don't want to do that,
but it would solve Melvin Carvalho's problem of sending to RSA keys
(assuming the RSA key holder previously published his custom cert with a
cert server). 

-- 
Timo Hanke
PGP AB967DA8, Key fingerprint = 1EFF 69BC 6FB7 8744 14DB  631D 1BB5 D6E3 AB96 
7DA8

--
Try New Relic Now  We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app,  servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Cold Signing Payment Requests

2013-04-25 Thread Timo Hanke
On Thu, Apr 25, 2013 at 12:05:06PM +0200, Mike Hearn wrote:
 Chaining a custom cert onto the end doesn't work, at least not if your
 end is the SSL cert. Chaining it to the SSL cert defeats the OP's
 intention of cold signing, as the SSL private key is usually kept
 online, therefore can't be used to sign a pubkey that is supposed to stay 
 offline.
i meant:  ^whose privkey is 
supposed to stay offline.

 the goal of all this is not to protect against web server compromise.

 The goal of this is to allow delegation of signing authority without giving 
 the
 delegate the SSL private key.

This is not how I understand the OP, which I said I was addressing:

 The difficulty is that Payment Requests must be generated live, and
 therefore the key used to sign those requests must also be live,
 exposing the key to theft similar to a hot wallet. Steal the key,
 forge payment requests, and the payer sees a 'green box' but the coins
 go to the attacker. The question... is there a way to sign something
 once, with a key kept offline, which verifies the address in the
 Payment Request belongs to the payee?



 That's a pointless goal to try and solve right now, because the SSL
 PKI cannot handle compromised web servers and so neither can we (with
 v1 of the payments spec).

I don't think the OP intended to solve it right now, i.e. in v1. 

He differentiated between most trusted and less trusted keys
(certs). So he can clearly live with the SSL PKI being less trusted
for his purpose.  

-- 
Timo Hanke
PGP AB967DA8, Key fingerprint = 1EFF 69BC 6FB7 8744 14DB  631D 1BB5 D6E3 AB96 
7DA8

--
Try New Relic Now  We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app,  servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Blockchain as root CA for payment protocol

2013-02-11 Thread Timo Hanke
On Sat, Feb 09, 2013 at 07:01:48PM +, Luke-Jr wrote:
 On Saturday, February 09, 2013 2:33:25 PM Timo Hanke wrote:
  namcoin tries to solve a different problem, DNS, whereas I want
  to establish an identity for a payment protocol.
 
 What is the technical difference here? Namecoin ties names to data; DNS is a 
 specific namespace in it. There is no reason I know of that this identity 
 stuff cannot be a new namespace.

It's not about technical differences, but about the different use or
purpose, which can result in different security demands. I argue that
DNS has a lower demand in this respect than payment ids have. So DNS
data can be in a chain with a hashrate lower than bitcoin's hashrate but
payment ids _for_ bitcoin have to be in a chain with equal hashrate.

  You can argue that alt-chains _can_ be as strong as bitcoin, but they
  don't _have to_ be. There is no guarantee how many people will
  cross-mine.
 
 This is true of namecoin, but it does not have to be true of new merged-mined 
 data. You could very well require the Bitcoin proof-of-work to be valid and 
 the master header to be in the Bitcoin blockchain.

Ok, true. This does the trick. If few miners merge-mine then the new
chain just becomes slower. But is this still an alt-chain? It is not
independently verifiable anymore, like the alt-chains described in the
wiki are. Instead, you need to refer to the bitcoin's chain to see if
the target is correct. Not sure if I got you right on this. But it seems
to be essentially a more efficient version of what I proposed, rather
than a true alt-chain.

I suppose you suggest to place the master header hash into the coinbase.
A drawback may be that it puts miners at a great advantage over regular
users. This could (but doesn't have to) become relevant depending on
your counter-measures against excessive alias registration. I think
Peter addressed this (below). 

On Fri, Feb 08, 2013 at 06:01:08AM -0500, Peter Todd wrote:
 Finally, why is this implemented within the reference client? Use the
 raw transaction API and make up your own database. If you want, create a
 RPC command that allows you to query the UTXO set directly; this would
 be a useful feature to have. This patch will never be accepted to the
 reference client, so you'll just wind up having to maintain a fork. Even
 for a prototype this approach is ill-advised - prototypes have a bad way
 of turning into production code.

This was not intended to be a prototype and will certainly not be
maintained. It is a demo to be run on the testnet to get a feel of how
the user interface (RPC) and the work flow could look like, starting
from the creation of a certificate all the way to paying to a
customer-derived payment addresses (pay-to-contract) when the merchant's
base address is defined in the certificate. There's an appeal to be able
to issue
./bitcoind sendtoalias foo deadbeef 10
and being sure that 10 BTC go, e.g., to a unique P2SH multisig address
that is derived for order number 'deadbeef' from the two pubkeys that
foo defined in his certificate. And having the certificate verification
happen automatically in the background. The demo is in the reference
client a) to simulate this feel, b) because it was the fastest way to
code it. Apart from that, it could have just as well been separate, and
an UTXO query-RPC would certainly be nice.  

Another reason for this demo was the fun of devising a certificate that
can handle all this. 

BTW, I'm sure that some form of certificate handling will find its way
directly into the reference client. The user will want to trust only one
piece of software running on one piece of dedicated hardware. 

On Mon, Feb 11, 2013 at 06:21:03AM -0500, Peter Todd wrote:
 In what way are you not solving the same problem as DNS? I don't mean
 the Luke-Jr's (quite correct) technical point about key-value maps, I
 mean the human problem that I have these unique numbers that I can't
 memorize, and I have some non-unique names that I can.
 
 By creating Yet Another Totally Different System you are just creating
 another way that users can be confused into thinking some name snatched
 up by some scammers in some little-used PKI system is who they are
 supposed to be communicating with. Fortunately your PKI system isn't
 actually used and probably never will be, so it's not a big deal yet,
 but ultimately you are adding to the problem.

What exactly is the problem, the little-used? Otherwise it's the same
as it is now, you pick up an interesting domain name on the street, type
it in, and start communicating with who you think it is, and maybe even
pay them. The EV that centralized PKI offers prevents only some attacks,
and may even create a false sense of security.

 Go work on namecoin and make it more usable. Then add some PKI to it
 using the *same* domain names so when I see a PKI certificate for foo
 I know it must be the same foo website I just visited and the same
 foo@foo I just emailed.

No. I outlined above why I

Re: [Bitcoin-development] Blockchain as root CA for payment protocol

2013-02-09 Thread Timo Hanke
On Fri, Feb 08, 2013 at 06:01:08AM -0500, Peter Todd wrote:
 On Fri, Feb 08, 2013 at 11:03:54AM +0100, Timo Hanke wrote:
  First, we have drafted a quite general specification for bitcoin 
  certificates (protobuf messages) that allow for a variety of payment 
  protocols (e.g. static as well as customer-side-generated payment 
  addresses).
  This part has surely been done elsewhere as well and is orthogonal to the 
  goal of this project.
  What is new here is the signatures _under_ the certificates.
  
  We have patched the bitcoind to handle certificates, submit signatures to 
  the blockchain, verify certificates against the blockchain, pay directly to 
  certificates (with various payment methods), revoke certificates.
  Signatures in the blockchain are stored entirely in the UTXO set (i.e. the 
  unspend, unprunable outputs). 
  This seems to make signature lookup and verification reasonably fast: 
  it took us 10s in the mainnet test we performed (lookup is instant on the 
  testnet, of course).
 
 Why don't you use namecoin or another alt-chain for this?

Because namcoin tries to solve a different problem, DNS, whereas I want
to establish an identity for a payment protocol. Your incoming payments
will land on addresses that are derived (regardless which way) from this
idenity. This makes your identity as important (securitywise) as
anything else involved in the bitcoin protocol. Therefore I would not
want to have payment-ids rely on anything _less_ than bitcoin's own
blockchain. In particular not on PKI with centralized root CAs. But also
not on namecoin or any other (weaker) alt-chains.

You can argue that alt-chains _can_ be as strong as bitcoin, but they
don't _have to_ be. There is no guarantee how many people will
cross-mine. The alt-chain could even disappear at some point. If at some
point your alt-chain is no longer being worked on, then how do you prove
that some old bitcoin transaction went to an address for which there was
a valid id/certificate at the time of sending? If the certificate is
based inside bitcoin's blockchain then you will have a proof for the
correct destinations of all your old transactions as long as bitcoin
exists.

Besides all this, as you mentioned namecoin specifically, that is
overkill if you just want to link two hashes together. A single 2-of-2
multisig output would suffice for that. 

 The UTXO set is the most expensive part of the blockchain because it
 must be stored in memory with fast access times. It's good that you have
 designed the system so that the addresses can be revoked, removing them
 from the UTXO set, but it still will encourage the exact same type of
 ugly squatting behavior we've already seen with first-bits, and again
 it'll have a significant cost to the network going forward for purposes
 that do not need to be done on the block chain.

You are probably right that storing this in the _spent outputs_ would be
better. There doesn't seem to be any type of client out there that would
benefit from having to search UTXO only. 

Timo

--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development