Re: [Bitcoin-development] 75%/95% threshold for transaction versions
On 27 Apr 2015, at 21:21, Peter Todd p...@petertodd.org wrote: Even right now there are edge cases without good solutions, like how in a multisig environment any of the key holders can mutate transactions. Can't we add requirement for RFC6979 signatures to mitigate this? Of course, multiple signers can still mutate transaction by choosing a different set (but not the order, thankfully) of signatures. Or when a single signer has multiple participating keys. In some interesting to me scenarios mutation by signer is not critical: it is mutation by non-signers that creates a problem. Do you know of any edge cases when non-signers can mutate transactions which are not covered by BIP62? What would be a more robust approach than whack-a-mole to work around mutability? (Normalized tx ids?) -- 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] Providing Payment Request within URI
Thanks for references. Yeah, I don't need X509 signing (if I could use certificates, I wouldn't need to include PR in the URL in the first place). I presume you used BITCOIN:-payment request instead of bitcoin:?r=somescheme://payment request to make it more compact. I also tried to look up Base43, but I could not find any info on how it is specifically optimized for QR codes. Could you enlighten me? On 26 Feb 2015, at 10:32, Andreas Schildbach andr...@schildbach.de wrote: 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
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? -- 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] replace-by-fee v0.10.0rc4
On 12 Feb 2015, at 13:49, Mike Hearn m...@plan99.net wrote: If unconfirmed payments become flaky enough that people stop using them, then a portion of the Bitcoin community will find workarounds like trusted third parties, trusted hardware, whatever and will just struggle one. Other people will look at the new tradeoffs/complexity, and decide that Bitcoin is no longer better for them than banks. How about a Ripple-like IOU-based payment network that is 100% decentralized, for dumb and daily payments only? IOUs will propagate from node to node and will trusted because of a joint escrow transaction between each pair of nodes (locking up certain amount on both ends in 2-of-2 multisig). Total amount of debt from one node to another will be limited to 50% of the locked amount (e.g. if both nodes lock up $20 each, they allow debt up to $10 in each direction). When debt is reaching its limit, it's being cleared by debtor via a real BTC transaction or simply by closing the contract transaction with correct proportion on outputs to pay off the debt. Every node may require an arbitrary fee for a service of providing his funds to back IOUs, when making a payment, merchant/customer may find several possible paths and choose the quickest/cheapest one to use. Centralization is possible at a proportional capital expense. If some node wants to be Visa-scale with millions of contracts and a lot of fees to earn, they'll have to lock up huge amount of money. This puts natural limit on centralization or associated risk. Example: I pay $10. The following path is discovered and signed off by the Merchant who accepts an ad-hoc 0.3% fee: Me: $10 - $9.99 (Alice) - $9.98 (Bob) - $9.97 (Merchant). Now I owe $10 to Alice, Alice owes $9.98 to Bob, Bob owes $9.97 to Merchant. Clearing of debts happens independently between each participant based on their debt-to-capital ratio and whether any party wishes to exit. Of course, if several paths are discovered within a reasonable timeframe, Merchant will choose the cheapest one. And maybe abort transaction if the proposed path is too expensive (e.g. total fee is 1%). Pros: - Decentralized. - Mere seconds to settle a payment. - Infinite scalability (no global consensus). Each payment involves 5-7 nodes only. - No trusted parties or federation (trust is purchased using joint escrow txs on blockchain) - No funny currency, IOUs denominated in BTC. - No global consensus or protocol. Nodes can be semi-compatible, upgrade independently. All risks are local. Political problems solved: - No need to debate zeroconf transactions. We don't *need* them anymore to buy a coffee. - No need to debate block size limit. It'd still be nice to raise it when needed, but for 99% of transactions we'll have a good decentralized solution off-chain, so the issue is less pressing. Cons: - Some amount of cash needs to be locked up with random nodes most of the time. If one of the nodes is offline, payments can't be cleared through that node. Although, it could not be a big problem as the network is useful for small-ish payments and every node will have 10-15 contracts, so it will tolerate occasional unavailability of some of them. -- 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] replace-by-fee v0.10.0rc4
I think that is a misdirection on your part. The point of replace-by-fee is to make 0-confirms reliably unreliable. Currently people can get away with 0-confirms but it's only because most people arent actively double spending, and when they do it is for higher value targets. Double spend attacks are happening a lot more frequently than is being admitted here, according to Peter from work with various clients. Like single address reuse, people have gotten used to something which is bad. Generally accepting 0-conf is also a bad idea(tm) and instant confirmation solutions should be sought elsewhere. There are already interesting solutions and concepts: greenaddress for example, and CHECKLOCKTIMEVERIFY micropayment channels for example. Rather than supporting and promoting risky 0-confirms, we need to spend time on better alternative solutions that will work for everyone and not during the honeymoon phase where attackers are fewer. Here's value-free assessment of the issue here: 1. Zero-conf txs are unsafe. 2. We'd all want to have a safer instant payments solution if possible. 3. As a social artifact, today zeroconf txs happen to work for some people in some situations. 4. Replace-by-fee will break #3 and probably hasten development of #2. The discussion boils down to whether we should make #2 happen sooner by breaking remnants of #3 sooner. I personally would rather not break anything, but work as fast as possible on #2 so no matter when and how #3 becomes utterly broken, we have a better solution. This implies that I also don't want to waste time debating with Peter Todd and others. I want to be ready with a working tool when zeroconf completely fails (with that patch or for some other reasons). TL;DR: those who are against the patch are better off building a decentralized clearing network rather than wasting time on debates. When we have such network, we might all want this patch to be used for all the reasons Peter has already outlined. -- 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] Standardizing automatic pre-negotiation of transaction terms with BIP70? (Emulating Amazon one-click purchase at all merchants)
Let's say you're visiting an international webshop. But they don't ship to your country. Wouldn't you want to know that before your start filling the cart? With this, your wallet / browser extension could tell you right away that you can't shop there. No time wasted! Why my wallet has to do anything with me being in some country? The webshop may detect my location and tell me if they ship to where I'm currently in. Why should I associate more private information (my location) with my wallet than strictly necessary? Why should I automatically advertise my shipping address to every webshop without my explicit consent? The wallet must be convenient only as much as it allows for better security and privacy, but not trading off security and privacy for some unrelated convenience. -- 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