From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 4AFE8486 for ; Sun, 27 Aug 2017 00:28:25 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pg0-f50.google.com (mail-pg0-f50.google.com [74.125.83.50]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DBDEAEB for ; Sun, 27 Aug 2017 00:28:24 +0000 (UTC) Received: by mail-pg0-f50.google.com with SMTP id 63so13087113pgc.2 for ; Sat, 26 Aug 2017 17:28:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=realss-com.20150623.gappssmtp.com; s=20150623; h=sender:from:date:to:subject:in-reply-to:message-id:references :user-agent:mime-version; bh=DRuV97IqeVeDTCNGqsLiTsZsmZndInbNKNVOsa4gIDw=; b=wc/++AjfDIpRa6wb2OCAB2fRCiQg3n/5q4rrrRuaVQN59JLBZk/Ho00HCrkLDDYHlg TuZvVK+2cwYWkh0INKWMsNUwX7fXlJ5mGm5J5BGsQsshHR+bmekgl9B/BWJNWIYATZic 2L7Gbqf5uFk7yWDcT+G+AruZrCw2+unuNC9AP82BzUJcU6Ccv4AcH4EaOWN60U0zPAkI IjqRwSwxyuxlOVryVXcokR2GeaA+JomsHJ58tCgXMaWP0OhbQGePDjYiJIRlVddrZgrt ZNJP0iNhKoLbpQOehzppO4u4voMgnmokt/7zQYSWOqFinwRuENAsm8V2W1RAzml7C0f1 GMqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:date:to:subject:in-reply-to :message-id:references:user-agent:mime-version; bh=DRuV97IqeVeDTCNGqsLiTsZsmZndInbNKNVOsa4gIDw=; b=cfNcBuGvZf6iOvbXOO8zuI9H5vHkCV5yaRZp4+tnBOUoRxGLpVup89SrBRoD7pjxvK fDRWK1z0AjxUMNY8qjweXHSDzwItc/w84r/RrpaeF2dTcNoTRxgThKjDV/IefMrhJrn9 H10G/dNXRi7SfbeisOVrWOOHGctasCcBpoAgjWKLn7RlsWHi10Y3YGk07ANh+MoN1mNI jLKIS8nac1Iri4kJ+xy+EIuhnrT51ckGj+QZy4aiYe3LpC6tytAJb79yjGDxTBxPIOjF NaRCse4Fc+pOK6FWc2cXVCVCdJfe86+zWKQf8rVbS+SbCFc21up7xsmirAv1mm1F7xtl RdUA== X-Gm-Message-State: AHYfb5hSRjn+b7a8KYo/HnmCj6cx9Uhn9QeeF4RWkPlX8XE7wz6euQCD ZEhPH19SngwPeU8G71g= X-Received: by 10.84.241.142 with SMTP id b14mr3502979pll.270.1503793704028; Sat, 26 Aug 2017 17:28:24 -0700 (PDT) Received: from [192.168.0.17] (14-200-49-1.static.tpgi.com.au. [14.200.49.1]) by smtp.gmail.com with ESMTPSA id p2sm15874818pgr.4.2017.08.26.17.28.21 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 26 Aug 2017 17:28:23 -0700 (PDT) Sender: Weiwu Zhang From: Weiwu X-Google-Original-From: Weiwu Date: Sun, 27 Aug 2017 10:27:49 +1000 (AEST) To: bitcoin-dev@lists.linuxfoundation.org In-Reply-To: Message-ID: References: User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Spam-Status: No, score=0.0 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, RCVD_IN_DNSWL_NONE autolearn=disabled version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Sun, 27 Aug 2017 00:38:23 +0000 Subject: Re: [bitcoin-dev] Solving the Scalability Problem on Bitcoin X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Aug 2017 00:28:25 -0000 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.