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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jtimon@jtimon.cc>) id 1Y2edx-0000dR-Hf
for bitcoin-development@lists.sourceforge.net;
Sun, 21 Dec 2014 11:25:49 +0000
Received: from mail-wg0-f48.google.com ([74.125.82.48])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Y2edq-0004RS-Pj
for bitcoin-development@lists.sourceforge.net;
Sun, 21 Dec 2014 11:25:49 +0000
Received: by mail-wg0-f48.google.com with SMTP id y19so4707339wgg.35
for <bitcoin-development@lists.sourceforge.net>;
Sun, 21 Dec 2014 03:25:36 -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;
bh=EN8z1NenNTJpxl82YgCl+hPU0ZUPyyKDsS2HITa/A9Q=;
b=kFgPh3q7uytnYqSTbwljNJS50OQMZQDqTdFdheYhFP7EK01GawsafRwoejgBwuwKeu
/ZrvzamKBrbYEUy4bIBRy3fZQ6WpCnsJJJSP9gr7AacJF+72rXdOLJ5uXpN4iL8EX6qL
/tR/CGpeILPaECp2DjRiMVIOFpXNlnAmoeHwZb6K5uaUYsatV81y7Zc95Xhj2uNFmZeq
sZg5coPkrYC0KHAW6IRoBmRX3EIo1fG4cOOVoTnKIR1DbXHcONijFfzGZKIOy5XbyYaC
zx+ZXgbIfWsRlPQNnFswS9jvIsflmNUxpiLt4mCsCLvTUGqfqbIoE/OjERWSwcAqp2Tn
2D/w==
X-Gm-Message-State: ALoCoQl+uLv3TUjhLbJg2U2BqABMEskWqPo+w4YQGL4ScYJrTAv77a8eK1VtPs80Xhcvr7eoGLKm
MIME-Version: 1.0
X-Received: by 10.180.72.33 with SMTP id a1mr21857156wiv.18.1419161136697;
Sun, 21 Dec 2014 03:25:36 -0800 (PST)
Received: by 10.194.19.38 with HTTP; Sun, 21 Dec 2014 03:25:36 -0800 (PST)
X-Originating-IP: [85.59.61.159]
In-Reply-To: <20141221055220.GB8255@savin.petertodd.org>
References: <20141212090551.GA8259@muck>
<20141220144800.GA26284@savin.petertodd.org>
<CAOG=w-vrHPY1aCNndmoW9QyCh9XnWyv8uZn2PyjZ6rNg2MoSSw@mail.gmail.com>
<20141221055220.GB8255@savin.petertodd.org>
Date: Sun, 21 Dec 2014 12:25:36 +0100
Message-ID: <CABm2gDp0nw+z2NdaNDb8VQ=4e9Eh44mkzp9OePJyJfrbyfpy7A@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Peter Todd <pete@petertodd.org>
Content-Type: text/plain; charset=UTF-8
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: 1Y2edq-0004RS-Pj
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>,
Mark Friedenbach <mark@friedenbach.org>
Subject: Re: [Bitcoin-development] The relationship between
Proof-of-Publication and Anti-Replay Oracles
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: Sun, 21 Dec 2014 11:25:49 -0000
st
On Sun, Dec 21, 2014 at 6:52 AM, Peter Todd <pete@petertodd.org> wrote:
> On Sun, Dec 21, 2014 at 11:57:51AM +0800, Mark Friedenbach wrote:
>> I think you are trying to say something more specific / limited than that,
>> and I suggest you adjust your wording accordingly. Decentralized exchange
>> would be possible today with vanilla bitcoin using SIGHASH_SINGLE if only
>> the protocol supported multiple validated assets (which it could, but
>> doesn't). Rather straightforward further extensions to the protocol would
>> enable market participants to use a wider class of orders, as well as
>> enable the buyer rather than the seller to dictate order sizes via partial
>> redemption, as we demonstrate in our Freimarkets paper.
>
> Do you realise that all those Freimarket's uses are either based on
> proof-of-publication, or insecure due to sybil attacks?
So let's go through an example to see in which ways
non-proof-of-publication orders are "insecure".
Alice the seller wants to sell 1 unit of A for 100 units of B.
Bob is willing to pay up to 200 Bs for 1 A.
Let's assume a proof of publication system first, in which the
execution price is the mean between bid and ask.
Alice publishes her order.
Bob could publish his order at price 200 Bs and the order would
execute at 150 Bs.
But after seeing Alice's order he knows he doesn't need to pay that
much, so he publishes and order buying for 100 Bs.
Alice gets 100 Bs (what she signed she wanted) and Bob pays less than
he was wiling to pay, he pays 100 Bs. Everybody happy.
Now let's assume native assets and sighash_single.
Alice publishes her order (out of band, using various channels).
Bob could publish his order at price 200 Bs and then a miner would
execute at 100 Bs for Alice, at 200 Bs for Bob and pocket 100 Bs as
mining fees.
But after seeing Alice's order he knows he doesn't need to pay that
much, so he publishes and order buying for 100 Bs.
Again, Alice gets 100 Bs (what she signed she wanted) and Bob pays pays 100 Bs.
The main difference is that Alice didn't had to pay a fee to publish
her binding order.
Now let's try to articulate your concerns.
Your concern is that Carol, isolates Bob preventing him from seeing
Alice's order.
Then maybe Bob publishes his own order at 200 Bs.
If Carol sees both orders while preventing the other participants from
seeing them, she can build a tx in which Alice sells at 100, Bob buys
at 200, and Carol pockets the difference.
But...any smart miner will replace Carol's address with his own when
processing the trade, so Carol cannot win this way.
Another thing Carol can do is to buy the A herself for 100 Bs, leaving
Bob without them.
If Alice cares about Bob getting the deal instead of Carol she can do
two things:
1) Establish a direct communication channel with Bob
2) Move to a proof of publication system and start paying fees for
publishing binding orders.
So again, what's the advantage that proof-of-publication provides TO
ALICE so that she will be so eager to pay the higher costs to get the
same deal?
If this example is not enough to be able to explain the advantage of
proof-of-publication markets feel free to write a more complex one.
|
