From: Tier Nolan <tier.nolan@gmail•com>
Cc: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] [BIP] Normalized Transaction IDs
Date: Wed, 13 May 2015 17:18:24 +0100 [thread overview]
Message-ID: <CAE-z3OXumLSS9phiw6x6MEv+p6My+HtgT9WaKQheKLASBytAJQ@mail.gmail.com> (raw)
In-Reply-To: <CALxbBHXjhgWrOdEa=_QLcvryZhP=tmdaCGnRwE9qNXJnVBmtjA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4683 bytes --]
On Wed, May 13, 2015 at 4:24 PM, Christian Decker <
decker.christian@gmail•com> wrote
> It does and I should have mentioned it in the draft, according to my
> calculations a mapping legacy ID -> normalized ID is about 256 MB in size,
> or at least it was at height 330'000, things might have changed a bit and
> I'll recompute that. I omitted the deprecation of legacy IDs on purpose
> since we don't know whether we will migrate completely or leave keep both
> options viable.
>
There are around 20 million UTXOs. At 2*32 bytes per entry, that is more
than 1GB. There are more UTXOs than transactions, but 256MB seems a little
low.
I think both IDs can be used in the merkle tree, since we lookup an ID in
> both indices we can use both to address them and we will find them either
> way.
>
The id that is used to sign should be used in the merkle tree. The hard
fork should simply be to allow transactions that use the normalized
transaction hash.
> As for the opcodes I'll have to check, but I currently don't see how they
> could be affected.
>
Agreed, the transaction is simply changed and all the standard rules apply.
> We can certainly split the proposal should it get too large, for now it
> seems manageable, since opcodes are not affected.
>
Right it is just a database update. The undo info also needs to be changed
so that both txids are included.
> Bloom-filtering is resolved by adding the normalized transaction IDs and
> checking for both IDs in the filter.
>
Yeah, if a transaction spends with a legacy txid, it should still match if
the normalized txid is included in the filter.
> Since you mention bundling the change with other changes that require a
hard-fork it might be a good idea to build a separate proposal for a
generic hard-fork rollout mechanism.
That would be useful. On the other hand, we don't want to make them to
easy.
I think this is a good choice for a hard fork test, since it is
uncontroversial. With a time machine, it would have been done this way at
the start.
What about the following:
The reference client is updated so that it uses version 2 transactions by
default (but it can be changed by user). A pop-up could appear for the GUI.
There is no other change.
All transactions in blocks 375000 to 385000 are considered votes and
weighted by bitcoin days destroyed (max 60 days).
If > 75% of the transactions by weight are version 2, then the community
are considered to support the hard fork.
There would need to be a way to protect against miners censoring
transactions/votes.
Users could submit their transactions directly to a p2p tallying system.
The coin would be aged based on the age in block 375000 unless included in
the blockchain. These votes don't need to be ordered and multiple votes
for the same coin would only count once.
In fact, votes could just be based on holding in block X.
This is an opinion poll rather than a referendum though.
Assuming support of the community, the hard fork can then proceed in a
similar way to the way a soft fork does.
Devs update the reference client to produce version 4 blocks and version 3
transactions. Miners could watch version 3 transactions to gauge user
interest and use that to help decide if they should update.
If 750 of the last 1000 blocks are version 4 or higher, reject blocks with
transactions of less than version 3 in version 4 blocks
This means that legacy clients will be slow to confirm their
transactions, since their transactions cannot go into version 4 blocks.
This is encouragement to upgrade.
If 950 of the last 1000 blocks are version 4 or higher, reject blocks with
transactions of less than version 3 in all blocks
This means that legacy nodes can no longer send transactions but can
still receive. Transactions received from other legacy nodes would remain
unconfirmed.
If 990 of the last 1000 blocks are version 4 or higher, reject version 3 or
lower blocks
This is the point of no return. Rejecting version 3 blocks means that
the next rule is guaranteed to activate within the next 2016 blocks.
Legacy nodes remain on the main chain, but cannot send. Miners mining with
legacy clients are (soft) forked off the chain.
If 1000 of the last 1000 blocks are version 4 or higher and the difficulty
retarget has just happened, activate hard fork rule
This hard forks legacy nodes off the chain. 99% of miners support this
change and users have been encouraged to update. The block rate for the
non-forked chain is ast most 1% of normal. Blocks happen every 16 hours.
By timing activation after a difficulty retarget, it makes it harder for
the other fork to adapt to the reduced hash rate.
>
[-- Attachment #2: Type: text/html, Size: 6995 bytes --]
next prev parent reply other threads:[~2015-05-13 16:18 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-13 12:48 Christian Decker
2015-05-13 13:12 ` Tier Nolan
2015-05-13 13:41 ` Gavin Andresen
2015-05-13 15:24 ` Christian Decker
2015-05-13 16:18 ` Tier Nolan [this message]
2015-05-13 16:34 ` Luke Dashjr
2015-05-13 17:14 ` Pieter Wuille
2015-05-13 18:04 ` Christian Decker
2015-05-13 18:40 ` Pieter Wuille
2015-05-13 19:14 ` Christian Decker
2015-05-13 19:40 ` Pieter Wuille
2015-05-13 18:11 ` Tier Nolan
2015-05-13 20:27 ` Tier Nolan
2015-05-13 20:31 ` Pieter Wuille
2015-05-13 20:32 ` Tier Nolan
2015-05-14 0:37 ` Pieter Wuille
2015-05-14 11:01 ` Christian Decker
2015-05-14 11:26 ` Christian Decker
2015-05-15 9:54 ` s7r
2015-05-15 10:45 ` Tier Nolan
2015-05-15 16:31 ` Luke Dashjr
2015-05-16 3:58 ` Stephen
2015-05-16 10:52 ` Tier Nolan
2015-05-19 8:28 ` Christian Decker
2015-05-19 9:13 ` Tier Nolan
2015-05-19 10:43 ` Christian Decker
2015-05-19 12:48 ` Stephen Morse
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=CAE-z3OXumLSS9phiw6x6MEv+p6My+HtgT9WaKQheKLASBytAJQ@mail.gmail.com \
--to=tier.nolan@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/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