On Thu, Jun 19, 2014 at 09:54:31AM -0400, Gavin Andresen wrote:
> RE: soft-forks bumping version numbers:
>
> Yes, we have consensus that is the way we will do it. I should probably
> turn https://gist.github.com/gavinandresen/2355445 into an informational
> BIP.
Sounds like it could turn EvalSc
It's not the pool operator's business what software the miner is running
to select transactions for his block, so long as the miner follows the
template and doesn't generate invalid blocks. We already discussed
invalid blocks, and checking the template requires parsing the coinbase
transaction and
Miner issues are just one thing what came to my mind. What about validating
transactions? How the pool can be sure that miner is running up to date
bitcoind which do full validation of transactions? Not talking that if
every miner takes his own set of transaction, pool need to calculate merkle
root
On Thu, Jun 19, 2014 at 7:35 PM, Mike Hearn wrote:
>
> My (fresh!) understanding is that the reason we don't see people using
> getblocktemplate to decentralise pools is because libblkmaker and other
> implementations don't actually support connecting your own node to the
> miners and choosing you
Do you need to do full validation? There's an economic cost to mining
invalid blocks, and even if that were acceptable there's really no
reason to perform such an attack. The result would be similar to a block
withholding attack, but unlike block withholding it would be trivially
detectable if/when
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/19/2014 05:11 PM, Kevin wrote:
> Why do you want to punish pools?
It's part of a general trend wherein people look at all the things
that can be accomplished in an economy that has a division of labor*,
and see some misbehavior at the edges, and
>
> The issue is centralized transaction selection policies, which is
> entirely orthogonal. And the solution already exists: getblocktemplate.
My (fresh!) understanding is that the reason we don't see people using
getblocktemplate to decentralise pools is because libblkmaker and other
implementa
> Supporting it in the protocol is easy. Building such a thing: that's
hard. Decentralised automated reputation systems are complex and subtle.
Bitcoin is valuable as a protocol because it is truly decentralized. The
complexity involved in building this system was expansive, but I think we
can all
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
On 6/19/2014 12:58 PM, 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
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
RE: soft-forks bumping version numbers:
Yes, we have consensus that is the way we will do it. I should probably
turn https://gist.github.com/gavinandresen/2355445 into an informational
BIP.
RE: malleability:
Orthogonal (but related) issue to IsStandard.
Detecting Scripts that leave extra items
On Wed, Jun 18, 2014 at 08:52:22AM -0400, Gavin Andresen wrote:
> RE: most of Peter Todd's comments:
>
> All of that should be separate pull requests. Big Honking Pull Requests
> are harder to review and are more likely to be bike-shedded to death.
Well, just doing one and not the rest isn't nec
13 matches
Mail list logo