From: Chris Priest <cp368202@ohiou•edu>
To: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: [bitcoin-dev] Coalescing Transactions BIP Draft
Date: Mon, 7 Dec 2015 15:39:12 -0800 [thread overview]
Message-ID: <CAAcC9yv3Eaqa4af0U4s_V3hpEt7cWn5mLx0DyhqBCK-g32D1yw@mail.gmail.com> (raw)
I made a post a few days ago where I laid out a scheme for
implementing "coalescing transactions" using a new opcode. I have
since come to the realization that an opcode is not the best way to do
this. A much better approach I think is a new "transaction type" field
that is split off from the version field. Other uses can come out of
this type field, wildcard inputs is just the first one.
There are two unresolved issues. First, there might need to be a limit
on how many inputs are included in the "coalesce". Lets say you have
an address that has 100,000,000 inputs. If you were to coalesce them
all into one single input, that means that every node has to count of
these 100,000,000 inputs, which could take a long time. But then
again, the total number of inputs a wildcard can cover is limited to
the actual number of UTXOs in the pool, which is very much a
finite/constrained number.
One solution is to limit all wildcard inputs to, say, 10,000 items. If
you have more inputs that you want coalesced, you have to do it in
10,000 chunks, starting from the beginning. I want wildcard inputs to
look as much like normal inputs as much as possible to facilitate
implementation, so embedding a "max search" inside the transaction I
don't think is the best idea. I think if there is going to be a limit,
it should be implied.
The other issue is with limiting wildcard inputs to only inputs that
are confirmed into a fixed number of blocks. Sort of like how coinbase
has to be a certain age before it can be spent, maybe wildcard inputs
should only work on inputs older than a certain block age. Someone
brought up in the last thread that re-orgs can cause problems. I don't
quite see how that could happen, as re-orgs don't really affect
address balances, only block header values, which coalescing
transactions have nothing to do with.
Here is the draft:
https://github.com/priestc/bips/blob/master/bip-coalesc-wildcard.mediawiki
reply other threads:[~2015-12-07 23:39 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=CAAcC9yv3Eaqa4af0U4s_V3hpEt7cWn5mLx0DyhqBCK-g32D1yw@mail.gmail.com \
--to=cp368202@ohiou$(echo .)edu \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.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