Re: [Bitcoin-development] [softfork proposal] Strict DER signatures
On Mon, Jan 26, 2015 at 10:35 AM, Gregory Maxwell wrote: >> I'd like to request a BIP number for this. > > Sure. BIP0066. Four implementations exist now: * for master: https://github.com/bitcoin/bitcoin/pull/5713 (merged) * for 0.10.0: https://github.com/bitcoin/bitcoin/pull/5714 (merged, and included in 0.10.0rc4) * for 0.9.4: https://github.com/bitcoin/bitcoin/pull/5762 * for 0.8.6: https://github.com/bitcoin/bitcoin/pull/5765 The 0.8 and 0.9 version have reduced test code, as many tests rely on new test framework code in 0.10 and later, but the implementation code is identical. Work to improve that is certainly welcome. -- Pieter -- 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] Two Proposed BIPs - Bluetooth Communication and bitcoin: URI Scheme Improvements
I think the Bitcoin community needs a good person-to-person payment protocol for BLE simply because Bluetooth LE is effectively peer-to-peer. Unlike NFC or conventional Bluetooth, a $5 micro can be either the master or slave and talk directly to other $5 micros nearby. [ASIDE... BLE is also the first wireless tech that Apple has allowed us free access to. They have claimed all NFC/RFID connections for their own "Pay" junk, and Bluetooth accessories are all locked down into their "make for iphone" program which literally requires a letter from your lawyer to enter. Of course Apple is just one vendor.] Surely, as a community, we can make a rock-solid P2P protocol that is resistant to spoofing and vandalism. I'm a big fan of putting crypto to good use, and doing a slightly more complex protocol involving EC signing of nonces sounds great. My only change to the RedPhone based "commit protocol" proposed previously, is I'd like the confirmation code to be a 6-digit decimal number rather than words. Wordlists are good for Red phone's audio application, but it's a lot easier to display a 6-digit code on vending machines, small mobile screens, and printed receipts. Just my two cents. --- Peter D. Gray || Founder, Coinkite || Twitter: @dochex || GPG: A3A31BAD 5A2A5B10 pgpaNC0CJGzTx.pgp Description: PGP 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] determining change addresses using the least significant digits
On Wed, Feb 4, 2015 at 2:23 PM, Isidor Zeuner wrote: > Hi there, > > traditionally, the Bitcoin client strives to hide which output > addresses are change addresses going back to the payer. However, > especially with today's dynamically calculated miner fees, this > may often be ineffective: > > A user sending a payment using the Bitcoin client will usually enter > the payment amount only up to the number of digits which are > considered to be significant enough. So, the least significant digits > will often be zero for the payment. With dynamically calculated miner > fees, this will often not be the case for the change amount, making it > easy for an observer to classify the output addresses. > > A possible approach to handle this issue would be to add a randomized > offset amount to the payment amount. This offset amount can be small > in comparison to the payment amount. Sending someone too much can really play hell with their accounting. Unless you know they're okay with it, I wouldn't suggest it. I often randomly round up the output when I'm paying to a depository account... and I've thought that would be a useful feature to have, but I dunno how to usefully present a UI for "pay at least X but you're allowed to round-up up to 0.01 BTC more". Another strategy is this: create two change outputs, with uniform probablity make one equal to your payment amount (which is also nice because if your payment amount models future payment amount the change will be usefully sized) or split your change evenly. -- 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] determining change addresses using the least significant digits
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/06/2015 03:08 PM, Jeff Garzik wrote: > Yes. You can certainly add additional inputs and outputs -- and as > such you can increase privacy and defrag your wallet at the same > time. A lot could be done to make regular spends resemble CoinJoin transactions and vice verse. - -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k -BEGIN PGP SIGNATURE- iQIcBAEBCAAGBQJU1P7iAAoJECpf2nDq2eYjeXwQAJGdVdYta5CddfL+xyFNG2+l RMxkSABfgWQF6mDus6ul+EhRhOYEveuuukbK2ibcnY2U4H9ecb8Gttno9+Wi0YfM zcu1Wt/j5cJyUFjO9owZO5gse5mTCt+1njgNIGMlXHHbFEHc5OavXEgkvh8YcL/j E8Kk4YNM5Ovp47vh1ihkB4Zo+ihu5oMuY4vbBO7So4BIe8KaSLOTsOAccT17bWGo jtd6KdjfqsLSjhQoVtuQAsx9AGUS+jfjBRWSnwkeAdd4G4BE87/7DCdYnczFKhds kVwnHODA0+5dwEwZ/ChipKVzAVLVZ2a7BXUenax70P1QgfG8WwL0tueoKviRBLfc 6Xa80GHGo84qeGEkiste1qnG4XZWwi6pnTSTwP1f5CtVvGvfYRysHsMCm82Mr7vA pwrQULv6fkhI63xB+kfcXBPr0WIVrilVrEtGcypzIbPbQgRQ6k3Wg66zLoQTc8vA w2pOZYrEU1Rmfiv27/MLdvSuWzR0kF+nidwCBxUYBuKAA4K0Y8GBH0FApp9JmCEo LXIY4RU3sCCbP3C1qloN8k99q8+CDTwrZpzi2zi3r0zRorg/1tTXqavicE9KPC2j ymk+eFFJhqG51o/d6irzA5R+hK/T2JatDhneEwTBetsrbXq0D9jiN3+KB+vME0wf KJhXhGbElNyz7eA4EOMt =zcqb -END PGP SIGNATURE- 0xEAD9E623.asc Description: application/pgp-keys -- 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] determining change addresses using the least significant digits
Yes. You can certainly add additional inputs and outputs -- and as such you can increase privacy and defrag your wallet at the same time. On Fri, Feb 6, 2015 at 2:11 AM, Wladimir wrote: > On Wed, Feb 4, 2015 at 2:23 PM, Isidor Zeuner > wrote: > > > A possible approach to handle this issue would be to add a randomized > > offset amount to the payment amount. This offset amount can be small > > in comparison to the payment amount. > > > > Any thoughts? > > Adding/subtracting a randomized offset amount is one way, but there > have also been more sophisticated ideas to obfuscate the amount, e.g. > by adding multiple change outputs or even distributing over multiple > transactions (potentially coinjoined for further privacy). > > Mike Hearn had some ideas regarding obfuscation of payment amounts, > which still make sense, and he wrote about them here: > https://medium.com/@octskyward/merge-avoidance-7f95a386692f > > Wladimir > > > -- > 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 > -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- 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] Two Proposed BIPs - Bluetooth Communication and bitcoin: URI Scheme Improvements
> > verification using breadwallet on apple is much faster (<1s) than HTTPS > payment request on bitcoin wallet on android (apparently apple has a > significantly more optimized signature verification algorithm). Probably on Android it's being verified in Java instead of C++. Some Android APIs are backed by OpenSSL but I don't know off hand if the way we're verifying cert chains on Android is. It's eminently fixable, at any rate. X.509 cert chains are pretty bloated, but even so, shouldn't take several seconds to transfer even over Bluetooth. Bottom line is that there may be ~1s time transferring the data with this > current bluetooth connection. Not sure how slow it will be with the BLE > connection. > BLE isn't really connection oriented, as far as I know. -- 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] Two Proposed BIPs - Bluetooth Communication and bitcoin: URI Scheme Improvements
BLE meets a different use case than regular Bluetooth. BLE is designed to allow always-on broadcast "beacons" which are conceptually similar to NFC tags, with very low power requirements. The tradeoff for this ultra-low power consumption and always on nature is the same as with NFC tags: you get very little space for data, and they are essentially one way. That's why a common use case for it is to trigger some other mechanism like a classical Bluetooth socket or HTTPS connection. I think BLE has a role to play in Bitcoin payments, but probably not for actually transferring payment data. Rather, a merchant should be able to drop a BLE beacon in their shop, and then wallet apps can use that to learn where to download a payment request/upload a payment message. But the actual data transfer would still take place over Bluetooth, Wifi or the internet. That leads to the question of what the beacon broadcasts. A bitcoin URI is the obvious answer: the problem is a URI contains an address. No problem for the "throw money at a live performer" use case but a problem for the cafe use case. If we are willing to mandate BIP70 and remove the static address part from the URI the we get a "uri that points to a url" which is a bit inefficient but at least lets us distinguish bitcoin beacons from other kinds. That still leaves the fundamental question raised by the Airbitz spec - how does your wallet download the right payment request? Unfortunately that's a tough UI problem. I don't think comparing long hex strings manually is a good way to go. This seems less user friendly than a QR code. Once we solve that problem, how BLE beacons can trigger payments will all fall into place. The tech part isn't the hard part. -- 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] determining change addresses using the least significant digits
On Wed, Feb 4, 2015 at 2:23 PM, Isidor Zeuner wrote: > A possible approach to handle this issue would be to add a randomized > offset amount to the payment amount. This offset amount can be small > in comparison to the payment amount. > > Any thoughts? Adding/subtracting a randomized offset amount is one way, but there have also been more sophisticated ideas to obfuscate the amount, e.g. by adding multiple change outputs or even distributing over multiple transactions (potentially coinjoined for further privacy). Mike Hearn had some ideas regarding obfuscation of payment amounts, which still make sense, and he wrote about them here: https://medium.com/@octskyward/merge-avoidance-7f95a386692f Wladimir -- 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 Core 0.10.0rc4 tagged
On Thu, Feb 5, 2015 at 12:33 PM, Wladimir wrote: > FYI, I've just tagged v0.10rc4, and pushed my signatures to the > gitian.sigs repository. > > Please start your gitian builders! Thanks to the extremely quick response (a whopping 9 gitian builders already!), the executables and tarball for rc4 have been uploaded to the usual place: https://bitcoin.org/bin/0.10.0/test/ Wladimir -- 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] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
On 02/06/2015 12:59 AM, Roy Badami wrote: >> In this case there is no need for P2P communication, just pay to an >> address you already have for the other party. If you want to avoid >> address reuse, use stealth addressing. >> >> But yes, if you don't have a stealth address for the other party you can >> certainly communicate in private as peers where you trust that you share >> a public key. The core issue here is really bootstrapping of that trust >> in an ad hoc manner. > > Something interactive might still be nicer, though, to avoid the risk > of paying to an address that the payee no longer has the private key > for. "Nooo!! Don't pay to that address. I lost my old phone so I > generated a new wallet." Certainly, which brings us back to proximity. Which reminds me - it's important to keep in mind the scenario that arises when there is no person present to represent the receiver. Such as a vending machine purchase. Proximity in these cases is insufficient, as the receiver is not able to prevent application of a fraudulent NFC device or replacement of a static QR code. In these cases BIP-70 becomes essential. 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] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
2015-02-06 2:29 GMT+01:00 Eric Voskuil : > On 02/05/2015 04:36 PM, Martin Habovštiak wrote: >> I believe, we are still talking about transactions of physical >> people in physical world. So yes, it's proximity based - people >> tell the words by mouth. :) > > Notice from my original comment: > > A MITM can substitute the key. If you don't have verifiable > identity associated with the public key (PKI/WoT), you need > a shared secret (such as a secret phrase). > > I said this could only be accomplished using a shared secret or a > trusted public key. Exchanging a value that is derived from a pair of > public keys is a distinction without a difference. The problem remains > that the parties must have a secure/out-of-band channel for > communicating this value. > > The fact that they are face-to-face establishes this channel, but that > brings us back to the original problem, as it requires manual > verification - as in visual/audible scanning of the two values for > comparison. At that point the visual comparison of the address, or some > value derived from it, is simpler. I have never been against manual verification. What I'm trying to say is let's just make manual verification easier and more secure. Comparison of address is simpler for the coder but also simpler to attack. It has these problems: - Addresses broadcasted in plaintext (privacy issue) - Amounts broadcasted in plaintext (privacy issue) - Address is long - takes lot of time to verify (user experience issue) - Address prefix can be brute-forced, if too short or used to make "black hole" address if longer (vandalism issue) Commit protocol can be used for both the encryption and the authentication while user experience is not bad and everything is still secure. > >> In case of RedPhone, you read those words verbally over not-yet- >> verified channel relying on difficulty of spoofing your voice. Also >> the app remembers the public keys, so you don't need to verify >> second time. > > This is reasonable, but wouldn't help in the case of an ad-hoc > connection between parties who don't know each other well. > >> I suggest you to try RedPhone (called Signal on iPhone) yourself. >> It's free/open source, Internet-based and end-to-end encrypted. You >> may find it useful some day. Also I'm willing to help you with >> trying it after I wake up. (~8 hours: Send me private e-mail if >> you want to.) > > I appreciate the offer. I really don't trust *any* smartphone as a > platform for secure communication/data. But encrypting on the wire does > of course shrink the attack surface and increase the attacker's cost. > > e > >> Dňa 6. februára 2015 1:22:23 CET používateľ Eric Voskuil > napísal: > >>> On 02/05/2015 04:04 PM, MⒶrtin HⒶboⓋštiak wrote: That's exactly what I though when seeing the RedPhone code, but after I studied the commit protocol I realized it's actually secure and convenient way to do it. You should do that too. :) >> >>> I was analyzing the model as you described it to me. A formal analysis >>> of the security model of a particular implementation, based on >>> inference >>>from source code, is a bit beyond what I signed up for. But I'm >>> perfectly willing to comment on your description of the model if you >>> are >>> willing to indulge me. >> Shortly, how it works: The initiator of the connection sends commit message containing the hash of his temporary public ECDH part, second party sends back their public ECDH part and then initiator sends his public ECDH part in open. All three messages are hashed together and the first two bytes are used to select two words from a shared dictionary which are displayed on the screen of both the initiator and the second party. >> The parties communicate those two words and verify they match. >> >>> How do they compare words if they haven't yet established a secure >>> channel? >> If an attacker wants to do MITM, he has a chance of choosing right public parts 1:65536. There is no way to brute-force it, since that would be noticed immediately. If instead of two words based on the first two bytes, four words from BIP39 wordlist were chosen, it would provide entropy of 44 bits which I believe should be enough even for paranoid people. How this would work in Bitcoin payment scenario: user's phone broadcasts his name, merchant inputs amount and selects the name from the list, commit message is sent (and then the remaining two messages), merchant spells four words he sees on the screen and buyer confirms transaction after verifying that words match. >> >>> So the assumption is that there exists a secure (as in proximity-based) >>> communication channel? >> >>> e >> 2015-02-06 0:46 GMT+01:00 Eric Voskuil : > On 02/05/2015 03:36 PM, MⒶrtin HⒶboⓋštiak wrote: >>> A BIP-70 signed payment request in the initial broadcast can >>> resolve the >>> integrity issues, but beca
Re: [Bitcoin-development] Two Proposed BIPs - Bluetooth Communication and bitcoin: URI Scheme Improvements
On 02/06/2015 12:40 AM, Andreas Schildbach wrote: > On 02/06/2015 01:36 AM, Eric Voskuil wrote: > >> The main advantage of BLE over BT is that it uses much less power, with >> a trade-off in lower bandwidth (100 kbps vs. 2 mbps). The BLE range can >> be even greater and connection latency lower than BT. For payment >> purposes the lower bandwidth isn't much of a hit. > > I'm all for extending the BT: scheme to Bluetooth LE. If you have > ideas how this can be done please let us know. I haven't had a chance to > play around with LE because none of my devices support it. > > I suspect the way how Bluetooth LE transfers files (like payment > requests) is opening a plain old Bluetooth socket. If this is true, I'm > afraid Bluetooth LE would not add anything for sending the BIP70 > messages back and forth. Note signed payment requests can easily be 4 kB > in size, so speed *does* matter. Hi Andreas, I haven't expressed any preference for BLE, just answering questions that were raised about it. The main thing that BLE brings to the table is increased battery life, but with larger transfers that benefit is reduced. 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] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
> In this case there is no need for P2P communication, just pay to an > address you already have for the other party. If you want to avoid > address reuse, use stealth addressing. > > But yes, if you don't have a stealth address for the other party you can > certainly communicate in private as peers where you trust that you share > a public key. The core issue here is really bootstrapping of that trust > in an ad hoc manner. Something interactive might still be nicer, though, to avoid the risk of paying to an address that the payee no longer has the private key for. "Nooo!! Don't pay to that address. I lost my old phone so I generated a new wallet." roy -- 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] Two Proposed BIPs - Bluetooth Communication and bitcoin: URI Scheme Improvements
On 02/06/2015 02:40 AM, Andy Schroder wrote: > Where is a more appropriate place to discuss the other issues you have > at length? What's wrong with this mailing list? -- 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] Two Proposed BIPs - Bluetooth Communication and bitcoin: URI Scheme Improvements
On 02/06/2015 01:36 AM, Eric Voskuil wrote: > The main advantage of BLE over BT is that it uses much less power, with > a trade-off in lower bandwidth (100 kbps vs. 2 mbps). The BLE range can > be even greater and connection latency lower than BT. For payment > purposes the lower bandwidth isn't much of a hit. I'm all for extending the BT: scheme to Bluetooth LE. If you have ideas how this can be done please let us know. I haven't had a chance to play around with LE because none of my devices support it. I suspect the way how Bluetooth LE transfers files (like payment requests) is opening a plain old Bluetooth socket. If this is true, I'm afraid Bluetooth LE would not add anything for sending the BIP70 messages back and forth. Note signed payment requests can easily be 4 kB in size, so speed *does* matter. -- 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
