Re: [Bitcoin-development] 0.8.1 ideas
On Wed, Mar 13, 2013 at 12:56:29PM +, Luke-Jr wrote: Here's a simple proposal to start discussion from... BEFORE block 262144: - Never make a block that, combined with the previous 4 blocks, results in over 4500 transaction modifications. - Reject any block that includes more than 4500 transaction modifications on its own (slight soft-fork) - (these rules should make older clients safe under most circumstances) FROM block 262144 to block 393216 (hard fork #1): - Never make, and reject any block that includes more than 24391 transaction modifications on its own (this *should* be equivalent to 1 MB) - (this rules can make older client backports safe unless a reorg is more than 6 blocks deep) FROM block 393216 onward (hard fork #2): - Never make, and reject any block that includes more than 48781 transaction modifications on its own (this *should* be equivalent to 2 MB) - Accept blocks up to 2 MB in data size If we're going to consider doing this, at minimum we need to also include a separate limit for how much the UTXO set can be grown by each block, calculated as the size of the scriptPubKey + constant metadata. (tx hash, index #, nValue, nVersion, nHeight should cover it) A P2SH transaction txout would measure 71bytes under that model. Given that we haven't even shown we can limit the creation of txouts that can not be spent economically caution would dictate setting the UTXO growth limit fairly low, say 1/4th of the block limit. -- 'peter'[:-1]@petertodd.org signature.asc Description: Digital signature -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] 0.8.1 ideas
On Wed, Mar 13, 2013 at 8:05 AM, Peter Todd p...@petertodd.org wrote: If we're going to consider doing this, at minimum we need to also I beg people to not derail discussion about fixing things with discussion of other controversial changes. Luke-jr, any chance in getting you to revise your proposal to narrow the scope to things that don't need serious debate? -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] 0.8.1 ideas
On Wednesday, March 13, 2013 3:18:36 PM Gregory Maxwell wrote: On Wed, Mar 13, 2013 at 8:05 AM, Peter Todd p...@petertodd.org wrote: If we're going to consider doing this, at minimum we need to also I beg people to not derail discussion about fixing things with discussion of other controversial changes. I figured 2 MB in 2-3 years was fairly uncontroversial. If not, let's scrap that idea for now. Luke-jr, any chance in getting you to revise your proposal to narrow the scope to things that don't need serious debate? It was a one-time start the conversation proposal. I expect what we end up going with may be substantially different. Luke -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] 0.8.1 ideas
On Wed, Mar 13, 2013 at 03:26:14PM +, Luke-Jr wrote: On Wednesday, March 13, 2013 3:18:36 PM Gregory Maxwell wrote: On Wed, Mar 13, 2013 at 8:05 AM, Peter Todd p...@petertodd.org wrote: If we're going to consider doing this, at minimum we need to also I beg people to not derail discussion about fixing things with discussion of other controversial changes. I figured 2 MB in 2-3 years was fairly uncontroversial. If not, let's scrap that idea for now. The very statement that we're willing to increase the blocksize as our solution to increased transaction volume rather go down the path of off-chain transactions is incredibly controversial. Fuck it, I'll make this public: I've had at least one person who went to the trouble of finding my personal phone number just so they could leave a few text messages saying I was going to do serious harm to Bitcoin. At the same time I've also had a few people asking questions along the line of had started and/or was considering starting a formal group opposing the blocksize increase. I even got a significant anonymous donation a few weeks ago. (rather fittingly this was done by emailing me an easywallet URL from a throwaway account) It's not just forum trolls who care about the issue, even if they make the most noise about it. -- 'peter'[:-1]@petertodd.org signature.asc Description: Digital signature -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] 0.8.1 ideas
I'm not sure I understand the need for hard forks. We can get through this crisis by mining pool collusion to prevent forking blocks until there is widespread adoption of patched clients. Proposal: 1) Patch the pre-0.8 branches to support an increased lock count, whatever number is required to make sure that this problem never shows up again at the current block size (I defer to Luke-Jr and gmaxwell's numbers on this). 2) Patch all branches to not *generate* blocks which trigger the lock count limit. A larger block would still be accepted as valid, however, if it is on the longest chain. 3) Simultaneously, provide an additional non-standard patch to mining pool operators (50% network hash) *rejecting* blocks that trigger the lock count limit. This keeps miners in collusion with each other to stay on a 'compatibility fork'. 4) At some point in the future once we've crossed an acceptable adoption threshold, the miners remove the above patch in a coordinated way. Does that not get us past this crisis without a hard-fork? Mark (Aside: I'm for BOTH raising the block-size limit and off-chain transactions, but like it or not there are political sides to that debate and we should keep politics out of crisis management.) On Wed, Mar 13, 2013 at 5:56 AM, Luke-Jr l...@dashjr.org wrote: Here's a simple proposal to start discussion from... BEFORE block 262144: - Never make a block that, combined with the previous 4 blocks, results in over 4500 transaction modifications. - Reject any block that includes more than 4500 transaction modifications on its own (slight soft-fork) - (these rules should make older clients safe under most circumstances) FROM block 262144 to block 393216 (hard fork #1): - Never make, and reject any block that includes more than 24391 transaction modifications on its own (this *should* be equivalent to 1 MB) - (this rules can make older client backports safe unless a reorg is more than 6 blocks deep) FROM block 393216 onward (hard fork #2): - Never make, and reject any block that includes more than 48781 transaction modifications on its own (this *should* be equivalent to 2 MB) - Accept blocks up to 2 MB in data size - Discontinue support for clients prior to 0.8.1 I intentionally set the block numbers conservatively to try to account for the yet-unseen ASIC upgrade. Thoughts? -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Blocksize and off-chain transactions
On Wed, Mar 13, 2013 at 01:01:43PM -0400, Gavin Andresen wrote: The very statement that we're willing to increase the blocksize as our solution to increased transaction volume rather go down the path of off-chain transactions is incredibly controversial. I really don't understand this either/or mentality. You said it best yourself: 10:48 gavinandresen Luke-Jr: argument for another day, but I can almost guarantee that the blocksize limit will be raised in less than 2 years, just based on pressure from the big businesses using the chain (and no, NOT satoshidice) Decentralization offers big businesses nothing; they're a regulation target already by virtue of size alone. OF COURSE we're going to raise the block size limit. Limiting the main blockchain to single-digit transactions-per-second is not an option, the vision FOREVER has been to scale it up. And OF COURSE there will be off-chain transactions-- at the very least, we need them for instantly confirmed transactions. But lets table that whole discussion until 0.8.1 is out the door. -- -- Gavin Andresen -- 'peter'[:-1]@petertodd.org signature.asc Description: Digital signature -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Blocksize and off-chain transactions
Please note that it was not 0.8 that had issues, but 0.7(and downwards). I really think changing features in 0.8 aiming for a fluffy limit to avoid lock object errors on 0.7 is the wrong way to go, and it will never cover for a similar situations in the future. Instead I would like to propose a setup for considerate mining: * Run pools either on newest or second newest version (up to you depending on which features you like as a pool admin) - say e.g. 0.8 * Connect to the rest of the bitcoin network _only_ through a node of the other version - say e.g. 0.7 This guarantees that no blocks will get into the network that will not be accepted by both 0.8 and 0.7. Those two versions together should add up to say 90%. Once everyone else (90%) have upgraded to the newest, (0.8), drop the 0.7 and start to introduce 0.9 instead. /M -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] 0.8.1 ideas
On Wednesday, March 13, 2013 5:41:29 PM you wrote: I'm not sure I understand the need for hard forks. We can get through this crisis by mining pool collusion to prevent forking blocks until there is widespread adoption of patched clients. Anything requiring widespread adoption of patched clients *is by definition* a hard fork. Proposal: 1) Patch the pre-0.8 branches to support an increased lock count, whatever number is required to make sure that this problem never shows up again at the current block size (I defer to Luke-Jr and gmaxwell's numbers on this). This is a hard fork. The only way to avoid a hard fork is to apply the existing lock limit to all clients forever. That would be fine, except that pre-0.8 clients cannot reorg N blocks without dividing that limit by (N * 2) + 1; that leaves us with the limit of around 1000 locks per block on average. Each transaction uses at least 3 locks on average (many times more). So about 300 transactions per block. This is a much smaller limit than the 1 MB we've been assuming is the bottleneck so far, and the need to increase it is much more urgent - as Pieter noted on IRC, we are probably already using more than that even ignoring DP spam. The only reason pre-0.8 clients have survived as well as they have thus far is because the blockchain has managed to avoid very deep reorgs. Luke -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Blocksize and off-chain transactions
On Wednesday, March 13, 2013 6:01:02 PM Michael Gronager wrote: Please note that it was not 0.8 that had issues, but 0.7(and downwards). While 0.7 and earlier do have issues, they also define the Bitcoin protocol. 0.8's failure to comply with the protocol is an issue. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] 0.8.1 ideas
This may be a semantic issue. I meant that it's not a hard-fork of the bitcoin protocol, which I'm taking to mean the way in which we all *expected* every version of the Satoshi client to behave: the rules which we have documented informally on the wiki, this mailing list, and in code comments, etc. I'm just trying to prevent protocol-creep. Luke-Jr is suggesting that we add-to/modify the bitcoin protocol rules which all verifying implementations must adhere to. I'm suggesting that we instead change the old codebase to do what we expected it to do all along (what 0.8 does and what every other verifying implementation does), and through miner collusion buy ourselves enough time for people to update their own installations. I know there's people here who will jump in saying that the bitcoin protocol is the behavior of the Satoshi client, period. But which Satoshi client? 0.7 or 0.8? How do you resolve that without being arbitrary? And regardless, we are moving very quickly towards a multi-client future. This problem is very clearly a *bug* in the old codebase. So let's be forward thinking and do what we would do in any other situation: fix the bug, responsibly notify people and give them time to react, then move on. Let's not codify the bug in the protocol. Mark On Wed, Mar 13, 2013 at 10:58 AM, Pieter Wuille pieter.wui...@gmail.comwrote: On Wed, Mar 13, 2013 at 10:41:29AM -0700, Mark Friedenbach wrote: 4) At some point in the future once we've crossed an acceptable adoption threshold, the miners remove the above patch in a coordinated way. Does that not get us past this crisis without a hard-fork? This is a hardfork: it means some nodes will have to accept blocks they formerly considered invalid. -- Pieter -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Blocksize and off-chain transactions
On Wed, Mar 13, 2013 at 07:01:02PM +0100, Michael Gronager wrote: Please note that it was not 0.8 that had issues, but 0.7(and downwards). I really think changing features in 0.8 aiming for a fluffy limit to avoid lock object errors on 0.7 is the wrong way to go, and it will never cover for a similar situations in the future. The current behaviour in 0.7 and before is indeed broken, and we cannot afford to keep that as an implicitly-defined rule on the network. I fully agree with that, but it will require a hardfork. But we cannot just drop support for old nodes. It is completely unreasonable to put the _majority_ of the network on a fork, without even as much as a discussion about it. Oh, you didn't get the memo? The rules implemented in your client are outdated. - that is not how Bitcoin works: the network defines the rules. IMHO, the way to go is first get a 0.8.1 out that mimics the old behaviour - just as a stopgap solution. That will allow miners to safely use 0.8-based code at least. We can also get patches for 0.7 and previous branches that fix the lock limit issue, but enforce the same limit as 0.8.1 does, simply as band-aid for those who do not yet wish to upgrade to 0.8. Finally, we'll have to schedule a hard fork to drop the 0.8.1 limit. This is something that requires widespread community consensus - far more than just miners and developers - but as this is about fixing a bug that would otherwise prevent most evolution, I hope it can be a very non-controversial one. To that end, I would prefer to limit this hard fork to only direct bug fixes, and leave the block limit issue for later. By now, I think it is clear that a hard fork will be inevitable, and by doing one, I think we can learn a lot that can make later ones easier. -- Pieter -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] 0.8.1 ideas
On Wed, Mar 13, 2013 at 11:27:13AM -0700, Mark Friedenbach wrote: I know there's people here who will jump in saying that the bitcoin protocol is the behavior of the Satoshi client, period. But which Satoshi client? 0.7 or 0.8? The protocol is whatever the network enforces - and that is some mix of versions of the reference client right now, but doesn't need to remain that way. I would very much like to have a text book of rules that is authorative, and every client that follows it would be correct. Unfortunately, that is not how a consensus system works. All (full) clients validate all rules, and all must independently come to the same solution. Consensus is of utmost importance, more than some theoretical correctness. If we'd have a specification document, and it was discovered that a lot of nodes on the network were doing something different than the document, those nodes would be buggy, but it would be the specification that is wrong. That is what happened: 0.7 and before had a bug, but 0.8 was wrong for not following the rules of the network (which I hate to say, as I'm responsible for many changes in 0.8). As said in another thread, the problem in the old versions needs fixing (this would even be the case if no 0.8 existed at all, and no fork risk existed at all). But let's please do it in a way we can all agree about, in a controlled fashion. -- Pieter -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] 0.8.1 ideas
Agree. I quite like Mark's proposal. Yes, formally it is hard fork. But the step 4) can come very far in the future, when the penetration of 0.8 clients will be mininimal. slush On Wed, Mar 13, 2013 at 7:27 PM, Mark Friedenbach m...@monetize.io wrote: This problem is very clearly a *bug* in the old codebase. So let's be forward thinking and do what we would do in any other situation: fix the bug, responsibly notify people and give them time to react, then move on. Let's not codify the bug in the protocol. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Blocksize and off-chain transactions
On Wed, Mar 13, 2013 at 07:28:06PM +0100, Pieter Wuille wrote: IMHO, the way to go is first get a 0.8.1 out that mimics the old behaviour - just as a stopgap solution. Presumably not emulate too precisely, at least if your initial report that the block caused 0.7 to 'get stuck' was correct. A network that has a mix of 0.8.1 nodes (which will reject the block) and 0.7 nodes (which will hang when receiving the block?) would appear to remove the fork risk. Is it obvious that no other serious problems remain in such a network? (Although I note your proposal to patch 0.7 too, so hopefully the network wouldn't remain in that state for very long) roy -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Blocksize and off-chain transactions
On Wed, Mar 13, 2013 at 2:28 PM, Pieter Wuille pieter.wui...@gmail.comwrote: But we cannot just drop support for old nodes. It is completely unreasonable to put the _majority_ of the network on a fork, without even as much as a discussion about it. Oh, you didn't get the memo? The rules implemented in your client are outdated. - that is not how Bitcoin works: the network defines the rules. ... Finally, we'll have to schedule a hard fork to drop the 0.8.1 limit. This is something that requires widespread community consensus - far more than just miners and developers The way I've started thinking about it is that there is a market for securing a payment network. In that market you have consumers (users of bitcoin) and providers (miners). It's not clear to me that if the overwhelming majority of miners stayed on 0.8 that the 0.7 fork wouldn't have still won out in the long run because effectively what you would have had is a situation where the providers abandon a large portion of their customers (0.7 users) and start providing a service that is in much less demand. Would everyone have upgraded to 0.8? Maybe, but maybe not. Maybe many people would have made the rational decision to stay on earlier versions and the small minority of miners that choose to service the 0.7 fork could have earned more Bitcoin on that fork...and maybe in the long run, the majority of miners on 0.8 would realize this situation and start to trickle back over to the 0.7 fork. The flip side of the equation is that the users have a pretty compelling reasons to use the services of the most secure network (less risk of double spends). So, the users very well could have made the rational decision to consume the services of the most powerful network and made the switch to 0.8. What happened in reality is that the majority of the mining community made the rational decision to service the largest pool of customers (0.8 as well as 0.7 and earlier users). It was rational because the risk of servicing only the 0.8 users would have been much greater. Because of this dynamic, I doubt there would ever be multiple forks of any consequence in permanent coexistence. I would even go so far as to say that at this point, a successful competitor to Bitcoin would have to arise as a fork of the UTXOs in the block chain (even if the competitor didn't even use a block chain). That competitor might even have to begin life in lock step co-existence with Bitcoin, recognizing all Bitcoin transactions for some period of time while it attempts to gain market share. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Blocksize and off-chain transactions
I hear consensus that at some point we need a hardfork (== creating blocks that will not be accepted by 0.7 clients). Miners generate block, hence they are the ones who should filter themselves though some consensus. But we cannot just drop support for old nodes. It is completely unreasonable to put the _majority_ of the network on a fork, without even as much as a discussion about it. Oh, you didn't get the memo? The rules implemented in your client are outdated. - that is not how Bitcoin works: the network defines the rules. Consensus was rapidly reached a day ago: To ensure the majority (all of?) the network could accept the blocks mined, and not just 0.8. This was the right decision! Too many was dependent on =0.7 So, the question is not if, but when to do a hardfork. We need to define and monitor the % of nodes running different versions (preferably a weighted average - some nodes, like e.g. blockchain.info mtgox serve many...). Once there was the rowit bitcoinstatus page - do we have another resource for this ? Then the second question is how to ensure we don't create a fork again? Pieter (and others?) are of the opinion that we should mimic a 0.7 lock-object-starvation-reject-rule. I don't like this for three reasons: 1. I find it hard to ensure we have actually coined the bug precisely 2. I expect that similar issues will happen again 3. The current issue was between two versions, but in the future it could be between two implementations - then trying implement or even to coordinate strange rules becomes very unlikely. Hence the scheme for considerate mining - it is the only scheme that guarantees 100% that no block are released that will not be accepted by a supermajority of the install base. Another nice thing about it - it requires no development :) So simply run in serial in front of all considerate miners nodes of different versions until a certain threshold of the install base is reached. /M -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] 0.8.1 ideas
On Wednesday, March 13, 2013 6:27:13 PM Mark Friedenbach wrote: Luke-Jr is suggesting that we add-to/modify the bitcoin protocol rules which all verifying implementations must adhere to. I'm suggesting that we instead change the old codebase to do what we expected it to do all along (what 0.8 does and what every other verifying implementation does), and through miner collusion buy ourselves enough time for people to update their own installations. Curiously enough, at least MtGox's custom implementation stuck with the canonical blockchain despite 0.8's accidental rule change. I know there's people here who will jump in saying that the bitcoin protocol is the behavior of the Satoshi client, period. But which Satoshi client? 0.7 or 0.8? How do you resolve that without being arbitrary? And regardless, we are moving very quickly towards a multi-client future. This problem is very clearly a *bug* in the old codebase. So let's be forward thinking and do what we would do in any other situation: fix the bug, responsibly notify people and give them time to react, then move on. Let's not codify the bug in the protocol. No, if any other client released diverged from the consensus of all past/existing clients, we would do the same thing: call it a formerly unknown protocol rule, that this new client has a bug implementing, and be done with it. The only reason this particular issue needs special treatment is because the implications of the new rule mean that we're up against a hard limit in the protocol today rather than 2 years from now. Luke -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] 0.8.1 ideas
On Wed, Mar 13, 2013 at 1:10 PM, Matthew Mitchell matthewmitch...@thelibertyportal.com wrote: Why would it be a difficulty in getting people to update away from 0.7 and earlier? How long would that roughly take? If people are hesitant to update, imagine if a more serious vulnerability is found. It could be disastrous. The development community backports critical fixes which makes updating instead of upgrading possible, but that still is not free. Many people are carrying patches against Bitcoin which require integration and time for testing— even if its just an update. Small behavior changes can still break things for the users. For example, a major mining pool lost well over 1000 BTC when upgrading to 0.8 because the reindex interacted poorly with their pool server software and caused them to pay people 25 BTC per share, an update or upgrade is just a risky even whos risk can be minimized if its done at your own pace. Sometimes when there is a vulnerability what people will do is isolate their production nodes from the internet using upgraded nodes, so they avoid touching the production systems. Other times the vulnerability is only a DOS attack so they ignore it unless the attack happens, or only applies to something else they don't care about. Another point is that if everyone instantly upgrades in response to developers claim that an urgent is needed (as opposed to implementing other workarounds) then the security of the system much more obviously reduces to the ability to compromise a developer— something no one should want. When roll outs take time there is more time for review to catch things, fewer nodes harmed by an introduced flaw, etc. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] On fork awareness Was: 0.8.1 ideas
On Wed, Mar 13, 2013 at 2:06 PM, Andy Parkins andypark...@gmail.com wrote: On Wednesday 13 Mar 2013 12:56:29 Luke-Jr wrote: Here's a simple proposal to start discussion from... It seems to me that the biggest failure was not the development of two chains, but the assurance to users (by the client) that their transactions The development of two chains was maximally bad because the state was irreconcilable without the manual intervention. The only reason you're saying that it was only the false confirms that were bad is because manual intervention resolved the worse badness. :) A whole bunch of people spending coins that can only exist in the different exclusive chains would have been very bad indeed. Is it possible to change the definition of 6 confirmations so that it's something like: six confirmations clear of any other chain. While there are two competing chains, it's possible that one will go pop at any moment. That makes the confirmation count of any transaction on one of those chains, zero. Not reliably, you will only hear of a competing chain if some of your peers have accepted it. If your peers were all pre-0.8 or all 0.8 you only would have heard of one chain. Relaying non-primary chains has some obvious and subtle challenges— Obviously you need some way of preventing it from being a DOS vector, but thats not a fundamental issue— you could rate limit by only relaying chains which are close to the current best in sum difficulty— just a software engineering one. A more subtle issue is it that it's not in a node's self-interest to tell peers about a chain it thinks is invalid: it wants its peers on _its_ view of the consensus, not some other one. Though perhaps this could be addressed by only relaying headers for non-primary chains. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] 0.8.1 ideas
On Wed, Mar 13, 2013 at 09:14:03PM +, Luke-Jr wrote: On Wednesday, March 13, 2013 9:06:44 PM Andy Parkins wrote: On Wednesday 13 Mar 2013 12:56:29 Luke-Jr wrote: Here's a simple proposal to start discussion from... It seems to me that the biggest failure was not the development of two chains, but the assurance to users (by the client) that their transactions were confirmed. These are both the same thing. The idea of the client detecting/warning about not-trivial forking seems worthwhile too, though, assuming it doesn't already (AIUI it doesn't). I don't know if there's any automatic monitoring for forks, but if not I would assume that the core devs and/or Bitcoin Foundation would be planning to put some in place. But there's no reason I can see why end users clients should't be warning of such situations, too, when they can (obviously they won't always be aware of the fork). roy -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] 0.8.1 ideas
On Wed, Mar 13, 2013 at 2:22 PM, Roy Badami r...@gnomon.org.uk wrote: The idea of the client detecting/warning about not-trivial forking seems worthwhile too, though, assuming it doesn't already (AIUI it doesn't). It does warn— if its heard the fork and its on the lower difficulty side. Extending that to also alert if its on the winning side and the fork is long enough might be wise, though I have a little concern that it'll be mistaken to be more dependable than it would be. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] 0.8.1 ideas
On Wed, Mar 13, 2013 at 02:27:01PM -0700, Gregory Maxwell wrote: On Wed, Mar 13, 2013 at 2:22 PM, Roy Badami r...@gnomon.org.uk wrote: The idea of the client detecting/warning about not-trivial forking seems worthwhile too, though, assuming it doesn't already (AIUI it doesn't). It does warn??? if its heard the fork and its on the lower difficulty side. Extending that to also alert if its on the winning side and the fork is long enough might be wise, though I have a little concern that it'll be mistaken to be more dependable than it would be. Still, it would have meant that all 0.8 users would have immediatley been told that something was wrong. I don't know to what extent it was luck that this was dealt with as promptly and efficiently as it was, but to the extent that luck was involved, a slew of 0.8 users shouting in various places wtf is going on couldn't but help in reducing the element of luck if something similar were to happen again. roy -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] 0.8.1 ideas
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I think that the course of action is quite simple: 1. Upgrade all the clients to implement the lock limits. (in code, not at the DB exception layer). A bit of research is needed to work out exactly what these limits are so we can maximise the number of transactions. 2. Fix the DB layer, and test that all the clients can support 1MB blocks. 3. Once we are confident that the network supports 1MB blocks, set a date where the lock limits are removed. For me, everyone signed up to bitcoin thinking that there was a 1MB / block limit. The lock limits were unexpected, and could be considered extremely uncontroversial to remove. The discussion of larger blocks (i.e. 1MB ), that I happen to disagree with, is not relevant to the discussion of the removal of the lock limits. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlFBF0QACgkQBJ8cMDO159aWbwEAs8Ldt8hRpzjS4HdrH3U9Jnaq MWhifXqkJuVC0TVCz3EBAOAfSogdSS7rJvtfV8FqTIox1ek/xJxuHvZdonUnQN1K =I5Cf -END PGP SIGNATURE- -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Ok to use 0.8.x?
Bitcoin version 0.8.0 is safe to use for everything EXCEPT creating blocks. So: safe for everybody except solo miners / pool operators. -- -- Gavin Andresen -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development