Re: [Bitcoin-development] Supermajority mining votes for valid->invalid changes.
On Mon, Oct 3, 2011 at 1:32 AM, Luke-Jr wrote: > Perhaps as a safeguard: > (3) Before applying the new rule, require 50% of the last Y blocks contain a > coinbase with a "I am upgraded" code > (4) Until the new rule is active, include an "I am upgraded" code in every > block; after it's active, this can be turned off (4) is a nice idea. I was hoping to avoid (3) simply because for any one of these upgrades hopefully 95% of the network is neutral wrt the change because they won't mine either form of the transactions. The active statement has the benefit that it constitutes a proof: You know with specific confidence (based on the window size) how likely a fork of length X will be if a newly invalid transaction is announced at the time of the activation. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Supermajority mining votes for valid->invalid changes.
On Monday, October 03, 2011 12:53:51 AM Gregory Maxwell wrote: > Upgraded nodes get the following rules: > (0) Never forward or mine a txn which would be invalid under the new rule. > (1) Apply old behavior before height X unconditionally. > (X set far enough in the future to get reasonable deployment by > large miners) > (2) Begin applying the new rule only after the first point in the chain > after X when none of the last Y blocks have contained an invalid > transaction under the new rules. Perhaps as a safeguard: (3) Before applying the new rule, require 50% of the last Y blocks contain a coinbase with a "I am upgraded" code (4) Until the new rule is active, include an "I am upgraded" code in every block; after it's active, this can be turned off > After the software has been released members of the bitcoin community then > begin _intentionally_ transmitting transactions which are invalid under > the new rules. (What would have been an attack under simplest deployment > plan) Why would legitimate community members ever intentionally transmit an invalid transaction? ;) -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Supermajority mining votes for valid->invalid changes.
It is possible to made changes to the distributed algorithm which make previously valid txn invalid without necessarily creating any lasting chain splits. This has been proposed for the addition of the eval opcode by using one of the existing NOPs. One challenge is that if transactions are emitted which are invalid under the new scheme but valid under the old after the block height that the rule is coded to take effect and a super-majority of miners are not yet upgraded the upgrade may cause a long reorganization and serious disruption. Here I explain one possible way of avoiding this. Upgraded nodes get the following rules: (0) Never forward or mine a txn which would be invalid under the new rule. (1) Apply old behavior before height X unconditionally. (X set far enough in the future to get reasonable deployment by large miners) (2) Begin applying the new rule only after the first point in the chain after X when none of the last Y blocks have contained an invalid transaction under the new rules. After the software has been released members of the bitcoin community then begin _intentionally_ transmitting transactions which are invalid under the new rules. (What would have been an attack under simplest deployment plan) By setting Y high enough that all major miners have a chance to mine in the window, this actually becomes an effective vote for the change by miners with a stochastic super-majority threshold. All nodes are able to exactly determine at what block the election has completed because it is an objective fact of the chain. With this scheme the new encoding will only become active when enough mining capacity supports it (or at least helpfully refuses to mine the who class of transactions) so that a large reorganization will not happen due to incompatible blocks during deployment. This could be further enhanced with conflicting block discouragement (e.g. refusing to extend or forward a rules violating block until it is burred) but I think this scheme is sufficient without that, and that this is generally superior to discouragement for this purpose. Cheers. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] My thoughts on DoS code
Hey, The Zen of Python is relevant here: http://www.python.org/dev/peps/pep-0020/ "In the face of ambiguity, refuse the temptation to guess." If a node incorrectly implements the standard then it should be shunned immediately. Not only is this more secure, but it will ensure long term compatibility between different implementations. Gavin argues that being a bit lenient makes it easier for people working on other implementations. I'd argue the opposite being the only person that's working on a full node implementation. Lucky I know my way around the code, so I don't have to guess. But if I did not things would be much harder. Imagine you're trying to interact with this protocol and then randomly it will suddenly disconnect you because of accumulated errors that have been building up. Everything should be strict, explicit, unambiguous and loud. I propose a new message type: "error" Payload is a uint64_t error_code and var_str reason. Before disconnecting a node you can send it an error message. The error_code is the main class of error- i.e version_sent_twice. Reason is just an implementation specific string that can add context. Other possible fields: uint8_t seriousness (debug, info, warning, error, fatal) uint8_t action_taken (disconnect, blacklist, .etc) -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Deprecating "midstate" in getwork?
On Thu, Sep 29, 2011 at 12:49 PM, solar wrote: > It's just simple SHA2, you can implement the whole thing easily without > dragging in a huge lib like OpenSSL. I guess I haven't looked at it > recently but the original CPU miner was just implemented locally in bitcoin > and didn't use any libs. > I don't get the 'dragging in' part. Bitcoin already depends on OpenSSL for ecdsa, bignum, and SSL for RPC. Please, please don't try to reimplement these locally :-) JS -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
