* [Bitcoin-development] Decentralized digital asset exchange with honest pricing and market depth
@ 2014-02-09 18:04 Peter Todd
2014-02-09 20:44 ` Peter Todd
2014-02-12 16:34 ` Dan Carter
0 siblings, 2 replies; 17+ messages in thread
From: Peter Todd @ 2014-02-09 18:04 UTC (permalink / raw)
To: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 5164 bytes --]
Alex Mizrahi recently outlined a mechanism(1) based on SIGHASH_SINGLE
that allows colored coins and similar embedded consensus system assets
to be securely transferred to another party in exchange for Bitcoins
atomically. In summary his p2p 2-step-trade mechanism operates as
follows:
Alice controls a colored txout and wishes to sell it for 1BTC. Bob
wishes to buy that txout.
Alice signs a scriptSig using SIGHASH_SINGLE|ANYONECANPAY for a
transaction with a that time. (albeit a offer floor) single input, the
colored txout, and a single output with a scriptPubKey she controls and
nValue=1 This transaction is not valid as the value out is greater than
the value in.
She gives this partial transaction to Bob. He can now complete the
transaction by providing one or more inputs with a sum value >=1BTC, one
output for the colored coins to be directed to, and optionally any other
outputs required. (for instance for change)
Bob signs his inputs with SIGHASH_ALL and broadcasts the transaction,
completing the trade.
What Alice has signed, the first txin scriptSig, guarantees that if the
colored txout is spent she will receive 1BTC. Meanwhile what Bob has
signed, all other txin scriptSigs, sign the colored input and output,
guaranteeing that he will receive his coin in exchange for his money.
Thus the trade is trust free and atomic.
Decentralized markets and honest pricing
========================================
We can extend Mizrahi's 2-step-trade mechanism to create a decentralized
marketplace. First of all, remember that traders wishing to sell their
assets want to be sure that their assets offers reach the 100% of the
audience who may wish to buy said assets; an attacker may try to
manipulate the market to depress the price of an asset by hiding offers
from potential buyers. Similarly buyers want assurance that the offers
they are responding to represent all offers available.
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)
There is still some potential for manipulation with very recent offers,
particularly those embedded in unconfirmed transactions. However
typically markets have a large number of long-standing offers, which in
this case would be committed to the blockchain with one or more
confirmations.
Interestingly such a system can also provide honest historical pricing
information: any offer that goes unfilled for one or more blocks has (in
theory) been honestly published to 100% of those watching the blockchain
at that time. Thus we can assume the unfufilled offers at any
given block height are honest information about the market at that time
historically.
The overhead involved involved in Alice publishing the offer is roughly
a doubling of the overall transaction fees consumed. (remember that the
offer transaction is incomplete, and about half the size of the
acceptance transaction)
Application to other embedded consensus systems
===============================================
Any embedded consensus system can make use of the 2-step-trade mechanism
so long as it is possible to create transactions where spending a single
transaction output moves an asset appropriately.
Unfortunately extending this to circumstances where more than one input
needs to be spent, or more than out output needs to be created, is
difficult. SIGHASH_SINGLE by itself results in a signature where the
index of the output is signed, but the contents - scriptPubKey and
nValue - of all other outputs is not signed. Meanwhile all transaction
inputs are signed and changes to that set, other than modifying the
nSequence value in each CTxIn, is not possible.
If there was a SIGHASH mode that merely truncated vin and vout based on
the index of the scriptSig we could commit to data in either, but
unfortunately we can't do that.
An alternative could be to create a mechanism where some embedded data
signified the creation of a temporary transfer txout, where spending
that txout made the underlying change desired in the consensus state
atomically.
1) Alex Mizrahi, color kernel design considerations, Jan 7th 2014,
Colored coins (BitcoinX) mailing list,
https://groups.google.com/d/msg/bitcoinx/pON4XCIBeV4/IvzwkU8Vch0J
2) Peter Todd, [Bitcoin-development] Disentangling Crypto-Coin Mining:
Timestamping, Proof-of-Publication, and Validation, Nov 19 2013,
https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03307.html
--
'peter'[:-1]@petertodd.org
000000000000000075829f6169c79d7d5aaa20bfa8da6e9edb2393c4f8662ba0
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Bitcoin-development] Decentralized digital asset exchange with honest pricing and market depth
2014-02-09 18:04 [Bitcoin-development] Decentralized digital asset exchange with honest pricing and market depth Peter Todd
@ 2014-02-09 20:44 ` Peter Todd
2014-02-10 19:32 ` Peter Todd
2014-02-12 16:34 ` Dan Carter
1 sibling, 1 reply; 17+ messages in thread
From: Peter Todd @ 2014-02-09 20:44 UTC (permalink / raw)
To: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 688 bytes --]
On Sun, Feb 09, 2014 at 01:04:58PM -0500, Peter Todd wrote:
> Alex Mizrahi recently outlined a mechanism(1) based on SIGHASH_SINGLE
> that allows colored coins and similar embedded consensus system assets
> to be securely transferred to another party in exchange for Bitcoins
> atomically. In summary his p2p 2-step-trade mechanism operates as
> follows:
I'm told there's probably at least one if not more earlier
attributions/reinventions for the 2-step-trade protocol using
SIGHASH_SINGLE. Please reply with them if you have them so we can give
credit where credit is due.
--
'peter'[:-1]@petertodd.org
0000000000000001465bc2730ffed7493d166d18d288f6cf15e8cdb5d4a3c7b1
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Bitcoin-development] Decentralized digital asset exchange with honest pricing and market depth
2014-02-09 20:44 ` Peter Todd
@ 2014-02-10 19:32 ` Peter Todd
2014-02-11 17:59 ` Troy Benjegerdes
0 siblings, 1 reply; 17+ messages in thread
From: Peter Todd @ 2014-02-10 19:32 UTC (permalink / raw)
To: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 5210 bytes --]
On Sun, Feb 09, 2014 at 03:44:34PM -0500, Peter Todd wrote:
> On Sun, Feb 09, 2014 at 01:04:58PM -0500, Peter Todd wrote:
> > Alex Mizrahi recently outlined a mechanism(1) based on SIGHASH_SINGLE
> > that allows colored coins and similar embedded consensus system assets
> > to be securely transferred to another party in exchange for Bitcoins
> > atomically. In summary his p2p 2-step-trade mechanism operates as
> > follows:
>
> I'm told there's probably at least one if not more earlier
> attributions/reinventions for the 2-step-trade protocol using
> SIGHASH_SINGLE. Please reply with them if you have them so we can give
> credit where credit is due.
Got this:
Message-ID: <52418EBA.3080602@monetize•io>
Date: Tue, 24 Sep 2013 06:08:10 -0700
From: Mark Friedenbach <mark@monetize•io>
Organization: Monetize.io Inc.
To: Meni Rosenfeld <meni@bitcoil•co.il>
Subject: Re: Freimarkets and investment
If assets were tagged you could do a very limited form of pre-signed offers:
in: 10 btc SINGLE|ANYONECANPAY
out: 1 AAA
These are composable, in that you can append the inputs and outputs of
multiple offers together and result in a valid transaction. However this
is pretty much the limit of what is possible without adding new SIGHASH
modes, and if you're going to hard-fork to add tagging, then you might
as well go the whole distance with explicit hierarchical
sub-transactions as we did with Freimarkets.
Cheers,
Mark
On 9/24/13 5:44 AM, Meni Rosenfeld wrote:
> Hi Jorge,
>
> The video was sent to me by Amos Meiri, I think eToro funded its production.
>
> Maybe I don't understand SIGHASH_ANYONECANPAY very well. In the
> transaction, there will be an output of 1 "my stock" to an initially
> unknown address. Can I provide a signature for my input of 1 "my stock"
> that will be valid even with the output details provided later?
>
> In any case, I think that's out of scope for the presentation.
>
> Meni
>
> On 24/09/2013 13:10, Jorge Timón wrote:
>> Yes, it's a nice presentation.
>> I love the video with the chameleons that you link at the end !!
>>
>> As a little sugestion, I think the biggest advantage of tagging is not
>> inflatable assets, it's open binding orders. Even without granular
>> subtransactions as freimarket has, you could sign your input (say,
>> representing 1 "My stock") and only the output you're interested in
>> (say 100 bitstampUSD to myAddress) with SIGHASH_SINGLE |
>> SIGHASH_ANYONECANPAY.
>>
>> Without tagging, you need to know where the inputs come from to check
>> they're really bitstampUSD, because the network won't enforce the "100
>> bistampUSD" in your output, any uncolored coins filling the btc
>> quantity you wanted to represent those 100 usd will be ok, for miners.
>>
>> Goog luck with the talk, I'm eager to hear it.
>>
>> By the way, Mark, the explanation of the blockchain image sounds a
>> little bit like hashcasttle, no? well, just merged mining every new
>> asset, sounds like jaromil's freecoin too.
>>
>>
>> On 9/24/13, Meni Rosenfeld <meni@bitcoil•co.il> wrote:
>>> Hi Mark,
>>>
>>> We currently have a more general mathematical framework for the concept of
>>> colored coins - a color is a combination of initial state and a kernel
>>> function that maps input colors to output colors. Order-based coloring is
>>> one such kernel function, tagging is another. As long as you can point at an
>>> output and say what its color is, we call it a colored coin system.
>>>
>>> The blockchain image is a stand-in for "using a new block chain for each
>>> asset".
>>>
>>> Meni
>>>
>>> On 24/09/2013 00:42, Mark Friedenbach wrote:
> Hi Meni,
>
> I did call Freimarkets "colored coins" in the early days, but the term
> colored coin itself within the community seems to have become
> identified with the specific proposal of assigning value to specific
> satoshis, and running an order based coloring algorithm to determine
> asset flow, e.g. Bitcoin-X. Freimarkets allows issuance of entirely
> new assets and has explicit tagging of outputs, so we decided to avoid
> the phrase "colored coin" so as to keep from confusing people. But as
> an academic, yes you are correct.
>
> You presentation looks great. BTW, what's the first logo for the
> "Alternative token systems" slide? Or is that just a stand-in for the
> block chain?
>
> Mark
>
> On 9/23/13 12:24 PM, Meni Rosenfeld wrote:
>>>>>> Hi,
>>>>>>
>>>>>> As you might know I'm giving a talk about Colored Coins in
>>>>>> Amsterdam.
>>>>>>
>>>>>> My presentation is available at
>>>>>> https://bitcoil.co.il/files/Colored Coins.pptx (I'm not posting
>>>>>> this link publicly until after the talk).
>>>>>>
>>>>>> I'll be happy for any feedback.
>>>>>>
>>>>>> I'm listing Freimarkets as an implementation of Colored Coins. It
>>>>>> doesn't look like you're identifying with the term, but it does fit
>>>>>> the definition (and though it does obviously do much more than
>>>>>> just implement colored coins.)
>>>>>>
>>>>>> Thanks, Meni
>>>>
>>>
>>
>
--
'peter'[:-1]@petertodd.org
0000000076654614e7bf72ac80d47c57bca12503989f4d602538d3cd7892ca7d
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Bitcoin-development] Decentralized digital asset exchange with honest pricing and market depth
2014-02-10 19:32 ` Peter Todd
@ 2014-02-11 17:59 ` Troy Benjegerdes
2014-02-14 5:21 ` Peter Todd
0 siblings, 1 reply; 17+ messages in thread
From: Troy Benjegerdes @ 2014-02-11 17:59 UTC (permalink / raw)
To: Peter Todd; +Cc: bitcoin-development
Is there any code that does this? I would like to develop a multicoin-qt
wallet that runs on two blockchains from one binary, and allows trading
using this mechanism between the two chains.
On Mon, Feb 10, 2014 at 02:32:47PM -0500, Peter Todd wrote:
> On Sun, Feb 09, 2014 at 03:44:34PM -0500, Peter Todd wrote:
> > On Sun, Feb 09, 2014 at 01:04:58PM -0500, Peter Todd wrote:
> > > Alex Mizrahi recently outlined a mechanism(1) based on SIGHASH_SINGLE
> > > that allows colored coins and similar embedded consensus system assets
> > > to be securely transferred to another party in exchange for Bitcoins
> > > atomically. In summary his p2p 2-step-trade mechanism operates as
> > > follows:
> >
> > I'm told there's probably at least one if not more earlier
> > attributions/reinventions for the 2-step-trade protocol using
> > SIGHASH_SINGLE. Please reply with them if you have them so we can give
> > credit where credit is due.
>
> Got this:
>
> Message-ID: <52418EBA.3080602@monetize•io>
> Date: Tue, 24 Sep 2013 06:08:10 -0700
> From: Mark Friedenbach <mark@monetize•io>
> Organization: Monetize.io Inc.
> To: Meni Rosenfeld <meni@bitcoil•co.il>
> Subject: Re: Freimarkets and investment
>
> If assets were tagged you could do a very limited form of pre-signed offers:
>
> in: 10 btc SINGLE|ANYONECANPAY
> out: 1 AAA
>
> These are composable, in that you can append the inputs and outputs of
> multiple offers together and result in a valid transaction. However this
> is pretty much the limit of what is possible without adding new SIGHASH
> modes, and if you're going to hard-fork to add tagging, then you might
> as well go the whole distance with explicit hierarchical
> sub-transactions as we did with Freimarkets.
>
> Cheers,
> Mark
>
> On 9/24/13 5:44 AM, Meni Rosenfeld wrote:
> > Hi Jorge,
> >
> > The video was sent to me by Amos Meiri, I think eToro funded its production.
> >
> > Maybe I don't understand SIGHASH_ANYONECANPAY very well. In the
> > transaction, there will be an output of 1 "my stock" to an initially
> > unknown address. Can I provide a signature for my input of 1 "my stock"
> > that will be valid even with the output details provided later?
> >
> > In any case, I think that's out of scope for the presentation.
> >
> > Meni
> >
> > On 24/09/2013 13:10, Jorge Timón wrote:
> >> Yes, it's a nice presentation.
> >> I love the video with the chameleons that you link at the end !!
> >>
> >> As a little sugestion, I think the biggest advantage of tagging is not
> >> inflatable assets, it's open binding orders. Even without granular
> >> subtransactions as freimarket has, you could sign your input (say,
> >> representing 1 "My stock") and only the output you're interested in
> >> (say 100 bitstampUSD to myAddress) with SIGHASH_SINGLE |
> >> SIGHASH_ANYONECANPAY.
> >>
> >> Without tagging, you need to know where the inputs come from to check
> >> they're really bitstampUSD, because the network won't enforce the "100
> >> bistampUSD" in your output, any uncolored coins filling the btc
> >> quantity you wanted to represent those 100 usd will be ok, for miners.
> >>
> >> Goog luck with the talk, I'm eager to hear it.
> >>
> >> By the way, Mark, the explanation of the blockchain image sounds a
> >> little bit like hashcasttle, no? well, just merged mining every new
> >> asset, sounds like jaromil's freecoin too.
> >>
> >>
> >> On 9/24/13, Meni Rosenfeld <meni@bitcoil•co.il> wrote:
> >>> Hi Mark,
> >>>
> >>> We currently have a more general mathematical framework for the concept of
> >>> colored coins - a color is a combination of initial state and a kernel
> >>> function that maps input colors to output colors. Order-based coloring is
> >>> one such kernel function, tagging is another. As long as you can point at an
> >>> output and say what its color is, we call it a colored coin system.
> >>>
> >>> The blockchain image is a stand-in for "using a new block chain for each
> >>> asset".
> >>>
> >>> Meni
> >>>
> >>> On 24/09/2013 00:42, Mark Friedenbach wrote:
> > Hi Meni,
> >
> > I did call Freimarkets "colored coins" in the early days, but the term
> > colored coin itself within the community seems to have become
> > identified with the specific proposal of assigning value to specific
> > satoshis, and running an order based coloring algorithm to determine
> > asset flow, e.g. Bitcoin-X. Freimarkets allows issuance of entirely
> > new assets and has explicit tagging of outputs, so we decided to avoid
> > the phrase "colored coin" so as to keep from confusing people. But as
> > an academic, yes you are correct.
> >
> > You presentation looks great. BTW, what's the first logo for the
> > "Alternative token systems" slide? Or is that just a stand-in for the
> > block chain?
> >
> > Mark
> >
> > On 9/23/13 12:24 PM, Meni Rosenfeld wrote:
> >>>>>> Hi,
> >>>>>>
> >>>>>> As you might know I'm giving a talk about Colored Coins in
> >>>>>> Amsterdam.
> >>>>>>
> >>>>>> My presentation is available at
> >>>>>> https://bitcoil.co.il/files/Colored Coins.pptx (I'm not posting
> >>>>>> this link publicly until after the talk).
> >>>>>>
> >>>>>> I'll be happy for any feedback.
> >>>>>>
> >>>>>> I'm listing Freimarkets as an implementation of Colored Coins. It
> >>>>>> doesn't look like you're identifying with the term, but it does fit
> >>>>>> the definition (and though it does obviously do much more than
> >>>>>> just implement colored coins.)
> >>>>>>
> >>>>>> Thanks, Meni
> >>>>
> >>>
> >>
> >
>
> --
> 'peter'[:-1]@petertodd.org
> 0000000076654614e7bf72ac80d47c57bca12503989f4d602538d3cd7892ca7d
> ------------------------------------------------------------------------------
> Androi apps run on BlackBerry 10
> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
> Now with support for Jelly Bean, Bluetooth, Mapview and more.
> Get your Android app in front of a whole new audience. Start now.
> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Bitcoin-development] Decentralized digital asset exchange with honest pricing and market depth
2014-02-09 18:04 [Bitcoin-development] Decentralized digital asset exchange with honest pricing and market depth Peter Todd
2014-02-09 20:44 ` Peter Todd
@ 2014-02-12 16:34 ` Dan Carter
2014-02-14 5:20 ` Peter Todd
1 sibling, 1 reply; 17+ messages in thread
From: Dan Carter @ 2014-02-12 16:34 UTC (permalink / raw)
To: bitcoin-development
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)
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Bitcoin-development] Decentralized digital asset exchange with honest pricing and market depth
2014-02-12 16:34 ` Dan Carter
@ 2014-02-14 5:20 ` Peter Todd
0 siblings, 0 replies; 17+ messages in thread
From: Peter Todd @ 2014-02-14 5:20 UTC (permalink / raw)
To: Dan Carter; +Cc: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 1901 bytes --]
On Wed, Feb 12, 2014 at 08:34:48AM -0800, Dan Carter wrote:
> 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.
You're assuming the seller cares about fairness - why should they? They
offered a price for an asset and someone bought it; exactly which buyer
willing to buy at that price was able to complete the trade is
irrelevant to them. What they do care about is being sure that at
whatever given price they offered 100% of the buyers willing to buy at
that price actually see the offer in a reasonable amount of time - at
the best price the seller will get there will be only a single buyer
after all so you need that solid proof that said buyer was actually able
to get the offer.
--
'peter'[:-1]@petertodd.org
0000000000000000c34e2307bf2d8e1de9db0351acfe7320a08826a5de3c146a
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Bitcoin-development] Decentralized digital asset exchange with honest pricing and market depth
2014-02-11 17:59 ` Troy Benjegerdes
@ 2014-02-14 5:21 ` Peter Todd
2014-02-17 5:47 ` Troy Benjegerdes
0 siblings, 1 reply; 17+ messages in thread
From: Peter Todd @ 2014-02-14 5:21 UTC (permalink / raw)
To: Troy Benjegerdes; +Cc: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 494 bytes --]
On Tue, Feb 11, 2014 at 11:59:19AM -0600, Troy Benjegerdes wrote:
> Is there any code that does this? I would like to develop a multicoin-qt
> wallet that runs on two blockchains from one binary, and allows trading
> using this mechanism between the two chains.
Cross-chain trading is a different thing entirely; it doesn't allow for
the clever 2-party-trade trick. (as far as I know)
--
'peter'[:-1]@petertodd.org
0000000000000000c34e2307bf2d8e1de9db0351acfe7320a08826a5de3c146a
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Bitcoin-development] Decentralized digital asset exchange with honest pricing and market depth
2014-02-14 5:21 ` Peter Todd
@ 2014-02-17 5:47 ` Troy Benjegerdes
2014-02-27 23:48 ` Jorge Timón
0 siblings, 1 reply; 17+ messages in thread
From: Troy Benjegerdes @ 2014-02-17 5:47 UTC (permalink / raw)
To: Peter Todd; +Cc: bitcoin-development
On Fri, Feb 14, 2014 at 12:21:59AM -0500, Peter Todd wrote:
> On Tue, Feb 11, 2014 at 11:59:19AM -0600, Troy Benjegerdes wrote:
> > Is there any code that does this? I would like to develop a multicoin-qt
> > wallet that runs on two blockchains from one binary, and allows trading
> > using this mechanism between the two chains.
>
> Cross-chain trading is a different thing entirely; it doesn't allow for
> the clever 2-party-trade trick. (as far as I know)
Is there a simple way to do cross-chain trades that doesn't need a third
chain to somehow facilitate things?
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Bitcoin-development] Decentralized digital asset exchange with honest pricing and market depth
2014-02-17 5:47 ` Troy Benjegerdes
@ 2014-02-27 23:48 ` Jorge Timón
2014-02-28 1:37 ` Peter Todd
0 siblings, 1 reply; 17+ messages in thread
From: Jorge Timón @ 2014-02-27 23:48 UTC (permalink / raw)
To: Troy Benjegerdes; +Cc: bitcoin-development
First of all, sorry for the delayed answer.
On 2/10/14, Peter Todd <pete@petertodd•org> wrote:
> Got this:
[...]
Thank you, I knew this wasn't new for us but I doubted we had written
it anywhere.
As said in those mails, being only able to offer AAA for BTC and not
BTC for AAA nor AAA for BBB is enough of a limitation to justify a
hardfork IMO.
On 2/17/14, Troy Benjegerdes <hozer@hozed•org> wrote:
> Is there a simple way to do cross-chain trades that doesn't need a third
> chain to somehow facilitate things?
These are the two methods I know for cross-chain trading (no third
chain needed in any of them):
https://en.bitcoin.it/wiki/Contracts#Example_5:_Trading_across_chains
https://bitcointalk.org/index.php?topic=321228
On 2/14/14, Peter Todd <pete@petertodd•org> wrote:
> You're assuming the seller cares about fairness - why should they? They
> offered a price for an asset and someone bought it; exactly which buyer
> willing to buy at that price was able to complete the trade is
> irrelevant to them. What they do care about is being sure that at
> whatever given price they offered 100% of the buyers willing to buy at
> that price actually see the offer in a reasonable amount of time - at
> the best price the seller will get there will be only a single buyer
> after all so you need that solid proof that said buyer was actually able
> to get the offer.
In fact, I don't think the seller will care enough about this to pay
the proof of publication fee either. Assuming sellers can either
broadcast the order on a bitmessage-like network or use your proof of
publication scheme, the later will be always be more expensive. So my
prediction is that most people will just use the simplest, fastest and
cheapest method, but I guess only time can tell.
I don't think this will be a tragedy, because like we discussed on
IRC, I don't think the primary goal of markets is price discovery, but
trade itself.
About historic data, the actual trades are always public, and some
kind of "archivers" could collect and maintain old orders for historic
bid and asks, etc.
As an aside, nLockTime would be nice not to always have to
double-spend the inputs of an order to cancel it.
--
Jorge Timón
http://freico.in/
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Bitcoin-development] Decentralized digital asset exchange with honest pricing and market depth
2014-02-27 23:48 ` Jorge Timón
@ 2014-02-28 1:37 ` Peter Todd
2014-02-28 17:49 ` Jorge Timón
0 siblings, 1 reply; 17+ messages in thread
From: Peter Todd @ 2014-02-28 1:37 UTC (permalink / raw)
To: Jorge Timón; +Cc: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 2839 bytes --]
On Fri, Feb 28, 2014 at 12:48:33AM +0100, Jorge Timón wrote:
> First of all, sorry for the delayed answer.
>
> On 2/10/14, Peter Todd <pete@petertodd•org> wrote:
> > Got this:
> [...]
> Thank you, I knew this wasn't new for us but I doubted we had written
> it anywhere.
> As said in those mails, being only able to offer AAA for BTC and not
> BTC for AAA nor AAA for BBB is enough of a limitation to justify a
> hardfork IMO.
As usual, you don't need a hardfork.
Anyway, one-sided trade is sufficient to get a functioning marketplace
up and running and test out the many other issues with this stuff prior
to forking anything.
> On 2/14/14, Peter Todd <pete@petertodd•org> wrote:
> > You're assuming the seller cares about fairness - why should they? They
> > offered a price for an asset and someone bought it; exactly which buyer
> > willing to buy at that price was able to complete the trade is
> > irrelevant to them. What they do care about is being sure that at
> > whatever given price they offered 100% of the buyers willing to buy at
> > that price actually see the offer in a reasonable amount of time - at
> > the best price the seller will get there will be only a single buyer
> > after all so you need that solid proof that said buyer was actually able
> > to get the offer.
>
> In fact, I don't think the seller will care enough about this to pay
> the proof of publication fee either. Assuming sellers can either
> broadcast the order on a bitmessage-like network or use your proof of
> publication scheme, the later will be always be more expensive. So my
> prediction is that most people will just use the simplest, fastest and
> cheapest method, but I guess only time can tell.
You can make the same argument against Bitcoin itself you know...
A Bitmessage-like network would be trivial to front-run via a sybil
attack. It's the fundemental problem with marketplaces - the data
they're trying to publish has to be public.
> I don't think this will be a tragedy, because like we discussed on
> IRC, I don't think the primary goal of markets is price discovery, but
> trade itself.
>
> About historic data, the actual trades are always public, and some
> kind of "archivers" could collect and maintain old orders for historic
> bid and asks, etc.
And again, how do you know that record is honest? Fact is without
proof-of-publication you just don't.
> As an aside, nLockTime would be nice not to always have to
> double-spend the inputs of an order to cancel it.
You mean a reverse nLockTime that makes a transaction invalid after a
certain amount of time - that's dangerous in a reorg unfortunately as it
can make transactions permenantly invalid.
--
'peter'[:-1]@petertodd.org
0000000000000000b52709f0485161e764ac0198960885ccab019a978322cc6e
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Bitcoin-development] Decentralized digital asset exchange with honest pricing and market depth
2014-02-28 1:37 ` Peter Todd
@ 2014-02-28 17:49 ` Jorge Timón
2014-03-01 17:45 ` Troy Benjegerdes
0 siblings, 1 reply; 17+ messages in thread
From: Jorge Timón @ 2014-02-28 17:49 UTC (permalink / raw)
To: Peter Todd; +Cc: bitcoin-development
On 2/28/14, Peter Todd <pete@petertodd•org> wrote:
> As usual, you don't need a hardfork.
>
> Anyway, one-sided trade is sufficient to get a functioning marketplace
> up and running and test out the many other issues with this stuff prior
> to forking anything.
I'm totally FOR experimenting with this as it is and I'm happy that
Alex/Killerstorm is working on "regular" colored coins.
> You can make the same argument against Bitcoin itself you know...
>
> A Bitmessage-like network would be trivial to front-run via a sybil
> attack. It's the fundemental problem with marketplaces - the data
> they're trying to publish has to be public.
I don't see the Bitcoin analogy...
Anyway, I still don't think the seller cares, if he sells at the price
he was asking, what would he care about "front running" those parallel
networks.
I've seen many street markets without "public information" and they
work just well.
>> I don't think this will be a tragedy, because like we discussed on
>> IRC, I don't think the primary goal of markets is price discovery, but
>> trade itself.
>>
>> About historic data, the actual trades are always public, and some
>> kind of "archivers" could collect and maintain old orders for historic
>> bid and asks, etc.
>
> And again, how do you know that record is honest? Fact is without
> proof-of-publication you just don't.
Well, the trades that appeared in the chain actually occurred.
Buying to yourself at fake prices? Be careful, the miner could just
separate the order and fill it himself. Or anyone paying a higher fee,
for that matter.
Again, you haven't addressed why the seller cares more about "accurate
historic market data" than just his own fees and sell.
> You mean a reverse nLockTime that makes a transaction invalid after a
> certain amount of time - that's dangerous in a reorg unfortunately as it
> can make transactions permenantly invalid.
Yes, I'm aware this is a concern for many people and that's why I
bring it up when there's an useful use case (we have several important
uses in freimarkets).
Probably this belongs to another thread or just #wizards, but if I
remember correctly, the last discussion we had about this, I think
with you and gmaxwell, was more or less like this:
-Valid transactions could get invalid with a regorg
-Just like with any transaction if a double-spend appears, this just
means that you would need to wait for expiry transactions to be
somewhat buried to accept payments from it.
-That introduces fungibility problems.
-True, but doesn't seem a particularly difficult problem (I think we
actually drafted some potential solutions, like introducing a maturity
rule for expiry transactions) and the advantages outweigh that
potential problem IMO.
So in summary, I feel like before actually solving the problem we need
to rise more awareness on how nice and necessary nExpiryTime would be.
Anyway, sorry, I just wanted to point out another use, a deeper
discussion about this belongs to another thread.
--
Jorge Timón
http://freico.in/
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Bitcoin-development] Decentralized digital asset exchange with honest pricing and market depth
2014-02-28 17:49 ` Jorge Timón
@ 2014-03-01 17:45 ` Troy Benjegerdes
2014-03-01 18:22 ` Jeff Garzik
0 siblings, 1 reply; 17+ messages in thread
From: Troy Benjegerdes @ 2014-03-01 17:45 UTC (permalink / raw)
To: Jorge Timón; +Cc: bitcoin-development
> > You can make the same argument against Bitcoin itself you know...
> >
> > A Bitmessage-like network would be trivial to front-run via a sybil
> > attack. It's the fundemental problem with marketplaces - the data
> > they're trying to publish has to be public.
>
> I don't see the Bitcoin analogy...
> Anyway, I still don't think the seller cares, if he sells at the price
> he was asking, what would he care about "front running" those parallel
> networks.
> I've seen many street markets without "public information" and they
> work just well.
The spot price for ammonia fertilizer, refined gasoline at terminals,
and price of tea in china are not 'public information', yet these are
some of the largest traded commodities in the world, far exceeding
the drop in the bucket that all cryptocoin transactions make.
I'd further argue that the *actual* price of corn (cash bid price at
elevators and ethanol plants) is not public information either. There
is a great deal of money traded in collecting and then distributing the
'cleared price' information. Have a look at
http://www.interquote.com/template.cfm?navgroup=aboutlist&urlcode=12&view=1
> >> I don't think this will be a tragedy, because like we discussed on
> >> IRC, I don't think the primary goal of markets is price discovery, but
> >> trade itself.
> >>
> >> About historic data, the actual trades are always public, and some
> >> kind of "archivers" could collect and maintain old orders for historic
> >> bid and asks, etc.
> >
> > And again, how do you know that record is honest? Fact is without
> > proof-of-publication you just don't.
>
> Well, the trades that appeared in the chain actually occurred.
> Buying to yourself at fake prices? Be careful, the miner could just
> separate the order and fill it himself. Or anyone paying a higher fee,
> for that matter.
You just made my long-term strategic argument for investing in my own
mining hardware so I can be sure to trade reliably.
> Again, you haven't addressed why the seller cares more about "accurate
> historic market data" than just his own fees and sell.
>
> > You mean a reverse nLockTime that makes a transaction invalid after a
> > certain amount of time - that's dangerous in a reorg unfortunately as it
> > can make transactions permenantly invalid.
People who take money from buyers and sellers care most about 'accurate
historic market data'. I just want to exchange my corn for e85, fertilizer,
and electricity, and audit the code that runs accounting for the exchange.
I really don't give a shit if there is 'accurate historic market data' as
long as **MY** personal trade data is accurate and I got a good enough price,
and I know who I'm dealing with.
I know someone smarter than me and with more money, market leverage, and
political connections **WILL** game the system and distort the market data
history so they can take more money from buyers and sellers without actually
doing some usefull market function.
As long as use buyers and sellers can see the code, and have a good eye for
knowing when someone's pushing the market around, we can just put our orders
in and relieve some speculators of their money.
Just get me working code for cross-chain trades, and we'll work on the
accurate historic data problem later.
----------------------------------------------------------------------------
Troy Benjegerdes 'da hozer' hozer@hozed•org
7 elements earth::water::air::fire::mind::spirit::soul grid.coop
Never pick a fight with someone who buys ink by the barrel,
nor try buy a hacker who makes money by the megahash
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Bitcoin-development] Decentralized digital asset exchange with honest pricing and market depth
2014-03-01 17:45 ` Troy Benjegerdes
@ 2014-03-01 18:22 ` Jeff Garzik
2014-03-01 18:28 ` Mark Friedenbach
0 siblings, 1 reply; 17+ messages in thread
From: Jeff Garzik @ 2014-03-01 18:22 UTC (permalink / raw)
To: Troy Benjegerdes; +Cc: Bitcoin Dev
This is wandering far off-topic for this mailing list.
On Sat, Mar 1, 2014 at 12:45 PM, Troy Benjegerdes <hozer@hozed•org> wrote:
>> > You can make the same argument against Bitcoin itself you know...
>> >
>> > A Bitmessage-like network would be trivial to front-run via a sybil
>> > attack. It's the fundemental problem with marketplaces - the data
>> > they're trying to publish has to be public.
>>
>> I don't see the Bitcoin analogy...
>> Anyway, I still don't think the seller cares, if he sells at the price
>> he was asking, what would he care about "front running" those parallel
>> networks.
>> I've seen many street markets without "public information" and they
>> work just well.
>
> The spot price for ammonia fertilizer, refined gasoline at terminals,
> and price of tea in china are not 'public information', yet these are
> some of the largest traded commodities in the world, far exceeding
> the drop in the bucket that all cryptocoin transactions make.
>
> I'd further argue that the *actual* price of corn (cash bid price at
> elevators and ethanol plants) is not public information either. There
> is a great deal of money traded in collecting and then distributing the
> 'cleared price' information. Have a look at
> http://www.interquote.com/template.cfm?navgroup=aboutlist&urlcode=12&view=1
>
>
>> >> I don't think this will be a tragedy, because like we discussed on
>> >> IRC, I don't think the primary goal of markets is price discovery, but
>> >> trade itself.
>> >>
>> >> About historic data, the actual trades are always public, and some
>> >> kind of "archivers" could collect and maintain old orders for historic
>> >> bid and asks, etc.
>> >
>> > And again, how do you know that record is honest? Fact is without
>> > proof-of-publication you just don't.
>>
>> Well, the trades that appeared in the chain actually occurred.
>> Buying to yourself at fake prices? Be careful, the miner could just
>> separate the order and fill it himself. Or anyone paying a higher fee,
>> for that matter.
>
> You just made my long-term strategic argument for investing in my own
> mining hardware so I can be sure to trade reliably.
>
>> Again, you haven't addressed why the seller cares more about "accurate
>> historic market data" than just his own fees and sell.
>>
>> > You mean a reverse nLockTime that makes a transaction invalid after a
>> > certain amount of time - that's dangerous in a reorg unfortunately as it
>> > can make transactions permenantly invalid.
>
> People who take money from buyers and sellers care most about 'accurate
> historic market data'. I just want to exchange my corn for e85, fertilizer,
> and electricity, and audit the code that runs accounting for the exchange.
>
> I really don't give a shit if there is 'accurate historic market data' as
> long as **MY** personal trade data is accurate and I got a good enough price,
> and I know who I'm dealing with.
>
> I know someone smarter than me and with more money, market leverage, and
> political connections **WILL** game the system and distort the market data
> history so they can take more money from buyers and sellers without actually
> doing some usefull market function.
>
> As long as use buyers and sellers can see the code, and have a good eye for
> knowing when someone's pushing the market around, we can just put our orders
> in and relieve some speculators of their money.
>
> Just get me working code for cross-chain trades, and we'll work on the
> accurate historic data problem later.
>
> ----------------------------------------------------------------------------
> Troy Benjegerdes 'da hozer' hozer@hozed•org
> 7 elements earth::water::air::fire::mind::spirit::soul grid.coop
>
> Never pick a fight with someone who buys ink by the barrel,
> nor try buy a hacker who makes money by the megahash
>
>
> ------------------------------------------------------------------------------
> Flow-based real-time traffic analytics software. Cisco certified tool.
> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
> Customize your own dashboards, set traffic alerts and generate reports.
> Network behavioral analysis & security monitoring. All-in-one tool.
> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Bitcoin-development] Decentralized digital asset exchange with honest pricing and market depth
2014-03-01 18:22 ` Jeff Garzik
@ 2014-03-01 18:28 ` Mark Friedenbach
2014-03-01 18:33 ` Jeff Garzik
0 siblings, 1 reply; 17+ messages in thread
From: Mark Friedenbach @ 2014-03-01 18:28 UTC (permalink / raw)
To: Jeff Garzik; +Cc: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 5617 bytes --]
Only if you view bitcoin as no more than a payment network.
On Mar 1, 2014 10:24 AM, "Jeff Garzik" <jgarzik@bitpay•com> wrote:
> This is wandering far off-topic for this mailing list.
>
> On Sat, Mar 1, 2014 at 12:45 PM, Troy Benjegerdes <hozer@hozed•org> wrote:
> >> > You can make the same argument against Bitcoin itself you know...
> >> >
> >> > A Bitmessage-like network would be trivial to front-run via a sybil
> >> > attack. It's the fundemental problem with marketplaces - the data
> >> > they're trying to publish has to be public.
> >>
> >> I don't see the Bitcoin analogy...
> >> Anyway, I still don't think the seller cares, if he sells at the price
> >> he was asking, what would he care about "front running" those parallel
> >> networks.
> >> I've seen many street markets without "public information" and they
> >> work just well.
> >
> > The spot price for ammonia fertilizer, refined gasoline at terminals,
> > and price of tea in china are not 'public information', yet these are
> > some of the largest traded commodities in the world, far exceeding
> > the drop in the bucket that all cryptocoin transactions make.
> >
> > I'd further argue that the *actual* price of corn (cash bid price at
> > elevators and ethanol plants) is not public information either. There
> > is a great deal of money traded in collecting and then distributing the
> > 'cleared price' information. Have a look at
> >
> http://www.interquote.com/template.cfm?navgroup=aboutlist&urlcode=12&view=1
> >
> >
> >> >> I don't think this will be a tragedy, because like we discussed on
> >> >> IRC, I don't think the primary goal of markets is price discovery,
> but
> >> >> trade itself.
> >> >>
> >> >> About historic data, the actual trades are always public, and some
> >> >> kind of "archivers" could collect and maintain old orders for
> historic
> >> >> bid and asks, etc.
> >> >
> >> > And again, how do you know that record is honest? Fact is without
> >> > proof-of-publication you just don't.
> >>
> >> Well, the trades that appeared in the chain actually occurred.
> >> Buying to yourself at fake prices? Be careful, the miner could just
> >> separate the order and fill it himself. Or anyone paying a higher fee,
> >> for that matter.
> >
> > You just made my long-term strategic argument for investing in my own
> > mining hardware so I can be sure to trade reliably.
> >
> >> Again, you haven't addressed why the seller cares more about "accurate
> >> historic market data" than just his own fees and sell.
> >>
> >> > You mean a reverse nLockTime that makes a transaction invalid after a
> >> > certain amount of time - that's dangerous in a reorg unfortunately as
> it
> >> > can make transactions permenantly invalid.
> >
> > People who take money from buyers and sellers care most about 'accurate
> > historic market data'. I just want to exchange my corn for e85,
> fertilizer,
> > and electricity, and audit the code that runs accounting for the
> exchange.
> >
> > I really don't give a shit if there is 'accurate historic market data' as
> > long as **MY** personal trade data is accurate and I got a good enough
> price,
> > and I know who I'm dealing with.
> >
> > I know someone smarter than me and with more money, market leverage, and
> > political connections **WILL** game the system and distort the market
> data
> > history so they can take more money from buyers and sellers without
> actually
> > doing some usefull market function.
> >
> > As long as use buyers and sellers can see the code, and have a good eye
> for
> > knowing when someone's pushing the market around, we can just put our
> orders
> > in and relieve some speculators of their money.
> >
> > Just get me working code for cross-chain trades, and we'll work on the
> > accurate historic data problem later.
> >
> >
> ----------------------------------------------------------------------------
> > Troy Benjegerdes 'da hozer'
> hozer@hozed•org
> > 7 elements earth::water::air::fire::mind::spirit::soul
> grid.coop
> >
> > Never pick a fight with someone who buys ink by the barrel,
> > nor try buy a hacker who makes money by the megahash
> >
> >
> >
> ------------------------------------------------------------------------------
> > Flow-based real-time traffic analytics software. Cisco certified tool.
> > Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
> > Customize your own dashboards, set traffic alerts and generate reports.
> > Network behavioral analysis & security monitoring. All-in-one tool.
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development@lists•sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc. https://bitpay.com/
>
>
> ------------------------------------------------------------------------------
> Flow-based real-time traffic analytics software. Cisco certified tool.
> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
> Customize your own dashboards, set traffic alerts and generate reports.
> Network behavioral analysis & security monitoring. All-in-one tool.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
[-- Attachment #2: Type: text/html, Size: 7652 bytes --]
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Bitcoin-development] Decentralized digital asset exchange with honest pricing and market depth
2014-03-01 18:28 ` Mark Friedenbach
@ 2014-03-01 18:33 ` Jeff Garzik
2014-03-02 18:08 ` Troy Benjegerdes
0 siblings, 1 reply; 17+ messages in thread
From: Jeff Garzik @ 2014-03-01 18:33 UTC (permalink / raw)
To: Mark Friedenbach; +Cc: Bitcoin Dev
This is not bitcoin-philosophy, it's bitcoin-development. Existential
philosophy belongs on IRC or the forums.
On Sat, Mar 1, 2014 at 1:28 PM, Mark Friedenbach <mark@monetize•io> wrote:
> Only if you view bitcoin as no more than a payment network.
>
> On Mar 1, 2014 10:24 AM, "Jeff Garzik" <jgarzik@bitpay•com> wrote:
>>
>> This is wandering far off-topic for this mailing list.
>>
>> On Sat, Mar 1, 2014 at 12:45 PM, Troy Benjegerdes <hozer@hozed•org> wrote:
>> >> > You can make the same argument against Bitcoin itself you know...
>> >> >
>> >> > A Bitmessage-like network would be trivial to front-run via a sybil
>> >> > attack. It's the fundemental problem with marketplaces - the data
>> >> > they're trying to publish has to be public.
>> >>
>> >> I don't see the Bitcoin analogy...
>> >> Anyway, I still don't think the seller cares, if he sells at the price
>> >> he was asking, what would he care about "front running" those parallel
>> >> networks.
>> >> I've seen many street markets without "public information" and they
>> >> work just well.
>> >
>> > The spot price for ammonia fertilizer, refined gasoline at terminals,
>> > and price of tea in china are not 'public information', yet these are
>> > some of the largest traded commodities in the world, far exceeding
>> > the drop in the bucket that all cryptocoin transactions make.
>> >
>> > I'd further argue that the *actual* price of corn (cash bid price at
>> > elevators and ethanol plants) is not public information either. There
>> > is a great deal of money traded in collecting and then distributing the
>> > 'cleared price' information. Have a look at
>> >
>> > http://www.interquote.com/template.cfm?navgroup=aboutlist&urlcode=12&view=1
>> >
>> >
>> >> >> I don't think this will be a tragedy, because like we discussed on
>> >> >> IRC, I don't think the primary goal of markets is price discovery,
>> >> >> but
>> >> >> trade itself.
>> >> >>
>> >> >> About historic data, the actual trades are always public, and some
>> >> >> kind of "archivers" could collect and maintain old orders for
>> >> >> historic
>> >> >> bid and asks, etc.
>> >> >
>> >> > And again, how do you know that record is honest? Fact is without
>> >> > proof-of-publication you just don't.
>> >>
>> >> Well, the trades that appeared in the chain actually occurred.
>> >> Buying to yourself at fake prices? Be careful, the miner could just
>> >> separate the order and fill it himself. Or anyone paying a higher fee,
>> >> for that matter.
>> >
>> > You just made my long-term strategic argument for investing in my own
>> > mining hardware so I can be sure to trade reliably.
>> >
>> >> Again, you haven't addressed why the seller cares more about "accurate
>> >> historic market data" than just his own fees and sell.
>> >>
>> >> > You mean a reverse nLockTime that makes a transaction invalid after a
>> >> > certain amount of time - that's dangerous in a reorg unfortunately as
>> >> > it
>> >> > can make transactions permenantly invalid.
>> >
>> > People who take money from buyers and sellers care most about 'accurate
>> > historic market data'. I just want to exchange my corn for e85,
>> > fertilizer,
>> > and electricity, and audit the code that runs accounting for the
>> > exchange.
>> >
>> > I really don't give a shit if there is 'accurate historic market data'
>> > as
>> > long as **MY** personal trade data is accurate and I got a good enough
>> > price,
>> > and I know who I'm dealing with.
>> >
>> > I know someone smarter than me and with more money, market leverage, and
>> > political connections **WILL** game the system and distort the market
>> > data
>> > history so they can take more money from buyers and sellers without
>> > actually
>> > doing some usefull market function.
>> >
>> > As long as use buyers and sellers can see the code, and have a good eye
>> > for
>> > knowing when someone's pushing the market around, we can just put our
>> > orders
>> > in and relieve some speculators of their money.
>> >
>> > Just get me working code for cross-chain trades, and we'll work on the
>> > accurate historic data problem later.
>> >
>> >
>> > ----------------------------------------------------------------------------
>> > Troy Benjegerdes 'da hozer'
>> > hozer@hozed•org
>> > 7 elements earth::water::air::fire::mind::spirit::soul
>> > grid.coop
>> >
>> > Never pick a fight with someone who buys ink by the barrel,
>> > nor try buy a hacker who makes money by the megahash
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Flow-based real-time traffic analytics software. Cisco certified tool.
>> > Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
>> > Customize your own dashboards, set traffic alerts and generate reports.
>> > Network behavioral analysis & security monitoring. All-in-one tool.
>> >
>> > http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
>> > _______________________________________________
>> > Bitcoin-development mailing list
>> > Bitcoin-development@lists•sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>>
>> --
>> Jeff Garzik
>> Bitcoin core developer and open source evangelist
>> BitPay, Inc. https://bitpay.com/
>>
>>
>> ------------------------------------------------------------------------------
>> Flow-based real-time traffic analytics software. Cisco certified tool.
>> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
>> Customize your own dashboards, set traffic alerts and generate reports.
>> Network behavioral analysis & security monitoring. All-in-one tool.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists•sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Bitcoin-development] Decentralized digital asset exchange with honest pricing and market depth
2014-03-01 18:33 ` Jeff Garzik
@ 2014-03-02 18:08 ` Troy Benjegerdes
2014-03-02 19:03 ` Jorge Timón
0 siblings, 1 reply; 17+ messages in thread
From: Troy Benjegerdes @ 2014-03-02 18:08 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Bitcoin Dev
I'm asking for how to DEVELOP THE CODE so I can trade between two block
chains, and then I'm going to start trading cats and dogs and bits.
Somewhere in trying to figure out the design spec we got caught up in existential
concern about 'globally knowable and accurate price history', and I'm telling you
it doesn't matter.
I'm the customer and the developer, someone give me a clear design document to
trade between two chains and I can write it, and then we can debate improvements.
On Sat, Mar 01, 2014 at 01:33:25PM -0500, Jeff Garzik wrote:
> This is not bitcoin-philosophy, it's bitcoin-development. Existential
> philosophy belongs on IRC or the forums.
>
>
> On Sat, Mar 1, 2014 at 1:28 PM, Mark Friedenbach <mark@monetize•io> wrote:
> > Only if you view bitcoin as no more than a payment network.
> >
> > On Mar 1, 2014 10:24 AM, "Jeff Garzik" <jgarzik@bitpay•com> wrote:
> >>
> >> This is wandering far off-topic for this mailing list.
> >>
> >> On Sat, Mar 1, 2014 at 12:45 PM, Troy Benjegerdes <hozer@hozed•org> wrote:
> >> >> > You can make the same argument against Bitcoin itself you know...
> >> >> >
> >> >> > A Bitmessage-like network would be trivial to front-run via a sybil
> >> >> > attack. It's the fundemental problem with marketplaces - the data
> >> >> > they're trying to publish has to be public.
> >> >>
> >> >> I don't see the Bitcoin analogy...
> >> >> Anyway, I still don't think the seller cares, if he sells at the price
> >> >> he was asking, what would he care about "front running" those parallel
> >> >> networks.
> >> >> I've seen many street markets without "public information" and they
> >> >> work just well.
> >> >
> >> > The spot price for ammonia fertilizer, refined gasoline at terminals,
> >> > and price of tea in china are not 'public information', yet these are
> >> > some of the largest traded commodities in the world, far exceeding
> >> > the drop in the bucket that all cryptocoin transactions make.
> >> >
> >> > I'd further argue that the *actual* price of corn (cash bid price at
> >> > elevators and ethanol plants) is not public information either. There
> >> > is a great deal of money traded in collecting and then distributing the
> >> > 'cleared price' information. Have a look at
> >> >
> >> > http://www.interquote.com/template.cfm?navgroup=aboutlist&urlcode=12&view=1
> >> >
> >> >
> >> >> >> I don't think this will be a tragedy, because like we discussed on
> >> >> >> IRC, I don't think the primary goal of markets is price discovery,
> >> >> >> but
> >> >> >> trade itself.
> >> >> >>
> >> >> >> About historic data, the actual trades are always public, and some
> >> >> >> kind of "archivers" could collect and maintain old orders for
> >> >> >> historic
> >> >> >> bid and asks, etc.
> >> >> >
> >> >> > And again, how do you know that record is honest? Fact is without
> >> >> > proof-of-publication you just don't.
> >> >>
> >> >> Well, the trades that appeared in the chain actually occurred.
> >> >> Buying to yourself at fake prices? Be careful, the miner could just
> >> >> separate the order and fill it himself. Or anyone paying a higher fee,
> >> >> for that matter.
> >> >
> >> > You just made my long-term strategic argument for investing in my own
> >> > mining hardware so I can be sure to trade reliably.
> >> >
> >> >> Again, you haven't addressed why the seller cares more about "accurate
> >> >> historic market data" than just his own fees and sell.
> >> >>
> >> >> > You mean a reverse nLockTime that makes a transaction invalid after a
> >> >> > certain amount of time - that's dangerous in a reorg unfortunately as
> >> >> > it
> >> >> > can make transactions permenantly invalid.
> >> >
> >> > People who take money from buyers and sellers care most about 'accurate
> >> > historic market data'. I just want to exchange my corn for e85,
> >> > fertilizer,
> >> > and electricity, and audit the code that runs accounting for the
> >> > exchange.
> >> >
> >> > I really don't give a shit if there is 'accurate historic market data'
> >> > as
> >> > long as **MY** personal trade data is accurate and I got a good enough
> >> > price,
> >> > and I know who I'm dealing with.
> >> >
> >> > I know someone smarter than me and with more money, market leverage, and
> >> > political connections **WILL** game the system and distort the market
> >> > data
> >> > history so they can take more money from buyers and sellers without
> >> > actually
> >> > doing some usefull market function.
> >> >
> >> > As long as use buyers and sellers can see the code, and have a good eye
> >> > for
> >> > knowing when someone's pushing the market around, we can just put our
> >> > orders
> >> > in and relieve some speculators of their money.
> >> >
> >> > Just get me working code for cross-chain trades, and we'll work on the
> >> > accurate historic data problem later.
> >> >
> >> >
> >> > ----------------------------------------------------------------------------
> >> > Troy Benjegerdes 'da hozer'
> >> > hozer@hozed•org
> >> > 7 elements earth::water::air::fire::mind::spirit::soul
> >> > grid.coop
> >> >
> >> > Never pick a fight with someone who buys ink by the barrel,
> >> > nor try buy a hacker who makes money by the megahash
> >> >
> >> >
> >> >
> >> > ------------------------------------------------------------------------------
> >> > Flow-based real-time traffic analytics software. Cisco certified tool.
> >> > Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
> >> > Customize your own dashboards, set traffic alerts and generate reports.
> >> > Network behavioral analysis & security monitoring. All-in-one tool.
> >> >
> >> > http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
> >> > _______________________________________________
> >> > Bitcoin-development mailing list
> >> > Bitcoin-development@lists•sourceforge.net
> >> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >>
> >>
> >>
> >> --
> >> Jeff Garzik
> >> Bitcoin core developer and open source evangelist
> >> BitPay, Inc. https://bitpay.com/
> >>
> >>
> >> ------------------------------------------------------------------------------
> >> Flow-based real-time traffic analytics software. Cisco certified tool.
> >> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
> >> Customize your own dashboards, set traffic alerts and generate reports.
> >> Network behavioral analysis & security monitoring. All-in-one tool.
> >>
> >> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
> >> _______________________________________________
> >> Bitcoin-development mailing list
> >> Bitcoin-development@lists•sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc. https://bitpay.com/
--
----------------------------------------------------------------------------
Troy Benjegerdes 'da hozer' hozer@hozed•org
7 elements earth::water::air::fire::mind::spirit::soul grid.coop
Never pick a fight with someone who buys ink by the barrel,
nor try buy a hacker who makes money by the megahash
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Bitcoin-development] Decentralized digital asset exchange with honest pricing and market depth
2014-03-02 18:08 ` Troy Benjegerdes
@ 2014-03-02 19:03 ` Jorge Timón
0 siblings, 0 replies; 17+ messages in thread
From: Jorge Timón @ 2014-03-02 19:03 UTC (permalink / raw)
To: Troy Benjegerdes; +Cc: Bitcoin Dev
Again, the two best ways are here:
https://en.bitcoin.it/wiki/Contracts#Example_5:_Trading_across_chains
https://bitcointalk.org/index.php?topic=321228
But this is off-topic, Peter wasn't talking about cross-chain trade.
On 3/2/14, Troy Benjegerdes <hozer@hozed•org> wrote:
> I'm asking for how to DEVELOP THE CODE so I can trade between two block
> chains, and then I'm going to start trading cats and dogs and bits.
>
> Somewhere in trying to figure out the design spec we got caught up in
> existential
> concern about 'globally knowable and accurate price history', and I'm
> telling you
> it doesn't matter.
>
> I'm the customer and the developer, someone give me a clear design document
> to
> trade between two chains and I can write it, and then we can debate
> improvements.
>
>
> On Sat, Mar 01, 2014 at 01:33:25PM -0500, Jeff Garzik wrote:
>> This is not bitcoin-philosophy, it's bitcoin-development. Existential
>> philosophy belongs on IRC or the forums.
>>
>>
>> On Sat, Mar 1, 2014 at 1:28 PM, Mark Friedenbach <mark@monetize•io>
>> wrote:
>> > Only if you view bitcoin as no more than a payment network.
>> >
>> > On Mar 1, 2014 10:24 AM, "Jeff Garzik" <jgarzik@bitpay•com> wrote:
>> >>
>> >> This is wandering far off-topic for this mailing list.
>> >>
>> >> On Sat, Mar 1, 2014 at 12:45 PM, Troy Benjegerdes <hozer@hozed•org>
>> >> wrote:
>> >> >> > You can make the same argument against Bitcoin itself you know...
>> >> >> >
>> >> >> > A Bitmessage-like network would be trivial to front-run via a
>> >> >> > sybil
>> >> >> > attack. It's the fundemental problem with marketplaces - the data
>> >> >> > they're trying to publish has to be public.
>> >> >>
>> >> >> I don't see the Bitcoin analogy...
>> >> >> Anyway, I still don't think the seller cares, if he sells at the
>> >> >> price
>> >> >> he was asking, what would he care about "front running" those
>> >> >> parallel
>> >> >> networks.
>> >> >> I've seen many street markets without "public information" and they
>> >> >> work just well.
>> >> >
>> >> > The spot price for ammonia fertilizer, refined gasoline at
>> >> > terminals,
>> >> > and price of tea in china are not 'public information', yet these
>> >> > are
>> >> > some of the largest traded commodities in the world, far exceeding
>> >> > the drop in the bucket that all cryptocoin transactions make.
>> >> >
>> >> > I'd further argue that the *actual* price of corn (cash bid price at
>> >> > elevators and ethanol plants) is not public information either.
>> >> > There
>> >> > is a great deal of money traded in collecting and then distributing
>> >> > the
>> >> > 'cleared price' information. Have a look at
>> >> >
>> >> > http://www.interquote.com/template.cfm?navgroup=aboutlist&urlcode=12&view=1
>> >> >
>> >> >
>> >> >> >> I don't think this will be a tragedy, because like we discussed
>> >> >> >> on
>> >> >> >> IRC, I don't think the primary goal of markets is price
>> >> >> >> discovery,
>> >> >> >> but
>> >> >> >> trade itself.
>> >> >> >>
>> >> >> >> About historic data, the actual trades are always public, and
>> >> >> >> some
>> >> >> >> kind of "archivers" could collect and maintain old orders for
>> >> >> >> historic
>> >> >> >> bid and asks, etc.
>> >> >> >
>> >> >> > And again, how do you know that record is honest? Fact is without
>> >> >> > proof-of-publication you just don't.
>> >> >>
>> >> >> Well, the trades that appeared in the chain actually occurred.
>> >> >> Buying to yourself at fake prices? Be careful, the miner could just
>> >> >> separate the order and fill it himself. Or anyone paying a higher
>> >> >> fee,
>> >> >> for that matter.
>> >> >
>> >> > You just made my long-term strategic argument for investing in my
>> >> > own
>> >> > mining hardware so I can be sure to trade reliably.
>> >> >
>> >> >> Again, you haven't addressed why the seller cares more about
>> >> >> "accurate
>> >> >> historic market data" than just his own fees and sell.
>> >> >>
>> >> >> > You mean a reverse nLockTime that makes a transaction invalid
>> >> >> > after a
>> >> >> > certain amount of time - that's dangerous in a reorg unfortunately
>> >> >> > as
>> >> >> > it
>> >> >> > can make transactions permenantly invalid.
>> >> >
>> >> > People who take money from buyers and sellers care most about
>> >> > 'accurate
>> >> > historic market data'. I just want to exchange my corn for e85,
>> >> > fertilizer,
>> >> > and electricity, and audit the code that runs accounting for the
>> >> > exchange.
>> >> >
>> >> > I really don't give a shit if there is 'accurate historic market
>> >> > data'
>> >> > as
>> >> > long as **MY** personal trade data is accurate and I got a good
>> >> > enough
>> >> > price,
>> >> > and I know who I'm dealing with.
>> >> >
>> >> > I know someone smarter than me and with more money, market leverage,
>> >> > and
>> >> > political connections **WILL** game the system and distort the
>> >> > market
>> >> > data
>> >> > history so they can take more money from buyers and sellers without
>> >> > actually
>> >> > doing some usefull market function.
>> >> >
>> >> > As long as use buyers and sellers can see the code, and have a good
>> >> > eye
>> >> > for
>> >> > knowing when someone's pushing the market around, we can just put
>> >> > our
>> >> > orders
>> >> > in and relieve some speculators of their money.
>> >> >
>> >> > Just get me working code for cross-chain trades, and we'll work on
>> >> > the
>> >> > accurate historic data problem later.
>> >> >
>> >> >
>> >> > ----------------------------------------------------------------------------
>> >> > Troy Benjegerdes 'da hozer'
>> >> > hozer@hozed•org
>> >> > 7 elements earth::water::air::fire::mind::spirit::soul
>> >> > grid.coop
>> >> >
>> >> > Never pick a fight with someone who buys ink by the barrel,
>> >> > nor try buy a hacker who makes money by the megahash
>> >> >
>> >> >
>> >> >
>> >> > ------------------------------------------------------------------------------
>> >> > Flow-based real-time traffic analytics software. Cisco certified
>> >> > tool.
>> >> > Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow
>> >> > Analyzer
>> >> > Customize your own dashboards, set traffic alerts and generate
>> >> > reports.
>> >> > Network behavioral analysis & security monitoring. All-in-one tool.
>> >> >
>> >> > http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
>> >> > _______________________________________________
>> >> > Bitcoin-development mailing list
>> >> > Bitcoin-development@lists•sourceforge.net
>> >> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>> >>
>> >>
>> >>
>> >> --
>> >> Jeff Garzik
>> >> Bitcoin core developer and open source evangelist
>> >> BitPay, Inc. https://bitpay.com/
>> >>
>> >>
>> >> ------------------------------------------------------------------------------
>> >> Flow-based real-time traffic analytics software. Cisco certified tool.
>> >> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
>> >> Customize your own dashboards, set traffic alerts and generate
>> >> reports.
>> >> Network behavioral analysis & security monitoring. All-in-one tool.
>> >>
>> >> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
>> >> _______________________________________________
>> >> Bitcoin-development mailing list
>> >> Bitcoin-development@lists•sourceforge.net
>> >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>>
>> --
>> Jeff Garzik
>> Bitcoin core developer and open source evangelist
>> BitPay, Inc. https://bitpay.com/
>
> --
> ----------------------------------------------------------------------------
> Troy Benjegerdes 'da hozer'
> hozer@hozed•org
> 7 elements earth::water::air::fire::mind::spirit::soul
> grid.coop
>
> Never pick a fight with someone who buys ink by the barrel,
> nor try buy a hacker who makes money by the megahash
>
>
> ------------------------------------------------------------------------------
> Flow-based real-time traffic analytics software. Cisco certified tool.
> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
> Customize your own dashboards, set traffic alerts and generate reports.
> Network behavioral analysis & security monitoring. All-in-one tool.
> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
Jorge Timón
http://freico.in/
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2014-03-02 19:08 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-02-09 18:04 [Bitcoin-development] Decentralized digital asset exchange with honest pricing and market depth 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
2014-02-14 5:20 ` Peter Todd
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox