Re: [Bitcoin-development] bitcoind json API (gettx/raw) (newbie questions #2)
Hey everybody, here's another question that I have: I'd like a small bit of clarification about the gettx / getrawtransaction (decoded) api call. I understand that I can find the address that a transaction output is directed at / available to for future use sits in the vout array in the scriptPubKey.addresses array. I'm a little uncertain as to why that piece of information would be typed as an array when all it ever seems to contain is one (not more, not less) address(es). Are there any cases of transactions right now that don't contain exactly 1 item in that array, i.e. more or less than a single address (per single vout element, not per tx)? Or is the thinking behind this array to somehow make the data structure more extensible for potential future use? But then I can't think of any use cases where it appears to make any sense to put more than 1 address there... This might be such a use case, just maybe -- https://coinb.in/multisig Also I recommend checking out http://abis.io These may be things you are thinking about in the context of this. Or am I even asking the wrong questions? For spending those coins, i.e. using them in a future transaction it's all about owning the public/private key that is contained in the vout script, right? So the address doesn't really matter and it could be 2 or more (or none at all?) addresses in there, and what matters is just that the next guy has the key to spending those coins... ? Once again I'm coming to these questions from a project where I'm trying to calculate unspent outputs and from that balances for all accounts and I'm not sure yet what other special cases there might be in the blockchain that I need to be aware of and handle properly in order to (re-)produce accurate data! Thanks for your help, much appreciated! - Denis Be the change you want to see in the world. (Mahatma Gandhi) -- 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 -- 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
[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
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
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] BIP70 proposed changes
On Tue, Feb 18, 2014 at 02:14:24PM -0500, Ryan X. Charles wrote: 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. Note that merge-avoidance implemented in conjunction CoinJoin doesn't have this problem - the CoinJoin'd transaction either does or doesn't confirm. Meanwhile being able to avoid merges, or more precisely, being able to be flexible with them, makes achiving good value-privacy much easier. Secondly merge-flexibility also makes cut-thru payments possible. For example BitPay can direct customers paying for goods to pay to addresses controlled by merchants and other parties who are owed money by BitPay. This skips a step, saving on transction fees as well as increasing privacy. Notably in this case the only parties that have to deal with accounting complexity are BitPay and the merchants - consumers' wallet software needs no changes beyond generic payment protocol support, and notably you can even use this technique without the payment protocol. See my post DarkWallet Best Practices for more info: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03508.html 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. What specifically do you dislike about X.509? The technical standard or the infrastructure around it? (IE the centralized authorities) -- 'peter'[:-1]@petertodd.org 51ad2df596f45df71320fb44b3c5f1b50231a591ffeb1d24 signature.asc Description: Digital signature -- 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
Any possibility of a UNIX UTC timestamp field in the customer payment message? For many transactions, the exact time of payment is when it is 'made' by the customer and not when 'requested' by the retailer or later mined. The blockchain time is an aggregate for the block and can differ significantly from transaction time so its value is limited. Small slices of time can greatly impact the transaction value. If we are ultimately taxed as a currency, an exact time will for the transaction will impact US GAAP accounting and the transaction's tax accounting. A time field may also support 'first come first served' retailer programs and time sensitive promotions. -- 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
