[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
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

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

Re: [Bitcoin-development] Electrum 2.0 has been tagged

2015-03-11 Thread Jim
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

Re: [Bitcoin-development] Electrum 2.0 has been tagged

2015-03-02 Thread Jim
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

Re: [Bitcoin-development] BIP32 wallet structure in use? Remove it?

2014-04-25 Thread Jim
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

Re: [Bitcoin-development] New BIP32 structure

2014-03-27 Thread Jim
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:

Re: [Bitcoin-development] Base-32 error correction coding

2014-02-24 Thread Jim Paris
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

Re: [Bitcoin-development] Fees UI warning

2013-12-16 Thread Jim
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

Re: [Bitcoin-development] Safe auto-updating

2013-08-05 Thread Jim
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

Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org

2013-07-09 Thread Jim
...@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

Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org

2013-06-30 Thread Jim
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

Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org

2013-06-28 Thread Jim
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.

[Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org

2013-06-27 Thread Jim
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

Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org

2013-06-27 Thread Jim
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

Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org

2013-06-27 Thread Jim
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

Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org

2013-06-27 Thread Jim
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

Re: [Bitcoin-development] Roadmap to getting users onto SPV clients

2012-12-04 Thread Jim Nguyen
-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