From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WxfyS-0001cC-8h for bitcoin-development@lists.sourceforge.net; Thu, 19 Jun 2014 17:18:08 +0000 Received: from mail-pb0-f49.google.com ([209.85.160.49]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WxfyQ-000243-BS for bitcoin-development@lists.sourceforge.net; Thu, 19 Jun 2014 17:18:08 +0000 Received: by mail-pb0-f49.google.com with SMTP id rr13so2106164pbb.8 for ; Thu, 19 Jun 2014 10:18:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:organization:user-agent :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=XrICAUTOVuXsbpQHI1Cp0agsO0PT/NX+V09p/AwAb6w=; b=N/zAOpLg4AB+vpujIBEQu/gLbhuAIDoshGZh0gQml4xaZIo+zGVnEC4XG/TjdYLNmm NzVP6ROcKSV11NDCWzFHV1Hqn168iztOawQPUXv0PYrxfKUUe/zpyA9EAl8sraP8WeGa EVpWzyBsPPqs23sAg/YRRhH14bwiCNJciYJidLCyOUtzRubSzjXOGL9MXN/cNQMjb64L TbAnKy617CW9a0n3P9wTkxVYw/t40lh/kQGE29Cx2MN2xY29s/8FohkBqeB2TdmbTulK F4B6yjUOsN455aEr/ZKUiX+g/wOfd2lqrUMjabGJ/oTpF9qP3DtSwYnHzlxJam+SyNyU kmeA== X-Gm-Message-State: ALoCoQlK1hHC5Yk4R6QxC4rZVNhUY4OpSrlWKf7Dm+pWp4TDEXYaPdOxM9khx/gMa6xXGLgTwBLx X-Received: by 10.66.174.199 with SMTP id bu7mr7519024pac.54.1403198280372; Thu, 19 Jun 2014 10:18:00 -0700 (PDT) Received: from [192.168.127.236] (50-0-36-179.dsl.dynamic.sonic.net. [50.0.36.179]) by mx.google.com with ESMTPSA id br1sm9535041pbc.6.2014.06.19.10.17.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 19 Jun 2014 10:17:59 -0700 (PDT) Message-ID: <53A31B3E.7020906@monetize.io> Date: Thu, 19 Jun 2014 10:17:50 -0700 From: Mark Friedenbach Organization: Monetize.io Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: bitcoin-development@lists.sourceforge.net References: <53A316BE.5040508@certimix.com> In-Reply-To: <53A316BE.5040508@certimix.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. X-Headers-End: 1WxfyQ-000243-BS Subject: Re: [Bitcoin-development] BlockPow: A Practical Proposal to prevent mining pools AND reduce payoff variance: X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 17:18:08 -0000 Sergio, why is preventing mining pools a good thing? The issue is not mining pools, which provide a needed service in greatly reducing variance beyond what any proposal like this can do. The issue is centralized transaction selection policies, which is entirely orthogonal. And the solution already exists: getblocktemplate. We just need more or better infrastructure which makes use of this technology to perform local transaction selection. If you have a proposal for eliminating hosted mining while keeping variance-reducing pools, that would be an interesting read. On 06/19/2014 09:58 AM, Sergio Lerner wrote: > I propose a setting that prevent mining pools AND reduce payoff variance > which requires two changes: increasing the block-rate and changing the > Bitcoin PoW (but still allowing current Bitcoin ASICs to work (as far as > I know)). The block rate must be increased at least 20 times and block > must still be near full (e.g. there must be at least 20 more > transactions/second than there is today) > > BlockPow is kind of PoW that only practically prevents mining pools for > certain cryptocurrency settings based on concepts similar to parmacoin, > but in a much simple degree. The idea is that if miners try to join a > pool, then they incur in overhead of transmitting information and earn > less than working solo. Let b (the payload) contain a full block. b must > contain all the transactions and the header, and not only the > transaction hashes. b should not hide anything. Let h be the block > header (which contains the previous block hash and the Merkle tree root > of the transactions). Let d be the difficulty. hash-block-length(b) > returns the number of blocks processed by the hash function when fed > with the block b. The target is divided by hash-block-length(b) so that > the difficulty does not depend on the length of the block. Some other > function can be used to encourage nodes to add more or less transactions. > > Def: Basic BlockPoW concept > > For each r in the nonce-range: if H ( H( r || b ) || h || r) ) < 2^-d/ > hash-block-length(b) then return r > > return null > > The header (h) is appended to the hashed message to allow SPV clients to > verify the PoW without requiring the full block to be downloaded. Peers > can send only (x,r,h) to SPV nodes, where x = H( r || b ), so they can > verify the PoW. The verification procedure is obvious, and is skipped > here. r is inserted at the beginning of the message to prevent pool > administrators from keeping a secret mid-state of the hash function > secret in order to prevent block stealing and also to force the miner to > know b in the inner mining loop. > > So now mining requires the knowledge of the block b to be mined, and b > must be received at each block-chain epoch. This could create an > incentive not to include any transaction and use an almost empty b, > because that way the bandwidth requirements is decreased. But this > incentive should not exists normally, since by including transactions > the solo miner gets an additional revenue from fees, which is lost if > the block is empty. Anyway, to prevent this possible incentive we can > append to b a subset of previous blocks (e.g 100 blocks). The block > subset to include could be derived from a peudo-random function seeded > by the previous block hash. Then a node would still need to download > part or all the block-chain in order to mine. > > Now if the miner wants to be a dumb node and take part of a pool, then > the current working unsolved block (the template) must be sent each time > from the pool admin to each miner. If the pool admin hosts 1000 miners, > then to serve them with fresh block templates he needs 1000 times more > bandwidth that the miners, making this much more expensive. If miners > create another network topology to distribute templates, they are > incurring in the same overhead as being actively part of the > cryptocurrency network, so they gain nothing. > > For example, in a block-chain with a 5 seconds block-rate, such as in > NimbleCoin , each block can be as large as 200 > Kbytes (100 tps are allowed). A miner will require the block template to > be ready as fast as possible, say before 3 seconds, so as not to loose > more than 60% of the times the transaction fees present in the block > template. This means that a pool admin serving 1000 clients must have a > upload bandwidth of at least 60 Mbytes/sec, and load balance servers, > because all miners will demand the block template at the same time and > will compete for it. > > The same miner, working solo, will not loose the 60% of block fees. If > block fees are 10% of block reward, then solo miners earn 6% more than > pool miners. Also, having a block rate of 5 seconds allows solo miners > to receive payments more often and so it reduces the payment variance. > > This method to discourage mining pools only work as long as time is > takes to transmit a block is comparable to the block interval time, e.g. > 20%. This seems not to be a problem since if the cryptocurrency becomes > popular, then we can expect blocks to be near full, while if is is not, > then nobody will care about mining pools. > > For this method to work for Bitcoin, Bitcoin should reduce the block > rate to at least 1 minute, and keep blocks of at least 10 Mbytes. Or go > the NimbleCoin way, and reduce the block interval to 5 seconds. The sole > reduction of the block rate from 10 minutes to 5 seconds would reduce > notably the mining reward variance, which is the main reason miners > don't mine solo. > > BitcoinBlockPow > > The basic BlockPoW is incompatible with Bitcoin ASICs as is but it can > be made partially compatible with some tweaks: The value b is replaced > by a a a subset or an integrity check of the block. > > Using a subset: > > First the hashMerkleRoot and hashPrevBlock fields are replaced by the > fields: ChildBlock (32 bytes) and ScatteredBlockBytes (32 bytes). > ChildBlock is the hash of a message with stores the old hashMerkleRoot > and hashPrevBlock. ScatteredBlockBytes is a pseudo-random subset of > bytes taken from the block template being mined. The seed for the > pseudo-random function that selects the subset is the hashMerkleRoot > plus the block time. When a miner scans all the 32bit nonce space, then > a new hashMerkleRoot must be created to increase the extra-nonce field > or the time must be updated. When this happens, a new subset of > pseudo-random 32 block bytes must be collected. If the miner only stores > 10% of the block template (e.g. 100 Kbytes instead of 1 Mbyte), then the > probability he can build the ScatteredBlockBytes by brute-forcing the > seed is 10^-32. If the miner performs 100 GH/sec, then the 32-bit nonce > will overflow every 20 msec and the miner could request the > ScatteredBlockBytes from the pool admin using a bandwidth of 1 Kbyte/s. > A pool hosting 6 PH/sec (such as Eligious, which has 8%) would need to > stream more than 60 Mb/s of ScatteredBlockBytes fields. A mining pool > having 50% would need to stream 500 Mb/s, which is quite challenging. So > miners will download the block normally, and become active part of the > network. > > Using an integrity check: > > ScatteredBlockBytes is replaced by a field BlockHash defined as H( > full-block-with-zero-nonce ). Obviously the header must be at the > beginning of the block to force the re-hash. > > Best regards, > Sergio. > > > > ------------------------------------------------------------------------------ > 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 >