From: Peter Todd <pete@petertodd•org>
To: Peter Vessenes <peter@coinlab•com>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Trusted identities
Date: Thu, 26 Apr 2012 13:30:00 -0400 [thread overview]
Message-ID: <20120426173000.GB16099@savin.lan> (raw)
In-Reply-To: <CAMGNxUs3eDaYHpg=ZqXQPC5+kQXZwhqUngH2t2OFaTa4x7vPcw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2031 bytes --]
On Thu, Apr 26, 2012 at 10:11:51AM -0700, Peter Vessenes wrote:
> These are interesting thoughts, karma for bitcoins essentially.
>
> I would like CoinLab to publish a 'cost of subverting 1-n transactions with
> 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.
>
> 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.
>
> I'm not sure of the current implementation of replacement transactions, can
> 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.
--
http://petertodd.org 'peter'[:-1]@petertodd.org
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
next prev parent reply other threads:[~2012-04-26 17:52 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-26 15:49 Peter Todd
2012-04-26 17:11 ` Peter Vessenes
2012-04-26 17:30 ` Peter Todd [this message]
2012-04-26 18:00 ` Alan Reiner
2012-04-26 17:59 ` Amir Taaki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120426173000.GB16099@savin.lan \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=peter@coinlab$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox