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 mor...@gmail.com 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] 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] 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 . rayst...@hotmail.com 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] Fwd: Block Size Increase Requirements
On Sun, May 31, 2015 at 6:55 PM, Alex Mizrahi alex.mizr...@gmail.com 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 jjlegou...@gmail.com 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] Block Size Increase Requirements
On Sun, May 31, 2015 at 10:59 AM, Jorge Timón jti...@jtimon.cc 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 kiw...@yahoo.com 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] Block Size Increase Requirements
On Sun, May 31, 2015 at 3:05 AM, Peter Todd p...@petertodd.org 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] Block Size Increase Requirements
On Sun, May 31, 2015 at 10:46 AM, Jorge Timón jti...@jtimon.cc 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 alex.mizr...@gmail.com 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 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] 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] 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 bitcoin-l...@bluematt.me 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] Proposed alternatives to the 20MB step function
On Fri, May 29, 2015 at 10:09 AM, Tier Nolan tier.no...@gmail.com 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] Proposed alternatives to the 20MB step function
On Thu, May 28, 2015 at 1:34 PM, Mike Hearn m...@plan99.net 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 stepfunction
On Thu, May 28, 2015 at 1:59 PM, Pieter Wuille pieter.wui...@gmail.com 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
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] [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 tier.no...@gmail.com 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 a...@cypherspace.org 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] 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 thom...@electrum.org 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] 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] 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 gmaxw...@gmail.com 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] 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
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
[Bitcoin-development] Fwd: Block Size Increase
On Thu, May 7, 2015 at 1:26 PM, Matt Corallo bitcoin-l...@bluematt.me 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] 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
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 pieter.wui...@gmail.com 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] 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 m...@plan99.net 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
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] BIP70: why Google Protocol Buffers for encoding?
On Mon, Jan 19, 2015 at 3:40 PM, Mike Hearn m...@plan99.net 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] Serialised P2SH HD chains
On Thu, Dec 4, 2014 at 10:42 AM, Luke Dashjr l...@dashjr.org 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=164703151iu=/4140/ostg.clktrk___ 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 pieter.wui...@gmail.com 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] 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 mor...@gmail.com 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] 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] 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] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time
On Sat, Oct 4, 2014 at 8:58 AM, Mike Hearn m...@plan99.net 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=154622311iu=/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
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=154622311iu=/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 l...@dashjr.org 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=154622311iu=/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 etothe...@gmail.com 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=154622311iu=/4140/ostg.clktrk___ 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] 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 kezi...@gmail.com 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
[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] Proposed BIP 70 extension
On Tue, Jun 24, 2014 at 3:00 PM, Gmail will.ya...@gmail.com 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] 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
[Bitcoin-development] Working on social contracts (was: Paper Currency)
On Mon, May 19, 2014 at 2:20 PM, Justus Ranvier justusranv...@gmail.comwrote: 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 to change payment protocol signing
There is a discussion about clarifying how BIP70 signs payment requests here: https://github.com/bitcoin/bips/pull/41 The issue is what to do with the signature field before signing. The code Mike and I initially wrote does this: request.set_signature(string()); (sets signature to the empty string) I think that is a mistake; it should be: request.clear_signature(); (clears signature field, so it is not serialized at all). So: if you are implementing, or have implemented, the payment protocol, please chime in. I'd like to change the spec and the reference implementation NOW, while BIP70 is still a 'Draft'. Because this type of hey, I'm implementing your standard and it doesn't work the way I think it should mistake is exactly why BIPs take a while before being declared 'Final.' -- -- 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] Error handling in payment protocol (BIP-0070 and BIP-0072)
The main area of concern is handling unexpected problems while sending the Payment message, or receiving the corresponding PaymentACK message. For example, in case of a transport layer failure or non-200 HTTP status code while sending the Payment message, what should the wallet software do next? Is it safe to re-send the Payment message? I'd propose that for any transport failure or 500 status code, the client retries after a delay (suggested at 30-60 seconds). For 400 status codes, the request should not be repeated, and as such the user should be alerted and a copy of the Payment message saved to be resent later. Why does error handling have to be standardized? I generally think that wallet software should be free to do whatever gives the user the best experience, so I'm in favor of restricting BIPs to things that must be standardized so that different implementations inter-operate. For 300 (redirect and similar) status codes, is it considered safe to follow redirects? I think we have to, but good to make it clear in the specification. Referencing whatever RFCs defines how to fetch URLs would be the best way to do this. Submit a pull request. On the merchant's side; I think it would be useful for there to be guidance for handling of errors processing Payment messages. I'd suggest that Payment messages should have a fixed maximum size to avoid merchant systems theoretically having to accept files of any size; 10MB would seem far larger than in any way practical, and therefore a good maximum size? PaymentRequests are limited to 50,000 bytes. I can't think of a reason why Payment messages would need to be any bigger than that. Submit a pull request to the existing BIP. A defined maximum time to wait (to avoid DDoS via connection holding) might be useful too, although I'd need to do measurements to find what values are tolerable. Implementation detail that doesn't belong in the spec, in my humble opinion. I would like to have the protocol state that merchant systems should handle repeatedly receiving the same Payment message, and return an equivalent (if not identical) PaymentACK to each. This is important in case of a network failure while the client is sending the Payment message, as outlined above. I think this should be left to implementations to work out. Lastly, I'm wondering about potential timing issues with transactions; if a merchant system wants to see confirmation of a transaction before sending a PaymentACK... not a good idea. The user should get feedback right away. Poking a pay now button and then waiting more than a second or three to get your payment has been received and is being processed is terrible UI. -- -- Gavin Andresen -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
I've formulated my replies to you and this proposal in a more public venue, where such discussions of existential changes to the protocol more rightfully belong I strongly disagree. It makes perfect sense to discuss changes here, first, where there are lots of people who understand how the system works at a very detailed level. And why do you think your blog is more public than this open, publicly archived mailing list??? -- -- Gavin Andresen -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Timed testing
On Thu, Apr 17, 2014 at 12:09 PM, Jorge Timón jti...@monetize.io wrote: So it seems a new mode only makes sense if the -private mode makes sense, which in turn only makes sense to include in bitcoind if it's useful enough for the network attack simulations, which remains the open question. Unless I misunderstood what your private mode does, you can get the same effect with -regtest by just controlling nodes connectivity. For example: Start 2 nodes, connected to each other. Mine a -regtest chain they both agree on. Restart them so they're not connected. Have one mine normally, have the other mine... however you like to simulate some attack (deep chain re-org, double-spend, whatever). To simulate launching the attack, connect them together again, let the two chains compete and see what happens. -- -- Gavin Andresen -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] 0.9.1 released
Bitcoin Core version 0.9.1 is now available from: https://bitcoin.org/bin/0.9.1/ This is a security update. It is recommended to upgrade to this release as soon as possible. It is especially important to upgrade if you currently have version 0.9.0 installed and are using the graphical interface OR you are using bitcoind from any pre-0.9.1 version, and have enabled SSL for RPC and have configured allowip to allow rpc connections from potentially hostile hosts. Please report bugs using the issue tracker at github: https://github.com/bitcoin/bitcoin/issues How to Upgrade -- If you are running an older version, shut it down. Wait until it has completely shut down (which might take a few minutes for older versions), then run the installer (on Windows) or just copy over /Applications/Bitcoin-Qt (on Mac) or bitcoind/bitcoin-qt (on Linux). If you are upgrading from version 0.7.2 or earlier, the first time you run 0.9.1 your blockchain files will be re-indexed, which will take anywhere from 30 minutes to several hours, depending on the speed of your machine. 0.9.1 Release notes === No code changes were made between 0.9.0 and 0.9.1. Only the dependencies were changed. - Upgrade OpenSSL to 1.0.1g. This release fixes the following vulnerabilities which can affect the Bitcoin Core software: - CVE-2014-0160 (heartbleed) A missing bounds check in the handling of the TLS heartbeat extension can be used to reveal up to 64k of memory to a connected client or server. - CVE-2014-0076 The Montgomery ladder implementation in OpenSSL does not ensure that certain swap operations have a constant-time behavior, which makes it easier for local users to obtain ECDSA nonces via a FLUSH+RELOAD cache side-channel attack. - Add statically built executables to Linux build Credits Credits go to the OpenSSL team for fixing the vulnerabilities quickly. -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP 70 refund field
On Fri, Mar 28, 2014 at 9:18 AM, Tamas Blummer ta...@bitsofproof.comwrote: May I ask how the current payment protocol is supposed to handle salaries? It doesn't. walk before you run and all that; lets see what problems we run into with the minimal payment protocol we have now (like refund outputs you have to remember forever) before we create an insurmountable set of problems by trying to solve everything we can think of all at once. -- -- Gavin Andresen -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Tree-chains preliminary summary
On Tue, Mar 25, 2014 at 8:28 AM, Peter Todd p...@petertodd.org wrote: Bitcoin doesn't scale. There's a lot of issues at hand here, but the most fundemental of them is that to create a block you need to update the state of the UTXO set, and the way Bitcoin is designed means that updating that state requires bandwidth equal to all the transaction volume to keep up with the changes to what set. Long story short, we get O(n^2) scaling, which is just plain infeasible. We have a fundamental disagreement here. If you go back and read Satoshi's original thoughts on scaling, it is clear that he imagined tens of thousands of mining nodes and hundreds of millions of lightweight SPV users. Scaling is a problem if every person is a fully validating node; then, indeed, you get an O(n^2) problem. Which can be solved by extending some tentative trust to your peers, but lets put all those possible solutions aside. Given tens of thousands of fully validating nodes, you get O(m*n), where m is the number of fully validating peers and is a large constant (10s of thousands). We don't know how large m can or will be; we have only just started to scale up. Bitcoin doesn't scale is pure FUD. It might not scale in exactly the way you want, but it WILL scale. -- -- Gavin Andresen Chief Scientist, Bitcoin Foundation https://www.bitcoinfoundation.org/ -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New side channel attack that can recover Bitcoin keys
Y'all are getting deep into tinfoil-wearing-hat-conspiracy-theory territory. If you are worried about the NSA compromising your hardware or software, then use multisig transactions and sign on diverse hardware/software stacks. Generate the multiple private keys on different hardware/software stacks, too. Or, in other words, eliminate the single point of failure and you will mitigate whole families of possible attacks, from NSA compromised the hardware random number generator in my CPU to NSA is listening to EMF radiation coming from my dedicated server in my data center to the much more likely data center employee is tricked into letting somebody have access to my dedicated server. -- -- Gavin Andresen -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fake PGP key for Gavin
On Sat, Mar 22, 2014 at 1:03 PM, Mike Hearn m...@plan99.net wrote: do we codesign the Windows binaries? Yes, the -setup.exe installers are Authenticode (or whatever Microsoft is calling that these days) code-signed. -- -- Gavin Andresen -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Bitcoin Core version 0.9.0 released
connections - Bump protocol version to 70002 - Add some additional logging to give extra network insight - Added new DNS seed from bitcoinstats.com Validation: - Log reason for non-standard transaction rejection - Prune provably-unspendable outputs, and adapt consistency check for it. - Detect any sufficiently long fork and add a warning - Call the -alertnotify script when we see a long or invalid fork - Fix multi-block reorg transaction resurrection - Reject non-canonically-encoded serialization sizes - Reject dust amounts during validation - Accept nLockTime transactions that finalize in the next block Build system: - Switch to autotools-based build system - Build without wallet by passing `--disable-wallet` to configure, this removes the BerkeleyDB dependency - Upgrade gitian dependencies (libpng, libz, libupnpc, boost, openssl) to more recent versions - Windows 64-bit build support - Solaris compatibility fixes - Check integrity of gitian input source tarballs - Enable full GCC Stack-smashing protection for all OSes GUI: - Switch to Qt 5.2.0 for Windows build - Add payment request (BIP 0070) support - Improve options dialog - Show transaction fee in new send confirmation dialog - Add total balance in overview page - Allow user to choose data directory on first start, when data directory is missing, or when the -choosedatadir option is passed - Save and restore window positions - Add vout index to transaction id in transactions details dialog - Add network traffic graph in debug window - Add open URI dialog - Add Coin Control Features - Improve receive coins workflow: make the 'Receive' tab into a form to request payments, and move historical address list functionality to File menu. - Rebrand to `Bitcoin Core` - Move initialization/shutdown to a thread. This prevents Not responding messages during startup. Also show a window during shutdown. - Don't regenerate autostart link on every client startup - Show and store message of normal bitcoin:URI - Fix richtext detection hang issue on very old Qt versions - OS X: Make use of the 10.8+ user notification center to display Growl-like notifications - OS X: Added NSHighResolutionCapable flag to Info.plist for better font rendering on Retina displays. - OS X: Fix bitcoin-qt startup crash when clicking dock icon - Linux: Fix Gnome bitcoin: URI handler Miscellaneous: - Add Linux script (contrib/qos/tc.sh) to limit outgoing bandwidth - Add '-regtest' mode, similar to testnet but private with instant block generation with 'setgenerate' RPC. - Add 'linearize.py' script to contrib, for creating bootstrap.dat - Add separate bitcoin-cli client Credits Thanks to everyone who contributed to this release: - Andrey - Ashley Holman - b6393ce9-d324-4fe1-996b-acf82dbc3d53 - bitsofproof - Brandon Dahler - Calvin Tam - Christian Decker - Christian von Roques - Christopher Latham - Chuck - coblee - constantined - Cory Fields - Cozz Lovan - daniel - Daniel Larimer - David Hill - Dmitry Smirnov - Drak - Eric Lombrozo - fanquake - fcicq - Florin - frewil - Gavin Andresen - Gregory Maxwell - gubatron - Guillermo Céspedes Tabárez - Haakon Nilsen - HaltingState - Han Lin Yap - harry - Ian Kelling - Jeff Garzik - Johnathan Corgan - Jonas Schnelli - Josh Lehan - Josh Triplett - Julian Langschaedel - Kangmo - Lake Denman - Luke Dashjr - Mark Friedenbach - Matt Corallo - Michael Bauer - Michael Ford - Michagogo - Midnight Magic - Mike Hearn - Nils Schneider - Noel Tiernan - Olivier Langlois - patrick s - Patrick Strateman - paveljanik - Peter Todd - phantomcircuit - phelixbtc - Philip Kaufmann - Pieter Wuille - Rav3nPL - R E Broadley - regergregregerrge - Robert Backhaus - Roman Mindalev - Rune K. Svendsen - Ryan Niebur - Scott Ellis - Scott Willeke - Sergey Kazenyuk - Shawn Wilkinson - Sined - sje - Subo1978 - super3 - Tamas Blummer - theuni - Thomas Holenstein - Timon Rapp - Timothy Stranex - Tom Geller - Torstein Husebø - Vaclav Vobornik - vhf / victor felder - Vinnie Falco - Warren Togami - Wil Bown - Wladimir J. van der Laan -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] 0.9.0rc3 tagged
Binaries for 0.9.0rc3 are available at: https://bitcoin.org/bin/0.9.0/test/ Please help sanity test. We will also need more 'gitian builders' for the final 0.9.0 release (Wladimir and I are the only builders so far for the rc3 binaries), so if you are running Linux or OSX and are willing to help please start up those virtual machines and start building dependencies. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Multisign payment protocol?
On Tue, Mar 11, 2014 at 8:38 AM, Jeff Garzik jgar...@bitpay.com wrote: On Tue, Mar 11, 2014 at 7:43 AM, Drak d...@zikula.org wrote: I very much like the idea of assuming each party uses HD wallets, that certainly simplifies things greatly. It also assumes a reality different from our current one. Multisig wallets are a different reality from our current one, so when we move to that new reality we should do it correctly from the beginning. -- -- Gavin Andrese -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Multisign payment protocol?
On Tue, Mar 11, 2014 at 10:13 AM, Jeff Garzik jgar...@bitpay.com wrote: Sure, but I don't see wallets being able to _assume_ _remote_ parties have an HD wallet for a long, long time. Interoperability common sense implies the environment will be heterogenous, perhaps forever, invalidating assume-each-party-uses-HD logic. If the remote party is one of the parties involved in a multisig, and speaks the Lets set up a multisig wallet together / Lets spend from a multisig protocols, then it should be perfectly reasonable to assume that they're HD-capable. Remote parties paying into a multisig, or receiving funds from a multisig, don't have to support it (that's what P2SH gives us). -- -- Gavin Andresen -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Multisign payment protocol?
In my experience, best process for standardizing something is: 1) Somebody has a great idea 2) They implement it 3) Everybody agrees, Great idea! and they copy it. 4) Idea gets refined by the people copying it. 5) It gets standardized. Mutisig wallets are at step 2 right now. BIP is step 5, in my humble opinion... On Mon, Mar 10, 2014 at 1:39 PM, Drak d...@zikula.org wrote: I was wondering if there would be merit in a kind of BIP for a payment protocol using multisig? Currently, setting up a multisig is quite a feat. Users have to exchange public keys, work out how to get the public keys from their addresses. If one of the parties are not savvy enough, an malicious party could easily be setup that was 2 of 3 instead of 2 of 2 where the malicious party generates the multisig address+script and thus be able to run off with funds anyway. It's also terribly complex to generate and keep track of. There's been a nice attempt at creating an browser interface at coinb.in/multisig but it still lacks the kind of ease with created by the payment protocol. If there was a BIP then it would go a long way to aiding future usability of multisig wallet implementations. What are your thoughts? Drak -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- -- Gavin Andresen -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Multisign payment protocol?
Multisig is orthogonal to the payment protocol (but payment protocol is needed first). There need to be protocols for: a) Establishing multisig wallets of various sorts. See: https://moqups.com/gavinandresen/no8mzUDB/ https://moqups.com/gavinandresen/no8mzUDB/p:ab18547e0 ... etc. for a UI mock-up. There needs to be some protocol so all participants in a multisig wallet contribute keys (actually, we should just assume everybody uses BIP32 HD public keys so we get privacy from the start). Multi-person shared wallets, escrows, and wallet protection service wallets (which might be protected with two-factor authentication) are different use cases and probably use slightly different protocols (and will probably need different BIPs eventually). b) Gathering signatures for a multisig spend. Here is where the payment protocol is useful; the PaymentRequest message should be passed around so all participants know what is being paid for, and maybe a partially-signed Payment message is where the signatures are gathered (or maybe the signatures are sent separately and one of the participants creates and submits the Payment and gets the PaymentACK... to be designed). See: https://moqups.com/gavinandresen/no8mzUDB/p:a7e81be96 https://moqups.com/gavinandresen/no8mzUDB/p:af7339204 ... for UI mock-up for the multi-person-spend case. And maybe a protocol for I don't want to be part of this multisig any more / I lost control of my private key don't trust me in this multisig any more. On Mon, Mar 10, 2014 at 8:14 PM, Jeff Garzik jgar...@bitpay.com wrote: All of that only melds with the payment protocol under an extremely expansive definition of payment. The payment protocol is really geared towards a direct one-to-one relationship -- Gavin Andresen -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] On OP_RETURN in upcoming 0.9 release
40 bytes is small enough to never require an OP_PUSHDATA1, too, which will make writing the OP_RETURN-as-standard BIP simpler. On Mon, Feb 24, 2014 at 11:39 AM, Wladimir laa...@gmail.com wrote: On Mon, Feb 24, 2014 at 5:03 PM, Jeff Garzik jgar...@bitpay.com wrote: A common IRC proposal seems to lean towards reducing that from 80. I'll leave it to the crowd to argue about size from there. I do think regular transactions should have the ability to include some metadata. I'd be in favor of bringing it down to 40 for 0.9. That'd be enough for 8 byte header/identifier32 byte hash. 80, as the standard line length, is almost asking for insert your graffiti message here. I also see no need for 64 bytes hashes such as SHA512 in the context of bitcoin, as that only offers 256-bit security (at most) in the first place. And if this is not abused, these kind of transactions become popular, and more space is really needed, the limit can always be increased in a future version. Wladimir -- -- Gavin Andresen -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability
I think we should get Pieter's proposal done and implemented quickly. I agree with Mike, it doesn't have to take a long time for the core network to fully support this. Getting wallets to start generating transaction.version=3 might take years, but that is OK. -- -- Gavin Andresen -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability
Great, I'm hearing rough consensus to proceed with Pieter's plan. RE: far from confident on malleability routes: I'm reasonably confident that we can squash malleability for IsStandard, SIGHASH_ALL transactions. A proper proof of DSA signature un-malleability (or an lower bound for how much work it would be to create a valid doppleganger signature) would be great, but I don't think it is necessary to proceed. On Thu, Feb 20, 2014 at 9:36 AM, Gregory Maxwell gmaxw...@gmail.com wrote: On Thu, Feb 20, 2014 at 6:29 AM, Gavin Andresen gavinandre...@gmail.com wrote: I think we should get Pieter's proposal done and implemented quickly. I agree with Mike, it doesn't have to take a long time for the core network to fully support this. Getting wallets to start generating transaction.version=3 might take years, but that is OK. Sure I'm all for doing what Pieter suggested-- it's basically the plan we've been executing for some time already but with the version check to make it sane to complete. My reserved sounding comments were relative to the proposals to do things with nversion=1 transactions, frankly I think thats completely insane. Though while we're on the subject of reservations, I am far from confident that we've uncovered all the possible malleability routes-- that list gained a new, never before discussed entry, when Pieter was writing it a couple weeks ago. We also have no proof of the absence of further algebraic malleability in DSA (though I think its somewhat unlikely, a solid proof of it has been somewhat elusive). -- -- Gavin Andresen -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Transaction malleability in the core code: update
A quick update on the state of transaction malleability work in Bitcoind/Bitcoin-Qt (aka Bitcoin Core). This is not about longer-term malleability issues, just the very short-term work being done (or already done) to the reference implementation. First, the problems: We've had a longstanding TODO to improve the way the core code deals with double-spends. From the core code's point of view, malleable transactions are just one particular form of double-spend. Improving double-spend handling never made it to the top of the TODO list, because the cases where it happened involved doing unsupported things (like copying your wallet.dat to another machine and then spending on both machines). And because there is a heavy-handed workaround if a wallet becomes confused because of a double-spend: restore all of the keys, rescan for transactions confirmed in the blockchain, and any outputs tied up in double-spends get released. Coins (really, unspent transaction outputs) were never permanently lost, but they could be tied up and unspendable when associated with a 0-confirmation transaction that would never confirm. So, work in progress or done: https://github.com/bitcoin/bitcoin/pull/3659 https://github.com/bitcoin/bitcoin/pull/3674 These implements a kinder, gentler sledgehammer (-zapwallettxes) to fix a confused wallet. If you have a wallet with 0-confirmation transactions that are tying up bitcoins these should fix it. https://github.com/bitcoin/bitcoin/pull/3651 https://github.com/bitcoin/bitcoin/pull/3657 https://github.com/bitcoin/bitcoin/pull/3676 These three merged pull requests implement a new command-line option: -nospendzeroconfchange . The best way to get a wallet confused is to spend zero-confirmation change outputs that you created yourself; if the transaction creating the change gets mutated, then the subsequent transaction is invalid and will never confirm. The core code spends unconfirmed change only as a last resort. If you are a service using bitcoind that generates a lot of transactions then best practice would be to run with -nospendzeroconfchange, and use sendmany to batch payments only after previous payments have confirmed. https://github.com/bitcoin/bitcoin/pull/3025 This tightens up the IsStandard() rule, so the easiest-to-implement method of mutating transactions is blocked. Many big mining pools are already running this patch. https://github.com/bitcoin/bitcoin/pull/3669 https://github.com/bitcoin/bitcoin/pull/3671 https://github.com/bitcoin/bitcoin/pull/3694 These three get at the root of the problem; they rework the core wallet code to implement handle double spends better. See the pull requests for details. How can you help: Testing and code review is, as always, the bottleneck for getting out a release with these changes. We have a chronic problem with people running Bitcoin services on top of the core code waiting until there is an official release, and then assuming that somebody else has done the hard work of reviewing and testing the changes. YOU SHOULD NOT BE MAKING THAT ASSUMPTION! Your particular RPC call usage might trigger some edge-case bug that was missed, or perhaps the size of your wallet triggers a performance problem introduced by a fix. Or, in other words: do not treat the core development team as if we were a commercial company that sold you a software library. That is not how open source works; if you are making a profit using the software, you are expected to help develop, debug, test, and review it. -- -- Gavin Andresen -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] MtGox blames bitcoin
RE: taking discussion elsewhere: Yes, please, the purpose of this mailing list is technical discussions to encourage interoperability of Bitcoin implementations, improve ease-of-use and security, etc. -- -- Gavin Andresen -- Androi apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP70: PaymentACK semantics
On Thu, Jan 30, 2014 at 9:51 AM, Jeff Garzik jgar...@bitpay.com wrote: Is this truly the intent? That the merchant/processor takes full responsibility for getting the TX confirmed? The intent is to give the customer a great experience. We could talk for months about whether having the wallet broadcast the transaction as soon as possible or having it wait for the merchant to respond with a PaymentACK is better. But I think we should let wallets experiment with different ways of doing it, and see what works best in practice. -- -- Gavin Andresen -- WatchGuard Dimension instantly turns raw network data into actionable security intelligence. It gives you real-time visual feedback on key security issues and trends. Skip the complicated setup - simply import a virtual appliance and go from zero to informed in seconds. http://pubads.g.doubleclick.net/gampad/clk?id=123612991iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP70: PaymentACK semantics
On Tue, Jan 28, 2014 at 6:42 AM, Mike Hearn m...@plan99.net wrote: Yeah, that's the interpretation I think we should go with for now. There was a reason why this isn't specified and I forgot what it was - some inability to come to agreement on when to broadcast vs when to submit via HTTP, I think. If the wallet software is doing automatic CoinJoin (for example), then typically one or several of the other participants will broadcast the transaction as soon as it is complete. If the spec said that wallets must not broadcast until they receive a PaymentACK (if a payment_url is specified), then you'd have to violate the spec to do CoinJoin. And even if you don't care about CoinJoin, not broadcasting the transaction as soon as the inputs are signed adds implementation complexity (should you retry if payment_url is unavailable? how many times? if you eventually unlock the probably-not-quite-spent-yet inputs, should you double-spend them to yourself just in case the merchant eventually gets around to broadcasting the transaction, or should you just unlock them and squirrel away the failed Payment so if the merchant does eventually broadcast you have a record of why the coins were spent). -- -- Gavin Andresen -- WatchGuard Dimension instantly turns raw network data into actionable security intelligence. It gives you real-time visual feedback on key security issues and trends. Skip the complicated setup - simply import a virtual appliance and go from zero to informed in seconds. http://pubads.g.doubleclick.net/gampad/clk?id=123612991iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Stealth Addresses
On Sun, Jan 12, 2014 at 5:33 AM, Jeremy Spilman jer...@taplink.co wrote: ... Now, you would need to get two pubkeys to the payer, throw in a prefix to help standardize it, and end up with addresses that could look like (for example): xSTLxsn59oaupR6ZKt2yddQ4dp5hcFinnTWkvsDiXtHgAEDg5ajNVzTY8MMQsmqnEn3ZMKxQzrfC3pDimfTWMkiUb7x3jX3J26JSX tSTLcpwzupCFL3maVZkSiB9ib3BXsCAfkhMLgckQEyoj8Tk83ANzofeuDdbX6bSPqNRfACLLFYK8EwVo1jdjxNDFNDWxhnQiAy4ba No, please. Make it easy for non-geeks, extend the payment protocol, or we'll spend the next two years writing code that tries to ignore linebreaks and spaces and changing input elements in HTML forms to textarea -- -- Gavin Andrese -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Merge avoidance and P2P connection encryption
On Fri, Dec 13, 2013 at 4:24 AM, Mike Hearn m...@plan99.net wrote: I think the right way to integrate BIP32 and BIP70 would be to specify output scripts as normal for backwards compatibility, and then allow each output to have an additional xpubkey and iteration count field. The iteration counts could be unsigned. Why would there be an iteration count? The payer would handle that, wouldn't they? If the use case is: I give the Foundation a here's where to pay my salary PaymentRequest, maybe with several Outputs each having a different xpubkey, then it seems to me the Foundation's wallet software should take care of iterating. (either saving state, so it knows it used xpubkey+10 last month and should use xpubkey+11 this month, or maybe it knows I'm paid monthly and just uses xpubkey+(number_of_months_from_date_in_original_payment_request). -- -- Gavin Andresen -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] 0.8.6 release candidate 1
0.8.6 release candidate 1 is available from: https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.8.6/test/ Please help sanity-test, especially if you are running OSX or Windows. -- -- Gavin Andresen -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Floating fees and SPV clients
Wouldn't the idea be that the user always sees 10mBTC no matter what, but the receiver may receive less if the user decides to pay with a huge transaction? If users want to pay with a huge transaction then it seems to me the user should cover that cost. Allowing users to pay merchants with 100K transactions full of dust and expecting them to eat the cost seems like a great way to enable bleed-the-merchant-dry attacks. RE: hiding or showing fees: I pointed out to Peter that there doesn't have to be One True Answer. Let wallets experiment with either hiding or exposing fees, and may the best user experience win. -- -- Gavin Andresen -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Floating fees and SPV clients
A merchant can always refuse the payment and refund it if that's a practical problem. No, they can't, at least not in bitcoin-qt: when the user pokes the SEND button, the transaction is broadcast on the network, and then the merchant is also told with the Payment/PaymentACK round-trip. Allowing merchants to cancel (e.g. having a PaymentNACK) makes implementation harder, and brings up nasty issues if we want to allow CoinJoin or CoinJoin-like transactions as payments to merchants. Bitcoin-Qt ALREADY allows you to pay several PaymentRequests with one transaction; handling the case where one merchant gives you a PaymentACK and another gives you (or wants to give you) a PaymentNACK is a nightmare. -- Gavin Andresen -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Floating fees and SPV clients
On Tue, Dec 3, 2013 at 12:44 AM, Mike Hearn m...@plan99.net wrote: PPv1 doesn't have any notion of fee unfortunately. I suppose it could be added easily, but we also need to launch the existing feature set. Lets bang out a merchant-pays-fee extension. How about: SPEC: optional uint64 allowfeetag number=1000 Allow up to allowfee satoshis to be deducted from the amount paid to be used to pay Bitcoin network transaction fees. A wallet implementation must not reduce the amount paid for fees more than allowfee, and transaction fees must be equal to or greater than the amount reduced. :ENDSPEC Rationale: we don't want wallet software giving users discounts-- sending transactions that are amount-allowfee without paying any fee. We also want to allow users to pay MORE in fees, if they need to (fragmented wallet, maybe, or big CoinJoin transaction) or decide to. PS: I think there was also consensus that the BIP72 request=... should be shortened to just r=... (save 6 chars in QR codes). Unless somebody objects, I'll change the BIP and the reference implementation code to make it so... -- -- Gavin Andresen -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Even simpler minimum fee calculation formula: f bounty*fork_rate/average_blocksize
Couple of thoughts: RE: the marvelous coincidence that the average fee these days is very close to the modeled minimum orphan cost: Engineers tend to underestimate the power of markets, even inefficient markets, to arrive at the 'correct' price. It would not surprise me at all if the messy, chaotic inefficient market with tens of thousands of individual decisions (which mining pool should I join and how high should my dice site set fees and how large should the minimum payout be and should I make my blocks bigger or smaller) might arrive at the 'correct' price, even if NOBODY involved has any clue how or why it happened. Or it might just be a coincidence. RE: orphan rate: The network-wide orphan rate has been very steady apart from the March blockchain fork. Kudos to Ben Reeves for keeping track of the data and giving us a nice chart: http://blockchain.info/charts/n-orphaned-blocks RE: new block latency: We should be able to reduce the size of new block announcements by about a factor of ten with very little additional effort (transmit/relay as merkleblock with full bloom filters-- the factor of 10 is because a transaction id hash is 32 bytes, average transaction size is a few hundred bytes). Mining revenue is a fixed-size pie, so if EVERYBODY agreed to accept (somewhat) higher orphan rates for more transaction volume then, in the long run, there is no difference. Well, except that more transaction volume means more utility for Bitcoin as a whole, so everybody should benefit from a higher bitcoin price. That's a classic free-rider problem, though-- a miner could defect to try to get a lower orphan rate. This is one of the reasons why I think relaying all blocks in a race is probably the right thing to do; if a miner is mildly punished (by losing the occasional block race) for creating blocks that don't include enough already-relayed transactions, that is a strong incentive to go along with whatever consensus has been established. The same argument applies for a miner producing too-large blocks, or blocks with lots of transactions that were never relayed across the network. -- -- Gavin Andresen -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Feedback requested: reject p2p message
On Tue, Oct 29, 2013 at 10:32 PM, Mike Hearn m...@plan99.net wrote: Yes, exactly. That's the point. As you well know I think the whole soft-fork mechanism is wrong and should not be used. If the rules change, your node is *supposed* to end up on a chain fork and trigger an alert to you, that's pretty much the whole purpose of Bitcoin's design. Undermining that security model is problematic. But if you are getting soft-forked recent versions of the reference implementation WILL alert you; see this code in main.cpp: if (nUpgraded 100/2) strMiscWarning = _(Warning: This version is obsolete, upgrade required!); That is, if more than half of the last 100 blocks are up-version, warn. block.version is part of the block header, so SPV clients can (and probably should) do the same. There are also warnings if you are forked, and, most recently, warnings if there is a high-work alternative fork. -- -- Gavin Andresen -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Feedback requested: reject p2p message
Thanks for the feedback, everybody, gist updated: https://gist.github.com/gavinandresen/7079034 Categories are: 0x01-0x0fProtocol syntax errors0x10-0x1fProtocol semantic errors0x40-0x4fServer policy rule https://gist.github.com/gavinandresen/7079034#rejection-codes-common-to-all-message-types RE: why not a varint: because we're never ever going to run out of reject codes. Eight are defined right now, if we ever defined eight more I'd be surprised. RE: why not use HTTP codes directly: because we'd be fitting round pegs into square holes. -- -- Gavin Andresen -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Advisory: PHP library Bitcoin SCI weak key generation
Thanks for the warning; to be clear, the Bitcoin SCI library is this project? http://bitfreak.info/index.php?page=toolst=bitsci On Mon, Oct 28, 2013 at 8:25 AM, Andres Home a86...@outlook.com wrote: For those developers who are using the Bitcoin SCI library (maybe others too, I found two total and could only make contact with one), I would advise that you review how your software handles private key creation. -- -- Gavin Andresen -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Feedback requested: reject p2p message
RE: use HTTP-like status codes: Okey dokey, I'll add a one-byte machine-readable HTTP-like status code. Unless y'all want a 32-bit status code. Or maybe a varint. Or a three-character numeric string. I really and truly don't care, but I am writing this code right now so whatever you want, decide quickly. If anybody has strong feelings about what the reject categories should be, then please take the time to write a specific list, I can't read your mind -- -- Gavin Andresen -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Making fee estimation better
On Fri, Oct 25, 2013 at 5:51 PM, Jeremy Spilman jer...@taplink.co wrote: ** Gavin, can you confirm the best place to read up on the discuss fee estimation changes for v0.9? The blog post is the best place for high-level overview. The (closed for now, but it will come back) pull request is the best place for low-level details and nit-picking discussion: https://github.com/bitcoin/bitcoin/pull/3024 I think fee estimation at its core is about providing a data point, or even call it an API, which can be used however you see fit. What parameters do I want to see in a 'fee estimation' API? - 30 minutes vs 24 hours processing time - Confidence Levels (50%/90%) The pull request adds an 'estimatefees' JSON-RPC api call: estimatefees [prioritymedian=0.1] [feemedian=0.5] Estimates the priority or fee a transaction needs to be relayed across the network and included in the block chain. prioritymedian and feemedian are values from 0.0 to 1.0, where 0.0 will return the smallest recently-included-in-a-block priority (or fee) seen, 1.0 the largest, and 0.5 the median priority (or fee) for transactions that were broadcast on the network and included in a block. The default value for prioritymedian (0.1) is chosen to return a priority for free transactions that will eventually be confirmed, but might take several hours. The default value for feemedian (0.5) returns how much fee you should include to have your transactions confirmed in an average amount of time. Values returned are: freepriority : priority needed to out-compete a prioritymedian fraction of free transactions to be relayed and included in blocks. feeperbyte : fee, in satoshis/byte, needed to out-compete a feemedian fraction of fee-paying transactions. Values of -1.0 are returned if not enough transactions have been seen to make a good estimate. That API doesn't give 30 minute versus 24 hour confirmation time or confidence intervals. I've always regretted not taking a statistics class; if you want to help write code that estimates confidence intervals send me an email. The API certainly isn't set in stone. - Is it globally consistent? Ummm roughly, yes, it will be. Nodes that have just joined the network and haven't seen enough transactions enter and leave the memory pool will have a different estimate than long-running nodes, but in my testing the estimate narrows down very quickly (with three or four blocks enough fee-paying transactions have been seen to make a reasonable estimate; it takes longer to see enough free transactions to get a good estimate of the priority needed to get into the free space of a block). RE: lots of other comments: I feel like there is a lot of in the weeds discussion here about theoretical, what-if-this-and-that-happens-in-the-future scenarios. I would just like to point out (again) that this is not intended to be The One True Solution For Transaction Fees And Transaction Prioritization. If you've got a better mechanism for estimating fees, fantastic! If it turns out estimates are often-enough wrong to be a problem and you've got a solution for that, fantastic! RE: are we already seeing pressure on transaction fees: I believe we are, yes. As part of the prep work for the smart fee work I spent some time plotting priority (for zero-fee transactions) and transaction fee (for zero-priority transactions) versus confirmation time, and it looks to me like people/services are starting to include more than the hard-coded fees in the reference implementation-- I assume because they want their transactions to be confirmed more quickly. There is definitely already competition among zero-fee transactions for the free block space. One of the reasons I'm comfortable with the fee changes I'm proposing is if the estimation code gets it very wrong we'll see that first as free transactions taking too long to confirm, but they'll confirm eventually because priority increases over time. -- -- Gavin Andresen -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Feedback requested: reject p2p message
Mike Hearn has been lobbying for an error message in the Bitcoin p2p protocol for years (at least since the ban peers if they send us garbage denial-of-service mitigation code was pull-requested). This came up again with my proposed smartfee changes, which would drop low-priority or low-fee transactions. In short, giving peers feedback about why their blocks or transactions are dropped or why they are being banned should help interoperability between different implementations, and will give SPV (simplified payment verification) clients feedback when their transactions are rejected due to insufficient priority or fees. See the gist for details, I'm looking for feedback and planning on implementing this before circling back to finish the 'smart fee' work: https://gist.github.com/gavinandresen/7079034 -- -- Gavin Andresen -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment protocol for onion URLs.
On Sat, Oct 26, 2013 at 1:31 PM, Gregory Maxwell gmaxw...@gmail.com wrote: This would give us an fully supported option which is completely CA free... it would only work for tor sites, but the people concerned about CA trechery are likely to want to use tor in any case. Thoughts? I think a tiny number of people would use it, so from a purely engineering priority perspective my initial reaction is not worth it. However, as a demonstration of the flexibility of the payment protocol and because it is a really nifty idea that will give lots of people warm fuzzies I think you should do it and we should pull it. -- -- Gavin Andresen -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Making fee estimation better
On Fri, Oct 25, 2013 at 12:54 AM, Peter Todd p...@petertodd.org wrote: Eligius has contracts to do transaction mining, and it's currently 10% of the hashing power. Yes, and I asked Luke what percentage of that 10% is OOB fee payments, and the answer is a small percentage. So: there are multiple layers of reasons why OOB fee payments will not screw up the fee estimation code: + If the transactions are not broadcast, then they have no effect on the estimates. + If the transactions are broadcast but not relayed because their priority and fee are way below current estimates then they will have very close to zero effect on the estimates. + If the OOB transaction is zero-fee, zero-priority (e.g comes from a high-tx-volume service and relies on recently spent outputs) it will have zero effect on the estimates. + If they make up less than about 40% of broadcast transactions they will have very close to zero effect on the fee estimate (because of the distribution of fees and behavior of taking a median) The only case where the estimation code is even slightly likely to get confused is estimating the priority needed to get into a block IF there are a significant number of zero-fee, low-but-not-zero-priority OOB transactions being broadcast. And since priority naturally increases over time, even if that case DOES occur the failure is very mild-- it means your free transactions might have to build up more priority than the code estimates before successfully entering a block. If that gets to be an actual problem, then implementing Pieter's idea of keeping track of memory pool transactions that are NOT getting mined would fix it. But I don't want to waste time on a theoretical problem when it is very possible miners will decide to stop accepting free transactions alltogether. And all of the above is completely orthogonal to child-pays-for-parent and/or replace-with-higher-fee. PS: I would appreciate it if you stop saying things like Regarding the transaction fee estimate code, it's not very well thought out. -- -- Gavin Andresen -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] bitcoind stops responding
On Tue, Oct 1, 2013 at 6:58 PM, slush sl...@centrum.cz wrote: One process is asking getinfo every second as a fallback to possibly misconfigured blocknotify. It also calls getblocktemplate every 30 second. getinfo does a bunch of stuff; with 0.9 you will be able to use getbestblockhash instead. Second process is calling getinfo once a minute to check if bitcoind is working. If it don't receive a response in a minute, it kills bitcoind and starts it again. If you just want to see if bitcoind is responding to RPC requests, then 'help getinfo' would do the trick without acquiring any locks. RE: running into the maximum-of-4-keepalive-requests : simple workaround is to run with -rpcthreads=11 (or however many keepalive connections you need to support). I agree that the rpc code should be smarter; making the last rpc thread ignore keepalive and always disconnecting should be a fairly simple patch, and patches welcome. -- -- Gavin Andresen -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Code review
On Fri, Oct 4, 2013 at 8:30 PM, Mike Hearn m...@plan99.net wrote: I'd like to make a small request - when submitting large, complex pieces of work for review, please either submit it as one giant squashed change, or be an absolute fascist about keeping commits logically clean and separated. I'll try harder to be a fascist (it doesn't come naturally to me). HUGE thanks for taking the time to review the fee changes in detail. RE: using Review Board: I'm all for using better tools, if they will actually get used. If a potential reviewer has to sign up to create a Review Board account or learn Yet Another Tool, then I think it would be counter-productive: we'd just make the pool of reviewers even smaller than it already is. Are there good examples of other open source software projects successfully incentivizing review that we can copy? For example, I'm wondering if maybe for the 0.9 release and onwards the Thank you section should thank only people who have significantly helped test or review other people's code. -- -- Gavin Andresen -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] smart contracts -- possible use case? yes or no?
On Sun, Sep 29, 2013 at 12:28 PM, Neil Fincham n...@asdf.co.nz wrote: I subscribe to this list so I can keep up-to date with bitcoin development, can we keep philosophy and tax evasion out of it? Yes, that's off-topic for this mailing list. Lets stick to technical issues that we can solve by writing code. -- -- Gavin Andresen -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72
On Tue, Sep 24, 2013 at 11:52 PM, Mike Hearn m...@plan99.net wrote: BTW, on the make qrcodes more scannable front -- is it too late to change BIP 72 so the new param is just r instead of request? Every byte helps when it comes to qrcodes ... Not too late, assuming there are no objections. Smaller QR codes is a very good reason to change it. -- -- Gavin Andresen -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Bitcoin-Qt / bitcoind version 0.8.5 released
Bitcoin-Qt version 0.8.5 is now available from: http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.8.5/ This is a maintenance release to fix a critical bug; we urge all users to upgrade. Please report bugs using the issue tracker at github: https://github.com/bitcoin/bitcoin/issues 0.8.5 Release notes === Bugs fixed -- Transactions with version numbers larger than 0x7fff were incorrectly being relayed and included in blocks. Blocks containing transactions with version numbers larger than 0x7fff caused the code that checks for LevelDB database inconsistencies at startup to erroneously report database corruption and suggest that you reindex your database. This release also contains a non-critical fix to the code that enforces BIP 34 (block height in the coinbase transaction). -- Thanks to Gregory Maxwell and Pieter Wuille for quickly identifying and fixing the transaction version number bug. -- How ServiceNow helps IT people transform IT departments: 1. Consolidate legacy IT systems to a single system of record for IT 2. Standardize and globalize service processes across IT 3. Implement zero-touch automation to replace manual, redundant tasks http://pubads.g.doubleclick.net/gampad/clk?id=5127iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] BIP 72 updated: require Accept HTTP header
I just added a requirement to the BIP 72 (bitcoin: URI payment protocol) spec: Wallets must include an Accept HTTP header in HTTP requests: Accept: application/bitcoin-paymentrequest ... and submitted a pull request so the reference implementation follows the spec. Thanks to Stephen/Jeff at BitPay for the suggestion. I'll make a similar change to BIP 70 and require wallets set Accept: application/bitcoin-paymentrequestack when sending the Payment and expecting a PaymentACK message in return. -- -- Gavin Andresen -- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] There will be a 0.8.4 release
There have been a few not-quite-serious-enough-to-justify-a-release security fixes that, along with a couple of serious bugs, we think together DO justify a new 0.8.* release. So I just created a 0.8.4 branch, based on the 0.8.3 branch, and will be cherry-picking from the master branch. Planned changes from the 0.8.3 release: Security-related: 42656ea Make RPC password resistant to timing attacks 159bc48 Simplify storage of orphan transactions, fix CVE-2013-4627 37c6389 Performance optimization for bloom filters (help mitigate potential DoS attack discussed last week) Bug fixes: 9bf2a4ab Fix multi-block reorg transaction resurrection bf81a3ef Fix Gnome bitcoin: URI handler f0784ac4 Fix non-standard disconnected transactions causing mempool orphans 2461aba1 Mempool consistency check pull 2916 Import OSX fsync change from LevelDB subtree (will hopefully fix the random-OSX leveldb corruption issues) There are lots of little fixes that could be included, but those will wait for the 0.9 release. -- -- Gavin Andresen -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72
On Tue, Aug 20, 2013 at 8:15 AM, Andreas Petersson andr...@petersson.atwrote: I was just reviewing the integration work to integrate the Payment Protocol into our products. Is there any notion of a standardized invoice serialisation? If i pay for two Burgers and one Club Mate, how would my Bitcoin Wallet be able to know that? No. There are XML-based (shudder) standards for electronic invoicing that include all sorts of bells and whistles; the PaymentDetails message could easily encapsulate one of them in an 'invoice' field extension. Or we could reinvent the wheel and come up with our own, but I'd rather use an existing standard (or maybe a subset of an existing standard). I didn't want to wade into that swamp for the 1.0 version of the payment protocol. Right now, i would simply put that into memo and come up with my own serialisation mechanism. Two Burgers, one Club Mate seems pretty user-friendly. Second, is there a way to communicate acceptance levels of TX (unconfirmed, 1 conf, 6 conf) maybe using several PaymentACK? No, because the Payment-PaymentACK communication round-trip is done in one, non-persistent http request-response round-trip. I don't think we want to allow merchants to push messages to the wallet (wouldn't take long for merchants to use the opportunity to push annoying advertising at me, I think), and I don't think we want wallets to poll the merchant. Although maybe a payment protocol version 2.0 feature could be a PaymentACK extension that says ask me how the transaction is going at THIS URL in THIS many minutes. -- -- Gavin Andresen -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] NODE_BLOOM BIP
Mike pointed out exactly the reason I oppose a NODE_BLOOM service bit: I also think it is a bad idea to start making various bits and pieces of the protocol optional. It is bad for privacy (easier to fingerprint nodes) and bad for decentralization (fewer nodes support your required feature set). And every bit you add can give you an exponential number of combinations your QA team should test. I'd say the same thing about NODE_TRANSACTION (I don't know about blocks, have and NODE_BLOCK bits. -- -- Gavin Andresen -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Gavin's post-0.9 TODO list...
Mike asked what non-0.9 code I'm working on; the three things on the top of my list are: 1) Smarter fee handling on the client side, instead of hard-coded fees. I was busy today generating scatter-plots and histograms of transaction fees versus priorities to get some insight into what miner policies look like right now. 2) First double-spend relaying and alerting, to better support low-value in-person transactions. Related: *Have *a *Snack*, Pay with *Bitcoins*http://www.tik.ee.ethz.ch/file/848064fa2e80f88a57aef43d7d5956c6/P2P2013_093.pdf 3) Work on 2-3 whitepapers on why we need to increase or remove the 1MB block size limit, how we can do it safely, and go through all of the arguments that have been made against it and explain why they're wrong. -- -- Gavin Andresen -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Version 0.9 goals
It feels to me like we're close to a 0.9 feature freeze / start of release cycle; I'd like to talk a little bit about what we'd like to see in the final 0.9 release. My list: Bug: I'd really like to see the leveldb corruption issue (mostly on OSX, it seems) fixed. This is hard because it can't be reliably reproduced, and, at least on my machine, takes weeks to occur. Help needed to reproduce/fix, see https://github.com/bitcoin/bitcoin/issues/2770 for what we know about the problem. Payment Protocol support is ready to be pulled ( https://github.com/bitcoin/bitcoin/pull/2539) . Unless there are major objections, I will pull it tomorrow (it has already gone through two rounds of bounty-driven QA testing, so I'm convinced it is ready). I'd love for 0.9 to contain sipa's headers first initial block download optimization; I think it is a big enough improvement to justify making the 0.9 test/release cycle longer. Coin control (https://github.com/bitcoin/bitcoin/pull/2343). The autotools work (https://github.com/bitcoin/bitcoin/pull/2805). Gitian-build with the latest openssl and Qt5. Perhaps update the version of Debian VMs that we gitian-build with. I plan on spending about half my time on code review and helping get pull requests tested, and the other half of my time working on code that probably won't make it into the 0.9 release. -- -- Gavin Andresen -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72
RE: making the bitcoin address in the bitcoin: URI optional: Ok, I'm convinced, sometimes merchants won't want or need backwards compatibility and sometimes it won't make sense for them to put an arbitrary bitcoin: address there. RE: should the customer's machine not broadcast the transaction: I'd like to hear from other wallet implementors. Do you have a notion of 'locked inputs' ? The tricky bit in constructing a transaction but not broadcasting it right away is the inputs must be locked, so they're not accidentally double-spent. I'd also like to hear from merchants: any issue with your payment processing server having broadcast transaction functionality? My biggest worry is that the payment protocol will not get wide support if it is too hard to implement. -- -- Gavin Andresen -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72
I've updated the BIP 72 spec at https://en.bitcoin.it/wiki/BIP_0072 so the bitcoin address is optional: If the request parameter is provided and backwards compatibility is not required, then the bitcoin address portion of the URI may be omitted (the URI will be of the form: bitcoin:?request=... ). The spec already said what should happen if both request and address/amount/etc were given: it should ignore the bitcoin address/amount/label/message in the URI and instead fetch a PaymentRequest message and then follow the payment protocol I think this gives us a smooth, clear upgrade path. -- -- Gavin Andresen -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
