[bitcoin-dev] Bitcoin Days Destroyed as block selection heuristic

[bitcoin-dev] Bitcoin Days Destroyed as block selection heuristic

[Dave Scotese]

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

Rather than (promising to, and when they don't actually, at least
pretending to) use the first-seen block, I propose that a more
sophisticated method of choosing which of two block solutions to accept.
Essentially, a miner receiving two solutions at the same height would
compute a weighted sum of bitcoin-days-destroyed (transactions received
earlier get higher weights) of whatever transactions are in a block *and
also* were in the miner's mempool *before* the first solution arrived.
Whichever block has more wins.

This strategy avoids allowing miners to use private transactions to mess
with the blockchain.  It also makes an empty block far less attractive
because it is easily replaced, all the way until the next block locks it
in.  Any block-selection heuristic can be gamed, but I believe that using a
weighted sum of BTCDD is harder to game than using block propagation timing.

I asked Can Bitcoin Days Destroyed be a better resolution mechanism for
competing blocks?
<http://bitcoin.stackexchange.com/questions/39226/can-bitcoin-days-destroyed-be-a-better-resolution-mechanism-for-competing-blocks>
on the stackexchange bitcoin site in order to collect objections to and
problems with this idea, and have not found any that I haven't addressed.
The best objection is that *maybe* empty blocks and selfish mining are
either good for bitcoin, or else they are so minimally bad that no effort
ought to be expended in preventing them.

If anyone here thinks this is a good idea, and no one can offer reasons
it's a bad idea, I will probably start working on an implementation.  I'm
really slow though, so ping me if it looks like fun to you.

notplato

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

Re: [bitcoin-dev] Bitcoin Days Destroyed as block selection heuristic

[Jorge Timón]

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

On Sep 11, 2015 12:27 PM, "Dave Scotese via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Rather than (promising to, and when they don't actually, at least
pretending to) use the first-seen block, I propose that a more
sophisticated method of choosing which of two block solutions to accept.

There's already a criterion to chose: the one with more work (in valid
blocks) on top of it.

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

Re: [bitcoin-dev] Bitcoin Days Destroyed as block selection heuristic

[Christophe Biocca]

It's pretty obvious that Dave is suggesting an alternate tie-breaker:

> It also makes an empty block far less attractive because it is easily replaced, all the way until the next block locks it in.

I do see a problem with the proposal. Right now, when a miner sees a
new block with the most work and there are no ties, it is always a
good idea to build on top of it (unless they're in the middle of
building a private chain, or other pathological cases).

With this new heuristic (assuming it is actually followed by a good
chunk of people), a miner can reasonably know whether or not they can
safely mine a sibling of the block instead. When enough widely
propagated transactions exist, and the block to orphan is small,
there's minimal risk in mining a sibling block instead of a child
block (the only extra risk is in someone else mining a child block
right around the time we suceed in mining a siblish block, where we'll
definitely be orphaned instead of ~50% of the time).

Because the risk can be measured and is sometimes very small, it will
then be profitable for a miner to orphan a small non-empty block and
double-spend some confirmed transactions whenever the block confirming
them is easily replaced. This lowers the security of 1-conf
transactions.

Mind you, that risk doesn't apply if we prefer non-empty blocks to
empty blocks and leave it at that, or only switch if the new block
doesn't double spend transactions in the old one, so it's a fixable
issue.

On 11 September 2015 at 12:32, Jorge Timón
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> On Sep 11, 2015 12:27 PM, "Dave Scotese via bitcoin-dev"
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> Rather than (promising to, and when they don't actually, at least
>> pretending to) use the first-seen block, I propose that a more sophisticated
>> method of choosing which of two block solutions to accept.
>
> There's already a criterion to chose: the one with more work (in valid
> blocks) on top of it.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

Re: [bitcoin-dev] Bitcoin Days Destroyed as block selection heuristic

[Jorge Timón]

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

On Sep 11, 2015 1:18 PM, "Christophe Biocca" <christophe.biocca@gmail.com>
wrote:
>
> It's pretty obvious that Dave is suggesting an alternate tie-breaker:

I thought he was proposing a new consesnsus rule. I see, this would be just
a policy validation that everybody would be free to ignore (like the "first
seen" spend conflict tx replacement policy).

I don't see how miners would benefit from running this policy so I would
not expect them to run it in the long run (like the "first seen" spend
conflict tx replacement policy).
If miners don't use it, I don't see how users can benefit from running that
policy themselves.
They will still have to keep waiting some block confirmation to
exponentially reduce the chances of a successful double-spend attack with
each new confirmation (as explained in the bitcoin white paper).

> Mind you, that risk doesn't apply if we prefer non-empty blocks to
> empty blocks and leave it at that, or only switch if the new block
> doesn't double spend transactions in the old one, so it's a fixable
> issue.

How do you know which of 2 blocks with the same height is "newer"?

> On 11 September 2015 at 12:32, Jorge Timón
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> > On Sep 11, 2015 12:27 PM, "Dave Scotese via bitcoin-dev"
> > <bitcoin-dev@lists.linuxfoundation.org> wrote:
> >>
> >> Rather than (promising to, and when they don't actually, at least
> >> pretending to) use the first-seen block, I propose that a more
sophisticated
> >> method of choosing which of two block solutions to accept.
> >
> > There's already a criterion to chose: the one with more work (in valid
> > blocks) on top of it.
> >
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >

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

Re: [bitcoin-dev] Bitcoin Days Destroyed as block selection heuristic

[Christophe Biocca]

> How do you know which of 2 blocks with the same height is "newer"?

From the particular node's perspective. I'm aware there is no
possibility of consistent global ordering.

Dave's code is about switching blocks (instead of continuing on the
existing one), and, in that context, "old" means the first sibling the
node saw, and "new" is any subsequent block. I will disambiguate this
in the future, because I'm clearly confusing at least 1 person.

> I don't see how miners would benefit from running this policy so I would not expect them to run it in the long run (like the "first seen" spend conflict tx replacement policy).

There's always a default, and if miners don't have any overriding
reason to change, they'll likely stick to it. Which is why Dave
started his statement with:

> Rather than (promising to, and when they don't actually, at least pretending to) use the first-seen block

Clearly recognizing that any changed logic is non-binding.

On 11 September 2015 at 14:37, Jorge Timón <jtimon@jtimon.cc> wrote:
>
> On Sep 11, 2015 1:18 PM, "Christophe Biocca" <christophe.biocca@gmail.com>
> wrote:
>>
>> It's pretty obvious that Dave is suggesting an alternate tie-breaker:
>
> I thought he was proposing a new consesnsus rule. I see, this would be just
> a policy validation that everybody would be free to ignore (like the "first
> seen" spend conflict tx replacement policy).
>
> I don't see how miners would benefit from running this policy so I would not
> expect them to run it in the long run (like the "first seen" spend conflict
> tx replacement policy).
> If miners don't use it, I don't see how users can benefit from running that
> policy themselves.
> They will still have to keep waiting some block confirmation to
> exponentially reduce the chances of a successful double-spend attack with
> each new confirmation (as explained in the bitcoin white paper).
>
>> Mind you, that risk doesn't apply if we prefer non-empty blocks to
>> empty blocks and leave it at that, or only switch if the new block
>> doesn't double spend transactions in the old one, so it's a fixable
>> issue.
>
> How do you know which of 2 blocks with the same height is "newer"?
>
>> On 11 September 2015 at 12:32, Jorge Timón
>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> >
>> > On Sep 11, 2015 12:27 PM, "Dave Scotese via bitcoin-dev"
>> > <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> >>
>> >> Rather than (promising to, and when they don't actually, at least
>> >> pretending to) use the first-seen block, I propose that a more
>> >> sophisticated
>> >> method of choosing which of two block solutions to accept.
>> >
>> > There's already a criterion to chose: the one with more work (in valid
>> > blocks) on top of it.
>> >
>> >
>> > _______________________________________________
>> > bitcoin-dev mailing list
>> > bitcoin-dev@lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >

Re: [bitcoin-dev] Bitcoin Days Destroyed as block selection heuristic

[Dave Scotese]

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

Yes, this proposal is a policy that everyone would be free to ignore.  I
should have introduced the situation in which this *unenforceable* policy
makes sense to me.  Here it is:

Every miner is listening for valid block solutions but might receive two
valid blocks and then they have to decide which one to use.  Choosing the
one you saw first is the default behavior.  In that situation, we'd all
like everyone to choose the same block.  I propose that a better heuristic
than "first seen" is to compare the BTCDD, *but only of transactions you
already have in your mempool*, and

*weight the BTCDD so that txns you got earlier are more important.*
The heuristic is most useful when the two blocks are received within a
small window of time, opting for the first-seen rule otherwise.  I assume
many miners have an idea of how long it takes for anyone's new block to get
across the network, and more specifically, the range of times it takes for
new solutions to get to themselves.  During this little time window, the
chances are 50/50 that they'll choose the right block.  If the default
behavior were to use BTCDD during that time window (one second? I have no
idea!), then the chances would be significantly better.

I think Jorge is right that it doesn't benefit miners.  It doesn't hurt
them either, unless they are trying to do selfish mining.  Well, it
benefits them in terms of increased bitcoin stability by A) making it
easier for clients to decide which block is valid when they see two
competing with each other, B) motivating miners to add transactions instead
of mining empty blocks, C) severely decreasing the utility of any global
private network of nodes intended to spread selfishly-mined blocks, and D)
motivating miners to stay well-connected so that they get transactions
quickly.

I sent this to the list because it is only useful if it is set as default
behavior since most miners leave the defaults alone, and the benefits don't
materialize unless a majority follows the policy.

On Fri, Sep 11, 2015 at 11:37 AM, Jorge Timón <jtimon@jtimon.cc> wrote:

>
> On Sep 11, 2015 1:18 PM, "Christophe Biocca" <christophe.biocca@gmail.com>
> wrote:
> >
> > It's pretty obvious that Dave is suggesting an alternate tie-breaker:
>
> I thought he was proposing a new consesnsus rule. I see, this would be
> just a policy validation that everybody would be free to ignore (like the
> "first seen" spend conflict tx replacement policy).
>
> I don't see how miners would benefit from running this policy so I would
> not expect them to run it in the long run (like the "first seen" spend
> conflict tx replacement policy).
> If miners don't use it, I don't see how users can benefit from running
> that policy themselves.
> They will still have to keep waiting some block confirmation to
> exponentially reduce the chances of a successful double-spend attack with
> each new confirmation (as explained in the bitcoin white paper).
>
> > Mind you, that risk doesn't apply if we prefer non-empty blocks to
> > empty blocks and leave it at that, or only switch if the new block
> > doesn't double spend transactions in the old one, so it's a fixable
> > issue.
>
> How do you know which of 2 blocks with the same height is "newer"?
>
> > On 11 September 2015 at 12:32, Jorge Timón
> > <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > >
> > > On Sep 11, 2015 12:27 PM, "Dave Scotese via bitcoin-dev"
> > > <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > >>
> > >> Rather than (promising to, and when they don't actually, at least
> > >> pretending to) use the first-seen block, I propose that a more
> sophisticated
> > >> method of choosing which of two block solutions to accept.
> > >
> > > There's already a criterion to chose: the one with more work (in valid
> > > blocks) on top of it.
> > >
> > >
> > > _______________________________________________
> > > bitcoin-dev mailing list
> > > bitcoin-dev@lists.linuxfoundation.org
> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > >
>



-- 
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto

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

Re: [bitcoin-dev] Bitcoin Days Destroyed as block selection heuristic

[Vincent Truong]

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

Would this alter the way txns will be prioritised in order to try to win?
You would always pick txns with the best BTCDD to maximize your chances of
being the block to build on.

I see this as potentially being a bad outcome for bitcoin's fungibility.
On Sep 12, 2015 5:26 AM, "Dave Scotese via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Yes, this proposal is a policy that everyone would be free to ignore.  I
> should have introduced the situation in which this *unenforceable* policy
> makes sense to me.  Here it is:
>
> Every miner is listening for valid block solutions but might receive two
> valid blocks and then they have to decide which one to use.  Choosing the
> one you saw first is the default behavior.  In that situation, we'd all
> like everyone to choose the same block.  I propose that a better heuristic
> than "first seen" is to compare the BTCDD, *but only of transactions you
> already have in your mempool*, and
>
> *weight the BTCDD so that txns you got earlier are more important.*
> The heuristic is most useful when the two blocks are received within a
> small window of time, opting for the first-seen rule otherwise.  I assume
> many miners have an idea of how long it takes for anyone's new block to get
> across the network, and more specifically, the range of times it takes for
> new solutions to get to themselves.  During this little time window, the
> chances are 50/50 that they'll choose the right block.  If the default
> behavior were to use BTCDD during that time window (one second? I have no
> idea!), then the chances would be significantly better.
>
> I think Jorge is right that it doesn't benefit miners.  It doesn't hurt
> them either, unless they are trying to do selfish mining.  Well, it
> benefits them in terms of increased bitcoin stability by A) making it
> easier for clients to decide which block is valid when they see two
> competing with each other, B) motivating miners to add transactions instead
> of mining empty blocks, C) severely decreasing the utility of any global
> private network of nodes intended to spread selfishly-mined blocks, and D)
> motivating miners to stay well-connected so that they get transactions
> quickly.
>
> I sent this to the list because it is only useful if it is set as default
> behavior since most miners leave the defaults alone, and the benefits don't
> materialize unless a majority follows the policy.
>
> On Fri, Sep 11, 2015 at 11:37 AM, Jorge Timón <jtimon@jtimon.cc> wrote:
>
>>
>> On Sep 11, 2015 1:18 PM, "Christophe Biocca" <christophe.biocca@gmail.com>
>> wrote:
>> >
>> > It's pretty obvious that Dave is suggesting an alternate tie-breaker:
>>
>> I thought he was proposing a new consesnsus rule. I see, this would be
>> just a policy validation that everybody would be free to ignore (like the
>> "first seen" spend conflict tx replacement policy).
>>
>> I don't see how miners would benefit from running this policy so I would
>> not expect them to run it in the long run (like the "first seen" spend
>> conflict tx replacement policy).
>> If miners don't use it, I don't see how users can benefit from running
>> that policy themselves.
>> They will still have to keep waiting some block confirmation to
>> exponentially reduce the chances of a successful double-spend attack with
>> each new confirmation (as explained in the bitcoin white paper).
>>
>> > Mind you, that risk doesn't apply if we prefer non-empty blocks to
>> > empty blocks and leave it at that, or only switch if the new block
>> > doesn't double spend transactions in the old one, so it's a fixable
>> > issue.
>>
>> How do you know which of 2 blocks with the same height is "newer"?
>>
>> > On 11 September 2015 at 12:32, Jorge Timón
>> > <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> > >
>> > > On Sep 11, 2015 12:27 PM, "Dave Scotese via bitcoin-dev"
>> > > <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> > >>
>> > >> Rather than (promising to, and when they don't actually, at least
>> > >> pretending to) use the first-seen block, I propose that a more
>> sophisticated
>> > >> method of choosing which of two block solutions to accept.
>> > >
>> > > There's already a criterion to chose: the one with more work (in valid
>> > > blocks) on top of it.
>> > >
>> > >
>> > > _______________________________________________
>> > > bitcoin-dev mailing list
>> > > bitcoin-dev@lists.linuxfoundation.org
>> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> > >
>>
>
>
>
> --
> I like to provide some work at no charge to prove my value. Do you need a
> techie?
> I own Litmocracy <http://www.litmocracy.com> and Meme Racing
> <http://www.memeracing.net> (in alpha).
> I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com>
> which now accepts Bitcoin.
> I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
> "He ought to find it more profitable to play by the rules" - Satoshi
> Nakamoto
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

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

Re: [bitcoin-dev] Bitcoin Days Destroyed as block selection heuristic

[Dave Scotese]

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

>
> From the Bitcoin wiki page on transaction fees
> <https://en.bitcoin.it/wiki/Transaction_fees#Technical_info>:
>
> Transaction priority is calculated as a value-weighted sum of input age,
> divided by transaction size in bytes: priority =
> sum(input_value_in_base_units * input_age)/size_in_bytes
>
If I read that correctly, that is directly proportional to BTCDD, so
whatever effect concerns you has already been built into the code.

On Fri, Sep 11, 2015 at 3:21 PM, Vincent Truong <
vincent.truong@procabiak.com> wrote:

> Would this alter the way txns will be prioritised in order to try to win?
> You would always pick txns with the best BTCDD to maximize your chances of
> being the block to build on.
>
> I see this as potentially being a bad outcome for bitcoin's fungibility.
>

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