Message-ID: <560AEC81.8040903@riseup.net>
Date: Tue, 29 Sep 2015 19:54:41 +0000
From: odinn <odinn.cyberguerrilla@riseup.net>
MIME-Version: 1.0
To: jl2012@xbt.hk, "Jonathan Toomim (Toomim Bros)" <j@toom.im>
References: <20150927185031.GA20599@savin.petertodd.org>	<CA+w+GKRCVr-9TVk66utp7xLRgTxNpxYoj3XQE-6y_N8JS6eO6Q@mail.gmail.com>	<20150928132127.GA4829@savin.petertodd.org>	<CA+w+GKTCZDNVJ-XEmsCAWGXUV3xOzVYmqMQYm0x+ihyYWQN0Gg@mail.gmail.com>	<20150928142953.GC21815@savin.petertodd.org>	<CA+w+GKTUz2eVJOpixSebWiQ59ovoELNhsZWSsbLHXWqk2eCn0A@mail.gmail.com>	<20150928144318.GA28939@savin.petertodd.org>	<40B097BA-A389-4C46-B5DE-2EC4738086BA@toom.im>
	<5e90be1b8f85cd46ed20eae84c062702@xbt.hk>
In-Reply-To: <5e90be1b8f85cd46ed20eae84c062702@xbt.hk>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!
Precedence: list

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hello, (see my remarks below)

jl2012 via bitcoin-dev:
> Jonathan Toomim (Toomim Bros) via bitcoin-dev 於 2015-09-29 09:30 寫
> 到:
>> SPV clients will appear to behave normally, and will continue to
>> show new transactions and get confirmations in a timely fashion.
>> However, they will be systematically susceptible to attack from
>> double-spends that attempt to spend funds in a way that the
>> upgraded nodes will reject. These transactions will appear to
>> get 1 confirmation, then regress to zero conf, every single time.
>> These attacks can be performed for as long as someone mines with
>> the old version.
> 
> 1. Who told you to accept 1-confirmation tx? Satoshi recommended 6 
> confirmations in the whitepaper. Take your own risk if you do not
> follow his advice.
> 
> 2. This is true only if your SPV client naively follows the
> longest chain without even looking at the block version. This might
> be good enough for the 1st generation SPV client, but future
> generations should at least have basic fraud detecting mechanism.
> 
> 

Regarding "basic fraud detecting mechanism" of which you speak, being
as I personally enjoy SPV for the time being (Electrum), and I know
that people will continue to keep using SPV wallets because they are
light and handy, I think that you make a good point that "basic fraud
detecting mechanism" is needed, but how to verify that such a
mechanism in an SPV wallet is good, and/or that the software and
version information provided by the server admins via the banner is
valid (being as it's not validated)?  I have made a thread on this
conundrum.  Which is posted here if you are interested.

https://bitcointalk.org/index.php?topic=1157545.0

So as to avoid repeating stuff please read whole thead before
answering in it or posting back to list.  It seems that there are
definitely unanswered questions...

I may open this up as an issue on https://github.com/spesmilo/electrum
about this stuff, but I wanted to post comment here also, for the record
.


> 
>> If an attacker thinks he could get more than 25 BTC of 
>> double-spends per block, he might even choose to mine with the 
>> obsolete version in order to get predictable orphans and to trick
>> SPV clients and fully verifying wallets on the old version.
> 
> This point is totally irrelevant. No matter there is a softfork or
> not, SPV users are always vulnerable to such double-spending attack
> if they blindly follow the longest chain AND accept 1-confirmation.
> The fiat currency system might be safer for them. 
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev@lists.linuxfoundation.org 
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

- -- 
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-----BEGIN PGP SIGNATURE-----

iQEcBAEBCgAGBQJWCuyBAAoJEGxwq/inSG8CtpAH/R6N1QYzMFWPo75RsP46VYbi
k33QbsbhlEznEEWX/ayKEzmnbt7DkXFXQtesuabongFr9UpwxED0OGQJztyRz5NC
iS8ty+Kfi9/Aq/e79A6IPSYfRCPB1w+oP/cEsV/LB4BPkut2mdpMbdwDZ3TQuLRq
LnFLmz8tY+CUqSbyrPUx/FKJ7ZbQsAlammMTKoUYaAYRytDBPzW4PdYtTyrK2QTK
jjt11n5U8ShmXdsCo/E0pWVbggQlhFgrCoIYjGNfmDyK/eYaskD5O6czIdqd5WPs
P+2zMC1Cukkr5l8BQXiSedVXGpMyaYhMgWB7MD6sNDIAE9IFbfEpkse/Ek4aJII=
=Ud4C
-----END PGP SIGNATURE-----