[bitcoin-dev] Encouraging good miners

[bitcoin-dev] Encouraging good miners

[Btc Ideas]

[-- Attachment #1: Type: text/plain, Size: 704 bytes --]

Add a preference for mined blocks to be the one with more transactions. This comes into play when 2 blocks of the same height are found. The first good block mined would be orphaned if it had less transactions than another. Optionally, have this rule apply to the current block and the previous one.

This increases incentive for full blocks because a miner thinking the faster propagation of a smaller block will win him the reward, but that would no longer be a good assumption.

I read some miners could attack a chain by mining small or empty blocks. This makes that a little more difficult, but they can still attack the chain many ways.

Sent with [ProtonMail](https://protonmail.com) Secure Email.

[-- Attachment #2: Type: text/html, Size: 934 bytes --]

Re: [bitcoin-dev] Encouraging good miners

[Jameson Lopp]

[-- Attachment #1: Type: text/plain, Size: 1560 bytes --]

Bitcoin chooses the "best chain" based upon the one that has the most
cumulative proof of work behind it. Are you proposing that the cumulative
proof of work be ignored if two blocks are within a certain threshold of
each others' work and if so, the number of transactions in the block / the
size of the block should be used as a "tie breaker?"

I think this idea needs more fleshing out of exactly how it would work,
with careful consideration that adding complexity to the best chain logic
could introduce exploitable flaws.

On Mon, Mar 27, 2017 at 12:12 PM, Btc Ideas via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Add a preference for mined blocks to be the one with more transactions.
> This comes into play when 2 blocks of the same height are found. The first
> good block mined would be orphaned if it had less transactions than
> another. Optionally, have this rule apply to the current block and the
> previous one.
>
> This increases incentive for full blocks because a miner thinking the
> faster propagation of a smaller block will win him the reward, but that
> would no longer be a good assumption.
>
> I read some miners could attack a chain by mining small or empty blocks.
> This makes that a little more difficult, but they can still attack the
> chain many ways.
>
>
> Sent with ProtonMail <https://protonmail.com> Secure Email.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #2: Type: text/html, Size: 2377 bytes --]

Re: [bitcoin-dev] Encouraging good miners

[Btc Ideas]

[-- Attachment #1: Type: text/plain, Size: 1766 bytes --]

I know miners can do that, but it is not meant to primarily stop a malicious miner, but just to keep the blocks full. I think it is good to convince greedy miners not to mine empty blocks for a speed advantage.

Sent with [ProtonMail](https://protonmail.com) Secure Email.

-------- Original Message --------
Subject: Re: [bitcoin-dev] Encouraging good miners
Local Time: March 28, 2017 12:23 AM
UTC Time: March 27, 2017 4:23 PM
From: patrick.mccorry@newcastle.ac.uk
To: Btc Ideas <btcideas@protonmail.com>, Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>

Miner's can include transactions that send themselves bitcoins. Number of transactions is not a good measure of utility.

---------------------------------------------------------------

From: bitcoin-dev-bounces@lists.linuxfoundation.org <bitcoin-dev-bounces@lists.linuxfoundation.org> on behalf of Btc Ideas via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Sent: 27 March 2017 17:12:19
To: bitcoin-dev@lists.linuxfoundation.org
Subject: [bitcoin-dev] Encouraging good miners

Add a preference for mined blocks to be the one with more transactions. This comes into play when 2 blocks of the same height are found. The first good block mined would be orphaned if it had less transactions than another. Optionally, have this rule apply to the current block and the previous one.

This increases incentive for full blocks because a miner thinking the faster propagation of a smaller block will win him the reward, but that would no longer be a good assumption.

I read some miners could attack a chain by mining small or empty blocks. This makes that a little more difficult, but they can still attack the chain many ways.

Sent with [ProtonMail](https://protonmail.com) Secure Email.

[-- Attachment #2: Type: text/html, Size: 3287 bytes --]

Re: [bitcoin-dev] Encouraging good miners

[Tom Zander]

For some time now the relation between block size and propagation speed has 
been decoupled. Using xthin/compact blocks miners only send a tiny version 
of a block which then causes the receiving node to re-create it using the 
memory pool.  Immediately getting double benefits by including pre-verified 
transactions from the memory pool you avoid the old problem of having to 
validate them again when a block was mined.

As such there is no downside to a miner creating a bigger block, as long as 
all the transactions they include are actually in the mempool.

As such I'm personally convinced that the problem you are trying to solve 
has already been solved.

Cheers!


On Monday, 27 March 2017 18:12:19 CEST Btc Ideas via bitcoin-dev wrote:
> Add a preference for mined blocks to be the one with more transactions.
> This comes into play when 2 blocks of the same height are found. The
> first good block mined would be orphaned if it had less transactions than
> another. Optionally, have this rule apply to the current block and the
> previous one.
> 
> This increases incentive for full blocks because a miner thinking the
> faster propagation of a smaller block will win him the reward, but that
> would no longer be a good assumption.


-- 
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

Re: [bitcoin-dev] Encouraging good miners

[Eric Voskuil]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 03/27/2017 10:29 AM, Tom Zander via bitcoin-dev wrote:
> For some time now the relation between block size and propagation
> speed has been decoupled. Using xthin/compact blocks miners only
> send a tiny version of a block which then causes the receiving node
> to re-create it using the memory pool.  Immediately getting double
> benefits by including pre-verified transactions from the memory
> pool you avoid the old problem of having to validate them again
> when a block was mined.
> 
> As such there is no downside to a miner creating a bigger block, as
> long as all the transactions they include are actually in the
> mempool.

All transactions being publicly available is not something that can be
assumed.

With no opportunity cost for a miner to generate withheld
transactions, a larger miner still maintains the economic advantage of
latency as a function of block size. Fast relay works to reduce
latency in relation to the opportunity cost created by the space
constraint. IOW, the more fees a miner must give up to mine withheld
transactions, the greater the economic disadvantage of doing so. So
there is a "downside" (i.e. centralization pressure) up to the point
where the advantage gained from withholding transactions turns negative.

The rational competing miner must presume that a block is valid upon
confirming the announcement's PoW. He then has the choice of mining on
top of the (partially-visible) block, or ignoring it until it can be
fully populated. The former *eliminates fee opportunity*, since the
next block must remain free of all public fee-generating transactions
until all of the preceding block's transactions are visible. The
latter increases orphaning probability, since it implies mining on the
weak chain, which *increases total reward loss*.

One can conclude that no matter how much space is created, it will
always be filled by a rational miner, as a competitive necessity,
given the centralizing effect of latency. Making blocks big enough to
include low cost transactions nullifies the benefits of fast relay
techniques based on your above assumption, since a rational miner will
simply substitute withheld transactions.

e
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBCAAGBQJY2W+bAAoJEDzYwH8LXOFOzkwH+wUulsdvUcfEHMspolfDjTD+
f4egP1FDoOFgXzaGJ+Bq1AjWP+CDYup9msYhp1NTk6xRnG4uGvaEA3DFYGbAzLut
INtkpCi38O1QGtDJaxmkJHXLoWJPS6VudcDEoam4W6qSKgHFB+ZRnIN4T7jnGMLI
rp/cGdom9wE/pcq/fvF/fonGfVWf/YP2YjBzJzaJy+zOYPTH2rNcnYBCHFPs4/KX
9Gu7tDw9WNxM5idnd0TiidublQhYui6xo7ZbZpmXQePcHQoQO5XqaO6yWwiWRWaU
mqXhalASOtP6xnPzj6FfAHYS7qA7JCaDfwT8UIzt9xv9XsPrhQ/r6Sfgfhvbm2k=
=b9sf
-----END PGP SIGNATURE-----

Re: [bitcoin-dev] Encouraging good miners

[Stian Ellingsen]

On 27/03/17 18:12, Btc Ideas via bitcoin-dev wrote:

> Add a preference for mined blocks to be the one with more
> transactions. This comes into play when 2 blocks of the same height
> are found. The first good block mined would be orphaned if it had
> less transactions than another. Optionally, have this rule apply to
> the current block and the previous one.

This would encourage miners to make their own tiny junk transactions
to fill up their blocks, perhaps leaving larger, more space-efficient
transactions in the mempool.

> This increases incentive for full blocks because a miner thinking
> the faster propagation of a smaller block will win him the reward,
> but that would no longer be a good assumption.

> I read some miners could attack a chain by mining small or empty
> blocks. This makes that a little more difficult, but they can still
> attack the chain many ways.

"Good" miners should probably build upon the block with a set of
transactions more similar to what they themselves would include based
on their mempool at the time.  However, miners don't have an incentive
to do so today.  Instead, they may be better off building upon the
block that leaves the most valuable transactions in the mempool,
e.g. a small or empty block, and maybe leave some valuable
transactions in the mempool for the next miner.[1]  This issue could
possibly be addressed by a soft-fork that requires miners to pay a
portion of their fees to future miners.

[1]
https://freedom-to-tinker.com/2016/10/21/bitcoin-is-unstable-without-the-block-reward/

-- 
Stian

Re: [bitcoin-dev] Encouraging good miners

[Juan Garavaglia]

If a miner try to hurt the network mining just empty blocks at some time the rest will start rejecting their blocks and will be orphans so will loss the reward incentive and that miner will join the behavior of the rest of the miners, if that miner has 51% of hashrate there the smallest problem are the empty blocks.

-----Original Message-----
From: bitcoin-dev-bounces@lists.linuxfoundation.org [mailto:bitcoin-dev-bounces@lists.linuxfoundation.org] On Behalf Of Stian Ellingsen via bitcoin-dev
Sent: Monday, March 27, 2017 2:50 PM
To: Btc Ideas <btcideas@protonmail.com>; Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Encouraging good miners

On 27/03/17 18:12, Btc Ideas via bitcoin-dev wrote:

> Add a preference for mined blocks to be the one with more 
> transactions. This comes into play when 2 blocks of the same height 
> are found. The first good block mined would be orphaned if it had less 
> transactions than another. Optionally, have this rule apply to the 
> current block and the previous one.

This would encourage miners to make their own tiny junk transactions to fill up their blocks, perhaps leaving larger, more space-efficient transactions in the mempool.

> This increases incentive for full blocks because a miner thinking the 
> faster propagation of a smaller block will win him the reward, but 
> that would no longer be a good assumption.

> I read some miners could attack a chain by mining small or empty 
> blocks. This makes that a little more difficult, but they can still 
> attack the chain many ways.

"Good" miners should probably build upon the block with a set of transactions more similar to what they themselves would include based on their mempool at the time.  However, miners don't have an incentive to do so today.  Instead, they may be better off building upon the block that leaves the most valuable transactions in the mempool, e.g. a small or empty block, and maybe leave some valuable transactions in the mempool for the next miner.[1]  This issue could possibly be addressed by a soft-fork that requires miners to pay a portion of their fees to future miners.

[1]
https://freedom-to-tinker.com/2016/10/21/bitcoin-is-unstable-without-the-block-reward/

--
Stian


_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Encouraging good miners

[Antoine Le Calvez]

[-- Attachment #1: Type: text/plain, Size: 1419 bytes --]

I don't think encouraging mining more transactions is a good idea since 
it would promote inefficient transaction patterns. It's more efficient 
to send transactions with a high number of outputs/inputs instead of 
creating long transaction chains as some services do.

You might consider incentivizing miners to mine blocks that reduce the 
UTXO set size the most, or some other metric that promotes efficient 
uses of the blockchain.

On 27/03/17 17:12, Btc Ideas via bitcoin-dev wrote:
> Add a preference for mined blocks to be the one with more 
> transactions. This comes into play when 2 blocks of the same height 
> are found. The first good block mined would be orphaned if it had less 
> transactions than another. Optionally, have this rule apply to the 
> current block and the previous one.
>
> This increases incentive for full blocks because a miner thinking the 
> faster propagation of a smaller block will win him the reward, but 
> that would no longer be a good assumption.
>
> I read some miners could attack a chain by mining small or empty 
> blocks. This makes that a little more difficult, but they can still 
> attack the chain many ways.
>
>
> Sent with ProtonMail <https://protonmail.com> Secure Email.
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


[-- Attachment #2: Type: text/html, Size: 2636 bytes --]