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
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jtimon@jtimon.cc>) id 1Y2mM7-0005BO-8C
for bitcoin-development@lists.sourceforge.net;
Sun, 21 Dec 2014 19:39:55 +0000
Received: from mail-wi0-f174.google.com ([209.85.212.174])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Y2mM4-0001sr-HA
for bitcoin-development@lists.sourceforge.net;
Sun, 21 Dec 2014 19:39:55 +0000
Received: by mail-wi0-f174.google.com with SMTP id h11so6336878wiw.7
for <bitcoin-development@lists.sourceforge.net>;
Sun, 21 Dec 2014 11:39:46 -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=yfnicUkxLGvGNGD7q85EdZShPf1Cey7p0+BphJVfBDc=;
b=GKylqH5xp7ZVJVqzVGx9KW/Hfs14zadOPFdAG8yTmXyJyTyWQ54qYMoBHtLeaW3r+p
VLqkH2hr+FBTHidLyu3lFNHYFpU7gDXn0scWanlhG+jGeXlAP+gyUnr/beHEmhesoTcc
V16EBpVn3La1AEYUVGemeY1d/H8VUpZOLyhbzUMMMtTrt3qObeDlSriyBN2g6Zuya1wh
Bi18fvTlTdiQJB1tpgJt6nup/Ou4lUECNObt8MfP4HUUgic0bk92Npi2q9q8rs4zxPNk
C2BYtdM+fGZ+PCgAZmviNu4vLodC3pTxmJbAPNby8e/ho2StXig3sRrSs3sScmIdZhLo
yiSw==
X-Gm-Message-State: ALoCoQnV04AzmqZ7IEtipbXzKP8Wob1Xiacy1pyF9osNCL3uHbDI1z3Y1ALSi/hoBxihYRFHN8Vs
MIME-Version: 1.0
X-Received: by 10.180.98.138 with SMTP id ei10mr25151533wib.32.1419190786467;
Sun, 21 Dec 2014 11:39:46 -0800 (PST)
Received: by 10.194.19.38 with HTTP; Sun, 21 Dec 2014 11:39:46 -0800 (PST)
X-Originating-IP: [85.59.61.159]
In-Reply-To: <20141221160713.GD3927@savin.petertodd.org>
References: <20141212090551.GA8259@muck>
<20141220144800.GA26284@savin.petertodd.org>
<CAOG=w-vrHPY1aCNndmoW9QyCh9XnWyv8uZn2PyjZ6rNg2MoSSw@mail.gmail.com>
<20141221055220.GB8255@savin.petertodd.org>
<CABm2gDp0nw+z2NdaNDb8VQ=4e9Eh44mkzp9OePJyJfrbyfpy7A@mail.gmail.com>
<20141221160713.GD3927@savin.petertodd.org>
Date: Sun, 21 Dec 2014 20:39:46 +0100
Message-ID: <CABm2gDp8CphQf4awAft8S6whJ-_qxxfa4D9aeXFoXAiDLjcFQA@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Peter Todd <pete@petertodd.org>
Content-Type: text/plain; charset=UTF-8
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: 1Y2mM4-0001sr-HA
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 19:39:55 -0000
On Sun, Dec 21, 2014 at 5:07 PM, Peter Todd <pete@petertodd.org> wrote:
> On Sun, Dec 21, 2014 at 12:25:36PM +0100, Jorge Tim=C3=B3n wrote:
>> 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.
>
> Incidentally, SIGHASH_SINGLE is just as usable in embedded consensus;
> it's not specific to native assets.
>
>> 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?
>
> Like I said the last time this issue was discused on the mailing list,
> it's silly to think the seller of an asset starts off with a specific
> price they want to sell it at and is happy no matter what happens or how
> it gets fufilled. In the real world sellers and buyers want to know
> they're connected to actual sellers and buyers - not sybil attackers
> trying to shave off a margin for themselves - and are willing to pay a
> premium for that. Note all the hatred and vitrol directed towards
> high-frequency traders...
And like last time we discussed this on the mailing list my opinion
differs from yours.
You talk about "real world sellers and buyers" but ignore Alice the
seller and Bob the buyer in my example.
You failed to explain how sybil attackers (Carol) get all those
margins. In my example I claim miners get them, what am I missing?
How is the same example with a proof-of-publication market any better?
Miners can reorder the orders with proof of publication too.
If getting orders into mined blocks faster has an advantage miners can
charge privileged traders for privileged connections (just like it
happens today with "perfectly fair" centralized markets today that
feature the high-frequency trading you mention).
They could even charge for moving transactions around within the same
block if that has any effect on the execution rules.
I prefer that miners can get the difference between bids and asks
directly to compensate for their hashing power.
> How *much* of a premium is an interesting question, and depends a lot on
> the specific scenario. For instance I fully expect to see a whole
> variety of mediums become used for the proof-of-publication needed,
> ranging from directly on a major blockchain to minor/less secure
> blockchains like Bitmessage over treechains to centralized-but-audited
> proof-of-publication schemes - AKA centralized exchanges - to standard
> exchanges. Point is, the concept of proof-of-publication makes these
> tradeoffs and options available and lets end-users pick the right one
> for their needs.
The point is that there's more models for p2p markets beyond those
that require proof of publication for their orders, and you're
claiming that only those using proof of publication are secure.
That's incorrect.
> Accurate unbiased price information is worth money.
Can you define "Accurate unbiased price information"?
> In systems that
> allow third-parties to republish asset bids and offers we'll even see
> third-parties republishing bids and offers from less secure systems to
> more secure systems to get better price discovery.
Traders want to trade. The primary function of markets is exchange,
not price discovery.
>> 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.
>
> I gotta ask, have you actually run the design and tradeoffs of
> Friemarket's past actual finance types? I have, and it's remarkable how
> excited many of them are about cryptographically provable fair price
> discovery.
"Provably fair price discovery" is probably impossible. But I can
imagine how many people could get excited about such a technology.
Can you formally define what you mean by this?
You see, "fair" implies morality and therefore it's a very subjective
term, so it's not obvious to me what you may mean by that.
> --
> 'peter'[:-1]@petertodd.org
> 000000000000000002661192e72bdc83e6c8101371520159531301aa1437cc2c
|
