Re: [Bitcoin-development] Bitcoind-in-background mode for SPV wallets

2014-04-10 Thread Tamas Blummer
Hi Wladimir, If the motivation of the SPV wallet is to radically extend functionality, as in my case, then the index is specific to the added features and the subset of the blockchain that is of interest for the wallet. As you also point out, adding huge generic purpose indices to core would

Re: [Bitcoin-development] Bitcoind-in-background mode for SPV wallets

2014-04-10 Thread Mike Hearn
I tend to agree with slush here - counting the IPs in addr broadcasts often gives a number like 100,000 vs just 10,000 for actually reachable nodes (or less). It seems like optimising the NAT tunneling code would help. Starting by adding more diagnostic stuff to the GUI. STUN support may also

Re: [Bitcoin-development] Bitcoind-in-background mode for SPV wallets

2014-04-10 Thread Wladimir
On Thu, Apr 10, 2014 at 8:38 AM, Mike Hearn m...@plan99.net wrote: I tend to agree with slush here - counting the IPs in addr broadcasts often gives a number like 100,000 vs just 10,000 for actually reachable nodes (or less). It seems like optimising the NAT tunneling code would help.

Re: [Bitcoin-development] Bitcoind-in-background mode for SPV wallets

2014-04-10 Thread Mike Hearn
It's an optimisation problem. Home environments are much more hostile than servers are due to things like virus scanners, wildly varying memory pressure as apps are started and shut down, highly asymmetrical upstream versus downstream bandwidth, complicated nat setups, people who only use laptops

Re: [Bitcoin-development] Bitcoind-in-background mode for SPV wallets

2014-04-10 Thread Tamas Blummer
You ask why people would install this ? I find it is odd that we who hold the key to instant machine to machine micro payments do not use it to incentivise committing resources to the network. What about serving archive blocks to peers paying for it ? Tamas Blummer http://bitsofproof.com On

Re: [Bitcoin-development] Bitcoind-in-background mode for SPV wallets

2014-04-10 Thread Mike Hearn
I find it is odd that we who hold the key to instant machine to machine micro payments do not use it to incentivise committing resources to the network. It's not a new idea, obviously, but there are some practical consequences: 1) To pay a node for serving, you have to have bitcoins. To get

Re: [Bitcoin-development] Bitcoind-in-background mode for SPV wallets

2014-04-10 Thread Peter Todd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 But we have to be realistic. Desktop tower machines that are always on are dying and will not be coming back. Not a single person I know uses them anymore, they have been wiped out in favour of laptops. This is why, given the tiny size of the

Re: [Bitcoin-development] Bitcoind-in-background mode for SPV wallets

2014-04-10 Thread Tamas Blummer
I know the idea is not new. Just bringing it up to emphasize that if we don’t use it how could we expect other networks using it. Machine to machine micro payments could become the killer application for Bitcoin. 1) There is no catch 22 as there are plenty of ways getting bitcoin without

Re: [Bitcoin-development] Bitcoind-in-background mode for SPV wallets

2014-04-10 Thread Peter Todd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 10 April 2014 05:17:28 GMT-04:00, Mike Hearn m...@plan99.net wrote: I find it is odd that we who hold the key to instant machine to machine micro payments do not use it to incentivise committing resources to the network. It's not a new

Re: [Bitcoin-development] Bitcoind-in-background mode for SPV wallets

2014-04-10 Thread Mike Hearn
1) There is no catch 22 as there are plenty of ways getting bitcoin without bootstrapping a full node. I think I maybe wasn't clear. To spend coins you need transaction data. Today, the dominant model is that people get that data by scanning the block chain. If you can obtain the transaction

Re: [Bitcoin-development] Bitcoind-in-background mode for SPV wallets

2014-04-10 Thread Tamas Blummer
Thanks, Peter and you convinced me. I run away with a thought. It’d be great to find a spot to deploy payment channels, but I agree this is not it. Tamas Blummer http://bitsofproof.com On 10.04.2014, at 12:40, Mike Hearn m...@plan99.net wrote: 1) There is no catch 22 as there are plenty of

Re: [Bitcoin-development] Bitcoind-in-background mode for SPV wallets

2014-04-10 Thread Wladimir
On Thu, Apr 10, 2014 at 8:04 AM, Tamas Blummer ta...@bitsofproof.comwrote: Serving headers should be default but storing and serving full blocks configurable to ranges, so people can tailor to their bandwith and space available. I do agree that it is important. This does require changes to

Re: [Bitcoin-development] Bitcoind-in-background mode for SPV wallets

2014-04-10 Thread Mike Hearn
What would this involve? Do you know of any previous work towards this? Chain pruning is a fairly complicated project, partly because it spans codebases. For instance if you try and implement it *just* by changing Bitcoin Core, you will break all the SPV clients based on bitcoinj (i.e. all

Re: [Bitcoin-development] Bitcoind-in-background mode for SPV wallets

2014-04-10 Thread Pieter Wuille
There were earlier discussions. The two ideas were either using one or a few service bits to indicate availability of blocks, or to extend addr messages with some flags to indicate this information. I wonder whether we can't have a hybrid: bits to indicate general degree of availability of

[Bitcoin-development] Chain pruning

2014-04-10 Thread Mike Hearn
Chain pruning is probably a separate thread, changing subject. Reason is that the actual blocks available are likely to change frequently (if you keep the last week of blocks I doubt anyone would specify blocks to keep in terms of time. More likely it'd be in terms of megabytes, as that's

Re: [Bitcoin-development] Bitcoind-in-background mode for SPV wallets

2014-04-10 Thread Peter Todd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 10 April 2014 06:44:32 GMT-04:00, Tamas Blummer ta...@bitsofproof.com wrote: Thanks, Peter and you convinced me. I run away with a thought. It’d be great to find a spot to deploy payment channels, but I agree this is not it. No problem! I'm

Re: [Bitcoin-development] Bitcoind-in-background mode for SPV wallets

2014-04-10 Thread Peter Todd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 10 April 2014 07:32:44 GMT-04:00, Pieter Wuille pieter.wui...@gmail.com wrote: There were earlier discussions. The two ideas were either using one or a few service bits to indicate availability of blocks, or to extend addr messages with some

Re: [Bitcoin-development] Bitcoind-in-background mode for SPV wallets

2014-04-10 Thread Mike Hearn
Oh yeah, credit goes to Mike Hearn for the payment channels, and if I'm correct, for the hub concept as well. Actually, the design is from Satoshi and Matt did most of the implementation work last year during a Google internship. Though I ended up doing a lot of work on it too. We actually

Re: [Bitcoin-development] Bitcoind-in-background mode for SPV wallets

2014-04-10 Thread Gregory Maxwell
On Thu, Apr 10, 2014 at 4:32 AM, Pieter Wuille pieter.wui...@gmail.com wrote: There were earlier discussions. On this list. The two ideas were either using one or a few service bits to indicate availability of blocks, or to extend addr messages with some flags to indicate this information.

Re: [Bitcoin-development] Bitcoind-in-background mode for SPV wallets

2014-04-10 Thread Peter Todd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 10 April 2014 07:45:16 GMT-04:00, Mike Hearn m...@plan99.net wrote: Oh yeah, credit goes to Mike Hearn for the payment channels, and if I'm correct, for the hub concept as well. Actually, the design is from Satoshi and Matt did most of the

Re: [Bitcoin-development] Bitcoind-in-background mode for SPV wallets

2014-04-10 Thread Peter Todd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 10 April 2014 07:50:55 GMT-04:00, Gregory Maxwell gmaxw...@gmail.com wrote: (Just be glad I'm not suggesting coding the entire blockchain with an error correcting code so that it doesn't matter which subset you're holding) I forgot to ask last

Re: [Bitcoin-development] Chain pruning

2014-04-10 Thread Wladimir
On Thu, Apr 10, 2014 at 1:37 PM, Mike Hearn m...@plan99.net wrote: Chain pruning is probably a separate thread, changing subject. Reason is that the actual blocks available are likely to change frequently (if you keep the last week of blocks I doubt anyone would specify blocks to keep in

Re: [Bitcoin-development] Chain pruning

2014-04-10 Thread Gregory Maxwell
On Thu, Apr 10, 2014 at 4:57 AM, Wladimir laa...@gmail.com wrote: Just wondering: Would there be a use for a [static] node that, say, always serves only the first 10 blocks? Or, even, a static range like block 10 - 20? The last time we discussed this sipa collected data based on

Re: [Bitcoin-development] Feedback request: colored coins protocol

2014-04-10 Thread Flavien Charlon
Thanks for the valuable feedback. I see there is a strong concern with requiring a large BTC capital for issuing coloring coins, so I am now in the process of modifying the specification to address that. I will post an update when this is finished. By the way, padding doesn't solve the issue

Re: [Bitcoin-development] Chain pruning

2014-04-10 Thread Wladimir
On Thu, Apr 10, 2014 at 2:10 PM, Gregory Maxwell gmaxw...@gmail.com wrote: But sure I could see a fixed range as also being a useful contribution though I'm struggling to figure out what set of constraints would leave a node without following the consensus? Obviously it has bandwidth if

Re: [Bitcoin-development] Chain pruning

2014-04-10 Thread Brian Hoffman
This is probably just noise, but what if nodes could compress and store earlier transaction sets (archive sets) and serve them up conditionally. So if there were let's say 100 archive sets of (10,000 blocks) you might have 5 open at any time when you're an active archive node while the others sit

Re: [Bitcoin-development] Chain pruning

2014-04-10 Thread Mike Hearn
Suggestions always welcome! The main problem with this is that the block chain is mostly random bytes (hashes, keys) so it doesn't compress that well. It compresses a bit, but not enough to change the fundamental physics. However, that does not mean the entire chain has to be stored on expensive

Re: [Bitcoin-development] Chain pruning

2014-04-10 Thread Brian Hoffman
Looks like only about ~30% disk space savings so I see your point. Is there a critical reason why blocks couldn't be formed into superblocks that are chained together and nodes could serve a specific superblock, which could be pieced together from different nodes to get the full blockchain? This

Re: [Bitcoin-development] Chain pruning

2014-04-10 Thread Ricardo Filipe
anyway, any kind of compression that comes to the blockchain is orthogonal to pruning. I agree that you will probably want some kind of replication on more recent nodes than on older ones. However, nodes with older blocks don't need to be static, get the block distribution algorithm to sort it

Re: [Bitcoin-development] Chain pruning

2014-04-10 Thread Ricardo Filipe
that's what blockchain pruning is all about :) 2014-04-10 17:47 GMT+01:00 Brian Hoffman brianchoff...@gmail.com: Looks like only about ~30% disk space savings so I see your point. Is there a critical reason why blocks couldn't be formed into superblocks that are chained together and nodes

Re: [Bitcoin-development] Chain pruning

2014-04-10 Thread Brian Hoffman
Okay...will let myself out now ;P On Thu, Apr 10, 2014 at 12:54 PM, Ricardo Filipe ricardojdfil...@gmail.comwrote: that's what blockchain pruning is all about :) 2014-04-10 17:47 GMT+01:00 Brian Hoffman brianchoff...@gmail.com: Looks like only about ~30% disk space savings so I see your

Re: [Bitcoin-development] Chain pruning

2014-04-10 Thread Pieter Wuille
On Thu, Apr 10, 2014 at 6:47 PM, Brian Hoffman brianchoff...@gmail.com wrote: Looks like only about ~30% disk space savings so I see your point. Is there a critical reason why blocks couldn't be formed into superblocks that are chained together and nodes could serve a specific superblock, which

Re: [Bitcoin-development] Chain pruning

2014-04-10 Thread Brian Hoffman
Ok I think I've got a good understanding of where we're at now. I can promise that the next person to waste your time in 30 days will not be me. I'm pleasantly surprised to see a community that doesn't kickban newcomers and takes the time to explain (re-explain) concepts. Hoping to add

Re: [Bitcoin-development] Feedback request: colored coins protocol

2014-04-10 Thread Alex Mizrahi
At this point, I don't think what you are doing is even colored coins anymore. You might want to look into Counterparty or Mastercoin. Nope, it's still colored coins. The difference between colored coin model and Mastercoin model is that colored coins are linked to transaction outputs, while

Re: [Bitcoin-development] Bitcoind-in-background mode for SPV wallets

2014-04-10 Thread Tier Nolan
Error correction is an interesting suggestion. If there was 1 nodes and each stored 0.1% of the blocks, at random, then the odds of a block not being stored is 45 in a million. Blocks are stored on average 10 times, so there is already reasonable redundancy. With 1 million blocks, 45 would

Re: [Bitcoin-development] Chain pruning

2014-04-10 Thread Paul Rabahy
You say UTXO commitments is a strict reduction in security. If UTXO commitments were rolled in as a soft fork, I do not see any new attacks that could happen to a person trusting the committed UTXO + any remaining blocks to catch up to the head. I would imagine the soft fork to proceed similar to

Re: [Bitcoin-development] Chain pruning

2014-04-10 Thread Pieter Wuille
On Thu, Apr 10, 2014 at 8:19 PM, Paul Rabahy prab...@gmail.com wrote: Please let me know if I have missed something. A 51% attack can make you believe you were paid, while you weren't. Full node security right now validates everything - there is no way you can ever be made to believe something

Re: [Bitcoin-development] Chain pruning

2014-04-10 Thread Mark Friedenbach
You took the quote out of context: a full node can copy the chain state from someone else, and check that its hash matches what the block chain commits to. It's important to note that this is a strict reduction in security: we're now trusting that the longest chain (with most proof of work)

Re: [Bitcoin-development] Chain pruning

2014-04-10 Thread Tier Nolan
On Thu, Apr 10, 2014 at 7:32 PM, Pieter Wuille pieter.wui...@gmail.comwrote: If you trust hashrate for determining which UTXO set is valid, a 51% attack becomes worse in that you can be made to believe a version of history which is in fact invalid. If there are invalidation proofs, then this

Re: [Bitcoin-development] Chain pruning

2014-04-10 Thread Pieter Wuille
On Thu, Apr 10, 2014 at 10:12 PM, Tier Nolan tier.no...@gmail.com wrote: On Thu, Apr 10, 2014 at 7:32 PM, Pieter Wuille pieter.wui...@gmail.com wrote: If you trust hashrate for determining which UTXO set is valid, a 51% attack becomes worse in that you can be made to believe a version of

Re: [Bitcoin-development] Chain pruning

2014-04-10 Thread Jesus Cea
On 10/04/14 18:59, Pieter Wuille wrote: It's important to note that this is a strict reduction in security: we're now trusting that the longest chain (with most proof of work) commits to a valid UTXO set (at some point in the past). AFAIK, current bitcoin code code already set blockchain

Re: [Bitcoin-development] Chain pruning

2014-04-10 Thread Mark Friedenbach
Checkpoints will go away, eventually. On 04/10/2014 02:34 PM, Jesus Cea wrote: On 10/04/14 18:59, Pieter Wuille wrote: It's important to note that this is a strict reduction in security: we're now trusting that the longest chain (with most proof of work) commits to a valid UTXO set (at some

Re: [Bitcoin-development] Chain pruning

2014-04-10 Thread Jesus Cea
On 11/04/14 00:15, Mark Friedenbach wrote: Checkpoints will go away, eventually. Why?. The points in the forum thread seem pretty sensible. -- Jesús Cea Avión _/_/ _/_/_/_/_/_/ j...@jcea.es - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ Twitter:

Re: [Bitcoin-development] Chain pruning

2014-04-10 Thread Gregory Maxwell
On Thu, Apr 10, 2014 at 3:24 PM, Jesus Cea j...@jcea.es wrote: On 11/04/14 00:15, Mark Friedenbach wrote: Checkpoints will go away, eventually. Why?. The points in the forum thread seem pretty sensible. Because with headers first synchronization the major problems that they solve— e.g. block

Re: [Bitcoin-development] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys

2014-04-10 Thread Nikita Schmidt
What do you think a big-integer division by a word-sized divisor *is*? Obviously rolling your own is always an option. Are you just saying that Base58 encoding and decoding is easier than Shamir's Secret Sharing because the divisors are small? Well, yes, to be fair, in fact it is. The