Re: [Bitcoin-development] A suggestion for reducing the size of the UTXO database
On 05/25/2015 11:05 PM, Peter Todd wrote: On Mon, May 25, 2015 at 10:29:26PM +0200, Andreas Schildbach wrote: I see this behavior all the time. I am using the latest release, as far as I know. Version 4.30. The same behavior occurs in the Testnet3 variant of the app. Go in there with an empty wallet and receive one payment and wait for it to confirm. Then send a payment and, before it confirms, try to send another one. The wallet won't let you send the second payment. It'll say something like, You need x.xx more bitcoins to make this payment. But if you wait for your first payment to confirm, then you'll be able to make the second payment. If it matters, I configure the app to connect only to my own trusted Bitcoin node, so I only ever have one active connection at most. I notice that outgoing payments never show as Sent until they appear in a block, presumably because the app never sees the transaction come in over any connection. Yes, that's the issue. Because you're connecting only to one node, you don't get any instant confirmations -- due to a Bitcoin protocol limitation you can only get them from nodes you don't post the tx to. Odd, I just tried the above as well - with multiple peers connected - and had the exact same problem. It should work, I'm testing this regularly. Can you report an issue through the app and attach your log when this happens again? -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] A suggestion for reducing the size of the UTXO database
On 05/25/2015 10:03 PM, Matt Whitlock wrote: On Monday, 25 May 2015, at 8:41 pm, Mike Hearn wrote: some wallets (e.g., Andreas Schildbach's wallet) don't even allow it - you can only spend confirmed UTXOs. I can't tell you how aggravating it is to have to tell a friend, Oh, oops, I can't pay you yet. I have to wait for the last transaction I did to confirm first. All the more aggravating because I know, if I have multiple UTXOs in my wallet, I can make multiple spends within the same block. Andreas' wallet hasn't done that for years. Are you repeating this from some very old memory or do you actually see this issue in reality? The only time you're forced to wait for confirmations is when you have an unconfirmed inbound transaction, and thus the sender is unknown. I see this behavior all the time. I am using the latest release, as far as I know. Version 4.30. The same behavior occurs in the Testnet3 variant of the app. Go in there with an empty wallet and receive one payment and wait for it to confirm. Then send a payment and, before it confirms, try to send another one. The wallet won't let you send the second payment. It'll say something like, You need x.xx more bitcoins to make this payment. But if you wait for your first payment to confirm, then you'll be able to make the second payment. If it matters, I configure the app to connect only to my own trusted Bitcoin node, so I only ever have one active connection at most. I notice that outgoing payments never show as Sent until they appear in a block, presumably because the app never sees the transaction come in over any connection. Yes, that's the issue. Because you're connecting only to one node, you don't get any instant confirmations -- due to a Bitcoin protocol limitation you can only get them from nodes you don't post the tx to. -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] A suggestion for reducing the size of the UTXO database
Actually your assumption is wrong. Bitcoin Wallet (and I think most, if not all, other bitcoinj based wallets) picks UTXO by age, in order to maximize priority. So it keeps the number of UTXOs low, though not as low as if it would always pick *all* UTXOs. On 05/09/2015 07:09 PM, Jim Phillips wrote: Forgive me if this idea has been suggested before, but I made this suggestion on reddit and I got some feedback recommending I also bring it to this list -- so here goes. I wonder if there isn't perhaps a simpler way of dealing with UTXO growth. What if, rather than deal with the issue at the protocol level, we deal with it at the source of the problem -- the wallets. Right now, the typical wallet selects only the minimum number of unspent outputs when building a transaction. The goal is to keep the transaction size to a minimum so that the fee stays low. Consequently, lots of unspent outputs just don't get used, and are left lying around until some point in the future. What if we started designing wallets to consolidate unspent outputs? When selecting unspent outputs for a transaction, rather than choosing just the minimum number from a particular address, why not select them ALL? Take all of the UTXOs from a particular address or wallet, send however much needs to be spent to the payee, and send the rest back to the same address or a change address as a single output? Through this method, we should wind up shrinking the UTXO database over time rather than growing it with each transaction. Obviously, as Bitcoin gains wider adoption, the UTXO database will grow, simply because there are 7 billion people in the world, and eventually a good percentage of them will have one or more wallets with spendable bitcoin. But this idea could limit the growth at least. The vast majority of users are running one of a handful of different wallet apps: Core, Electrum; Armory; Mycelium; Breadwallet; Coinbase; Circle; Blockchain.info; and maybe a few others. The developers of all these wallets have a vested interest in the continued usefulness of Bitcoin, and so should not be opposed to changing their UTXO selection algorithms to one that reduces the UTXO database instead of growing it. From the miners perspective, even though these types of transactions would be larger, the fee could stay low. Miners actually benefit from them in that it reduces the amount of storage they need to dedicate to holding the UTXO. So miners are incentivized to mine these types of transactions with a higher priority despite a low fee. Relays could also get in on the action and enforce this type of behavior by refusing to relay or deprioritizing the relay of transactions that don't use all of the available UTXOs from the addresses used as inputs. Relays are not only the ones who benefit the most from a reduction of the UTXO database, they're also in the best position to promote good behavior. -- *James G. Phillips IV* https://plus.google.com/u/0/113107039501292625391/posts /Don't bunt. Aim out of the ball park. Aim for the company of immortals. -- David Ogilvy / /This message was created with 100% recycled electrons. Please think twice before printing./ -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Electrum 2.0 has been tagged
Thanks Thomas, for sharing your experience! I'd like know why you think it's a problem that BIP43 is tied to BIP32? I understand we all agreed at least on the BIP32-derivation spec (excluding the BIP32-hierarchy spec)? -- 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] Electrum 2.0 has been tagged
For reasonably skilled users your points are valid, but I'm sure you also – like me – encountered the kind of user who has absolutely no clue but thinks he understands. S/he will ignore warnings and run into troubles. This generates a huge amount of support cases and likely tears about lost coins. The simple fact that someone elses broken RNG implementation/wrapper could compromise the security of my software frightens me. On 03/11/2015 08:04 PM, Jim wrote: The wallet words system isn't perfect for sure but it does help the user in two main ways: 1) Assuming wallet devs ensure forward compatibility for _their_ wallet the user knows they can recover their bitcoins using the same wallet software in case of a Bad Thing Happening. 2) To an imperfect degree, they can transfer/ recover their bitcoins that are stored in Wallet X into Wallet Y. We need to give them guidance on how to do this. I think it is up to each wallet team to explain to their users clearly how they can do this in their help. It's only good manners to show your guests where the fire exits are. It can be a simple help page saying: If you want to transfer your bitcoin out of MultiBit HD to Lighthouse, do this, this and this. If you want to use the Trezor wallet you created in MultiBit HD on myTrezor.com, do this, this and this. That way users have clear instructions on how to recover their bitcoins. Users don't care about BIP this or BIP that but they REALLY DO CARE about keeping their bitcoins. -- 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] Electrum 2.0 has been tagged
Thy, your message threading is broken. Can you make sure your mail program uses the correct message ID when replying? -- 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] Electrum 2.0 has been tagged
That doesn't work for mobile wallets, because we need to consider the offline case. To fix this, we'd need to extend BIP70 to tell the merchant where to forward the half-signed transaction to. Then again I'm not sure if we want that, for privacy reasons. In any case, practical multisig is still a looong way off. On 03/12/2015 12:50 AM, devrandom wrote: I'd like to offer that the best practice for the shared wallet use case should be multi-device multi-sig. The mobile has a key, the desktop has a key and a third-party security oracle has a third key. The oracle would have different security thresholds for countersigning the mobile. This way you can have the same overall wallet on all devices, but different security profiles on different keys. That said, I do agree that mnemonic phrases should be portable, and find it unfortunate that the ecosystem is failing to standardize on phrase handling. On 2015-03-11 04:22 PM, Mike Hearn wrote: Users will want to have wallets shared between devices, it's as simple as that, especially for mobile/desktop wallets. Trying to stop them from doing that by making things gratuitously incompatible isn't the right approach: they'll just find workarounds or wallet apps will learn how to import seeds from other apps. Better to just explain the risks and help people mitigate them. On Wed, Mar 11, 2015 at 3:57 PM, Aaron Voisine vois...@gmail.com mailto:vois...@gmail.com wrote: I'm not convinced that wallet seed interoperability is such a great thing. There is a wide variability in the quality and security level of wallet implementations and platforms. Each new device and wallet software a user types their seed into increases their attack surface and exposure to flaws. Their security level is reduced to the lowest common denominator. I see the need for a fire exit, certainly, but we must also remember that fire exits are potential entrances for intruders. Aaron Voisine co-founder and CEO breadwallet.com http://breadwallet.com On Wed, Mar 11, 2015 at 12:46 PM, Gregory Maxwell gmaxw...@gmail.com mailto:gmaxw...@gmail.com wrote: On Wed, Mar 11, 2015 at 7:24 PM, Ricardo Filipe ricardojdfil...@gmail.com mailto:ricardojdfil...@gmail.com wrote: i guess you look at the glass half full :) even though what you say is true, we should aim for wallets not to require those instructions, by standardizing these things in BIPs. let's hope bitcoin doesn't fail in standards as our industries have in the past... There are genuine principled disagreements on how some things should be done. There are genuine differences in functionality. We cannot expect and should not expect complete compatibility. If you must have complete compatibility: use the same software (or maybe not even then, considering how poor the forward compatibility of some things has been..). What we can hope to do, and I think the best we can hope to do, is to minimize the amount of gratuitous incompatibility and reduce the amount of outright flawed constructions (so if there are choices which must be made, they're at least choices among relatively good options). -- 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 mailto: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 mailto:Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Electrum 2.0 has been tagged
On 03/12/2015 01:11 AM, Gregory Maxwell wrote: Ultimately, the most fundamental compatibility is guaranteed: you can always send your funds to another wallet. This always works and guarantees that you are never locked in to a single wallet. It is well tested and cannot drive any software in to weird or confused states. This. -- 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] Electrum 2.0 has been tagged
On 03/12/2015 07:27 PM, Natanael wrote: Den 12 mar 2015 17:48 skrev Mike Hearn m...@plan99.net mailto:m...@plan99.net: b) Creation date is just a short-term hack. I agree, but we need things to be easy in the short term as well as the long term :) The long term solution is clearly to have the 12 word seed be an encryption key for a wallet backup with all associated metadata. We're heading in that direction one step at a time. Unfortunately it will take time for wallets to start working this way, and all the pieces to fall into place. Restoring from the block chain will be a semi regular operation for users until then. This have been mentioned a few times before, and what I think is necessary is to create a common file format that can be interpreted by a library which all wallets can use. I see it as similar as the work to create libconsensus for parsing the blockchain. I'm afraid this will never fly. Wallets are just too different and that's a good thing! For example, by design choice Bitcoin Wallet and bitcoinj doesn't support multiple accounts. How would it ever import wallets from MultiBit or Mycelium? Bitcoinj-based wallets could probably share the bitcoinj protobuf wallet format (or whatever format we will be at the time of the merge – we already have tons of requirements piling up!). This would mean bitcoinj is the consensus library equivalent you were mentioning. -- 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] Electrum 2.0 has been tagged
Congrats on the release! Electrum is a very nice wallet. On 03/01/2015 04:23 PM, Thomas Voegtlin wrote: Dear Bitcoin devs, I just tagged version 2.0 of Electrum: https://github.com/spesmilo/electrum/tree/2.0 The electrum.org website will be updated later today. The release notes are a bit dense, due to the large amount of changes and new features in this release. In the coming weeks we will be adding more detailed documentation to the wiki and to the website. There has been a very long hiatus in Electrum releases, because it took me a lot of time to decide about the new seed derivation method and wallet structure. Now that this part is done, I hope that we will resume to a faster release pace. I would like to thank all the people who contributed to this release, developers, beta testers, but also people from this list who provided useful feedback. Cheers, Thomas _ RELEASE-NOTES # Release 2.0 * Before you upgrade, make sure you have saved your wallet seed on paper. * Documentation is now hosted on a wiki: http://electrum.orain.org * New seed derivation method (not compatible with BIP39). The seed phrase includes a version number, that refers to the wallet structure. The version number also serves as a checksum, and it will prevent the import of seeds from incompatible wallets. Old Electrum seeds are still supported. * New address derivation (BIP32). Standard wallets are single account and use a gap limit of 20. * Support for Multisig wallets using parallel BIP32 derivations and P2SH addresses (2 of 2, 2 of 3). * Compact serialization format for unsigned or partially signed transactions, that includes the BIP32 master public key and derivation needed to sign inputs. Serialized transactions can be sent to cosigners or to cold storage using QR codes (using Andreas Schildbach's base 43 idea). * Support for BIP70 payment requests: - Verification of the chain of signatures uses tlslite. - In the GUI, payment requests are shown in the 'Invoices' tab. * Support for hardware wallets: Trezor (Satoshilabs) and Btchip (Ledger). * Two-factor authentication service by TrustedCoin. This service uses 2 of 3 multisig wallets and Google Authenticator. Note that wallets protected by this service can be deterministically restored from seed, without Trustedcoin's server. * Cosigner Pool plugin: encrypted communication channel for multisig wallets, to send and receive partially signed transactions. * Audio Modem plugin: send and receive transactions by sound. * OpenAlias plugin: send bitcoins to aliases verified using DNSSEC. * New 'Receive' tab in the GUI: - create and manage payment requests, with QR Codes - the former 'Receive' tab was renamed to 'Addresses' - the former Point of Sale plugin is replaced by a resizeable window that pops up if you click on the QR code * The 'Send' tab in the Qt GUI supports transactions with multiple outputs, and raw hexadecimal scripts. * The GUI can connect to the Electrum daemon: electrum -d will start the daemon if it is not already running, and the GUI will connect to it. The daemon can serve several clients. It times out if no client uses if for more than 5 minutes. * The install wizard can be used to import addresses or private keys. A watching-only wallet is created by entering a list of addresses in the wizard dialog. * New file format: Wallets files are saved as JSON. Note that new wallet files cannot be read by older versions of Electrum. Old wallet files will be converted to the new format; this operation may take some time, because public keys will be derived for each address of your wallet. * The client accepts servers with a CA-signed SSL certificate. * ECIES encrypt/decrypt methods, availabe in the GUI and using the command line: encrypt pubkey message decrypt pubkey message * The Android GUI has received various updates and it is much more stable. Another script was added to Android, called Authenticator, that works completely offline: it reads an unsigned transaction shown as QR code, signs it and shows the result as a QR code. -- 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/ -- 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
Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
On 02/23/2015 04:09 PM, Jan Vornberger wrote: 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. It's the same with Bluetooth. More and more people use audio via Bluetooth, mostly because they use a headset or stream their music to their stereo at home. Those that still switch off Bluetooth all the time can simply press a button. It can't be any easier. Another idea could be to request the permission BLUETOOTH_ADMIN which, as far as I know, allows you to programmatically turn on Bluetooth without user interaction. True, but those people who switch off Bluetooth will also simply not install the app because of that permission. If only Android had optional permissions... )-: -- 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
Yeah, you'd be limited to simple usecases. X509 signing or lots of outputs will make the QR code hard to scan. However, if all you want to do is send to a custom script (without using P2SH) I invite you to have a look at https://github.com/schildbach/bitcoin-wallet/blob/master/wallet/src/de/schildbach/wallet/ui/InputParser.java#L86 https://github.com/schildbach/bitcoin-wallet/blob/master/wallet/src/de/schildbach/wallet/util/Qr.java#L134 https://github.com/schildbach/bitcoin-wallet/blob/master/wallet/src/de/schildbach/wallet/util/Base43.java Basically it's BITCOIN:- plus the payment request in Base43 encoded form. I picked Base43, because that's optimized for QR codes. On 02/24/2015 04:58 PM, Oleg Andreev 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/ -- 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
On 02/26/2015 12:14 PM, Oleg Andreev wrote: Base43 is the same as any BaseX standard, but using a different alphabet (43 characters). It's meant to be used for efficiently storing binary data into QR codes. The alphabet is picked to match the 'Alphanumeric' input mode of QR codes as closely as possible, but at the same time be allowed in URIs. Does it mean Base58 or Base64 take more space in QR code than Base43? Do you have an estimate of the gains? Both Base58 and Base64 force QR codes into binary encoding. Base64 can take 6 bits per char, binary of course has 8 bits per char. So you're wasting 25% of space if you use Base64, a little bit more with Base58. Base43 takes log2(43) = 5.43 bits per char, while each char uses up 5.5 bits in QR codes in 'Alphanumeric' encoding. So that's a waste of 1.3%. Source for QR code standard: http://en.wikipedia.org/wiki/QR_code -- 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:41 AM, Mike Hearn wrote: 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. What if the script doesn't use any key at all? Somehow this re-using the fallback address idea feels less and less appealing to me. I think we should add our own parameter and let go of fallback addresses as soon as possible. If will waste space during the transition period, but after that it should make no difference any more. -- 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/23/2015 01:18 PM, Mike Hearn wrote: I read from your answer that even if we use ECDHE, we can't use it for every situation. Which situations do you mean? I think it can be used in every situation. It's the opposite way around - a fixed session key in the URI cannot be used in every situation. Ok sorry probably I read wrong. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk ___ 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/23/2015 11:58 AM, Mike Hearn wrote: You're right that just sending the session key is simpler. I originally suggested doing ECDHE to set up an encrypted channel for the following reasons: [...] I read from your answer that even if we use ECDHE, we can't use it for every situation. So in any case we need the simple bootstrap via a session key parameter. My suggestion is defer ECDHE for now but keep it in mind. We can add it later I think. These discussions keep coming up. I think the next step is for someone to upgrade Andreas' wallet to support encrypted connections and the TBIPs, to see what happens. I happily step up and do the implementation work on the app side. A first step could be: - If there is an s parameter present wrap the Bluetooth connections with AES. Sounds good? -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk ___ 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
I think at this point I'd like to bring back my original suggestion of using DHKE (Diffie-Hellman) or simlar. I know we'd still need to transmit some secret that could be eavesdropped, but at least the session could not be decrypted from recordings. Anyway, establishing a mostly secure session is clearly an improvement to no protection at all. If we can't find a solution to the dilemma of how to exchange the secret, I suggest going ahead with what we have and make the best from it. On 02/23/2015 08:36 AM, Andy Schroder wrote: I agree that NFC is the best we have as far as a trust anchor that you are paying the right person. The thing I am worried about is the privacy loss that could happen if there is someone passively monitoring the connection. So, in response to some of your comments below and also in response to some of Eric Voskuil's comments in another recent e-mail: Consider some cases: If NFC is assumed private, then sending the session key over the NFC connection gives the payer and the payee assumed confidence that that a private bluetooth connection can be created. If the NFC actually isn't private, then by sending the session key over it means the bluetooth connection is not private. An eavesdropper can listen to all communication and possibly modify the communication, but the payer and payee won't necessarily know if eavesdropping occurs unless communication is also modified (which could be difficult to do for a really low range communication). If we send a public key of the payee over the NFC connection (in place of a session key) and the NFC connection is assumed trusted (and is unmodified but actually monitored by an eavesdropper) and use that public key received via NFC to encrypt a session key and send it back via bluetooth, to then initiate an encrypted bluetooth connection using that session key for the remaining communication, then the payee still receives payment as expected and the payer sends the payment they expected, and the eavesdropper doesn't see anything. If we send a public key of the payee over the NFC connection (in place of a session key) and the NFC connection is assumed trusted (and is actually modified by an eavesdropper) and use that public key received via NFC to encrypt a session key and send it back via bluetooth, to then initiate an encrypted bluetooth connection using that session key for the remaining communication, then the payee receives no payment and the attack is quickly identified because the customer receives no product for their payment and they notify the payee, and hopefully the problem remedied and no further customers are affected. The privacy loss will be significantly reduced and the motive for such attacks will be reduced. It's possible a really sophisticated modification could be done where the attacker encrypts and decrypts the communication and then relays to each party (without them knowing or any glitches detected), but I guess I'm not sure how easy that would be on such a close proximity device? Erick Voskuil mentioned this same problem would even occur if you had a hardwired connection to the payment terminal and those wires were compromised. I guess I still think what I am saying would be better in that case. There is also more obvious physical tampering required to mess with wires. I'm not sure if there is any trust anchor required of the payer by the payee, is there? Eric also mentioned a need for this. Why does the payer care who they are as long as they get a payment received? Just to avoid a sophisticated modification that I mention above? I can see how this could be the case for a longer range communication (like over the internet), but I'm not convinced it will be easy on really short ranges? It's almost like the attacker would be better off to just replace the entire POS internals than mess with an attack like that, in which case everything we could do locally (other than the payment request signing using PKI), is useless. I'm not a cryptography expert so I apologize if there is something rudimentary that I am missing here. Andy Schroder On 02/22/2015 08:02 PM, Andreas Schildbach wrote: On 02/23/2015 12:32 AM, Andy Schroder wrote: I guess we need to decide whether we want to consider NFC communication private or not. I don't know that I think it can be. An eavesdropper can place a tiny snooping device near and read the communication. If it is just passive, then the merchant/operator won't realize it's there. So, I don't know if I like your idea (mentioned in your other reply) of putting the session key in the URL is a good idea? I think the trust by proximity is the best we've got. If we don't trust the NFC link (or the QR code scan), what other options have we got? Speaking the session key by voice? Bad UX, and can be eavesdropped as well of course. -- Download
Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
On 02/22/2015 11:37 PM, Andy Schroder wrote: Andreas and I had a number of private discussions regarding the payment_url parameter. I had suggested a additional_payment_urls repeated parameter, but he didn't seem to like that idea and I personally am indifferent, so that is why we decided to just change payment_url to a repeated field. The spec is simpler without the additional_payment_urls, but the wallets have to be a little bit smarter finding the right url they want to use in the list. 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? I think it will cause too much chaos. My recommendation for the payment_url field is prefer the same mechanism that was used for fetching the payment request. Only if the recommendation fails use the alternatives in order (or in reverse order, I'm not sure at the moment). 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. I think it can know. The method for catching these intents is very similar and you can reuse almost all code, but in fact you need to add an additional line to your AndroidManifest.xml. That is one reason why so many existing wallets happen to support BIP21 payment request via NFC. Many? Bitcoin Wallet and its forks were the only ones for about a year. Only recently Mycelium caught up and the others still do not care I guess. 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. I agree whatever we do must be robust. However I see no reason why NFC can't be robust, see my previous post. I don't really like the Airbitz proposal. Figuring out if your selecting is the right one is a real nuisance. The idea is neat in a few applications, but I just don't think it is going to work for people as the most efficient and trouble free option day to day. I realize they are probably doing it to work with Apple's limited functionality phones (and BLE is a new buzz word). However, I don't think we should base bitcoin around what Apple wants us to do. They've already had their war on bitcoin. They are going to do whatever they can to protect their NFC based payment system. We need to make their platform the the less desirable one if they are going to play the game that way. If that means an Airbitz like proposal is implemented as a fallback, maybe that is fine and POS systems need to support both, but I just don't think we should limit what we can do because of Apple's products capabilities. Ack on Airbitz, and ack on our relationship to Apple (-: There is also the ack memo that I mentioned in reference [2]. I think we can improve upon this really. Can we make a new status field or different bluetooth message header? I know Andreas didn't want to change it because that is how his app already works, but I don't think the way it is is ideal. I'm not against improving this point, but I felt the BT enhancements and the r,r1,r2 proposals are already getting complex enough. I would like to simplify the proposal by moving unrelated things to somewhere else. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk ___ 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/23/2015 12:32 AM, Andy Schroder wrote: I guess we need to decide whether we want to consider NFC communication private or not. I don't know that I think it can be. An eavesdropper can place a tiny snooping device near and read the communication. If it is just passive, then the merchant/operator won't realize it's there. So, I don't know if I like your idea (mentioned in your other reply) of putting the session key in the URL is a good idea? I think the trust by proximity is the best we've got. If we don't trust the NFC link (or the QR code scan), what other options have we got? Speaking the session key by voice? Bad UX, and can be eavesdropped as well of course. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk ___ 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
Jan, this is great stuff! Thanks for sharing your experiences. I think the 4k payments requests issue must be solvable somehow. I had no trouble transmitting that amount via NFC, although yes a bit of delay was noticable. About payment_url: Protobuf allows changing optional to repeated and yes it's backwards compatible. Which is why I'm personally against parsing two fields rather than just one. 2) @Andreas: Is the r, r1, r2 mechanism already implemented in Bitcoin Wallet? No it isn't. It's implemented in bitcoinj though. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk ___ 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/22/2015 11:39 PM, Eric Voskuil wrote: The MAC address (and resource name) should be encoded using base58. This is shorter than base16, is often shorter than base64, better standardized and does not require URI encoding, and is generally available to implementers. Of course this is just a minor detail, but Base64Url is well defined, almost always more efficient than Base58 and never less efficient, and implemented in way more libraries and OSes than Base58. Base58 was designed for copy-typing by humans. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk ___ 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:mac 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
Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
Thanks Paul, for writing up your protocol! First thoughts: For a BIP standard, I think we should skip bitcoin: URIs entirely and publish BIP70 payment requests instead. URIs mainly stick around because of QR codes limited capacity. BIP70 would partly address the copycat problem by signing payment requests. In your Motivation section, I miss some words about NFC. NFC already addresses all of the usability issues mentioned and is supported by mobile wallets since 2011. That doesn't mean your method doesn't make sense in some situations, but I think it should be explained why to prefer broadcasting payment requests over picking them up via near field radio. On 02/05/2015 09:01 AM, Paul Puey wrote: Airbitz has developed and implemented a method for communicating a bitcoin URI across Bluetooth (BLE) or any other P2P, mid range, wireless, broadcast medium. The currently documented implementation is available in our iOS and Android mobile wallet (updated Android version with BLE coming in about 1 week). We would like to have the BIP pulled into Github for review and discussion. Here is the current BIP: BIP: TBD Title: P2P Wireless URI transfer Authors: Thomas Baker tom’at’airbitz.co http://airbitz.co, Paul Puey paul’at’airbitz.co http://airbitz.co Contributors: Joey Krug joeykrug’at’gmail.com http://gmail.com Status: proposal Type: Standards Track Created: 2015-01-12 Table of Contents * Abstract * Motivation * Specification * Compatibility * Examples * References Abstract This is a protocol for peer-to-peer wireless transfer of a URI request using an open broadcast or advertisement channel such as Bluetooth, Bluetooth Low Energy, or WiFi Direct. Motivation There are disadvantages for a merchant (requester) and customer (sender) to exchange a URI request using QR codes that can be eliminated by using wireless broadcast or advertisements. Current QR code scan method to transfer a request URI from merchant (Requester) to customer (Sender) is cumbersome. A usual scenario is a merchant with a POS terminal for order entry and a separate tablet for transacting payments with bitcoin, and a customer with a smartphone. After the order is entered, the merchant enters payment request information into the tablet, generates the QR code representing the URI, and presents this to the customer. The customer prepares to scan the QR code with their smartphone by maneuvering the camera to the tablet. The tablet screen must be relatively clean, point at the customer, and held steady. The smartphone camera lens must be clean, point at the tablet screen, come into range, and held steady to focus and wait for a QR scan. Environmental conditions such as bright outdoor sunlight, indoor spot lights, or significant distance between QR code and camera can create difficult and cumbersome experiences for users. Using a wireless local broadcast allows the merchant to just enter the payment and wait. The tablet and smartphone are not maneuvered to align in any way. The customer observes broadcast listings, selects the appropriate one from possible simultaneous broadcasts from other POS stations nearby, examines the URI request details such as amount, and decides whether to send funds, initiating a bitcoin network transfer. The merchant and customer then receive the transaction confirmations and are done with the sale. Merchant and customer devices are kept private and secured in their own possession. The URI and other broadcast identification (Joe’s Grill #1) only contain public information. However, a copycat broadcaster acting as MITM might duplicate the broadcast simultaneously as the merchant, attempting to lure the customer to send funds to the copycat. That attack is mitigated with this broadcast method because of the partial address in the broadcast. Specification Requester generates a bitcoin URI request of variable length, and a limited descriptive identifier string. Requester then broadcasts the URI’s partial public address (paddress) plus identifier (id) over a publicly visible wireless channel. Sender scans for broadcasts on their device, examines and selects the desired request by the identifier and partial address. This connects a data channel to Requester. Requester sends full URI back over the data channel. Sender device ensures paddress is part of the full URI public address and checks the full address integrity. Checking the broadcast and full URI integrity prevents a copycat device within range from copying the partial address and fooling the customer into sending funds to the copycat instead. Below is a description of the protocol through Bluetooth Smart (Low Energy). Requestor Sender - Bitcoin transaction roles Peripheral Central- Bluetooth GAP definitions Mode Mode 1
Re: [Bitcoin-development] Export format for xpub
On 02/03/2015 10:33 AM, Levin Keller wrote: Why not have more descriptive parameters? Saving on data? Yes. QR codes are very size sensitive. -- 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] Export format for xpub
On 02/03/2015 01:22 AM, Pavol Rusnak wrote: Hm, let me put the questions the other way around: What gap limit should a wallet use if it encounters h=bip32? It should follow the spec. I know BIP32-hierarchy is short on gap limits, which is why (amongst other reasons) I expect BIP32-hierarchy-based wallets migrate to a better standard at some time. What h value should I use for myTREZOR wallets? Which is essentially a BIP44 wallet that produces h=bip32 xpubs with gap limit 20 ... If it follows BIP32, h=bip32 is fine. -- 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] Export format for xpub
On 02/03/2015 11:10 AM, Pavol Rusnak wrote: Another option that might make sense is the block number. Not really IMHO. Keys can be used on multiple blockchains. -- 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] Export format for xpub
On 02/02/2015 03:47 PM, vv01f wrote: Uff, I would expect MMDD there so it's human readable as well. Those strings are not meant to be read by humans. MMDD is more complicated than necessary, given that Bitcoin deals with seconds since epoch everywhere. First that is a pitty .. as its simply a waste of storage. but back to Pavol's point: IMHO no harm to anything, as Bitcoin never has any valid timestamp below ~1230768000 (jan2009) and thus will always have 10 digits.. you can easily identify 8 char long timestamp as the proposed format. And there never is anything wrong with having a transparent, human readable option - especially when it saves 2 bytes in e.g. qr-codes. Pavol's suggestion saves 2 chars only because its just a date. I think the creation date should be at least precise to the hour, if not to the minute. But anyhow, if everyone prefers a human readble date format I will bow to the majority. -- 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] Export format for xpub
On 02/02/2015 03:56 PM, Pavol Rusnak wrote: To me it seems more important to describe how addresses should be discovered (i.e. to scan xpub/0/i and xpub/1/j chains using gap limit G) instead of how the xpub was created/obtained (bip32 vs bip44). What do you thing about changing ?h=bip32 to something like ?t=01g=20 - t=01 meaning that chains 0 and 1 should be scanned (feel free to change 01 into any other descriptive string) - g=20 meaning that gap 20 should be used I don't think that parameterizing will work, we can't predict future BIPs. It's the same as for BIP43, in the end we agreed on just putting the BIP number. -- 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] Export format for xpub
On 02/02/2015 12:33 PM, Mike Hearn wrote: I looked at what Andreas is doing a few days ago - basically it's just an xpub string with a ?a=bc=d query string added to the end, with a hierarchy type specifier and something else I forgot, encoded into a QR code. It's h=bip32 for the hierarchy used and c=123456 for the creation date of the wallet (in seconds since epoch). I pondered about if we should add a scheme (e.g. bitcoin-xpub:) but decided to start without. The only advantage I currently see would be it could be used on Android to dispatch intents to the right app(s). -- 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] Export format for xpub
On 02/02/2015 01:59 PM, Pavol Rusnak wrote: It's h=bip32 for the hierarchy used and Do I understand this correctly and h=bip32 hierarchy means that both xpub/0/i and xpub/1/j chains are scanned? (So it applies to BIP44 generated xpubs as well?) Yes, except that BIP32-hierarchy and BIP44 differ in some requirements (e.g. gap limit). c=123456 for the creation date of the wallet (in seconds since epoch). Uff, I would expect MMDD there so it's human readable as well. Those strings are not meant to be read by humans. MMDD is more complicated than necessary, given that Bitcoin deals with seconds since epoch everywhere. -- 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] BIP72 amendment proposal
I agree that this would be another way of achieving the same goal. I'd be fine with that if there is a majority. However, I also see downsides of this approach: 1. It's more complicated. It touches more BIPs, and although signing is terribly difficult its still more difficult than just hashing. E.g. signing the payment request twice (ECC + X.509) poses the question in which order you sign, and which signature fields to null for signing. 2. Isn't it discouraged to disclose the public key you're going to receive coins on? (not sure about that) 3. Unlike an hash we can just re-assign to different objects (see my proposal) I think we cannot easily do the same with a signature. It's probably not very important to have this option, but still it should be considered. 4. I'm afraid of the idea of re-purposing the BIP21 address. Someone might send money to it although it isn't meant to receive money any more (service is already using an advanced BIP70 usecase). A clear separation into two parameters would prevent such mistakes, and as soon as the address can go away the URL needn't be longer than it used to be. 5. A hash can be checked without knowing a secret. Are we excluding stateless devices (e.g. proxies, smartwatches)? Generally about the URL length discussion: Currently we have address, amount and r, and it works well. In future we would have h and r. So all we need to do is make sure h not longer than address+amount. I think this is already the case with untruncated SHA256 hashes. But I'd be fine with truncating to maybe 192 bits to save a few characters. On 09/12/2014 06:31 PM, Mike Hearn wrote: Putting aside the question of necessity for a moment, a more efficient approach to this would be; 1. Add another marker param like s to the end of the URL 2. Add another field to PaymentRequest that contains an ECC signature calculated using the public key that hashes to the address in the URI 3. Upgraded wallets look for the additional param and if it's there, expect to find the PaymentDetails signed with the address key. PKI signing of course is still useful to provide an actual identity for receipts, display on hardware wallets, dispute mediation etc. This adds only a few characters to a normal backwards-compatible QR code, and is not hard to implement. On Fri, Sep 12, 2014 at 5:37 PM, Mike Hearn m...@plan99.net mailto:m...@plan99.net wrote: That way we leave up to implementers to experiment with different lengths and figure out what the optimum is Ah, that's a good suggestion if we do go this way. -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP72 amendment proposal
On 09/12/2014 08:43 PM, Aaron Voisine wrote: Should BIP72 require that signed payment requests be from the same domain, Although it currently does not seem to be used that way, I'd like to see merchants sign their payment requests but store them on their payment processors server. Currently if you buy from Humble Bundle, all you see is Coinbase which is unfortunate. and also require https? I think that's unrealistic. HTTP is already in use, and also the proposed spec is open to other transports, e.g. Bluetooth which is also already in common use. -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP72 amendment proposal
On 09/12/2014 12:11 PM, Mark van Cuijk wrote: On 12 Sep 2014, at 11:55 , bitcoin-development-requ...@lists.sourceforge.net wrote: The hash is meant to link the trust anchor (e.g. the QR code) to the payment request message in a secure way. This will solve the problem several apps are comparing address+amount fields as a workaround instead, preventing some advanced BIP70 usecases. When these apps read a matching hash, they need not compare any of the other fields. Sounds like a good plan. Do you have a list (possibly incomplete) of apps that perform this kind of checking? We’re currently working with some parties in a supply chain to allow a consumer payment on a retail website to automatically pay supply chain parties, the way BIP70 allows with multiple outputs on a transaction. This behaviour would prohibit this use case. Hard to say, but here is my last assertion: - Bitcoin Wallet - Hive Bitcoin Wallet (checked by source) - countless ( 300) forks/clones of Bitcoin Wallet Since you're planning an advanced BIP70 usecase, you'll also have to deal with the many wallets that don't support BIP70 at all. -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP72 amendment proposal
On 09/12/2014 03:49 PM, Mike Hearn wrote: (1) Base64 of SHA256 seems overkill. 256 bits of hash is a lot. The risk here is that a MITM intercepts the payment request, which will be typically requested just seconds after the QR code is vended. 80 bits of entropy would still be a lot and take a long time to brute force, whilst keeping QR codes more compact, which impacts scannability. To put that into perspective, here is how a bitcoin: URI would look like: bitcoin:?h=J-J-4mra0VorfffEZm5J7mBmHGKX86Dpt-TnnmC_fhEr=http://wallet.schildbach.de/bip70/r1409992884.bitcoinpaymentrequest (obviously for real-world usage you would optimize the r parameter) I looked at the list in this doc to evaluate what's easily available: https://code.google.com/p/guava-libraries/wiki/HashingExplained I thought SHA1 has a bad reputation these days, and we don't save much by using it. I don't know anything about Murmur. MD5 is clearly broken. What hash function would you recommend? (2) This should *not* be necessary in the common HTTPS context. It is. People can't check names. People don't want to check names. People can't get certificates for lots of reasons. X.509 is centralized. X.509 has had serious security issues in the past. And shit continues to happen. To sum up, X.509 can't replace the trust anchor that is established by scanning a QR code or tapping two devices together. (3) This can be useful in the Bluetooth context, but then again, we could also do things a different way by signing with the key in the first part of the URI, thus avoiding the need for a hash. Sure. But signing is harder than just calculating a hash. -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] How to create a pull tester JAR
On 08/05/2014 05:11 PM, Mike Hearn wrote: Oh, I forgot to mention something important. Ridiculously, the default package repository Maven uses was not protected by SSL up until a few days ago. They made it available via SSL now, but you have to tell Maven about the new URL. I guess they'll do a new release where SSL is the default soon. FWIW, I filed a wishlist item here: https://jira.codehaus.org/browse/MNG-5672 and here, for the old Ubuntu versions of Maven: https://bugs.launchpad.net/ubuntu/+source/maven/+bug/1352418 -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin development (testing where to get Wallet code)
Are you aware of bitcoinj? http://bitcoinj.github.io/ It contains everything to plug together a basic SPV wallet and runs in the JVM. On 07/30/2014 09:38 AM, Caleb Roger Davis wrote: Yes, I was thinking something on the JVM, I have a big interest in Clojure right now (am a long time Java dev, since 1996). I do not know if I want to tackle writing bitcoin in Clojure, but I want to create a tool kit first to learn more about how it works. Caleb On Tue, Jul 29, 2014 at 5:12 PM, Felipe Micaroni Lalli micar...@walltime.info mailto:micar...@walltime.info wrote: May I ask you which language? I'd love to implement Bitcoin in Clojure or Scheme. Related: http://bitcoin.stackexchange.com/questions/5344/has-anyone-ported-the-bitcoin-software-to-pure-clojure Sincerely, Felipe Micaroni Lalli Walltime: https://walltime.info Bitcoin Paranoid Android developer PGP ID: 0x4c0afccfed5cde14 BTC: 1LipeR1AjHL6gwE7WQECW4a2H4tuqm768N On 29/07/2014, at 19:32, Caleb Roger Davis moab...@gmail.com mailto:moab...@gmail.com wrote: I have several Bitcoin contributions I would like to make, mostly for learning purposes to get started: • I would like to contribute to unit and/or other types of tests (code), not production code. • I would like to understand the Bitcoin code (as much as possible from top to bottom) • I would like to write a Bitcoin wallet in another language (so would like to know where to get the Bitcoin - Core Wallet code, but not sure where it resides. I am a seasoned software developer, but I do need direction on where to get started. If there is a wiki doc for new developers that would reduce my searching and experimentation that would be great. For each of the three items above, I would like to know the tools and frameworks I would need to understand and initially work on tests ( how to run the existing tests to get code coverage and find where coverage is needed, what is the preferred IDE and full development stack etc ), and also where to get started looking at the bitcoin core code and also the wallet code (where is the initial starting point and then I could trace from there ). Is there a separate area (github mailing list) for core wallet development? Sincerely, -- Caleb -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net mailto:Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Caleb M: 801.896.3278 https://plus.google.com/+CalebRogerDavis/about -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP 38 NFC normalisation issue
Here is a good article that helped me with what's going wrong: http://www.oracle.com/technetwork/articles/javase/supplementary-142654.html Basically, Java is stuck at 16 bits per char due to legacy reasons. They admit that for a new language, they would probably use 32 (or 24?) bits per char. \u literals express UTF-16 encoding, so you have to use 16 bits. I learned that for codepoint 0x010400, I could write \uD801\uDC00, which is the UTF-16 encoding of that codepoint. Other languages have literals for codepoints. E.g. Python can use u\U00010400 or HTML has #x10400; Unfortunately, Java is missing such a construct (at least in Java6). On 07/17/2014 12:59 PM, Mike Hearn wrote: Glad we got to the bottom of that. That's quite a nasty compiler/language bug I must say. Not even a warning. Still, python crashes when trying to print the name of a null character. It wouldn't surprise me if there are other weird issues lurking. Would definitely sleep better with a more restricted character set. On 17 Jul 2014 00:04, Andreas Schildbach andr...@schildbach.de mailto:andr...@schildbach.de wrote: Please excuse me. I had a more thorough look at the original problem and found that the only problem with the original test case was that you cannot specify codepoints from the SMP using \u in Java. I always tried \u010400 but that doesn't work. Here is a fix for bitcoinj. The test now passes. https://github.com/bitcoinj/bitcoinj/pull/143 We can (and probably should) still need to filter control chars, I'll have a look at that now again. On 07/16/2014 11:06 PM, Aaron Voisine wrote: If I first remove \u, so the non-normalized passphrase is \u03D2\u0301\U00010400\U0001F4A9, and then NFC normalize it, it becomes \u03D3\U00010400\U0001F4A9 UTF-8 encoded this is: 0xcf93f0909080f09f92a9 (not the same as what you got, Andreas!) Encoding private key: 5Jajm8eQ22H3pGWLEVCXyvND8dQZhiQhoLJNKjYXk9roUFTMSZ4 with this passphrase, I get a BIP38 key of: 6PRW5o9FMb4hAYRQPmgcvVDTyDtr6R17VMXGLmvKjKVpGkYhBJ4uYuR9wZ I recommend rather than simply removing control characters from the password that instead the spec require that passwords containing control characters are invalid. We don't want people trying to be clever and putting them in thinking they are adding to the password entropy. Also for UI compatibility across many platforms, I'm also in favor disallowing any character below U+0020 (space) I can submit a PR once we figure out why Andreas's passphrase was different than what I got. Aaron Voisine breadwallet.com http://breadwallet.com On Wed, Jul 16, 2014 at 4:04 AM, Andreas Schildbach andr...@schildbach.de mailto:andr...@schildbach.de wrote: Damn, I just realized that I implement only the decoding side of BIP38. So I cannot propose a complete test vector. Here is what I have: Passphrase: ϓ␀Ѐ (\u03D2\u0301\u\U00010400\U0001F4A9; GREEK UPSILON WITH HOOK, COMBINING ACUTE ACCENT, NULL, DESERET CAPITAL LETTER LONG I, PILE OF POO) Passphrase bytes after removing ISO control characters and NFC normalization: 0xcf933034303066346139 Bitcoin Address: 16ktGzmfrurhbhi6JGqsMWf7TyqK9HNAeF Unencrypted private key (WIF): 5Jajm8eQ22H3pGWLEVCXyvND8dQZhiQhoLJNKjYXk9roUFTMSZ4 Can someone calculate the encrypted key from it (using whatever implementation) and I will verify it decodes properly in bitcoinj? On 07/16/2014 12:46 PM, Andreas Schildbach wrote: I will change the bitcoinj implementation and propose a new test vector. On 07/16/2014 11:29 AM, Mike Hearn wrote: Yes sorry, you're right, the issue starts with the null code point. Python seems to have problems starting there too. It might work if we took that out. On Wed, Jul 16, 2014 at 11:17 AM, Andreas Schildbach andr...@schildbach.de mailto:andr...@schildbach.de mailto:andr...@schildbach.de mailto:andr...@schildbach.de wrote: Guys, you are always talking about the Unicode astral plane, but in fact its a plain old (ASCII) control character where this problem starts and likely ends: \u. Let's ban/filter ISO control characters and be done with it. Most control characters will never be enterable by any keyboard into a password field. Of course I assume that Character.isISOControl() works consistently across platforms. http://docs.oracle.com/javase/7/docs/api/java/lang/Character.html#isISOControl%28char%29 On 07/16/2014 12:23 AM, Aaron Voisine wrote
Re: [Bitcoin-development] BIP 38 NFC normalisation issue
Guys, you are always talking about the Unicode astral plane, but in fact its a plain old (ASCII) control character where this problem starts and likely ends: \u. Let's ban/filter ISO control characters and be done with it. Most control characters will never be enterable by any keyboard into a password field. Of course I assume that Character.isISOControl() works consistently across platforms. http://docs.oracle.com/javase/7/docs/api/java/lang/Character.html#isISOControl%28char%29 On 07/16/2014 12:23 AM, Aaron Voisine wrote: If the user creates a password on an iOS device with an astral character and then can't enter that password on a JVM wallet, that sucks. If JVMs really can't support unicode NFC then that's a strong case to limit the spec to the subset of unicode that all popular platforms can support, but it sounds like it might just be a JVM string library bug that could hopefully be reported and fixed. I get the same result as in the test case using apple's CFStringNormalize(passphrase, kCFStringNormalizationFormC); Aaron Voisine breadwallet.com On Tue, Jul 15, 2014 at 11:20 AM, Mike Hearn m...@plan99.net wrote: Yes, we know, Andreas' code is indeed doing normalisation. However it appears the output bytes end up being different. What I get back is: cf930001303430300166346139 vs cf9300f0909080f09f92a9 from the spec. I'm not sure why. It appears this is due to the character from the astral planes. Java is old and uses 16 bit characters internally - it wouldn't surprise me if there's some weirdness that means it doesn't/won't support this kind of thing. I recommend instead that any implementation that wishes to be compatible with JVM based wallets (I suspect Android is the same) just refuse any passphrase that includes characters outside the BMP. At least unless someone can find a fix. I somehow doubt this will really hurt anyone. -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP 38 NFC normalisation issue
I will change the bitcoinj implementation and propose a new test vector. On 07/16/2014 11:29 AM, Mike Hearn wrote: Yes sorry, you're right, the issue starts with the null code point. Python seems to have problems starting there too. It might work if we took that out. On Wed, Jul 16, 2014 at 11:17 AM, Andreas Schildbach andr...@schildbach.de mailto:andr...@schildbach.de wrote: Guys, you are always talking about the Unicode astral plane, but in fact its a plain old (ASCII) control character where this problem starts and likely ends: \u. Let's ban/filter ISO control characters and be done with it. Most control characters will never be enterable by any keyboard into a password field. Of course I assume that Character.isISOControl() works consistently across platforms. http://docs.oracle.com/javase/7/docs/api/java/lang/Character.html#isISOControl%28char%29 On 07/16/2014 12:23 AM, Aaron Voisine wrote: If the user creates a password on an iOS device with an astral character and then can't enter that password on a JVM wallet, that sucks. If JVMs really can't support unicode NFC then that's a strong case to limit the spec to the subset of unicode that all popular platforms can support, but it sounds like it might just be a JVM string library bug that could hopefully be reported and fixed. I get the same result as in the test case using apple's CFStringNormalize(passphrase, kCFStringNormalizationFormC); Aaron Voisine breadwallet.com http://breadwallet.com On Tue, Jul 15, 2014 at 11:20 AM, Mike Hearn m...@plan99.net mailto:m...@plan99.net wrote: Yes, we know, Andreas' code is indeed doing normalisation. However it appears the output bytes end up being different. What I get back is: cf930001303430300166346139 vs cf9300f0909080f09f92a9 from the spec. I'm not sure why. It appears this is due to the character from the astral planes. Java is old and uses 16 bit characters internally - it wouldn't surprise me if there's some weirdness that means it doesn't/won't support this kind of thing. I recommend instead that any implementation that wishes to be compatible with JVM based wallets (I suspect Android is the same) just refuse any passphrase that includes characters outside the BMP. At least unless someone can find a fix. I somehow doubt this will really hurt anyone. -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net mailto:Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net mailto:Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP 38 NFC normalisation issue
Damn, I just realized that I implement only the decoding side of BIP38. So I cannot propose a complete test vector. Here is what I have: Passphrase: ϓ␀Ѐ (\u03D2\u0301\u\U00010400\U0001F4A9; GREEK UPSILON WITH HOOK, COMBINING ACUTE ACCENT, NULL, DESERET CAPITAL LETTER LONG I, PILE OF POO) Passphrase bytes after removing ISO control characters and NFC normalization: 0xcf933034303066346139 Bitcoin Address: 16ktGzmfrurhbhi6JGqsMWf7TyqK9HNAeF Unencrypted private key (WIF): 5Jajm8eQ22H3pGWLEVCXyvND8dQZhiQhoLJNKjYXk9roUFTMSZ4 Can someone calculate the encrypted key from it (using whatever implementation) and I will verify it decodes properly in bitcoinj? On 07/16/2014 12:46 PM, Andreas Schildbach wrote: I will change the bitcoinj implementation and propose a new test vector. On 07/16/2014 11:29 AM, Mike Hearn wrote: Yes sorry, you're right, the issue starts with the null code point. Python seems to have problems starting there too. It might work if we took that out. On Wed, Jul 16, 2014 at 11:17 AM, Andreas Schildbach andr...@schildbach.de mailto:andr...@schildbach.de wrote: Guys, you are always talking about the Unicode astral plane, but in fact its a plain old (ASCII) control character where this problem starts and likely ends: \u. Let's ban/filter ISO control characters and be done with it. Most control characters will never be enterable by any keyboard into a password field. Of course I assume that Character.isISOControl() works consistently across platforms. http://docs.oracle.com/javase/7/docs/api/java/lang/Character.html#isISOControl%28char%29 On 07/16/2014 12:23 AM, Aaron Voisine wrote: If the user creates a password on an iOS device with an astral character and then can't enter that password on a JVM wallet, that sucks. If JVMs really can't support unicode NFC then that's a strong case to limit the spec to the subset of unicode that all popular platforms can support, but it sounds like it might just be a JVM string library bug that could hopefully be reported and fixed. I get the same result as in the test case using apple's CFStringNormalize(passphrase, kCFStringNormalizationFormC); Aaron Voisine breadwallet.com http://breadwallet.com On Tue, Jul 15, 2014 at 11:20 AM, Mike Hearn m...@plan99.net mailto:m...@plan99.net wrote: Yes, we know, Andreas' code is indeed doing normalisation. However it appears the output bytes end up being different. What I get back is: cf930001303430300166346139 vs cf9300f0909080f09f92a9 from the spec. I'm not sure why. It appears this is due to the character from the astral planes. Java is old and uses 16 bit characters internally - it wouldn't surprise me if there's some weirdness that means it doesn't/won't support this kind of thing. I recommend instead that any implementation that wishes to be compatible with JVM based wallets (I suspect Android is the same) just refuse any passphrase that includes characters outside the BMP. At least unless someone can find a fix. I somehow doubt this will really hurt anyone. -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net mailto:Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net
Re: [Bitcoin-development] BIP 38 NFC normalisation issue
Please excuse me. I had a more thorough look at the original problem and found that the only problem with the original test case was that you cannot specify codepoints from the SMP using \u in Java. I always tried \u010400 but that doesn't work. Here is a fix for bitcoinj. The test now passes. https://github.com/bitcoinj/bitcoinj/pull/143 We can (and probably should) still need to filter control chars, I'll have a look at that now again. On 07/16/2014 11:06 PM, Aaron Voisine wrote: If I first remove \u, so the non-normalized passphrase is \u03D2\u0301\U00010400\U0001F4A9, and then NFC normalize it, it becomes \u03D3\U00010400\U0001F4A9 UTF-8 encoded this is: 0xcf93f0909080f09f92a9 (not the same as what you got, Andreas!) Encoding private key: 5Jajm8eQ22H3pGWLEVCXyvND8dQZhiQhoLJNKjYXk9roUFTMSZ4 with this passphrase, I get a BIP38 key of: 6PRW5o9FMb4hAYRQPmgcvVDTyDtr6R17VMXGLmvKjKVpGkYhBJ4uYuR9wZ I recommend rather than simply removing control characters from the password that instead the spec require that passwords containing control characters are invalid. We don't want people trying to be clever and putting them in thinking they are adding to the password entropy. Also for UI compatibility across many platforms, I'm also in favor disallowing any character below U+0020 (space) I can submit a PR once we figure out why Andreas's passphrase was different than what I got. Aaron Voisine breadwallet.com On Wed, Jul 16, 2014 at 4:04 AM, Andreas Schildbach andr...@schildbach.de wrote: Damn, I just realized that I implement only the decoding side of BIP38. So I cannot propose a complete test vector. Here is what I have: Passphrase: ϓ␀Ѐ (\u03D2\u0301\u\U00010400\U0001F4A9; GREEK UPSILON WITH HOOK, COMBINING ACUTE ACCENT, NULL, DESERET CAPITAL LETTER LONG I, PILE OF POO) Passphrase bytes after removing ISO control characters and NFC normalization: 0xcf933034303066346139 Bitcoin Address: 16ktGzmfrurhbhi6JGqsMWf7TyqK9HNAeF Unencrypted private key (WIF): 5Jajm8eQ22H3pGWLEVCXyvND8dQZhiQhoLJNKjYXk9roUFTMSZ4 Can someone calculate the encrypted key from it (using whatever implementation) and I will verify it decodes properly in bitcoinj? On 07/16/2014 12:46 PM, Andreas Schildbach wrote: I will change the bitcoinj implementation and propose a new test vector. On 07/16/2014 11:29 AM, Mike Hearn wrote: Yes sorry, you're right, the issue starts with the null code point. Python seems to have problems starting there too. It might work if we took that out. On Wed, Jul 16, 2014 at 11:17 AM, Andreas Schildbach andr...@schildbach.de mailto:andr...@schildbach.de wrote: Guys, you are always talking about the Unicode astral plane, but in fact its a plain old (ASCII) control character where this problem starts and likely ends: \u. Let's ban/filter ISO control characters and be done with it. Most control characters will never be enterable by any keyboard into a password field. Of course I assume that Character.isISOControl() works consistently across platforms. http://docs.oracle.com/javase/7/docs/api/java/lang/Character.html#isISOControl%28char%29 On 07/16/2014 12:23 AM, Aaron Voisine wrote: If the user creates a password on an iOS device with an astral character and then can't enter that password on a JVM wallet, that sucks. If JVMs really can't support unicode NFC then that's a strong case to limit the spec to the subset of unicode that all popular platforms can support, but it sounds like it might just be a JVM string library bug that could hopefully be reported and fixed. I get the same result as in the test case using apple's CFStringNormalize(passphrase, kCFStringNormalizationFormC); Aaron Voisine breadwallet.com http://breadwallet.com On Tue, Jul 15, 2014 at 11:20 AM, Mike Hearn m...@plan99.net mailto:m...@plan99.net wrote: Yes, we know, Andreas' code is indeed doing normalisation. However it appears the output bytes end up being different. What I get back is: cf930001303430300166346139 vs cf9300f0909080f09f92a9 from the spec. I'm not sure why. It appears this is due to the character from the astral planes. Java is old and uses 16 bit characters internally - it wouldn't surprise me if there's some weirdness that means it doesn't/won't support this kind of thing. I recommend instead that any implementation that wishes to be compatible with JVM based wallets (I suspect Android is the same) just refuse any passphrase that includes characters outside the BMP. At least unless someone can find a fix. I somehow doubt this will really hurt anyone
Re: [Bitcoin-development] BIP 38 NFC normalisation issue
I think generally control-characters (such as \u) should be disallowed in passphrases. (Even the use of whitespaces is very questionable.) I'm ok with allowing pile-of-poo's. On mobile phones there is keyboards just containing emoticons -- why not allow those? Assuming NFC works of course. On 07/15/2014 03:07 PM, Eric Winer wrote: I don't know for sure if the test vector is correct NFC form. But for what it's worth, the Pile of Poo character is pretty easily accessible on the iPhone and Android keyboards, and in this string it's already in NFC form (f09f92a9 in the test result). I've certainly seen it in usernames around the internet, and wouldn't be surprised to see it in passphrases entered on smartphones, especially if the author of a BIP38-compatible app includes a (possibly ill-advised) suggestion to have your passphrase include special characters. I haven't seen the NULL character on any smartphone keyboards, though - I assume the iOS and Android developers had the foresight to know how much havoc that would wreak on systems assuming null-terminated strings. It seems unlikely that NULL would be in a real-world passphrase entered by a sane user. On Tue, Jul 15, 2014 at 8:03 AM, Mike Hearn m...@plan99.net mailto:m...@plan99.net wrote: [+cc aaron] We recently added an implementation of BIP 38 (password protected private keys) to bitcoinj. It came to my attention that the third test vector may be broken. It gives a hex version of what the NFC normalised version of the input string should be, but this does not match the results of the Java unicode normaliser, and in fact I can't even get Python to print the names of the characters past the embedded null. I'm curious where this normalised version came from. Given that pile of poo is not a character I think any sane user would put into a passphrase, I question the value of this test vector. NFC form is intended to collapse things like umlaut control characters onto their prior code point, but here we're feeding the algorithm what is basically garbage so I'm not totally surprised that different implementations appear to disagree on the outcome. Proposed action: we remove this test vector as it does not represent any real world usage of the spec, or if we desperately need to verify NFC normalisation I suggest using a different, more realistic test string, like Zürich, or something written in Thai. Test 3: * Passphrase ϓ␀Ѐ (\u03D2\u0301\u\U00010400\U0001F4A9; GREEK UPSILON WITH HOOK http://codepoints.net/U+03D2, COMBINING ACUTE ACCENT http://codepoints.net/U+0301, NULL http://codepoints.net/U+, DESERET CAPITAL LETTER LONG I http://codepoints.net/U+10400, PILE OF POO http://codepoints.net/U+1F4A9) * Encrypted key: 6PRW5o9FLp4gJDDVqJQKJFTpMvdsSGJxMYHtHaQBF3ooa8mwD69bapcDQn * Bitcoin Address: 16ktGzmfrurhbhi6JGqsMWf7TyqK9HNAeF * Unencrypted private key (WIF): 5Jajm8eQ22H3pGWLEVCXyvND8dQZhiQhoLJNKjYXk9roUFTMSZ4 * /Note:/ The non-standard UTF-8 characters in this passphrase should be NFC normalized to result in a passphrase of0xcf9300f0909080f09f92a9 before further processing -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net mailto:Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___
Re: [Bitcoin-development] BIP 38 NFC normalisation issue
Can you provide the rationale for standard practice? For example, why should whitespace be allowed? I regularly use trim() on any passphrase (or other input ftm). So what's the action point? Should we amend the spec to filter control characters? That would get rid of the \u problem. On 07/15/2014 05:17 PM, Jeff Garzik wrote: Unicode guarantees that null-terminated strings still work. U+ terminates a unicode (or C) string. strlen() gets the string byte count. mbstowcs() gets the character count. Whitespace can be problematic, but should be allowed. Control characters should be filtered. Emoticons probably cannot be filtered without substandard approaches such as character blacklists, a road you do not want to travel. (all this is simply standard practice) On Tue, Jul 15, 2014 at 9:07 AM, Eric Winer enwi...@gmail.com wrote: I don't know for sure if the test vector is correct NFC form. But for what it's worth, the Pile of Poo character is pretty easily accessible on the iPhone and Android keyboards, and in this string it's already in NFC form (f09f92a9 in the test result). I've certainly seen it in usernames around the internet, and wouldn't be surprised to see it in passphrases entered on smartphones, especially if the author of a BIP38-compatible app includes a (possibly ill-advised) suggestion to have your passphrase include special characters. I haven't seen the NULL character on any smartphone keyboards, though - I assume the iOS and Android developers had the foresight to know how much havoc that would wreak on systems assuming null-terminated strings. It seems unlikely that NULL would be in a real-world passphrase entered by a sane user. On Tue, Jul 15, 2014 at 8:03 AM, Mike Hearn m...@plan99.net wrote: [+cc aaron] We recently added an implementation of BIP 38 (password protected private keys) to bitcoinj. It came to my attention that the third test vector may be broken. It gives a hex version of what the NFC normalised version of the input string should be, but this does not match the results of the Java unicode normaliser, and in fact I can't even get Python to print the names of the characters past the embedded null. I'm curious where this normalised version came from. Given that pile of poo is not a character I think any sane user would put into a passphrase, I question the value of this test vector. NFC form is intended to collapse things like umlaut control characters onto their prior code point, but here we're feeding the algorithm what is basically garbage so I'm not totally surprised that different implementations appear to disagree on the outcome. Proposed action: we remove this test vector as it does not represent any real world usage of the spec, or if we desperately need to verify NFC normalisation I suggest using a different, more realistic test string, like Zürich, or something written in Thai. Test 3: Passphrase ϓ␀Ѐ (\u03D2\u0301\u\U00010400\U0001F4A9; GREEK UPSILON WITH HOOK, COMBINING ACUTE ACCENT, NULL, DESERET CAPITAL LETTER LONG I, PILE OF POO) Encrypted key: 6PRW5o9FLp4gJDDVqJQKJFTpMvdsSGJxMYHtHaQBF3ooa8mwD69bapcDQn Bitcoin Address: 16ktGzmfrurhbhi6JGqsMWf7TyqK9HNAeF Unencrypted private key (WIF): 5Jajm8eQ22H3pGWLEVCXyvND8dQZhiQhoLJNKjYXk9roUFTMSZ4 Note: The non-standard UTF-8 characters in this passphrase should be NFC normalized to result in a passphrase of0xcf9300f0909080f09f92a9 before further processing -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds
Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments
On 07/01/2014 10:18 AM, Mike Hearn wrote: However it's not ideal at the moment. Basically the main problem is that in the BIP72 there is no way to provide a fallback alternative URI for payment request fetch if client wallet supports BIP70 but doesn't not support fetching over bluetooth or bluetooth connection fails for any reason. I think the way to go here is using multiple r= parameters. So the idea here is that the recipient wallet both uploads to the internet and exposes the payment request over Bluetooth simultaneously, then let's the sending wallet pick whatever radio layer works best in its current conditions? Either that, or just use the other ones as a fallback. Currently, Bitcoin Wallet just falls back to BIP21 if fetching the PR via the r= URL fails. I think having multiple r= params is reasonable, but the Bluetooth support is not specced in any BIP anyway. And if it were to be, people would point out the lack of link-layer encryption. Its specced in code and implemented by several parties. I think its clear that link-layer encryption has to be an add-on to the current unencrypted connection, just like HTTPS is on top of HTTP. Anyway, that's unrelated to the question of how to provide fallback URLs. One more thought: We have a similar problem with the BIP70 payment URL. It doesn't allow for fallbacks either. I brought this issue up in the discussion phase of BIP70, but it was dismissed I think because of let's not get too complex for the first version. The fallback here is to send the transaction via the P2P network. (I think BIP70 via P2P radio will get used more often in future. I plan to look into Bluetooth 4 LE as soon as I have devices and wanted to try WIFI Direct again also. I hope we can skip BIP72 for both of those, but lets see.) -- 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] Payment Protocol for Face-to-face Payments
Does r[]= really need to be encoded as r%5B1%5D= ? In this case, I'd advocate for a simple array parameter name, like rs= (plural of r). Length really does matter for QR codes. I'm fine with either multiple r= params or exactly one r= plus zero to many r[]= params. Although I think it is a violation of the (current) spec to choke on more than one r= parameters, I admit that bitcoinj is currently implemented that way. (We could however fix this in a maintenance release.) However, r= should also allow all other protocols, exactly like any of the r[]= params. I don't think we should do a distinction here. Also because of backwards compatibility to the status quo. On 07/01/2014 03:03 PM, Alex Kotenko wrote: In my mind it's not like the client's phone is going all directions at the same time. There should be a priority method and fallback method(s). And I see p2p radio as priority, and web as fallback, and BIP21 in the end as always-working-default. So I'm keeping support for it all while want to be able to provide best user experience. Mike, a while ago in this thread you've described contactless cards user experience. I'm also using contactless cards often, and what I'm aiming at is creating same level of user experience for Bitcoin users. Encryption over bluetooth is a matter to worry about, and we will introduce that, but we need to sort out more low level problems first before coming into that stage. So, the backwards compatibility is a good issue Michael pointed out. While processing of multiple r parameters is indeed uncertain (since there is no RFC for that various implementations may behave differently), the array solution is somewhat better. The array parameter name is r%5B1%5D=, i.e. it's not r=, and we can add plain r= alongside. And if particular implementation understands the array construct - it will use it, otherwise it will ignore the r%5B1%5D= and use only usual r=. This doens't work though for cases where particular implementation understands array construct but doesn't work well with repeating parameters, since it will see two repeating r - an array and a string. I don't have a solution for that atm. If add completely new parameter to solve this we will need to make it an array straight away to address upcoming issues with accommodating other protocols. And then I would also modify existing BIP72 to strictly define r= as http(s) only parameter, while all other protocols (bluetooth, WiFi Direct, ultrasound, chirp etc) should go to the new array parameter. -- 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] Payment Protocol for Face-to-face Payments
Ok, one more idea: r= is used for the first URL, and we *think* of it as r0= additional URLs are appended as r1= r2= and so on. This would also define an ordering in case we need it. On 07/01/2014 05:07 PM, Michael Wozniak wrote: Multiple parameters is currently undefined as far as I can tell. Should the client take the first, last, or ignore it completely if there are multiple of any parameter? I think that’s the point of the parameter pollution discussion, which will define it one way or the other. I’m only familiar with the Electrum implementation, which is currently checking for any duplicate parameters and treating the entire URI as invalid if duplicate parameters exist (following the parameter pollution suggestions). - Michael Wozniak On Jul 1, 2014, at 10:59 AM, Andreas Schildbach andr...@schildbach.de wrote: Does r[]= really need to be encoded as r%5B1%5D= ? In this case, I'd advocate for a simple array parameter name, like rs= (plural of r). Length really does matter for QR codes. I'm fine with either multiple r= params or exactly one r= plus zero to many r[]= params. Although I think it is a violation of the (current) spec to choke on more than one r= parameters, I admit that bitcoinj is currently implemented that way. (We could however fix this in a maintenance release.) However, r= should also allow all other protocols, exactly like any of the r[]= params. I don't think we should do a distinction here. Also because of backwards compatibility to the status quo. On 07/01/2014 03:03 PM, Alex Kotenko wrote: In my mind it's not like the client's phone is going all directions at the same time. There should be a priority method and fallback method(s). And I see p2p radio as priority, and web as fallback, and BIP21 in the end as always-working-default. So I'm keeping support for it all while want to be able to provide best user experience. Mike, a while ago in this thread you've described contactless cards user experience. I'm also using contactless cards often, and what I'm aiming at is creating same level of user experience for Bitcoin users. Encryption over bluetooth is a matter to worry about, and we will introduce that, but we need to sort out more low level problems first before coming into that stage. So, the backwards compatibility is a good issue Michael pointed out. While processing of multiple r parameters is indeed uncertain (since there is no RFC for that various implementations may behave differently), the array solution is somewhat better. The array parameter name is r%5B1%5D=, i.e. it's not r=, and we can add plain r= alongside. And if particular implementation understands the array construct - it will use it, otherwise it will ignore the r%5B1%5D= and use only usual r=. This doens't work though for cases where particular implementation understands array construct but doesn't work well with repeating parameters, since it will see two repeating r - an array and a string. I don't have a solution for that atm. If add completely new parameter to solve this we will need to make it an array straight away to address upcoming issues with accommodating other protocols. And then I would also modify existing BIP72 to strictly define r= as http(s) only parameter, while all other protocols (bluetooth, WiFi Direct, ultrasound, chirp etc) should go to the new array parameter. -- 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 -- 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
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] instant confirmation via payment protocol backwards compatible proto buffer extension
Yes I meant only the supports_instant is not needed. trusted_instant_providers makes sense to me. Generally I like the simplicity of this BIP. Still, I have more questions: What is the use of the Transactions message? Note the Payment message already contains a transactions field that could be signed. Can you briefly describe the whole flow of messages on an example, including the BIP70 messages? Should we allow adding multiple signatures (from different instant providers or maybe while transitioning to another PKI)? On 06/15/2014 11:22 AM, Lawrence Nahum wrote: Andreas Schildbach andreas at schildbach.de writes: Just a quick comment: The supports_instant field seems redundant to me. First, as per your spec, you can derive it from trusted_instant_providers. And second, why do you need it at all? Protobuf is designed so it will simply ignore fields you don't know. So you can just send the instant_* fields in the Payment message without harm. Agreed, supports_instant is redundant and can/should/will go. trusted_instant_providers on the other hand I think is needed. Sometimes the providers will charge fees for instant. While the software can ignore the fields, users may not want to pay for instant when the merchant may not accept it or care (even if it would not break the protocol it would still be a waste of fees) Does it make sense? Not all transactions from GreenAddress provide double spend protection, there are additional checks on prevout that are normally not done when spending normally, etc -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension
Just a quick comment: The supports_instant field seems redundant to me. First, as per your spec, you can derive it from trusted_instant_providers. And second, why do you need it at all? Protobuf is designed so it will simply ignore fields you don't know. So you can just send the instant_* fields in the Payment message without harm. On 06/14/2014 02:00 PM, Lawrence Nahum wrote: Hello, I had the pleasure to meet some of you in Amsterdam and/or to speak on #bitcoin-dev but this is actually my first message to the mailing list - I feel a bit clumsy so apologies in advance if I make any mistake :) Quick introduction/background: my name is Lawrence Nahum and I'm the founder of GreenAddress, a BIP32 multisignature service and instant confirmation platform available in form of web socket APIs and Wallet for mobile, desktop and web. My background is in CS with distributed systems and I've worked most of my career in the City on OTC financial services like confirmation and clearing platforms. This post is to gather feedback, comments and reviews about a BIP70 payment protocol proto buffer extension proposal. https://github.com/greenaddress/bips/blob/bip-payment-request-instant-confirmations/bip-payment-request-instant-confirmations.mediawiki If you are interested in GreenAddress design or for more information on GreenAddress you can find the white paper here http://ghgreenaddress.files.wordpress.com/2014/04/greenaddressp2sh2of2hd-61.pdf and our homepage on https://greenaddress.it Cheers, Lawrence -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] testnet-seed.bitcoin.petertodd.org is up again
You're very quick to point at others. Especially since they run software that had the time to mature for about 30 years, and the protocol didn't really change since then... The last time it didn't work, the bug -- non RFC-conformance -- was on the bitcoin seeders side. ISPs do weird things with DNS, but usually they stay within the RFC. Anyway, without logs we don't have a chance to debug this issue. Any chance you could add simple logging to the seeder? DNS via HTTP? Never heard of that, at least it sounds weird as well. On 05/26/2014 06:37 PM, Peter Todd wrote: On Sun, May 25, 2014 at 09:12:10PM +0200, Andreas Schildbach wrote: Thanks for looking at the issue. Unfortunately, it still fails for me: $ nslookup testnet-seed.bitcoin.petertodd.org Server: 127.0.1.1 Address: 127.0.1.1#53 ** server can't find testnet-seed.bitcoin.petertodd.org: SERVFAIL Like I said, can you look at the logfiles how the requests arrive? There are no logfiles for DNS requests. I just checked on EC2 and my cellphone internet connection here in Tel Aviv; both work fine. My best guess is that your DNS resolver locally or at your ISP is unable to deal with the fact that the second DNS seed serving the domain testnet-seed.bitcoin.petertodd.org happens to be down right now. Note that some ISP's appear to both run buggy DNS servers, and redirect traffic meant to go to Google's 8.8.8 and 8.8.4.4 DNS servers to their own servers. I'd suggest that someone setup an alternate HTTP(S) based DNS seed for protocol redundency. What particular thing did you fix? It would be good to know for future outages. Dunno exactly. It appeared to be running fine when I logged into the machine, but for whatever reason DNS requests just weren't getting resolved. Restarted and it was ok again. -- The best possible search technologies are now affordable for all companies. Download your FREE open source Enterprise Search Engine today! Our experts will assist you in its installation for $59/mo, no commitment. Test it for FREE on our Cloud platform anytime! http://pubads.g.doubleclick.net/gampad/clk?id=145328191iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- The best possible search technologies are now affordable for all companies. Download your FREE open source Enterprise Search Engine today! Our experts will assist you in its installation for $59/mo, no commitment. Test it for FREE on our Cloud platform anytime! http://pubads.g.doubleclick.net/gampad/clk?id=145328191iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] testnet-seed.bitcoin.petertodd.org is up again
On 05/27/2014 12:39 AM, Peter Todd wrote: On 27 May 2014 01:12:05 GMT+03:00, Andreas Schildbach andr...@schildbach.de wrote: You're very quick to point at others. Especially since they run software that had the time to mature for about 30 years, and the protocol didn't really change since then... The last time it didn't work, the bug -- non RFC-conformance -- was on the bitcoin seeders side. ISPs do weird things with DNS, but usually they stay within the RFC. Anyway, without logs we don't have a chance to debug this issue. Any chance you could add simple logging to the seeder? DNS via HTTP? Never heard of that, at least it sounds weird as well. Hey, really sorry I don't have the time to fix this issue, been travelling for a few weeks for my consulting job. If you want to step up and volunteer please feel free. I'm already volunteering. At least I don't get paid for my efforts in debugging the seed infrastructure. Can you verify if your copy of the seeder contains the commit 8dcc006e6256cb746c2b025daf3df41baa26353e ? It fixed a bug that has exactly the symptoms we currently see. I wonder if the restart of your server actually changed/fixed anything. If you got a SERVFAIL this may be because you were traveling through parts of the world that can't reach your server. Did you actually try at home, before the restart? -- The best possible search technologies are now affordable for all companies. Download your FREE open source Enterprise Search Engine today! Our experts will assist you in its installation for $59/mo, no commitment. Test it for FREE on our Cloud platform anytime! http://pubads.g.doubleclick.net/gampad/clk?id=145328191iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] testnet-seed.bitcoin.petertodd.org is up again
Thanks for looking at the issue. Unfortunately, it still fails for me: $ nslookup testnet-seed.bitcoin.petertodd.org Server: 127.0.1.1 Address:127.0.1.1#53 ** server can't find testnet-seed.bitcoin.petertodd.org: SERVFAIL Like I said, can you look at the logfiles how the requests arrive? What particular thing did you fix? It would be good to know for future outages. On 05/24/2014 12:17 AM, Peter Todd wrote: FWIW That said, keep in mind the github discussion(1) that was had: if all the DNS seeds being down breaks your application, your application is broken and insecure. The only exception is initial startup, and even then you should have fallbacks such as hardcoded node lists and manual peer entry. If for some reason you really do need instant startup, run your own centralized high-availability/low-latency nodes; either way you're depending on a centralized resource. 1) https://github.com/bitcoin/bitcoin/pull/4203 -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] DNS seeds unstable
Great, thanks for this contribution! Do you plan to have your seeds reachable on port 53 eventually? Currently bitcoinj cannot deal with nonstandard ports I think. On 05/21/2014 11:23 AM, Alex Kotenko wrote: okay, I've set it up with bind forwarding requests to two dnsseeds running on separate ports. Though I see a problem with testnet DNS seed itself. It runs, but somehow it only returns one IP address. Exactly same DNS seeder looking for mainnet nodes is working fine. You can reach seeds through mainnet seed: dig @node.alexykot.me http://node.alexykot.me bitcoin-seed.alexykot.me http://bitcoin-seed.alexykot.me A or directly dig -p 8353 @node.alexykot.me http://node.alexykot.me bitcoin-seed.alexykot.me http://bitcoin-seed.alexykot.me A testnet seed dig @node.alexykot.me http://node.alexykot.me testnet-seed.alexykot.me http://testnet-seed.alexykot.me A or directly dig -p 18353 @node.alexykot.me http://node.alexykot.me testnet-seed.alexykot.me http://testnet-seed.alexykot.me A So what can be the problem with testnet DNS seeder? Best regards, Alex Kotenko 2014-05-20 1:50 GMT+01:00 Robert McKay rob...@mckay.com mailto:rob...@mckay.com: On Tue, 20 May 2014 01:44:29 +0100, Robert McKay wrote: On Mon, 19 May 2014 19:49:52 -0400, Jeff Garzik wrote: On Mon, May 19, 2014 at 4:36 PM, Robert McKay rob...@mckay.com mailto:rob...@mckay.com wrote: It should be possible to configure bind as a DNS forwarder.. this can be done in a zone context.. then you can forward the different zones to different dnsseed daemons running on different non-public IPs or two different ports on the same IP (or on one single non-public IP since there's really no reason to expose the dnsseed directly daemon at all). Quite the opposite. dnsseed data rotates through a lot of addresses if available. Using the bind/zone-xfer system would result in fewer total addresses going through to the clients, thanks to the addition of caching levels that the bind/zone-xfer system brings. That said, if the choice is between no-service and bind, bind it is ;p Setting it up as a zone forwarder causes each request to go through to the dnsseed backend for each request. This stackoverflow describes a similar situation; http://stackoverflow.com/questions/15338232/how-to-forward-a-subzone you can additionally specify the port to forward too; http://www.zytrax.com/books/dns/ch7/queries.html#forwarders it should be possible to forward to different ports on 127.0.0.1 for each dnsseed instance. Rob -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net mailto:Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] DNS seeds unstable
Hmmm, not for me: $ nslookup bitcoin-seed.alexykot.me Server: 127.0.1.1 Address:127.0.1.1#53 ** server can't find bitcoin-seed.alexykot.me: SERVFAIL $ nslookup testnet-seed.alexykot.me Server: 127.0.1.1 Address:127.0.1.1#53 ** server can't find testnet-seed.alexykot.me: SERVFAIL Can you look up in the logfile what requests I just made? On 05/21/2014 01:10 PM, Alex Kotenko wrote: Misunderstanding. Both seeds are available on port 53 via BIND forwarding. Just also each DNS seed is available separately on it's own port. Best regards, Alex Kotenko 2014-05-21 12:03 GMT+01:00 Andreas Schildbach andr...@schildbach.de mailto:andr...@schildbach.de: Great, thanks for this contribution! Do you plan to have your seeds reachable on port 53 eventually? Currently bitcoinj cannot deal with nonstandard ports I think. On 05/21/2014 11:23 AM, Alex Kotenko wrote: okay, I've set it up with bind forwarding requests to two dnsseeds running on separate ports. Though I see a problem with testnet DNS seed itself. It runs, but somehow it only returns one IP address. Exactly same DNS seeder looking for mainnet nodes is working fine. You can reach seeds through mainnet seed: dig @node.alexykot.me http://node.alexykot.me http://node.alexykot.me bitcoin-seed.alexykot.me http://bitcoin-seed.alexykot.me http://bitcoin-seed.alexykot.me A or directly dig -p 8353 @node.alexykot.me http://node.alexykot.me http://node.alexykot.me bitcoin-seed.alexykot.me http://bitcoin-seed.alexykot.me http://bitcoin-seed.alexykot.me A testnet seed dig @node.alexykot.me http://node.alexykot.me http://node.alexykot.me testnet-seed.alexykot.me http://testnet-seed.alexykot.me http://testnet-seed.alexykot.me A or directly dig -p 18353 @node.alexykot.me http://node.alexykot.me http://node.alexykot.me testnet-seed.alexykot.me http://testnet-seed.alexykot.me http://testnet-seed.alexykot.me A So what can be the problem with testnet DNS seeder? Best regards, Alex Kotenko 2014-05-20 1:50 GMT+01:00 Robert McKay rob...@mckay.com mailto:rob...@mckay.com mailto:rob...@mckay.com mailto:rob...@mckay.com: On Tue, 20 May 2014 01:44:29 +0100, Robert McKay wrote: On Mon, 19 May 2014 19:49:52 -0400, Jeff Garzik wrote: On Mon, May 19, 2014 at 4:36 PM, Robert McKay rob...@mckay.com mailto:rob...@mckay.com mailto:rob...@mckay.com mailto:rob...@mckay.com wrote: It should be possible to configure bind as a DNS forwarder.. this can be done in a zone context.. then you can forward the different zones to different dnsseed daemons running on different non-public IPs or two different ports on the same IP (or on one single non-public IP since there's really no reason to expose the dnsseed directly daemon at all). Quite the opposite. dnsseed data rotates through a lot of addresses if available. Using the bind/zone-xfer system would result in fewer total addresses going through to the clients, thanks to the addition of caching levels that the bind/zone-xfer system brings. That said, if the choice is between no-service and bind, bind it is ;p Setting it up as a zone forwarder causes each request to go through to the dnsseed backend for each request. This stackoverflow describes a similar situation; http://stackoverflow.com/questions/15338232/how-to-forward-a-subzone you can additionally specify the port to forward too; http://www.zytrax.com/books/dns/ch7/queries.html#forwarders it should be possible to forward to different ports on 127.0.0.1 for each dnsseed instance. Rob -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net mailto:Bitcoin-development@lists.sourceforge.net mailto:Bitcoin-development@lists.sourceforge.net mailto:Bitcoin
Re: [Bitcoin-development] Paper Currency
One problem we couldn't figure out here though - how to protect the notes from unauthorized redeem. Like if someone else tries to reach your wallet with his own NFC - how can we distinguish between deliberate redeem by owner and fraudulent redeem by anybody else with custom built long range NFC antenna? Any ideas? I think you'd need multiple factors to protect against that attack. Like encrypting with a key that is printed on the note as an QR code. -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Paper Currency
Jerry, some feedback on generating space-efficient QR codes. QR codes have 4 possible encodings, see Storage: http://en.wikipedia.org/wiki/QR_code The encoding you're proposing in BIP81 switches you to binary mode without actually using all the bits. So you'll end up with bloaty QR codes. One fix would be of course use all the available bits. However, binary QR codes cannot be used to auto-dispatch to apps on Android. If you want a wallet app to automatically open upon scan, you need to encode your data as an URI. That pretty much locks you into using alphanumeric mode QR codes. I've implemented that in Bitcoin Wallet for efficiently encoding transactions and BIP70 payment requests into QR codes. Since the allowed alphabet is 43 chars, I've named the encoding Base43 (it uses the same algorithm as Base58 or Base64). Tell me if you're interested in the details. On 05/17/2014 05:31 PM, Jerry Felix wrote: It seems to me that there's a huge need for a paper currency that is counterfeit-resistant, inexpensive to print, internationally recognized (border-less), fits in a wallet, and machine readable. I pitched this idea at the Cincinnati Bitcoin meetup last week, and I didn't get thrown out, so I took the time to document a proposed standard to accomplish this. I've put my ideas into BIP format, so that you can see what I have in mind, although I picked some BIP numbers myself that seem to be available. Call them proposed proposals, or provisional BIPs. I've numbered them provisionally BIP-80 to BIP-84. If you guys think that this idea has some merit, let's discuss. https://github.com/jerfelix/provisional_bips/blob/master/README.mediawiki Submitted with humility and some fear of getting laughed out of here... - Jerry -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] DNS seeds unstable
I think the best way to contribute to the infrastructure is actually what we're doing: Test the current infrastructure and point out where it is not working. Trying to find solutions for problems. There is nothing gained by throwing additional hardware at a problem if the problem itself isn't understood well. On 05/17/2014 02:58 AM, Alex Kotenko wrote: Ok, what do I need to do? How do I host a testnet seed myself? Best regards, Alex Kotenko 2014-05-16 23:02 GMT+01:00 Jeff Garzik jgar...@bitpay.com mailto:jgar...@bitpay.com: There are only two testnet seeds listed in bitcoind, and one of them returns SERVFAIL (testnet-seed.bitcoin.petertodd.org http://testnet-seed.bitcoin.petertodd.org) and the other just returns one A record (testnet-seed.bluematt.me http://testnet-seed.bluematt.me). No idea what seeds bitcoinj uses. If you are going to depend on testnet, especially for an important demo... contribute to the infrastructure! This stuff doesn't just fix itself for free. -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] DNS seeds unstable
On 05/17/2014 02:02 PM, Alex Kotenko wrote: So, my understanding is that atm we have no working DNS seeds at the testnet3, right? There are two DNS seeds known, of which one is unreachable atm, and another one is giving just one IP address, which is also a dead node. Yes, that's my understanding too. If I'll start a DNS seed of my own and make sure it works well, will this help? Yes, definately. I've found this DNS seeder daemon https://github.com/sipa/bitcoin-seeder, and it seems to be exactly what I need to run a DNS seeder myself. Afaik this is what most of the other seeds are using, yes. So if my understanding is correct, I'll setup a DNS seeds for mainnet and for testnet at bitcoin-seed.alexykot.me http://bitcoin-seed.alexykot.me and testnet-seed.alexykot.me http://testnet-seed.alexykot.me, and also a well connected nodes for mainnet and testnet on the same server. Is this a good plan? Will this all help? Sound great! Let me know if you've got something to test. -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] DNS seeds unstable
On 05/15/2014 07:48 PM, Gregory Maxwell wrote: On Thu, May 15, 2014 at 4:50 AM, Andreas Schildbach andr...@schildbach.de wrote: I'm bringing this issue up again. The current Bitcoin DNS seed infrastructure is unstable. I assume this is because of we're using a custom DNS implementation which is not 100% compatible. There have been bugs in the past, like a case sensitive match for the domain name. If software is using the DNS seeds in a way where one or two being unavailable is problematic, then the software may be using them poorly. Generally DNS seeds should only be used as fast connectivity hints, primarily for initial connectivity. Relying on them exclusively increases isolation vulnerabilities (e.g. because the dns seed operators or any ISP or network attacker on the path between you and the seeds can replace the results with ones that isolate you on a bogus network). I just used nslookup, after seeing the issues in bitcoinj. I agree that clients should be robust regarding DNS lookups (and bitcoinj isn't), but still I think the first step needs to be maintaining a quality infrastructure. -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] DNS seeds unstable
Apparently British Telecom also cannot speak to Peter Todd's server. That another very large ISP in Europe. On 05/15/2014 01:50 PM, Andreas Schildbach wrote: I'm bringing this issue up again. The current Bitcoin DNS seed infrastructure is unstable. I assume this is because of we're using a custom DNS implementation which is not 100% compatible. There have been bugs in the past, like a case sensitive match for the domain name. Current state (seeds taken from bitcoinj): mainnet: seed.bitcoin.sipa.be OK dnsseed.bluematt.me OK dnsseed.bitcoin.dashjr.orgSERVFAIL, tried multiple ISPs seed.bitcoinstats.com OK testnet: testnet-seed.bitcoin.petertodd.orgSERVFAIL, just from Telefonica testnet-seed.bluematt.me OK (but only returns one node) Note: Telefonica is one of Europe's largest ISPs. I would try to improve DNS myself, but I'm not capable of writing C. My fix would be to reimplement everything in Java -- I doubt you guys would be happy with that. -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] DNS seeds unstable
For example just now: $ nslookup testnet-seed.bluematt.me Server: 127.0.1.1 Address:127.0.1.1#53 Non-authoritative answer: testnet-seed.bluematt.mecanonical name = bitcoin-seednode.bluematt.me. bitcoin-seednode.bluematt.mecanonical name = desktopv2.bluematt.me. Name: desktopv2.bluematt.me Address: 152.23.202.18 And that address doesn't connect on port 18333. On 05/16/2014 08:53 PM, Matt Corallo wrote: This is very strange...when did you run this test and can anyone else reproduce this? Matt On 05/15/14 11:50, Andreas Schildbach wrote: testnet-seed.bluematt.me OK (but only returns one node) -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] DNS seeds unstable
I'm bringing this issue up again. The current Bitcoin DNS seed infrastructure is unstable. I assume this is because of we're using a custom DNS implementation which is not 100% compatible. There have been bugs in the past, like a case sensitive match for the domain name. Current state (seeds taken from bitcoinj): mainnet: seed.bitcoin.sipa.beOK dnsseed.bluematt.me OK dnsseed.bitcoin.dashjr.org SERVFAIL, tried multiple ISPs seed.bitcoinstats.com OK testnet: testnet-seed.bitcoin.petertodd.org SERVFAIL, just from Telefonica testnet-seed.bluematt.meOK (but only returns one node) Note: Telefonica is one of Europe's largest ISPs. I would try to improve DNS myself, but I'm not capable of writing C. My fix would be to reimplement everything in Java -- I doubt you guys would be happy with that. -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] BIP32 wallet structure in use? Remove it?
Does anyone use or plan to use the wallet structure part of the BIP32 document? I suggest removing it from the document and maybe instead point at BIP43. That new specification proposal just defines a purpose and leaves everything else to the inventor of that purpose. The idea it that over time a standard will evolve naturally rather than top-down. https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki I'd volunteer to submit a pull request if I can see some level of consent here. -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New BIP32 structure
On 04/08/2014 05:46 PM, slush wrote: I understand each client will implement things a little bit different, for example the current plan is bitcoinj will hold all keys in memory and start reusing keys on low resources. Electrum uses a chain for their private purpose. Etc. It still doesn't mean that bitcoinj or Electrum cannot share the bare minimum of BIP XX. Of course if somebody will use Electrum for 2to3 transactions and then move wallet to client which does not offer such feature, it won't work. But I don't see that as a problem. There is no bare minimum. Either you implement the BIP fully or not. There is no inbetween. Likewise, the standard cannot be extended unless you create a new standard that is based on the old (without re-using the path, of course). We're lightyears away from a BIP. Lets first create implementations and see if they are compatible in all possible combinations and situations. The moment any two apps have a different view on their wallets generated from the same seed, they're incompatible. In this case they should either fix the issue or intentionally choose incompatible paths, so that they don't see and spend subsets of each other. -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Why are we bleeding nodes?
They're _not_ phasing out into SPV wallets from what I can say. At around the 24th of February, there has been a sharp change of the current installs graph of Bitcoin Wallet. That number used to grow at about 20.000 per month. After that date until now, it just barely moves horizontal. My guess is that a large number of users have lost interest after they lost their money in MtGox. The 24th of February coincides with the final shutdown, according to http://en.wikipedia.org/wiki/Mt._Gox#February_2014_shutdown_and_bankruptcy On 04/07/2014 02:17 PM, Ricardo Filipe wrote: phasing out of bitcoinqt into spv wallets? 2014-04-07 12:34 GMT+01:00 Mike Hearn m...@plan99.net: At the start of February we had 10,000 bitcoin nodes. Now we have 8,500 and still falling: http://getaddr.bitnodes.io/dashboard/chart/?days=60 I know all the reasons why people might stop running a node (uses too much disk space, bandwidth, lost interest etc). But does anyone have any idea how we might get more insight into what's really going on? It'd be convenient if the subVer contained the operating system, as then we could tell if the bleed was mostly from desktops/laptops (Windows/Mac), which would be expected, or from virtual servers (Linux), which would be more concerning. When you set up a Tor node, you can add your email address to the config file and the Tor project sends you emails from time to time about things you should know about. If we did the same, we could have a little exit survey: if your node disappears for long enough, we could email the operator and ask why they stopped. -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees_APR ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees_APR -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees_APR ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP 70 refund field
I'd prefer 3 months to 2 just because a quarter of year is a more common timespan. But of course its just paint shedding, so 2 sounds good for me too (-: On 03/29/2014 02:29 PM, Mike Hearn wrote: So how about we say two months? That way it's easy for merchants to comply with the EU DSD and we keep RAM usage in check until we come up with a more sophisticated refund scheme. There's another issue with BIP 70 and refunds that I noticed. The PaymentRequest doesn't specify whether refunds are possible. So wallets have to either never submit refund data, or always submit it even if it makes no sense. Because setting things up to get refunds has a non-zero cost for the sender, it'd help if we could optimise it away for merchants that simply refuse to issue refunds for whatever reason. On Sat, Mar 29, 2014 at 10:27 AM, Roy Badami r...@gnomon.org.uk mailto:r...@gnomon.org.uk wrote: On Fri, Mar 28, 2014 at 09:56:57PM +0100, Andreas Schildbach wrote: On 03/28/2014 07:19 PM, Mike Hearn wrote: Ok, why don't fix this in the spec for now, by defining a fixed expiry time. In the EU, most products are covered by a 2 years warranty, so it seems appropriate to pick 2.5 years (30 months) -- allowing for some time to ship the product back and forth. Yeah I was thinking something like that on the walk home. But 2 years is a long time. Do we have enough RAM for that? It depends on usage stats, script size, etc... Plus warranties usually result in the defective goods being replaced rather than a monetary refund, right? Usually yes. The next smaller unit of time in Germany would be two weeks, the so-called Fernabsatzgesetz. It allows you to send back mail-orders and usually you want the money back. Don't know if that made it into EU law or how it applies to other countries. It's EU law, but the Distance Selling Directive only says at least seven days, so the exact period probably varies by country (in the UK it is 7 days). But the clock only starts ticking when you receive the goods, and the Distance Selling Directive allows the supplier 30 days to execute the order (I *think* the 30 days always has to include shipping, because for consumer contracts title doesn't pass until the goods are delivered, so the order wouldn't be considered complete until then). So I think latest possible deadline for returning the goods for refund could be up to 30 days to execute the order plus at least 7 days (with some countries allowing more). Plus, conceivably, shipping time, if some member states have chosen to interpret the 30 day execution differently. So I think this adds up to a couple of months, give or take. In practice, though, even a couple of months is a bit on the short time. What if the goods are delayed. How many people have had miner orders outstanding for the best part of a year? roy -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net mailto:Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP 70 refund field
I see the problem. However, I don't see how PaymentDetails can be an answer. None of the fields (other than outputs and network) can be known in advance (at the time of the initial payment). You're probably aiming for an expires field? How would you refund a payment after expiry? Note its not your choice wether to refund a payment -- it can be ordered by a court years after the payment happened. Btw. another problem is that the refund address is currently unprotected. On 03/28/2014 12:07 PM, Mike Hearn wrote: Modern devices like smartphones and tablets do not have swap files. This design is chosen to ensure responsive, fluid UI that can avoid blocking on disk regardless of how much multi-tasking is done, but it creates ripples that impact everything else. One implication of this is that on these devices, we cannot store all keys or transactions in memory forever. BIP 70 has an expiry field for PaymentRequests that we can use to allow us to eventually stop loading those keys into RAM - at that point payments to those keys would no longer be recognised. But there's no equivalent for refund addresses. More generally, though we re-used the output structure to define the refund, we didn't (for some reason that I forgot) reuse PaymentDetails, even though the payment details for a refund are indeed PaymentDetails. Though I am loathe to go back and redesign this part of BIP 70 so soon after we shipped v1, it seems to me like the refund feature may be hard to implement on phones if there's no time limit for when you can receive a refund. Otherwise a wallet has to be looking out for refunds for payments you may have made years ago. So perhaps we should add a new refund field that embeds a PaymentDetails structure instead of being just a list of outputs. We could try and solve this problem some other way purely internally, by doing a kind of wallet-specific swapping process in which things like Bloom filters are calculated without all keys in them being held in memory at once (perhaps caching filters for old parts of the key chain on disk), so you can have infinite wallets, but eventually the huge Bloom filters that would result would hurt efficiency in other ways. So key expiry seems pretty fundamental to scalability. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP 70 refund field
Ok, why don't fix this in the spec for now, by defining a fixed expiry time. In the EU, most products are covered by a 2 years warranty, so it seems appropriate to pick 2.5 years (30 months) -- allowing for some time to ship the product back and forth. On 03/28/2014 12:31 PM, Mike Hearn wrote: On Fri, Mar 28, 2014 at 12:25 PM, Andreas Schildbach andr...@schildbach.de mailto:andr...@schildbach.de wrote: However, I don't see how PaymentDetails can be an answer. None of the fields (other than outputs and network) can be known in advance (at the time of the initial payment). You don't need all the fields indeed, but they're mostly optional (except time). So for the refund you'd fill out: outputs (same as today) time expiry_time You're probably aiming for an expires field? How would you refund a payment after expiry? It'd have to be ad-hoc at that point. OK, you don't get the nice UI that the refund field provides. Oh well. It should be rare to get refunds very very late after the purchase. Btw. another problem is that the refund address is currently unprotected. Yes indeed as is the rest of the Payment structure. We talked about signing it with one of the keys that's signing the Bitcoin transaction as well. But it seems like a bit overkill. Usually it'll be submitted over HTTPS or a (secured!) Bluetooth channel though so tampering with it should not be possible. However this does raise the question of whether a refund should be a full blown PaymentRequest with optional PKI signing. Normally, I think, a seller does not know or care about the identity of a buyer for refunds, outside of their own tracking system. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP 70 refund field
On 03/28/2014 07:19 PM, Mike Hearn wrote: Ok, why don't fix this in the spec for now, by defining a fixed expiry time. In the EU, most products are covered by a 2 years warranty, so it seems appropriate to pick 2.5 years (30 months) -- allowing for some time to ship the product back and forth. Yeah I was thinking something like that on the walk home. But 2 years is a long time. Do we have enough RAM for that? It depends on usage stats, script size, etc... Plus warranties usually result in the defective goods being replaced rather than a monetary refund, right? Usually yes. The next smaller unit of time in Germany would be two weeks, the so-called Fernabsatzgesetz. It allows you to send back mail-orders and usually you want the money back. Don't know if that made it into EU law or how it applies to other countries. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments
But these cases are the norm, rather than the exception. Of all these places I spend my money at during the day I hardly ever know their official name. I'm thinking in terms of bakery, indian restaurant or snack vending machine. In Germany usually businesses are named like the people that run it. That usually just one or two random family names plus the legal form of the company. On 03/26/2014 11:56 PM, Mike Hearn wrote: Yeah, for those cases we'd need to think of something else. That gets into the realm of creating our own infrastructure though ... -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New BIP32 structure
Thanks for starting the discussion on finding a better structure. For me, the most important thing is either we're 100% interoperable or 0%. There should not be anything inbetween, as users will delete seeds without knowing there is still money in them on another implementation. I heard from multiple sources that using this standard some wallets will only see a subset of the addresses/keys of some other wallets. Implementation differences can always happen (and should addresses as bugs), but I think its unacceptable that this source of issues is by design. I suggest we agree on an even simpler least common denominator and wallets that want to implement some feature on top of that can do but are encouraged to pick a totally different cointype. I guess that would mean removing reserved and account. I'm still thinking it might be a good idea to have a separate chain for refunds. Refunds will be rarely used and thus need a much slower moving window than receiving addresses or change. On 03/26/2014 09:49 PM, Mike Hearn wrote: Myself, Thomas V (Electrum) and Marek (Trezor) got together to make sure our BIP32 wallet structures would be compatible - and I discovered that only I was planning to use the default structure. Because I'm hopeful that we can get a lot of interoperability between wallets with regards to importing 12-words paper wallets, we brainstormed to find a structure acceptable to everyone and ended up with: /m/cointype/reserved'/account'/change/n The extra levels require some explanation: * cointype: This is zero for Bitcoin. This is here to support two things, one is supporting alt coins based off the same root seed. Right now nobody seemed very bothered about alt coins but sometimes feature requests do come in for this. Arguably there is no need and alt coins could just use the same keys as Bitcoin, but it may help avoid confusion if they don't. More usefully, cointype can distinguish between keys intended for things like multisig outputs, e.g. for watchdog services. This means if your wallet does not know about the extra protocol layers involved in this, it can still import the raw money and it will just ignore/not see the keys used in more complex transactions. * reserved is for other stuff. I actually don't recall why we ended up with this. It may have been intended to split out multisig outputs etc from cointype. Marek, Thomas? * account is for keeping essentially wallets-within-a-wallet to avoid mixing of coins. If you want that. * change is 0 for receiving addresses, 1 for change addresses. * n is the actual key index For bitcoinj we're targeting a deliberately limited feature set for hdw v1 so I would just set the first three values all to zero and that is a perfectly fine way to be compatible. The goal here is that the same seed can be written down once, and meet all the users needs, whilst still allowing some drift between what wallets support. Pieter made the I think valid point that you can't really encode how keys are meant to be used into just an HDW hierarchy and normally you'd need some metadata as well. However, I feel interop between wallets is more important than arriving at the most perfect possible arrangement, which feels a little like bikeshedding, so I'm happy to just go with the flow on this one. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments
On 03/20/2014 05:14 PM, Alex Kotenko wrote: Hmm, if we're inventing an URI for bluetooth, I'd rather follow existing URI's patterns. BT is strictly point-to-point connection, so BT MAC should be considered as server address, and payment request ID can be considered as request path. Probably bt:bt-mac/ random_id_of_payment_request would be more usual and easily understandable. Agreed. I used the dash because I feared a slash would need to be escaped if used in an URL parameter. I wonder how complex it would be to implement HTTP-over-Bluetooth. Not like I'm willing to do that now, but HTTP is well known and proven to be quite good for tasks like this, so in theory it would be handy to have such capacities in here. Thought of that as well. On the other hand, HTTP might be overkill and we inherit its potential downsides as well. Well, do we need to be compatible? If the dev community decides Base43 PR QR's (or whatever other self-contained format) is the way to go, we just implement, roll it out and use it. My PoS needs to be compatible with BIP21, as when I'm presenting QR code or sending NFC message - I have no way to tell what wallet/phone is on the accepting side, so I have to be compatible to existing widely supported technologies. Agreed. All I wanted to say support for QR is still small enough that we might be able to switch to an incompatible standard. If we're determined that is. Well, yes, it would be less efficient than base43. But did you calculate how much less? It's a compatible and already widely used way and loosing compatibility needs to have serious reasons, so would be great to know exact figures here. Base 64 via binary QR: 64 chars / 256 chars == 6 bit / 8 bit = 0.75 Base 43 via alphanum QR: 43 chars / 45 chars == 5.43 bit / 5.49 bit = 0.99 That would be efficiency in terms of PR data size vs. amount space used in a QR code. Of course, the visual QR encoding also plays a role, for example its size is increased in discrete steps. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments
On 03/20/2014 01:12 PM, Adam Back wrote: Whats a sensible limit on practical/convenient QR code size? Technically 3 KB. In my experience codes above 1.5 KB become impossible to scan (ZXing scanner, 3 years ago). You will want to stay below 500 bytes for convenient scanning. That said, I'm convinced there is a lot of room for scanning improvements. How much of the payment protocol message size comes from use of x509? As said in the OP, a minimal PR uses 50 bytes. X.509 seems to put about 4000 bytes on top of that. As you can see, we have quite some room for improvements to PR payload (PaymentDetails). X.509 certification will probably not be possible via QR, at least not until specialized CA's will issue space-efficient certs (using ECDSA?). -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments
On 03/20/2014 06:31 PM, Jeff Garzik wrote: Afaik, BIP73 needs an external server (the web server). Yes. Internet connectivity is not a rarity these days. Near-field web servers also work fine. Unfortunately it still is. At least here in Germany. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments
+1 I couldn't do a better job at describing my motivation behind trying to stuff payment requests into QR codes. On 03/20/2014 10:52 PM, Roy Badami wrote: On Thu, Mar 20, 2014 at 07:31:27PM +0100, Mike Hearn wrote: Yes, this overlaps somewhat with the PKI signing in BIP70, but not entirely - you might want to serve unsigned payment requests, but still have confidentiality and authenticity for a local face to face transaction. The signing and encryption does different things I'm not sure if this what you're getting at, but in a common face-to-face scenario, it really doesn't overlap so much (in that the PKI in BIP70 isn't really helpful). It's not unusual, in a face-to-face transaction at a bricks-and-mortar establishment, that you know neither the legal name of the entity running the establishment, nor any electronic identifier (domain name, email address) that might be presented to you in an X.509 certificate, even if such a certificate is presented in the PaymentRequest. In many cases I want/need to simply be assured that I am paying the person/organisation which operates that machine behind the counter, right there. In many ways I'll miss the simplicity of BIP21 QR codes for face-to-face transactions - because in this use case the payment protocol complicates (and in many cases weakens) the assurance that you really are paying the entity that prepared the QR code. roy -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Post to list request
Access granted. Welcome! (-: On 03/21/2014 10:11 AM, Chris D'Costa wrote: Hello I wonder if I could be granted access to post to the dev list. My project is the Meek hardware wallet, and we are working on a solution to avoid MITM attacks when communicating a pay-to information over a non-secure transport mechanism. Regards Chris -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments
On 03/20/2014 03:22 AM, Alex Kotenko wrote: Right now, before BIP70, I'm sending BIP21 URI via NFC or QR code, and I need to still be able to use it for backwards compatibility. But at the same time I want to be able to support BIP70. And also I want to avoid using external servers, the concept of my POS is that everything is happening between just payer's phone and payee's POS device. This means that BIP72 HTTP(S) link inside Bitcoin URI is not suitable for me. We could use Bluetooth in the r parameter, not unlike we use Bluetooth in the payment_url. However, since multiple devices could access your machine at the same time, we need some for of adressibility of different payment requests. Something like bt:btmac-random_id_of_payment_request. You're also offering an option to include Base43 encoded PR body right inside the Bitcoin URI, but in a way that is not backwards compatible with BIP21. Well, do we need to be compatible? If the dev community decides Base43 PR QR's (or whatever other self-contained format) is the way to go, we just implement, roll it out and use it. I understand your intention behind base43 encoding and noncompatible URI - you want to make most possible use of QR codes. But I wonder - did you compare this base43 to base64 encoded request in a binary QR code format? How much do we actually win in total bytes capacity at a price of noncompatibility and increased complexity? Alphanumeric QR codes have an alphabet of 45 chars, of which I am using 43. I skipped Space and '%' because they're not allowed in URIs. When I invented the Base43 format back in 2011, wanted it to be URI compatible so we can use the Android intent dispatcher. If we let go of the URI requirement, we can use binary QR codes as well. This means users will always have to manually start their Bitcoin app first. (Also, there is an implementation issue with the ZXing scanner I'm using, it returns Strings rather than a byte array so it will choke on \0 characters.) And also maybe we can extend BIP72 to include encoded payment request in the URL directly in a backwards compatible way? I took this into consideration. It would be space inefficient. The Base58-encoded address from BIP21 forces the QR code into binary mode. Still you can't encode the payment request extension (probably an URL parameter) as binary because it needs to stay compatible to the URI standard (RFC 3986). You could use one of the Base64 variants for the PR in this case, but still it would be inefficient. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] moving the default display to mbtc
btw. None of Bitcoin Wallet's users complained about confusion because of the mBTC switch. In contrast, I get many mails and questions if exchange rates happen to differ by 10%. I suspect nobody looks at the Bitcoin price. It's the amount in local currency that matters to the users. On 03/13/2014 02:40 PM, Andreas Schildbach wrote: Indeed. And users were crying for mBTC. Nobody was asking for µBTC. I must admit I was not aware if this thread. I just watched other wallets and at some point decided its time to switch to mBTC. On 03/13/2014 02:31 PM, Mike Hearn wrote: The standard has become mBTC and that's what was adopted. It's too late to try and sway this on a mailing list thread now. On Thu, Mar 13, 2014 at 2:29 PM, Gary Rowe g.r...@froot.co.uk mailto:g.r...@froot.co.uk wrote: The MultiBit HD view is that this is a locale-sensitive presentation issue. As a result we offer a simple configuration panel giving pretty much every possible combination: icon, m+icon, μ+icon, BTC, mBTC, μBTC, XBT, mXBT, μXBT, sat along with settings for leading/trailing symbol, commas, spaces and points. This allows anyone to customise to meet their own needs beyond the offered default. We apply the NIST guidelines for representation of SI unit symbols (i.e no conversion to native language, no RTL giving icon+m etc). Right now MultiBit HD is configured to use m+icon taken from the Font Awesome icon set. However reading earlier posts it seems that μ+icon is more sensible. Let us know what you'd like. Links: m+icon screenshot: http://imgur.com/a/WCDoG Font Awesome icon: http://fortawesome.github.io/Font-Awesome/icon/btc/ NIST SI guidelines: http://physics.nist.gov/Pubs/SP811/sec07.html On 13 March 2014 12:56, Jeff Garzik jgar...@bitpay.com mailto:jgar...@bitpay.com wrote: Resurrecting this topic. Bitcoin Wallet moved to mBTC several weeks ago, which was disappointing -- it sounded like the consensus was uBTC, and moving to uBTC later --which will happen-- may result in additional user confusion, thanks to yet another decimal place transition. On Sun, Nov 17, 2013 at 9:28 PM, Wendell w...@grabhive.com mailto:w...@grabhive.com wrote: We're with uBTC too. Been waiting for the signal to do this, let's do it right after the fee system is improved. -wendell grabhive.com http://grabhive.com | twitter.com/hivewallet http://twitter.com/hivewallet | gpg: 6C0C9411 On Nov 15, 2013, at 6:03 AM, Jeff Garzik wrote: Go straight to uBTC. Humans and existing computer systems handle numbers to the left of the decimals just fine (HK Dollars, Yen). The opposite is untrue (QuickBooks really does not like 3+ decimal places). -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net mailto:Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net mailto:Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development
Re: [Bitcoin-development] moving the default display to mbtc
By that definition 3.56 is a price. Maybe I misunderstood you and you're lobbying for mBTC? On 03/14/2014 03:57 PM, Tamas Blummer wrote: you miss the point Andreas. It is not about the magnitude but about the form of a price. A number with no decimals or with two decimals is percieved as a price in some currency. A number with more than two decimals is just not percieved as a price but as a geeky something that you rather convert to local currency. Tamas Blummer Bits of Proof On 14.03.2014, at 15:49, Andreas Schildbach andr...@schildbach.de mailto:andr...@schildbach.de wrote: How much do you pay for an Espresso in your local currency? At least for the Euro and the Dollar, mBTC 3.56 is very close to what people would expect. Certainly more familiar than µBTC 3558 or BTC 0.003578. Anyway, I was just sharing real-world experience: nobody is confused. On 03/14/2014 03:14 PM, Tamas Blummer wrote: You give them a hard to interpret thing like mBTC and then wonder why they rather look at local currency. Because the choices you gave them are bad. I think Bitcoin would have a better chance to be percieved as a currency of its own if it had prices and fractions like currencies do. 3.558 mBTC or 0.003578 BTC will never be as accepted as 3558 bits would be. Tamas Blummer Bits of Proof On 14.03.2014, at 15:05, Andreas Schildbach andr...@schildbach.de mailto:andr...@schildbach.de wrote: btw. None of Bitcoin Wallet's users complained about confusion because of the mBTC switch. In contrast, I get many mails and questions if exchange rates happen to differ by 10%. I suspect nobody looks at the Bitcoin price. It's the amount in local currency that matters to the users. On 03/13/2014 02:40 PM, Andreas Schildbach wrote: Indeed. And users were crying for mBTC. Nobody was asking for µBTC. I must admit I was not aware if this thread. I just watched other wallets and at some point decided its time to switch to mBTC. On 03/13/2014 02:31 PM, Mike Hearn wrote: The standard has become mBTC and that's what was adopted. It's too late to try and sway this on a mailing list thread now. On Thu, Mar 13, 2014 at 2:29 PM, Gary Rowe g.r...@froot.co.uk mailto:g.r...@froot.co.uk mailto:g.r...@froot.co.uk wrote: The MultiBit HD view is that this is a locale-sensitive presentation issue. As a result we offer a simple configuration panel giving pretty much every possible combination: icon, m+icon, μ+icon, BTC, mBTC, μBTC, XBT, mXBT, μXBT, sat along with settings for leading/trailing symbol, commas, spaces and points. This allows anyone to customise to meet their own needs beyond the offered default. We apply the NIST guidelines for representation of SI unit symbols (i.e no conversion to native language, no RTL giving icon+m etc). Right now MultiBit HD is configured to use m+icon taken from the Font Awesome icon set. However reading earlier posts it seems that μ+icon is more sensible. Let us know what you'd like. Links: m+icon screenshot: http://imgur.com/a/WCDoG Font Awesome icon: http://fortawesome.github.io/Font-Awesome/icon/btc/ NIST SI guidelines: http://physics.nist.gov/Pubs/SP811/sec07.html On 13 March 2014 12:56, Jeff Garzik jgar...@bitpay.com mailto:jgar...@bitpay.com mailto:jgar...@bitpay.com wrote: Resurrecting this topic. Bitcoin Wallet moved to mBTC several weeks ago, which was disappointing -- it sounded like the consensus was uBTC, and moving to uBTC later --which will happen-- may result in additional user confusion, thanks to yet another decimal place transition. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] moving the default display to mbtc
I don't know about financial software. I really don't get what you mean by weird notation? Bitcoin Wallet is made for ordinary users. They are used to real-world prices like EUR 1.63 / USD 2.26 (that would be the Espresso example). How can mBTC 3.56 be weird to these people? Granted, there are exceptions, like in Japan. Maybe those would be better served with µBTC as default. Maybe. Up to now, outside of this mailing list nobody requested µBTC. Then again, Japanese userbase is tiny compared to US. On 03/14/2014 04:12 PM, Tamas Blummer wrote: I think you want to misunderstand me Andreas. It is astonishing arrogance to define the units because we in Bitcoin are used to some wierd notation and ignore that the vast majority of population and financial software in existence does not have a notion of prices with more than two decimals. With 1 bit = 100 satoshi, we would solve this problem for good. Instead mBTC is a confusing step in-between. Tamas Blummer http://bitsofproof.com On 14.03.2014, at 16:02, Andreas Schildbach andr...@schildbach.de mailto:andr...@schildbach.de wrote: By that definition 3.56 is a price. Maybe I misunderstood you and you're lobbying for mBTC? On 03/14/2014 03:57 PM, Tamas Blummer wrote: you miss the point Andreas. It is not about the magnitude but about the form of a price. A number with no decimals or with two decimals is percieved as a price in some currency. A number with more than two decimals is just not percieved as a price but as a geeky something that you rather convert to local currency. Tamas Blummer Bits of Proof On 14.03.2014, at 15:49, Andreas Schildbach andr...@schildbach.de mailto:andr...@schildbach.de mailto:andr...@schildbach.de wrote: How much do you pay for an Espresso in your local currency? At least for the Euro and the Dollar, mBTC 3.56 is very close to what people would expect. Certainly more familiar than µBTC 3558 or BTC 0.003578. Anyway, I was just sharing real-world experience: nobody is confused. On 03/14/2014 03:14 PM, Tamas Blummer wrote: You give them a hard to interpret thing like mBTC and then wonder why they rather look at local currency. Because the choices you gave them are bad. I think Bitcoin would have a better chance to be percieved as a currency of its own if it had prices and fractions like currencies do. 3.558 mBTC or 0.003578 BTC will never be as accepted as 3558 bits would be. Tamas Blummer Bits of Proof On 14.03.2014, at 15:05, Andreas Schildbach andr...@schildbach.de mailto:andr...@schildbach.de mailto:andr...@schildbach.de wrote: btw. None of Bitcoin Wallet's users complained about confusion because of the mBTC switch. In contrast, I get many mails and questions if exchange rates happen to differ by 10%. I suspect nobody looks at the Bitcoin price. It's the amount in local currency that matters to the users. On 03/13/2014 02:40 PM, Andreas Schildbach wrote: Indeed. And users were crying for mBTC. Nobody was asking for µBTC. I must admit I was not aware if this thread. I just watched other wallets and at some point decided its time to switch to mBTC. On 03/13/2014 02:31 PM, Mike Hearn wrote: The standard has become mBTC and that's what was adopted. It's too late to try and sway this on a mailing list thread now. On Thu, Mar 13, 2014 at 2:29 PM, Gary Rowe g.r...@froot.co.uk mailto:g.r...@froot.co.uk mailto:g.r...@froot.co.uk mailto:g.r...@froot.co.uk wrote: The MultiBit HD view is that this is a locale-sensitive presentation issue. As a result we offer a simple configuration panel giving pretty much every possible combination: icon, m+icon, μ+icon, BTC, mBTC, μBTC, XBT, mXBT, μXBT, sat along with settings for leading/trailing symbol, commas, spaces and points. This allows anyone to customise to meet their own needs beyond the offered default. We apply the NIST guidelines for representation of SI unit symbols (i.e no conversion to native language, no RTL giving icon+m etc). Right now MultiBit HD is configured to use m+icon taken from the Font Awesome icon set. However reading earlier posts it seems that μ+icon is more sensible. Let us know what you'd like. Links: m+icon screenshot: http://imgur.com/a/WCDoG Font Awesome icon: http://fortawesome.github.io/Font-Awesome/icon/btc/ NIST SI guidelines: http://physics.nist.gov/Pubs/SP811/sec07.html On 13 March 2014 12:56, Jeff Garzik jgar...@bitpay.com mailto:jgar...@bitpay.com mailto:jgar...@bitpay.com mailto:jgar...@bitpay.com wrote: Resurrecting this topic. Bitcoin Wallet moved to mBTC several weeks ago, which was disappointing -- it sounded like the consensus was uBTC, and moving to uBTC later --which will happen-- may result in additional user confusion, thanks to yet another decimal place transition. -- Learn Graph Databases - Download FREE O'Reilly Book Graph
Re: [Bitcoin-development] moving the default display to mbtc
Indeed. And users were crying for mBTC. Nobody was asking for µBTC. I must admit I was not aware if this thread. I just watched other wallets and at some point decided its time to switch to mBTC. On 03/13/2014 02:31 PM, Mike Hearn wrote: The standard has become mBTC and that's what was adopted. It's too late to try and sway this on a mailing list thread now. On Thu, Mar 13, 2014 at 2:29 PM, Gary Rowe g.r...@froot.co.uk mailto:g.r...@froot.co.uk wrote: The MultiBit HD view is that this is a locale-sensitive presentation issue. As a result we offer a simple configuration panel giving pretty much every possible combination: icon, m+icon, μ+icon, BTC, mBTC, μBTC, XBT, mXBT, μXBT, sat along with settings for leading/trailing symbol, commas, spaces and points. This allows anyone to customise to meet their own needs beyond the offered default. We apply the NIST guidelines for representation of SI unit symbols (i.e no conversion to native language, no RTL giving icon+m etc). Right now MultiBit HD is configured to use m+icon taken from the Font Awesome icon set. However reading earlier posts it seems that μ+icon is more sensible. Let us know what you'd like. Links: m+icon screenshot: http://imgur.com/a/WCDoG Font Awesome icon: http://fortawesome.github.io/Font-Awesome/icon/btc/ NIST SI guidelines: http://physics.nist.gov/Pubs/SP811/sec07.html On 13 March 2014 12:56, Jeff Garzik jgar...@bitpay.com mailto:jgar...@bitpay.com wrote: Resurrecting this topic. Bitcoin Wallet moved to mBTC several weeks ago, which was disappointing -- it sounded like the consensus was uBTC, and moving to uBTC later --which will happen-- may result in additional user confusion, thanks to yet another decimal place transition. On Sun, Nov 17, 2013 at 9:28 PM, Wendell w...@grabhive.com mailto:w...@grabhive.com wrote: We're with uBTC too. Been waiting for the signal to do this, let's do it right after the fee system is improved. -wendell grabhive.com http://grabhive.com | twitter.com/hivewallet http://twitter.com/hivewallet | gpg: 6C0C9411 On Nov 15, 2013, at 6:03 AM, Jeff Garzik wrote: Go straight to uBTC. Humans and existing computer systems handle numbers to the left of the decimals just fine (HK Dollars, Yen). The opposite is untrue (QuickBooks really does not like 3+ decimal places). -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net mailto:Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net mailto:Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three
Re: [Bitcoin-development] Instant / contactless payments
On 03/10/2014 04:09 PM, Alex Kotenko wrote: Yes, I'm certain about that we need to switch to BIP70 asap. As I said earlier - support among the wallets is the biggest problem here really. Only Andreas' Wallet supports it right now AFAIK, and even in there it's only as LABS feature, so will be turned off for most of users. Just a small clarification here. Bitcoin Wallet supports the customer side of the protocol since 2011, without any Labs enabling! This means you've got an install base of half a million devices that you can interoperate with. Sure, a lot of users will have Bluetooth switched off. The UI flow to enable it while paying is pretty smooth though. The merchant side used to have the Labs enabling but this is gone since a few weeks. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Instant / contactless payments
On 03/06/2014 07:03 PM, Alex Kotenko wrote: Supporting Bluetooth is optional in the sense that if a wallet should not support it, you will still receive the transaction via the P2P network. So I'd say definately go for Bluetooth. Yes, it's part of the plan. Just again - I need to make sure we support all major wallets. And no other wallets actually support NFC by now, not talking about bluetooth. So I imagine we will decide and implement together some solution here, both on the wallet and POS sides, but I will have to keep URI method and even QR codes for backwards compatibility, and wait for other main wallets to accept innovations before we will be able to completely switch to it. As I said earlier - bluetooth support for my POS is not a problem, we can plug it in easily and make it work. Support among all hardware/software and polished user experience - this is a main thing here really. Sure, take all the time you need. All I wanted to say is you don't need to break Bitcoin URI compatibility in order to support direct payments via Bluetooth. It's simply an add-on, both in the BIP21 and the BIP70 cases. -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Instant / contactless payments
I'm not sure if iso-dep is the way to go here. Afaik as soon as you pick up the phone the connection breaks. It's ok if some people decide to let the app do risk analysis, but you cannot force it onto users by picking a protocol that cannot deal with manual verification. Users should always have the choice to verify their payment without time pressure and by holding the device of their choice at their individual viewing distance. Besides, how do you plan to risk-analyse the memo field? In current phone implementations, the screen must be on already for NFC to be active. Also it must be unlocked, although I certainly hope future OSes will allow payment apps on the lock screen, just like they allow music players. To get the very fast light feel the actual contact period has to be quite short, so I bet we'd need to optimise the bootup process of the Android wallet app. It's already very short if you can do without Android Beam, e.g. on Android 2.3. I'd say 200 ms for an BIP21 payment request. Bootup of the app and everything else happens after -- no need to continue contact. Indeed most of the bootup time goes into loading complex wallets. Our long standing plans to clean up the wallet and archieve transactions should help. Also, if Bitcoin catches on the app will just stay in memory. The most obvious optimization to speed up signature checking is to make it lazy. The user can already inspect the payment while signatures are being checked. Even transaction signing could already happen in advance, if it can be made sure that no signed transaction escapes the dialog without the users consent. Even the current ~10 second roundtrip is a huge improvement to the status quo. I recently tried to buy a subway ticket and it took me 7 full minutes (just for the payment process)! -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Instant / contactless payments
On 03/06/2014 02:44 PM, Mike Hearn wrote: I'm not sure if iso-dep is the way to go here. Afaik as soon as you pick up the phone the connection breaks. If the phone isn't willing to immediately authorise then it'd have to fall back to HTTPS or Bluetooth as normal. Ok, that would be an option. Besides, how do you plan to risk-analyse the memo field? I guess only the amount and destination are relevant for risk analysis. The memo field (and its logical evolution, an invoice) also needs to be verified, since its part of the contract. Imagine sitting in a restaurant and you're being presented the bill, most people will do a quick scan of the meals and drinks consumed (and non-malignant errors are frequent in that business). It's already very short if you can do without Android Beam, e.g. on Android 2.3. I think IsoDep based protocols must bypass Beam - when I scan my e-passport there's no beam animation. Everything except Beam bypasses Beam (-: Beam is an Android-specific protocol. I assume it would also be possible to write an own NDEF implementation on top of the low level NFC APIs. I want to try as soon as I have a second NFC-capable phone, preferably Android 4.4. Even the current ~10 second roundtrip is a huge improvement to the status quo. I recently tried to buy a subway ticket and it took me 7 full minutes (just for the payment process)! Then that subway kind of sucks ;) You can't really blame the subway for a broken payment process. Have you been to London and used Oyster? Yes, it was a complete disaster. Obtaining a ticket took even longer -- ca. 45 minutes. Boarding the train took some additional seconds, compared to no overhead in Germany where we simply don't have any gates. On top of that, you walk more (in tunnels) than you get driven around, get tracked on each movement and if you want to get your (monetary) change, you need to wait for another 45 minutes. The upside is, when going by public transport in England I always feel like Mr. Freeman in City 17 (-: -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Instant / contactless payments
Not sure if you've seen it, but here is how we do NFC right now http://www.youtube.com/watch?v=DGOMIG9JUY8 with XBTerminal. Thanks for the video! It's always good to see these things in action so you can start believing in it. For now this is just an NDEF URI message with Bitcoin URI inside, and then transaction itself propagated to the network by the phone using it's own Internet connection. Far not ideal, but even this is supported only by Andreas' Wallet, so we cannot move ahead alot really until other wallets will have some support in this area. Supporting Bluetooth is optional in the sense that if a wallet should not support it, you will still receive the transaction via the P2P network. So I'd say definately go for Bluetooth. As you see - it's taking just few seconds, most of which is manual payment confirmation. I wonder about the receipt step -- are you generating a PDF on device and sending it via NFC? This is something that could be supported by the BIP70 payment protocol. We should try to avoid the second tap, its not intuitive. And btw, have you been to London lately? Oyster readers now accept contactless cards directly along with Oyster cards itself. Contactless cards? Last I was to London, the Oyster card was already contactless. Have there ever been magnet-strip-based Oyster cards? I wonder if eventually in future we could add bitcoin support into that system directly, without hardware replacements. Neat thought (-: -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Instant / contactless payments, IsoDep
On 03/06/2014 03:51 PM, Andreas Schildbach wrote: I'm not sure if iso-dep is the way to go here. Afaik as soon as you pick up the phone the connection breaks. If the phone isn't willing to immediately authorise then it'd have to fall back to HTTPS or Bluetooth as normal. Ok, that would be an option. One of the first things to explore is if its possible to dispatch different isodep applications to different apps. I know you can add an intent filter matching action=android.nfc.action.TECH_DISCOVERED and a custom tech filter android.nfc.tech.IsoDep. However, as long as there is no mime type or similar concept, apps will always fight for access to IsoDep endpoints. We will want to avoid that situation. -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments
I've written up a document about all the different methods on how the payment protocol (both the old one and BIP70) is used in Bitcoin Wallet. It only provides an overview -- I plan to go into details with separate (BIP?) documents where needed. https://github.com/schildbach/bitcoin-wallet/wiki/Payment-Requests If you have any questions about compatibility, don't hesitate to contact me. On 01/27/2014 12:59 PM, Andreas Schildbach wrote: As promised I'd like to present my work done on leveraging the payment protocol for face-to-face payments. [...] -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] BIP70 proposed changes
I'm starting a thread on proposed changes on BIP70 based on my experience in implementing the payment protocol in Bitcoin Wallet: - certificate chain in pki_data: I think it should be required that is most contain the first certificate PLUS all intermediate certificates (if any), but NOT the root certificate. Reason: We want to be able to verify offline. - definition of timezone: Its not clear if times (e.g. expires) are in UTC or local. I suggest to require UTC. If if we can't agree on this, there should be a sentence about timezones in the spec. (probably more to be added...) -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP70 proposed changes
On 02/18/2014 08:14 PM, Ryan X. Charles wrote: The most important missing piece of the payment protocol is that is has no concept of the status of a payment after it has been made. What if the payment is too little? Too much? What if it is never confirmed? What if it is confirmed, but very late? These are regular occurrences at BitPay (although hopefully they will be a lot fewer after the payment protocol is widely adopted). I would like to understand why this happens at BitPay? If this is because people use cut and paste to copy the address and then type the amount by hand... well this kind of usage will go away. A program (like an app) should be capable of paying the exact amount. If not, that's a bug of the app not the protocol. On an unrelated note, X.509 is a terrible standard that should be abandoned as quickly as possible. +1 BitPay is working on a new standard based on bitcoin-like addresses for authentication. It would be great if we could work with the community to establish a complete, decentralized authentication protocol. Sounds interesting, let us know as soon as you have anything. - certificate chain in pki_data: I think it should be required that is most contain the first certificate PLUS all intermediate certificates (if any), but NOT the root certificate. Reason: We want to be able to verify offline. So long as the root certificate remains an optional addition, this seems like a good idea. In which case does it make sense to duplicate the root cert? I'm asking because it should already be present in the trusted root store, right? Maybe can you tell about which measures you needed to take to get X.509 working? To me it felt there very several problems. My experience with tls in node is that it is required TLS? We're not using that for pki_data -- its just a byte array. - definition of timezone: Its not clear if times (e.g. expires) are in UTC or local. I suggest to require UTC. If if we can't agree on this, there should be a sentence about timezones in the spec. The world needs to abandon timezones altogether for everything and only use UTC. So, agreed. Require UTC. -- https://github.com/bitcoin/bips/pull/20 -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments
I have refreshed the Bitcoin Wallet preview version with beta version 3.32. It now implements BIP72 aka URI extension for payment protocol. There is one important deviation from the standard though: Bitcoin URI address and amount fields need to correspond to the data from the payment request. The makes sure the signature really signs the URI (which you've gotten directly from the payee) and not a malicious payment request introduced by a MITM. Note the memo isn't protected like that, so it can still be MITM'ed. I know this means that for the time being Bitcoin URIs must be backwards compatible. That should not be an issue since we will be in transition phase for many months anyway. Until then, I hope we will have agreed on a more sophisticated approach, e.g. a separate hash in the URI. Source: https://github.com/schildbach/bitcoin-wallet/commits/v3.32 Binaries: https://github.com/schildbach/bitcoin-wallet/releases/tag/v3.32 (also published to the corresponding channels on Google Play) On 01/30/2014 11:46 AM, Andreas Schildbach wrote: Just a small update. I merged the code to my bitcoinj-0.11 branch and put up binary .apk files for experimentation. Just make sure to tick BIP70 for tap-to-pay/scan-to-pay in the labs settings. Source: https://github.com/schildbach/bitcoin-wallet/commits/bitcoinj-0.11 Binaries: https://github.com/schildbach/bitcoin-wallet/releases/tag/v3.30-bitcoinj0.11 On 01/27/2014 12:59 PM, Andreas Schildbach wrote: As promised I'd like to present my work done on leveraging the payment protocol for face-to-face payments. The general assumption is that individuals don't own X.509 certificates. Their devices may be only badly connected to the internet or in some cases not at all. I've implemented a prototype on a branch of Bitcoin Wallet. It is using bitcoinj 0.11 (not released). https://github.com/schildbach/bitcoin-wallet/commits/payment-protocol -- WatchGuard Dimension instantly turns raw network data into actionable security intelligence. It gives you real-time visual feedback on key security issues and trends. Skip the complicated setup - simply import a virtual appliance and go from zero to informed in seconds. http://pubads.g.doubleclick.net/gampad/clk?id=123612991iu=/4140/ostg.clktrk -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121051231iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments
Just a small update. I merged the code to my bitcoinj-0.11 branch and put up binary .apk files for experimentation. Just make sure to tick BIP70 for tap-to-pay/scan-to-pay in the labs settings. Source: https://github.com/schildbach/bitcoin-wallet/commits/bitcoinj-0.11 Binaries: https://github.com/schildbach/bitcoin-wallet/releases/tag/v3.30-bitcoinj0.11 On 01/27/2014 12:59 PM, Andreas Schildbach wrote: As promised I'd like to present my work done on leveraging the payment protocol for face-to-face payments. The general assumption is that individuals don't own X.509 certificates. Their devices may be only badly connected to the internet or in some cases not at all. I've implemented a prototype on a branch of Bitcoin Wallet. It is using bitcoinj 0.11 (not released). https://github.com/schildbach/bitcoin-wallet/commits/payment-protocol -- WatchGuard Dimension instantly turns raw network data into actionable security intelligence. It gives you real-time visual feedback on key security issues and trends. Skip the complicated setup - simply import a virtual appliance and go from zero to informed in seconds. http://pubads.g.doubleclick.net/gampad/clk?id=123612991iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Payment Protocol for Face-to-face Payments
As promised I'd like to present my work done on leveraging the payment protocol for face-to-face payments. The general assumption is that individuals don't own X.509 certificates. Their devices may be only badly connected to the internet or in some cases not at all. I've implemented a prototype on a branch of Bitcoin Wallet. It is using bitcoinj 0.11 (not released). https://github.com/schildbach/bitcoin-wallet/commits/payment-protocol TAP TO PAY First I looked at the NFC tap-to-pay usecase. The way it works as currently rolled out: A BIP21 URL is published using an NDEF URI message. The URL is supplemented by a Bluetooth MAC address that can be connected in order to finish the payment. Once connected, a very simple custom protocol transmits the signed transaction(s) in bitcoin-serialized form to the payee, who replies with an ack or nack. The way I prototyped it to work in future: Instead of the BIP21 URL a BIP70 payment request is published using an NDEF MIME message (mime-type as per BIP71). The paymentUrl field can (and in the face-to-face case should) contain a Bluetooth URL which contains the MAC address of the payee. Because I could not find any standard for Bluetooth URLs, I made up my own: bt:112233445566 means MAC address 11:22:33:44:55:66. Once connected, Payment message and PaymentACK reply are used to finish the payment. Since Bluetooth sockets are streams, I had to use the delimited variant of the protobufs for Payment and PaymentACK messages. This prepends them with a VARINT containing the message length. All of the above should be easy to migrate. NFC implementations are rare, and the current Bluetooth protocol is implemented only by Bitcoin Wallet afaik. Fallbacks are provided where necessary. In future, I'd like to add encryption to the Bluetooth connection, maybe using SSL and some DH key exchange. SCAN TO PAY For scan-to-pay, the current landscape looks different. I assume at least 50% of Bitcoin transactions are initiated by a BIP21 URL encoded into a QR-code. Nevertheless, I tried to encode a payment request into the bitcoin URL. I used my existing work on encoding transactions into QR-codes. Steps to encode: 1. The payment request is protobuf-serialized. For a simple payment request, this results in only ~50 bytes thanks to the efficiency of protobuf. 2. The bytes are encoded using Base43, which is the same as Base64/Base58, but its alphabet consists of the characters allowed in so-called alphanumeric QR-codes, minus the characters not allowed in URLs. 3. The resulting string is prefixed by BITCOIN: 4. All of that goes into a QR-code, and because it only contains alphanumeric characters, it will produce a very efficient code. For simple payment requests, I could not notice any difference in scanning difficulty. There are some limitations however: - Obviously such QR-encoded payment requests cannot grow in size as much as using other media. In particular, I expect PKI signed requests are out of question. However, in face to face payments the value of a sig based on PKI is highly questionable, and the fact the sig cannot be verified without TCP connectivity doesn't help. There should be some headroom for multiple-output requests and moderately more complex scripts though. - I chose to re-use the bitcoin: URL scheme, because it's already whitelisted in web browsers, QR-code scanners and so on. In order to differentiate payment requests URLs from BIP21 URLs, I test for uri.startsWith(BITCOIN:) because you'll get letters in all-caps from alphanumeric QR-codes. I will investigate into a better solution. - Due to wide deployment of BIP21 QR-codes, migration needs to happen in distinct phases. Ability to parse payment protocol URLs comes first, default to presenting them to users has to come (much) later. CLICK TO PAY Finally this is the usecase the payment protocol was invented for and it's not face-to-face. I don't have much to add, just one thing. As a byproduct of the above, payment protocol URLs can be used for links published on web pages as well. This might provide a nice replacement for the imho rather ugly BIP72 specification once the payment protocol is widely deployed. Open for discussion. -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP70: PaymentACK semantics
On 01/27/2014 03:54 PM, Gavin Andresen wrote: The purpose of PaymentACK is to give the customer reassurance that their payment request has been received and will be processed (or not). If it is syntactically incorrect or invalid in a way that the payment processor can detect right away then a PaymentACK with a message saying that there is a problem should be the response. Thanks for the clarification. So I am *always* supposed to reply with an ack. I was assuming that if I actually send a nack, I would just close the connection without sending an ack. Maybe that should be mentioned in the spec explicitly. I must admit that I think the name of the message is misleading -- PaymentResponse would make this clearer. -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Experiment with linking payment requests via href
On 01/27/2014 07:18 PM, Andreas Schildbach wrote: Rather than pack a file into a URL, if you don't want to use the current r= extension it's better for apps to just register to handle .bitcoinpaymentrequest files / the right MIME type. Downloading it and opening it would do the right thing automatically. That's a good point. I'll implement this asap. It doesn't look too good. I've tried Chrome, the AOSP browser and Firefox. All insist on handling the link with their download manager, which would involve an additional click. In the case of Chrome and AOSP, that download manager a separate component that is not updatable with the browser (rather its tied to the OS version afaik). If you click on the file in the download manager of Chrome and AOSP it opens as expected. On Firefox, it just ignores the click. I registered the correct mime type and also set the mime type of the href just in case. In case you want to have a look at the href, its on http://wallet.schildbach.de and links to Gavins generator. I didn't try suffixes, but I'd assume it behaves similar. Any ideas what else to try? -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP70/71 issue, RFD
Bluetooth, Wifi Direct, HTTP request/responses via broken proxies, smoke signals... basically anything that is a stream rather than a file. Right, NFC NDEF and QR codes are not affected, so we can skip the delimiter for these mediums. On 01/26/2014 10:24 PM, Mike Hearn wrote: Which medium is this an issue for? As you note, for files and HTTP responses it's not a problem in practice. i'd guess nor for NFC tags nor QR codes. On Sun, Jan 26, 2014 at 10:11 PM, Andreas Schildbach andr...@schildbach.de mailto:andr...@schildbach.de wrote: I'm experimenting with BIP70/71 (payment protocol) usage in face to face payments (more on that soon). I've excountered an issue with the protobuf format. Protobufs are not self-delimiting. That means if you're reading from an undelimited stream, you will read endlessly because you don't know how much to read. The current BIP70 implementations probably work because they're reading either from a file or from an HTTP resource which sets the Content-Length header. Trouble is the Content-Length header is optional, and also there are many kinds of streams that don't have this built-in delimiting mechanism. The Java protobuf API solves this by offering delimited I/O, like payment.writeDelimitedTo(os); This writes the size of the message as a varint before writing the data. I don't know about protobuf implementations for other languages but I'd expect them to offer something compatible. However, this leading varint is an incompatible change and would need to be added to the spec. I specifically encountered this with PaymentMessage and PaymentACK, but it might be a good idea to apply this to all messages if any. Open for discussion. -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net mailto:Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment protocol and reliable Payment messages
On 01/13/2014 06:56 PM, Pieter Wuille wrote: I want to avoid the case where a transaction confirms, but the associated payment is not delivered. If there is a reasonable chance that this case occurs in normal operation, it means the payment transmission cannot be relied upon. I was thinking about this some more. Generally I think you have a point. However, there is one case I'm worried about. Imagine you get a good offer (payment request) from a merchant. You would like to accept that offer, however the merchant has changed his mind. If you don't broadcast the payment to the blockchain, you won't have a chance to accept and legally bind the offer. The merchant will silently discard your payment messages. At some point, you will involve a judge. If you can present the payment request and the payment from the block chain, you're in a much better position than if you just present a request but no confirmed payment. I think in some cases you might want to broadcast your txn to the P2P network, even if the payment messages get lost. What do you think? -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment protocol and reliable Payment messages
On 01/14/2014 11:45 AM, Mike Hearn wrote: Imagine you get a good offer (payment request) from a merchant. You would like to accept that offer, however the merchant has changed his mind. Usually if the merchant has not delivered, then at that point it's not a problem and he is allowed to change his mind. It's only if they change their mind *after* you pay that it's a problem, right? It was my understanding of the spec that a payment request is legally binding one side for the specified amount of time. Basically I offer you to sell you these 10 eggs (described in the memo) for this amount if you accept until this time. I have even signed this so you can know its me who made you the offer. If you accept (by paying), the contract is valid and there should be nothing I can do about it (except for extreme cases which are covered by law already). Actually what good is the payment request if its not binding? Why do we have an expiry time in the message? -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment protocol and reliable Payment messages
Thanks for the explanation. On 01/13/2014 06:56 PM, Pieter Wuille wrote: As for you proposal, just be aware I'd like to use the payment protocol for face to face payments as well. That meant payment request via NFC or QR, payment message and payment confirmations via Bluetooth. I think it can be done by putting a Bluetooth mac address into the payment_url. I'm aware. What issues do you see? Looks good so far. Just wanted to keep you aware (-: -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fees UI warning
On 12/16/2013 07:28 PM, Mike Hearn wrote: I don't know how to solve this. Badly designed software that looks appealing will always be a danger. One way would be to explicitly warn against some services. For example, on the Choose you wallet page of bitcoin.org. -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
