[Bitcoin-development] Why do we need a MAX_BLOCK_SIZE at all?
Ok, I understand at least some of the reason that blocks have to be kept to a certain size. I get that blocks which are too big will be hard to propagate by relays. Miners will have more trouble uploading the large blocks to the network once they've found a hash. We need block size constraints to create a fee economy for the miners. But these all sound to me like issues that affect some, but not others. So it seems to me like it ought to be a configurable setting. We've already witnessed with last week's stress test that most miners aren't even creating 1MB blocks but are still using the software defaults of 730k. If there are configurable limits, why does there have to be a hard limit? Can't miners just use the configurable limit to decide what size blocks they can afford to and are thus willing to create? They could just as easily use that to create a fee economy. If the miners with the most hashpower are not willing to mine blocks larger than 1 or 2 megs, then they are able to slow down confirmations of transactions. It may take several blocks before a miner willing to include a particular transaction finds a block. This would actually force miners to compete with each other and find a block size naturally instead of having it forced on them by the protocol. Relays would be able to participate in that process by restricting the miners ability to propagate large blocks. You know, like what happens in a FREE MARKET economy, without burdensome regulation which can be manipulated through politics? Isn't that what's really happening right now? Different political factions with different agendas are fighting over how best to regulate the Bitcoin protocol. I know the limit was originally put in place to prevent spamming. But that was when we were mining with CPUs and just beginning to see the occasional GPU which could take control over the network and maliciously spam large blocks. But with ASIC mining now catching up to Moore's Law, that's not really an issue anymore. No one malicious entity can really just take over the network now without spending more money than it's worth -- and that's just going to get truer with time as hashpower continues to grow. And it's not like the hard limit really does anything anymore to prevent spamming. If a spammer wants to create thousands or millions of transactions, a hard limit on the block size isn't going to stop him.. He'll just fill up the mempool or UTXO database instead of someone's block database.. And block storage media is generally the cheapest storage.. I mean they could be written to tape and be just as valid as if they're stored in DRAM. Combine that with pruning, and block storage costs are almost a non-issue for anyone who isn't running an archival node. And can't relay nodes just configure a limit on the size of blocks they will relay? Sure they'd still need to download a big block occasionally, but that's not really that big a deal, and they're under no obligation to propagate it.. Even if it's a 2GB block, it'll get downloaded eventually. It's only if it gets to the point where the average home connection is too slow to keep up with the transaction block flow that there's any real issue there, and that would happen regardless of how big the blocks are. I personally would much prefer to see hardware limits act as the bottleneck than to introduce an artificial bottleneck into the protocol that has to be adjusted regularly. The software and protocol are TECHNICALLY capable of scaling to handle the world's entire transaction set. The real issue with scaling to this size is limitations on hardware, which are regulated by Moore's Law. Why do we need arbitrary soft limits? Why can't we allow Bitcoin to grow naturally within the ever increasing limits of our hardware? Is it because nobody will ever need more than 640k of RAM? Am I missing something here? Is there some big reason that I'm overlooking why there has to be some hard-coded limit on the block size that affects the entire network and creates ongoing issues in the future? -- *James G. Phillips IV* https://plus.google.com/u/0/113107039501292625391/posts *Don't bunt. Aim out of the ball park. Aim for the company of immortals. -- David Ogilvy* *This message was created with 100% recycled electrons. Please think twice before printing.* -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] No Bitcoin For You
I think all the suggestions recommending cutting the block time down also suggest reducing the rewards to compensate. -- *James G. Phillips IV* https://plus.google.com/u/0/113107039501292625391/posts http://www.linkedin.com/in/ergophobe *Don't bunt. Aim out of the ball park. Aim for the company of immortals. -- David Ogilvy* *This message was created with 100% recycled electrons. Please think twice before printing.* On Tue, May 26, 2015 at 12:43 AM, gabe appleton gapplet...@gmail.com wrote: Sync time wouldn't be longer compared to 20MB, it would (eventually) be longer under either setup. Also, and this is probably a silly concern, but wouldn't changing block time change the supply curve? If we cut the rate in half or a power of two, that affects nothing, but if we want to keep it in round numbers, we need to do it by 10, 5, or 2. I feel like most people would bank for 10 or 5, both of which change the supply curve due to truncation. Again, it's a trivial concern, but probably one that should be addressed. On May 25, 2015 11:52 PM, Jim Phillips j...@ergophobia.org wrote: Incidentally, even once we have the Internet of Things brought on by 21, Inc. or whoever beats them to it, I would expect the average home to have only a single full node hub receiving the blockchain and broadcasting transactions created by all the minor SPV connected devices running within the house. The in-home full node would be peered with high bandwidth full-node relays running at the ISP or in the cloud. There are more than enough ISPs and cloud compute providers in the world such that there should be no concern at all about centralization of relays. Full nodes could some day become as ubiquitous on the Internet as authoritative DNS servers. And just like DNS servers, if you don't trust the nodes your ISP creates or it's too slow or censors transactions, there's nothing preventing you from peering with nodes hosted by the Googles or OpenDNSs out there, or running your own if you're really paranoid and have a few extra bucks for a VPS. -- *James G. Phillips IV* https://plus.google.com/u/0/113107039501292625391/posts http://www.linkedin.com/in/ergophobe *Don't bunt. Aim out of the ball park. Aim for the company of immortals. -- David Ogilvy* *This message was created with 100% recycled electrons. Please think twice before printing.* On Mon, May 25, 2015 at 10:23 PM, Jim Phillips j...@ergophobia.org wrote: I don't see how the fact that my 2Mbps connection causes me to not be a very good relay has any bearing on whether or not the network as a whole would be negatively impacted by a 20MB block. My inability to rapidly propagate blocks doesn't really harm the network. It's only if MOST relays are as slow as mine that it creates an issue. I'm one node in thousands (potentially tens or hundreds of thousands if/when Bitcoin goes mainstream). And I'm an individual. There's no reason at all for me to run a full node from my home, except to have my own trusted and validated copy of the blockchain on a computer I control directly. I don't need to act as a relay for that and as long as I can download blocks faster than they are created I'm fine. Also, I can easily afford a VPS server or several to run full nodes as relays if I am feeling altruistic. It's actually cheaper for me to lease a VPS than to keep my own home PC on 24/7, which is why I have 2 of them. And as a business, the cost of a server and bandwidth to run a full node is a drop in the bucket. I'm involved in several projects where we have full nodes running on leased servers with multiple 1Gbps connections. It's an almost zero cost. Those nodes could handle 20MB blocks today without thinking about it, and I'm sure our nodes are just a few amongst thousands just like them. I'm not at all concerned about the network being too centralized. What concerns me is the fact that we are using edge cases like my home PC as a lame excuse to debate expanding the capacity of the network. -- *James G. Phillips IV* https://plus.google.com/u/0/113107039501292625391/posts http://www.linkedin.com/in/ergophobe *Don't bunt. Aim out of the ball park. Aim for the company of immortals. -- David Ogilvy* *This message was created with 100% recycled electrons. Please think twice before printing.* On Mon, May 25, 2015 at 10:02 PM, Thy Shizzle thyshiz...@outlook.com wrote: Indeed Jim, your internet connection makes a good reason why I don't like 20mb blocks (right now). It would take you well over a minute to download the block before you could even relay it on, so much slow down in propagation! Yes I do see how decreasing the time to create blocks is a bit of a band-aid fix, and to use tge term I've seen mentioned here kicking the can down the road I agree that this is doing this, however as you say bandwidth is our biggest enemy right now and so hopefully by the time we exceed the capacity gained by the decrease
Re: [Bitcoin-development] No Bitcoin For You
On Mon, May 25, 2015 at 1:36 PM, Mike Hearn m...@plan99.net wrote: This meme about datacenter-sized nodes has to die. The Bitcoin wiki is down right now, but I showed years ago that you could keep up with VISA on a single well specced server with today's technology. Only people living in a dreamworld think that Bitcoin might actually have to match that level of transaction demand with today's hardware. As noted previously, too many users is simply not a problem Bitcoin has and may never have! ... And will certainly NEVER have if we can't solve the capacity problem SOON. In a former life, I was a capacity planner for Bank of America's mid-range server group. We had one hard and fast rule. When you are typically exceeding 75% of capacity on a given metric, it's time to expand capacity. Period. You don't do silly things like adjusting the business model to disincentivize use. Unless there's some flaw in the system and it's leaking resources, if usage has increased to the point where you are at or near the limits of capacity, you expand capacity. It's as simple as that, and I've found that same rule fits quite well in a number of systems. In Bitcoin, we're not leaking resources. There's no flaw. The system is performing as intended. Usage is increasing because it works so well, and there is huge potential for future growth as we identify more uses and attract more users. There might be a few technical things we can do to reduce consumption, but the metric we're concerned with right now is how many transactions we can fit in a block. We've broken through the 75% marker and are regularly bumping up against the 100% limit. It is time to stop debating this and take action to expand capacity. The only questions that should remain are how much capacity do we add, and how soon can we do it. Given that most existing computer systems and networks can easily handle 20MB blocks every 10 minutes, and given that that will increase capacity 20-fold, I can't think of a single reason why we can't go to 20MB as soon as humanly possible. And in a few years, when the average block size is over 15MB, we bump it up again to as high as we can go then without pushing typical computers or networks beyond their capacity. We can worry about ways to slow down growth without affecting the usefulness of Bitcoin as we get closer to the hard technical limits on our capacity. And you know what else? If miners need higher fees to accommodate the costs of bigger blocks, they can configure their nodes to only mine transactions with higher fees.. Let the miners decide how to charge enough to pay for their costs. We don't need to cripple the network just for them. -- *James G. Phillips IV* https://plus.google.com/u/0/113107039501292625391/posts *Don't bunt. Aim out of the ball park. Aim for the company of immortals. -- David Ogilvy* *This message was created with 100% recycled electrons. Please think twice before printing.* -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] No Bitcoin For You
Frankly I'm good with either way. I'm definitely in favor of faster confirmation times. The important thing is that we need to increase the amount of transactions that get into blocks over a given time frame to a point that is in line with what current technology can handle. We can handle WAY more than we are doing right now. The Bitcoin network is not currently Disk, CPU, or RAM bound.. Not even close. The metric we're closest to being restricted by would be Network bandwidth. I live in a developing country. 2Mbps is a typical broadband speed here (although 5Mbps and 10Mbps connections are affordable). That equates to about 17MB per minute, or 170x more capacity than what I need to receive a full copy of the blockchain if I only talk to one peer. If I relay to say 10 peers, I can still handle 17x larger block sizes on a slow 2Mbps connection. Also, even if we reduce the difficulty so that we're doing 1MB blocks every minute, that's still only 10MB every 10 minutes. Eventually we're going to have to increase that, and we can only reduce the confirmation period so much. I think someone once said 30 seconds or so is about the shortest period you can practically achieve. -- *James G. Phillips IV* https://plus.google.com/u/0/113107039501292625391/posts http://www.linkedin.com/in/ergophobe *Don't bunt. Aim out of the ball park. Aim for the company of immortals. -- David Ogilvy* *This message was created with 100% recycled electrons. Please think twice before printing.* On Mon, May 25, 2015 at 9:30 PM, Thy Shizzle thyshiz...@outlook.com wrote: Nah don't make blocks 20mb, then you are slowing down block propagation and blowing out conf tikes as a result. Just decrease the time it takes to make a 1mb block, then you still see the same propagation times today and just increase the transaction throughput. -- From: Jim Phillips j...@ergophobia.org Sent: 26/05/2015 12:27 PM To: Mike Hearn m...@plan99.net Cc: Bitcoin Dev bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] No Bitcoin For You On Mon, May 25, 2015 at 1:36 PM, Mike Hearn m...@plan99.net wrote: This meme about datacenter-sized nodes has to die. The Bitcoin wiki is down right now, but I showed years ago that you could keep up with VISA on a single well specced server with today's technology. Only people living in a dreamworld think that Bitcoin might actually have to match that level of transaction demand with today's hardware. As noted previously, too many users is simply not a problem Bitcoin has and may never have! ... And will certainly NEVER have if we can't solve the capacity problem SOON. In a former life, I was a capacity planner for Bank of America's mid-range server group. We had one hard and fast rule. When you are typically exceeding 75% of capacity on a given metric, it's time to expand capacity. Period. You don't do silly things like adjusting the business model to disincentivize use. Unless there's some flaw in the system and it's leaking resources, if usage has increased to the point where you are at or near the limits of capacity, you expand capacity. It's as simple as that, and I've found that same rule fits quite well in a number of systems. In Bitcoin, we're not leaking resources. There's no flaw. The system is performing as intended. Usage is increasing because it works so well, and there is huge potential for future growth as we identify more uses and attract more users. There might be a few technical things we can do to reduce consumption, but the metric we're concerned with right now is how many transactions we can fit in a block. We've broken through the 75% marker and are regularly bumping up against the 100% limit. It is time to stop debating this and take action to expand capacity. The only questions that should remain are how much capacity do we add, and how soon can we do it. Given that most existing computer systems and networks can easily handle 20MB blocks every 10 minutes, and given that that will increase capacity 20-fold, I can't think of a single reason why we can't go to 20MB as soon as humanly possible. And in a few years, when the average block size is over 15MB, we bump it up again to as high as we can go then without pushing typical computers or networks beyond their capacity. We can worry about ways to slow down growth without affecting the usefulness of Bitcoin as we get closer to the hard technical limits on our capacity. And you know what else? If miners need higher fees to accommodate the costs of bigger blocks, they can configure their nodes to only mine transactions with higher fees.. Let the miners decide how to charge enough to pay for their costs. We don't need to cripple the network just for them. -- *James G. Phillips IV* https://plus.google.com/u/0/113107039501292625391/posts *Don't bunt. Aim out of the ball park. Aim for the company of immortals. -- David Ogilvy
Re: [Bitcoin-development] No Bitcoin For You
I don't see how the fact that my 2Mbps connection causes me to not be a very good relay has any bearing on whether or not the network as a whole would be negatively impacted by a 20MB block. My inability to rapidly propagate blocks doesn't really harm the network. It's only if MOST relays are as slow as mine that it creates an issue. I'm one node in thousands (potentially tens or hundreds of thousands if/when Bitcoin goes mainstream). And I'm an individual. There's no reason at all for me to run a full node from my home, except to have my own trusted and validated copy of the blockchain on a computer I control directly. I don't need to act as a relay for that and as long as I can download blocks faster than they are created I'm fine. Also, I can easily afford a VPS server or several to run full nodes as relays if I am feeling altruistic. It's actually cheaper for me to lease a VPS than to keep my own home PC on 24/7, which is why I have 2 of them. And as a business, the cost of a server and bandwidth to run a full node is a drop in the bucket. I'm involved in several projects where we have full nodes running on leased servers with multiple 1Gbps connections. It's an almost zero cost. Those nodes could handle 20MB blocks today without thinking about it, and I'm sure our nodes are just a few amongst thousands just like them. I'm not at all concerned about the network being too centralized. What concerns me is the fact that we are using edge cases like my home PC as a lame excuse to debate expanding the capacity of the network. -- *James G. Phillips IV* https://plus.google.com/u/0/113107039501292625391/posts http://www.linkedin.com/in/ergophobe *Don't bunt. Aim out of the ball park. Aim for the company of immortals. -- David Ogilvy* *This message was created with 100% recycled electrons. Please think twice before printing.* On Mon, May 25, 2015 at 10:02 PM, Thy Shizzle thyshiz...@outlook.com wrote: Indeed Jim, your internet connection makes a good reason why I don't like 20mb blocks (right now). It would take you well over a minute to download the block before you could even relay it on, so much slow down in propagation! Yes I do see how decreasing the time to create blocks is a bit of a band-aid fix, and to use tge term I've seen mentioned here kicking the can down the road I agree that this is doing this, however as you say bandwidth is our biggest enemy right now and so hopefully by the time we exceed the capacity gained by the decrease in block time, we can then look to bump up block size because hopefully 20mbps connections will be baseline by then etc. -- From: Jim Phillips j...@ergophobia.org Sent: 26/05/2015 12:53 PM To: Thy Shizzle thyshiz...@outlook.com Cc: Mike Hearn m...@plan99.net; Bitcoin Dev bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] No Bitcoin For You Frankly I'm good with either way. I'm definitely in favor of faster confirmation times. The important thing is that we need to increase the amount of transactions that get into blocks over a given time frame to a point that is in line with what current technology can handle. We can handle WAY more than we are doing right now. The Bitcoin network is not currently Disk, CPU, or RAM bound.. Not even close. The metric we're closest to being restricted by would be Network bandwidth. I live in a developing country. 2Mbps is a typical broadband speed here (although 5Mbps and 10Mbps connections are affordable). That equates to about 17MB per minute, or 170x more capacity than what I need to receive a full copy of the blockchain if I only talk to one peer. If I relay to say 10 peers, I can still handle 17x larger block sizes on a slow 2Mbps connection. Also, even if we reduce the difficulty so that we're doing 1MB blocks every minute, that's still only 10MB every 10 minutes. Eventually we're going to have to increase that, and we can only reduce the confirmation period so much. I think someone once said 30 seconds or so is about the shortest period you can practically achieve. -- *James G. Phillips IV* https://plus.google.com/u/0/113107039501292625391/posts http://www.linkedin.com/in/ergophobe *Don't bunt. Aim out of the ball park. Aim for the company of immortals. -- David Ogilvy * *This message was created with 100% recycled electrons. Please think twice before printing.* On Mon, May 25, 2015 at 9:30 PM, Thy Shizzle thyshiz...@outlook.com wrote: Nah don't make blocks 20mb, then you are slowing down block propagation and blowing out conf tikes as a result. Just decrease the time it takes to make a 1mb block, then you still see the same propagation times today and just increase the transaction throughput. -- From: Jim Phillips j...@ergophobia.org Sent: 26/05/2015 12:27 PM To: Mike Hearn m...@plan99.net Cc: Bitcoin Dev bitcoin-development@lists.sourceforge.net Subject: Re
Re: [Bitcoin-development] No Bitcoin For You
Incidentally, even once we have the Internet of Things brought on by 21, Inc. or whoever beats them to it, I would expect the average home to have only a single full node hub receiving the blockchain and broadcasting transactions created by all the minor SPV connected devices running within the house. The in-home full node would be peered with high bandwidth full-node relays running at the ISP or in the cloud. There are more than enough ISPs and cloud compute providers in the world such that there should be no concern at all about centralization of relays. Full nodes could some day become as ubiquitous on the Internet as authoritative DNS servers. And just like DNS servers, if you don't trust the nodes your ISP creates or it's too slow or censors transactions, there's nothing preventing you from peering with nodes hosted by the Googles or OpenDNSs out there, or running your own if you're really paranoid and have a few extra bucks for a VPS. -- *James G. Phillips IV* https://plus.google.com/u/0/113107039501292625391/posts http://www.linkedin.com/in/ergophobe *Don't bunt. Aim out of the ball park. Aim for the company of immortals. -- David Ogilvy* *This message was created with 100% recycled electrons. Please think twice before printing.* On Mon, May 25, 2015 at 10:23 PM, Jim Phillips j...@ergophobia.org wrote: I don't see how the fact that my 2Mbps connection causes me to not be a very good relay has any bearing on whether or not the network as a whole would be negatively impacted by a 20MB block. My inability to rapidly propagate blocks doesn't really harm the network. It's only if MOST relays are as slow as mine that it creates an issue. I'm one node in thousands (potentially tens or hundreds of thousands if/when Bitcoin goes mainstream). And I'm an individual. There's no reason at all for me to run a full node from my home, except to have my own trusted and validated copy of the blockchain on a computer I control directly. I don't need to act as a relay for that and as long as I can download blocks faster than they are created I'm fine. Also, I can easily afford a VPS server or several to run full nodes as relays if I am feeling altruistic. It's actually cheaper for me to lease a VPS than to keep my own home PC on 24/7, which is why I have 2 of them. And as a business, the cost of a server and bandwidth to run a full node is a drop in the bucket. I'm involved in several projects where we have full nodes running on leased servers with multiple 1Gbps connections. It's an almost zero cost. Those nodes could handle 20MB blocks today without thinking about it, and I'm sure our nodes are just a few amongst thousands just like them. I'm not at all concerned about the network being too centralized. What concerns me is the fact that we are using edge cases like my home PC as a lame excuse to debate expanding the capacity of the network. -- *James G. Phillips IV* https://plus.google.com/u/0/113107039501292625391/posts http://www.linkedin.com/in/ergophobe *Don't bunt. Aim out of the ball park. Aim for the company of immortals. -- David Ogilvy* *This message was created with 100% recycled electrons. Please think twice before printing.* On Mon, May 25, 2015 at 10:02 PM, Thy Shizzle thyshiz...@outlook.com wrote: Indeed Jim, your internet connection makes a good reason why I don't like 20mb blocks (right now). It would take you well over a minute to download the block before you could even relay it on, so much slow down in propagation! Yes I do see how decreasing the time to create blocks is a bit of a band-aid fix, and to use tge term I've seen mentioned here kicking the can down the road I agree that this is doing this, however as you say bandwidth is our biggest enemy right now and so hopefully by the time we exceed the capacity gained by the decrease in block time, we can then look to bump up block size because hopefully 20mbps connections will be baseline by then etc. -- From: Jim Phillips j...@ergophobia.org Sent: 26/05/2015 12:53 PM To: Thy Shizzle thyshiz...@outlook.com Cc: Mike Hearn m...@plan99.net; Bitcoin Dev bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] No Bitcoin For You Frankly I'm good with either way. I'm definitely in favor of faster confirmation times. The important thing is that we need to increase the amount of transactions that get into blocks over a given time frame to a point that is in line with what current technology can handle. We can handle WAY more than we are doing right now. The Bitcoin network is not currently Disk, CPU, or RAM bound.. Not even close. The metric we're closest to being restricted by would be Network bandwidth. I live in a developing country. 2Mbps is a typical broadband speed here (although 5Mbps and 10Mbps connections are affordable). That equates to about 17MB per minute, or 170x more capacity than what I need to receive
Re: [Bitcoin-development] Zero-Conf for Full Node Discovery
Do any wallets actually do this yet? On May 25, 2015 11:37 PM, Matt Whitlock b...@mattwhitlock.name wrote: This is very simple to do. Just ping the all nodes address (ff02::1) and try connecting to TCP port 8333 of each node that responds. Shouldn't take but more than a few milliseconds on any but the most densely populated LANs. On Monday, 25 May 2015, at 11:06 pm, Jim Phillips wrote: Is there any work being done on using some kind of zero-conf service discovery protocol so that lightweight clients can find a full node on the same LAN to peer with rather than having to tie up WAN bandwidth? I envision a future where lightweight devices within a home use SPV over WiFi to connect with a home server which in turn relays the transactions they create out to the larger and faster relays on the Internet. In a situation where there are hundreds or thousands of small SPV devices in a single home (if 21, Inc. is successful) monitoring the blockchain, this could result in lower traffic across the slow WAN connection. And yes, I realize it could potentially take a LOT of these devices before the total bandwidth is greater than downloading a full copy of the blockchain, but there's other reasons to host your own full node -- trust being one. -- *James G. Phillips IV* https://plus.google.com/u/0/113107039501292625391/posts http://www.linkedin.com/in/ergophobe *Don't bunt. Aim out of the ball park. Aim for the company of immortals. -- David Ogilvy* *This message was created with 100% recycled electrons. Please think twice before printing.* -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Zero-Conf for Full Node Discovery
Is there any work being done on using some kind of zero-conf service discovery protocol so that lightweight clients can find a full node on the same LAN to peer with rather than having to tie up WAN bandwidth? I envision a future where lightweight devices within a home use SPV over WiFi to connect with a home server which in turn relays the transactions they create out to the larger and faster relays on the Internet. In a situation where there are hundreds or thousands of small SPV devices in a single home (if 21, Inc. is successful) monitoring the blockchain, this could result in lower traffic across the slow WAN connection. And yes, I realize it could potentially take a LOT of these devices before the total bandwidth is greater than downloading a full copy of the blockchain, but there's other reasons to host your own full node -- trust being one. -- *James G. Phillips IV* https://plus.google.com/u/0/113107039501292625391/posts http://www.linkedin.com/in/ergophobe *Don't bunt. Aim out of the ball park. Aim for the company of immortals. -- David Ogilvy* *This message was created with 100% recycled electrons. Please think twice before printing.* -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] A suggestion for reducing the size of the UTXO database
I feel your pain. I've had the same thing happen to me in the past. And I agree it's more likely to occur with my proposed scheme but I think with HD wallets there will still be UTXOs left unspent after most transactions since, for privacy sake it's looking for the smallest set of addresses that can be linked. On May 9, 2015 9:11 PM, Matt Whitlock b...@mattwhitlock.name wrote: Minimizing the number of UTXOs in a wallet is sometimes not in the best interests of the user. In fact, quite often I've wished for a configuration option like Try to maintain _[number]_ UTXOs in the wallet. This is because I often want to make multiple spends from my wallet within one block, but spends of unconfirmed inputs are less reliable than spends of confirmed inputs, and some wallets (e.g., Andreas Schildbach's wallet) don't even allow it - you can only spend confirmed UTXOs. I can't tell you how aggravating it is to have to tell a friend, Oh, oops, I can't pay you yet. I have to wait for the last transaction I did to confirm first. All the more aggravating because I know, if I have multiple UTXOs in my wallet, I can make multiple spends within the same block. On Saturday, 9 May 2015, at 12:09 pm, Jim Phillips wrote: Forgive me if this idea has been suggested before, but I made this suggestion on reddit and I got some feedback recommending I also bring it to this list -- so here goes. I wonder if there isn't perhaps a simpler way of dealing with UTXO growth. What if, rather than deal with the issue at the protocol level, we deal with it at the source of the problem -- the wallets. Right now, the typical wallet selects only the minimum number of unspent outputs when building a transaction. The goal is to keep the transaction size to a minimum so that the fee stays low. Consequently, lots of unspent outputs just don't get used, and are left lying around until some point in the future. What if we started designing wallets to consolidate unspent outputs? When selecting unspent outputs for a transaction, rather than choosing just the minimum number from a particular address, why not select them ALL? Take all of the UTXOs from a particular address or wallet, send however much needs to be spent to the payee, and send the rest back to the same address or a change address as a single output? Through this method, we should wind up shrinking the UTXO database over time rather than growing it with each transaction. Obviously, as Bitcoin gains wider adoption, the UTXO database will grow, simply because there are 7 billion people in the world, and eventually a good percentage of them will have one or more wallets with spendable bitcoin. But this idea could limit the growth at least. The vast majority of users are running one of a handful of different wallet apps: Core, Electrum; Armory; Mycelium; Breadwallet; Coinbase; Circle; Blockchain.info; and maybe a few others. The developers of all these wallets have a vested interest in the continued usefulness of Bitcoin, and so should not be opposed to changing their UTXO selection algorithms to one that reduces the UTXO database instead of growing it. From the miners perspective, even though these types of transactions would be larger, the fee could stay low. Miners actually benefit from them in that it reduces the amount of storage they need to dedicate to holding the UTXO. So miners are incentivized to mine these types of transactions with a higher priority despite a low fee. Relays could also get in on the action and enforce this type of behavior by refusing to relay or deprioritizing the relay of transactions that don't use all of the available UTXOs from the addresses used as inputs. Relays are not only the ones who benefit the most from a reduction of the UTXO database, they're also in the best position to promote good behavior. -- *James G. Phillips IV* https://plus.google.com/u/0/113107039501292625391/posts *Don't bunt. Aim out of the ball park. Aim for the company of immortals. -- David Ogilvy* *This message was created with 100% recycled electrons. Please think twice before printing.* -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] A suggestion for reducing the size of the UTXO database
Makes sense.. So with that said, I'd propose the following criteria for selecting UTXOs: 1. Select the smallest possible set of addresses that can be linked in order to come up with enough BTC to send to the payee. 2. Given multiple possible sets, select the one that has the largest number of UTXOs. 3. Given multiple possible sets, choose the one that contains the largest amount of total BTC. 4. Given multiple possible sets, select the one that destroys the most bitcoin days. 5. If there's still multiple possible sets, just choose one at random. Once the final set of addresses has been identified, use ALL UTXOs from that set, sending appropriate outputs to the recipient(s), a new change address, and a mining fee. Miners should be cognisant of and reward the fact that the user is making an effort to consolidate UTXOs. They can easily spot these transactions by looking at whether all possible UTXOs from each input addresses have been used. Since most miners use Bitcoin Core, and its defaults, this test can be built into Bitcoin Core's logic for determining which transactions to include when mining a block. -- *James G. Phillips IV* https://plus.google.com/u/0/113107039501292625391/posts http://www.linkedin.com/in/ergophobe *Don't bunt. Aim out of the ball park. Aim for the company of immortals. -- David Ogilvy* *This message was created with 100% recycled electrons. Please think twice before printing.* On Sat, May 9, 2015 at 3:38 PM, Pieter Wuille pieter.wui...@gmail.com wrote: Miners do not care about the age of a UTXO entry, apart for two exceptions. It is also economically irrelevant. * There is a free transaction policy, which sets a small portion of block space aside for transactions which do not pay sufficient fee. This is mostly an altruistic way of encouraging Bitcoin adoption. As a DoS prevention mechanism, there is a requirement that these free transactions are of sufficient priority (computed as BTC-days-destroyed per byte), essentially requiring these transactions to consume another scarce resource, even if not money. * Coinbase transaction outputs can, as a consensus rule, only be spent after 100 confirmations. This is to prevent random reorganisations from invalidating transactions that spend young coinbase transactions (which can't move to the new chain). In addition, wallets also select more confirmed outputs first to consume, for the same reason. On May 9, 2015 1:20 PM, Raystonn rayst...@hotmail.com wrote: That policy is included in Bitcoin Core. Miners use it because it is the default. The policy was likely intended to help real transactions get through in the face of spam. But it favors those with more bitcoin, as the priority is determined by amount spent multiplied by age of UTXOs. At the very least the amount spent should be removed as a factor, or fees are unlikely to ever be paid by those who can afford them. We can reassess the role age plays later. One change at a time is better. On 9 May 2015 12:52 pm, Jim Phillips j...@ergophobia.org wrote: On Sat, May 9, 2015 at 2:43 PM, Raystonn rayst...@hotmail.com wrote: How about this as a happy medium default policy: Rather than select UTXOs based solely on age and limiting the size of the transaction, we select as many UTXOs as possible from as few addresses as possible, prioritizing which addresses to use based on the number of UTXOs it contains (more being preferable) and how old those UTXOs are (in order to reduce the fee)? If selecting older UTXOs gives higher priority for a lesser (or at least not greater) fee, that is an incentive for a rational user to use the older UTXOs. Such policy needs to be defended or removed. It doesn't support privacy or a reduction in UTXOs. Before starting this thread, I had completely forgotten that age was even a factor in determining which UTXOs to use. Frankly, I can't think of any reason why miners care how old a particular UTXO is when determining what fees to charge. I'm sure there is one, I just don't know what it is. I just tossed it in there as homage to Andreas who pointed out to me that it was still part of the selection criteria. -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] A suggestion for reducing the size of the UTXO database
On Sat, May 9, 2015 at 1:45 PM, Peter Todd p...@petertodd.org wrote: On Sat, May 09, 2015 at 12:09:32PM -0500, Jim Phillips wrote: The vast majority of users are running one of a handful of different wallet apps: Core, Electrum; Armory; Mycelium; Breadwallet; Coinbase; Circle; Blockchain.info; and maybe a few others. The developers of all these wallets have a vested interest in the continued usefulness of Bitcoin, and so should not be opposed to changing their UTXO selection algorithms to one that reduces the UTXO database instead of growing it. You can't assume that UTXO growth will be driven by walles at all; the UTXO set's global consensus functionality is incredibly useful and will certainly be used by all manner of applications, many having nothing to do with Bitcoin. You're correct in this point. Future UTXO growth will be coming from all directions. But I'm a believer in the idea that whatever can be done should be done. If we get Bitcoin devs into the mindset now that UTXOs are expensive to those that have to store them, and that they should be good netizens and do what they can to limit them, then hopefully that will ideal will be passed down to future developers. I don't believe consolidating UTXOs in the wallet is the only solution.. I just think it is a fairly easy one to implement, and can only help the problem from getting worse in the future. -- *James G. Phillips IV* https://plus.google.com/u/0/113107039501292625391/posts http://www.linkedin.com/in/ergophobe *Don't bunt. Aim out of the ball park. Aim for the company of immortals. -- David Ogilvy* *This message was created with 100% recycled electrons. Please think twice before printing.* -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] A suggestion for reducing the size of the UTXO database
On Sat, May 9, 2015 at 2:00 PM, Andreas Schildbach andr...@schildbach.de wrote: Actually your assumption is wrong. Bitcoin Wallet (and I think most, if not all, other bitcoinj based wallets) picks UTXO by age, in order to maximize priority. So it keeps the number of UTXOs low, though not as low as if it would always pick *all* UTXOs. Is it not fair to say though that UTXO database growth is not considered when selecting the UTXOs to use? And that size of transaction is a priority if not the top priority? -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] A suggestion for reducing the size of the UTXO database
On Sat, May 9, 2015 at 2:06 PM, Pieter Wuille pieter.wui...@gmail.com wrote: It's a very complex trade-off, which is hard to optimize for all use cases. Using more UTXOs requires larger transactions, and thus more fees in general. Unless the miner determines that the reduction in UTXO storage requirements is worth the lower fee. There's no protocol level enforcement of a fee as far as I understand it. It's enforced by the miners and their willingness to include a transaction in a block. In addition, it results in more linkage between coins/addresses used, so lower privacy. Not if you only select all the UTXOs from a single address. A wallet that is geared more towards privacy minded individuals may want to reduce the amount of address linkage, but a wallet geared towards the general masses probably won't have to worry so much about that. The only way you can guarantee an economical reason to keep the UTXO set small is by actually having a consensus rule that punishes increasing its size. There's an economical reason right now to keeping the UTXO set small. The smaller it is, the easier it is for the individual to run a full node. The easier it is to run a full node, the faster Bitcoin will spread to the masses. The faster it spreads to the masses, the more valuable it becomes. -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] A suggestion for reducing the size of the UTXO database
On Sat, May 9, 2015 at 2:12 PM, Patrick Mccorry (PGR) patrick.mcco...@newcastle.ac.uk wrote: Not necessarily. If you want to ensure privacy, you could limit the selection of UTXOs to a single address, and even go so far as to send change back to that same address. This wouldn't be as effective as combining the UTXOs from multiple addresses, but it would help. The key is to do everything that can be done when building a transaction to ensure that as many inputs as possible are consolidated into as few outputs as possible. I would agree if you have multiple utxo for a single address then it makes sense since there is no privacy loss. However sending the change back to the same address would damage privacy (Hive does this) as it is then obvious from looking at the transaction which output is change and which output is sending funds. I tend to agree with you here. But the change output could just as easily be sent to a new change address. Also not everyone is concerned with their own privacy, and I'm not aware of any HD-wallet implementations that won't already combine inputs from multiple addresses within that wallet without user input. For people who do not care for privacy then it would work fine. But adding it into the wallet as default behaviour would deter those who do care for privacy - and making it a customisable option just adds complexity for the users. Wallets do need to combine utxo at times to spend bitcoins which is how people can be tracked today, using the minimum set of utxo tries to reduce the risk. Different wallets are targeted at different demographics. Some are geared towards more mainstream users (for whom the privacy issue is less a concern) and some (such as DarkWallet) are geared more towards the privacy advocates. These wallets may choose to set their defaults at oposite ends of the spectrum as to how they choose to select and link addresses and UTXOs, but they can all improve on their current algorithms and promote some degree of consolidation. Additionally, large wallets that have lots of addresses owned by multiple users like exchanges, blockchain.info, and Coinbase can consolidate UTXOs very effectively when building transactions That's true - I'm not sure how they would feel about it though. I imagine they probably are already to minimise key management. That's what these discussions are for. Hopefully this thread will be seen by developers of these wallets and give them something to consider. -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] A suggestion for reducing the size of the UTXO database
On Sat, May 9, 2015 at 2:25 PM, Raystonn rayst...@hotmail.com wrote: Lack of privacy is viral. We shouldn't encourage policy in most wallets that discourages privacy. It adversely affects privacy across the entire network. How about this as a happy medium default policy: Rather than select UTXOs based solely on age and limiting the size of the transaction, we select as many UTXOs as possible from as few addresses as possible, prioritizing which addresses to use based on the number of UTXOs it contains (more being preferable) and how old those UTXOs are (in order to reduce the fee)? -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] A suggestion for reducing the size of the UTXO database
On Sat, May 9, 2015 at 2:43 PM, Raystonn rayst...@hotmail.com wrote: How about this as a happy medium default policy: Rather than select UTXOs based solely on age and limiting the size of the transaction, we select as many UTXOs as possible from as few addresses as possible, prioritizing which addresses to use based on the number of UTXOs it contains (more being preferable) and how old those UTXOs are (in order to reduce the fee)? If selecting older UTXOs gives higher priority for a lesser (or at least not greater) fee, that is an incentive for a rational user to use the older UTXOs. Such policy needs to be defended or removed. It doesn't support privacy or a reduction in UTXOs. Before starting this thread, I had completely forgotten that age was even a factor in determining which UTXOs to use. Frankly, I can't think of any reason why miners care how old a particular UTXO is when determining what fees to charge. I'm sure there is one, I just don't know what it is. I just tossed it in there as homage to Andreas who pointed out to me that it was still part of the selection criteria. -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Electrum 2.0 has been tagged
The wallet words system isn't perfect for sure but it does help the user in two main ways: 1) Assuming wallet devs ensure forward compatibility for _their_ wallet the user knows they can recover their bitcoins using the same wallet software in case of a Bad Thing Happening. 2) To an imperfect degree, they can transfer/ recover their bitcoins that are stored in Wallet X into Wallet Y. We need to give them guidance on how to do this. I think it is up to each wallet team to explain to their users clearly how they can do this in their help. It's only good manners to show your guests where the fire exits are. It can be a simple help page saying: If you want to transfer your bitcoin out of MultiBit HD to Lighthouse, do this, this and this. If you want to use the Trezor wallet you created in MultiBit HD on myTrezor.com, do this, this and this. That way users have clear instructions on how to recover their bitcoins. Users don't care about BIP this or BIP that but they REALLY DO CARE about keeping their bitcoins. -- http://bitcoin-solutions.co.uk On Wed, Mar 11, 2015, at 05:14 PM, Mike Hearn wrote: Sigh. The wallet words system is turning into kind of a mess. I thought the word list is in fact not a fixed part of the spec, because the entropy is a hash of the words. But perhaps I'm misunderstanding something. The main problem regular SPV wallets have with BIP39 is that there is no birth time included in the data. Therefore we must ask users to write down a timestamp as well, so we know where to start rescanning the chain. It sounds like the Electrum version doesn't fix this, so now we have at least FIVE incompatible results from a 12 word list: - Electrum v2 with a version number but no date - myTREZOR with no version and no date and BIP44 key derivation. Some seeds I believe are now being generated with 24 words instead of 12. - MultiBit HD with no version and a date in a custom form that creates non-date-like codes you are expected to write down. I think BIP32 and BIP44 are both supported (sorta). - GreenAddress with no version, no date and BIP32 - Other bitcoinj based wallets, with no version and a date written down in normal human form, BIP32 only. I really hope we can recover from this somehow because otherwise all wallets will have to provide the user with a complicated matrix of possibilities and software combinations, and in practice many won't bother so these word combinations will actually end up being wallet specific for no particularly good reason, just very minor details like the presence or absence of single fields. It feels like we somehow fell flat on our faces just before the finishing line. This is deeply unfortunate. Compatibility and UX consistency is important! Currently, I don't have any bright ideas for how to get everyone back onto the same page with a fully compatible system that is acceptable to all. If anyone else has suggestions, I'm all ears. -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Electrum 2.0 has been tagged
Great to see Electrum 2.0 tagged ! It's been a long road I know. Congratulations to ThomasV and all the other Electrum contributors. :-) Jim -- http://bitcoin-solutions.co.uk On Mon, Mar 2, 2015, at 03:37 PM, Mike Hearn wrote: Congrats Thomas! Glad to see Electrum 2 finally launch. * New seed derivation method (not compatible with BIP39). Does this mean a 12 words wallet created by Electrum won't work if imported into some other wallet that supports BIP39? Vice versa? This seems unfortunate. I guess if seeds are being represented with 12 words consistently, people will expect them to work everywhere. -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP32 wallet structure in use? Remove it?
Oh dear. For reasons that are perfectly reasonable we are close to losing any chance of intra-client HD compatibility for BIP32 wallets. In the next 12 months there will probably be collectively millions of users of our new wallets. I don't want them to suffer from vendor lockin. Can we not agree on a lowest common denominator that we agree to support ? An HD Basic if you like. For entry level users we can keep things simple and any HD Basic bitcoin will be fully interoperable. Sure, if you use anything fancy you'll be locked in to a particular wallet but a lot of users just want somewhere safe to put their bitcoin, spend it and receive it. I appreciate standising everything is very difficult (if not impossible) but if we don't have a minimum of interoperability I think we'll do our users a disservice. On Fri, Apr 25, 2014, at 11:23 AM, Andreas Schildbach wrote: Does anyone use or plan to use the wallet structure part of the BIP32 document? I suggest removing it from the document and maybe instead point at BIP43. That new specification proposal just defines a purpose and leaves everything else to the inventor of that purpose. The idea it that over time a standard will evolve naturally rather than top-down. https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki I'd volunteer to submit a pull request if I can see some level of consent here. -- 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 -- http://bitcoin-solutions.co.uk -- 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] New BIP32 structure
Good to hear the bip32 wallet structure is _so_ close to being standardised. For MultiBit HD, we have put in support for 12/18/24 words but have the UI 'suggest' to use 12. You can see this on the wallet creation wizard Gary recently blogged about: https://multibit.org/blog/2014/03/26/multibit-hd-welcome-wizard.html There's a little combo for the seed length, with 12 as the default. @Thomas. You mention gaps. We are creating new addresses on the UI in a panel marked 'Request' where the user also types in a QR code label and a note to themselves. This gets stored away as a first class 'PaymentRequest'. The UI 'suggests' that each address is used once. There will be some gaps (where the payment request is never paid) but we aren't bulk creating addresses. I am hoping this shouldn't cause Electrum a problem. We are also storing a timestamp (the number of days since the genesis block) to help wallet restore but that is SPV specific. On Thu, Mar 27, 2014, at 01:49 PM, Thomas Voegtlin wrote: Le 27/03/2014 13:49, Mike Hearn a écrit : IP32 allows for a range of entropy sizes and it so happens that they picked 256 bits instead of 128 bits. I'd have thought that there is a right answer for this. 2^128 should not be brute forceable, and longer sizes have a cost in terms of making the seeds harder to write down on paper. So should this be a degree of freedom? Here is what I understand: 2^128 iterations is not brute forcable today, and will not be for the foreseeable future. An EC pubkey of length n can be forced in approximately 2^(n/2) iterations (see http://ecc-challenge.info/) Thus, Bitcoin pubkeys, which are 256 bits, would require 2^128 iterations. This is why unused addresses (160 bits hash) are better protected than already used ones. However, people tend to believe that a public key of size n requires 2^n iterations. This belief might have been spread by this popular image: https://bitcointalk.org/index.php?topic=508880.msg5616146#msg5616146 -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- http://bitcoin-solutions.co.uk -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Base-32 error correction coding
Mark Friedenbach wrote: What follows is a proposed BIP for human-friendly base-32 serialization with error correction encoding. ... 2. Automatic correction of up to 1 transcription error per 31 coded digits (130 bits of payload data). For a 256-bit hash or secret key, this enables seamless recovery from up to two transcription errors so long as they occur in separate halves of the coded representation. Can we do better than correcting single transcription errors? I'd imagine that transposition of two adjacent characters, or insertion or deletion of a single character, would be very common. At the very least, a transposition could be corrected by interleaving the two halves of the coded representation, e.g.: ABABABABABABABABABABABABABABABABABABABABABABABABABABABABABABAB insead of AAABBB Jim -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fees UI warning
Yes I saw that on reddit too. I think it applies mainly to custom transactions rather than where fees are calculated automatically. Another variant of not understanding change that loses people's bitcoins I have encountered is: 1) Import a private key of a brainwallet/ paper wallet. 2) Send a small amount of bitcoin from that key. 3) The user then secure deletes all copies of the wallet 'for security'. If they are not careful they can delete a change address with funds on it. In MultiBit I have tried to reduce this possibility by: 1) Hiding the ability to delete wallet (in the next version I am removing it entirely) 2) There is always a single key in a new wallet. When a user imports a key then that makes two. I always send the change to the second address, if it is available. (This is bad for privacy but at least lessens the chances that the funds become lost). If users are determined to use a brain wallet and secure delete every copy of the wallet after they use them you cannot stop them (it is their machine after all) But these two options help lessen the chance of bitcoin loss if they do. For the HD version of MultiBit we are removing the import of individual private keys entirely and only supporting HD addresses, primarily for safety reasons. Jim On Mon, Dec 16, 2013, at 10:13 AM, Drak wrote: Not sure if this is the right place, but since a few wallet authors congregate here I though it might be the best place. It seems every once in a while you see stories of people accidentally paying huge fees. Today I read about a man who paid a 20.14BTC fee for a 0.05 BTC transaction[1], oops. There was another recently where someone paid a fee of about 200BTC which fortunately the pool operator refunded. It just occurs to me this kind of sad story could be averted if wallets implemented a confirmation box if the fee amount seems crazy - for example, if it's 10x what the default fee should be, or if it's greater than x% of the sending amount. the fee seems unusually high, are you really sure you want to pay X in fees? I realise the exact details of this might need to be fleshed out given we want flexible fees, but it should be pretty simple to agree with what looks like an unusually large fee according to the going rate. Drak [1] http://www.reddit.com/r/Bitcoin/comments/1syu3h/i_lost_all_my_bitcoins_in_an_erroneous/ -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- http://bitcoin-solutions.co.uk -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Safe auto-updating
One approach you could use would be to use bitcoin signing on a list of the build artifacts together with their SHA256 hashes. If you have a look at the MultiBit release notes you get the overall idea: https://multibit.org/releases/multibit-0.5.13/release.txt Currently these aren't machine readable but you can imagine having a machine readable statement with: + a list of the files in the build + their SHA256 hashes + the above bitcoin signed by multiple signatures e.g. 2 of 3 The client can then download the file, check the signature, check the hashes and knows which files to download. The acceptable Bitcoin addresses for signatures would be a whitelist in the client code. On Mon, Aug 5, 2013, at 05:47 PM, Alan Reiner wrote: Indeed. You can hardcode a distributor public key in the software, and client software will only trust signed data from that key. Of course, the private key for that data is not kept on the server distributing the signed checksums. Ideally it would be kept offline, and the couple-times-per-year that you actually execute an upgrade, you sign the new checksums offline and upload the signed checksum to the distribution server. Then even if the server is compromised, the client-side software will not accept a bogus checksum because it won't bear the right signature. If you do this, it would be good to also have some kind of revocation process that can be used in the event of the offline key being compromised. You won't be able to switch keys, as that would defeat the purpose (the attacker who compromises the offline key could just issue a replacement with his own). Instead, it would be an irreversible broadcast that would force clients to start rejecting updates from that key. If the key is compromised (and find out), you broadcast the revocation and the users will stop auto-updating, and be given a warning that they should manually upgrade the software through trusted channels. It's not failproof, but it's a decent way to minimize damage if you discover compromise early enough. -Alan On 08/05/2013 11:54 AM, Daniel F wrote: If you want package authentication, you should at least throw in some digital signing, not just a checksum. With a compromised host, both the checksum and binaries can be changed undetectably, but if there's a signature made by a key that is not kept on the host, there's no way to fake a valid binary. There may be other issues people would want to bring up, but surely just a checksum is not sufficient. on 08/05/2013 10:39 AM Wendell said the following: For usability purposes, we at Hive would like to have an auto-updater in our wallet app. What is a safe way to do this? I understand that Bitcoin-QT lacks such an updater for security reasons... Has been thought out in more detail since that decision was made? We have been toying around with the idea of placing one server behind a Tor hidden service, whose only function is to output a checksum of the update package. The theory is that if it is well-secured, it will at least be immune to tampering at the physical hosting level. Any thoughts or advice about any of this? -wendell grabhive.com | twitter.com/grabhive | gpg: 6C0C9411 -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk
Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org
For those interested in these things the multibit.org server is a dedicated server hosted by the German company http://www.server4you.net. It is physically located in the delightful city of Strasbourg, just on the French side of the French German border. On Tue, Jul 9, 2013, at 03:28 PM, Mike Hearn wrote: SourceForge has a horrible UI and blocks some countries. It also exposes us to a large and potentially hackable mirror network. Whilst we're not bandwidth constrained on our own servers, let's try and keep using them. On Tue, Jul 9, 2013 at 4:06 PM, Jeff Garzik jgar...@bitpay.com wrote: On Tue, Jul 9, 2013 at 10:00 AM, Daniel F nanot...@gmail.com wrote: on 07/09/2013 06:56 AM Jim said the following: + it will bump up the MultiBit download from about 11MB to 30-40MB (I think). This drops the maximum copies of MultiBit the multibit.org server can deliver per day from around 90,000 to 30,000ish. The multibit.org server maxes out at 1 TB of bandwidth per day. You could host your downloads on sourceforge and achieve virtually unlimited capacity. Indeed. There is no reason to worry about download bandwidth these days, for open source software downloads. Move the downloads to a site where such worries do not exist. -- Jeff Garzik Senior Software Engineer and open source evangelist BitPay, Inc. https://bitpay.com/ -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- https://multibit.orgMoney, reinvented -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org
Yeah email jim' was never going to work so I have bumped up MultiBit support (a bit) by: + having a dedicated Support page on the website https://multibit.org/support.html It has fixes and support notes for the most common gotchas. + the in-app help also now has a 'Support' section with Troubleshooting' and the commonest gotchas. I've also written more help to cover as much as possible. + Failing that people are directed first to bitcoin.stackchange.com (I have a notification set up for the 'multibit' keyword. + Then finally users are directed to the github issues to search existing or raise a new issue. Gary and Tim often chip in on there to close issues down as well as me. On Sun, Jun 30, 2013, at 12:42 PM, Mike Hearn wrote: Sounds like we have consensus, Saivann, shall we do it? I'm also going to ask Theymos again to relax the newbie restrictions for the alt client forums. It's probably too hard to get support at the moment and email jim doesn't scale at all. On Fri, Jun 28, 2013 at 4:24 PM, Gavin Andresen gavinandre...@gmail.com wrote: I vote yes to have MultiBit replace Bitcoin-Qt as the recommended desktop wallet app. I think most users will be happier with it. If I'm wrong, it is easy to change back. -- 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 -- 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 -- https://multibit.orgMoney, reinvented -- 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] Proposal: MultiBit as default desktop client on bitcoin.org
There are already descriptions as you describe on: http://bitcoin.org/en/choose-your-wallet. If you hover over any of the wallet icons you get a description and a link. People being people, we find in practice that the very first wallet link on the page is what the majority of new users click. On Fri, Jun 28, 2013, at 09:37 PM, Bill Hees wrote: There are good, valid arguments in support of promoting both the reference client, Bitcoin-QT, and for offering a lighter-weight alternative. Why not outline these arguments on bitcoin.org and provide links to each; or even links to a variety of alternative wallet solutions alongside descriptions of their respective benefits and drawbacks? Is there an advantage to having a singular recommended client? On Fri, Jun 28, 2013 at 1:35 PM, Bill Hees billh...@gmail.com wrote: There are good, valid arguments in support of promoting both the reference client, Bitcoin-QT, and for offering a lighter-weight alternative. Why not outline these arguments on bitcoin.org and provide links to each; or even links to a variety of alternative wallet solutions alongside descriptions of their respective benefits and drawbacks? Is there an advantage to having a singular recommended client? On Fri, Jun 28, 2013 at 7:24 AM, Gavin Andresen gavinandre...@gmail.comwrote: I vote yes to have MultiBit replace Bitcoin-Qt as the recommended desktop wallet app. I think most users will be happier with it. If I'm wrong, it is easy to change back. -- 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 -- 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 -- https://multibit.orgMoney, reinvented -- 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
[Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org
Hello Everybody, Over the last few months we have been steadily adding functionality to MultiBit including: + encrypted wallets + sign and verify message + stability improvements and bug fixes. As a result of these efforts I think MultiBit is now suitable for the entry level Bitcoin user. I propose that we put MultiBit as the default desktop client on the bitcoin.org Choose your wallet page. I think a typical new user comes to bitcoin.org from a google search or a Bitcoin news article. We want them to peruse the bitcoin.org site and try out a wallet. They should be able to get MultiBit up and running in a tea break. Then perhaps they get a colleague to send them some bitcoin from an Android phone by zapping a QR code. We say: Welcome to the Bitcoin economy ! There is plenty MultiBit cannot do of course. However if in the first ten minutes we get the new user interested there is a good chance they will go on to explore other Bitcoin wallets and solutions. Let me know if you think this is a good idea (or not!) and if you have any questions. Jim https://multibit.org -- 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] Proposal: MultiBit as default desktop client on bitcoin.org
A few replies, in order of point raised: Jeff: Arguments against multibit default: * Less testing, field experience on desktop Yes this is true - downloads of multibit have typically been around 1/7th to 1/5th of bitcoin-QT downloads. It helps of course that the bitcoinj networking/ object model is also used by Andreas as you note. Greg: I think Mike has squashed the deadlocking problems with reentrant locks (primarily in the Wallet). I haven't seen one in at least a month. We discussed proxy support on the bitcoinj mailing list a while ago and at the time the stumbling block was the Java library used for the networking (Netty) did not support it. Mike or Miron would know better than I if this is still the case. Change address behaviour will improve significantly when HD wallet support goes into multibit/ bitcoinj (I am hoping to get my bit done over the summer). Matija Mazi has been working on a Java impl of HD wallets so it is coming down the pipe but there is a lot to do yet. Connections out from MultiBit are: + 4 bitcoind nodes on port 8333 + multibit.org (188.138.113.201) for help, current version info (and probably more in future) + the currency ticker will make HTTP gets to the source of whichever exchange(s) you have set up e.g MtGox, CampBX. This calls should disappear if you switch the currency conversion and ticker off. I think that is all the connections out I make. Mainly due to the exchanges abruptly changing their APIs and breaking things we are planning to put in intermediate Exchange Data Provider servers. Tim Molter is working on this in his XChange project. That will enable us to patch the server when things change and the multibits in the field won't be affected. There will probably be a couple of these initially for redundancy. Alex: Yes I think most users migrate to blockchain.info or, more recently coinbase.com. They are both good wallets but I'd like to keep Bitcoin as P2P as possible. Luke-Jr I think you are right here on the number of full nodes versus SPV nodes. I don't think we even know yet what are the working ratios of full nodes to SPV nodes. I haven't seen anybody do any analysis on this. I doubt multibit will ever participate in the Bitcoin network other than as an SPV client. All the optimisation is to reduce data traffic - it is effectively a mobile wallet that happens to live on a desktop. It is not really intended to be more than a wallet for regular people to store and spend their bitcoin. In English the nomenclature for direction of the transactions is: Sent to and Received with. To be honest I haven't transliterated the localisation files to check other language packs but the localisers are pretty good in my experience. On Thu, Jun 27, 2013, at 07:41 PM, Gregory Maxwell wrote: On Thu, Jun 27, 2013 at 11:04 AM, Luke-Jr l...@dashjr.org wrote: On Thursday, June 27, 2013 5:30:21 PM Jeff Garzik wrote: * Very real possibility of an overall net reduction of full nodes on P2P network Even a reduction of *nodes at all*, as I've never seen a listening bitcoinj or MultiBit node. :/ Jim, will MultiBit be adding p2p listening support? Without validation listening isn't currently very useful. :( Maybe it could be somewhat more with some protocol additions. -- 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 -- https://multibit.orgMoney, reinvented -- 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] Proposal: MultiBit as default desktop client on bitcoin.org
RE: 141.101.113.245 http://whois.domaintools.com/141.101.113.245 gives it as CloudFlare - I suspect it is protecting Mt Gox when we make our get for currency ticker info. On Thu, Jun 27, 2013, at 08:18 PM, Jim wrote: A few replies, in order of point raised: Jeff: Arguments against multibit default: * Less testing, field experience on desktop Yes this is true - downloads of multibit have typically been around 1/7th to 1/5th of bitcoin-QT downloads. It helps of course that the bitcoinj networking/ object model is also used by Andreas as you note. Greg: I think Mike has squashed the deadlocking problems with reentrant locks (primarily in the Wallet). I haven't seen one in at least a month. We discussed proxy support on the bitcoinj mailing list a while ago and at the time the stumbling block was the Java library used for the networking (Netty) did not support it. Mike or Miron would know better than I if this is still the case. Change address behaviour will improve significantly when HD wallet support goes into multibit/ bitcoinj (I am hoping to get my bit done over the summer). Matija Mazi has been working on a Java impl of HD wallets so it is coming down the pipe but there is a lot to do yet. Connections out from MultiBit are: + 4 bitcoind nodes on port 8333 + multibit.org (188.138.113.201) for help, current version info (and probably more in future) + the currency ticker will make HTTP gets to the source of whichever exchange(s) you have set up e.g MtGox, CampBX. This calls should disappear if you switch the currency conversion and ticker off. I think that is all the connections out I make. Mainly due to the exchanges abruptly changing their APIs and breaking things we are planning to put in intermediate Exchange Data Provider servers. Tim Molter is working on this in his XChange project. That will enable us to patch the server when things change and the multibits in the field won't be affected. There will probably be a couple of these initially for redundancy. Alex: Yes I think most users migrate to blockchain.info or, more recently coinbase.com. They are both good wallets but I'd like to keep Bitcoin as P2P as possible. Luke-Jr I think you are right here on the number of full nodes versus SPV nodes. I don't think we even know yet what are the working ratios of full nodes to SPV nodes. I haven't seen anybody do any analysis on this. I doubt multibit will ever participate in the Bitcoin network other than as an SPV client. All the optimisation is to reduce data traffic - it is effectively a mobile wallet that happens to live on a desktop. It is not really intended to be more than a wallet for regular people to store and spend their bitcoin. In English the nomenclature for direction of the transactions is: Sent to and Received with. To be honest I haven't transliterated the localisation files to check other language packs but the localisers are pretty good in my experience. On Thu, Jun 27, 2013, at 07:41 PM, Gregory Maxwell wrote: On Thu, Jun 27, 2013 at 11:04 AM, Luke-Jr l...@dashjr.org wrote: On Thursday, June 27, 2013 5:30:21 PM Jeff Garzik wrote: * Very real possibility of an overall net reduction of full nodes on P2P network Even a reduction of *nodes at all*, as I've never seen a listening bitcoinj or MultiBit node. :/ Jim, will MultiBit be adding p2p listening support? Without validation listening isn't currently very useful. :( Maybe it could be somewhat more with some protocol additions. -- 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 -- https://multibit.orgMoney, reinvented -- 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 -- https://multibit.orgMoney, reinvented -- 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] Proposal: MultiBit as default desktop client on bitcoin.org
I missed Greg's point on confirmations. It is definitely a challenge to explain/ visualize both: + has the transaction propagated the network ? and + it it confirmed/ buried in a block ? when those words probably don't mean much to the intended audience. The transaction status icons I *think* do it (explained here: https://multibit.org/en/help/v0.5/help_transactions.html). It basically boils down to: 1) triangle or square : bad. 2) filling circle : good 3) tick mark : great. On Thu, Jun 27, 2013, at 08:40 PM, Jim wrote: RE: 141.101.113.245 http://whois.domaintools.com/141.101.113.245 gives it as CloudFlare - I suspect it is protecting Mt Gox when we make our get for currency ticker info. On Thu, Jun 27, 2013, at 08:18 PM, Jim wrote: A few replies, in order of point raised: Jeff: Arguments against multibit default: * Less testing, field experience on desktop Yes this is true - downloads of multibit have typically been around 1/7th to 1/5th of bitcoin-QT downloads. It helps of course that the bitcoinj networking/ object model is also used by Andreas as you note. Greg: I think Mike has squashed the deadlocking problems with reentrant locks (primarily in the Wallet). I haven't seen one in at least a month. We discussed proxy support on the bitcoinj mailing list a while ago and at the time the stumbling block was the Java library used for the networking (Netty) did not support it. Mike or Miron would know better than I if this is still the case. Change address behaviour will improve significantly when HD wallet support goes into multibit/ bitcoinj (I am hoping to get my bit done over the summer). Matija Mazi has been working on a Java impl of HD wallets so it is coming down the pipe but there is a lot to do yet. Connections out from MultiBit are: + 4 bitcoind nodes on port 8333 + multibit.org (188.138.113.201) for help, current version info (and probably more in future) + the currency ticker will make HTTP gets to the source of whichever exchange(s) you have set up e.g MtGox, CampBX. This calls should disappear if you switch the currency conversion and ticker off. I think that is all the connections out I make. Mainly due to the exchanges abruptly changing their APIs and breaking things we are planning to put in intermediate Exchange Data Provider servers. Tim Molter is working on this in his XChange project. That will enable us to patch the server when things change and the multibits in the field won't be affected. There will probably be a couple of these initially for redundancy. Alex: Yes I think most users migrate to blockchain.info or, more recently coinbase.com. They are both good wallets but I'd like to keep Bitcoin as P2P as possible. Luke-Jr I think you are right here on the number of full nodes versus SPV nodes. I don't think we even know yet what are the working ratios of full nodes to SPV nodes. I haven't seen anybody do any analysis on this. I doubt multibit will ever participate in the Bitcoin network other than as an SPV client. All the optimisation is to reduce data traffic - it is effectively a mobile wallet that happens to live on a desktop. It is not really intended to be more than a wallet for regular people to store and spend their bitcoin. In English the nomenclature for direction of the transactions is: Sent to and Received with. To be honest I haven't transliterated the localisation files to check other language packs but the localisers are pretty good in my experience. On Thu, Jun 27, 2013, at 07:41 PM, Gregory Maxwell wrote: On Thu, Jun 27, 2013 at 11:04 AM, Luke-Jr l...@dashjr.org wrote: On Thursday, June 27, 2013 5:30:21 PM Jeff Garzik wrote: * Very real possibility of an overall net reduction of full nodes on P2P network Even a reduction of *nodes at all*, as I've never seen a listening bitcoinj or MultiBit node. :/ Jim, will MultiBit be adding p2p listening support? Without validation listening isn't currently very useful. :( Maybe it could be somewhat more with some protocol additions. -- 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 -- https://multibit.orgMoney, reinvented -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list Bitcoin
Re: [Bitcoin-development] Roadmap to getting users onto SPV clients
Gavin's grandma needs to be able to use bitcoin. Here is a real world sampling of the types of people wanting to use bitcoin but are having some difficulty which I have collected from Facebook. Should we listen to the end user? :-P *what is the intention of Bitcoin? Is it supposed to be - eventually - for dummies like myself or is it just for those individuals who are code and algorithm writers? I downloaded a wallet but how do I know if I need more software or a massive computer system to solve the problem for the next block? With all the talk of mathematical problem solving on a world wide network of computers I can't see a small laptop figuring out anything thus not gaining any bitcoins. Why should I be interested in this if it appears it's just for computer scientists?* *hi, instaled bitcoin qt, but after it dowladed all the stuff, now i get DEP protecction from windows, and it tells me bitcoinQT need to run with DEP on, dont let me make an exception for it, nor work it i turn DEP only for sys, so hwat i should do?* *hi, i'm new to bitcoin, i got a bunch of free bitcoins from a bunch of the free sites. how come when i tried to send my bitcoins to myself, it says the fee exceeds the balance? I thought there was no fees?* *Is there a way to speed up the process of synchronisation with the network? It has been taken ages on my MAC.* *Any help would be nice* * * *and more...* Sorry if this doesn't belong to the bitcoin-development email list. I just see this as end-user/customer data gathering to refine the requirements, since this is software engineering...isn't it? Jim On Tue, Dec 4, 2012 at 6:54 PM, Gregory Maxwell gmaxw...@gmail.com wrote: On Tue, Dec 4, 2012 at 9:08 PM, Alan Reiner etothe...@gmail.com wrote: Our divergence is on two points (personal opinions): (1) I don't think there is any real risk to the centralization of the network by promoting a SPV (purely-consuming) node to brand-new users. In my opinion (but I'm not as familiar with the networking as you), as long as all full nodes are full-validation, the bottleneck will be computation and bandwidth, long before a constant 10k nodes would be insufficient to support propagating data through the network. Not so— a moderately fast multicore desktop machine can keep up with the maximum possible validation rate of the Bitcoin network and the bandwidth has a long term maximum rate of about 14kbit/sec— though you'll want at least ten times that for convergence stability and the ability feed multiple peers. Here are the worst blocks testnet3 (which has some intentionally constructed maximum sized blocks),E31230 : (with the new parallel validation code) - Verify 2166 txins: 250.29ms (0.116ms/txin) - Verify 3386 txins: 1454.25ms (0.429ms/txin) - Verify 5801 txins: 575.46ms (0.099ms/txin) - Verify 6314 txins: 625.05ms (0.099ms/txin) Even the slowest one _validates_ at 400x realtime. (these measurements are probably a bit noisy— but the point is that its fast). (the connecting is fast too, but thats obvious with such a small database) Although I haven't tested leveldb+ultraprune with a really enormous txout set or generally with sustained maximum load— so there may be other gaffs in the software that get exposed with sustained load, but they'd all be correctable. Sounds like some interesting stuff to test with on testnet fork that has the POW test disabled. While syncing up a behind node can take a while— keep in mind that you're expecting to sync up weeks of network work in hours. Even 'slow' is quite fast. In fact, I was under the impression that connectedness was the real metric of concern (and resilience of that connectedness to large percentage of users disappearing suddenly). If that's true, above a certain number of nodes, the connectedness isn't really going to get any better (I know it's not really that simple, but I feel like it is up to 10x the current network size). Thats not generally concern for me. There are a number of DOS attack risks... But attacker linear DOS attacks aren't generally avoidable and they don't persist. Of the class of connectedness concerns I have is that a sybil attacker could spin up enormous numbers of nodes and then use them to partition large miners. So, e.g. find BitTaco's node(s) and the nodes for miners covering 25% hashpower and get them into a separate partition from the rest of the network. Then they give double spends to that partition and use them to purchase an unlimited supply of digitally delivered tacos— allowing their captured miners to build an ill fated fork— and drop the partition once the goods are delivered. But there is no amount of full nodes that removes this concern, especially if you allow for attackers which have compromised ISPs. It can be adequately addressed by a healthy darknet of private authenticated peerings between miners and other likely targets. I've also thrown out some ideas on using
