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

2014-04-07 Thread Flavien Charlon
Thanks for the feedback Mark. (1) there is absolutely no reason to include asset tagging information if it is not validated Sure, there is a good reason to include it in the blockchain: so that clients don't need external information to recognize colored coins. Also, I'm not sure what you mean

Re: [Bitcoin-development] Why are we bleeding nodes?

2014-04-07 Thread Jameson Lopp
I'm glad to see that I'm not the only one concerned about the consistent dropping of nodes. Though I think that the fundamental question should be: how many nodes do we really need? Obviously more is better, but it's difficult to say how concerned we should be without more information. I posted

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

2014-04-07 Thread Jorge Timón
On 4/7/14, Flavien Charlon flavien.char...@coinprism.com wrote: Also those 54 BTC (actually 5.4 BTC if the dust is now 540 satoshis) become part of the capital of the company, and can always be recovered by uncoloring the shares. It's an investment, not an expense, so I think it is acceptable.

Re: [Bitcoin-development] Why are we bleeding nodes?

2014-04-07 Thread Pieter Wuille
On Mon, Apr 7, 2014 at 2:19 PM, Jameson Lopp jameson.l...@gmail.com wrote: I'm glad to see that I'm not the only one concerned about the consistent dropping of nodes. Though I think that the fundamental question should be: how many nodes do we really need? Obviously more is better, but it's

Re: [Bitcoin-development] Why are we bleeding nodes?

2014-04-07 Thread Mike Hearn
In my opinion, the number of full nodes doesn't matter (as long as it's enough to satisfy demand by other nodes). Correct. Still, a high number of nodes has a few other benefits: 1) The more nodes there are, the cheaper it should be to run each one, given that the bandwidth and CPU for

Re: [Bitcoin-development] Why are we bleeding nodes?

2014-04-07 Thread Jameson Lopp
On 04/07/2014 08:26 AM, Pieter Wuille wrote: In my opinion, the number of full nodes doesn't matter (as long as it's enough to satisfy demand by other nodes). I agree, but if we don't quantify demand then we are practically blind. What is the plan? To wait until SPV clients start lagging /

Re: [Bitcoin-development] Why are we bleeding nodes?

2014-04-07 Thread Andreas Schildbach
They're _not_ phasing out into SPV wallets from what I can say. At around the 24th of February, there has been a sharp change of the current installs graph of Bitcoin Wallet. That number used to grow at about 20.000 per month. After that date until now, it just barely moves horizontal. My guess

Re: [Bitcoin-development] Why are we bleeding nodes?

2014-04-07 Thread Gregory Maxwell
On Mon, Apr 7, 2014 at 4:34 AM, Mike Hearn m...@plan99.net wrote: At the start of February we had 10,000 bitcoin nodes. Now we have 8,500 and still falling: FWIW, A few months before that we had even less than 8500 by the bitnodes count. Bitcoin.org recommends people away from running

Re: [Bitcoin-development] Why are we bleeding nodes?

2014-04-07 Thread Gregory Maxwell
On Mon, Apr 7, 2014 at 6:50 AM, Gregory Maxwell gmaxw...@gmail.com wrote: FWIW, A few months before that we had even less than 8500 by the bitnodes count. Gah, accidentally send I wanted to continue here that it was less than 8500 and had been falling pretty consistently for months,

Re: [Bitcoin-development] Why are we bleeding nodes?

2014-04-07 Thread Jameson Lopp
The Bitnodes project updated their counting algorithm a month or so ago. It used to be slower and less accurate - prior to their update, it was reporting in excess of 100,000 nodes. - Jameson On 04/07/2014 09:53 AM, Gregory Maxwell wrote: On Mon, Apr 7, 2014 at 6:50 AM, Gregory Maxwell

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

2014-04-07 Thread Flavien Charlon
Jorge, they'd have to be. Otherwise, assuming the price of the share goes low enough, you could buy a share of the company, melt the gold plate, and sell it for a profit. If the gold is part of the capital of the company, the cheapest a share can be is the price of the gold on which the stock

Re: [Bitcoin-development] Why are we bleeding nodes?

2014-04-07 Thread Gregory Maxwell
On Mon, Apr 7, 2014 at 6:58 AM, Jameson Lopp jameson.l...@gmail.com wrote: The Bitnodes project updated their counting algorithm a month or so ago. It used to be slower and less accurate - prior to their update, it was reporting in excess of 100,000 nodes. Nah. It reported multiple metrics.

Re: [Bitcoin-development] Why are we bleeding nodes?

2014-04-07 Thread Mike Hearn
My guess is that a large number of users have lost interest after they lost their money in MtGox. The 24th of February coincides with the final shutdown Sigh. It would not be surprising if MtGox has indeed dealt the community a critical blow in this regard. TX traffic is down since then too:

Re: [Bitcoin-development] Why are we bleeding nodes?

2014-04-07 Thread Mike Hearn
Indeed, fully agreed. The only way to really make progress here is to make the UX of being your own bank not only as good as trusting a third party, but better. I've been encouraged by the rise of risk analysis services, but we need to integrate them into wallets more widely for them to have much

Re: [Bitcoin-development] Why are we bleeding nodes?

2014-04-07 Thread Eric Martindale
We need to make it so mind-numbingly simple to run Bitcoin correctly that the average user doesn't find reasons to do so in the course of normal use. Right now, Coinbase and Bitstamp are winning in the user experience battle, which technically endanger the user, and by proxy the Bitcoin network.

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

2014-04-07 Thread Mark Friedenbach
Flavien, capital is wealth or resources available for the stated purpose of the company. These bitcoins represent nothing more than a speculative floor owned by the investors, not the company. On 04/07/2014 07:00 AM, Flavien Charlon wrote: Jorge, they'd have to be. Otherwise, assuming the price

Re: [Bitcoin-development] Why are we bleeding nodes?

2014-04-07 Thread Jameson Lopp
I would point to bandwidth as the most important issue to the casual user who runs a node at home. Few casual users have the know-how to set up QoS rules and thus become quite annoyed when their Internet connection is discernibly slowed. - Jameson On 04/07/2014 11:53 AM, Gregory Maxwell wrote:

Re: [Bitcoin-development] Why are we bleeding nodes?

2014-04-07 Thread Mark Friedenbach
Right now running a full-node on my home DSL connection (1Mbps) makes other internet activity periodically unresponsive. I think we've already hit a point where resource requirements are pushing out casual users, although of course we can't be certain that accounts for all lost nodes. On

Re: [Bitcoin-development] Why are we bleeding nodes?

2014-04-07 Thread Gregory Maxwell
On Mon, Apr 7, 2014 at 9:27 AM, Mark Friedenbach m...@monetize.io wrote: Right now running a full-node on my home DSL connection (1Mbps) makes other internet activity periodically unresponsive. I think we've already hit a point where resource requirements are pushing out casual users, although

Re: [Bitcoin-development] Why are we bleeding nodes?

2014-04-07 Thread Drak
For what it's worth, the number of nodes rose dramatically during the China bullrun (I recall 45k in China alone) and dropped as dramatically as the price after the first PBOC announcement designed to cool down bitcoin trading in China. On 7 April 2014 12:34, Mike Hearn m...@plan99.net wrote:

Re: [Bitcoin-development] Why are we bleeding nodes?

2014-04-07 Thread Gregory Maxwell
On Mon, Apr 7, 2014 at 10:01 AM, Mark Friedenbach m...@monetize.io wrote: On 04/07/2014 09:57 AM, Gregory Maxwell wrote: That is an implementation issue— mostly one that arises as an indirect consequence of not having headers first and the parallel fetch, not a requirements issue. Oh,

Re: [Bitcoin-development] Why are we bleeding nodes?

2014-04-07 Thread Mark Friedenbach
On 04/07/2014 09:57 AM, Gregory Maxwell wrote: That is an implementation issue— mostly one that arises as an indirect consequence of not having headers first and the parallel fetch, not a requirements issue. Oh, absolutely. But the question why are people not running full nodes? has to do with

Re: [Bitcoin-development] Why are we bleeding nodes?

2014-04-07 Thread Brent Shambaugh
How difficult would it be to set up a node? Using lots of electricity at home (if required) could be an issue, but I do have a Webfaction account. On Mon, Apr 7, 2014 at 12:16 PM, Gregory Maxwell gmaxw...@gmail.com wrote: On Mon, Apr 7, 2014 at 10:01 AM, Mark Friedenbach m...@monetize.io

Re: [Bitcoin-development] Why are we bleeding nodes?

2014-04-07 Thread Mike Hearn
It uses ~no electricity, it's not like mining. The primary resources it needs are disk space and bandwidth, after an intensive initial day or two of building the database. Actually, I wonder if we should start shipping (auditable) pre-baked databases calculated up to the last checkpoint so

Re: [Bitcoin-development] Why are we bleeding nodes?

2014-04-07 Thread Gregory Maxwell
On Mon, Apr 7, 2014 at 10:40 AM, Mike Hearn m...@plan99.net wrote: Actually, I wonder The actual validation isn't really the problem today. The slowness of the IBD is almost exclusively the lack of parallel fetching and the existence of slow peers. And making the signature gate adaptive (and

Re: [Bitcoin-development] Why are we bleeding nodes?

2014-04-07 Thread Tamas Blummer
I rather prefer to start with SPV and upgrade to full node, if desired. Tamas Blummer http://bitsofproof.com On 07.04.2014, at 19:40, Mike Hearn m...@plan99.net wrote: Actually, I wonder if we should start shipping (auditable) pre-baked databases calculated up to the last checkpoint so

Re: [Bitcoin-development] Why are we bleeding nodes?

2014-04-07 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/07/2014 05:16 PM, Gregory Maxwell wrote: When I read resource requirements of a full node are moving beyond I didn't extract from that that there are implementation issues that need to be improved to make it work better for low resource

Re: [Bitcoin-development] Why are we bleeding nodes?

2014-04-07 Thread Brent Shambaugh
Okay awesome. It seems like I set up a Litecoin node without knowing it (because it was like this: https://bitcointalk.org/index.php?topic=128122.0) I was able to bootstrap it (https://litecoin.info/). On Mon, Apr 7, 2014 at 12:40 PM, Mike Hearn m...@plan99.net wrote: It uses ~no electricity,

Re: [Bitcoin-development] Why are we bleeding nodes?

2014-04-07 Thread Chris Williams
I’m afraid this is a highly simplistic view of the costs of running a full node. My node consumes fantastic amounts of data traffic, which is a real cost. In the 30 days ending Apri 6, my node: * Received 36.8 gb of data * Sent 456.5 gb data At my geographic service location (Singapore), this

Re: [Bitcoin-development] Why are we bleeding nodes?

2014-04-07 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/07/2014 05:40 PM, Mike Hearn wrote: The primary resources it needs are disk space and bandwidth, after an intensive initial day or two of building the database. Check out the kind of hardware causal users are running these days. The

Re: [Bitcoin-development] Why are we bleeding nodes?

2014-04-07 Thread Mike Hearn
* Sent 456.5 gb data At my geographic service location (Singapore), this cost about $90 last month for bandwidth alone. One of the reasons I initiated the (now stalled) PayFile project was in anticipation of this problem: https://github.com/mikehearn/PayFile

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

2014-04-07 Thread Jorge Timón
On 4/7/14, Flavien Charlon flavien.char...@coinprism.com wrote: Ok, I guess I'm not using the proper terminology. It would be listed on the Asset section of the company's balance sheet, is what I meant. No, it's an asset for the owner of the share, not the company, just like the gold plates are

Re: [Bitcoin-development] Why are we bleeding nodes?

2014-04-07 Thread Tamas Blummer
Headers first loading allows the node to run SPV from the very first minutes and it can converge to full node by time. This is BTW how newest versions of BOP can work. Pruning however disqualifies the node as a source for bootstrapping an other full node. BTW, did we already agree on the

Re: [Bitcoin-development] Why are we bleeding nodes?

2014-04-07 Thread Gregory Maxwell
On Mon, Apr 7, 2014 at 11:35 AM, Tamas Blummer ta...@bitsofproof.com wrote: BTW, did we already agree on the service bits for an archive node? I'm still very concerned that a binary archive bit will cause extreme load hot-spotting and the kind of binary Use lots of resources YES or NO I think

Re: [Bitcoin-development] Why are we bleeding nodes?

2014-04-07 Thread Tamas Blummer
Once a single transaction in pruned in a block, the block is no longer eligible to be served to other nodes. Which transactions are pruned can be rather custom e.g. even depending on the wallet(s) of the node, therefore I guess it is more handy to return some bitmap of pruned/full blocks than

Re: [Bitcoin-development] Why are we bleeding nodes?

2014-04-07 Thread Gregory Maxwell
On Mon, Apr 7, 2014 at 12:00 PM, Tamas Blummer ta...@bitsofproof.com wrote: Once a single transaction in pruned in a block, the block is no longer eligible to be served to other nodes. Which transactions are pruned can be rather custom e.g. even depending on the wallet(s) of the node,

Re: [Bitcoin-development] Why are we bleeding nodes?

2014-04-07 Thread Gregory Maxwell
On Mon, Apr 7, 2014 at 12:00 PM, Tamas Blummer ta...@bitsofproof.com wrote: therefore I guess it is more handy to return some bitmap of pruned/full blocks than ranges. A bitmap also means high overhead and— if it's used to advertise non-contiguous blocks— poor locality, since blocks are fetched

Re: [Bitcoin-development] Why are we bleeding nodes?

2014-04-07 Thread Mark Friedenbach
On 04/07/2014 12:00 PM, Tamas Blummer wrote: Once a single transaction in pruned in a block, the block is no longer eligible to be served to other nodes. Which transactions are pruned can be rather custom e.g. even depending on the wallet(s) of the node, therefore I guess it is more handy to

Re: [Bitcoin-development] Why are we bleeding nodes?

2014-04-07 Thread Tamas Blummer
Maybe it is not a question of the maturity of the implementation but that of the person making presumptions of it. I consider a fully pruned blockchain being equivalent to the UTXO. Block that hold no more unspent transaction are reduced to a header. There is however no harm if more retained.

Re: [Bitcoin-development] Why are we bleeding nodes?

2014-04-07 Thread Tamas Blummer
Once headers are loaded first there is no reason for sequential loading. Validation has to be sequantial, but that step can be deferred until the blocks before a point are loaded and continous. Tamas Blummer http://bitsofproof.com On 07.04.2014, at 21:03, Gregory Maxwell gmaxw...@gmail.com

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

2014-04-07 Thread Flavien Charlon
An IOU written in a gold plate sure makes no sense. I see what you are saying, the inconvenience comes from the fact that the buyer has to buy some amount of BTC at the same time as he buys a share. That's why I was making the point that you could have a colored coin representing a single share,

Re: [Bitcoin-development] Why are we bleeding nodes?

2014-04-07 Thread Mark Friedenbach
On 04/07/2014 12:20 PM, Tamas Blummer wrote: Validation has to be sequantial, but that step can be deferred until the blocks before a point are loaded and continous. And how do you find those blocks? I have a suggestion: have nodes advertise which range of full blocks they possess, then you

Re: [Bitcoin-development] Why are we bleeding nodes?

2014-04-07 Thread Tamas Blummer
You have the trunk defined by the headers. Once a range from genesis to block n is fully downloaded, you may validate upto block n. Furthermore after validation you can prune transactions spent until block n. You would approach the highest block with validation and stop pruning say 100 blocks

Re: [Bitcoin-development] Why are we bleeding nodes?

2014-04-07 Thread Paul Lyon
I hope I'm not thread-jacking here, apologies if so, but that's the approach I've taken with the node I'm working on. Headers can be downloaded and stored in any order, it'll make sense of what the winning chain is. Blocks don't need to be downloaded in any particular order and they don't need

Re: [Bitcoin-development] Why are we bleeding nodes?

2014-04-07 Thread Troy Benjegerdes
I understand the theoretical benefits of multi-sig. But if you want to make this mind-numbingly simple, do it on the *existing* single-sig. But why in the world do we not have a *business* that offers bitcoin wallet insurance? The bitcoin world (and this list) ran around blaming MtGox and users

Re: [Bitcoin-development] Why are we bleeding nodes?

2014-04-07 Thread Tamas Blummer
You have to load headers sequantially to be able to connect them and determine the longest chain. Blocks can be loaded in random order once you have their order given by the headers. Computing the UTXO however will force you to at least temporarily store the blocks unless you have plenty of

Re: [Bitcoin-development] Draft BIP for seamless website authentication using Bitcoin address

2014-04-07 Thread Troy Benjegerdes
I have to play dissenter here again.. Using a bitcoin address as a persistent identity key is the first real-world use of Bitcoin that I can imagine will make it a 'killer app' that everyone and their grandma will want to use. If you think 'certificates' are a good solution, then there is some

Re: [Bitcoin-development] Why are we bleeding nodes?

2014-04-07 Thread Ricardo Filipe
Or have blocks distributed through pruned nodes as a DHT. 2014-04-07 20:13 GMT+01:00 Mark Friedenbach m...@monetize.io: On 04/07/2014 12:20 PM, Tamas Blummer wrote: Validation has to be sequantial, but that step can be deferred until the blocks before a point are loaded and continous. And

Re: [Bitcoin-development] Why are we bleeding nodes?

2014-04-07 Thread Tier Nolan
On Mon, Apr 7, 2014 at 8:50 PM, Tamas Blummer ta...@bitsofproof.com wrote: You have to load headers sequantially to be able to connect them and determine the longest chain. The isn't strictly true. If you are connected to a some honest nodes, then you could download portions of the chain and

Re: [Bitcoin-development] Draft BIP for seamless website authentication using Bitcoin address

2014-04-07 Thread Ricardo Filipe
2014-04-07 21:08 GMT+01:00 Troy Benjegerdes ho...@hozed.org: I have to play dissenter here again.. Using a bitcoin address as a persistent identity key is the first real-world use of Bitcoin that I can imagine will make it a 'killer app' that everyone and their grandma will want to use. I

Re: [Bitcoin-development] Why are we bleeding nodes?

2014-04-07 Thread Gregory Maxwell
On Mon, Apr 7, 2014 at 2:48 PM, Tier Nolan tier.no...@gmail.com wrote: Blocks can be loaded in random order once you have their order given by the headers. Computing the UTXO however will force you to at least temporarily store the blocks unless you have plenty of RAM. You only need to store

Re: [Bitcoin-development] Draft BIP for seamless website authentication using Bitcoin address

2014-04-07 Thread Eric Martindale
This is toying with the economics of cryptofinance in a way that needs to be understood before being put under consideration for implementation in Bitcoin. This is an opportunity for an altcoin to explore the implications of these proposals prior to changing the properties of an already

Re: [Bitcoin-development] Why are we bleeding nodes?

2014-04-07 Thread Tier Nolan
On Mon, Apr 7, 2014 at 10:55 PM, Paul Lyon pml...@hotmail.ca wrote: I actually ask for headers from each peer I'm connected to and then dump them into the backend to be sorted out.. is this abusive to the network? I think downloading from a subset of the peers and switching out any slow ones

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

2014-04-07 Thread Nikita Schmidt
I'd be fine with changing the key fingerprint algorithm to something else. Do you like CRC16? I like CRC16. Do you intend to use it in conjunction with a cryptographic hash? Regarding the choice of fields, any implementation of this BIP will need big integer arithmetic to do base-58 anyway.

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

2014-04-07 Thread Gregory Maxwell
On Mon, Apr 7, 2014 at 5:33 PM, Nikita Schmidt nik...@megiontechnologies.com wrote: Regarding the choice of fields, any implementation of this BIP will need big integer arithmetic to do base-58 anyway. Nah, it doesn't. E.g.

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

2014-04-07 Thread Matt Whitlock
On Monday, 7 April 2014, at 5:38 pm, Gregory Maxwell wrote: On Mon, Apr 7, 2014 at 5:33 PM, Nikita Schmidt nik...@megiontechnologies.com wrote: Regarding the choice of fields, any implementation of this BIP will need big integer arithmetic to do base-58 anyway. Nah, it doesn't. E.g.

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

2014-04-07 Thread Gregory Maxwell
On Mon, Apr 7, 2014 at 6:46 PM, Matt Whitlock b...@mattwhitlock.name wrote: On Monday, 7 April 2014, at 5:38 pm, Gregory Maxwell wrote: On Mon, Apr 7, 2014 at 5:33 PM, Nikita Schmidt nik...@megiontechnologies.com wrote: Regarding the choice of fields, any implementation of this BIP will

Re: [Bitcoin-development] Why are we bleeding nodes?

2014-04-07 Thread kjj
Multi-sig requires infrastructure. It isn't a magic wand that we can wave to make everyone secure. The protocols and techniques necessary don't exist yet, and apparently no one has much of an incentive to create them. I mean no offense, and I don't mean to pick on you. Your post stuck out

Re: [Bitcoin-development] Draft BIP for seamless website authentication using Bitcoin address

2014-04-07 Thread Jeff Garzik
On Fri, Apr 4, 2014 at 10:56 AM, Eric Larchevêque ela...@gmail.com wrote: Yes, but no one will ever install a plug in. This is quite true. I said the same about KryptoKit. Incredibly cool to do bitcoin + PGP in client... but ultimately plugins reach 0.01% of the user population. -- Jeff

Re: [Bitcoin-development] Why are we bleeding nodes?

2014-04-07 Thread Jeff Garzik
Being Mr. Torrent, I've held open the 80% serious suggestion to simply refuse to serve blocks older than X (3 months?). That forces download by other means (presumably torrent). I do not feel it is productive for any nodes on the network to waste time/bandwidth/etc. serving static, ancient data.