Peter Todd [ARCHIVE] on Nostr: š Original date posted:2012-04-26 š Original message:On Thu, Apr 26, 2012 at ...
š
Original date posted:2012-04-26
š Original message: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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120426/6028de45/attachment.sig>;
š Original message: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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120426/6028de45/attachment.sig>;