[Bitcoin-development] Working on social contracts (was: Paper Currency)
On Mon, May 19, 2014 at 2:20 PM, Justus Ranvier wrote: > > You and Gavin could do a lot better by working on a Bitcoin social > contract - a promise of what features will *never* be added (or taken > away) from Bitcoin, because despite what you say it's not acceptable > to propose anything at all. > Now I'm really confused. Why would Mike or I have the authority to write a "social contract" to promise anything about future-Bitcoin? I thought the only "social contract" was the decentralized one we have already-- if you don't like something about the code, then don't download and run it. Or fork it if you're able. As the person who started this mailing list, I DO feel like I have the authority to enforce a social contract of "no trolling or flaming or name-calling" here. I'd very much like to delegate that authority, though; ideally to some software algorithm that automatically censors topics or people who don't contribute to a productive discussion. PS: speaking of productive discussion... ... please change the Subject line when the topic wanders. -- -- Gavin Andresen -- "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] Working on social contracts (was: Paper Currency)
Okey dokey: I hereby promise and solemnly swear on pain of atomic wedgie that I will never ever work on or endorse any changes to the Bitcoin system that would enable any person or group to confiscate, blacklist, or devalue any other person or group's bitcoin. RE: writing an RFC: go for it. I have much higher tasks on my TODO list. -- -- Gavin Andresen -- "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
[Bitcoin-development] Proposal: relax the IsStandard rules for P2SH transactions
Assuming there is rough consensus, I'll make this a pull request (see https://github.com/gavinandresen/bitcoin-git/tree/relax_isstandard for code changes). Now that we are finally starting to see the use of multi-signature and other more complicated transaction forms in applications I think it is time to open up the "IsStandard" transaction rules on the main Bitcoin network. There are two main risks to doing this: 1. The risk that one of the seldom-used opcodes has a not-yet-discovered chain-forking bug. I believe that risk to be very low; we have never seen such a bug on the test network (where all transaction forms are allowed) and have never found a bug after writing extensive unit tests. 2. The risk of opening up a denial-of-service attack (either bloat the blockchain or use an excessive amount of CPU time) via a very expensive-to-store-or-verify transaction. This proposal does not entirely eliminate IsStandard checks to mitigate the potential for DoS attacks. Proposal Allow any Script containing 15 or fewer signature operations as a pay-to-script-hash (P2SH) Script to be relayed and mined by the reference implementation. This should be a simple change to the AreInputsStandard() method in the reference implementation. Discussion -- P2SH Scripts are limited to 520 bytes, and are currently limited to one of the "standard" transaction forms on the main network. In practice that means you can currently encode a n-of-15 OP_CHECKMULTISIG which can be redeemed as a 'standard' transaction. Allowing any P2SH Script would allow an attacker to craft a single standard transaction output that requires on the order of 200 ECDSA signature checking operations to validate-- an order of magnitude more than is currently allowed. Therefore I am proposing that we keep the current 15-signature-checking-operations-per-transaction-output limit in place, but allow any combination of enabled Script opcodes. So, for example, you might have a P2SH Script that is redeemed with 2-of-2 OR 2-of-3 using: ``` OP_IF 2 pubkey1 pubkey2 2 OP_CHECKMULTISIG OP_ELSE 2 pubkey3 pubkey4 pubkey5 3 OP_CHECKMULTISIG OP_ENDIF ``` (this would count as 5 signature operations) Restricting arbitrary Scripts to P2SH transaction types limits unspent transaction output set bloat in two ways: 1. The Scripts are not stored in UTXO set. 2. They are limited to 520 bytes by the Script rule on the amount of data that can be pushed onto the stack. The reference implementation's wallet will still only recognize P2SH transactions that use one of the standard transaction forms. To actually USE a new transaction form will require specialized wallets or specialized applications. -- -- Gavin Andresen Chief Scientist, Bitcoin Foundation https://www.bitcoinfoundation.org/ -- 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: relax the IsStandard rules for P2SH transactions
RE: most of Peter Todd's comments: All of that should be separate pull requests. Big Honking Pull Requests are harder to review and are more likely to be bike-shedded to death. RE: not relaying/mining transactions with OP_NOPs so miners don't mine up-version transactions that are invalid under future-new-rules: I'm not convinced it is worth adding more code (more potential for bugs) to protect against something that isn't going to happen because up-version transactions are non-standard (due to version check) in any case. In any case, lets make that a separate pull request. I'm going to take the lack of immediate "That's a Terrible Idea!" as rough consensus... -- -- Gavin Andresen Chief Scientist, Bitcoin Foundation https://www.bitcoinfoundation.org/ -- 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: relax the IsStandard rules for P2SH transactions
RE: soft-forks bumping version numbers: Yes, we have consensus that is the way we will do it. I should probably turn https://gist.github.com/gavinandresen/2355445 into an informational BIP. RE: malleability: Orthogonal (but related) issue to IsStandard. Detecting Scripts that leave extra items on the stack will be done in a different part of the code than the code addressed by this pull reques. No need to execute the Script twice to figure out if it leaves extra stuff, and the idea behind IsStandard is to get to a quick yes/no before running a potentially expensive Script execution. -- -- Gavin Andresen Chief Scientist, Bitcoin Foundation https://www.bitcoinfoundation.org/ -- 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] Proposed BIP 70 extension
On Tue, Jun 24, 2014 at 3:00 PM, Gmail wrote: > 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. > Protocol buffers are designed to be extensible, and there are hundreds of field numbers available. 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. -- -- Gavin Andresen -- 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
[Bitcoin-development] Building from git on OSX
Just FYI for anybody else building on OSX: libtool is a new dependency, so if you update to git HEAD and have trouble building: brew install libtool (or port install libtool -- see doc/build-osx.md for all the dependencies) ./autogen.sh ./configure etc, whatever configure options you use. I develop with: ./configure --disable-hardening --disable-silent-rules CXXFLAGS='-g3 -O0 -DDEBUG_LOCKORDER' -- -- Gavin Andresen -- 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] Squashing redundant tx data in blocks on the wire
A couple of half-baked thoughts: On Thu, Jul 17, 2014 at 5:35 PM, Kaz Wesley wrote: > If there's support for this proposal, I can begin working on the specific > implementation details, such as the bloom filters, message format, and > capability advertisment, and draft a BIP once I have a concrete proposal > for > what those would look like and a corresponding precise cost/benefit > analysis. > I'd encourage you to code up a prototype first (or at the same time), in whatever programming language / networking library you're most familiar with. Maybe not even using the existing p2p protocol; there could be a mining-only very-fast-block-propagation network separate from the existing p2p network. Combining your optimizations with "broadcast as many near-miss blocks as bandwidth will allow" on a mining backbone network should allow insanely fast propagation of most newly solved blocks. -- -- Gavin Andresen -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Squashing redundant tx data in blocks on the wire
Two more half-baked thoughts:
We should be able to assume that the majority of transaction data (except
for coinbase) has already been propagated. As Jeff said, incentivizing
nodes to propagate transactions is a very good thing (the signature cache
already gives a small incentive to miners to propagate and not 'hoard'
transactions).
So the only information that theoretically needs to be propagated is which
transactions a miner is including in their block, and in what order they
are included.
But if there was some agreed-upon canonical ordering, then it should
theoretically be possible to take shortcuts in the "what order".
You'd start with setof(transactions I think everybody knows about)
Select some subset, based on miner's policy
Sort that subset with the canonical ordering algorithm
Very efficiently broadcast, taking all sorts of shortcuts assuming most of
your peers already know the set you started with and expect the same
canonical ordering (see gmaxwell's thoughts on block encoding).
Second half-baked thought:
I wonder if broadcasting your transaction selection policy ("11KB of free
transactions, sorted by priority, then 111K of fee-paying transactions,
sorted by fee") might make it possible to save even more bandwidth by
letting your peers create a very good approximation of your block with just
that information
--
--
Gavin Andresen
--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time
Very nice, semantics are clear and use cases are compelling. Can we defer discussion of how to roll this out for a little bit, and see if there is consensus that: a) benefits of having this outweigh risks b) we're all happy with exact semantics Then we can have a knock-down drag-out argument about whether it should roll out as a soft fork, wait for a hard fork, be combined with some other things that it would be nice to add or change, etc. -- -- Gavin Andresen -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time
On Wed, Oct 1, 2014 at 2:23 PM, Luke Dashjr wrote: > houghts on some way to have the stack item be incremented by the height at > which the scriptPubKey was in a block? A limitation of encoding the target > height/time directly, is that miners may choose not to mine the first > transaction until they can also take the "burn to fee". > If the first transaction is P2SH, then the miner won't know there is an advantage to holding it until it is too late (the scriptPubKey is an opaque hash until the second transaction is final and relayed/broadcast). -- -- Gavin Andresen -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time
On Wed, Oct 1, 2014 at 5:04 PM, Alan Reiner wrote: > On 10/01/2014 04:58 PM, Gavin Andresen wrote: > > If the first transaction is P2SH, then the miner won't know there is > > an advantage to holding it until it is too late (the scriptPubKey is > > an opaque hash until the second transaction is final and > > relayed/broadcast). > > If you're doing some kind of proof-of-burn scheme, wouldn't using P2SH > defeat the purpose of it? > No, the burner would supply the funding transaction plus the redeeming script as the proof-of-burn to whoever needed the proof. Only after at least one confirmation, if there was some risk that revealing the redeeming script would make miners refuse to mine that first transaction because they want to get it plus the CHECKTIMELOCKVERIFY "burn" transaction. -- -- Gavin Andresen -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time
On Sat, Oct 4, 2014 at 8:58 AM, Mike Hearn wrote: > >> Meanwhile, what I said *is* correct. New version numbers result in only > a log print. Being hard forked off results in both log prints *and* the > -alertnotify being run: > That is easy to change; I'll submit a pull request. It is a good idea to get an -alertnotify sooner rather than later for EITHER a hard fork or a soft-fork. Better to be told you have to upgrade while the block.version is on its way to being a super-majority than after you are either hard-forked off the main chain (or soft-forked). I don't have any opinion on the hard- versus soft- fork debate. I think either can work. -- -- Gavin Andresen -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP process
RE: process: I like author == primary control, and an "assume they will do the right thing, revert if they don't" RE: separate mailing list for BIP discussion: Great idea. Jeff Garzik was looking for a better mailing list solution than SourceForge, but assuming there isn't a clearly better solution I think "we" should create a strictly moderated bitcoin-bips@lists.sourceforge list. -- -- Gavin Andresen -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] death by halving
We had a halving, and it was a non-event. Is there some reason to believe next time will be different? -- -- Gavin Andresen -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Reworking the policy estimation code (fee estimates)
I think Alex's approach is better; I don't think we can know how much better until we have a functioning fee market. We don't have a functioning fee market now, because fees are hard-coded. So we get "pay the hard-coded fee and you'll get confirmed in one or two or three blocks, depending on which miners mine the next three blocks and what time of day it is." git HEAD code says you need a fee of 10, satoshis/kb to be pretty sure you'll get confirmed in the next block. That looks about right with Alex's real-world data (if we take "90% chance" as 'pretty sure you'll get confirmed'): Fee rate 10 Avg blocks to confirm 1.09 NumBlocks:% confirmed 1: 0.901 2: 1.0 3: 1.0 My only concern with Alex's code is that it takes much longer to get 'primed' -- Alex, if I started with no data about fees, how long would it take to be able to get enough data for a reasonable estimate of "what is the least I can pay and still be 90% sure I get confirmed in 20 blocks" ? Hours? Days? Weeks? -- -- Gavin Andresen -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Reworking the policy estimation code (fee estimates)
On Tue, Oct 28, 2014 at 10:30 AM, Alex Morcos wrote: > > Do you think it would make sense to make that 90% number an argument to > rpc call? For instance there could be a default (I would use 80%) but then > you could specify if you required a different certainty. It wouldn't > require any code changes and might make it easier for people to build more > complicated logic on top of it. > RE: 80% versus 90% : I think a default of 80% will get us a lot of "the fee estimation logic is broken, I want my transactions to confirm quick and a lot of them aren't confirming for 2 or 3 blocks." RE: RPC argument: I'm reluctant to give too many 'knobs' for the RPC interface. I think the default percentage makes sense as a command-line/bitcoin.conf option; I can imagine services that want to save on fees running with -estimatefeethreshold=0.5 (or -estimatefeethreshold=0.95 if as-fast-as-possible confirmations are needed). Setting both the number of confirmations and the estimation threshold on a transaction-by-transaction basis seems like overkill to me. -- -- Gavin Andresen -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP62 and future script upgrades
On Tue, Nov 4, 2014 at 8:29 AM, Pieter Wuille wrote: > Luke suggested on the pull request to not apply this rule on every > transaction with nVersion >= 3, which indeed solves the problem. I > believe this can easily be generalized: make the (non mandatory) BIP62 > rules only apply to transaction with strict nVersion==3, and not to > higher ones. > I agree; soft-forking is a useful way of rolling out upgrades, we shouldn't prohibit it. -- -- Gavin Andresen -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Serialised P2SH HD chains
On Thu, Dec 4, 2014 at 10:42 AM, Luke Dashjr wrote: > Is anyone working on a serialisation format to convey P2SH HD chains? For > example, > to give someone who wants to make recurring payments a single token that > can be used to generate many P2SH addresses paying to a multisig script. Seems like the wrong approach to me, because in practice you really need a reasonable expiration date or some way of determining that whatever you are paying is still around (I still get random transactions to the Bitcoin Faucet's old addresses). See the discussion from January about extending the payment protocol for recurring transactions: https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03823.html "Give them a single token" == "give them a recurring PaymentRequest" in my mind. Or maybe "Give them a URL where they can fetch PaymentRequests whenever they need to make a payment" or maybe "Give them an array of PaymentRequests for the next X days/months/years of payments." -- -- Gavin Andresen -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP70: why Google Protocol Buffers for encoding?
On Mon, Jan 19, 2015 at 3:40 PM, Mike Hearn wrote: > OK, I guess we can boil this down more simply. BIP 70 uses protocol >> buffers because I designed it and implemented the original prototype (with >> lots of input from Gavin and an earlier proposal by sipa). I used protocol >> buffers because, beyond all their nice properties, I used to work at Google >> and so was very familiar with them. >> > What Mike said. Runner-up for encoding was JSON. XML+ASN.1 was Right Out, because lots of us hate XML and ASN.1 with a burning passion. Complexity is the Enemy of Security, and both XML and ASN.1 are too complex. -- -- Gavin Andresen Chief Scientist, Bitcoin Foundation https://www.bitcoinfoundation.org/ -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [softfork proposal] Strict DER signatures
DERSIG BIP looks great to me, just a few nit-picky changes suggested: You mention the "DER standard" : should link to http://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf (or whatever is best reference for DER). "this would simplify avoiding OpenSSL in consensus implementations" --> "this would make it easier for non-OpenSSL implementations" "causing opcode failure" : I know what you mean by "opcode failure", but it might be good to be more explicit. "since v0.8.0, and nearly no transactions" --> "and very few transactions..." "reducing this avenue for malleability is useful on itself as well" : awkward English. How about just "This proposal has the added benefit of reducing transaction malleability (see BIP62)." -- -- Gavin Andresen -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New BIP: protocol for multisignature payments
I agree- standards should be descriptive ("here is how this thing I did
works") and NOT proscriptive ("here's what I think will work, lets all try
to do it this way.").
On Sat, Jan 31, 2015 at 2:07 PM, Mike Hearn wrote:
> I could look at implementing it someday, but now I'd like to receive
>> feedback from community.
>>
>
> IMO it's better to pair a protocol spec with an implementation.
>
--
--
Gavin Andresen
--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [softfork proposal] Strict DER signatures
I think we should just do it, and include it with the other DERSIG changes for 0.10. On Tue, Feb 3, 2015 at 1:15 PM, Pieter Wuille wrote: > > I understand it's late, which is also why I ask for opinions. It's > also not a priority, but if we release 0.10 without, it will first > need a cycle of making this non-standard, and then in a further > release doing a second softfork to enforce it. > > It's a 2-line change; see #5743. > > -- > Pieter > > -- -- Gavin Andresen -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Block Size Increase
For reference: the blog post that (re)-started this debate, and which links to individual issues, is here: http://gavinandresen.ninja/time-to-roll-out-bigger-blocks In it, I asked people to email me objections I might have missed. I would still appreciate it if people do that; it is impossible to keep up with this mailing list, /r/bitcoin posts and comments, and #bitcoin-wizards and also have time to respond thoughtfully to the objections raised. I would very much like to find some concrete course of action that we can come to consensus on. Some compromise so we can tell entrepreneurs "THIS is how much transaction volume the main Bitcoin blockchain will be able to support over the next eleven years." I've been pretty clear on what I think is a reasonable compromise (a one-time increase scheduled for early next year), and I have tried to explain why I think it it is the right set of tradeoffs. There ARE tradeoffs here, and the hard question is what process do we use to decide those tradeoffs? How do we come to consensus? Is it worth my time to spend hours responding thoughtfully to every new objection raised here, or will the same thing happen that happened last year and the year before-- everybody eventually gets tired of arguing angels-dancing-on-the-head-of-a-pin, and we're left with the status quo? I AM considering contributing some version of the bigger blocksize-limit hard-fork patch to the Bitcoin-Xt fork (probably "target a hobbyist with a fast Internet connection, and assume Nelson's law to increase over time), and then encouraging merchants and exchanges and web wallets and individuals who think it strikes a reasonable balance to run it. And then, assuming it became a super-majority of nodes on the network, encourage miners to roll out a soft-fork to start producing bigger blocks and eventually trigger the hard fork. Because ultimately consensus comes down to what software people choose to run. -- -- Gavin Andresen -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Block Size Increase
Fee dynamics seems to come up over and over again in these discussions, with lots of talk and theorizing. I hope some data on what is happening with fees right now might help, so I wrote another blog post (with graphs, which can't be done in a mailing list post): http://gavinandresen.ninja/the-myth-of-not-full-blocks We don’t need 100% full one megabyte blocks to start to learn about what is likely to happen as transaction volume rises and/or the one megabyte block size limit is raised. -- -- Gavin Andresen -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Fwd: Block Size Increase
On Thu, May 7, 2015 at 1:26 PM, Matt Corallo wrote: > I think this is a huge issue. You've been wandering around telling > people that the blocksize will increase soon for months I think the strongest thing I've ever said is: "There is consensus that the max block size much change sooner or later. There is not yet consensus on exactly how or when. I will be pushing to change it this year." This is what "I will be pushing to change it this year" looks like. -- -- Gavin Andresen -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed alternatives to the 20MB step function
I like the bitcoin days destroyed idea. I like lots of the ideas that have been presented here, on the bitcointalk forums, etc etc etc. It is easy to make a proposal, it is hard to wade through all of the proposals. I'm going to balance that equation by completely ignoring any proposal that isn't accompanied by code that implements the proposal (with appropriate tests). However, I'm not the bottleneck-- you need to get the attention of the other committers and convince THEM: a) something should be done "now-ish" b) your idea is good We are stuck on (a) right now, I think. On Fri, May 8, 2015 at 8:32 AM, Joel Joonatan Kaartinen < joel.kaarti...@gmail.com> wrote: > Matt, > > It seems you missed my suggestion about basing the maximum block size on > the bitcoin days destroyed in transactions that are included in the block. > I think it has potential for both scaling as well as keeping up a constant > fee pressure. If tuned properly, it should both stop spamming and increase > block size maximum when there are a lot of real transactions waiting for > inclusion. > > - Joel > -- -- Gavin Andresen -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed alternatives to the 20MB step function
RE: fixing sigop counting, and building in UTXO cost: great idea! One of the problems with this debate is it is easy for great ideas get lost in all the noise. RE: a hard upper limit, with a dynamic limit under it: I like that idea. Can we drill down on the hard upper limit? There are lots of people who want a very high upper limit, right now (all the big Bitcoin companies, and anybody who thinks as-rapid-as-possible growth now is the best path to long-term success). This is the "it is OK if you have to run full nodes in a data center" camp. There are also lots of people who want an upper limit low enough that they can continue to run Bitcoin on the hardware and Internet connection that they have (or are concerned about centralization, so want to make sure OTHER people can continue to run). Is there an upper limit "we" can choose to make both sets of people mostly happy? I've proposed "must be inexpensive enough that a 'hobbyist' can afford to run a full node" ... Is the limit chosen once, now, via hard-fork, or should we expect multiple hard-forks to change it "when necessary" ? The economics change every time the block reward halves, which make me think that might be a good time to adjust the hard upper limit. If we have a hard upper limit and a lower dynamic limit, perhaps adjusting the hard upper limit (up or down) to account for the block reward halving, based on the dynamic limit RE: the lower dynamic limit algorithm: I REALLY like that idea. -- -- Gavin Andresen -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed alternatives to the 20MB step function
Let me make sure I understand this proposal: On Fri, May 8, 2015 at 11:36 PM, Gregory Maxwell wrote: > (*) I believe my currently favored formulation of general dynamic control > idea is that each miner expresses in their coinbase a preferred size > between some minimum (e.g. 500k) and the miner's effective-maximum; > the actual block size can be up to the effective maximum even if the > preference is lower (you're not forced to make a lower block because you > stated you wished the limit were lower). There is a computed maximum > which is the 33-rd percentile of the last 2016 coinbase preferences > minus computed_max/52 (rounding up to 1) bytes-- or 500k if thats > larger. The effective maximum is X bytes more, where X on the range > [0, computed_maximum] e.g. the miner can double the size of their > block at most. If X > 0, then the miners must also reach a target > F(x/computed_maximum) times the bits-difficulty; with F(x) = x^2+1 --- > so the maximum penalty is 2, with a quadratic shape; for a given mempool > there will be some value that maximizes expected income. (obviously all > implemented with precise fixed point arithmetic). The percentile is > intended to give the preferences of the 33% least preferring miners a > veto on increases (unless a majority chooses to soft-fork them out). The > minus-comp_max/52 provides an incentive to slowly shrink the maximum > if its too large-- x/52 would halve the size in one year if miners > were doing the lowest difficulty mining. The parameters 500k/33rd, > -computed_max/52 bytes, and f(x) I have less strong opinions about; > and would love to hear reasoned arguments for particular parameters. > I'm going to try to figure out how much transaction fee a transaction would have to pay to bribe a miner to include it. Greg, please let me know if I've misinterpreted the proposed algorithm. And everybody, please let me know if I'm making a bone-headed mistake in how I'm computing anything: Lets say miners are expressing a desire for 600,000 byte blocks in their coinbases. computed_max = 600,000 - 600,000/52 = 588,462 bytes. --> this is about 23 average-size (500-byte) transactions less than 600,000. effective_max = 1,176,923 Lets say I want to maintain status quo at 600,000 bytes; how much penalty do I have? ((600,000-588,462)/588,462)^2 + 1 = 1.00038 How much will that cost me? The network is hashing at 310PetaHash/sec right now. Takes 600 seconds to find a block, so 186,000PH per block 186,000 * 0.00038 = 70 extra PH If it takes 186,000 PH to find a block, and a block is worth 25.13 BTC (reward plus fees), that 70 PH costs: (25.13 BTC/block / 186,000 PH/block) * 70 PH = 0.00945 BTC or at $240 / BTC: $2.27 ... so average transaction fee will have to be about ten cents ($2.27 spread across 23 average-sized transactions) for miners to decide to stay at 600K blocks. If they fill up 588,462 bytes and don't have some ten-cent-fee transactions left, they should express a desire to create a 588,462-byte-block and mine with no penalty. Is that too much? Not enough? Average transaction fees today are about 3 cents per transaction. I created a spreadsheet playing with the parameters: https://docs.google.com/spreadsheets/d/1zYZfb44Uns8ai0KnoQ-LixDwdhqO5iTI3ZRcihQXlgk/edit?usp=sharing "We" could tweak the constants or function to get a transaction fee we think is reasonable... but we really shouldn't be deciding whether transaction fees are too high, too low, or just right, and after thinking about this for a while I think any algorithm that ties difficulty to block size is just a complicated way of dictating minimum fees. As for some other dynamic algorithm: OK with me. How do we get consensus on what the best algorithm is? I'm ok with any "don't grow too quickly, give some reasonable-percentage-minority of miners the ability to block further increases." Also relevant here: "The curious task of economics is to demonstrate to men how little they really know about what they imagine they can design." - Friedrich August von Hayek -- -- Gavin Andresen -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Long-term mining incentives
I think long-term the chain will not be secured purely by proof-of-work. I think when the Bitcoin network was tiny running solely on people's home computers proof-of-work was the right way to secure the chain, and the only fair way to both secure the chain and distribute the coins. See https://gist.github.com/gavinandresen/630d4a6c24ac6144482a for some half-baked thoughts along those lines. I don't think proof-of-work is the last word in distributed consensus (I also don't think any alternatives are anywhere near ready to deploy, but they might be in ten years). I also think it is premature to worry about what will happen in twenty or thirty years when the block subsidy is insignificant. A lot will happen in the next twenty years. I could spin a vision of what will secure the chain in twenty years, but I'd put a low probability on that vision actually turning out to be correct. That is why I keep saying Bitcoin is an experiment. But I also believe that the incentives are correct, and there are a lot of very motivated, smart, hard-working people who will make it work. When you're talking about trying to predict what will happen decades from now, I think that is the best you can (honestly) do. -- -- Gavin Andresen -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Long-term mining incentives
Added back the list, I didn't mean to reply privately: Fair enough, I'll try to find time in the next month or three to write up four plausible future scenarios for how mining incentives might work: 1) Fee-supported with very large blocks containing lots of tiny-fee transactions 2) Proof-of-idle supported (I wish Tadge Dryja would publish his proof-of-idle idea) 3) Fees purely as transaction-spam-prevention measure, chain security via alternative consensus algorithm (in this scenario there is very little mining). 4) Fee supported with small blocks containing high-fee transactions moving coins to/from sidechains. Would that be helpful, or do you have some reason for thinking that we should pick just one and focus all of our efforts on making that one scenario happen? I always think it is better, when possible, not to "bet on one horse." On Tue, May 12, 2015 at 10:39 AM, Thomas Voegtlin wrote: > Le 12/05/2015 15:44, Gavin Andresen a écrit : > > Ok, here's my scenario: > > > > https://blog.bitcoinfoundation.org/a-scalability-roadmap/ > > > > It might be wrong. I welcome other people to present their road maps. > > > > [answering to you only because you answered to me and not to the list; > feel free to repost this to the list though] > > Yes, that's exactly the kind of roadmap I am asking for. But your blog > post does not say anything about long term mining incentives, it only > talks about scalability. My point is that we need the same kind of thing > for miners incentives. > -- -- Gavin Andresen -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [BIP] Normalized Transaction IDs
I think this needs more details before it gets a BIP number; for example,
which opcodes does this affect, and how, exactly, does it affect them? Is
the merkle root in the block header computed using normalized transaction
ids or normalized ids?
I think there might actually be two or three or four BIPs here:
+ Overall "what is trying to be accomplished"
+ Changes to the OP_*SIG* opcodes
+ Changes to the bloom-filtering SPV support
+ ...eventually, hard fork rollout plan
I also think that it is a good idea to have actually implemented a proposal
before getting a BIP number. At least, I find that actually writing the
code often turns up issues I hadn't considered when thinking about the
problem at a high level. And I STRONGLY believe BIPs should be descriptive
("here is how this thing works") not proscriptive ("here's how I think we
should all do it").
Finally: I like the idea of moving to a normalized txid. But it might make
sense to bundle that change with a bigger change to OP_CHECKSIG; see Greg
Maxwell's excellent talk about his current thoughts on that topic:
https://www.youtube.com/watch?v=Gs9lJTRZCDc
On Wed, May 13, 2015 at 9:12 AM, Tier Nolan wrote:
> I think this is a good way to handle things, but as you say, it is a hard
> fork.
>
> CHECKLOCKTIMEVERIFY covers many of the use cases, but it would be nice to
> fix malleability once and for all.
>
> This has the effect of doubling the size of the UTXO database. At
> minimum, there needs to be a legacy txid to normalized txid map in the
> database.
>
> An addition to the BIP would eliminate the need for the 2nd index. You
> could require a SPV proof of the spending transaction to be included with
> legacy transactions. This would allow clients to verify that the
> normalized txid matched the legacy id.
>
> The OutPoint would be {LegacyId | SPV Proof to spending tx | spending tx
> | index}. This allows a legacy transaction to be upgraded. OutPoints
> which use a normalized txid don't need the SPV proof.
>
> The hard fork would be followed by a transitional period, in which both
> txids could be used. Afterwards, legacy transactions have to have the SPV
> proof added. This means that old transactions with locktimes years in the
> future can be upgraded for spending, without nodes needing to maintain two
> indexes.
>
>
> --
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
--
Gavin Andresen
--
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Long-term mining incentives
On Tue, May 12, 2015 at 7:48 PM, Adam Back wrote: > I think its fair to say no one knows how to make a consensus that > works in a decentralised fashion that doesnt weaken the bitcoin > security model without proof-of-work for now. > Yes. > I am presuming Gavin is just saying in the context of not pre-judging > the future that maybe in the far future another innovation might be > found (or alternatively maybe its not mathematically possible). > Yes... or an alternative might be found that weakens the Bitcoin security model by a small enough amount that it either doesn't matter or the weakening is vastly overwhelmed by some other benefit. I'm influenced by the way the Internet works; packets addressed to 74.125.226.67 reliably get to Google through a very decentralized system that I'll freely admit I don't understand. Yes, a determined attacker can re-route packets, but layers of security on top means re-routing packets isn't enough to pull off profitable attacks. I think Bitcoin's proof-of-work might evolve in a similar way. Yes, you might be able to 51% attack the POW, but layers of security on top of POW will mean that won't be enough to pull off profitable attacks. -- -- Gavin Andresen -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed alternatives to the 20MB step function
On Fri, May 8, 2015 at 3:20 AM, Matt Whitlock wrote: > Between all the flames on this list, several ideas were raised that did > not get much attention. I hereby resubmit these ideas for consideration and > discussion. > > - Perhaps the hard block size limit should be a function of the actual > block sizes over some trailing sampling period. For example, take the > median block size among the most recent 2016 blocks and multiply it by 1.5. > This allows Bitcoin to scale up gradually and organically, rather than > having human beings guessing at what is an appropriate limit. > A lot of people like this idea, or something like it. It is nice and simple, which is really important for consensus-critical code. With this rule in place, I believe there would be more "fee pressure" (miners would be creating smaller blocks) today. I created a couple of histograms of block sizes to infer what policy miners are ACTUALLY following today with respect to block size: Last 1,000 blocks: http://bitcoincore.org/~gavin/sizes_last1000.html Notice a big spike at 750K -- the default size for Bitcoin Core. This graph might be misleading, because transaction volume or fees might not be high enough over the last few days to fill blocks to whatever limit miners are willing to mine. So I graphed a time when (according to statoshi.info) there WERE a lot of transactions waiting to be confirmed: http://bitcoincore.org/~gavin/sizes_357511.html That might also be misleading, because it is possible there were a lot of transactions waiting to be confirmed because miners who choose to create small blocks got lucky and found more blocks than normal. In fact, it looks like that is what happened: more smaller-than-normal blocks were found, and the memory pool backed up. So: what if we had a dynamic maximum size limit based on recent history? The average block size is about 400K, so a 1.5x rule would make the max block size 600K; miners would definitely be squeezing out transactions / putting pressure to increase transaction fees. Even a 2x rule (implying 800K max blocks) would, today, be squeezing out transactions / putting pressure to increase fees. Using a median size instead of an average means the size can increase or decrease more quickly. For example, imagine the rule is "median of last 2016 blocks" and 49% of miners are producing 0-size blocks and 51% are producing max-size blocks. The median is max-size, so the 51% have total control over making blocks bigger. Swap the roles, and the median is min-size. Because of that, I think using an average is better-- it means the max size will change (up or down) more slowly. I also think 2016 blocks is too long, because transaction volumes change quicker than that. An average over 144 blocks (last 24 hours) would be better able to handle increased transaction volume around major holidays, and would also be able to react more quickly if an economically irrational attacker attempted to flood the network with fee-paying transactions. So my straw-man proposal would be: max size 2x average size over last 144 blocks, calculated at every block. There are a couple of other changes I'd pair with that consensus change: + Make the default mining policy for Bitcoin Core neutral-- have its target block size be the average size, so miners that don't care will "go along with the people who do care." + Use something like Greg's formula for size instead of bytes-on-the-wire, to discourage bloating the UTXO set. - When I've proposed (privately, to the other core committers) some dynamic algorithm the objection has been "but that gives miners complete control over the max block size." I think that worry is unjustified right now-- certainly, until we have size-independent new block propagation there is an incentive for miners to keep their blocks small, and we see miners creating small blocks even when there are fee-paying transactions waiting to be confirmed. I don't even think it will be a problem if/when we do have size-independent new block propagation, because I think the combination of the random timing of block-finding plus a dynamic limit as described above will create a healthy system. If I'm wrong, then it seems to me the miners will have a very strong incentive to, collectively, impose whatever rules are necessary (maybe a soft-fork to put a hard cap on block size) to make the system healthy again. -- -- Gavin Andresen -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed alternatives to the 20MB step function
On Thu, May 28, 2015 at 1:05 PM, Mike Hearn wrote: > Isn't that a step backwards, then? I see no reason for fee pressure to >> exist at the moment. All it's doing is turning away users for no purpose: >> mining isn't supported by fees, and the tiny fees we use right now seem to >> be good enough to stop penny flooding. >> > > Why not set the max size to be 20x the average size? Why 2x, given you > just pointed out that'd result in blocks shrinking rather than growing. > Twenty is scary. And two is a very neutral number: if 50% of hashpower want the max size to grow as fast as possible and 50% are dead-set opposed to any increase in max size, then half produce blocks 2 times as big, half produce empty blocks, and the max size doesn't change. If it was 20, then a small minority of miners could force a max size increase. (if it is less than 2, then a minority of minors can force the block size down) As for whether there "should" be fee pressure now or not: I have no opinion, besides "we should make block propagation faster so there is no technical reason for miners to produce tiny blocks." I don't think us developers should be deciding things like whether or not fees are too high, too low, . -- -- Gavin Andresen -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed alternatives to the 20MB stepfunction
On Thu, May 28, 2015 at 1:59 PM, Pieter Wuille wrote: > I personally think the block size should increase, by the way, but only if > we can do it under a policy of doing it after technological growth has been > shown to be sufficient to support it without increased risk. > > Can you be more specific about this? What risks are you worried about? I've tried to cover all that I've heard about in my blog posts about why I think the risks of 20MB blocks are outweighed by the benefits, am I missing something? (blog posts are linked from http://gavinandresen.ninja/time-to-roll-out-bigger-blocks ) There is the "a sudden jump to a 20MB max might have unforseen consequences" risk that I don't address, but a dynamic increase would fix that. -- -- Gavin Andresen -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed alternatives to the 20MB step function
On Thu, May 28, 2015 at 1:34 PM, Mike Hearn wrote: > As noted, many miners just accept the defaults. With your proposed change >> their target would effectively *drop* from 1mb to 800kb today, which >> seems crazy. That's the exact opposite of what is needed right now. >> > > I am very skeptical about this idea. > By the time a hard fork can happen, I expect average block size will be above 500K. Would you support a rule that was "larger of 1MB or 2x average size" ? That is strictly better than the situation we're in today. -- -- Gavin Andresen -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed alternatives to the 20MB step function
Can we hold off on bike-shedding the particular choice of parameters until people have a chance to weigh in on whether or not there is SOME set of dynamic parameters they would support right now? -- -- Gavin Andresen -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed alternatives to the 20MB step function
What do other people think? If we can't come to an agreement soon, then I'll ask for help reviewing/submitting patches to Mike's Bitcoin-Xt project that implement a big increase now that grows over time so we may never have to go through all this rancor and debate again. I'll then ask for help lobbying the merchant services and exchanges and hosted wallet companies and other bitcoind-using-infrastructure companies (and anybody who agrees with me that we need bigger blocks sooner rather than later) to run Bitcoin-Xt instead of Bitcoin Core, and state that they are running it. We'll be able to see uptake on the network by monitoring client versions. Perhaps by the time that happens there will be consensus bigger blocks are needed sooner rather than later; if so, great! The early deployment will just serve as early testing, and all of the software already deployed will ready for bigger blocks. But if there is still no consensus among developers but the "bigger blocks now" movement is successful, I'll ask for help getting big miners to do the same, and use the soft-fork block version voting mechanism to (hopefully) get a majority and then a super-majority willing to produce bigger blocks. The purpose of that process is to prove to any doubters that they'd better start supporting bigger blocks or they'll be left behind, and to give them a chance to upgrade before that happens. Because if we can't come to consensus here, the ultimate authority for determining consensus is what code the majority of merchants and exchanges and miners are running. -- -- Gavin Andresen -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed alternatives to the 20MB step function
On Fri, May 29, 2015 at 10:09 AM, Tier Nolan wrote: > How do you intend to measure exchange/merchant acceptance? > Public statements saying "we're running software that is ready for bigger blocks." And looking at the version (aka user-agent) strings of publicly reachable nodes on the network. (e.g. see the count at https://getaddr.bitnodes.io/nodes/ ) -- -- Gavin Andresen -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Block Size Increase Requirements
Matt brought this up on Twitter, I have no idea why I didn't respond weeks ago (busy writing blog posts, probably): On Thu, May 7, 2015 at 6:02 PM, Matt Corallo wrote: > > > * Though there are many proposals floating around which could > significantly decrease block propagation latency, none of them are > implemented today. If block propagation isn't fixed, then mines have a strong incentive to create smaller blocks. So the max block size is irrelevant, it won't get hit. > In addition, I'd expect to > see analysis of how these systems perform in the worst-case, not just > packet-loss-wise, but in the face of miners attempting to break the system. > See http://gavinandresen.ninja/are-bigger-blocks-better-for-bigger-miners for analysis of "but that means bigger miners can get an advantage" argument. Executive summary: if little miners are stupid and produce huge blocks, then yes, big miners have an advantage. But they're not, so they won't. Until the block reward goes away, and assuming transaction fees become an important source of revenue for miners. I think it is too early to worry about that; see: http://gavinandresen.ninja/when-the-block-reward-goes-away > * I'd very much like to see someone working on better scaling > technology, both in terms of development and in terms of getting > traction in the marketplace. Ok. What does this have to do with the max block size? Are you arguing that work won't happen if the max block size increases? * I'd like to see some better conclusions to the discussion around > long-term incentives within the system. Again, see http://gavinandresen.ninja/when-the-block-reward-goes-away for what I think about that. -- -- Gavin Andresen -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] soft-fork block size increase (extension blocks) Re: Proposed alternatives to the 20MB stepfunction
RE: soft-forking an "extension block": So... go for it, code it up. Implement it in the Bitcoin Core wallet. Then ask the various wallet developer how long it would take them to update their software to support something like this, and do some UI mockups of what the experience would look like for users. If there are two engineering solutions to a problem, one really simple, and one complex, why would you pick the complex one? Especially if the complex solution has all of the problems of the simple one (20MB extension blocks are just as "dangerous" as 20MB main blocks, yes? If not, why not?) -- -- Gavin Andresen -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Block Size Increase Requirements
On Fri, May 29, 2015 at 7:42 PM, Chun Wang <1240...@gmail.com> wrote: > Hello. I am from F2Pool. We are currently mining the biggest blocks on > the network. Thanks for giving your opinion! > Bad miners could attack us and the network with artificial > big blocks. How? I ran some simulations, and I could not find a network topology where a big miner producing big blocks could cause a loss of profit to another miner (big or small) producing smaller blocks: http://gavinandresen.ninja/are-bigger-blocks-better-for-bigger-miners (the 0.3% advantage I DID find was for the situation where EVERYBODY was producing big blocks). > We think > the max block size should be increased, but must be increased > smoothly, 2 MB first, and then after one or two years 4 MB, then 8 MB, > and so on. Thanks. Why 2 MB ? You said that server bandwidth is much more expensive in China; what would be the difference in your bandwidth costs between 2MB blocks and 20MB blocks? -- -- Gavin Andresen -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Block Size Increase Requirements
twork.
> >
>
> Oh? You mention at http://gavinandresen.ninja/bigger-blocks-another-way
> that "I struggle with wanting to stay true to Satoshi’s original vision
> of Bitcoin as a system that scales up to Visa-level transaction volume".
> That is in direct contradiction.
>
I have said repeatedly that if it was left completely up to me I would go
back to Satoshi's original "there is no consensus-level blocksize limit".
20MB is a compromise.
> Ok, I wrote about that here:
> >
> > http://gavinandresen.ninja/it-must-be-done-but-is-not-a-panacea
> >
>
> "it is not a panacea", but everyone in the community seems to be taking
> it as one. You've claimed many times that many of the big
> webwallet/payment processors/etc have been coming to you and saying they
> need bigger block sizes to continue operating. In reality, they dont, it
> just makes it easier
>
>
... and now you're pissing me off. I have NEVER EVER said that they need
bigger blocks to continue operating. Please stop being overly dramatic.
They believe that bigger blocks are better for Bitcoin.
Brian Armstrong at Coinbase, in particular, said that smaller blocks drive
centralization towards services like Coinbase ("look ma! No blockchain
transaction!" <-- if you pay a Coinbase merchant from your Coinbase
wallet), but he supports bigger blocks because more transactions on our
existing decentralized network is better.
--
--
Gavin Andresen
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: Block Size Increase Requirements
On Sat, May 30, 2015 at 9:31 PM, Chun Wang <1240...@gmail.com> wrote: > > If someone propagate a 20MB block, it will take at best 6 seconds for > us to receive to verify it at current configuration, result of one > percent orphan rate increase. That orphan rate increase will go to whoever is producing the 20MB blocks, NOT you. Or, we can mine the next block only on > the previous block's header, in this case, the network would see many > more transaction-less blocks. > Are you sure that is the best strategy? If a big block is slow to propagate, I suspect it will be better to punish the miner that created it by refusing to build on it until it has been fully validated. I'll try to find time to run a couple of simulations. > > Our orphan rate is about 0.5% over the past few months. If the network > floods 20MB blocks, it can be well above 2%. Besides bandwidth, A 20MB > block could contain an average of 5 transactions, hundred of > thousands of sigops, Do you have an estimate how long it takes on the > submitblock rpccall? > I can benchmark it. It should be pretty fast, and sipa has a couple of patches pending to make the UTXO cache much faster. It can be fast because the vast majority of the work of validating all those transactions can happen as they are received into the memory pool. > For references, our 30Mbps bandwidth in Beijing costs us 1350 dollars > per month. You should be able to handle 20MB blocks no problem; if I round up to 100MB per block that works out to 1.3Mbps. We also use Aliyun and Linode cloud services for block > propagation. As of May 2015, the price is 0.13 U.S. dollars per GB for > 100Mbps connectivity at Aliyun. That speed will handle 20MB blocks no problem. If each 20MB block is 100MB of data up/down the wire (I'm vastly over-estimating, after optimization it should be 40MB) then you'll be paying...uhhh: 0.1 GB / block-data-on-wire * 144 blocks/day * 30.5 days/month * 0.13 $ / GB = $57 Less than $2 per day in bandwidth, surely you can afford that. > For a single cross-border TCP > connection, it would be certainly far slower than 12.5 MB/s. That's OK, you'll 1.3Mbps or less. > I think we can accept 5MB block at most. > Are you worried about paying too much, or do 20MB blocks "feel like too much" ? -- -- Gavin Andresen -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Block Size Increase Requirements
On Sun, May 31, 2015 at 3:05 AM, Peter Todd wrote: > Yeah, I'm pretty surprised myself that Gavin never accepted the > compromises offered by others in this space for a slow growth solution > What compromise? I haven't seen a specific proposal that could be turned into a pull request. > Something important to note in Gavin Andresen's analysises of this issue > is that he's using quite optimistic scenarios for how nodes are > connected to each other. NO I AM NOT. I simulated a variety of connectivities; see the .cfg files at https://github.com/gavinandresen/bitcoin_miningsim The results I give in the "are bigger blocks better" blog post are for WORST CASE connectivity (one dominant big miner, multiple little miners, big miner connects to only 30% of little miners, but all the little miners connected directly to each other). > For instance, assuming that connections between > miners are direct is a very optimistic assumption Again, I did not simulate all miners directly connected to each other. I will note that miners are VERY HIGHLY connected today. It is in their best interest to be highly connected to each other. > that depends on a > permissive, unregulated, environment where miners co-operate with each > other - obviously that's easily subject to change! Really? How is that easily subject to change? If it is easily subject to change, do bigger blocks have any effect? Why are 1MB blocks not subject to change? I talk about "what if your government bans Bitcoin entirely" here: http://gavinandresen.ninja/big-blocks-and-tor ... and the issues are essentially the same, independent of block size. -- -- Gavin Andresen -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: Block Size Increase Requirements
On Sat, May 30, 2015 at 9:31 PM, Chun Wang <1240...@gmail.com> wrote: > > If someone propagate a 20MB block, it will take at best 6 seconds for > us to receive to verify it at current configuration, result of one > percent orphan rate increase. That orphan rate increase will go to whoever is producing the 20MB blocks, NOT you. Or, we can mine the next block only on > the previous block's header, in this case, the network would see many > more transaction-less blocks. > Are you sure that is the best strategy? If a big block is slow to propagate, I suspect it will be better to punish the miner that created it by refusing to build on it until it has been fully validated. I'll try to find time to run a couple of simulations. > > Our orphan rate is about 0.5% over the past few months. If the network > floods 20MB blocks, it can be well above 2%. Besides bandwidth, A 20MB > block could contain an average of 5 transactions, hundred of > thousands of sigops, Do you have an estimate how long it takes on the > submitblock rpccall? > I can benchmark it. It should be pretty fast, and sipa has a couple of patches pending to make the UTXO cache much faster. It can be fast because the vast majority of the work of validating all those transactions can happen as they are received into the memory pool. > For references, our 30Mbps bandwidth in Beijing costs us 1350 dollars > per month. You should be able to handle 20MB blocks no problem; if I round up to 100MB per block that works out to 1.3Mbps. We also use Aliyun and Linode cloud services for block > propagation. As of May 2015, the price is 0.13 U.S. dollars per GB for > 100Mbps connectivity at Aliyun. That speed will handle 20MB blocks no problem. If each 20MB block is 100MB of data up/down the wire (I'm vastly over-estimating, after optimization it should be 40MB) then you'll be paying...uhhh: 0.1 GB / block-data-on-wire * 144 blocks/day * 30.5 days/month * 0.13 $ / GB = $57 Less than $2 per day in bandwidth. > For a single cross-border TCP > connection, it would be certainly far slower than 12.5 MB/s. That's OK, you'll 1.3Mbps or less. > I think we can accept 5MB block at most. > Are you worried about paying too much, or do 20MB blocks "feel like too much" ? -- -- Gavin Andresen -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: Block Size Increase Requirements
On Sun, May 31, 2015 at 10:34 AM, Yifu Guo wrote: > comments, question and grievances welcome. > Thanks for chiming in with facts, Yifu! Do you have any real-world data on latency/bandwidth/cost through the gfw ? Chung Wang's post was very helpful to get away from hypotheticals to "what would it actually cost." -- -- Gavin Andresen -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Block Size Increase Requirements
On Sun, May 31, 2015 at 10:46 AM, Jorge Timón wrote: > Here's a thought experiment: > > Subsidy is gone, all the block reward comes from fees. > I wrote about long-term hypotheticals and why I think it is a big mistake to waste time worrying about them here: http://gavinandresen.ninja/when-the-block-reward-goes-away -- -- Gavin Andresen -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: Block Size Increase Requirements
On Sun, May 31, 2015 at 9:45 AM, Alex Mizrahi wrote: > > >> That orphan rate increase will go to whoever is producing the 20MB >> blocks, NOT you. >> > > This depends on how miners are connected. > > E.g. suppose there are three miners, A and B have fast connectivity > between then, and C has a slow network. > Suppose that A miners a block and B receives it in 1 second. C receives it > in 6 seconds. > This means that blocks mined by C during these ~5 seconds will be orphaned > because B gets A's block first. > Yes, if you are on a slow network then you are at a (slight) disadvantage. So? There are lots of equations that go into the "is mining profitable" equation: cost of power, Internet cost and connectivity, cost of capital, access to technology other miners don't have, inexpensive labor or rent, inexpensive cooling, ability to use waste heat... That's good. An equation with lots of variables has lots of different maximum solutions, and that means better decentralization -- there is less likely to be one perfect place or way to mine. -- -- Gavin Andresen -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Block Size Increase Requirements
On Sun, May 31, 2015 at 10:59 AM, Jorge Timón wrote: > Whatever...let's use the current subsidies, the same argument applies, > it's just 20 + 25 = 45 btc per block for miner B vs 27 btc for miner B. > Miner B would still go out of business, bigger blocks still mean more > mining and validation centralization > Sorry, but that's ridiculous. If Miner B is leaving 18BTC per block on the table because they have bad connectivity, then they need to pay for better connectivity. If you are arguing "I should be able to mine on a 56K modem connection from the middle of the Sahara" then we're going to have to agree to disagree. So: what is your specific proposal for minimum requirements for connectivity to run a full node? The 20MB number comes from estimating costs to run a full node, and as my back-and-forth to Chang Wung shows, the costs are not excessive. -- -- Gavin Andresen -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [Bulk] Re: Fwd: Block Size Increase Requirements
On Sun, May 31, 2015 at 9:31 AM, gb wrote: > Aren't you calculating bandwidth for a singly-connected node? A "highly > connected" miner could have 30-100 node connections so you probably need > to increase your traffic estimates by that factor. > > I.e. For 100MB blocks, 30-100 Mbps and $60-$100 per day data costs. > No, randomly connected gossip networks (which is what the Bitcoin p2p network is) don't work that way, bandwidth is (roughly) O(N) where N is the number of bytes relayed to everybody. (it is actually a small multiple of N, because of the overhead of 'inv' messages, and if we ever get really serious about scaling up we'll need to fix the protocol to reduce that overhead, but that won't be a problem for years). -- -- Gavin Andresen -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: Block Size Increase Requirements
On Sun, May 31, 2015 at 6:55 PM, Alex Mizrahi
wrote:
> Yes, if you are on a slow network then you are at a (slight) disadvantage.
>> So?
>>
>
> Chun mentioned that his pool is on a slow network, and thus bigger blocks
> give it an disadvantage. (Orphan rate is proportional to block size.)
>
You said that no, on contrary those who make big blocks have a disadvantage.
> And now you say that yes, this disadvantage exist.
>
>
Did you just lie to Chun?
>
Chun said that if somebody produced a big block it would take them at least
6 seconds to process it.
He also said he has nodes outside the great firewall ("We also use Aliyun
and Linode cloud services for block
propagation.").
So I assumed that he was talking about the "what if somebody produces a
block that takes a long time to process" attack -- which doesn't work (the
attacker just increases their own orphan rate).
If the whole network is creating blocks that takes everybody (except the
person creating the blocks) six seconds to broadcast+validate, then the
increase in orphan rate is spread out over the whole network. The
network-wide orphan rate goes up, everybody suffers a little (fewer blocks
created over time) until the next difficulty adjustment, then the
difficulty drops, then everybody is back in the same boat.
If it takes six seconds to validate because of limited bandwidth, then he
should connect via Matt's fast relay network, which optimize new block
announcements so they take a couple orders of magnitude less bandwidth.
If it takes six seconds because he's trying to validate on a raspberry
pi then he should buy a better validating machine, and/or help test the
current pending pull requests to make validation faster (e.g.
https://github.com/bitcoin/bitcoin/pull/5835 or
https://github.com/bitcoin/bitcoin/pull/6077 ).
If Chun had six seconds of latency, and he can't pay for a lower-latency
connection (or it is insanely expensive), then there's nothing he can do,
he'll have to live with a higher orphan rate no matter the block size.
--
--
Gavin Andresen
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed alternatives to the 20MB step
RE: going to the public: I started pushing privately for SOMETHING, ANYTHING to be done, or at the very least for there to be some coherent plan besides "wait and see" back in February. As for it being unhealthy for me to write the code that I think should be written and asking people to run it: Ok. What would you suggest I do? I believe scaling up is the number one priority right now. I think core devs SHOULD be taking time to solve it, because I think the uncertainty of how it will be solved (or if it will be solved) is bad for Bitcoin. I think working on things like fixing transaction malleability is great... but the reason to work on that is to enable smart contracts and all sorts of other interesting new uses of the blockchain. But if we're stuck with 1MB blocks then there won't be room for all of those interesting new uses on the blockchain. Others disagree, and have the advantage of status-quo : if nothing is done, they get what they want. Based on some comments I've seen, I think there is also concern that "my own personal network/computer connection might not be able to handle more transaction volume." That is NOT a good reason to limit scalability, but I think it is clouding the judgement of many of the core contributors who started contributing as a spare-time hobby from their homes (where maybe they have crappy DSL connections). RE: decentralization: I think this is a red-herring. I'll quote something I said on reddit yesterday: "I don't believe a 20MB max size will increase centralization to any significant degree. See http://gavinandresen.ninja/does-more-transactions-necessarily-mean-more-centralized and http://gavinandresen.ninja/are-bigger-blocks-better-for-bigger-miners And I think we will have a lot LESS centralization of payments via services like Coinbase (or hubs in some future StrawPay/Lightning network) if the bitcoin network can directly handle more payment volume. The centralization trade-offs seems very clear to me, and I think the "big blocks mean more centralized" arguments are either just wrong or are exaggerated or ignore the tradeoff with payment centralization (I think that is a lot more important for privacy and censorship resistance)." RE: incentives for off-chain solutions: I'll quote myself again from http://gavinandresen.ninja/it-must-be-done-but-is-not-a-panacea : "The “layer 2” services that are being built on top of the blockchain are absolutely necessary to get nearly instant real-time payments, micropayments and high volume machine-to-machine payments, to pick just three examples. The ten-minute settlement time of blocks on the network is not fast enough for those problems, and it will be the ten minute block interval that drives development of those off-chain innovations more than the total number of transactions supported." On Mon, Jun 1, 2015 at 8:45 AM, Jérôme Legoupil wrote: > If during the "1MB bumpy period" something goes wrong, consensus among the > community would be reached easily if necessary. > That is the problem: this will be a "frog in boiling water" problem. I believe there will be no sudden crisis-- instead, transactions will just get increasingly unreliable and expensive, driving more and more people away from Bitcoin towards... I don't know what. Some less expensive, more reliable, probably more-centralized solution. The Gavin 20MB proposal is compromising Bitcoin's long-term security in an > irreversible way, for gaining short-term better user experience. > If by long-term security you mean "will transaction fees be high enough to pay for enough hashing power to secure the network if there are bigger blocks" I've written about that: http://gavinandresen.ninja/block-size-and-miner-fees-again If you mean something else, then please be specific. -- -- Gavin Andresen -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: Block Size Increase Requirements
On Mon, Jun 1, 2015 at 7:20 AM, Chun Wang <1240...@gmail.com> wrote: > I cannot believe why Gavin (who seems to have difficulty to spell my > name correctly.) insists on his 20MB proposal regardless the > community. BIP66 has been introduced for a long time and no one knows > when the 95% goal can be met. This change to the block max size must > take one year or more to be adopted. We should increase the limit and > increase it now. 20MB is simply too big and too risky, sometimes we > need compromise and push things forward. I agree with any solution > lower than 10MB in its first two years. > > Thanks, that's useful! What do other people think? Would starting at a max of 8 or 4 get consensus? Scaling up a little less than Nielsen's Law of Internet Bandwidth predicts for the next 20 years? (I think predictability is REALLY important). I chose 20 because all of my testing shows it to be safe, and all of my back-of-the-envelope calculations indicate the costs are reasonable. If consensus is "8 because more than order-of-magnitude increases are scary" -- ok. -- -- Gavin Andresen -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New attack identified and potential solution described: Dropped-transaction spam attack against the block size limit
ing other better proposals. >> >> Large blocks created by a miner as a means to spam other miners out of >> competition is a problem because miners do not pay fees for their own >> transactions when they mine them. They collect the fees they pay. This >> breaks the economic barrier keeping people from spamming the network, as >> the >> spamming is essentially free. The proposed fix is to add a new rule on >> how >> fees are handled. Some amount of every fee should be considered as burned >> and can never be spent. I will propose 50% of the fee here, but there may >> be better numbers that can be discovered prior to putting this into place. >> If we'd like miners to continue to collect the same fees after this >> change, >> we can suggest the default fee per transaction to be doubled. Half of >> every >> fee would be burned and disappear forever, effectively distributing the >> value of those bitcoins across the entire money supply. The other half >> would be collected by the miner of the block as is done today. This >> solution would mean large blocks would cost a significant number of >> bitcoin >> to create, even when all of the transactions are created by the miner of >> that block. For this to work, we'd need to ensure a minimum fee is paid >> for >> most of the transactions in every block, and the new transaction fee rule >> is >> in place. Then the block size limit can be removed. >> >> Raystonn >> >> >> >> -- >> ___ >> 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 > > -- -- Gavin Andresen -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New attack identified and potential solution described: Dropped-transaction spam attack against the block size limit
On Tue, Jun 9, 2015 at 1:52 PM, Raystonn . wrote: > That does sound good on the surface, but how do we enforce #1 and #2? > They seem to be unenforceable, as a miner can adjust the size of the memory > pool in his local source. > It doesn't have to be enforced. As long as a reasonable percentage of hash rate is following that policy an attacker that tries to flood the network will fail to prevent normal transaction traffic from going through and will just end up transferring some wealth to the miners. Although the existing default mining policy (which it seems about 70% of hashpower follows) of setting aside some space for high-priority transactions regardless of fee might also be enough to cause this attack to fail in practice. -- -- Gavin Andresen -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Mining centralization pressure from non-uniform propagation speed
Nice work, Pieter. You're right that my simulation assumed bandwidth for 'block' messages isn't the bottleneck. But doesn't Matt's fast relay network (and the work I believe we're both planning on doing in the near future to further optimize block propagation) make both of our simulations irrelevant in the long-run? Or, even simpler, why couldn't the little miners just run their block-assembling-and-announcing code on the other high-bandwidth-side of the bandwidth bottleneck? -- -- Gavin Andresen -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
On Thu, Jun 18, 2015 at 1:42 PM, Alex Morcos wrote: > Let me take a pass at explaining how I see this. > > 1) Code changes to Bitcoin Core that don't change consensus: Wladimir is > the decider but he works under a process that is well understood by > developers on the project in which he takes under reasonable consideration > other technical opinions and prefers to have clear agreement among them. > Yes. 2) Changes to the consensus rules: As others have said, this isn't anyone's > decision for anyone else. > Yes. > It's up to each individual user as to what code they run and what rules > they enforce. So then why is everyone so up in arms about what Mike and > Gavin are proposing if everyone is free to decide for themselves? I > believe that each individual user should adhere to the principle that there > should be no changes to the consensus rules unless there is near complete > agreement among the entire community, users, developers, businesses miners > etc. It is not necessary to define complete agreement exactly because every > individual person decides for themselves. I believe that this is what > gives Bitcoin, or really any money, its value and what makes it work, that > we all agree on exactly what it is. So I believe that it is misleading and > bad for Bitcoin to tell users and business that you can just choose without > concern for everyone else which code you'll run and we'll see which one > wins out. No. You should run the old consensus rules (on any codebase you > want) until you believe that pretty much everyone has consented to a change > in the rules. It is your choice, but I think a lot of people that have > spent time thinking about the philosophy of consensus systems believe that > when the users of the system have this principle in mind, it's what will > make the system work best. > I don't think I agree with "pretty much everybody", because status-quo bias is a very powerful thing. Any change that disrupts the way they've been doing things will generate significant resistance -- there will be 10 or 20% of any population that will take a position of "too busy to think about this, everything seems to be working great, I don't like change, NO to any change." For example, I think some of the resistance for bigger blocks is coming from contributors who are worried they, personally, won't be able to keep up with a bigger blockchain. They might not be able to run full nodes from their home network connections (or might not be able to run a full node AND stream Game of Thrones), on their old raspberry pi machines. The criteria for me is "clear super-majority of the people and businesses who are using Bitcoin the most," and I think that criteria is met. > 3) Code changes to Core that do change consensus: I think that Wladimir, > all the other committers besides Gavin, and almost all of the other > developers on Core would defer to #2 above and wait for its outcome to be > clear before considering such a code change. > Yes, that's the way it has mostly been working. But even before stepping down as Lead I was starting to wonder if there are ANY successful open source projects that didn't have either a Benevolent Dictator or some clear voting process to resolve disputes that cannot be settled with "rough consensus." -- -- Gavin Andresen -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee
I just sent the following email to F2Pool: I was disappointed to see Peter Todd claiming that you have (or will?) run his replace-by-fee patch. I strongly encourage you to wait until most wallet software supports replace-by-fee before doing that, because until that happens replace-by-fee just makes it easier to steal from bitcoin-accepting merchants. I will tell you the same thing about 8MB blocks: until most merchants support bigger blocks I will strongly encourage you keep creating less-than-1MB blocks. If we want Bitcoin to succeed more quickly, we should all be thinking about what is good for the whole system: users, merchants, exchanges and miners. As always, if you have questions or concerns feel free to email me. -- -- Gavin Andresen -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] BIP 16 status update
Mining support for BIP 16 is still under 50%, and won't possibly be over 50% by March 1. Which means we need a new evaluation/switchover date: Re-evaluate support: March 15'th Target switchover: April 1 If you're already supporting BIP16, restart bitcoind with the argument: -paytoscripthashtime=1333238400 ... to delay switchover until April 1. Hopefully this will be the last delay; Tycho has told me that deepbit will support BIP16 as soon as he's able to merge and test the changes, which will put support at well over 55%. -- -- Gavin Andresen -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Duplicate transactions vulnerability
> > The purpose of this mail is asking for support for adding this rule to > the protocol rules. If there is consensus this rule is the solution, I > hope pools and miners can agree to update their nodes without lengthy > coinbase-flagging procedure that would only delay a solution. So, who > is in favor? Pieter > Most of you might already know this, but I'm strongly in favor of doing this as soon as possible. -- -- Gavin Andresen -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Anything to chat about today at 21:00 UTC ?
I'll be in the #bitcoin-development IRC channel in two hours, for the semi-regular Tuesday IRC meeting. Things that might be worth some discussion: + The duplicate coinbase attack/fix, and strategy for rolling out sipa's fix. + 0.6 release schedule + Is there anything we can do to attract a great Windows developer? (we've got issues piling up...) + Multisignature next-steps: who is working on what? Am I forgetting anything? -- -- Gavin Andresen -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Duplicate transactions vulnerability
On Wed, Feb 29, 2012 at 5:05 PM, Ben Reeves wrote: > A malicious miner can produce a duplicate coinbase which the majority > of clients will accept but the majority of hashing power won't. > Spending the coinbase output after That can't happen until the coinbase matures, which takes 100 blocks. And it won't mature because a majority of hashing power is rejecting it, right? -- -- Gavin Andresen -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: Proposal for a new opcode
On Fri, Mar 2, 2012 at 2:57 PM, Watson Ladd wrote: > Dear all, > I am proposing a new opcode for the purposes of anonymous > transactions. That's very exciting! I'm eager to read the paper for all of the details, and working out what else would need to be done besides a new opcode to enable strong anonymity (at the very least, I assume we'll need one or more new 'standard' transaction types that clients understand). -- -- Gavin Andresen -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] 0.6rc3 binaries available
Version 0.6 release candidate 3 binaries are available at: https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.6.0/test/ The big reason to run rc3 is to get the BIP30 security fix that takes effect on March 15. It also includes a fix to the problem of running rc1, upgrading, and being stuck on the wrong block-chain fork -- -- Gavin Andresen -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] April 1 BIP16 switchover time is definite
Support for BIP16 has been approximately 70% of hashing power for the
last two days, and is 54% over the last week, so we're going to
announce that the BIP16 switchover time of April 1 is final and
strongly encourage any pools/miners that haven't yet upgraded their
software to do so in the next two weeks or risk hashing on a minority
chain.
I'll be checking to make sure support doesn't slip before April 1.
I've learned a lot, and have started writing up a document that
suggests how we can make the next upgrade process less painful for
everybody; when I've got a reasonable draft I'll start a discussion
about it here.
--
--
Gavin Andresen
PS: If you're curious, here is what support over the last 30 days
looks like, beginning with the last 24 hours (144 blocks) and going
backwards for each 24 hour period:
Found 103 matches in 144 blocks (71.5 percent)
Found 99 matches in 144 blocks (68.8 percent)
Found 87 matches in 144 blocks (60.4 percent)
Found 70 matches in 144 blocks (48.6 percent)
Found 73 matches in 144 blocks (50.7 percent)
Found 57 matches in 144 blocks (39.6 percent)
Found 52 matches in 144 blocks (36.1 percent)
Found 40 matches in 144 blocks (27.8 percent)
Found 40 matches in 144 blocks (27.8 percent)
Found 46 matches in 144 blocks (31.9 percent)
Found 41 matches in 144 blocks (28.5 percent)
Found 45 matches in 144 blocks (31.2 percent)
Found 57 matches in 144 blocks (39.6 percent)
Found 69 matches in 144 blocks (47.9 percent)
Found 51 matches in 144 blocks (35.4 percent)
Found 53 matches in 144 blocks (36.8 percent)
Found 65 matches in 144 blocks (45.1 percent)
Found 43 matches in 144 blocks (29.9 percent)
Found 48 matches in 144 blocks (33.3 percent)
Found 51 matches in 144 blocks (35.4 percent)
Found 46 matches in 144 blocks (31.9 percent)
Found 57 matches in 144 blocks (39.6 percent)
Found 61 matches in 144 blocks (42.4 percent)
Found 54 matches in 144 blocks (37.5 percent)
Found 53 matches in 144 blocks (36.8 percent)
Found 44 matches in 144 blocks (30.6 percent)
Found 52 matches in 144 blocks (36.1 percent)
Found 51 matches in 144 blocks (35.4 percent)
Found 53 matches in 144 blocks (36.8 percent)
Command used to get that data:
for i in {1..30}; do ./search_coinbases.py --n=$(($i * 144))
--start=$(( ($i -1) * 144)); done
search_coinbases is one of my bitcointools:
https://github.com/gavinandresen/bitcointools
Pretty graph of support over the last 100 blocks here:
github.com/bitcoin/bitcoin/
--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] April 1 BIP16 switchover time is definite
> Pretty graph of support over the last 100 blocks here: > github.com/bitcoin/bitcoin/ D'oh! correct url for the pretty graph: http://blockchain.info/P2SH -- -- Gavin Andresen -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Urgent: Windows Bitcoin-Qt update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 A potential security vulnerability has been discovered in the Windows version of Bitcoin-Qt. If you are running Bitcoin-Qt versions 0.5 through 0.6 on Windows you should shut it down and upgrade to either version 0.5.3.1 or 0.6rc4 NOW. The command-line bitcoin daemon (bitcoind), Mac and Linux versions of Bitcoin-Qt, and versions prior to 0.5 are not affected. Due to the nature of the vulnerability, we believe it would be very difficult for an attacker to do anything more than crash the Bitcoin-Qt process. However, because there is a possibility of such a crash causing remote code execution we consider this a critical issue. Binaries are available at SourceForge: https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.6.0/test/ https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.5.3/ If you have questions, feel free to drop by the #bitcoin-dev channel on FreeNode IRC. - -- Gavin Andresen Gregory Maxwell Matt Corallo Nils Schneider Wladimir J. van der Laan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9j12IACgkQdYgkL74406iIyQCfbxFTO3yD4Q2bHDjPlDuJn3Mj 9GAAn3mV+ggo+5q1Ujd0A5zwpFYojkE2 =g1Ad -END PGP SIGNATURE- -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Full disclosure on the Bitcoin-Qt on Windows problem
Reposting from my tech blog:
http://gavintech.blogspot.com/2012/03/full-disclosure-bitcoin-qt-on-windows.html
A major bug in Bitcoin-Qt on Windows went unnoticed for over four
months. The bug was in the bitcoin-qt.pro file, in these two lines of
code:
windows:LIBS += -lws2_32 -lshlwapi
windows:DEFINES += WIN32
See the bug?
I don't-- I can't see it, because the problem was Bitcoin-Qt on
Windows should have been linked with the "mingw" multithreading
library and compiled with the -D_MT to turn on support for
multithread-safe C++ exception handling in the "mingw" library (you
can see the 3-line fix here).
There might be developers reading this who have had experience writing
multithreaded mingw-based C++ applications who will say "Duh! You guys
are idiots, everybody knows that!"
If that's you and you're interested in Bitcoin: we need people like
you to help out! Review the code, review the build process, let us
know when we're being idiots. There seem to be a lot fewer Windows
developers willing to help out with Bitcoin than Linux or Mac
developers, which is unfortunate since a majority of our downloads are
Windows users.
Non-mingw-C++-multithreaded developers are reading this and thinking
"the bug was THERE? Not in some #ifdef WINDOWS C++ code or some
slightly-out-of-date library that you were linking against?"
The other reason this bug went unnoticed for so long is because it
almost never matters. Bitcoin-Qt doesn't throw a lot of exceptions
normally, and most of the time the single-threaded-application
exception support in mingw works just fine. I'm still not sure exactly
what triggers the bug-- probably something like two threads throwing
exceptions at the same time, or one thread being interrupted while in
a try{} block and then resuming later and crashing because the
exception handling code is in a different state.
Matt Corallo deserves a lot of credit for being persistent and finding
the bug when investigating hard-to-reproduce reports of Bitcoin-Qt
crashing sometimes when run with the -server flag and handling
JSON-RPC requests. He was never able to get the code to crash when
running outside of the debugger, which is typical of bugs related to
multithreading. But he did see crashes not involving RPC requests, and
that is why we consider this a critical issue and are telling
everybody affected to upgrade immediately.
It it exploitable? Could an attacker craft bitcoin protocol messages
that triggered the bug and compromised Windows computers? Has it
already been exploited?
We don't know. We think it would be extremely difficult to craft a
usable exploit, partly because it is hard to even trigger the bug
reliably but also because Bitcoin-Qt has some security-in-depth to try
to prevent this type of bug from becoming exploitable.
If we're very careful and extremely lucky, this will be the last time
we have to tell users to shutdown and upgrade immediately because of
some potential vulnerability. But there is no such thing as perfect
security, and I expect that there will be another subtle bug either in
Bitcoin or in one of the many libraries we link against that becomes a
potential security issue.
That doesn't mean we give up and go back to paying each other with
cowrie shells; it means we assume that devices get compromised and
design around that assumption. I think that is a lesson that the
entire software industry needs to learn better.
--
--
Gavin Andresen
--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Please trim excessive quoting
Messages over 40Kbytes big require moderator approval on this list; if you want your messages to appear promptly, please trim excessive quoting before hitting send. Thanks! -- -- Gavin Andresen -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Version 0.6 release candidate 5 binaries
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Barring any last-minute showstopper issues, the plan is for release candidate 5 to become the official 0.6.0 release on Wednesday. So please help look for last-minute showstopper issues: https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.6.0/test/ The major changes from release candidate 4: + Much faster writing of blkindex.dat during initial blockchain download (by modifying the default bdb environment cache settings) + A new policy for wallet.dat upgrades: use the old format unless the user either uses a feature that requires an upgrade (encrypts the wallet) or explicitly requests that the wallet be upgraded using the new -upgradewallet option. New wallets will use new features (for 0.6, the only new wallet feature is compressed public keys). + bugfix introduced in rc4 for an assertion failure that could occur during blockchain reorganizations + New code for managing the addr.dat file that prevents an attacker from filling it with bogus entries. - -- - -- Gavin Andresen -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9w/mIACgkQdYgkL74406gafACdHYn6QI6QoKhkf22e0My2jCWa IPkAn3YnNeMEmG8N6xEyCdNx3MTjgkcF =CRL2 -END PGP SIGNATURE- -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Release plan: 0.6.1
Summarizing a discussion from #bitcoin-dev this morning: The merge window for pull requests for a 0.6.1 release is now open. This will be a bug-fix and code-cleanup only release, with the goal to have Release Candidate 1 binaries available for testing in three weeks: April 23'rd. We want this to be a quick release cycle so we can start pulling new features for a 0.7 release in a month or so. The major issues I would like to get resolved: # 1024 Correct passphrase crashed the client # 1012 bitcoin-qt slow to shut down after recent commits There are currently 189 open issues in our bug tracker; lets try to get that down to under 100. I know this will frustrate some of you who think development is happening at a snail's pace; feel free to pull and test new features (IPv6 support and coin control) that are important to you. Adequate testing is still our biggest issue, if you want your favorite feature to get into bitcoin core faster please spend some time helping test other people's favorite features. -- -- Gavin Andresen -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Signature Blocks and URI Sign Requests
RE: signature blocks and BIP 10: We should avoid reinventing the wheel, if we can. I think we should extend existing standards whenever possible. So: could we encode signature blocks or BIP-10 transactions using S/MIME ? Or is there a more appropriate "sign a message" standard we could/should use? You're glossing over little details like what character encoding is used for the message, but I'd rather leverage all the work already done by the IETF to nail down all those little details rather then re-discover them and come up with our own solutions. -- -- Gavin Andresen -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Adding request/reply id in messages
On Wed, Apr 11, 2012 at 2:39 PM, Christian Bodt wrote: > I would like to discuss the following bitcoin protocol improvement proposal: > > Adding request/reply id in all messages (in the message header, > based on what was done for the "checksum" field) That seems like a perfectly reasonable protocol improvement to me. Anybody else have an opinion? -- -- Gavin Andresen -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Testnet reset for the 0.7 release
Testnet "Mark III" will be part of the 0.7 release, and is now in the master github branch. "Mark III" because this is the third genesis block for the testnet. The main reason for the reset is to get a more 'sane' test network; with the BIP16 and BIP30 and testnet difficulty blockchain rule changes the old testnet is a mess, with old clients serving up different, incompatible chains. The good news is the mess uncovered a couple of large-block-chain-reorganization bugs, but having a stable testnet to test new implementations or services is more important. Rules for tesnet3: + Minimum difficulty 1.0 (same as main net-- old testnet min difficulty was 0.125) + max-difficulty-protection rule that allows blocks to be mined at min difficulty if the block's timestamp is 20 minutes or more after the last block AND the block isn't on a difficulty-adjustment boundary. To make it easy to run either old code (using the old tesnet) and new code, the wallet and blockchain are stored in $DATADIR/testnet3 instead of $DATADIR/testnet. And to make it easy to find other testnet3-running nodes, the IRC channel used for bootstrapping is #bitcoinTEST3 (instead of #bitcoinTEST). The new testnet comes with a new blockchain that is full of interesting test cases. In particular, there are test cases for: + BIP16; early blocks were generated with a timestamp before the BIP16 switchover date, and there are transactions that test the BIP16 switchover rules + Most of the enabled Script opcodes. I created thousands of transactions that try to exercise edge cases in the Script interpreter. Missing are comprehensive tests for the signature opcodes and SIGHASH_ modes. + Block acceptance rules, including the rule on maximum block size, block times, etc (thanks to gmaxwell) If you're re-implementing Bitcoin then accepting the Mark III testnet blockchain is a good first test for compatibility. You'll still need to do a lot of work to make sure you reject the same set of invalid transactions or blocks as the original Bitcoin code. -- -- Gavin Andresen -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP22/getmemorypool
I think the sourceforge mailing list system had the hiccups this weekend; sorry for Pieter's messages appearing in your inbox multiple times, it is not his fault. I deleted the extra copies from the mailing list archives. As for the contents of his message, since this mailing list was not working discussion wandered into the pull request: https://github.com/bitcoin/bitcoin/pull/936 Assuming this mailing list is now fixed, I'd like to pull that discussion back here. The executive summary: Pieter and I feel like BIP 22 is overly complicated, and would like it to be simpler. I'd especially like to hear what people think will be the "will be used by lots of pool customers" features and what are the "will be used by less than 5% of pool customers" features. -- -- Gavin Andresen -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Raw Transaction RPC calls for bitcoind
x : raw transaction with signature(s) (hex-encoded string)
complete : 1 if transaction has a complete set of signature (0 if not)
E.g.: signrawtx
"010001334208fbabeea988af229a0be667b2b775fde3f5b59180bbf7208844a26ee4fc000100f2052a01001976a9146e0920fc26383dc7e6101bc417cf87169d0cedbd88ac"
'["0100016d40da062b6a0edcaf643b6e25b943baf103941589d287e39d6f425d84ae8b1c4847304402203fb648ff8381d8961e66ef61ab88afe52826a5179b8a7312742c8d93785ca56302204240ea12de1211fffab49686f13ca0e78011d1985765be6e6aa8e747852f897d010100f2052a010017a914f96e358e80e8b3660256b211a23ce3377d2f9cb187"]'
Returns:
{
"rawtx" :
"010001334208fbabeea988af229a0be667b2b775fde3f5b59180bbf7208844a26ee4fc9100473044022007f3ba1b8bdc156f2340ef1222eb287c3f5481a8078a8dad43aa09fd289ba19002201cc72e97406d546dc918159978dc78aee8215a6418375956665ee44e6eacc1150147522102894ca6e7a6483d0f8fa6110c77c431035e8d462e3a932255d9dda65e8fada55c2103c556ef01e89a07ee9ba61581658fa007bf442232daed8b465c47c278550d3dab52ae0100f2052a01001976a9146e0920fc26383dc7e6101bc417cf87169d0cedbd88ac",
"complete" : false
}
sendrawtx
Submits raw transaction (serialized, hex-encoded) to local node and network.
E.g.: sendrawtx
010001334208fbabeea988af229a0be667b2b775fde3f5b59180bbf7208844a26ee4fc9100473044022007f3ba1b8bdc156f2340ef1222eb287c3f5481a8078a8dad43aa09fd289ba19002201cc72e97406d546dc918159978dc78aee8215a6418375956665ee44e6eacc1150147522102894ca6e7a6483d0f8fa6110c77c431035e8d462e3a932255d9dda65e8fada55c2103c556ef01e89a07ee9ba61581658fa007bf442232daed8b465c47c278550d3dab52ae0100f2052a01001976a9146e0920fc26383dc7e6101bc417cf87169d0cedbd88ac
Returns:
error: {"code":-22,"message":"TX rejected"}
(Rejected because it doesn't have all required signatures, if it was
accepted it would return the transaction id)
--
--
Gavin Andresen
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Raw Transaction RPC calls for bitcoind
On Thu, Jun 14, 2012 at 10:37 AM, Peter Vessenes wrote: > This is super cool! > > I have a feature request: it would be awesome to be able to provide private > keys at the command line with the signature, turning the client into a > wallet-less signature machine. I like that idea. A third argument that is an array of private keys (in the same format as the dumpprivkey RPC call) should be easy to support, assuming the semantics are: + If third argument given, do not require that the wallet be unlocked, and only sign using the private key(s) given (ignore the bitcoind wallet entirely). + Private keys would stay in bitcoind memory only for the duration of the RPC call. -- -- Gavin Andresen -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Near-term scalability
> (1) Change the mining code to group transactions together with their > mempool dependencies and then calculate all fees as a group. I think there is general consensus this is a good idea. > (2) SatoshiDice should use the same fee algorithms as Bitcoin-Qt to > avoid paying excessive fees and queue-jumping. Guess that's on my > plate. I don't think the problem is with SatoshiDice, but is with the current fixed/inflexible fee rules: I've been thinking about fees a lot the last couple of days, and I'm close to making a formal proposal. Here are my thoughts so far: It seems to me there are two typical use cases: Case 1: I want my transaction to be confirmed quickly, and am willing to pay a fee to make that happen. Case 2: I want my transaction to be confirmed eventually. I'd rather not pay, unless I have to. I don't think the current code handles those two cases as well as it could; here's a proposal to fix that: o Let miners decide on how many free transactions they'll support, by letting them specify how much of each block to set aside for 'free' transactions (bytes) and what the threshold for 'free' is (bitcoins/kilobyte). I think a new RPC call to get/set the parameters dynamically is the right way to go. o Change the block creation code to calculate a bitcoin-fee-per-kilobyte for each transaction, where the fee and size are both calculated based on the transaction and it's dependent descendants (so we get the receiver-can-opt-to-pay-the-fee behavior we want). Order transactions so highest-paying get into the non-free space first. o Fill up the "free" space (if any) with the highest-priority transactions, where priority is a function of transaction size, age of inputs, number of bitcoins... and ratio of inputs to outputs (to encourage combining inputs so more pruning is possible). The fee-paying space in a block lets Use Case #1 users compete to make their fees high enough to get into the block. The free space should let non-spamming Use Case #2 users (who don't send a lot of transactions, and so have well-aged, high-priority inputs) send transactions for free, at least as long as there are miners willing to accept free transactions. The question is: how do clients suggest fees to users if miners might have very different fee policies? I think full, transaction-verifying clients can watch how long transactions stay in the memory pool to figure it out. I'm gathering statistics right now to test a couple of simple heuristic algorithms for reasonable fee/priority policies. But that won't work for newly started clients that haven't seen a lot of transactions enter/exit the memory pool, or SPV clients that can't lookup transaction inputs (so can't calculate what fees are being paid -- and once we have bloom filters may not be paying attention anything but their own transactions, anyway). I'm still thinking about that. Maybe a new p2p network command: you give me a list of block hashes, I tell you average fees paid per kilobyte for fee-paying transactions in those blocks, and minimum and average priority of free transactions in those blocks. Maybe the big mining pools all publish their fee policies and that information somehow gets to clients (encoded in the coinbase? ... but they have a strong incentive to lie to try put upward pressure on fees... ). Maybe each client developer runs a "fee policy server" and clients periodically ask it for reasonable fee rules (HTTP fetch info from a web page that is updated as often or infrequently as is convenient, maybe). I think I like this solution the best, it should let clients compete to have the smartest/bestest algorithms for saving their user's money on transaction fees. -- -- Gavin Andresen -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] After compressed pubkeys: hybrid pubkeys
RE: 0x06/0x07 'hybrid' public keys: > Any opinions? Forbidding it certainly makes alternative implementation > slightly easier in the future, but I'm not sure the hassle of a network > rule change is worth it. I say treat any transactions that use them as 'non-standard' -- don't relay/mine them by default, but accept blocks that happen to contain them. I agree that a rule change isn't worth it right now, but making them non-standard now is easy and should make a rule change in the future easier. -- -- Gavin Andresen -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] LevelDB benchmarking
> OK, to make progress on this work I need a few decisions (Gavin?) > > 1) Shall we do it? What problem does it solve? If the problem it will solve is "it will only take 4 hours to download the entire blockchain next year instead of taking 16 hours" then no, I don't think we should do it, both 4 and 16 hours to get fully up and running is too long. If the problem it will solve is the "too easy to get a DB_RUNRECOVERY error" because bdb is fragile when it comes to its environment... then LevelDB looks very interesting. If the problem is bdb is creaky and old and has obscure semantics and a hard-to-work-with API, then yes, lets switch (I'm easily seduced by a pretty API and blazing fast performance). > 2) LevelDB is obscure, new and has a very minimalist build system. It > supports "make" but not "make install", for example, and is unlikely > to be packaged. It's also not very large. I suggest we just check the > source into the main Bitcoin tree and link it statically rather than > complicate the build. As long as it compiles and runs on mac/windows/linux that doesn't really worry me. I just tried it, and it compiled quickly with no complaints on my mac. Lack of infrastructure because it is new does worry me; for example, could I rework bitcointools to read the LevelDB blockchain? (are there python bindings for LevelDB?) > 3) As the DB format would change and a slow migration period > necessary, any other tweaks to db format we could make at the same > time? Right now the key/values are the same as before, though using > satoshi serialization for everything is a bit odd. Satoshi rolled his own network serialization because he didn't trust existing serialization solutions to be 100% secure against remote exploits. Then it made sense to use the same solution for disk serialization; I don't see a compelling reason to switch to some other serialization scheme. Modifying the database schema during migration to better support applications like InstaWallet (tens of thousands of separate wallets) or something like Pieter's ultra-pruning makes sense. -- -- Gavin Andresen -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP 34: Block v2, Height in Coinbase
> But those issues are solvable through other, non-backwards incompatible > means. For example, mandate that a refers > to the first such pair that is not already spent. No? Yes, that is essentially what BIP 30 did. We want to do this also, partly for "belt and suspenders" security but mostly for two reasons: 1. To test using block/transaction version numbers to smoothly roll out changes. The next change we need to make might be prompted by some crisis; better to learn any lessons now, when we have the luxury of time to fix problems that might crop up. 2. We think we'll all appreciate the change in a year or three, when the whole network has upgraded and we can start writing code that assumes all new blocks past a certain checkpoint contain their height; that should make it easier to do things like figure out whether or not an orphan chain can possibly be part of the main chain. -- -- Gavin Andresen -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Reconsidering block version number use
> The current block height in coinbase addition currently proposes to use block > version 2. However, the protocol change is in fact to the coinbase > transaction, not the block itself (which really doesn't have any extensibility > without a hardfork anyway). Perhaps we should consider bumping the coinbase > transaction version number to 2 for this instead? I'd thought about bumping the coinbase transaction version, but the problem is if we want a smooth rollout then, during the rollout, every time a new block comes in the percentage of the last 1,000 blocks that support the new version has to be computed. If that means looking in the coinbase transaction, then either the last 1,000 coinbases have to be stored in memory or they have to be fetched from disk. Which isn't a huge deal, unless we start aggressively pruning spent transactions, and that coinbase 900 blocks back got spent and pruned. On Sun, Jul 22, 2012 at 4:52 PM, Luke-Jr wrote: > It just occurred to me that the block version number could easily be used as a > cheap "extra nonce" right now. Considering that we will probably see lots of > ASIC miners running at 1 TH/s per rig before the end of 2012, it might be > desirable to save the block version for this purpose. Hmm... I think it'd be ok to give 3 of the 4 block version bytes as a simple extranonce, so version=0x0001 is what we have now, version 2 blocks are any with 0x02 in the low byte, 0x03 is version 3, etc. I don't think we'll go through 253 block versions before we're all dead. That'd be 7 bytes of nonce in the block header, which is 72,057,594,037,927,936 ~ 72 petahashes = 72,000 terahashes So: the changes for version 2 blocks would be "has height in the coinbase, and has a 1-byte version number with a 3-byte extranonce." > Also, Jeff noticed that block 190192 has version==2 without a valid block > height in the coinbase. I suspect this may be the result of combining the > current blockheight-in-coinbase pullreq with P2Pool. This means that if we go > forward with the version==2 marker, we will forever need to make an exception > for that block. No, the rules are "enforce the rules when the chain has a super-majority." Since block 190192 is in a part of the chain with zero other version==2 blocks, the height-in-the-coinbase rule will not be enforced. -- -- Gavin Andresen -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] script tests - invalid script in script_valid.json?
> Is there interest to port more tests (P2SH, checksig, checkmultisig, > block verification, maybe even DoS rules) into data-driven format? It > might be something that I'd like to help with if pull requests in that > direction are welcome. Yes, more tests are definitely welcome. check*sig tests are tricky, because they have to refer to previous unspent transactions and private keys (so require a particular block chain to test against). Brilliant ideas on a simple data-driven format welcome. block verification tests would be great; a collection of good/bad block chains, starting from a common chain (maybe the testnet3 tesnet-in-a-box chain) would be very useful for regression testing. -- -- Gavin Andresen -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Please help test: 0.7.0 release candidate 1
Bitcoin version 0.7.0 release candidate 1 binaries are now available for download at: http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.7.0/test/ Please use the issue tracker at https://github.com/bitcoin/bitcoin/issues to report bugs. Notable changes: Qt GUI -- * Add UI RPC console / debug window * Re-Enable URI handling on Windows, add safety checks and tray-notifications * Add 2 labels to the overviewpage that display Wallet and Transaction status (obsolete or current) * Extend the optionsdialog (e.g. language selection) and re-work it to a tabbed UI * Merge sign/verify message into a single window with tabbed UI * Improve error reporting at startup * Fine-grained UI updates for a much smoother UI during block downloads * Reorganize tray icon menu into more logical order * Persistently poll for balance change when number of blocks changed * Much better translations * Added 'immature balance' display on the overview page * (Windows only): enable ASLR and DEP for bitcoin-qt.exe * (Windows only): add meta-data to bitcoin-qt.exe (e.g. description) Bitcoin Improvement Proposals implemented - BIP 22 - 'getblocktemplate', 'submitblock' RPCs JSON-RPC API * Internal HTTP server is now thread-per-connection, rather than a single-threaded queue that would stall on network I/O. * Internal HTTP server supports HTTP/1.1, pipelined requests and connection keep-alive. * Support JSON-RPC 2.0 batches, to encapsulate multiple JSON-RPC requests within a single HTTP request. * IPv6 support * Added raw transaction API. See https://gist.github.com/2839617 * Added 'getrawmempool', to list contents of TX memory pool * Added 'getpeerinfo', to list data about each connected network peer * Added 'listaddressgroupings' for better coin control * Rework gettransaction, getblock calls. 'gettransaction' responds for non-wallet TXs now. * Remove deprecated RPC 'getblocknumber' * New blockchain checkpoint at block 193,000 * listtransactions output now displays "smart" times for transactions, and 'blocktime' and 'timereceived' fields were added P2P networking -- * IPv6 support * Tor hidden service support * Attempts to fix "stuck blockchain download" problems * Replace BDB database "addr.dat" with internally-managed "peers.dat" file containing peer address data. * Lower default send buffer from 10MB to 1MB * proxy: SOCKS5 by default * Support connecting by hostnames passed to proxy (-proxydns) * Add -seednode connections, and use this for -dnsseed + -proxydns * Added -externalip and -discover * Add -onlynet to connect only to a given network (IPv4, IPv6, or Tor) * Separate listening sockets, -bind= Internal codebase - * Additional unit tests * Compile warning fixes Miscellaneous - * Reopen debug.log upon SIGHUP * Bash programmable completion for bitcoind(1) * On supported OS's, each thread is given a useful name Thanks to everybody who contributed to this release: === Chris Moore Christian von Roques David Joel Schwartz Douglas Huff Fordy Gavin Andresen Giel van Schijndel Gregory Maxwell Jeff Garzik Luke Dashjr Matt Corallo Michael Ford Michael Hendricks Peter Todd Philip Kaufmann Pieter Wuille R E Broadley Ricardo M. Correia Rune K. Svendsen Scott Ellis Stephane Glondu Wladimir J. van der Laan cardpuncher coderrr fanquake grimd34th sje397 xanatos -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Bitcoin-Qt/bitcoind version 0.7 released
oother UI during block downloads * Remove autocorrection of 0/i in addresses in UI * Reorganize tray icon menu into more logical order * Persistently poll for balance change when number of blocks changed * Much better translations * Override progress bar design on platforms with segmented progress bars to assist with readability * Added 'immature balance' display on the overview page * (Windows only): enable ASLR and DEP for bitcoin-qt.exe * (Windows only): add meta-data to bitcoin-qt.exe (e.g. description) Internal codebase - * Additional unit tests * Compile warning fixes Miscellaneous - * Reopen debug.log upon SIGHUP * Bash programmable completion for bitcoind(1) * On supported OS's, each thread is given a useful name -- Thanks to everybody who contributed to this release: Chris Moore Christian von Roques David Joel Schwartz Douglas Huff Fordy Gavin Andresen Giel van Schijndel Gregory Maxwell Jeff Garzik Luke Dashjr Matt Corallo Michael Ford Michael Hendricks Peter Todd Philip Kaufmann Pieter Wuille R E Broadley Ricardo M. Correia Rune K. Svendsen Scott Ellis Stephane Glondu Wladimir J. van der Laan cardpuncher coderrr fanquake grimd34th sje397 xanatos Thanks to Sergio Lerner for reporting denial-of-service vulnerabilities fixed in this release. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin Testing Project
There are test cases that can be automated. That's Jenkins, and those will be run automagically. Then there are tests that cannot be automated; things like "Does the GUI look OK on all of the platforms that we support (Windows XP/2000/Vista/7/8, Ubuntu/Debian blah with window managers foo and bar, OSX 10.5/6/7/8)." Thanks to Matt, we're doing great with automated functional test cases (can always do better, of course). We're failing on simple, boring stuff like making sure we actually run on all of the platforms that we say we run on BEFORE final release. That is where I think a QA team can add a lot of value. Steve: I'm worried you're over-designing The Process. A release acceptance test plan could be nothing more than a step-by-step checklist on a wiki page, Google Doc, or Drobox shared folder... -- -- Gavin Andresen -- How fast is your code? 3 out of 4 devs don\\\'t know how their code performs in production. Find out how slow your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219672;13503038;z? http://info.appdynamics.com/FreeJavaPerformanceDownload.html___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment protocol thoughts
I agree we need a payment protocol, but instead of thinking of all of the things we might possibly want I would like to solve a few boring problems that we have right now. Absolutely critical: + Bitcoin addresses by themselves are insecure against man-in-the-middle attacks. We need a payment protocol so if you get a donation link for "Bitcoin Foundation" in an email message and click on it you can be reasonably certain that your coins will actually go to the Foundation and not some hacker at your ISP that modified the email message. + After sending payment I should have a receipt that proves I followed the payee's instructions, so if the payee says they never received the funds I can prove that it wasn't my fault. + Protocol for gathering signatures from multiple devices (extension/variation of the basic payment protocol, I think). Not absolutely necessary, but I think v1 should have it anyway: + Where-to-send-refund information included with payments, so overpayments/refunds can be handled efficiently and displayed intelligently in the customer's wallet. Everything else I think can wait. -- -- Gavin Andresen -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: Re: Bitcoin Testing Project
I had hope the Testing Project would be self-organizing, with somebody taking on the QA lead role and figuring out the hard questions like: + How to do fundraising? + If/when bitcoins are available, how to decide who gets rewarded for what? + If somebody wants to help, how do they start? Steve jumped in and started creating a gazillion tests cases, which is great, but creating test cases isn't the hard part. Creating a "community" of testing that gets things done is the hard part that I, frankly, don't have time to do. I hoped that the BetterMeans platform would help, but it sounds like it was more of a hindrance than a help. Ok: live and learn. Failed experiment, lets move on... So, RE: moving on: I'd like to tag a 0.7.1rc1 release in the next few days (I'll start another thread about that). How about a very short-term goal of getting these QA deliverables: 1. A process for QA testers to sanity-test release builds, and sign-off as "Tested/problems found" or "Tested/OK" 2. Some place online I can look to see if all of our supported platforms have been tested before promoting a release candidate to "final release" PS: Thanks to Peter for responding to the "what's the relationship between the Foundation and the Testing Project" (executive summary: no relationship right now). -- -- Gavin Andresen -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] 0.7.1 release
There is consensus that we need to do a 0.7.1 release to fix the "click on a bitcoin: URI and nothing happens" bug on Windows. I would really like to fix the "I upgraded from a binary running an incompatible version of BDB and now I get a DB_RUNRECOVERY error on startup" problem, too, and I've got a pull request that fixes half of that problem (plus a bunch of other "my wallet is broken" cases): "Handle corrupt wallets gracefully" : https://github.com/bitcoin/bitcoin/pull/1895 This pull request: "Add -reindex, to perform in-place reindexing of blockchain data files" : https://github.com/bitcoin/bitcoin/pull/1870 ... could be the basis for fixing the other half of the problem (if blkindex.dat is bad, delete it and re-create it from the blk000?.dat files). Are there any other very-high-priority pull requests that should go into a 0.7.1 release? I'd like to pull: "P2P: Do not request blocks from peers with fewer blocks than us" : https://github.com/bitcoin/bitcoin/pull/1834 "In listaddressgroupings push down the IsMine check to run on each input." : https://github.com/bitcoin/bitcoin/pull/1872 ... and these which could be considered fixes to the new raw transactions API: "Add redeemScript to raw transactions API" : https://github.com/bitcoin/bitcoin/pull/1818 "Add new RPC "lockunspent", to prevent spending of selected outputs" : https://github.com/bitcoin/bitcoin/pull/1861 -- -- Gavin Andresen -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Public key and signature malleability
Any objections from other transaction-validating implementations? I strongly support more precisely defining the transaction validity rules by changing the reference implementation. -- -- Gavin Andresen -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Draft BIP for Bloom filtering
RE: sharing parts of the merkle branches when returning a 'merkleblock' : I think I agree that complicating the BIP for what should be a very rare case (more than a handful of transactions in a block match the transactions in your wallet) is the right decision. I want to make sure I'm understanding this bit correctly: "In addition, because a merkleblock message contains only a list of transaction hashes, any transactions that the requesting node hasn't either received or announced with an inv will be automatically sent as well. This avoids a slow roundtrip that would otherwise be required (receive hashes, didn't see some of these transactions yet, ask for them)." Requiring serving/relaying nodes to keep track of which transactions they have or have not sent to their peers makes me nervous. I think requiring an extra 'inv' round-trip would be simpler to implement and less likely to lead to some kind of DoS attack. -- -- Gavin Andresen -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Draft BIP for Bloom filtering
On Wed, Oct 24, 2012 at 3:10 PM, Mike Hearn wrote: > Bitcoin already keeps track of which nodes have seen what to avoid redundant > inv announcements. Oops, right. That memory usage is bounded right now by bounds on the memory pool size, though, right? (I'm being lazy and not digging into that code) What is the worst-case for an attacker interested in trying to get you to saturate your upstream bandwidth or use lots of memory? Set a bloom filter that matches everything, and then start requesting old blocks in the chain? It would be nice if the worst-case was no worse than the worst-case we've got now (... requesting full, old blocks...). -- -- Gavin Andresen -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] IRC meeting agenda, 18:00 UTC Thursday
Thursdays at 18:00 UTC (6PM Europe/1PM east US/10AM west US) seem to be a good time for the core dev team to meet on the #bitcoin-dev freenode IRC channel to chat. I'd like to talk about: o Can we put together a TODO list to get to a 0.8 release candidate ? o Is it time to feature-freeze 0.8 and work on just testing the new features and fixing existing bugs (the issues list keeps getting longer and longer ... )? o BIP process: are we happy with how it is working? What can we do to improve it? What else should we talk about? -- -- Gavin Andresen -- LogMeIn Central: Instant, anywhere, Remote PC access and management. Stay in control, update software, and manage PCs from one command center Diagnose problems and improve visibility into emerging IT issues Automate, monitor and manage. Do more in less time with Central http://p.sf.net/sfu/logmein12331_d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
This is the next big "lets all agree to do things the same way" thing
I think we should tackle. I'm particularly looking for feedback from
other bitcoin client developers, even if it is just a quick "looks
reasonable, if everybody else is going to do it then I will
(eventually) too..."
Thanks to Pieter Wuille and Mike Hearn for lots of feedback and
suggestions and brainstorming.
This document is online at https://gist.github.com/4120476
If you respond to this message, please be considerate of people who
subscribe to the digest version of this mailing list and trim your
response.
Invoices, Payments and Receipts for Bitcoin Transactions
This document proposes protocol buffer-based formats for signed,
authenticated "invoices" and "receipts" -- requests for payment, and
proof-of-payment.
Separate documents propose an extension to the Bitcoin URI syntax and
new MIME types to support them.
Motivation
==
The idea of a "payment protocol" to improve on Bitcoin addresses has
been around for over a year. Users have been asking for some features
in this proposal (like the ability to provide a refund address so
overpayments or refunds can be returned to customers without the need
to ask them for their address) for two or three years, and have
started to work around shortcomings in the Bitcoin payment process
with creative (but inefficient) uses of transactions.
The key features of this proposal are:
+ Requests for payment (Invoices) are tied to authenticated identities
using the only widely-deployed identity authentication system we have
right now (X.509 certificates signed by root certificate authorities)
+ Invoices include a user-friendly description of what the payment is for
+ Payments include where refunds should be sent
+ At the end of the payment process, the customer holds a
cryptographically signed Receipt that can be used as proof-of-payment
if there is any dispute with the merchant.
Specification
=
Invoice/SignedInvoice
-
An Invoice is a request for payment from a merchant to a customer:
::
message Output {
optional uint64 amount = 1;
required bytes script = 2;
}
amount: Number of satoshis (0.0001 BTC) to be paid. If not given
or zero, then the customer will be asked how much to pay.
script: a "TxOut" script to which the customer should direct payment.
This will normally be one of the standard Bitcoin transaction script
(e.g. pubkey OP_CHECKSIG).
::
message Invoice {
repeated bytes x509chain = 1;
repeated Output outputs = 2;
required uint64 time = 3;
optional uint64 expires = 4;
optional bool single_use = 5 [default = true];
optional string memo = 6;
optional string receiptURI = 7;
optional bytes merchant_data = 8;
}
outputs: one or more outputs where Bitcoins are to be sent.
x509chain: one or more DER-encoded X.509 certificates that identifies
the merchant. See the "Certificates" section below for details.
time: Unix timestamp (seconds since 1-Jan-1970) when the Invoice was created.
expires: Unix timestamp after which the Invoice should be considered
invalid. If not given, the Invoice may be re-used until the earliest
certificate expiration date in the X509chain.
single_use: If true, this Invoice should be used for only one payment.
If false, it may be added to the user's address book and used
repeatedly until it expires (e.g. for donations or a recurring
payment).
memo: UTF-8 encoded, plain-text (no formatting) note that should be
displayed to the customer, explaining what this Invoice is for.
receiptURI: Secure (https) URI where a Payment message (see below) may
be sent to obtain a SignedReceipt as proof-of-payment.
merchant_data : Arbitrary data ignored by the client that may be used
by the merchant to identify the Invoice.
::
message SignedInvoice {
required Invoice invoice = 1;
required bytes signature = 2;
}
A SignedInvoice is an Invoice signed using the private key
corresponding to the public key in the first certificate in the
x509chain and the HMAC SHA-256 algorithm.
When a Bitcoin client receives a SignedInvoice, it must authorize
payment by doing the following:
1. Validate the x509chain certificate chain up to it's list of root
certificate authorities
2. Validate that the time on the customer's system is before Invoice.expires
3. Display the "Common Name" (CN) string from the first x509chain
certificate and ask the customer if they would like to submit payment
Payment
---
::
message Payment {
required Invoice invoice = 1;
repeated bytes transactions = 2;
repeated Output refund_to = 3;
optional string memo = 4;
}
invoice : the invoice received from the merchant. A merchant must
validate the Invoice and may reject the Payment if the Invoice was
altered by the customer.
transactions : One or more vali
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
RE: SignedReceipt: I agree it is superfluous. I'll remove it from the spec. RE: "it is controversial use of the host key to use it for digital signing of documents" : The idea of embedding a x509 certificate chain comes from the IETF's JSON Object Signing and Encryption working group "JWS" specification, so I can't be TOO controversial. RE: the ifex-project and other electronic invoicing standards: Thanks for the pointers, Walter! I'm all for adopting the best ideas that have come before, as long as we end up with something useful and small enough to convince ourselves it is as secure as we can make it. I looked at the ifex spec, and quickly got lost. It would help me if you could write up what our motivating use cases would look like if implemented on top of ifex. RE: jgarzik's suggestion to allow txids in the Payment: that worries me, because it is trivial to create several different variations of the same transaction (same inputs to same outputs) with different txids (re-signing inputs uses a different signature nonce, which changes the signature/txid, for example). RE: using self-signed certificates: as Mike said, I assume Bitcoin clients will have some way of managing root certificates, so experts could add trusted self-signed certs. -- -- Gavin Andresen -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
One more thought: RE: "Receipt" verus "Acceptance" : I believe "Receipt" is the right term-- it means "I got your payment", NOT "your payment has cleared." E.g. if I hand a merchant a paper check they'll hand me a receipt, but the check could still bounce. That's the analogy here-- a merchant might give you a receipt, but if the transaction is rejected by the network for whatever reason (Finney attack maybe) you cannot expect to go to court with your invoice/receipt and claim you made a valid payment. -- -- Gavin Andresen -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
Spec updated: https://gist.github.com/4120476 Notable changes are: + Removed SignedReceipt + Replaced Invoice.x509chain with a "pki_type" and "pki_data" to make using other identity systems cleaner. + Added a "Why not an existing electronic invoice standard?" section to the design notes -- -- Gavin Andresen -- Keep yourself connected to Go Parallel: DESIGN Expert tips on starting your parallel project right. http://goparallel.sourceforge.net ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
RE: Changing SignedInvoice's invoice field to 'bytes serialized_invoice': Good Idea, I agree it will avoid potential issues. I think it then makes sense to pull the pki_type and pki_data into SignedInvoice, too, and specify that the signature is on the SHA256-HMAC of pki_type, pki_data, and serialized_invoice (being careful to combine them in a way that is secure). RE: Changing Payment to include just merchant_data and not the entire Invoice: Agreed, good idea. RE: Mr. Stanish's suggestion to punt all of this and wait for a Grand Unified Solution: No, we have problems that need a solution right now. And, having written one (I was the lead author of the ISO/IEC 14772-1 international standard) I'm very pessimistic about your chances for anything like IFEX to actually be adopted. -- -- Gavin Andresen -- Keep yourself connected to Go Parallel: INSIGHTS What's next for parallel hardware, programming and related areas? Interviews and blogs by thought leaders keep you ahead of the curve. http://goparallel.sourceforge.net ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
