diff options
| author | Thomas Zander <thomas@thomaszander.se> | 2015-08-12 09:54:24 +0200 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-08-12 07:54:42 +0000 |
| commit | 3752d9fc95ff2e35cb23c7af1a6098f3fb000daf (patch) | |
| tree | 90aef8c67a306b27cbc9612ad3f641edee66ac1e /79 | |
| parent | ceb7059ee02396ba1f5e7f7b00400558f375a7c6 (diff) | |
| download | pi-bitcoindev-3752d9fc95ff2e35cb23c7af1a6098f3fb000daf.tar.gz pi-bitcoindev-3752d9fc95ff2e35cb23c7af1a6098f3fb000daf.zip | |
Re: [bitcoin-dev] Fees and the block-finding process
Diffstat (limited to '79')
| -rw-r--r-- | 79/7735e8637ded1c2ba74f5f302d226c5a03c2e3 | 98 |
1 files changed, 98 insertions, 0 deletions
diff --git a/79/7735e8637ded1c2ba74f5f302d226c5a03c2e3 b/79/7735e8637ded1c2ba74f5f302d226c5a03c2e3 new file mode 100644 index 000000000..6bb270e3b --- /dev/null +++ b/79/7735e8637ded1c2ba74f5f302d226c5a03c2e3 @@ -0,0 +1,98 @@ +Return-Path: <thomas@thomaszander.se> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 34AE926C + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 12 Aug 2015 07:54:42 +0000 (UTC) +X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 +Received: from pmx.vmail.no (pmx.vmail.no [193.75.16.11]) + by smtp1.linuxfoundation.org (Postfix) with ESMTP id 994A818D + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 12 Aug 2015 07:54:41 +0000 (UTC) +Received: from pmx.vmail.no (localhost [127.0.0.1]) + by localhost (pmx.isp.as2116.net) with SMTP id B40D6447BA + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 12 Aug 2015 09:54:39 +0200 (CEST) +Received: from smtp.bluecom.no (smtp.bluecom.no [193.75.75.28]) + by pmx.vmail.no (pmx.isp.as2116.net) with ESMTP id 4E7D4444CB + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 12 Aug 2015 09:54:39 +0200 (CEST) +Received: from pluto.localnet (unknown [81.191.183.21]) + (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) + (No client certificate requested) + by smtp.bluecom.no (Postfix) with ESMTPS id 3C66519F + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 12 Aug 2015 09:54:38 +0200 (CEST) +From: Thomas Zander <thomas@thomaszander.se> +To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org> +Date: Wed, 12 Aug 2015 09:54:24 +0200 +Message-ID: <1754831.BkYoPF5aHZ@pluto> +User-Agent: KMail/4.14.1 (Linux/3.16.0-4-amd64; KDE/4.14.2; x86_64; ; ) +In-Reply-To: <CABm2gDq+2mXEN2hZY6_JYXAJX=Wxrxr6jm86P6g2YD4zzy-=Nw@mail.gmail.com> +References: <CABsx9T16fH+56isq95m4+QWsKwP==tf75ep8ghnEcBoV4OtZJA@mail.gmail.com> + <CALgxB7sQM5ObxyxDiN_BOyJrgsgfQ6PAtJi52dJENfWCRKywWg@mail.gmail.com> + <CABm2gDq+2mXEN2hZY6_JYXAJX=Wxrxr6jm86P6g2YD4zzy-=Nw@mail.gmail.com> +MIME-Version: 1.0 +Content-Transfer-Encoding: quoted-printable +Content-Type: text/plain; charset="iso-8859-1" +X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW + autolearn=ham version=3.3.1 +X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on + smtp1.linux-foundation.org +Subject: Re: [bitcoin-dev] Fees and the block-finding process +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.12 +Precedence: list +List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Wed, 12 Aug 2015 07:54:42 -0000 + +On Tuesday 11. August 2015 21.27.46 Jorge Tim=F3n wrote: +> Can we agree that the first step in any potentially bad situation is +> hitting the limit and then fees rising as a consequence? + +Fees rising due to scarcity has nothing to do with the problem. Its a=20= + +consequence that is irrelevant to me. + +Bad situations are roughly divided into two parts; + * technical + * marketing. + +The technical part is that we already know of several technical=20 +solutions we=20 +will need when we have a forever growing backlog. Without them, nodes=20= + +will=20 +crash. +On top of that, we can expect a lot of new problems we don't know yet. + +IT experts are serious when they say that they avoid maxing out a=20 +system like=20 +the plague. + + +Marketing wise full blocks means we can only serve 3 transactions a=20 +second.=20 +Which is beyond trivial. All the banks, nasdaq, countries, businesses=20= + +etc etc=20 +now contemplating using Bitcoin itself will see this as a risk too big = +to=20 +ignore and the 1Mb Bitcoin will loose 99% of its perceived value. + +If you want fees to rise, then it should be viable to be used, withing = +6=20 +months, for something bigger than the economic size of Iceland.=20 +(=3Drandom=20 +smallest country I know). + +--=20 +Thomas Zander + |