Re: [Bitcoin-development] Plans to separate wallet from core

2014-06-24 Thread Mike Hearn
So first bitcoind will support SPV mode then we separate the wallet? Are the core and the wallet share any code (say, the p2p messages via a sub-repo or something)? bitcoind already supports SPV mode, that's how bitcoinj clients work. However the current wallet code doesn't use it, it

Re: [Bitcoin-development] Plans to separate wallet from core

2014-06-24 Thread Wladimir
The question is; what does this buy us, and is it worth the potentially huge amount of time it could take? My gut feeling is we have bigger fish to fry. There's plenty of work to do just on the core consensus code, making Bitcoin Core into a competitive wallet as well would be an additional

Re: [Bitcoin-development] Plans to separate wallet from core

2014-06-24 Thread Mike Hearn
From my experience the main thing people are missing with BitcoinJ is a quick and easy way to set up a wallet as a daemon, to use the functionality from non-java through RPC. Yes. I'd love to have a mostly Core compatible JSON-RPC frontend. Most of my current users are happy using it as a

Re: [Bitcoin-development] Plans to separate wallet from core

2014-06-24 Thread Jorge Timón
On 6/24/14, Mike Hearn m...@plan99.net wrote: bitcoind already supports SPV mode, that's how bitcoinj clients work. However the current wallet code doesn't use it, it integrates directly with the full mode main loop and doesn't talk P2P internally. Which is the fine and obvious way to

Re: [Bitcoin-development] Plans to separate wallet from core

2014-06-24 Thread Wladimir
On Tue, Jun 24, 2014 at 1:29 PM, Jorge Timón jti...@monetize.io wrote: On 6/24/14, Mike Hearn m...@plan99.net wrote: ou did want to separate the wallet code from the full node then that'd be the way to do it. Exactly, this is part of my point, the qt-wallet does not support SPV operation at

Re: [Bitcoin-development] Plans to separate wallet from core

2014-06-24 Thread Tamas Blummer
I think there are three typical uses: 1. Building consensus on the block chain. This is what the core is for. 2. Single user wallets. This is where SPV alone is good. 3. Services e.g. exchange, payment processor This is where core + indexing server talking SPV to core is the right choice

Re: [Bitcoin-development] Plans to separate wallet from core

2014-06-24 Thread Wladimir
On Tue, Jun 24, 2014 at 2:16 PM, Mike Hearn m...@plan99.net wrote: priority. So a single unified program that just figures it out automatically rather than expecting users to assemble a bag of parts seems a goal worth striving for. As I've said before -- and I think we disagree here - I like

Re: [Bitcoin-development] Plans to separate wallet from core

2014-06-24 Thread Thomas Voegtlin
Le 24/06/2014 11:44, Wladimir a écrit : But IMO this is a passed stage. SPV wallets w/ Bloom filtering can work without any special servers, so why require a 'close binding' to a trusted bitcoin core? To clarify (and not piss off ThomasV :-): I do not think the idea of having servers with

Re: [Bitcoin-development] Plans to separate wallet from core

2014-06-24 Thread Jorge Timón
On 6/24/14, Tamas Blummer ta...@bitsofproof.com wrote: 3. Services e.g. exchange, payment processor This is where core + indexing server talking SPV to core is the right choice I think this is my main question, what's the advantage of having the processes talking via the p2p protocol

[Bitcoin-development] Proposed BIP 70 extension

2014-06-24 Thread Mike Hearn
Coinbase have started allowing merchants to set discounts for purchasing with Bitcoin. Seeing an individual discount is not very motivating as they tend to be small. Seeing them stack up over time can be more motivating because it feels like free money. Many businesses exploit this effect with

Re: [Bitcoin-development] Plans to separate wallet from core

2014-06-24 Thread Pieter Wuille
I'd like to point out that there is quite a difference between what core nodes should be like and what the codebase core nodes are built from must support. Given sufficiently modularized code (which I think everyone seems to be in favor of, regardless of the goals), you can likely build a binary

Re: [Bitcoin-development] Proposed BIP 70 extension

2014-06-24 Thread Jeff Garzik
On Tue, Jun 24, 2014 at 9:27 AM, Mike Hearn m...@plan99.net wrote: Wallets would then be able to persist this data to disk and compete on cool visualisations for how much money you saved over time. heh, this is a cool idea. It also seems like it would be subject to instant inflation, as it's

Re: [Bitcoin-development] Proposed BIP 70 extension

2014-06-24 Thread Mike Hearn
It also seems like it would be subject to instant inflation, as it's unprovable The user knows the price that is on the website or menu, they know the price they actually paid ... if the numbers don't add up that would seem to be pretty easily detectable. But sure it's only for marketing. I

Re: [Bitcoin-development] Proposed BIP 70 extension

2014-06-24 Thread slush
Sounds like marketing bullshit to me. It does not have even statistical meaning; well, you can save a lot of satoshis, but nobody tell you that the merchant cut you on BTC/USD exchange rate in tens of %. Payment protocol should not contain these fictional data, which has no real meaning for the

Re: [Bitcoin-development] Proposed BIP 70 extension

2014-06-24 Thread Mike Hearn
Sounds like marketing bullshit to me. It does not have even statistical meaning; well, you can save a lot of satoshis, but nobody tell you that the merchant cut you on BTC/USD exchange rate in tens of %. Your own wallet can look up the exchange rate and compare it to what you're getting (and

Re: [Bitcoin-development] Proposed BIP 70 extension

2014-06-24 Thread Gmail
On Jun 24, 2014, at 10:32, slush sl...@centrum.cz wrote: Sounds like marketing bullshit to me. It does not have even statistical meaning; well, you can save a lot of satoshis, but nobody tell you that the merchant cut you on BTC/USD exchange rate in tens of %. People would also abuse

Re: [Bitcoin-development] Plans to separate wallet from core

2014-06-24 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/24/2014 09:07 AM, Wladimir wrote: My main argument for the split is that full nodes and wallets have completely different usage scenarios: - A wallet should be online as little as possible, ideally only when you do transactions or want to

Re: [Bitcoin-development] Proposed BIP 70 extension

2014-06-24 Thread Andreas Schildbach
I think it should be made more clear what's the reference price for the discount. In Germany, we generally don't use credit cards but rather EC-Cards, which is already much cheaper. Or maybe for some merchants the only alternative is cash, and they would still offer a Bitcoin discount. Also,

Re: [Bitcoin-development] Proposed BIP 70 extension

2014-06-24 Thread Jeff Garzik
I think there is nothing wrong with having a numeric memo field, which is effectively what this is. Structured rather than unstructured data. On Tue, Jun 24, 2014 at 11:15 AM, Gmail will.ya...@gmail.com wrote: On Jun 24, 2014, at 10:32, slush sl...@centrum.cz wrote: Sounds like marketing

Re: [Bitcoin-development] Proposed BIP 70 extension

2014-06-24 Thread Mike Hearn
I think it should be made more clear what's the reference price for the discount. That might be useful for merchants that already provide a series of price-differentiated payment methods, yes. Will think about it. Also, currently PR are created by the payment processors afaik. How can

Re: [Bitcoin-development] Plans to separate wallet from core

2014-06-24 Thread Jorge Timón
On 6/24/14, Justus Ranvier justusranv...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/24/2014 09:07 AM, Wladimir wrote: My main argument for the split is that full nodes and wallets have completely different usage scenarios: - A wallet should be online as little as

Re: [Bitcoin-development] Proposed BIP 70 extension

2014-06-24 Thread Drak
Seems like a nice idea. On 24 June 2014 14:27, Mike Hearn m...@plan99.net wrote: Coinbase have started allowing merchants to set discounts for purchasing with Bitcoin. Seeing an individual discount is not very motivating as they tend to be small. Seeing them stack up over time can be more

Re: [Bitcoin-development] Proposed BIP 70 extension

2014-06-24 Thread Gmail
Ok, wanting structured data is a decent argument, but why this random arbitrary case in particular? There are hundreds of fields like this that people might want to use. If we're going to support one random cosmetic field, we might as well support them all with a generic structured data

Re: [Bitcoin-development] Proposed BIP 70 extension

2014-06-24 Thread Roy Badami
On Tue, Jun 24, 2014 at 10:21:46AM -0400, Jeff Garzik wrote: On Tue, Jun 24, 2014 at 9:27 AM, Mike Hearn m...@plan99.net wrote: Wallets would then be able to persist this data to disk and compete on cool visualisations for how much money you saved over time. heh, this is a cool idea.

Re: [Bitcoin-development] Proposed BIP 70 extension

2014-06-24 Thread Andy Alness
I somewhat agree with Will (but also with Mike, Jeff, and Charlie.) I think the idea of letting consumers know advanced details about the transaction is good and defining these with strong types is also good. Maybe an arbitrary set of accounting line items would be more palatable. You could have a

[Bitcoin-development] Bill Request Message - (another) Proposed BIP 70 extension

2014-06-24 Thread Paul Goldstein
Here's an idea for a BIP 70 extension to let wallets be scanned by merchant bar code readers to start off a payment request flow instead of the other way around (wallet scanning the merchant QR). Useful for brick and mortar merchants and mobile wallet apps. Motivation: A mechanism is needed for

Re: [Bitcoin-development] Proposed BIP 70 extension

2014-06-24 Thread Gavin Andresen
On Tue, Jun 24, 2014 at 3:00 PM, Gmail will.ya...@gmail.com wrote: Ok, wanting structured data is a decent argument, but why this random arbitrary case in particular? There are hundreds of fields like this that people might want to use. Protocol buffers are designed to be extensible, and

Re: [Bitcoin-development] Proposed BIP 70 extension

2014-06-24 Thread Gmail
On Jun 24, 2014, at 16:12, Gavin Andresen gavinandre...@gmail.com wrote: It would be silly to add a generic stuff field inside a container format that ALREADY has all the mechanisms necessary for forwards and backwards extensibility. I agree. It would be even sillier to start specifying