From: Tomas <tomas@tomasvdw•nl>
To: Eric Voskuil <eric@voskuil•org>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>,
Libbitcoin Development <libbitcoin@lists•dyne.org>
Subject: Re: [bitcoin-dev] Using a storage engine without UTXO-index
Date: Tue, 11 Apr 2017 12:04:01 +0200 [thread overview]
Message-ID: <1491905041.2824926.941053248.0A8F8971@webmail.messagingengine.com> (raw)
In-Reply-To: <83947375-e06b-71dd-1f79-6ca97bea392e@voskuil.org>
On Tue, Apr 11, 2017, at 11:41, Eric Voskuil wrote:
> It's not the headers/tx-hashes of the blocks that I'm referring to, it
> is the confirmation and spend information relative to all txs and all
> outputs for each branch. This reverse navigation (i.e. utxo
> information) is essential, must be persistent and is branch-relative.
That is exactly what is stored in the spend-tree.
>> As a simpler example, if two miners both mine a block at
>> approximately the same time and send it to each other, then surely
>> they would want to continue mining on their own block. Otherwise
>> they would be throwing away their own reward.
> That's not your concurrent validation scenario. In the scenario you
> described, the person chooses the weaker block of two that require
> validation because it's better somehow, not because it's his own
> (which does not require validation).
> Consistency is reached, despite seeing things at different times,
> because people use the same rules. If the economy ran on arbitrary
> block preference consistency would be elusive.
No but my example shows that it is up to the miner to choose which tip
to work on. This is not using different rules, it is just optimizing its
income. This means that the economy *does* run on arbitrary "block
preference", even if it is not running on arbitrary rules.
If two blocks are competing, a miner could optimize its decision which
to mine on, not just on whether one of the blocks is his own, but also
on fees, or on excessive validation costs.
> I read this as encoding the height at which a fork historically
> activated. If you intend to track activation for each branch that will
> not be "height-based" it will be history based.
I understand "height-based" was not the right wording, as it is of
course branch-specific. Per tip ruleset metadata, must be matched with
per-transaction ruleset metadata.
Tomas
next prev parent reply other threads:[~2017-04-11 10:04 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-06 22:12 Tomas
2017-04-06 23:38 ` Eric Voskuil
2017-04-07 0:17 ` Tomas
2017-04-08 22:37 ` Eric Voskuil
2017-04-08 23:58 ` Tomas
2017-04-11 1:44 ` Eric Voskuil
2017-04-11 8:43 ` Tomas
2017-04-11 9:41 ` Eric Voskuil
2017-04-11 10:04 ` Tomas [this message]
[not found] ` <CAAS2fgTEMCkDWdhCWt1EsUrnt3+Z_8m+Y1PTsff5Rc0CBnCKWQ@mail.gmail.com>
2017-04-07 0:48 ` Tomas
2017-04-07 1:09 ` Gregory Maxwell
2017-04-07 1:29 ` Tomas
2017-04-07 18:52 ` Tom Harding
2017-04-07 19:42 ` Gregory Maxwell
2017-04-08 18:27 ` Tom Harding
2017-04-08 19:23 ` Tomas
2017-04-07 7:55 ` Marcos mayorga
2017-04-07 8:47 ` Tomas
2017-04-07 14:14 ` Greg Sanders
2017-04-07 16:02 ` Tomas
2017-04-07 18:18 ` Gregory Maxwell
2017-04-07 18:39 ` Bram Cohen
2017-04-07 19:55 ` Eric Voskuil
2017-04-07 21:44 ` Tomas
2017-04-07 23:51 ` Eric Voskuil
2017-04-07 21:14 ` Tomas
2017-04-08 0:44 ` Gregory Maxwell
2017-04-08 7:28 ` Tomas
2017-04-08 19:23 ` Johnson Lau
2017-04-08 19:56 ` Tomas
2017-04-08 20:21 ` Johnson Lau
2017-04-08 20:42 ` Tomas
2017-04-08 22:12 ` Gregory Maxwell
2017-04-08 22:34 ` Tomas
2017-04-08 21:22 ` Troy Benjegerdes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1491905041.2824926.941053248.0A8F8971@webmail.messagingengine.com \
--to=tomas@tomasvdw$(echo .)nl \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=eric@voskuil$(echo .)org \
--cc=libbitcoin@lists$(echo .)dyne.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox