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 EFBF849D for ; Sun, 27 Aug 2017 13:19:36 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-oi0-f66.google.com (mail-oi0-f66.google.com [209.85.218.66]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9A85BA6 for ; Sun, 27 Aug 2017 13:19:36 +0000 (UTC) Received: by mail-oi0-f66.google.com with SMTP id u206so1892239oif.0 for ; Sun, 27 Aug 2017 06:19:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=n9NdX7ET8lUoWinTWZR+xuI7Pluadww05r3WcKqlfKw=; b=AH3pEZPaSVtttgGp2UzYAmca7fissgfcWv778mS1XXvgZazdY58AwqRHpLGClJC8U1 6LYEFfbXoE0aYtlRSOfAwg7G86+BeJU13A3RmRnD/RZhUl50dAiC3vg3bxWh0mnzKqOL fx+kNzHm+LbkHI5RAedwe6xfvR8f0kbINmWWbPyho5xIupHY1FYuw9OESAETAyr4jY2T izfeLFOrgh2T4iqPxiKggk/xrERXLh3+s2UYbhBxgd0tUkptTGwlDxsFECjanLcHQgis y2ij8DGiflSODFfBGIlUfu1p5JOKSDe30FOOtZ1hAw5xnX9pE4qYrQJyqXE+vlRCUNZh juOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=n9NdX7ET8lUoWinTWZR+xuI7Pluadww05r3WcKqlfKw=; b=VgEFb5d4xCCDw1mYHW4PbUqMSvorFc68QOyHhvFjIjFsz0wCmPLj1PmptgekCPQoAT K9S6dGTDq09TOV2EWt2vfP2YU24dvV/ulcSUlv/GihUM4KeBsdxBvxf5qqiAE91uLuqi 2O5FWJKfeyX4Wt9DPicKIMFjmWiP48NjeG5QwAuTy3p0TVlN34XGdsEBDB2CzTbrB9EF W3olfFoMfGspnRzT1W41UXoRtG8KceWwXYH4YZnFCzu6PWLCCNGAk9ufLN15+LJGYFup XtZDhGMIQLEVIwYp7CPP4NfgWzdO+UnYBKC/2pstA9L3AzFCRKEyL+CiMnWhirizaWq1 514w== X-Gm-Message-State: AHYfb5jJWp90MYV6YcObVtNW/KdRd/d3j/7cBtwO0DAsJamqPorhKVP1 RV2pJEecYltkDwivu8MThKO69npSNg1C X-Received: by 10.202.252.149 with SMTP id a143mr134255oii.75.1503839975575; Sun, 27 Aug 2017 06:19:35 -0700 (PDT) MIME-Version: 1.0 From: Matthew Beton Date: Sun, 27 Aug 2017 13:19:25 +0000 Message-ID: To: bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary="001a113de43c8b2a120557bc074b" X-Spam-Status: No, score=0.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM 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 13:21:50 +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 13:19:37 -0000 --001a113de43c8b2a120557bc074b Content-Type: text/plain; charset="UTF-8" I think a slight problem with this is that wallets (often ones made by third party wallet software) do not fully empty. I don't know how often this happens, but some wallets, even if you tell them to send all funds, leave a small fraction of bitcoin remaining. If this is the case, it could be detrimental to the 'pruning idea', as wallets with any coins left cannot be pruned. For example: A has 1 BTC A -> B -> C If these wallets are not removing all the BTC, and a fraction is left over, B will not be able to be pruned out of the chain. On the other hand, of the wallets are completely emptied, the new 'pruned block' will be able to show A sending 1btc to C. This could be a problem, and so we need a way to persuade people to get their wallets to send everything instead of leaving a small fraction left over. I don't know how problematic this could be, or how frequently this happens, but I'm just putting it out there. --001a113de43c8b2a120557bc074b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think a slight problem with this is that wallets (often ones made by thir= d party wallet software) do not fully empty. I don't know how often thi= s happens, but some wallets, even if you tell them to send all funds, leave= a small fraction of bitcoin remaining. If this is the case, it could be de= trimental to the 'pruning idea', as wallets with any coins left can= not be pruned. For example:

A has 1 BTC
A -> B -> C
If these wallets are= not removing all the BTC, and a fraction is left over, B will not be able = to be pruned out of the chain. On the other hand, of the wallets are comple= tely emptied, the new 'pruned block' will be able to show A sending= 1btc to C.=C2=A0

This c= ould be a problem, and so we need a way to persuade people to get their wal= lets to send everything instead of leaving a small fraction left over. I do= n't know how problematic this could be, or how frequently this happens,= but I'm just putting it out there.
--001a113de43c8b2a120557bc074b--