Re: [Bitcoin-development] Why are we bleeding nodes?
Multi-sig requires infrastructure. It isn't a magic wand that we can wave to make everyone secure. The protocols and techniques necessary don't exist yet, and apparently no one has much of an incentive to create them. I mean no offense, and I don't mean to pick on you. Your post stuck out while I was reading. Secure multi-sig is what we all want, but wanting apparently isn't enough to make it happen. Other random notes from reading this 50+ post thread: Perhaps we should have a config flag to prevent a node from serving IBD to new nodes. IBD crushes marginal machines, particularly those with spinning disks. This has been extensively discussed elsewhere. The ideal IBD hosts are serving the blockchain out of a RAM disk. Is there any interest in setting up a network of volunteers to host expensive servers with fast connections? It doesn't look too terribly difficult to figure out when a node has stopped asking for blocks in bulk, so we could add another config flag to eject nodes once they are done booting. Even ignoring IBD, I think that we are gradually outgrowing cheapass hosting options. Personally, I long ago gave up on answering forum questions about running nodes on virtual servers and VPSs. It is certainly still possible to run bitcoind on small boxes, but it isn't trivial any more. (Anyone running on less than my Athlon XP 1800+ with 896 MB RAM?) If we want those nodes back, we need to optimize the hell out of the memory use, and even that might not be enough. Eric Martindale wrote: We need to make it so mind-numbingly simple to run Bitcoin correctly that the average user doesn't find reasons to do so in the course of normal use. Right now, Coinbase and Bitstamp are winning in the user experience battle, which technically endanger the user, and by proxy the Bitcoin network. Multi-sig as a default is a start. It won't succeed unless the user experience is simply better than trusted third parties, but we need to start the education process with the very basic fundamental: trusting a third-party with full access to your Bitcoin is just replacing one centralized banking system with another. -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Finite monetary supply for Bitcoin
Matt Whitlock wrote: The creation date in your BIP header has the wrong format. It should be 01-04-2014, per BIP 1. At first, I thought this was a second April Fool's joke, but then I looked and saw that all of the BIPs really do use this format. As far as I can tell, we are using this insane format because RFC 822 predates ISO 8601 by half a decade. Since we don't have half a gajillion mail servers to patch, we could, if we desired, adopt a sensible date format here. The cost to the community would be minimal, with probably not more than a half dozen people needing to update scripts. It could even be as simple as one guy running sed s/parseabomination/parsedate/g -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Multisign payment protocol?
I was trying to use bip10 for multisig and coinjoin, but there was a problem with it. I'll have to look back at my notes, but I thought I sent you a message about it. And then real life swallowed my bitcoin time... I think the bottom line was that it would be useful in the generic case with just one minor change. If there is interest, and it sounds like there just may be, I can dust off my notes and see where I left it. Probably should do it soon before someone implements it in PB or XML. Alan Reiner wrote: Then of course I tried to do this with BIP 10 https://github.com/bitcoin/bips/blob/master/bip-0010.mediawiki when Armory implemented offline-transactions two years ago. I got some positive feedback, but no one wanted to help improve it, etc. I guess nobody else was doing it and/or cared at the time. So I continue to use BIP 10 even though it's pretty crappy. I wanted it to be useful for multisig, too, but it has some deficiencies there (it was done when Armory was extremely young and OP_EVAL was still on the table). However, with all this activity, we should start thinking about that and discussing it. Otherwise, I'll just do my own thing again and probably end up with something that fits my own needs, but not anyone else's. Really though, multisig shouldn't require all the same app to work. -Alan On 03/10/2014 01:49 PM, Gavin Andresen wrote: In my experience, best process for standardizing something is: 1) Somebody has a great idea 2) They implement it 3) Everybody agrees, Great idea! and they copy it. 4) Idea gets refined by the people copying it. 5) It gets standardized. Mutisig wallets are at step 2 right now. BIP is step 5, in my humble opinion... On Mon, Mar 10, 2014 at 1:39 PM, Drak d...@zikula.org mailto:d...@zikula.org wrote: I was wondering if there would be merit in a kind of BIP for a payment protocol using multisig? Currently, setting up a multisig is quite a feat. Users have to exchange public keys, work out how to get the public keys from their addresses. If one of the parties are not savvy enough, an malicious party could easily be setup that was 2 of 3 instead of 2 of 2 where the malicious party generates the multisig address+script and thus be able to run off with funds anyway. It's also terribly complex to generate and keep track of. There's been a nice attempt at creating an browser interface at coinb.in/multisig http://coinb.in/multisig but it still lacks the kind of ease with created by the payment protocol. If there was a BIP then it would go a long way to aiding future usability of multisig wallet implementations. What are your thoughts? Drak -- 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/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net mailto:Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- -- Gavin Andresen -- 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/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- 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/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- 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/13534_NeoTech___ Bitcoin-development mailing list
Re: [Bitcoin-development] Bitcoin-development Digest, Vol 31, Issue 25
Ryan Carboni wrote: And the economic parameters of bitcoin are not fixed in stone. If there needs to be a change, it will be messy but it could happen. Need is an awfully big word. One thing we are certain of is that some guy telling us all that we are wrong is nowhere near the need level. Besides, using Austrian precepts of inflation blurs the fact that deflation will still be possible under my proposal. Although amusingly enough Austrian-defined inflation is still occurring within Bitcoin, in fact faster then desired since blocks are being processed every seven minutes now as opposed to ten, and it's quite likely when 28nm ASIC miners are released that blocks will be processed every five minutes before the difficulty is adjusted again. Don't take this the wrong way, but things like this make it very hard for us to take you seriously. Please read up on how the system works, then read up on why we reject the argument from authority, then if you still have something to say, please do so in a proper venue. One option for this discussion is the bitcointalk.org forums, where you will find literally dozens of threads proposing the exact same thing you are proposing. This mailing list is NOT for political discussion. -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Monetary Authority for Bitcoin
Ryan Carboni wrote: Bitcoin lacks a Central Bank. This is a feature, not a bug. Also, this is offtopic. Political debate is thataway -. bitcoin-development is for development and technical discussion. -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Floating fees and SPV clients
After reading all 99 messages in this thread, I think allowfee is just about perfect. It effectively lets merchants to give an allowance against the purchase price for network fees, if they choose. It is still up to the sender (and/or the sender's software) to get the fees right. Sometimes the sender will need to pay more fees than allowed, and sometimes the sender will need to pay less. We can't solve the fee problem, in general. I'm not sure that we can even define it properly. But this is something that we can do, that will be useful at least occasionally, and that will cause no harm the rest of the time. P.S. Clever senders can use this to defrag their wallets. Who wants to write the patch for that? Gavin Andresen wrote: On Tue, Dec 3, 2013 at 12:44 AM, Mike Hearn m...@plan99.net mailto:m...@plan99.net wrote: PPv1 doesn't have any notion of fee unfortunately. I suppose it could be added easily, but we also need to launch the existing feature set. Lets bang out a merchant-pays-fee extension. How about: SPEC: optional uint64 allowfeetag number=1000 Allow up to allowfee satoshis to be deducted from the amount paid to be used to pay Bitcoin network transaction fees. A wallet implementation must not reduce the amount paid for fees more than allowfee, and transaction fees must be equal to or greater than the amount reduced. :ENDSPEC Rationale: we don't want wallet software giving users discounts-- sending transactions that are amount-allowfee without paying any fee. We also want to allow users to pay MORE in fees, if they need to (fragmented wallet, maybe, or big CoinJoin transaction) or decide to. PS: I think there was also consensus that the BIP72 request=... should be shortened to just r=... (save 6 chars in QR codes). Unless somebody objects, I'll change the BIP and the reference implementation code to make it so... -- -- Gavin Andresen -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Feedback requested: reject p2p message
Any reason not to use actual HTTP codes? I'm not aware of any major deficiency in them. Most of them won't apply to us, which is fine, they don't seem to apply to HTTP either. We can extend the scheme on our own if we find a good reason to. That implies 16 bits, or a varint. I would avoid a string or varstring here; we already have a text field. Varint vs. 16 bits is a minor issue, and arguments can be made in both directions. I flipped a coin and got heads, so I'll say varint. Gavin Andresen wrote: RE: use HTTP-like status codes: Okey dokey, I'll add a one-byte machine-readable HTTP-like status code. Unless y'all want a 32-bit status code. Or maybe a varint. Or a three-character numeric string. I really and truly don't care, but I am writing this code right now so whatever you want, decide quickly. If anybody has strong feelings about what the reject categories should be, then please take the time to write a specific list, I can't read your mind -- -- Gavin Andresen -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Feedback requested: reject p2p message
The HTTP status code system seems to work well enough, and seems to give the best of both worlds. A 3 digit numeric code that is machine-readable, and a freeform text note for humans. The clever part about that system was in realizing that the numeric codes didn't need to account for every possible error. They just need to give the other node the most useful information, like try that again later, I'm having a temporary problem vs. That is just plain wrong and it will still be wrong next time too, so don't bother to retry. We can leave it to the humans to puzzle out the meaning of 403: values of txid gives rise to dom! Gavin wrote: On Oct 26, 2013, at 11:01 AM, Jean-Paul Kogelman jeanpaulkogel...@me.com wrote: Would it make sense to use either fixed length strings or maybe even enums? No. Enums or fixed length strings just make it harder to extend, for no benefit (bandwidth of 'reject' messages doesn't matter, they will be rare and are not relayed). -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
