[Bitcoin-development] Bitcoin core 0.11.0 release candidate 1 available
Hello, I've just uploaded Bitcoin Core 0.11.0rc1 executables to: https://bitcoin.org/bin/bitcoin-core-0.11.0/test/ The source code can be found in the source tarball or in git under the tag 'v0.11.0rc1' Preliminary release notes can be found here: https://github.com/bitcoin/bitcoin/blob/0.11/doc/release-notes.md Thanks to everyone that participated in development or in the gitian build process, Wladimir -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Meta suggestions for this block size debate
Gabe, Did you ever get an answer to this? Ill have some time tomorrow to be able to help with some work on this and will need to do it myself anyways since I'm not sure I understand the nuances, where bitcoin XT fits into the scheme of things (or not) etc. I would have thought that there would be a testnet4 by now using 8mb blocks... but hey that's just me. p. On Tue, Jun 2, 2015 at 11:52 AM, gabe appleton gapplet...@gmail.com wrote: I don't have permission to create a page. If someone else does, I'll happily get a framework started. On Mon, Jun 1, 2015 at 11:32 PM, Ethan Heilman eth...@gmail.com wrote: I second this, I don't have time to read the large number of emails generated every day from the block size debate. A summary of the various positions and arguments would be extremely helpful. On Mon, Jun 1, 2015 at 11:02 PM, gabe appleton gapplet...@gmail.com wrote: Also, can we try to get a wiki page for the debate? That way we could condense the information as much as possible. I'll be willing to assist if the page gets approval. On Jun 1, 2015 6:41 PM, Mats Henricson m...@henricson.se wrote: Hi! My fingers have been itching many times now, this debate drives me nuts. I just wish all posters could follow two simple principles: 1. Read up. Yes. All of what has been written. Yes, it will take many hours. But if you're rehashing what other smarter people have said over and over before, you're wasting hundreds of peoples time. Please don't. 2. Be helpful. Suggest alternatives. Just cristizising is just destructive. If you want no change, then say so. Mats -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [RFC] Canonical input and output ordering in transactions
Rusty, this doesn't play well with SIGHASH_SINGLE which is used in assurance contracts among other things. Sometimes the ordering is set by the signing logic itself... On Jun 5, 2015 9:43 PM, Rusty Russell ru...@rustcorp.com.au wrote: Title: Canonical Input and Output Ordering Author: Rusty Russell ru...@rustcorp.com.au Discussions-To: Bitcoin Dev bitcoin-development@lists.sourceforge.net Status: Draft Type: Standards Track Created: 2015-06-06 Abstract This BIP provides a canonical ordering of inputs and outputs when creating transactions. Motivation Most bitcoin wallet implementations randomize the outputs of transactions they create to avoid trivial linkage analysis (especially change outputs), however implementations have made mistakes in this area in the past. Using a canonical ordering has the same effect, but is simpler, more obvious if incorrect, and can eventually be enforced by IsStandard() and even a soft-fork to enforce it. Specification Inputs should be ordered like so: index (lower value first) txid (little endian order, lower byte first) Outputs should be ordered like so: amount (lower value first) script (starting from first byte, lower byte first, shorter wins) Rationale Any single wallet is already free to implement this, but if other wallets do not it would reduce privacy by making those transactions stand out. Thus a BIP is appropriate, especially if this were to become an IsStandard() rule once widely adopted. Because integers are fast to compare, they're sorted first, before the lexographical ordering. The other input fields do not influence the sort order, as any valid transactions cannot have two inputs with the same index and txid. Reference Implementation https://github.com/rustyrussell/bitcoin/tree/bip-in-out-ordering -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] [RFC] Canonical input and output ordering in transactions
Title: Canonical Input and Output Ordering Author: Rusty Russell ru...@rustcorp.com.au Discussions-To: Bitcoin Dev bitcoin-development@lists.sourceforge.net Status: Draft Type: Standards Track Created: 2015-06-06 Abstract This BIP provides a canonical ordering of inputs and outputs when creating transactions. Motivation Most bitcoin wallet implementations randomize the outputs of transactions they create to avoid trivial linkage analysis (especially change outputs), however implementations have made mistakes in this area in the past. Using a canonical ordering has the same effect, but is simpler, more obvious if incorrect, and can eventually be enforced by IsStandard() and even a soft-fork to enforce it. Specification Inputs should be ordered like so: index (lower value first) txid (little endian order, lower byte first) Outputs should be ordered like so: amount (lower value first) script (starting from first byte, lower byte first, shorter wins) Rationale Any single wallet is already free to implement this, but if other wallets do not it would reduce privacy by making those transactions stand out. Thus a BIP is appropriate, especially if this were to become an IsStandard() rule once widely adopted. Because integers are fast to compare, they're sorted first, before the lexographical ordering. The other input fields do not influence the sort order, as any valid transactions cannot have two inputs with the same index and txid. Reference Implementation https://github.com/rustyrussell/bitcoin/tree/bip-in-out-ordering -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
