Re: [Bitcoin-development] Plans to separate wallet from core
On Mon, Jun 23, 2014 at 10:15 PM, Jorge Timón wrote: > On 6/23/14, Wladimir wrote: >> It's least surprising if the wallet works as a SPV client by default. >> Then, users can use it without first setting up a core. Thus the idea >> would be to use P2P primarily. > > 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)? Yes, they will share code. At least the basic data structures and serialization and deserialization. Probably also part of the network code and utilities like argument parsing (although that's not a hard requirement - it may be an opportunity to do things better). So part of Bitcoin Core will have to be turned into a library or libraries. Movement toward this is already in progress for a while. >> There could be a mode to use a trusted core by RPC for >> mempool/conflicted transaction validation and such. But I'm not sure >> about this - as we've seen, pure-SPV wallets work pretty well. If you >> want it to act as an edge router you can point a SPV wallet at your >> trusted core as well. > > I thought we would first separate wallet from core (maintaining the > full-node wallet status) and then implement an optional SPV mode for > the core (and transitively for "qt-wallet", which would support both > full and SPV mode). We want to move away from "full node wallets". In the beginning it made some sense to jump-start the network, but the more the chain grows the less unwieldy they become. 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 check for them. - A full node should be online 24/7 or it is virtually useless to the network. >> There are no plans for adding Electrum-like functionality to bitcoind. >> There is already Electrum. Let's not reinvent any wheels. > > I'm sorry, but I still don't know what Electrum has to do with all this. I suggest you look at the interface for Electrum. It probably does exactly what you expected the interface between the Bitcoin Core wallet and Bitcoin Core to become. Electrum server keeps some extra indices that can be queried by the wallets. It already exists! 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? (As said - I'm fine with optional close binding to a core using RPC with slight security benefits like utxo queries and conflicted transaction checking, and to get the dynamic fee data, but it should not be required) >> It does not need to keep a full chain database. But it needs its own >> record of the chain, headers-only + what concerns the keys in the >> wallet. > > Why cannot consume that data from a bitcoind node that always run alongside > it? To not require having a bitcoind node always running alongside it. Wladimir -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Plans to separate wallet from core
> > 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 integrates directly with the full mode main loop and doesn't talk P2P internally. Which is the fine and obvious way to implement the wallet feature. I'm not totally convinced it should become an SPV wallet given the complexity of doing that. But if you did want to separate the wallet code from the full node then that'd be the way to do it. 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 burden. However I may be quite biased, as I am the maintainer of what is primarily a wallet library :) > I'm sorry, but I still don't know what Electrum has to do with all this. > People use Electrum as shorthand to mean "something a bit like the P2P network, but with trusted remote servers which build additional databases and thus support additional commands". -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Plans to separate wallet from core
> 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 burden. I don't intend to work on that myself but that's up to the people that want to contribute to that. Once it's a separate project it could either be a big success, or it could slowly wither away. It can have a release cycle separate from the node. Likely faster. The organizational reason to split off the wallet is to get rid of that responsibility (and code) from the bitcoind repo. Maintaining a wallet should not be part of maintaining the core infrastructure. But just deleting it would be unreasonable. > However I may be quite biased, as I am the maintainer of what is primarily a > wallet library :) Hah. I've thought about that migration path as well. >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. But there are other interesting upcoming wallet projects as well, for example CoinVault. Wladimir -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Plans to separate wallet from core
> 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 a reputation of their own is a passed stage. There are many things that cannot be done at SPV level security with just the P2P protocol yet. So having fewer but more trusted Electrum servers is a reasonable compromise. But for basic wallet functionality it isn't necessary. Wladimir -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Plans to separate wallet from core
> > 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 library though. A lot of popular languages can run directly on the JVM these days. The big ones we miss are C++ and PHP, I think. But you can use JavaScript, Python 2.7, Lisp, Ruby, along with other less well known ones. The other good reason to have JSON-RPC support would be to reuse the Core regression tests. Anyway, this is off topic :) -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Plans to separate wallet from core
On 6/24/14, Mike Hearn 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 implement the wallet feature. I'm not totally convinced > it should become an SPV wallet given the complexity of doing that. But if > you did want to separate the wallet code from the full node then that'd be > the way to do it. > > 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 > burden. Exactly, this is part of my point, the qt-wallet does not support SPV operation at this point, and that complex work should be done after the wallet is separated. Thus the first version of the separated wallet should be functionally equivalent to today's wallet, that is, a full node wallet (even though I understand Wladimir's arguments against full-node wallets). >> I'm sorry, but I still don't know what Electrum has to do with all this. >> > > People use Electrum as shorthand to mean "something a bit like the P2P > network, but with trusted remote servers which build additional databases > and thus support additional commands". Ok, thanks. So a bitcoin core node which maintains and serves additional indexes (say, an utxo index via rpc or something else) is referred to as "an electrum" even though it doesn't use electrum-server. Strange, but now I get it. So in summary: 1) I accept the library approach over the "core-wallet protocol". 2) That doesn't necessarily mean that optionally maintaining additional indexes in the core is not interesting for some use cases (interesting for bitcoind, I don't care much if electrum-server currently does this and more [with more dependencies]). Although Pieter thinks that should also be separated into an "index node" too, but I think that's another discussion. 3) The wallet doesn't currently operate as SPV and that work should be done (if there's enough interest) only after the wallet is separated from the core. -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Plans to separate wallet from core
On Tue, Jun 24, 2014 at 1:29 PM, Jorge Timón wrote: > On 6/24/14, Mike Hearn 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 this point, and that complex work should be done after > the wallet is separated. Thus the first version of the separated > wallet should be functionally equivalent to today's wallet, that is, a > full node wallet (even though I understand Wladimir's arguments > against full-node wallets). Do mind that some of the steps on the path of bitcoind towards SPV are also useful in general. For example, headers-first allows parallel block download, which would solve a lot of sync issues people are having - a much higher priority than the wallet. But anyhow I'm describing how I would do it. If you're going to do it, you can do it in any order that you want. As we're talking about a separate project here it's not even clear who will be maintainer. > 2) That doesn't necessarily mean that optionally maintaining > additional indexes in the core is not interesting for some use cases > (interesting for bitcoind, I don't care much if electrum-server > currently does this and more [with more dependencies]). Although > Pieter thinks that should also be separated into an "index node" too, > but I think that's another discussion. I don't understand your argument against Electrum here. Dependencies? Come on, that's a matter of software distribution. If that really bothers you I suppose you could contribute to Electrum server so that it has less deps. It doesn't make the protocol worth any less. Although Pieter and I disagree with regard to issue #4351, we agree on wanting to keep (or at least making) bitcoind as lean as possible. Maintaining extra indices for others doesn't fit in there - that's also why the address index patch was not merged. An 'index node' could be a different animal. Wladimir -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Plans to separate wallet from core
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 Regards, Tamás Blummer Founder, CEO http://bitsofproof.com signature.asc Description: Message signed with OpenPGP using GPGMail -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Plans to separate wallet from core
> > Although Pieter and I disagree with regard to issue #4351, we agree on > wanting to keep (or at least making) bitcoind as lean as possible. > Maintaining extra indices for others doesn't fit in there - that's > also why the address index patch was not merged. An 'index node' could > be a different animal. We definitely want to head in the direction of allowing a p2p node to be as useful as possible within its resource constraints and optional advertising of new (expensive) indexes is the way to go. Sometimes I wonder if we should have an RPC or new socket based method where additional programs could run along side Bitcoin Core and opt to handle a subset of p2p commands. But then I think, that seems like a lot of complexity for people who just want to help out the system, which I guess is the bulk of our network now. Keeping their lives simple should have a high 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. -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Plans to separate wallet from core
On Tue, Jun 24, 2014 at 2:16 PM, Mike Hearn 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 moving towards a bag of parts of specialized tools, maintained by people that specialize in those tools, instead of a single project that aims to do and know everything. This encourages experimentation and makes competition possible and I think that is healthy in this space. Bitcoin has a strict need for consensus in the block chain format, scripting system and validation. Outside of those, innovation should be possible without any gatekeeper bottleneck or even widespread agreement. Wallets, what data to store on disk, what indices to maintain. But even P2P message extensions, as long as it doesn't interfere with the rest of the network. After an experiment is successful it could always be merged into bitcoin core. But then the 'what-ifers' have less ammo, as it has been tested in the real world. For user convenience it's still possible to package pre-assembled bags. But that doesn't need to figure into how things are developed. Wladimir -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Plans to separate wallet from core
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 a reputation of their own is a passed stage. There > are many things that cannot be done at SPV level security with just > the P2P protocol yet. So having fewer but more trusted Electrum > servers is a reasonable compromise. > Thanks for that :) Note that my goal is to make the Electrum servers as trustless as possible, and not to rely on some sort of 'reputation'. Thomas -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Plans to separate wallet from core
On 6/24/14, Tamas Blummer 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 instead of something more direct when you control both processes? Wladimir, of course headers-first is generally good, and of course nobody will be force to separate the code in a way he doesn't like, I was just testing the waters to see what people had in mind, since I realized the ideas could be more different than I had assumed. I don't have any issues with electrum, I'm just not convinced by the arguments that say that the indexes must be necessarily out of the core, specially when some of them could be committed in the future. So I'm all in favor of modularity and competing codebases, I'm just not convinced that the "core full-node" must be necessarily restricted to validation only (for example, I think it should maintain a minimal and non-optimized mining functionality,even if it's only used for testing purposes). So far it is great that everybody seems to agree that the wallet code needs to be separated. Thanks everyone for sharing your views on the subject. -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Proposed BIP 70 extension
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
loyalty points, etc. Bitcoin should do this too - show the user how much
they're saving by using Bitcoin instead of credit cards.
I suggested to Charlie Lee (who pushed this through at Coinbase) and
Stephen Pair the following minor BIP 70 extension:
message PaymentDetails {
// Size in satoshis of any discount provided by the merchant ONLY
// because the user chose to pay using Bitcoin or other similar
// digital currency. Other kinds of discounts, loyalty bonuses and
// so on should not be recorded here, rather they could be mentioned
// in the memo field. This field exists so wallets can show the user
// a running total of how much money they have saved by avoiding
// credit cards and bank payments; the goal is to encourage people to
// use Bitcoin. Putting other kinds of discounts here would make the
// running total calculated meaningless; so don't do it!
optional uint64 currency_usage_discount_size = 8;
}
Wallets would then be able to persist this data to disk and compete on cool
visualisations for how much money you saved over time.
We haven't formalised how to extend BIP 70 yet, that's my fault. We should
do that. In the meantime, what do people think of this proposal?
--
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Plans to separate wallet from core
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 that does full verification and maintains some indexes of some sort. I still believe that what we push for to run as the core nodes of the network should aim for purely verification and relay, and nothing else, but people can and will do things differently if the source code allows it. And that's fine. On Tue, Jun 24, 2014 at 3:26 PM, Jorge Timón wrote: > I think this is my main question, what's the advantage of having the > processes talking via the p2p protocol instead of something more > direct when you control both processes? IMHO, maintaining a correct view of the current state of the chain (excluding blocks, just headers) is already sufficiently hard (I hope that everyone who ever implemented an SPV wallet can agree). You simplify things a bit by not needing to verify what the peer claims if you trust them, but not much. You still need to support reorganizations, counting confirmations, making sure you stay up-to-date. These are functions the (SPV) P2P protocol has already shown to do well, and there are several codebases out there that implement it. No need to reinvent the wheel with a marginally more efficient protocol, if it means starting over everything else. -- Pieter -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed BIP 70 extension
On Tue, Jun 24, 2014 at 9:27 AM, Mike Hearn 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 unprovable, and a rational economic actor may choose to exaggerate such numbers. It also seems collectively rational by some points of view for all bitcoin actors to inflate this number. At a minimum, I would either add "marketing_" to the field name itself, or include additional comment caveats noting in BOLD language that this field is informational, and should not be relied upon for accounting/auditing purposes. It just seems like a statistic that everyone has an incentive to exaggerate. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed BIP 70 extension
> > 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 think the comment makes it clear it's just for fun. -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed BIP 70 extension
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 payment itself. Put these marketing claims to memo field instead... slush On Tue, Jun 24, 2014 at 4:24 PM, Mike Hearn wrote: > 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 think the > comment makes it clear it's just for fun. > > > -- > Open source business process management suite built on Java and Eclipse > Turn processes into business applications with Bonita BPM Community Edition > Quickly connect people, data, and systems into organized workflows > Winner of BOSSIE, CODIE, OW2 and Gartner awards > http://p.sf.net/sfu/Bonitasoft > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed BIP 70 extension
> > 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 in fact, wallets do!). Besides, assuming the customer is *always* being scammed seems extreme. There are plenty of merchants that genuinely care about their reputation and genuinely want people to pay with Bitcoin so they can avoid card fees. > Payment protocol should not contain these fictional data > Well, I think the protocol should contain whatever is useful. I'll probably draft a BIP for this next week or so. -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed BIP 70 extension
> On Jun 24, 2014, at 10:32, slush 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 this feature in the same way amazon (and other sales sites) abuse the definition of "save". For example, Amazon will indicate that you're getting x% off by shopping at amazon, but all that number really means is x% off MSRP. In reality, every website has the same price. I have no doubt that merchants would put similarly meaningless and/or misleading data in this field. I agree, the memo field is appropriate for this data. smime.p7s Description: S/MIME cryptographic signature -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Plans to separate wallet from core
-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 check for them. > > - A full node should be online 24/7 or it is virtually useless to > the network. I think btcd has done this right. A wallet is a daemon that runs constantly in the background, just like the full node. The GUI (which is distinct from the wallet) runs as little as possible. Presumably there's no need for a 1:1 relationship between wallets and GUIs. - -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJTqZpVAAoJEMP3uyY4RQ21E48H/0XNYBzR8QZjfku/MeL5IbwL A56jrlWe2EZTabwfKdGx12L5oeBXe3DOeLsTizqIu0vijcl7qQryU49AjrVe91Rx OdEi4lmaiXdkM3lWeWUxLoLLHR1B+1f8T18Mrnzo+yasyrywPb+6H79VN5KERdA2 5yHYCZyHXdNoXpzyf38GC2PdYJmAZdrRfAGyC5+OXSwE3XLhpRBrSBh/mrx0ct5M ghkCKtsmJCJJ6sR2TbFxaj71kPp0J0tp8JVvjVEqC2uB4Ih0NY+79kz8L81TaNmw ol1o6p7TypIk7QRQ4ES3Fq0ALh2aQ/tX4rc0GC0ed+xLi+dHJ2wGBI37HoyGIyg= =Nn9X -END PGP SIGNATURE- 0x38450DB5.asc Description: application/pgp-keys -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed BIP 70 extension
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, currently PR are created by the payment processors afaik. How can
they know what other payment option the merchant provides and what's the
conditions? Maybe we should first solve the signature delegation problem
so that the merchant can create the request.
Although I'm sure this feature will get abused, I (as a wallet author)
would be willing to give it a try. I agree with Jeff that the name of
the field should start with something like "marketing".
On 06/24/2014 03:27 PM, Mike Hearn 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
> motivating because it feels like free money. Many businesses exploit
> this effect with loyalty points, etc. Bitcoin should do this too - show
> the user how much they're saving by using Bitcoin instead of credit cards.
>
> I suggested to Charlie Lee (who pushed this through at Coinbase) and
> Stephen Pair the following minor BIP 70 extension:
>
>
> message PaymentDetails {
> // Size in satoshis of any discount provided by the merchant ONLY
> // because the user chose to pay using Bitcoin or other similar
> // digital currency. Other kinds of discounts, loyalty bonuses and
> // so on should not be recorded here, rather they could be mentioned
> // in the memo field. This field exists so wallets can show the user
> // a running total of how much money they have saved by avoiding
> // credit cards and bank payments; the goal is to encourage people to
> // use Bitcoin. Putting other kinds of discounts here would make the
> // running total calculated meaningless; so don't do it!
> optional uint64 currency_usage_discount_size = 8;
> }
>
> Wallets would then be able to persist this data to disk and compete on
> cool visualisations for how much money you saved over time.
>
> We haven't formalised how to extend BIP 70 yet, that's my fault. We
> should do that. In the meantime, what do people think of this proposal?
>
>
> --
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
>
>
>
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed BIP 70 extension
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 wrote: > > >> On Jun 24, 2014, at 10:32, slush 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 this feature in the same way amazon (and other sales > sites) abuse the definition of "save". For example, Amazon will indicate that > you're getting x% off by shopping at amazon, but all that number really means > is x% off MSRP. In reality, every website has the same price. I have no doubt > that merchants would put similarly meaningless and/or misleading data in this > field. > > I agree, the memo field is appropriate for this data. > -- > Open source business process management suite built on Java and Eclipse > Turn processes into business applications with Bonita BPM Community Edition > Quickly connect people, data, and systems into organized workflows > Winner of BOSSIE, CODIE, OW2 and Gartner awards > http://p.sf.net/sfu/Bonitasoft > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed BIP 70 extension
> > 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 > they know what other payment option the merchant provides and what's the > conditions? > Currently Coinbase let merchants specify the size of their discount (I guess in percentage terms, I should ask). So the merchants tell the payment processor. I don't think this is a worry at the moment. -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Plans to separate wallet from core
On 6/24/14, Justus Ranvier 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 possible, ideally only >> when you do transactions or want to check for them. >> >> - A full node should be online 24/7 or it is virtually useless to >> the network. > > I think btcd has done this right. > > A wallet is a daemon that runs constantly in the background, just like > the full node. > > The GUI (which is distinct from the wallet) runs as little as > possible. Presumably there's no need for a 1:1 relationship between > wallets and GUIs. I think he means that the wallet shouldn't be running as much as it is currently doing. But yes, I think you're right about wallets and GUIs not necessarily mapping 1:1. -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed BIP 70 extension
Seems like a nice idea.
On 24 June 2014 14:27, Mike Hearn 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 motivating
> because it feels like free money. Many businesses exploit this effect with
> loyalty points, etc. Bitcoin should do this too - show the user how much
> they're saving by using Bitcoin instead of credit cards.
>
> I suggested to Charlie Lee (who pushed this through at Coinbase) and
> Stephen Pair the following minor BIP 70 extension:
>
>
> message PaymentDetails {
> // Size in satoshis of any discount provided by the merchant ONLY
> // because the user chose to pay using Bitcoin or other similar
> // digital currency. Other kinds of discounts, loyalty bonuses and
> // so on should not be recorded here, rather they could be mentioned
> // in the memo field. This field exists so wallets can show the user
> // a running total of how much money they have saved by avoiding
> // credit cards and bank payments; the goal is to encourage people to
> // use Bitcoin. Putting other kinds of discounts here would make the
> // running total calculated meaningless; so don't do it!
> optional uint64 currency_usage_discount_size = 8;
> }
>
> Wallets would then be able to persist this data to disk and compete on
> cool visualisations for how much money you saved over time.
>
> We haven't formalised how to extend BIP 70 yet, that's my fault. We should
> do that. In the meantime, what do people think of this proposal?
>
>
> --
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed BIP 70 extension
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 format. I'd rather we just didn't have this essentially pointless "feature" at all. Let's try and keep as much cruft as possible out of the payment protocol. The textual memo field is already more than sufficient. > On Jun 24, 2014, at 11:48, Jeff Garzik wrote: > > I think there is nothing wrong with having a numeric memo field, which > is effectively what this is. Structured rather than unstructured > data. smime.p7s Description: S/MIME cryptographic signature -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed BIP 70 extension
On Tue, Jun 24, 2014 at 10:21:46AM -0400, Jeff Garzik wrote: > On Tue, Jun 24, 2014 at 9:27 AM, Mike Hearn 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 > unprovable, and a rational economic actor may choose to exaggerate > such numbers. It also seems collectively rational by some points of > view for all bitcoin actors to inflate this number. Rather than offering discounts, how about offering automatic cashback? I know they're kinda stupid, but I gather cashback deals are very commonplace in the US and (probably as a result) not unheard of elsewhere. So you add an optional cashback_to field to the Payment message, distinct from but conceptually similar to the refund_to field. The wallet can tally up how much cashback is received, without having to trust the merchants. Much harder to game, AFAICS. roy -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed BIP 70 extension
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 line item for state sales tax for example, or a cash back reward, or a merchant discount like the proposed, whatever is applicable. It would be a list of amount / label tuples maybe. On Tue, Jun 24, 2014 at 12:00 PM, Gmail 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. > > If we're going to support one random cosmetic field, we might as well > support them all with a generic structured data format. > > I'd rather we just didn't have this essentially pointless "feature" at all. > Let's try and keep as much cruft as possible out of the payment protocol. > The textual memo field is already more than sufficient. > > On Jun 24, 2014, at 11:48, Jeff Garzik wrote: > > I think there is nothing wrong with having a numeric memo field, which > is effectively what this is. Structured rather than unstructured > data. > > > -- > Open source business process management suite built on Java and Eclipse > Turn processes into business applications with Bonita BPM Community Edition > Quickly connect people, data, and systems into organized workflows > Winner of BOSSIE, CODIE, OW2 and Gartner awards > http://p.sf.net/sfu/Bonitasoft > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -- Andy Alness Software Engineer Coinbase San Francisco, CA -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Bill Request Message - (another) Proposed BIP 70 extension
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 mobile wallets to request a bill, so that a
payment protocol flow can be initiated. Current mechanisms for initiating
BIP70 payment flows generally require wallets to either scan a merchant
barcode (not optimal, see below), or click on a specially formatted url
link (only suitable while browsing and purchasing on a merchant website).
Successful non-bitcoin mobile wallet apps to date (a popular coffee shop
app comes to mind) allow for the wallet app to be scanned by the merchant
and not the other way around (as is commonly done in bitcoin wallets
today). For broad bitcoin adoption we need a mechanism for wallets to be
scanned by merchant bar code readers at brick and mortar shops. This will
also greatly ease checkouts at drive throughs and allows merchants to
leverage existing hardware (barcode readers).
Other technologies like NFC may obviate the need for this extension,
however, those technologies remain somewhat uncommon and may not be
suitable for smaller wearables hitting the market.
message BillRequest {
required uint64 time = 1;
optional uint64 expires = 2;
required string bill_request_uri = 3;
}
time - Unix timestamp (seconds since 1-Jan-1970 UTC) when the BillRequest
was created.
expires - Unix timestamp (UTC) after which the BillRequest should be
considered invalid (wallets may only be monitoring for messages for a short
time).
bill_req_addr - Typically a URL where a BIP70 payment request can be sent
that is being monitored by the wallet. However this could also support URIs
like "sms:860-555-1212" or "mailto:a...@gmail.com"; allowing for a variety
of connection options.
Recommendations: it is recommended that wallet apps display a non-QR
barcode like a PDF417 barcode to initiate the Bill Request flow. This will
avoid confusion with existing QR code usage in wallet apps.
Paul G.
--
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed BIP 70 extension
On Tue, Jun 24, 2014 at 3:00 PM, Gmail 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 there are hundreds of field numbers available. 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. -- -- Gavin Andresen -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed BIP 70 extension
> On Jun 24, 2014, at 16:12, Gavin Andresen 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 container formats for random one-off "that would be kind of nice, I guess" features. How about exchange rate? Sharing links? Referral information? Any of these things are just as deserving of specification (and just as arbitrary). smime.p7s Description: S/MIME cryptographic signature -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Plans to separate wallet from core
On Tue, Jun 24, 2014 at 6:40 PM, Jorge Timón wrote: > > I think he means that the wallet shouldn't be running as much as it is > currently doing. > But yes, I think you're right about wallets and GUIs not necessarily > mapping 1:1. I haven't been talking about the GUI at all in this entire conversation. When I say wallet, I mean the wallet code. There are very few reasons for running a wallet 24/7. One could be if you're running an exchange that has to send and receive transactions all the time. But that's an exception - in the usual merchant/end-user case you're mostly receiving transactions and sometimes manually or batched- sending them. No need to leave the wallet running, exposed to the network outside those times. How the wallet GUI (if any) relates to the wallet code is a completely different topic, and a much less pressing matter. Anything from 'GUI uses wallet as a library' (multibit, electrum, bitcoin core) to elaborate client-server protocols (btcd, coinvault?) are acceptable depending on the use case. Wladimir -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
