From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1SNSrr-0007oC-4p for bitcoin-development@lists.sourceforge.net; Thu, 26 Apr 2012 17:52:35 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.149.84 as permitted sender) client-ip=62.13.149.84; envelope-from=pete@petertodd.org; helo=outmail149084.authsmtp.net; Received: from outmail149084.authsmtp.net ([62.13.149.84]) by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1SNSrm-00055G-SS for bitcoin-development@lists.sourceforge.net; Thu, 26 Apr 2012 17:52:35 +0000 Received: from mail-c194.authsmtp.com (mail-c194.authsmtp.com [62.13.128.121]) by punt8.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id q3QHU6e7042269; Thu, 26 Apr 2012 18:30:06 +0100 (BST) Received: from savin.lan (206-248-185-238.dsl.teksavvy.com [206.248.185.238]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2) with ESMTP id q3QHU14g076905 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 26 Apr 2012 18:30:03 +0100 (BST) Date: Thu, 26 Apr 2012 13:30:00 -0400 From: Peter Todd To: Peter Vessenes Message-ID: <20120426173000.GB16099@savin.lan> References: <20120426154928.GA13737@savin.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1UWUbFP1cBYEclgG" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-Server-Quench: 75b68d3c-8fc5-11e1-80b9-0022640b883e X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdAQUGUUGAgsB AmQbWlxeU117WWc7 aQpXcwdZalRPVwB0 UktBXVdaExppT10C Z2Z7Ux0ldwJAcX51 K0diXXhbEkN/J0B1 Fk0HCGVQNmJ9aWFK UV1Qd1FdbQNKfB1D blAtXHsONCtlM3Bw LCUyIzs2PDMaJClL TwUKNVcfR1o+VgIm WgseEDlnHEEIQTky Mx0rMTYA X-Authentic-SMTP: 61633532353630.1015:706 X-AuthFastPath: 0 (Was 255) X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Score: -1.5 (-) 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 SPF_PASS SPF: sender matches SPF record X-Headers-End: 1SNSrm-00055G-SS Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] Trusted identities 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: Thu, 26 Apr 2012 17:52:35 -0000 --1UWUbFP1cBYEclgG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 26, 2012 at 10:11:51AM -0700, Peter Vessenes wrote: > These are interesting thoughts, karma for bitcoins essentially. >=20 > I would like CoinLab to publish a 'cost of subverting 1-n transactions wi= th > 90% probability' metric soon, and I think it would help everyone to > understand what that number is. There's gotta be a lot of subtlies there. For instance, if I just want to double-spend, the easiest approach would be to first buy a whole bunch of VPS's, each with different /16's for their IP address to defeat that anti-sybil measure. Then figure out what is the set of nodes closest to my target - easier for an active target that makes a lot of transactions. Then it's just a matter of giving them my transaction, and immediately flooding the network faster with my nodes than their single node. It's not block-replacement, but it would be effective against people who accept 0-confirmations. (although as Gavin has pointed out elsewhere, in the future miners may be very happy to replace transactions for more fees in that kind of circumstance) Of course, this whole trusted identities business could be equally used for the bitcoin flood network as a whole to prevent sybil's, and perhaps even get guarantees of behavior like "My node respects nLockTime and won't ignore it for a higher-fee transaction replacement" > When we started out, you probably needed to wait 5 blocks for $10 or $20 = of > bitcoin value transfer. >=20 > Now, I'd happily accept a $1k transaction with 1 confirmation. Yup, especially when a human is in the loop. > More difficulty shortens the safe time we can transact large volumes in, > which is good for the network. >=20 > I'm not sure of the current implementation of replacement transactions, c= an > anyone on the core team speak to this? Can I replace transactions, or is > that part of the spec unimplemented or deprecated right now? My understanding is it's completely disabled. --=20 http://petertodd.org 'peter'[:-1]@petertodd.org --1UWUbFP1cBYEclgG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJPmYYTAAoJEH+rEUJn5PoEAsYH/RnMabHBU/GN0+hJnbKLwQsZ niWjB/G9e2VXTxHNhIMkuXiohp+FolZY/ez53jDDIFFBUcAUVc48QqhmtFbPCr1m IMIk9Yn+MWdQoU8SgTCM++eNRi0PLPQKSf3lr2ZHnXK09xEUGvC7tW1WJA8DLZtz AvhfDmnu9210iEDm97MIIYkJHqdIbuI0qZSOzm0FW9Nu3MKtKTysYwgxP4bZ/0HW tTSPABFc0Aa8d5gEOgfPzOddbg3rjLBW8VJ/acSqed/3Col04bxxPY1LTqpGkJ38 S+tczkoHE0AZdTIW1Bvh1NvYFHF48YGJho6d5zRXsUOuhrK/+OHc1EKQcAqFM54= =QN9x -----END PGP SIGNATURE----- --1UWUbFP1cBYEclgG--