[Bitcoin-development] Why do we need a MAX_BLOCK_SIZE at all?

2015-06-01 Thread Jim Phillips
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

Re: [Bitcoin-development] No Bitcoin For You

2015-05-26 Thread Jim Phillips
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

Re: [Bitcoin-development] No Bitcoin For You

2015-05-25 Thread Jim Phillips
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

Re: [Bitcoin-development] No Bitcoin For You

2015-05-25 Thread Jim Phillips
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

Re: [Bitcoin-development] No Bitcoin For You

2015-05-25 Thread Jim Phillips
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

Re: [Bitcoin-development] No Bitcoin For You

2015-05-25 Thread Jim Phillips
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

Re: [Bitcoin-development] Zero-Conf for Full Node Discovery

2015-05-25 Thread Jim Phillips
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

[Bitcoin-development] Zero-Conf for Full Node Discovery

2015-05-25 Thread Jim Phillips
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

Re: [Bitcoin-development] A suggestion for reducing the size of the UTXO database

2015-05-10 Thread Jim Phillips
, 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

Re: [Bitcoin-development] A suggestion for reducing the size of the UTXO database

2015-05-09 Thread Jim Phillips
. 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

Re: [Bitcoin-development] A suggestion for reducing the size of the UTXO database

2015-05-09 Thread Jim Phillips
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

Re: [Bitcoin-development] A suggestion for reducing the size of the UTXO database

2015-05-09 Thread Jim Phillips
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

Re: [Bitcoin-development] A suggestion for reducing the size of the UTXO database

2015-05-09 Thread Jim Phillips
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

Re: [Bitcoin-development] A suggestion for reducing the size of the UTXO database

2015-05-09 Thread Jim Phillips
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

Re: [Bitcoin-development] A suggestion for reducing the size of the UTXO database

2015-05-09 Thread Jim Phillips
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

Re: [Bitcoin-development] A suggestion for reducing the size of the UTXO database

2015-05-09 Thread Jim Phillips
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