From: Weiwu <a@colourful•land>
To: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Solving the Scalability Problem on Bitcoin
Date: Sun, 27 Aug 2017 10:27:49 +1000 (AEST) [thread overview]
Message-ID: <alpine.OSX.2.21.1708270923010.933@jamess-macbook-pro.local> (raw)
In-Reply-To: <CACQPdjphPmSC7bmicXGytuD3YAXYmsEGOECTTTuLfB_5iqDQGw@mail.gmail.com>
On Sat, 26 Aug 2017, Adam Tamir Shem-Tov via bitcoin-dev wrote:
> For example:
>
> A = 2.3 BTC, B=0, C=1.4. (Block 1)
>
> If A sends 2.3 BTC to B. (Block 2)
>
> And then B sends 1.5 to C. (Block 3)
>
> The pruning block will report:
>
> B = 0.8 and C=2.9.
You effecitvely want these two transactions:
A -(2.30)-> B; B -(1.5)-> C;
To be shorten to one transaction:
A -(0.8)-> B -(1.5)-> C;
For that to work a lot of changes has to be done to Bitcoin. For
simplicity of the discussion I'll assume all transactions are
standard transactions.
First, a block has to refer to the hash of the "balance sheet" (with
nonce), not the hash of the previous block. This way, a previous block
can be replaced with a smaller one without affecting the hash
reference. To add problem to this significant change, Bitcoin uses
UTXO table instead of "balance sheet". The difference is that UTXO is
indexed by transaction ID while a balance sheet is indexed by owner's
public keys. The shortening you suggested wouldn't affect the balance
sheet but would totally replace UTXOs for B and C, and probably even
A, if A has some changes left.
Second, Alice has to place a new signature on the shortened
transaction. The design challenge is how do we motivate A to do so,
since A needs to do it after "B->C", at which time Alice's business is
done and her wallet offline. Luckily, all bitcoins come from
miners. Imagine A gets her money from A', and all the way back, the
originating A" must be a miner. We just need to design a different
reward mechanism, where miners are not only rewarded by finding
blocks, but also by shortening transactions after his
expenses. Whatever new reward mechanism it may be, it will interfer
with block hash reference discussed in the previous paragraph.
Third, hash references are stablized by work. This is necessary,
otherwise a smaller block intended to replace a long one will not be
forced to maintain the same balance sheet. However, because work is
done on blocks, shortening can only happen within one block. Normally,
Bob who receives a transaction in a block, will not spend it to Carol
in the same block, because he wants 6 confirmations before being sure,
therefore, there will be little opportunity of shortening in one
block. You mentioned the idea of shortening between 1000 blocks - that
surely give a lot of opportunities to shorten a large directed
transaction graph, but you would abandon the proof of work in those
999 blocks in between.
There are three major design issue that needs to be worked out, but
almost all unique aspects of Bitcoin will be affected. Just to name a few:
- wallets need to be aware that the UTXO in it may change to some
other UTXO with the same sum value.
- nLockTime transactions are affected. Such transactions timed for
near future probably can stay by ruling that shortening can only
happen after a year; however, those timed for years to come will
find itself losing UTXO referenes (e.g. a will).
- I assumed all transactions standard, but if they are not, those who can
redeem them will lose the UTXO references to them after shortening.
I am, like you, risking proposing what is already proposed or
explaining what is already explained. The thinking around Bitcoin is a
big tome!
Regards
Weiwu Z.
next prev parent reply other threads:[~2017-08-27 0:28 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-26 19:21 Adam Tamir Shem-Tov
2017-08-26 21:31 ` Thomas Guyot-Sionnest
2017-08-26 22:32 ` Adam Tamir Shem-Tov
2017-08-27 5:18 ` Thomas Guyot-Sionnest
[not found] ` <CAN6UTayLR6rqSuHrsyF+7fFM4Fht7vbgXYRWzBRYXw8i43WzBw@mail.gmail.com>
2017-08-27 12:10 ` Leandro Coutinho
2017-08-27 3:52 ` Btc Ideas
2017-08-27 0:27 ` Weiwu [this message]
2017-08-27 13:19 Matthew Beton
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=alpine.OSX.2.21.1708270923010.933@jamess-macbook-pro.local \
--to=a@colourful$(echo .)land \
--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