From: Dan Carter <carterd@gmail•com>
To: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Decentralized digital asset exchange with honest pricing and market depth
Date: Wed, 12 Feb 2014 08:34:48 -0800 [thread overview]
Message-ID: <ldg7qs$6rn$1@ger.gmane.org> (raw)
In-Reply-To: <20140209180458.GB20126@savin>
I'm not sure how well this would work.
Sure it would provide honest historical pricing, but those who wait for
publication confirmation may be at a disadvantage -- to get the best
deal possible Bob would connect to as many nodes as he could, examine
the stream of unconfirmed asks coming in and sign the best ones before
someone else does. The network would gravitate towards an O(n^2) fully
connected network, because being fully connected means one is fully
aware of all unconfirmed asks at any moment so one can make the best
judgement and buy before someone else does.
The seller needs a guarantee that all bidders can act on the ask
transaction simultaneously. Maybe the partial ask transaction could be
time-locked with a network propagation delay, there would be multiple
bidder responses and the winner is chosen by lottery (and fee priority)
by the bitcoin/alt-coin miner who confirms the atomic transaction in
their block. That would eliminate the advantage to being fully
connected as it would no longer matter that one can act first, so you
have a more sane network.
On 2014-02-09 10:04 AM, Peter Todd wrote:
> Proof-of-publication(2) offers a solution. Alice can embed her
> incomplete transaction as data in a second, valid, transaction. She
> broadcasts this secondary transaction to some agreed upon blockchain,
> either the one the colored coin is in, or potentially a secondary system
> with suitable proof-of-publication security. Bidders such as Bob can now
> scan the blockchain for offers with an acceptable price. (the offers can
> make use of techniques like prefix filters to allow Bob to only scan
> part of the blockchain, although Bob needs to know the status of all
> assets of the type he is interested in anyway)
next prev parent reply other threads:[~2014-02-12 16:40 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-09 18:04 Peter Todd
2014-02-09 20:44 ` Peter Todd
2014-02-10 19:32 ` Peter Todd
2014-02-11 17:59 ` Troy Benjegerdes
2014-02-14 5:21 ` Peter Todd
2014-02-17 5:47 ` Troy Benjegerdes
2014-02-27 23:48 ` Jorge Timón
2014-02-28 1:37 ` Peter Todd
2014-02-28 17:49 ` Jorge Timón
2014-03-01 17:45 ` Troy Benjegerdes
2014-03-01 18:22 ` Jeff Garzik
2014-03-01 18:28 ` Mark Friedenbach
2014-03-01 18:33 ` Jeff Garzik
2014-03-02 18:08 ` Troy Benjegerdes
2014-03-02 19:03 ` Jorge Timón
2014-02-12 16:34 ` Dan Carter [this message]
2014-02-14 5:20 ` Peter Todd
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='ldg7qs$6rn$1@ger.gmane.org' \
--to=carterd@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/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