Mike Hearn [ARCHIVE] on Nostr: 📅 Original date posted:2014-06-16 📝 Original message:> > I read the comments on ...
📅 Original date posted:2014-06-16
📝 Original message:>
> I read the comments on the PR. I mean no disrespect but this patch can't
> prevent double spends minutes apart and a solution is as good as it's
> weakest link.
>
Actually Tom is running a page where he shows double spends detected by his
node or relayed by mine (there are only two nodes in this little detection
network currently), and it does show double spends that occur seconds,
minutes or even days apart.
Regardless, whether that approach helps or not is off topic for this
thread. Let's all hope it does and discuss the details in some other
thread, or on the pull request.
> instant confirmation between exchanges can create huge arbitrage
> opportunities and as such
> liquidity.
>
Yes indeed, if you want to do high frequency trading then every millisecond
counts and you probably don't want to rely on watching transactions
propagate across the block chain. For inter-exchange traffic this BIP would
probably be useful. I've been talking about the consumer case.
> What do you expect for e-commerce and escrow to happen? Don't you think the
> market will naturally converge to a handful of hubs that will helps with
> refunds and things like that?
No, I expect there to be many kinds of trades where dispute mediation is
unnecessary, e.g. when I buy a drink at Starbucks or a burger at McDonalds
the chances of me wanting to charge it back is basically zero. Same for
sending between people who know each other, large corporate transactions
where the threat of a lawsuit is more useful than mediation, etc.
But for transactions where third parties are needed for dispute mediation,
yes, I'd expect there to be a handful of well known trusted names for the
majority of such transactions, and then a long tail of specialists who only
mediate e.g. purchases of rare Aztec artifacts or other things where a
generic company might be easily fooled.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140616/1fb740b4/attachment.html>;
📝 Original message:>
> I read the comments on the PR. I mean no disrespect but this patch can't
> prevent double spends minutes apart and a solution is as good as it's
> weakest link.
>
Actually Tom is running a page where he shows double spends detected by his
node or relayed by mine (there are only two nodes in this little detection
network currently), and it does show double spends that occur seconds,
minutes or even days apart.
Regardless, whether that approach helps or not is off topic for this
thread. Let's all hope it does and discuss the details in some other
thread, or on the pull request.
> instant confirmation between exchanges can create huge arbitrage
> opportunities and as such
> liquidity.
>
Yes indeed, if you want to do high frequency trading then every millisecond
counts and you probably don't want to rely on watching transactions
propagate across the block chain. For inter-exchange traffic this BIP would
probably be useful. I've been talking about the consumer case.
> What do you expect for e-commerce and escrow to happen? Don't you think the
> market will naturally converge to a handful of hubs that will helps with
> refunds and things like that?
No, I expect there to be many kinds of trades where dispute mediation is
unnecessary, e.g. when I buy a drink at Starbucks or a burger at McDonalds
the chances of me wanting to charge it back is basically zero. Same for
sending between people who know each other, large corporate transactions
where the threat of a lawsuit is more useful than mediation, etc.
But for transactions where third parties are needed for dispute mediation,
yes, I'd expect there to be a handful of well known trusted names for the
majority of such transactions, and then a long tail of specialists who only
mediate e.g. purchases of rare Aztec artifacts or other things where a
generic company might be easily fooled.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140616/1fb740b4/attachment.html>;