Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YYMqJ-0005Lm-O9 for bitcoin-development@lists.sourceforge.net; Wed, 18 Mar 2015 22:53:39 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 74.125.82.43 as permitted sender) client-ip=74.125.82.43; envelope-from=natanael.l@gmail.com; helo=mail-wg0-f43.google.com; Received: from mail-wg0-f43.google.com ([74.125.82.43]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YYMqI-0005mk-RY for bitcoin-development@lists.sourceforge.net; Wed, 18 Mar 2015 22:53:39 +0000 Received: by wgbcc7 with SMTP id cc7so47546402wgb.0 for ; Wed, 18 Mar 2015 15:53:32 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.181.27.201 with SMTP id ji9mr10961603wid.20.1426719212819; Wed, 18 Mar 2015 15:53:32 -0700 (PDT) Received: by 10.28.218.8 with HTTP; Wed, 18 Mar 2015 15:53:32 -0700 (PDT) Received: by 10.28.218.8 with HTTP; Wed, 18 Mar 2015 15:53:32 -0700 (PDT) In-Reply-To: References: Date: Wed, 18 Mar 2015 23:53:32 +0100 Message-ID: From: Natanael To: Dennis Sullivan Content-Type: multipart/alternative; boundary=001a11c3476adfdac6051197f3a6 X-Spam-Score: 0.4 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (natanael.l[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 1.0 FREEMAIL_REPLY From and body contain different freemails X-Headers-End: 1YYMqI-0005mk-RY Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] Are Instant Confirmations safe? X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 22:53:39 -0000 --001a11c3476adfdac6051197f3a6 Content-Type: text/plain; charset=UTF-8 Den 18 mar 2015 23:38 skrev "Dennis Sullivan" : > > Hello. This is my first time posting to this list. I wanted to ask your opinions on something relating to confirmation times. > > I recently read about a "transaction locking" proposal which claims to make it possible to accept 0-conf transactions with guarantee they will get mined. This seems rather dubious to me, because if there was merit to the system, I would have already expected to see discussion on this list regarding it. Sounds like it would be weak to sybil attacks (deterministically choosing my own nodes sounds great!), and of course Finney attacks (single-block reversal) and defecting miners (what are you gonna do, punish miners with limited network connectivity as well? You'll risk forking the network). Zero-conf is only safe if nobody's actively trying to attack you. It has no inherent security in and of itself. For low values the risk is usually tolerated. For large values there's too much risk of making yourself a target. --001a11c3476adfdac6051197f3a6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Den 18 mar 2015 23:38 skrev "Dennis Sullivan" <dennis.jm.sullivan@gmail.com>:
>
> Hello. This is my first time posting to this list. I wanted to ask you= r opinions on something relating to confirmation times.
>
> I recently read about a "transaction locking" proposal which= claims to make it possible to accept 0-conf transactions with guarantee th= ey will get mined. This seems rather dubious to me, because if there was me= rit to the system, I would have already expected to see discussion on this = list regarding it.

Sounds like it would be weak to sybil attacks (deterministic= ally choosing my own nodes sounds great!), and of course Finney attacks (si= ngle-block reversal) and defecting miners (what are you gonna do, punish mi= ners with limited network connectivity as well? You'll risk forking the= network).

Zero-conf is only safe if nobody's actively trying to at= tack you. It has no inherent security in and of itself. For low values the = risk is usually tolerated. For large values there's too much risk of ma= king yourself a target.

--001a11c3476adfdac6051197f3a6--