Re: [Bitcoin-development] Bitcoin Protocol Specification
And for translation's facility :P 2014-07-07 14:57 GMT-03:00 JMOlmos GMail : > And for translation's facility :P > > > 2014-07-02 22:21 GMT-03:00 Isidor Zeuner : > > Hello Krzysztof, >> >> [...] >> > As before, it can be found under: >> > >> > http://enetium.com/resources/Bitcoin.pdf >> > >> > I hope it will prove useful to the community and thank in advance >> > for any further improvement proposals. >> > >> >> I think it's great work and provides a good reference for those >> who want to get some insight into Bitcoin's design. >> >> Have you considered putting the document source under version control, >> which may facilitate tracking future protocol improvements in the >> document easily? >> >> Best regards, >> >> Isidor >> >> >> -- >> 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 >> > > -- 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 25, 2014, at 10:15, slush 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 16:12, Gavin Andresen 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] 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 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 10:32, slush 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] 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 > > 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 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
