Return-Path: <thomas.kerin@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id E2DAE65
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 25 Jul 2015 15:04:51 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com
[209.85.212.173])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C65E0E9
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 25 Jul 2015 15:04:49 +0000 (UTC)
Received: by wibxm9 with SMTP id xm9so65783163wib.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 25 Jul 2015 08:04:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=message-id:date:from:user-agent:mime-version:to:subject:references
:in-reply-to:content-type;
bh=NtYBYEwBu33CVlbFzh2dQNGNzdv8DZ3IL6WNz0rsUvM=;
b=Bb74F3uvQqpx91c2/VM96tiyNkVHaPmlB8R4PVAIYqfOuxU5jWor2XreQPsHIsuUIA
b22458PxX/vxdz2YFkcsgaAwtvY6qo7W7yv3mWe7Trzk+t1QLPY8pGQntO8dlwBS+iIB
4yHYkeyG4/M9XZZuI/QBAq+XmudlIeLVcziBLguFhVb/KzJ8YItb5rUh6GqRYIxGuM6A
2BKEEnDjQeel8HC7dFpwQ4R+upx2bnsKBURB2tfGZFenU6jJLr83RjId/fNr08FZuajK
fMRwS3AFrSx6rG8K5kbvt7BMnD5x8Ej1wsc8b5MlPgOAMQzdXD00o8oJjAS65ThUyMNm
iAyw==
X-Received: by 10.180.83.137 with SMTP id q9mr7614573wiy.68.1437836688286;
Sat, 25 Jul 2015 08:04:48 -0700 (PDT)
Received: from [192.168.1.33] (azura.nullbyte.me. [94.242.198.164])
by smtp.googlemail.com with ESMTPSA id
m10sm3675153wib.17.2015.07.25.08.04.43
(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Sat, 25 Jul 2015 08:04:47 -0700 (PDT)
Message-ID: <55B3A589.1010107@gmail.com>
Date: Sat, 25 Jul 2015 16:04:41 +0100
From: Thomas Kerin <thomas.kerin@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:31.0) Gecko/20100101 Thunderbird/31.8.0
MIME-Version: 1.0
To: bitcoin-dev@lists.linuxfoundation.org, kiwigb@yahoo.com
References: <l.com@mac.com>
<D472C05D-7164-4ED1-B571-94415AD8E60F@gmail.com> <346D4CE0-E00D-4ABB-B131-EFA1416CB20C@me.com> <29363BE6-72A7-4D06-A974-C52BA12FD8BD@gmail.com> <55FFBC8F-A3C9-4109-89C7-AC359FBBD478@me.com> <4734381C-2000-4D9B-9099-DDE3D38D64A3@me.com> <DEF9C610-2FBC-40C1-9AFA-9E91903C7F96@petertodd.org> <DFA3CCE4-52F7-4D63-8982-2EB133AB6EAA@me.com> <B8F9DE4B-A8AA-490D-991B-11C28B2AA527@gmail.com> <D7EE14EC-B36D-43F2-8CEC-B63443FBBCA8@me.com> <0E15E07E-E21C-4541-869A-3C34CBA35774@gmail.com> <9AC88C7C-4BA4-4DF2-913F-9DC6874BD19D@me.com> <83982C1D-4FE6-4A5C-BC93-BFBD9756F3D2@gmail.com> <COL131-DS24D730A430CE77D648AE9CCD810@phx.gbl> <55B1FBCE.1080002@jonasschnelli.ch> <CABm2gDqK0qd_JNHCUrnz4L1axG99i9=M7DjCQWatE3Lf0HOiyA@mail.gmail.com> <CACrzPenbkh86bW9GQe1M4Zt1OxDTQNeMU6osatRDEvcwOyxHAg@mail.gmail.com>
<1437790691.2111.3.camel@yahoo.com>
In-Reply-To: <1437790691.2111.3.camel@yahoo.com>
Content-Type: multipart/alternative;
boundary="------------080208040309000203020002"
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,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] Bitcoin, Perceptions, and Expectations
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: Sat, 25 Jul 2015 15:04:52 -0000
This is a multi-part message in MIME format.
--------------080208040309000203020002
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
FWIW, the 6 confirmations figure came from a modest estimate of a miner
with 10% of the hash rate, such that there is < 0.1% probability of the
transaction being undone.
I wonder at times if this figure should fluctuate with the hashrate of
the largest player. Presently, AntMiner has 20% of the hashrate,
requiring 11 blocks to give you the same certainty. And previously when
GHash.io had 45%, the number of blocks to wait would be 340 - over two days!
With this in mind, I would be wary about publishing these numbers as
they are prone to change.
On 25/07/15 03:18, gb via bitcoin-dev wrote:
>
> Validated - (seen on network)
>
> Settled/Cleared - 1 conf
>
> Finalised - 6 confs
>
> On Sat, 2015-07-25 at 00:37 +1000, Vincent Truong via bitcoin-dev wrote:
>>
>> "Fast transactions"
>> Fast transactions implies it is slower than Visa, and Visa is
>> 'instant' by comparison from the spender's POV. Bitcoin is still very
>> instant because wallets still send notifications/pings when
>> transactions are first seen, not when it goes into a block. We
>> shouldn't mislead people into thinking a transaction literally takes
>> 10 minutes to travel the globe.
>>
>> Maybe this feels like PR speak. But being too humble about Bitcoin's
>> attributes isn't a good idea either.
>>
>> If we're going to look at perception, image and expectations, perhaps
>> we can start to look at redefining some terminology too. Like
>> confirmations, which is an arbitrary concept. Where possible we should
>> describe it with finance terminology.
>>
>> "0 conf transaction"
>> 0 conf is the 'transaction' - just the act of making an exchange. It
>> doesn't imply safe and I believe using the word 'settle' in place of
>> confirmations will automatically click with merchants.
>>
>> "1st conf"
>> A 'confirmation' is a 'settlement'. If it is 'settled', it implies
>> final (except by court order), whereas confirmation usually means 'ah,
>> I've seen it come through'. I rarely hear any sales clerk call credit
>> card transactions confirmed. More often you will hear 'approved'
>> instead. Although 1st conf can be overtaken, so...
>>
>> "n confirmations"
>> This term can probably stay since I can't come up with a better word.
>> Settlements only happen once, putting a number next to it breaks the
>> meaning of the word. "Settled with 4 confirmations" seems pretty
>> clear. Alternatively I think instead of displaying a meaningless
>> number we ought to go by a percentage (the double spend improbability)
>> and go by 'confidence'. "Settled with 92% confidence." Or we can pick
>> an arbitrary number like 6 and use 'settling...' and 'settled' when
>> reached.
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
- --
My PGP key can be found here <https://thomaskerin.io/me.pub.asc>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCgAGBQJVs6WBAAoJEAiDZR291eTlmA4P/1uARaRISbq6ZN9gSy+Tsq+N
aooU/irB06IdTnOrxqW/iAS2M2SxqTq5/M6PVMK6LAefRuAAYE6KeDQb5/n2QWIM
vBgVeDPBVkq+KHOJlaswO962kl/Mr9TC9xb9hbfB9IdQACLbSwfyQ+cYNY3RRnvl
Jkgj7boVjA4o/lE/BxTshPTriQNtVl9c6OxOfXsZotpTphSlMGIUrEHR/t2rjbcV
yPeTwHFIAaqcCMivYvfsk24JD9DiygwGVvjqwQPsNF8H9y6xor+QAc23aaD8WPi1
1J91bfRxJWghxyGmsPx1G/EVi/0retE1tZdkyqlahThdSACZtUfA997V0KT/DrdH
svHjNclViHExWGL7cUd2s9AMjIz1vr0tUGxvU7KsZT2kEXP0qp96mjIfo0TkZbUb
xsYMKujE8ZRpn8+CakfeT7RMtAhGIRvtPDQDm+Qv84A6JOufrgF4C0B00/9kERIe
g5hH2YG2R4YD40G4wtxEGpk/2jcdWc37CJ+T17+7m8MgPFNmX8V5YsAFwfPe6iAt
1QON3crilFRYCawYcOypbjh4hb5O5Usvg0msUrvzaRJ7Gj6K/SmFdG4hOepCHbPc
g2Bu15ifdmaCa8ssZHK+HJmhbGTMkDqdBnv2lziR8TXIC/se2+y7Iasz4eVkfG1/
RkDgokFOv7YA5aqp5ZHn
=VgWS
-----END PGP SIGNATURE-----
--------------080208040309000203020002
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA512<br>
<br>
FWIW, the 6 confirmations figure came from a modest estimate of a
miner with 10% of the hash rate, such that there is < 0.1%
probability of the transaction being undone.<br>
<br>
I wonder at times if this figure should fluctuate with the hashrate
of the largest player. Presently, AntMiner has 20% of the hashrate,
requiring 11 blocks to give you the same certainty. And previously
when GHash.io had 45%, the number of blocks to wait would be 340 -
over two days!<br>
<br>
With this in mind, I would be wary about publishing these numbers as
they are prone to change.<br>
<br>
On 25/07/15 03:18, gb via bitcoin-dev wrote:<br>
<span style="white-space: pre;">><br>
> Validated - (seen on network) <br>
><br>
> Settled/Cleared - 1 conf<br>
><br>
> Finalised - 6 confs<br>
><br>
> On Sat, 2015-07-25 at 00:37 +1000, Vincent Truong via
bitcoin-dev wrote:<br>
>><br>
>> "Fast transactions"<br>
>> Fast transactions implies it is slower than Visa, and
Visa is<br>
>> 'instant' by comparison from the spender's POV. Bitcoin
is still very<br>
>> instant because wallets still send notifications/pings
when<br>
>> transactions are first seen, not when it goes into a
block. We<br>
>> shouldn't mislead people into thinking a transaction
literally takes<br>
>> 10 minutes to travel the globe.<br>
>><br>
>> Maybe this feels like PR speak. But being too humble
about Bitcoin's<br>
>> attributes isn't a good idea either.<br>
>><br>
>> If we're going to look at perception, image and
expectations, perhaps<br>
>> we can start to look at redefining some terminology too.
Like<br>
>> confirmations, which is an arbitrary concept. Where
possible we should<br>
>> describe it with finance terminology.<br>
>><br>
>> "0 conf transaction"<br>
>> 0 conf is the 'transaction' - just the act of making an
exchange. It<br>
>> doesn't imply safe and I believe using the word 'settle'
in place of<br>
>> confirmations will automatically click with merchants.<br>
>><br>
>> "1st conf"<br>
>> A 'confirmation' is a 'settlement'. If it is 'settled',
it implies<br>
>> final (except by court order), whereas confirmation
usually means 'ah,<br>
>> I've seen it come through'. I rarely hear any sales clerk
call credit<br>
>> card transactions confirmed. More often you will hear
'approved'<br>
>> instead. Although 1st conf can be overtaken, so...<br>
>><br>
>> "n confirmations"<br>
>> This term can probably stay since I can't come up with a
better word.<br>
>> Settlements only happen once, putting a number next to it
breaks the<br>
>> meaning of the word. "Settled with 4 confirmations" seems
pretty<br>
>> clear. Alternatively I think instead of displaying a
meaningless<br>
>> number we ought to go by a percentage (the double spend
improbability)<br>
>> and go by 'confidence'. "Settled with 92% confidence." Or
we can pick<br>
>> an arbitrary number like 6 and use 'settling...' and
'settled' when<br>
>> reached.<br>
>><br>
>> _______________________________________________<br>
>> bitcoin-dev mailing list<br>
>> <a class="moz-txt-link-abbreviated" href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a><br>
>>
<a class="moz-txt-link-freetext" href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
><br>
><br>
> _______________________________________________<br>
> bitcoin-dev mailing list<br>
> <a class="moz-txt-link-abbreviated" href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a><br>
>
<a class="moz-txt-link-freetext" href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a></span><br>
<br>
- -- <br>
My PGP key can be found here
<a class="moz-txt-link-rfc2396E" href="https://thomaskerin.io/me.pub.asc"><https://thomaskerin.io/me.pub.asc></a><br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v2<br>
<br>
iQIcBAEBCgAGBQJVs6WBAAoJEAiDZR291eTlmA4P/1uARaRISbq6ZN9gSy+Tsq+N<br>
aooU/irB06IdTnOrxqW/iAS2M2SxqTq5/M6PVMK6LAefRuAAYE6KeDQb5/n2QWIM<br>
vBgVeDPBVkq+KHOJlaswO962kl/Mr9TC9xb9hbfB9IdQACLbSwfyQ+cYNY3RRnvl<br>
Jkgj7boVjA4o/lE/BxTshPTriQNtVl9c6OxOfXsZotpTphSlMGIUrEHR/t2rjbcV<br>
yPeTwHFIAaqcCMivYvfsk24JD9DiygwGVvjqwQPsNF8H9y6xor+QAc23aaD8WPi1<br>
1J91bfRxJWghxyGmsPx1G/EVi/0retE1tZdkyqlahThdSACZtUfA997V0KT/DrdH<br>
svHjNclViHExWGL7cUd2s9AMjIz1vr0tUGxvU7KsZT2kEXP0qp96mjIfo0TkZbUb<br>
xsYMKujE8ZRpn8+CakfeT7RMtAhGIRvtPDQDm+Qv84A6JOufrgF4C0B00/9kERIe<br>
g5hH2YG2R4YD40G4wtxEGpk/2jcdWc37CJ+T17+7m8MgPFNmX8V5YsAFwfPe6iAt<br>
1QON3crilFRYCawYcOypbjh4hb5O5Usvg0msUrvzaRJ7Gj6K/SmFdG4hOepCHbPc<br>
g2Bu15ifdmaCa8ssZHK+HJmhbGTMkDqdBnv2lziR8TXIC/se2+y7Iasz4eVkfG1/<br>
RkDgokFOv7YA5aqp5ZHn<br>
=VgWS<br>
-----END PGP SIGNATURE-----<br>
<br>
</body>
</html>
--------------080208040309000203020002--