Re: [Bitcoin-development] Proposed BIP 70 extension
On Jun 25, 2014, at 10:15, slush sl...@centrum.cz wrote: Good standard must be explicit as much as possible. Having million optional fields with ambiguous meaning is even worse than not having these fields. +1. BIP70 is important. We want to keep it very simple and generalized, or there is a very real risk that implementers will either not bother with it or implement it in buggy, poorly standardized ways. Any information not required by the machine should only exist in human-oriented fields (namely, the memo field). Let's try to avoid ending up with another horrendously complicated, edge-case-oriented protocol like we programmers frequently complain about. smime.p7s Description: S/MIME cryptographic signature -- 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] Proposed BIP 70 extension
On Jun 24, 2014, at 10:32, slush sl...@centrum.cz wrote: Sounds like marketing bullshit to me. It does not have even statistical meaning; well, you can save a lot of satoshis, but nobody tell you that the merchant cut you on BTC/USD exchange rate in tens of %. People would also abuse this feature in the same way amazon (and other sales sites) abuse the definition of save. For example, Amazon will indicate that you're getting x% off by shopping at amazon, but all that number really means is x% off MSRP. In reality, every website has the same price. I have no doubt that merchants would put similarly meaningless and/or misleading data in this field. I agree, the memo field is appropriate for this data. smime.p7s Description: S/MIME cryptographic signature -- 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] Proposed BIP 70 extension
Ok, wanting structured data is a decent argument, but why this random arbitrary case in particular? There are hundreds of fields like this that people might want to use. If we're going to support one random cosmetic field, we might as well support them all with a generic structured data format. I'd rather we just didn't have this essentially pointless feature at all. Let's try and keep as much cruft as possible out of the payment protocol. The textual memo field is already more than sufficient. On Jun 24, 2014, at 11:48, Jeff Garzik jgar...@bitpay.com wrote: I think there is nothing wrong with having a numeric memo field, which is effectively what this is. Structured rather than unstructured data. smime.p7s Description: S/MIME cryptographic signature -- 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] Proposed BIP 70 extension
On Jun 24, 2014, at 16:12, Gavin Andresen gavinandre...@gmail.com wrote: It would be silly to add a generic stuff field inside a container format that ALREADY has all the mechanisms necessary for forwards and backwards extensibility. I agree. It would be even sillier to start specifying container formats for random one-off that would be kind of nice, I guess features. How about exchange rate? Sharing links? Referral information? Any of these things are just as deserving of specification (and just as arbitrary). smime.p7s Description: S/MIME cryptographic signature -- 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] Why are we bleeding nodes?
Unlikely. I doubt any significant portion of miners in china will continue to mine on a china-specific chain, since it will certainly be outmined by non-Chinese miners, and will be orphaned eventually. More likely is that mining interests in china will make special arrangements to circumvent the GFwOC. Users who can't access the worldwide blockchain will notice horrendously slow confirmation times and other side effects. On May 20, 2014, at 10:37, Eugen Leitl eu...@leitl.org Could a blockchain fork due to network split happen? smime.p7s Description: S/MIME cryptographic signature -- 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] Bitcoin Fee Formula Proposal
What about 0 confirmation inputs? Mightn't this make tiny spam transactions unsafely inexpensive? On May 12, 2014, at 20:21, Peter Grigor pe...@grigor.ws wrote: I propose the transaction fee should be calculated from a percentage of the input amount divided by the confirmations of the input multiplied by the number of inputs. smime.p7s Description: S/MIME cryptographic signature -- 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] bits: Unit of account
People in the Bitcoin community are sometimes resistant to the idea of using the word credit as a unit of Bitcoin, because Bitcoin is not a credit-based system. However, given that the average person has close to no understanding of what credit means, and probably no concern for the distinction even if they do know, it may be wise to use the futuristic and easily understandable credit as our human-friendly unit. Do others agree that credits as a unit of account has a desirable futuristic connotation? Will smime.p7s Description: S/MIME cryptographic signature -- 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/NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
