Re: [Bitcoin-development] No Bitcoin For You
for individuals collectively to make up the majority of the network, if more parts of the network itself rely on SPV-level security. With SPV-level security, it might be possible to implement a scalable DHT-type network of nodes that collectively store and index the exhaustive and fast-growing corpus of transaction history, up to and including currently unconfirmed transactions. Each individual node could host a slice of the transaction set with a configurable size, let's say down to a few GB today. Such a network would have the desirable property of being run by the community. Most transactions would be submitted to it, and like today's network, it would disseminate blocks (which would be rapidly torn apart and digested). Therefore miners and other full nodes would depend on it, which is rather critical as those nodes grow closer to data-center proportions. -- 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 -- Ryan X. Charles Software Engineer @BitGo twitter.com/ryanxcharles github.com/ryanxcharles keybase.io/ryanxcharles onename.com/ryanxcharles -- 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] Proposal to change payment protocol signing
Agreed with Mike. It doesn't really matter what the signature field is set to. Changing the standard now is too hard with too little benefit. On 4/28/14, 12:14 PM, Mike Hearn wrote: Who cares what it is? Setting to an empty byte array is fine, IMO. The payment protocol is already rolling out. It's implemented in several wallets, BitPay implements it, Coinbase is implementing it, etc. -10 for changing such a basic thing at this point. It'd cause chaos for the early adopters, punishing them instead of rewarding them. It'd seriously hurt adoption of the payment protocol when it's at its most vulnerable. We should mark BIP 70 as accepted and be done with it. -- 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 -- Ryan X. Charles Software Engineer, BitPay 0xA11B4DDE.asc Description: application/pgp-keys -- 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] sorting public keys for p2sh multisig transactions
For a p2sh multisig transaction, the serialized script looks like this: m [pubkey] ... [pubkey] n OP_CHECKMULTISIG The p2sh address is the hash of this script. The public keys can come in any order, but the hash depends on the order. If you have a list of public keys, to which address do you send your money? We need a standard way of sorting the public keys so that the address generated is always the same for the same public keys and m. There are two kinds of public keys: compressed and uncompressed. Uncompressed are longer than compressed. There are a few obvious ways we could sort the public keys: as strings, as big endian numbers, as little endian numbers. The difference is this. Suppose one public key is 59234 (uncompressed), and the other is 6903 (compressed). If we sort these as strings, then 6903 59234. But if we sort them as big endian numbers, then 6903 is really 06903, and then 06903 59234. So it makes a critical difference. Sorting as little endian is yet another option that is not the same as the other two. I noticed Alan Reiner's comment in an earlier message: Just like Jean-Pierre mentioned, we'll be using parallel trees to generate P2SH addresses after sorting the keys lexicographically. It sounds like lexicographically probably means sorting as strings. I have made an implementation of public key sorting in javascript where I sort them as big endian numbers and fill in the 0s. IMO, the simpler method is to sort them as strings, which has a simpler implementation since it doesn't require filling in 0s first. However, I don't actually care what method we use so long as everyone in the bitcoin world uses the same standard. Which is the best way to sort public keys? -- Ryan X. Charles Software Engineer, BitPay 0xA11B4DDE.asc Description: application/pgp-keys -- 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] BIP70 proposed changes
Here are my complementary thoughts after working on the payment protocol on the merchant side at BitPay. 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). One way to handle this would be to add another type of message, say with content-type bitcoin-paymentstatus, that can return the merchant's view of the status of the transaction(s). Are the transactions under or overpaid? Are they confirmed? How many confirmations? Is the payment accepted even if the transactions aren't confirmed? I think it would be great if wallets could check the status of a payment, and if anything goes wrong, request a refund, all within the payment protocol. The payment protocol is also the perfect opportunity to implement merge avoidance to increase customer and merchant privacy. The merchant can simply deliver multiple outputs in the payment details, say 10 or so, and the customer can spend multiple outputs to those outputs in separate transactions. It would be great if BitPay could work with wallet authors to make merge avoidance a reality in the near-term. Merge avoidance would increase the need to have a bitcoin-paymentstatus message since it's possible that some, but not all, of the transactions would confirm, and so knowing the status of payment would be a complex question that should be handled automatically by the software. On an unrelated note, X.509 is a terrible standard that should be abandoned as quickly as possible. 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. The sooner we can evolve beyond X.509 the better. One more thing. The new bitcoin URI in BIP 72 is extremely long and makes for very dense QR codes. BitPay has proposed a new standard, BIP 73, for shorter URIs and less dense QR codes. We hope wallet authors will implement this better standard. My response to Andreas' thoughts: On 2/18/14, 12:31 PM, Andreas Schildbach wrote: 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. So long as the root certificate remains an optional addition, this seems like a good idea. My experience with tls in node is that it is required for the root certificate to be present, so we don't want to require that the root certificate be absent, since that would make it painful to make code that is interoperable between the two. IIRC setting rejectUnauthorized=true will reject connections that do not deliver the root certificate, so allowing the root certificate to be present would be compatible with this and presumably other tls code. Would be great if someone with more experience with tls weighed in on whether the root certificate can/should be present. - 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. (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 -- Ryan X. Charles Software Engineer, BitPay 0xA11B4DDE.asc Description: application/pgp-keys -- 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
