Re: [Bitcoin-development] Tree-chains preliminary summary

2014-03-26 Thread Peter Todd
On Tue, Mar 25, 2014 at 08:40:40PM +, Ricardo Filipe wrote:
 2014-03-25 13:49 GMT+00:00 Peter Todd p...@petertodd.org:
  On Tue, Mar 25, 2014 at 08:45:00AM -0400, Gavin Andresen wrote:
  On Tue, Mar 25, 2014 at 8:28 AM, Peter Todd p...@petertodd.org wrote:
 
   Bitcoin doesn't scale. There's a lot of issues at hand here, but the
   most fundemental of them is that to create a block you need to update
   the state of the UTXO set, and the way Bitcoin is designed means that
   updating that state requires bandwidth equal to all the transaction
   volume to keep up with the changes to what set. Long story short, we get
   O(n^2) scaling, which is just plain infeasible.
  
 
  We have a fundamental disagreement here.
 
  If you go back and read Satoshi's original thoughts on scaling, it is clear
  that he imagined tens of thousands of mining nodes and hundreds of millions
  of lightweight SPV users.
 
  Yeah, about that...
 
  https://blockchain.info/pools
 
 
 On-topic:
 This argument is quite the fallacy. The only reason we have that few
 pools is because each of their miners doesn't find it feasible to mine
 on their own. if you count the individual miners on those pools you
 will get to the scale Gavin was trying to point out.

Yeah, that's part of my fundemental disagreement with him: I draw a
sharp line between mining - the act of validating and constructing new
blocks - and hashing - the act of solving proof-of-work problems. The
latter definitely has incentives to decentralize due to simple physics:
it's cheaper per unit hashing power to get rid of a small amount of
waste heat than a large amount. The former requires a full node, and
that full node is a fixed cost overhead related to the number of
transactions per second. Any fixed cost overhead discourages
decentralization, and encourages centralization.

 Nevertheless i think that is just a minor disagreement, since tree
 chains help decentralization.

Yup. Quite importantly, the model is for any one miner to be able to
fully participate at the same level as any other miner by mining some
section of the tree. As your reward is linked to blocks mined, there
will always be some level at which you are mining blocks at a reasonably
low variance and you don't need to join a pool to achieve that low
varience. Equally your resources to keep up with that part of the tree
can be made reasonably low, and that cost only grows at the log of the
total transaction volume.

-- 
'peter'[:-1]@petertodd.org
f4f5ba334791a4102917e4d3f22f6ad7f2c4f15d97307fe2


signature.asc
Description: Digital signature
--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Sudden temporary drop in reachable nodes?

2014-03-26 Thread Mike Hearn
Hey Addy,

I am seeing a big drop in reachable nodes on
http://getaddr.bitnodes.io/dashboard/ starting from about March 25th 7:20pm
and coming back 9:35pm. Is this a glitch in the monitoring system or did
some real network event happen then?
--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Sudden temporary drop in reachable nodes?

2014-03-26 Thread Addy Yeow
Hi Mike,

That was because I had to restart the crawler for update. This disconnects
the crawler from all reachable nodes temporarily and it will take about 15
minutes (3 snapshots) before the crawler stabilize again. I will look into
annotating these drops with a note.

Cheers,
Addy


On Thu, Mar 27, 2014 at 12:07 AM, Mike Hearn m...@plan99.net wrote:

 Hey Addy,

 I am seeing a big drop in reachable nodes on
 http://getaddr.bitnodes.io/dashboard/ starting from about March 25th
 7:20pm and coming back 9:35pm. Is this a glitch in the monitoring system or
 did some real network event happen then?

--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] New BIP32 structure

2014-03-26 Thread Mike Hearn
Myself, Thomas V (Electrum) and Marek (Trezor) got together to make sure
our BIP32 wallet structures would be compatible - and I discovered that
only I was planning to use the default structure.

Because I'm hopeful that we can get a lot of interoperability between
wallets with regards to importing 12-words paper wallets, we brainstormed
to find a structure acceptable to everyone and ended up with:

  /m/cointype/reserved'/account'/change/n

The extra levels require some explanation:

   - cointype:  This is zero for Bitcoin. This is here to support two
   things, one is supporting alt coins based off the same root seed. Right now
   nobody seemed very bothered about alt coins but sometimes feature requests
   do come in for this. Arguably there is no need and alt coins could just use
   the same keys as Bitcoin, but it may help avoid confusion if they don't.

   More usefully, cointype can distinguish between keys intended for things
   like multisig outputs, e.g. for watchdog services. This means if your
   wallet does not know about the extra protocol layers involved in this, it
   can still import the raw money and it will just ignore/not see the keys
   used in more complex transactions.

   - reserved is for other stuff. I actually don't recall why we ended up
   with this. It may have been intended to split out multisig outputs etc from
   cointype. Marek, Thomas?

   - account is for keeping essentially wallets-within-a-wallet to avoid
   mixing of coins. If you want that.

   - change is 0 for receiving addresses, 1 for change addresses.

   - n is the actual key index

For bitcoinj we're targeting a deliberately limited feature set for hdw v1
so I would just set the first three values all to zero and that is a
perfectly fine way to be compatible.

The goal here is that the same seed can be written down once, and meet all
the users needs, whilst still allowing some drift between what wallets
support.

Pieter made the I think valid point that you can't really encode how keys
are meant to be used into just an HDW hierarchy and normally you'd need
some metadata as well. However, I feel interop between wallets is more
important than arriving at the most perfect possible arrangement, which
feels a little like bikeshedding, so I'm happy to just go with the flow on
this one.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

2014-03-26 Thread Roy Badami
On Fri, Mar 21, 2014 at 12:02:44AM +0100, Mike Hearn wrote:
 
  It's not unusual, in a face-to-face transaction at a bricks-and-mortar
  establishment, that you know neither the legal name of the entity
  running the establishment
 
 
 I'd hope that people can get certs for their actual business name, but
 sometimes it does differ yes.

The actual example I was thinking of is that of traditional British
pubs.  Often a company will own several pubs - however the pubs
themselves will typically have individual traditional pub names.  The
name of the company might not be at all prominently advertised in the
pubs.

Traders at music festivals are another example that comes to mind (they
often accept credit cards if they sell higher value items so why not
Bitcoin?)  In this example there often are no clearly advertised
business names - at least, that the customer will be aware of.

roy

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

2014-03-26 Thread Mike Hearn
Yeah, for those cases we'd need to think of something else. That gets into
the realm of creating our own infrastructure though ...
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

2014-03-26 Thread Andreas Schildbach
But these cases are the norm, rather than the exception. Of all these
places I spend my money at during the day I hardly ever know their
official name. I'm thinking in terms of bakery, indian restaurant or
snack vending machine.

In Germany usually businesses are named like the people that run it.
That usually just one or two random family names plus the legal form of
the company.


On 03/26/2014 11:56 PM, Mike Hearn wrote:
 Yeah, for those cases we'd need to think of something else. That gets
 into the realm of creating our own infrastructure though ...
 
 
 --
 
 
 
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development
 



--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] New BIP32 structure

2014-03-26 Thread Andreas Schildbach
Thanks for starting the discussion on finding a better structure.

For me, the most important thing is either we're 100% interoperable or
0%. There should not be anything inbetween, as users will delete seeds
without knowing there is still money in them on another implementation.
I heard from multiple sources that using this standard some wallets will
only see a subset of the addresses/keys of some other wallets.
Implementation differences can always happen (and should addresses as
bugs), but I think its unacceptable that this source of issues is by design.

I suggest we agree on an even simpler least common denominator and
wallets that want to implement some feature on top of that can do but
are encouraged to pick a totally different cointype. I guess that
would mean removing reserved and account.

I'm still thinking it might be a good idea to have a separate chain for
refunds. Refunds will be rarely used and thus need a much slower
moving window than receiving addresses or change.


On 03/26/2014 09:49 PM, Mike Hearn wrote:
 Myself, Thomas V (Electrum) and Marek (Trezor) got together to make sure
 our BIP32 wallet structures would be compatible - and I discovered that
 only I was planning to use the default structure.
 
 Because I'm hopeful that we can get a lot of interoperability between
 wallets with regards to importing 12-words paper wallets, we
 brainstormed to find a structure acceptable to everyone and ended up with:
 
   /m/cointype/reserved'/account'/change/n
 
 The extra levels require some explanation:
 
   * cointype:  This is zero for Bitcoin. This is here to support two
 things, one is supporting alt coins based off the same root seed.
 Right now nobody seemed very bothered about alt coins but sometimes
 feature requests do come in for this. Arguably there is no need and
 alt coins could just use the same keys as Bitcoin, but it may help
 avoid confusion if they don't.
 
 More usefully, cointype can distinguish between keys intended for
 things like multisig outputs, e.g. for watchdog services. This means
 if your wallet does not know about the extra protocol layers
 involved in this, it can still import the raw money and it will
 just ignore/not see the keys used in more complex transactions.
 
   * reserved is for other stuff. I actually don't recall why we ended
 up with this. It may have been intended to split out multisig
 outputs etc from cointype. Marek, Thomas?
 
   * account is for keeping essentially wallets-within-a-wallet to avoid
 mixing of coins. If you want that.
 
   * change is 0 for receiving addresses, 1 for change addresses.
 
   * n is the actual key index
 
 For bitcoinj we're targeting a deliberately limited feature set for hdw
 v1 so I would just set the first three values all to zero and that is a
 perfectly fine way to be compatible.
 
 The goal here is that the same seed can be written down once, and meet
 all the users needs, whilst still allowing some drift between what
 wallets support.
 
 Pieter made the I think valid point that you can't really encode how
 keys are meant to be used into just an HDW hierarchy and normally you'd
 need some metadata as well. However, I feel interop between wallets is
 more important than arriving at the most perfect possible arrangement,
 which feels a little like bikeshedding, so I'm happy to just go with the
 flow on this one.
 
 
 
 --
 
 
 
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development
 



--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] New BIP32 structure

2014-03-26 Thread Alan Reiner
This might be tangential, but the comment about refund chains reminded
me.  Armory will be implementing multi-sig/linked wallets where a each
device has a parallel HDW branch and produces P2SH addresses.  For those
types of wallets, I plan to allocate two chains /per signing
authority/.  If you have a shared 2-of-2 wallet split between your phone
and your spouse's phone, your phone would distribute addresses on P2SH
chain 0 and generate change addresses on P2SH chain 1.  Your spouse's
phone would use chains 2 and 3.

So if you and your spouse switch to a new app that supports M-of-N
linked wallets, it should search for coin history along the first 2*N
chains.
-Alan



On 03/26/2014 07:37 PM, Andreas Schildbach wrote:
 Thanks for starting the discussion on finding a better structure.

 For me, the most important thing is either we're 100% interoperable or
 0%. There should not be anything inbetween, as users will delete seeds
 without knowing there is still money in them on another implementation.
 I heard from multiple sources that using this standard some wallets will
 only see a subset of the addresses/keys of some other wallets.
 Implementation differences can always happen (and should addresses as
 bugs), but I think its unacceptable that this source of issues is by design.

 I suggest we agree on an even simpler least common denominator and
 wallets that want to implement some feature on top of that can do but
 are encouraged to pick a totally different cointype. I guess that
 would mean removing reserved and account.

 I'm still thinking it might be a good idea to have a separate chain for
 refunds. Refunds will be rarely used and thus need a much slower
 moving window than receiving addresses or change.


 On 03/26/2014 09:49 PM, Mike Hearn wrote:
 Myself, Thomas V (Electrum) and Marek (Trezor) got together to make sure
 our BIP32 wallet structures would be compatible - and I discovered that
 only I was planning to use the default structure.

 Because I'm hopeful that we can get a lot of interoperability between
 wallets with regards to importing 12-words paper wallets, we
 brainstormed to find a structure acceptable to everyone and ended up with:

   /m/cointype/reserved'/account'/change/n

 The extra levels require some explanation:

   * cointype:  This is zero for Bitcoin. This is here to support two
 things, one is supporting alt coins based off the same root seed.
 Right now nobody seemed very bothered about alt coins but sometimes
 feature requests do come in for this. Arguably there is no need and
 alt coins could just use the same keys as Bitcoin, but it may help
 avoid confusion if they don't.

 More usefully, cointype can distinguish between keys intended for
 things like multisig outputs, e.g. for watchdog services. This means
 if your wallet does not know about the extra protocol layers
 involved in this, it can still import the raw money and it will
 just ignore/not see the keys used in more complex transactions.

   * reserved is for other stuff. I actually don't recall why we ended
 up with this. It may have been intended to split out multisig
 outputs etc from cointype. Marek, Thomas?

   * account is for keeping essentially wallets-within-a-wallet to avoid
 mixing of coins. If you want that.

   * change is 0 for receiving addresses, 1 for change addresses.

   * n is the actual key index

 For bitcoinj we're targeting a deliberately limited feature set for hdw
 v1 so I would just set the first three values all to zero and that is a
 perfectly fine way to be compatible.

 The goal here is that the same seed can be written down once, and meet
 all the users needs, whilst still allowing some drift between what
 wallets support.

 Pieter made the I think valid point that you can't really encode how
 keys are meant to be used into just an HDW hierarchy and normally you'd
 need some metadata as well. However, I feel interop between wallets is
 more important than arriving at the most perfect possible arrangement,
 which feels a little like bikeshedding, so I'm happy to just go with the
 flow on this one.



 --



 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development



 --
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] New BIP32 structure

2014-03-26 Thread Allen Piscitello
For every branch (say multiple accounts), how would a new wallet be able to
know how many sequence items to scan?  It seems like not only do you need
to have standard rules for the hierarchy, but how the usage can be
detected.  The other scanning seems pretty straightforward.  For accounts,
it seems like you could have a situation where you want to initially set up
10 different accounts, but only account #10 gets any transactions.  If a
new wallet was trying to scan with this seed, it would have to know to keep
scanning each account until it found the account.  The user would have to
be responsible for knowing how many accounts there are, or some rules would
need to be in place to not allow creating accounts until earlier accounts
can be proven to have existed in the blockchain.  Or I am missing something.

-Allen

On Wed, Mar 26, 2014 at 3:49 PM, Mike Hearn m...@plan99.net wrote:

 Myself, Thomas V (Electrum) and Marek (Trezor) got together to make sure
 our BIP32 wallet structures would be compatible - and I discovered that
 only I was planning to use the default structure.

 Because I'm hopeful that we can get a lot of interoperability between
 wallets with regards to importing 12-words paper wallets, we brainstormed
 to find a structure acceptable to everyone and ended up with:

   /m/cointype/reserved'/account'/change/n

 The extra levels require some explanation:

- cointype:  This is zero for Bitcoin. This is here to support two
things, one is supporting alt coins based off the same root seed. Right now
nobody seemed very bothered about alt coins but sometimes feature requests
do come in for this. Arguably there is no need and alt coins could just use
the same keys as Bitcoin, but it may help avoid confusion if they don't.

More usefully, cointype can distinguish between keys intended for
things like multisig outputs, e.g. for watchdog services. This means if
your wallet does not know about the extra protocol layers involved in this,
it can still import the raw money and it will just ignore/not see the
keys used in more complex transactions.

- reserved is for other stuff. I actually don't recall why we ended
up with this. It may have been intended to split out multisig outputs etc
from cointype. Marek, Thomas?

- account is for keeping essentially wallets-within-a-wallet to avoid
mixing of coins. If you want that.

- change is 0 for receiving addresses, 1 for change addresses.

- n is the actual key index

 For bitcoinj we're targeting a deliberately limited feature set for hdw v1
 so I would just set the first three values all to zero and that is a
 perfectly fine way to be compatible.

 The goal here is that the same seed can be written down once, and meet all
 the users needs, whilst still allowing some drift between what wallets
 support.

 Pieter made the I think valid point that you can't really encode how keys
 are meant to be used into just an HDW hierarchy and normally you'd need
 some metadata as well. However, I feel interop between wallets is more
 important than arriving at the most perfect possible arrangement, which
 feels a little like bikeshedding, so I'm happy to just go with the flow on
 this one.



 --

 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] New BIP32 structure

2014-03-26 Thread Troy Benjegerdes
On Wed, Mar 26, 2014 at 09:49:39PM +0100, Mike Hearn wrote:
 Myself, Thomas V (Electrum) and Marek (Trezor) got together to make sure
 our BIP32 wallet structures would be compatible - and I discovered that
 only I was planning to use the default structure.
 
 Because I'm hopeful that we can get a lot of interoperability between
 wallets with regards to importing 12-words paper wallets, we brainstormed
 to find a structure acceptable to everyone and ended up with:
 
   /m/cointype/reserved'/account'/change/n
 
 The extra levels require some explanation:
 
- cointype:  This is zero for Bitcoin. This is here to support two
things, one is supporting alt coins based off the same root seed. Right now
nobody seemed very bothered about alt coins but sometimes feature requests
do come in for this. Arguably there is no need and alt coins could just use
the same keys as Bitcoin, but it may help avoid confusion if they don't.

Using the same keys across different altcoins seems like an exceedingly bad 
opsec
practice. Cointype is critical, as well as having a predictable and 
deterministic
mapping of alt coins to Cointype.

What should I be using for Catcoin, for instance? the CAT symbol all the 
exchanges use, or do we set up a 'registry', or some other mechanism?

I'd venture to guess the altcoin market is, or soon will be larger in US
dollar value trade volume than Bitcoin, so *some* of us are quite bothered
by the wailing and gnashing of teeth that occurs on this list at mere thought
of such heresy.


-- 

Troy Benjegerdes 'da hozer'  ho...@hozed.org
7 elements  earth::water::air::fire::mind::spirit::soulgrid.coop

  Never pick a fight with someone who buys ink by the barrel,
 nor try buy a hacker who makes money by the megahash


--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development