1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jtimon@monetize.io>) id 1WJRga-00079B-7N
for bitcoin-development@lists.sourceforge.net;
Fri, 28 Feb 2014 17:57:24 +0000
Received: from mail-la0-f43.google.com ([209.85.215.43])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WJRgY-0005AP-QN
for bitcoin-development@lists.sourceforge.net;
Fri, 28 Feb 2014 17:57:24 +0000
Received: by mail-la0-f43.google.com with SMTP id e16so2707511lan.16
for <bitcoin-development@lists.sourceforge.net>;
Fri, 28 Feb 2014 09:57:16 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type
:content-transfer-encoding;
bh=jCI/valhY/hFYq/C1O5lqv7CAtLPrMaWxfqjQcm2UAE=;
b=Hz6rGS+QDr2UtbhyvJ+1czgYAQHZQlkwTHgaY5YFIMD3S06NQrivZsLq45lP+PAp/m
BNFzPa2UFDQlK2McYiTzl+7LIIeV0uRS94sFhu6b3r1J/yZ9Bd/Pm1YbMDhnyzIkHTcX
gllRNfe2yJfhMSkeF1tDg9kFmrioMZMo8WsCNSez3nP2+Ycifh3WQf3CjlsDj4podqTN
rK61whrRpQc3PuLz2IzUmkHEntvDfCAVl6+Wo/FOnuRVdqaO+AdnZ3W0hJxmf4KpGI1B
ABBnfdA9niLgrB+P2ohnLDz1BORd+GKXWZo6QwbnRezMAyagR1ZdKHUBLL8NFsez3W/c
Kivg==
X-Gm-Message-State: ALoCoQm7xwkO6QNzIid+A6Gnrt9Gt3fCOGSq3WfNEhUFhA/gYmEOVh9mqSZo58Y1Goz4x+cUycAc
MIME-Version: 1.0
X-Received: by 10.112.144.35 with SMTP id sj3mr7207718lbb.44.1393609792647;
Fri, 28 Feb 2014 09:49:52 -0800 (PST)
Received: by 10.112.62.136 with HTTP; Fri, 28 Feb 2014 09:49:52 -0800 (PST)
X-Originating-IP: [108.193.6.130]
In-Reply-To: <20140228013719.GA5786@savin>
References: <20140209180458.GB20126@savin> <20140209204434.GA11488@savin>
<20140210193247.GC17359@savin> <20140211175919.GV3180@nl.grid.coop>
<20140214052159.GF31437@savin> <20140217054751.GY3180@nl.grid.coop>
<CAC1+kJNTq2sMbORAU-HBSpTVE3ohzsxHrxXw9JOXZp5ux32Gtw@mail.gmail.com>
<20140228013719.GA5786@savin>
Date: Fri, 28 Feb 2014 18:49:52 +0100
Message-ID: <CAC1+kJPL0NpzihMUfuOvEaE8LoKZehS0PbXFCVMu4_N5MJCJfA@mail.gmail.com>
From: =?ISO-8859-1?Q?Jorge_Tim=F3n?= <jtimon@monetize.io>
To: Peter Todd <pete@petertodd.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
X-Headers-End: 1WJRgY-0005AP-QN
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Decentralized digital asset exchange with
honest pricing and market depth
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Fri, 28 Feb 2014 17:57:24 -0000
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.
--=20
Jorge Tim=F3n
http://freico.in/
|
