<div dir="auto">See this soft-fork proposal from Felix Weiss <div dir="auto"><br></div><div dir="auto"><a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/012194.html">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/012194.html</a><div dir="auto"><div dir="auto"><br></div><div dir="auto">Adam</div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Apr 12, 2017 5:43 PM, "Oleg Andreev via bitcoin-dev" <<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">(This is a sketch, not a fully-formed proposal, just to kick off the discussion.)<br>
<br>
Confidential Transactions (by GMaxwell & Poelstra) require a new accounting model,<br>
new representation of numbers (EC points as Pedersen commitments) and range proofs<br>
per number. Setting aside performance and bandwidth concerns (3-4Kb per output,<br>
50x more signature checks), how would we deploy that feature on Bitcoin network<br>
in the most compatible manner?<br>
<br>
I'll try to present a sketch of the proposal. I apologize if this discussion already<br>
happened somewhere, although I couldn't find anything on this subject, apart from Elements<br>
sidechain proposal, of course.<br>
<br>
At first glance we could create a new extblock and transaction format, add a protocol to<br>
"convert" money into and from such extblock, and commit to that extblock from the<br>
outer block's coinbase transaction. Unfortunately, this opens gates to a flood of<br>
debates such as what should be the block size limit in such block, should we<br>
take opportunity to fix over 9000 of pet-peeve issues with existing transactions<br>
and blocks, should we adjust inflation schedule, insert additional PoW, what would<br>
Satoshi say etc. Federated sidechain suffers from the same issues, plus adds<br>
concerns regarding governance, although it would be more decoupled, which is useful.<br>
<br>
I tried to look at a possibility to make the change as compatible as possible,<br>
sticking confidential values right into the existing transaction structure and<br>
see how that would look like. As a nice bonus, confidential transactions would have<br>
to fit into the hard-coded 1 Mb limit, preserving the drama around it :-P<br>
<br>
We start with a segwit-enabled script versioning and introduce 2 new script versions:<br>
version A has an actual program concatenated with the commitment, while version B<br>
has only the commitment and allows mimblewimble usage (no signatures, non-interactive<br>
cut-through etc). Legacy cleartext amount can nicely act as "min value" to minimize<br>
the range proof size, and range proofs themselves are provided separately in the<br>
segregated witness payload.<br>
<br>
Then, we soft fork additional rules:<br>
<br>
1. In non-coinbase tx, sum of commitments on inputs must balance with sum of commitments<br>
on the outputs plus the cleartext mining fee in the witness.<br>
2. Range proof can be confidential, based on borromean ring signature.<br>
3. Range proof can be non-confidential, consisting of an amount and raw blinding factor.<br>
4. Tx witness can have an excess value (cf. MW) and cleartext amount for a miner's fee.<br>
5. In coinbase tx, total plaintext reward + commitments must balance with subsidy,<br>
legacy fees and new fees in the witness.<br>
6. Extra fees in the witness must be signed with the excess value's key.<br>
<br>
The confidential transactions use the same UTXO set, can be co-authored with plaintext inputs/outputs<br>
using legacy software and maybe even improve scalability by compressing on-chain transactions<br>
using mimblewimble cut-through.<br>
<br>
The rules above could have been made more complicated with export/import logic to allow users<br>
converting their coins to and from confidential ones, but that would require<br>
more complex support from miners to respect and merge outputs representing "plaintext value bank",<br>
mutate export transactions, which in turn requires introduction of a non-malleable TxID<br>
that excludes miner-adjustable export/import outputs.<br>
<br>
The rules above have a nice side effect that miners, being the minters of confidential coins,<br>
can sell them at a premium, which creates an incentive for them to actually support<br>
that feature and work on improving performance of rangeproof validation (e.g. in GPUs).<br>
<br>
Would love to hear comments and criticism of that approach.<br>
<br>
Thanks!<br>
Oleg.<br>
<br>
<br>
<br>
______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.<wbr>linuxfoundation.org</a><br>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
</blockquote></div></div>