Re: [Bitcoin-development] Proposal: allocate 8 service bits for experimental use
On Tue, Jun 17, 2014 at 11:29 PM, Jeff Garzik jgar...@bitpay.com wrote: I wrote a patch for string-based name extensions, circa 2011-2012. I agree that is preferable to unreadable bits, for reasons you cite. However, it was noted that extensions (or UUIDs etc.) would not be propagated around the network in addr messages, as service bits are. Thanks for letting me know, I didn't remember your patch. Ugh, yes, propagating all extensions in `addr` messages is not how I imagined this to work. But then there would need to be an alternative way to discover nodes that offer a certain extension. Alas, this moves it from a straightforward and common sense change to a significant change to the protocol. Wladimir -- 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
Please, let's talk about other anti-double spend things on a separate thread. On Tue, Jun 17, 2014 at 5:58 PM, Isidor Zeuner cryptocurrenc...@quidecco.de wrote: What prevents the following steps from happening: I linked to Satoshi's post on this earlier, he explains why it works there, assuming people follow the original protocol rules. Your analysis holds as long as network abandons the original Bitcoin design. Obviously, we hope people won't do that. If everyone decides not to do things how Satoshi laid out then things will break, although whether we have a failure of Bitcoin at that point is debatable. -- 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] Proposal: allocate 8 service bits for experimental use
On Wed, Jun 18, 2014 at 5:23 AM, Wladimir laa...@gmail.com wrote: Anyhow -- back to the original proposal. I'm fine with setting aside part of the service bit space for experiments. ACK -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- 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
Andreas Schildbach andreas at schildbach.de writes: 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? Updated the BIP draft with an example and a few corrections (like the redundant parameter). You can see the diff here https://github.com/greenaddress/bips/commit/636d5819c1be9cc099dca0a47a3148332 522a3d4 Allow me to recap BIP changes in discussion: - making some changes to allow merchants to offer discounts in case of instant ? - allowing multiple signatures ? Did I miss anything? Thoughts on the above from others? -- 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
I think that's true if you assume that the instant provider list is based on a by hand created list of accepted instant providers. That's how VISA works now and that's why I was asking for an approach where the trusted_instant_providers list is scalable because that seems very dangerous. Supporting it in the protocol is easy. Building such a thing: that's hard. Decentralised automated reputation systems are complex and subtle. I don't feel strongly about whether the field should be optional or repeated, 100% of implementations in the forseeable future would just look at the first item and ignore the rest. But if later someone did crack this problem it would lead to a simple upgrade path. So perhaps you're right and the protobuf should allow multiple signatures. It means a new sub-message to wrap the pki_type, pki_data and signature fields into one, and then making that repeated. Up to 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
Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension
Den 17 jun 2014 17:59 skrev Isidor Zeuner cryptocurrenc...@quidecco.de: quote: Mike Hearn, why don't we just have all nodes report attempted double spends through the node network. No need to involve the miners at all really, or do your suggestion but also report the double spend attempt. By waiting maybe 10-60 seconds (instead of 10 minutes for first conf), merchants can be more sure that a double spend attack was not tried. Attacker would have to hold back second tx by 10-60 seconds and hope that that second tx (with higher fee) get's into a solved block before the first one. This forced delay time ought to make the attack less successful (but not impossible). What prevents the following steps from happening: 1. attacker sends first transaction, paying to the merchant 2. merchant waits 10-60 seconds 3. merchant confirms the payment as received 4. attacker sees merchant's confirmation 5. attacker sends double spend The security improvement seems to be pretty much exactly the chance that during the 10-60 seconds, a block is solved. Am I missing something? Regarding reporting double spends, this would only help if it comes with some kind of penalty for the double spend. Now what if the double spend was not done on malicious motives? Maybe someone posted a transaction which does not confirm for some reason, and wants to recover his funds? Should we regard transactions which do not confirm as forever lost, in order to get to an every double spend is a misbehaviour policy? Best regards, Isidor With 2-of-2 multisignature notaries, the doublespend (the set of conflicting transactions) would be published and propagated together as evidence of the notary being malicious. This is trivial and self-evident self-contained proof. But there should be no direct penalty IMHO in the Bitcoin protocol itself. If a transaction would have to be replaced honestly because of being wrong or simply not confirming, then I think there should be some means of showing the second transaction is legitimate. Don't ask me how exactly it would work in practice, but one method could be through showing the original recipients have signed off on it (showing they agree it should be reversed). If you can't get the original recipient to sign, then you're stuck with either not replacing it or the notary trying to prove the replacing transaction was legitimate. -- 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] 0 confirmation txs using replace-by-fee and game theory
quote: [...] On 4/24/14, Chris Pacia ctpa...@gmail.com wrote: It would work but it's an ugly hack IMO. What do people do if they don't have extra to pay when making a purchase? I have 200 mbtc and want to buy a 200 mbtc phone but I can't because I need 400 mbtc. Sucks for me. I would much prefer the hassle of a green address notary than always having to make sure I have double what I need to make a purchase. This scheme wouldn't be mandatory. You can still wait for confirmations or rely somehow on existing trust instead if that's better for you on that situation. Considering hotel or car rental payments where the credit card processor reserves a higher amount in order to cover risks, it doesn't seem like anything new or particularly inconvenient that a payment system may require a larger amount than the final price being available. Which brings us to the question: Is it an important characteristic in a payment system that it is capable of quickly spending your last penny? Best regards, Isidor -- 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
