path: root/3e/71940b467fe4aa1a49e95c19f9d5af800f98f8

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 <mark@monetize.io>) 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 <bitcoin-development@lists.sourceforge.net>;
	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 <bitcoin-development@lists.sourceforge.net>
	(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 <mark@monetize.io>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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 <http://nimbleCoin.org>, 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
>