Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
On 02/23/2015 09:53 PM, Andy Schroder wrote: I was saying provide a public key via NFC (or a public key fingerprint and then send the full public key over bluetooth). Instead of providing a new public key on each tap, why can't the payee just stop accepting connections from new parties on that resource after a session key has been received from the first person? Because the presumption was that there was not an additional secret in the URI. If the public key is reused then anyone can spoof a payer and obtain payment requests. Adding a secret to the URI can resolve this, as long as it is encrypted with the public key before being transmitted back to BT. Otherwise the secret can be intercepted and replayed to the terminal, encrypted with the well-known public key. So if you want to treat the resource as a secret this would work. However the resource was designed as a public session identifier, leading the byte stream. This changes it to private session identifier, which loses some utility. Also, reuse of the public key introduces a forward secrecy problem and the potential for persistent seller impersonation in the case of undiscovered key compromise. But there's really no benefit to reusing the key. An ephemeral key resolves these issues and can also seed the public resource name. If the person decides to have there friend or family pay for them instead and cancel the payment, they could just hit cancel on the POS or something (on my fuel pump I have a switch that needs to be turned, the purpose of this is to avoid wasting too many addresses) Don't you have someone stop by the pump once a week and empty out the addresses? :) and/or do another NFC tap (if you're providing QR codes you'd still need a button of some kind though so it knows to refresh it), or the POS can just provide a completely new payment request to any new connections on that same resource which use a different session key. I feel like the authentication of the payer to the payee in any future connections after they receive the session key from them (which was encrypted with the payees public key), comes from the fact that they are sending responses back that are encrypted using the session key they gave to the payee. The way I am seeing it is that the NFC tap or QR code scan is acting in addition to the visual name check on the signature verification in the wallet. With a secure channel that identifies the parties by proximity, the reason for the payment request signature is for the payer to obtain a non-repudiation guarantee. But it also serves as a defense-in-depth solution to a compromise of the channel (though does not offer a benefit in the case of seller terminal/cert compromise). If the certificate used isn't signed by a CA (self signed), it may be fine as long as you heard about it via NFC or QR code. I don't think it will require PKI and should still work wallet-to-wallet. In that case the cert provides no benefit. A self-signed cert can be repudiated and if the channel is compromised anyone can sign the payment request. It sounds like you are saying I'm proposing the customer is going to need a certificate signed by CA? If so, why? This was not a serious proposal, it was to point out what would become necessary if the payer could not be identified by proximity. In the case where a public key is reused, any payer can contact the BT terminal and obtain the payment request. If the merchant can't rely on proximity (i.e. can't trust the integrity of the NFC connection) then he would have to fall back on some other means of identifying the payer. A mutual verbal/visual confirmation could work, but the point of of NFC+BT is elimination of that hassle. Yes, it sounds a bit wild, but I have seen on this list a serious proposal to have people broadcast their photo, having the merchant select them and push to them the payment request. Of course anyone can spoof another's image, so at some point your image would need to be certified, and hence a CA. I wouldn't go there, but was just making the point. I don't need this for any https website I visit. When you go to a web site you first establish a private communication. The site doesn't know who you are (hopefully). Then you log on with your secret, or proof of it, establishing who you are. Customer identity problem solved. Or you create an account, providing your relevant identity information which effectively becomes who you are to the site. Or you shop anonymously and when you go to check out they know that if you pay, you get permission to direct the product shipment. And only you can see the bill. This because your session binds your shopping to your bill and payment. However when you go to the local adult shop to pick up some love toys, the person at the counter has no idea who's asking their terminal for a payment request. You having the shop's public cert doesn't help them with that problem (nor does some anonymous signal sending
Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
Does this not also require the BT publication of the script for a P2SH address? You mean if the URI you're serving is like this? bitcoin:3aBcD?bt= Yes it would. I guess then, the server would indicate both the script, and the key within that script that it wanted to use. A bit more complex but would still work to save URI space. -- 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] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
On 02/24/2015 11:49 AM, Andy Schroder wrote: Hello, I think were talking about a lot of the same things. There is one key piece of information that I was not thinking about until you made it clear. Why the payee needs to identify the payer. In my fuel pump application, they really don't, so I wasn't thinking closely about these other situations. With my fuel pump, it won't even let you do anything until you sign a transaction and submit it. So, the payment request contains no personal information, it's just a request for payment, and not for anything specific. It doesn't know or care what you are going to buy until you make a prepayment, because there is no use in trying to start doing business without a signed transaction. This approach minimizes risk because once you dispense a fuel, or anything else, it's not like you can easily give it back if you happened to not have any funds. It also makes it a higher chance for a confirmation before the customer leaves. Other transactions have similar post payment traditions, like a restaurant (not fast food), where the seller doesn't know if you actually have enough money until you've already consumed the food, but this work flow seems to be a culturally driven one rather than risk driven. In the discussion about an https website, there are many websites where no login or authentication by the client required to have a private connection. With a shopping website though, the customer can identify themselves without logging in by saying (in band) what they are intending to buy after the private connection has been established. At a cash register in person the items being purchased have no tie to the customer. The items being purchased were communicated to the seller out of band (in real life) and insecurely to establish that link. You are trying to make a tie between that list of items and the buyer separately, and that is why some unique identifier needs to be transmitted via NFC. Stepping a bit back: I guess I'm wondering if it would be useful to encourage an opposite work flow where a micro payment channel is setup for most purchases. For example, if I go to the grocery store, it usually takes a minute or so to check out. If I immediately tap and open up a payment channel with the store when I start checkout, rather than finish, there can be more network propagation of that transaction while they are scanning all the items. They'll see the channel is open and start adding all the items I want to buy to that micro payment channel. I'm identified because I made a payment, not because I've transmitted a unique resource or used a unique public key to encrypt communication. A payment terminal would not allow for new payment channels to be open until the currently active one is closed. If I don't have enough funds left in the payment channel, they just stop scanning items. There may be some additional privacy implications of setting up micro payment channels all the time for everyday purchases. It also may not work for every sales case, so we may still need some way to authenticate the payer with a unique identifier. So, maybe we don't want to do this, but it is just a thought to consider. It's an interesting thought. As you say, it may be more of a cultural than technical issue. So, unless someone thinks what I am proposing in my previous paragraph has any potential (as a complete solution, not a complement to solutions), the plan is the following: * Get rid of the h= parameter Agree. * Add a s= parameter that uses a unique public key for each session. This public key identifies the payee to the payer and payer to the payee. This would be the simple model, which just tacks on another parameter to the bitcoin URL: bitcoin:[address]?bt=macs=key But we should also look at the more flexible r# approach from your existing TBIPs, which would yield: bitcoin:[address]?r=bt:mac/key and incorporate the payment_url list. * Use a base58 encoding to save space and reduce the character set slightly. :) * Get rid of the resource? If a terminal is accepting payment from multiple customers simultaneously, it should be smart enough to distinguish between customers based on the public key they are encrypting the data with. Is this approach feasible? Yes, it is not necessary on the URL. But an id is useful in helping the BT terminal identify the session without having to try all of its outstanding keys until it finds one that works. I proposed that the resource name (session id may be a better name) be deterministically derived from the session key. Given the design change to pass an EC public key it would need to be derived from that key (not from the session key because the receiver would not have a copy before decrypting the first BT message). So any function on the public key that reduces it to a smaller length, fixed width should be fine. Hashing it first may be better
Re: [Bitcoin-development] Request for comments on hybrid PoW/PoS enhancement for Bitcoin
Hi Mike, Thanks for the feedback and letting me know that my earlier emails fell victim to spam. My scheme might be better because it would add further incentives for running full nodes. A full node can be run on even a cheap laptop. In my experience, once a person new to bitcoin accepts it as at worthy of attention, the next area of interest is how to mine. They'll learn about mining pools, search, and if they are technical enough, they'll join the pool and likely be disappointed with their results. They'll then consider a graphics card, or ASICs, or just stop mining altogether. And I wouldn't be surprised if, when making that selection of a mining pool, a person might, based on limited information, decide that the best mining pool to join is the largest. I've made a number of assumptions in that progression to further my point, but I don't think that journey is too far off mark. I do so to illustrate that for a person to enjoy some financial reward for running a full node, in practice, it isn't as simple as running a full node . My proposal makes it easier for a full node to enjoy rewards, and to do so on modest hardware. In that sense, it is better than what we have now. Many people new to bitcoin express an interest in mining. I suspect that the primary motive that they want a way to earn bitcoin using the computer ** that they have **. If you too believe this, then I hope you'd agree that my proposal offers a solution that meets the desires of that person new to bitcoin. It makes bitcoin more accommodating, which makes it better, but this time on a social rather than technological scale. This would help ** keep ** people interested in bitcoin and result in ecosystem growth. With a larger ecosystem running full nodes, the blockchain becomes more secure. That's better. Then there are the merits of enodorsement itself which is at the heart of my new scheme which one might argue could raise the bar from 51% to 101% to pull off such an attack. I don't know that my scheme helps on the sybil front, but since it requires and builds on top of the current system, I don't know that is makes it any worse. I tried to be more crisp, but that's one of the areas I need to improve. Thanks -Chris On Wed, Feb 25, 2015 at 7:30 AM, Mike Hearn m...@plan99.net wrote: Hi Chris, Just FYI you may not have received much feedback on this because Gmail put it into the spam folder for some reason. So I'm guessing a lot of people didn't see it. My main feedback is - I do not really see how this is different from actual mining. Mining also incentives the running of full nodes, miners are rewarded via coinbases, etc. I'm missing a crisp description of why your scheme is better than this, in particular, taking into account the difficulty of distinguishing full node sybils of each other. -- 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] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
Hello, I think were talking about a lot of the same things. There is one key piece of information that I was not thinking about until you made it clear. Why the payee needs to identify the payer. In my fuel pump application, they really don't, so I wasn't thinking closely about these other situations. With my fuel pump, it won't even let you do anything until you sign a transaction and submit it. So, the payment request contains no personal information, it's just a request for payment, and not for anything specific. It doesn't know or care what you are going to buy until you make a prepayment, because there is no use in trying to start doing business without a signed transaction. This approach minimizes risk because once you dispense a fuel, or anything else, it's not like you can easily give it back if you happened to not have any funds. It also makes it a higher chance for a confirmation before the customer leaves. Other transactions have similar post payment traditions, like a restaurant (not fast food), where the seller doesn't know if you actually have enough money until you've already consumed the food, but this work flow seems to be a culturally driven one rather than risk driven. In the discussion about an https website, there are many websites where no login or authentication by the client required to have a private connection. With a shopping website though, the customer can identify themselves without logging in by saying (in band) what they are intending to buy after the private connection has been established. At a cash register in person the items being purchased have no tie to the customer. The items being purchased were communicated to the seller out of band (in real life) and insecurely to establish that link. You are trying to make a tie between that list of items and the buyer separately, and that is why some unique identifier needs to be transmitted via NFC. Stepping a bit back: I guess I'm wondering if it would be useful to encourage an opposite work flow where a micro payment channel is setup for most purchases. For example, if I go to the grocery store, it usually takes a minute or so to check out. If I immediately tap and open up a payment channel with the store when I start checkout, rather than finish, there can be more network propagation of that transaction while they are scanning all the items. They'll see the channel is open and start adding all the items I want to buy to that micro payment channel. I'm identified because I made a payment, not because I've transmitted a unique resource or used a unique public key to encrypt communication. A payment terminal would not allow for new payment channels to be open until the currently active one is closed. If I don't have enough funds left in the payment channel, they just stop scanning items. There may be some additional privacy implications of setting up micro payment channels all the time for everyday purchases. It also may not work for every sales case, so we may still need some way to authenticate the payer with a unique identifier. So, maybe we don't want to do this, but it is just a thought to consider. So, unless someone thinks what I am proposing in my previous paragraph has any potential (as a complete solution, not a complement to solutions), the plan is the following: * Get rid of the h= parameter * Add a s= parameter that uses a unique public key for each session. This public key identifies the payee to the payer and payer to the payee. * Use a base58 encoding to save space and reduce the character set slightly. * Get rid of the resource? If a terminal is accepting payment from multiple customers simultaneously, it should be smart enough to distinguish between customers based on the public key they are encrypting the data with. Is this approach feasible? * When you said a new public key for each tap, do you see that as every single tap, or do you consider multiple taps from the same customer the same tap? Andy Schroder On 02/24/2015 06:28 AM, Eric Voskuil wrote: On 02/23/2015 09:53 PM, Andy Schroder wrote: I was saying provide a public key via NFC (or a public key fingerprint and then send the full public key over bluetooth). Instead of providing a new public key on each tap, why can't the payee just stop accepting connections from new parties on that resource after a session key has been received from the first person? Because the presumption was that there was not an additional secret in the URI. If the public key is reused then anyone can spoof a payer and obtain payment requests. Adding a secret to the URI can resolve this, as long as it is encrypted with the public key before being transmitted back to BT. Otherwise the secret can be intercepted and replayed to the terminal, encrypted with the well-known public key. So if you want to treat the resource as a secret this would work. However the resource was designed as a
Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
Andy Schroder On 02/23/2015 10:09 AM, Jan Vornberger wrote: Hey! On Sun, Feb 22, 2015 at 05:37:16PM -0500, Andy Schroder wrote: It's maybe not a bad idea for the wallet to try all payment_url mechanisms in parallel. Should we add this as a recommendation to wallets in TBIP75? It doesn't need to be a recommendation I think, but maybe it would be good to mention that a wallet may do that, if it wants. I actually also happen to be using nfcpy. I am having some reliability issues as well with it. What exactly are your problems? Aw, interesting. Sometimes transfers seem to start and then not complete in some way and occasionally the NFC dongle is then totally 'stuck' in some way afterwards, that even after restarting the Python script or reloading the driver nothing works anymore. I have to actually unplug the dongle and plug it in again. Obviously not exactly production ready. I had the same problems with the command line tools based on libnfc, so it might be a problem lower down the stack. I'm not sure I have the expertise to troubleshoot that. I've had similar issues where the NFC device has to be disconnected and reconnected. I've got lots of error checking in my code on the NFC device, which helps, but still has problems sometimes. I've found if I limit how quickly a new connection can be made, that reduces the problem. Have you tried this? What command line tool are you using with libnfc? I have seen your video before. I guess I'm wondering how your prototype works with bitpay and bluetooth. Doesn't bitpay sign the payment request for you with an https based payment_url? If so, how do you add the bluetooth payment_url while keeping their signature valid? Good point, I'm currently simply removing the signature, so that I can modify the payment request. I haven't spoken with BitPay yet, but I hope that they will extend their API at some point to set additional payment_urls or provide a Bluetooth MAC and then I can do it properly with signed requests. This sounds weird to me. Why are you even using bitpay at all if you are already going through the effort to remove a signature and change the memo field? Wouldn't it be better to just manage everything yourself? In your video it looks like the phone still has cellular and wifi reception (it is not offline). You are right, I forgot to actually disable wifi and cellular data when recording the video. But as you know it would work the same way offline. Regarding the NFC data formats. I would like to clarify that the wallets are having those events dispatched by the android OS. The URI and mime type events are sent to the application in the same way as from other sources such as a web browser, e-mail, stand alone QR code scanner app, etc.. So, I don't think the wallet actually knows it is receiving the event from NFC. That is one reason why so many existing wallets happen to support BIP21 payment request via NFC. Andreas can correct me if I am wrong on these statements. I'm a little weary sending the mime type based format over NFC because of backwards compatibility and because of the long certificate chain that needs to be transferred. You want that tap to be as robust and fast as possible. A bluetooth connection can have a retry without any user interaction. There is a specific NFC intent that you have to list in your Android manifest, but you are right that if you already support BIP21 URIs then it is often fairly easy and quick to also support them via NFC. Whereas the mime type approach means that you necessarily need to be able to actually understand BIP70, which a lot of wallet don't yet. But personally that wouldn't hold me back using the mime type if I feel it's the better experience. Those wallets simply have to fall back on scanning the QR code in the meantime and then get up to speed on their NFC and BIP70 support. I'm still concerned that the fact, that Bluetooth is often disabled, is a problem for the UX. And it's not just a one-time thing as with NFC, which is - in my experience - also often disabled, but then people turn it on and leave it on. But with Bluetooth the Android system is geared much more towards turning it off after use and people have this general idea of 'it uses energy, so I should disable it' and sometimes also 'Bluetooth is insecure and if I leave it on I will get hacked'. So chances are, Bluetooth will be off most of the time, which means everytime you pay the dialog 'Turn on Bluetooth?' will pop up, which isn't exactly streamlined. I'm personally not to annoyed by the enable bluetooth popup. I do know what you mean about the bluetooth is insecure, I should disable it attitude. I used to have this same concern. So the advantage of transmitting the whole BIP70 payment request via NFC I see is, that you don't need Bluetooth to get the payment request and for sending the transaction back the wallet can then make an intelligent decision and first try via HTTP and only
Re: [Bitcoin-development] Request for comments on hybrid PoW/PoS enhancement for Bitcoin
This is an interesting idea from the standpoint of trying to incentivize people to run nodes, though from a high level it seems to just be adding complexity to the current process by which nodes 'endorse' blocks. When a node receives and validates a block it then informs its peers of the new inventory, thus offering to send the block that 'endorses' as valid. Because there is an incentive to include endorsers, there is an incentive to broadcast mined blocks as soon as possible. - I'd say that this is already the case due to the incentive for a miner's block to get propagated around the network first. My first question would be whether or not your proposal would include a change to how nodes propagate new blocks. At the moment, a node that hears about a second valid block at the tip of the chain will ignore it and not propagate it to its peers. Wouldn't your proposal necessitate a change to this logic so that blocks with 'better' endorsements get propagated even if they are received after non-endorsed or lesser-endorsed blocks? I'd also be interested to know more how endorsements would be limited (fairly) to only a subset of nodes. I'm a bit fuzzy on the endorsement timing. You're saying that a miner will add endorsement payouts in their block based upon nodes that endorsed the previous block? Which means they're paying nodes to endorse a block that they probably didn't even mine? Or would a miner only include payouts to endorsers for the last block that they mined that was accepted by the network? - Jameson On Mon, Feb 23, 2015 at 2:27 PM, Chris Page pag...@gmail.com wrote: I'm soliciting feedback on an idea to will improve security, increase the number of full nodes, and provide more avenues for bitcoin distribution. The idea is still in its infancy, but I need constructive feedback before I take this further, or decide to abandon the idea. In particular, my ego is in check and I'm ready to be made a fool, but in turn, I'll be that much better educated, so fair trade! Here is the high-level overview: 1) A new block B0 is mined and broadcast as usual 2) Full nodes verify block B0. A subset of these nodes broadcast a new endorsement message endorsing the block as valid, and preferred. 3) Miners, now assembling and beginning mining a new block (B1), add endorsements of B0 to B1's coinbase transaction, sharing the block reward with endorsers of B0. As proposed, the idea of Block Endorsement requires a new message, but fits into current structures. Here some details about each of the steps above, and what it buys us: 1) The mining of block B0: No changes to current process or format. Blocks are mined and broadcast as they are today. 2) Only a subset of nodes are eligible to endorse a block, and hence, only a subset are eligible for an endorsement reward. We restrict to avoid a flood of endorsement messages by every node following the announcement of each new block. An endorsement message needs to identify exactly one block at a specific height that it is endorsing. It needs to include a payout address that meets certain validation criteria relative to the block it is endorsing. A valid payout address will include some proof of stake (PoS), whether that be that it has a 1+ bitcoin balance, some age weighted balance, or something else is TBD. The reason for PoS is that it should not be the case that a subversive miner could easily fabricate a valid endorsement payout address. The other requirement is that the tail bits of a valid endorsement payout address, when masked (size of mask TBD) need to match the trailing bits of the hash of the block it is validating. This directly ties endorsements to a specific block, and makes it computationally inexpensive to verify/relay, or drop invalid endorsement messages. The combination of PoS and mask will restrict the number of valid addresses. There are no restrictions on which endorsements a miner can include, as long as they are valid. As part of new block validation, full nodes would need to do all that they do now, but they would also need to validate endorsements included in the coinbase transaction. 3) Miners consider whether to include endorsement payouts as part of their coinbase transaction. They need not do so, but by including endorsements, they significantly increase the likelihood that their block will be selected. CHANGE TO BEST CHAIN SELECTION Block Endorsement requires a change to the best chain selection algorithm to encourage miners to include endorsement payouts. Because there is an incentive to include endorsers, there is an incentive to broadcast mined blocks as soon as possible. For the purpose of best chain selection, a block should get a significant bonus to its work (10%) for each valid endorsement payout included in a block's valid coinbase transaction. How many endorsements should be permitted is a design parameter which is in play, but let's assume that up to
Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
On Tue, Feb 24, 2015 at 01:14:43AM -0500, Andy Schroder wrote: I've had similar issues where the NFC device has to be disconnected and reconnected. I've got lots of error checking in my code on the NFC device, which helps, but still has problems sometimes. I've found if I limit how quickly a new connection can be made, that reduces the problem. Have you tried this? I have a limit there, yes, but maybe I need to raise it. I'd rather would like it to simply not jam up instead though. :-) What command line tool are you using with libnfc? I don't remember exactly right now, but the Debian packages 'libnfc-bin' and 'libnfc-examples' have some binaries and I think I used one of them to present an NFC URI record and I ran into similar problems with instability. This sounds weird to me. Why are you even using bitpay at all if you are already going through the effort to remove a signature and change the memo field? For their tie-in with the traditional banking system, i.e. cash-out in fiat. Here in Germany that might currently be the only feasible way of accepting bitcoins commercially, because of unresolved questions around VAT - but that's another topic. Jan -- 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] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
We can change resource to Session ID if you want. I think the URL scheme should be: bitcoin:[address]?r=bt:macs=PublicKey But when connecting to the mac, the client indicates the SessionID in the header, and as you say, SessionID is derived in some way from PublicKey. This is a slightly different format than both of your suggestions below, but seems to make more sense based on what you said in your entire message. The other thing is it can be used with more protocols without taking up more space in the URL. However, by loosing the h= parameter, I think we are now loosing some benefit it brought to https based connections if the customer doesn't want to use bluetooth. Right? Also, you talk about a new public key (and session ID) for each tap. I guess I'm wondering about this though. If the public key is compromised on the first tap, isn't their payment request already compromised? Since we are securing everything, can we change the message header format from what Schildbach's bitcoin wallet implements to something more consistent? Maybe we can create a new UUID for this secure service so Schildbach's bitcoin wallet can still maintain backwards compatibility. Andy Schroder On 02/24/2015 05:14 PM, Eric Voskuil wrote: * Add a s= parameter that uses a unique public key for each session. This public key identifies the payee to the payer and payer to the payee. This would be the simple model, which just tacks on another parameter to the bitcoin URL: bitcoin:[address]?bt=macs=key But we should also look at the more flexible r# approach from your existing TBIPs, which would yield: bitcoin:[address]?r=bt:mac/key and incorporate the payment_url list. * Use a base58 encoding to save space and reduce the character set slightly. :) * Get rid of the resource? If a terminal is accepting payment from multiple customers simultaneously, it should be smart enough to distinguish between customers based on the public key they are encrypting the data with. Is this approach feasible? Yes, it is not necessary on the URL. But an id is useful in helping the BT terminal identify the session without having to try all of its outstanding keys until it finds one that works. I proposed that the resource name (session id may be a better name) be deterministically derived from the session key. Given the design change to pass an EC public key it would need to be derived from that key (not from the session key because the receiver would not have a copy before decrypting the first BT message). So any function on the public key that reduces it to a smaller length, fixed width should be fine. Hashing it first may be better as is prevents disclosure of any bits of the public key, which should be treated as a secret during the session. * When you said a new public key for each tap, do you see that as every single tap, or do you consider multiple taps from the same customer the same tap? Yes, since there would be no other way to distinguish between customers in some scenarios and this is the safest approach. We certainly won't run out of numbers, and unused sessions can be discarded based on any number of criteria, including discarding all but the most recent. That may may be sufficient for your vending machines given there's little if any call for parallelism. e signature.asc Description: OpenPGP digital signature -- 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] Request for comments on hybrid PoW/PoS enhancement for Bitcoin
Thanks for the feedback and questions. Answers inline. On Tue, Feb 24, 2015 at 9:54 AM, Jameson Lopp jameson.l...@gmail.com wrote: This is an interesting idea from the standpoint of trying to incentivize people to run nodes, though from a high level it seems to just be adding complexity to the current process by which nodes 'endorse' blocks. When a node receives and validates a block it then informs its peers of the new inventory, thus offering to send the block that 'endorses' as valid. Because there is an incentive to include endorsers, there is an incentive to broadcast mined blocks as soon as possible. - I'd say that this is already the case due to the incentive for a miner's block to get propagated around the network first. I agree with this, for well meaning miners. In the case of a 51% attack, there is an incentive to mine a block and not share it right away, so that another block could be mined on top of it. Because that first block wasn't shared, it wouldn't have endorsers. The total work represented in this attack chain, even with 2 blocks, would ideally represent less work that one fully endorsed block. This is because, as currently proposed, endorsers provide a work multiplier, which when a block has a full complement of endorsers, its proof of work is doubled for the purpose of best chain selection. That's if we allow up to 10 endorsers each providing a 10% work bonus. My concern is that giving endorsers too much power potentially opens up another attack vector where endorsers could collude to endorse an invalid block. But that's why it is so important that the selection criteria for endorsers needs to be both random and narrow. I discuss that more below. My first question would be whether or not your proposal would include a change to how nodes propagate new blocks. At the moment, a node that hears about a second valid block at the tip of the chain will ignore it and not propagate it to its peers. Wouldn't your proposal necessitate a change to this logic so that blocks with 'better' endorsements get propagated even if they are received after non-endorsed or lesser-endorsed blocks? I think that the proposal does impact consensus, which creates a high barrier to acceptance, and I'm not yet convinced that the benefits are worth the risk. My hope is that in sharing the idea, we can identify ways to reduce the risk. Whenever there is a fork, Bitcoin chooses the chain with the most work. I could easily be mistaken, so correct me if I cam wrong, but based on a current level of difficulty, any arriving valid block is going to present an equivalent proof of work. So currently, it makes sense to simply ignore a second valid block. With the proposal, if a second valid block came in with more endorsers, it would displace the current tip. In practice, with proper incentive, I would expect all found blocks to have the same number of endorsers. Therefore all incoming blocks would be interchangeable, and it would be the case that in practice, a second valid block would be ignored just as today. I'd also be interested to know more how endorsements would be limited (fairly) to only a subset of nodes. A node endorses by providing an address for payout. The limiting criteria is a function of that address. The first requirement is that the address must have a relationship to the block that it is endorsing. As an example, 082ab88cefb003f1dc1fa25881dbd56ed58c0548fbec5382 is the hash of a recent block. The requirement is that the address matches some number (TBD) of trailing bits. If the threshold were 32 bits, then the address (more likely, the hash of the public address) would need to end in fbec5382.. An valid address must have some proof of stake. Maybe that isn't fair, because it limits participation by balance, and it is yet another case of the rich get richer. But without proof of stake, everyone would generate enough addresses so that they could always find an address that meets the first requirement. Assuming the idea has merit, in order to get it right, we'd need much discussion to understand what combination of PoS and size of mask makes sense. I'm a bit fuzzy on the endorsement timing. You're saying that a miner will add endorsement payouts in their block based upon nodes that endorsed the previous block? Which means they're paying nodes to endorse a block that they probably didn't even mine? Or would a miner only include payouts to endorsers for the last block that they mined that was accepted by the network? With my proposal, miners would not be required to payout to endorsers at all. I think that this would help us avoid a hard fork. But when they choose to payout to endorsers, yes, they would be paying out to those that endorsed the tip of the chain that they are building on. Why would a miner ever do that? Because they would benefit from the multiplier provided by the endorsers. Any block that includes
Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
The list appears dead, this is a test. e signature.asc Description: OpenPGP digital signature -- 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
[Bitcoin-development] BCF 2012 Miner vote
It would appear that the Bitcoin Foundation has decided that their next two seats would be decided by miners. (More information available at: https://bitcoinfoundation.org/forum/index.php?/topic/1255-blockchain-voting/#entry13453 ) Unfortunately, they seem to have not provided the software needed to participate. I've taken Luke DashJr's somewhat notorious IsNotorious patch, which he's used previously to block things like the Horse Stapler Battery dust-spam attacks and re-purposed it so miners can avoid casting votes in the election that they don't intend to cast. Not really an ideal fit, but the code has the benefit of having been run in production for some time; a necessity for deployment on short notice. A patch (against git master, but should apply to 0.10 cleanly at least and probably other versions) is available at: https://people.xiph.org/~greg/bcf2012.patch Let me know if you have any trouble applying it, I'll be glad to do my civic duty and do what I can to help people participate with the system was clearly intended by the design. [Please note that I am relying on some claims from reddit for some of the candidate addresses ( http://www.reddit.com/r/Bitcoin/comments/2x3ffk/bitcoin_foundation_runoff_voting_live_stats_2015/ ) because the official voting software is more or less completely busted for me and I can only see some of the candidates. If any are wrong, please let me know.] Cheers. -- 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] Providing Payment Request within URI
Andreas' wallet supports this, but don't do it. Payment requests can get larger in future even without signing. Exploding the capacity of a QR code is very easy. Instead, take a look at the Bluetooth/NFC discussion happening in a different thread. On Tue, Feb 24, 2015 at 4:58 PM, Oleg Andreev olega...@gmail.com wrote: Hi, I wonder if there is a standard way to put Payment Request data into bitcoin: URI or directly into QR code. The goal is to allow device to generate a multi-output payment request on its own, without relying on the server and x509 certificates. When scanned via QR code from, say, POS, it's pretty secure, so no additional authentication needed. I'd like something like this: bitcoin:?r=data://base64url-encoded-payment-request If there's no standard for that, would it be a good idea to extend BIP72 this way? -- 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] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
On 02/24/2015 02:50 PM, Andy Schroder wrote: We can change resource to Session ID if you want. I think the URL scheme should be: bitcoin:[address]?r=bt:macs=PublicKey This is a question of proper URL semantics, as applied to the bt scheme. From rfc3986 [Uniform Resource Identifier (URI): Generic Syntax]: The path component contains data, usually organized in hierarchical form, that, along with data in the non-hierarchical query component (Section 3.4), serves to identify a resource within the scope of the URI's scheme and naming authority (if any). ... The query component contains non-hierarchical data that, along with data in the path component (Section 3.3), serves to identify a resource within the scope of the URI's scheme and naming authority (if any). The query component is indicated by the first question mark (?) character and terminated by a number sign (#) character or by the end of the URI. https://tools.ietf.org/html/rfc3986#section-3.3 The question therefore is whether key is (1) relative to the path (hierarchical) or (2) independent of the path and instead relative to the scheme and naming authority. The bt scheme does not include a naming authority, and as such the question is simply whether key is relative to bt or relative to the path, which is mac. Quite clearly key is valid only in the context of mac, not relevant to all macs. As such one must conclude that the proper form is: bt:mac/key But when connecting to the mac, the client indicates the SessionID in the header, and as you say, SessionID is derived in some way from PublicKey. Yes. This is a slightly different format than both of your suggestions below, but seems to make more sense based on what you said in your entire message. The other thing is it can be used with more protocols without taking up more space in the URL. However, by loosing the h= parameter, I think we are now loosing some benefit it brought to https based connections if the customer doesn't want to use bluetooth. Right? I don't believe that the BIP-70 protocol over https has any need for the parameter. It was only useful because the NFC/BT session wasn't secured. So I don't think anything is lost. Also, you talk about a new public key (and session ID) for each tap. I guess I'm wondering about this though. If the public key is compromised on the first tap, isn't their payment request already compromised? Yes, but that is not the problem that non-reuse is designed to resolve. Reuse of the public key creates a forward secrecy problem. If 1000 sessions are recorded, and later the private key associated with the reused public key is compromized, all of the sessions are retroactively compromised. Another problem is persistent impersonation. If the one associated private key is compromised, and nobody knows it, the attacker can not only monitor all transactions but can selectively steal payments (if they aren't signed and verified). This is BTW also a good reason to not use HD generation of these session keys. Another problem is that any payer can use the well-known public key to obtain payment requests. Another problem is that without a unique public key there is no unique session id, so that would need to be added explicitly on the URI. Since we are securing everything, can we change the message header format from what Schildbach's bitcoin wallet implements to something more consistent? Could you spell this out, I'm not familiar with the implementation, just the proposals. Maybe we can create a new UUID for this secure service so Schildbach's bitcoin wallet can still maintain backwards compatibility. That may be necessary depending on the implementation of existing terminals, but I'm not familiar enough to speculate. e On 02/24/2015 05:14 PM, Eric Voskuil wrote: * Add a s= parameter that uses a unique public key for each session. This public key identifies the payee to the payer and payer to the payee. This would be the simple model, which just tacks on another parameter to the bitcoin URL: bitcoin:[address]?bt=macs=key But we should also look at the more flexible r# approach from your existing TBIPs, which would yield: bitcoin:[address]?r=bt:mac/key and incorporate the payment_url list. * Use a base58 encoding to save space and reduce the character set slightly. :) * Get rid of the resource? If a terminal is accepting payment from multiple customers simultaneously, it should be smart enough to distinguish between customers based on the public key they are encrypting the data with. Is this approach feasible? Yes, it is not necessary on the URL. But an id is useful in helping the BT terminal identify the session without having to try all of its outstanding keys until it finds one that works. I proposed that the resource name (session id may be a better name) be deterministically derived from the session key. Given the design change to pass an EC
Re: [Bitcoin-development] Request for comments on hybrid, PoW/PoS enhancement for Bitcoin
Having stakeholders endorse blocks has, according to you, the benefits of increasing the number of full nodes and making a 51% attack more expensive. It seems to me it would have the opposite effects and other negative side effects. Any stakeholder that has won could just be running an SPV client and be informed by a full node that they have won, then cooperate to collect the reward. You are mistaking proof of stake as a proof you are running a full node. At the same time, the network becomes cheaper to attack in proportion to the amount of the block reward that is paid to endorsers. Another side effect is that miners would have a bigger economy of scale. The more stake a miner has, the more they can endorse their own blocks and not others blocks. I recommend reading this: https://download.wpsoftware.net/bitcoin/pos.pdf -Andrew Lapp -- 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] Request for comments on hybrid, PoW/PoS enhancement for Bitcoin
I definitely need to have an deeper understanding of that paper before proceeding. Thanks for the reference! On Wed, Feb 25, 2015 at 4:58 PM, Andrew Lapp la...@purdue.edu wrote: Having stakeholders endorse blocks has, according to you, the benefits of increasing the number of full nodes and making a 51% attack more expensive. It seems to me it would have the opposite effects and other negative side effects. Any stakeholder that has won could just be running an SPV client and be informed by a full node that they have won, then cooperate to collect the reward. You are mistaking proof of stake as a proof you are running a full node. At the same time, the network becomes cheaper to attack in proportion to the amount of the block reward that is paid to endorsers. Another side effect is that miners would have a bigger economy of scale. The more stake a miner has, the more they can endorse their own blocks and not others blocks. I recommend reading this: https://download.wpsoftware.net/bitcoin/pos.pdf -Andrew Lapp -- 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
