On Sun, Dec 21, 2014 at 12:51 PM, Peter Todd wrote:
> On Sun, Dec 21, 2014 at 06:10:47PM +, Adam Back wrote:
> > Yes you could for example define a new rule that two signatures
> > (double-spend) authorises something - eg miners to take funds. (And
> > this would work with existing ECDSA addr
On Sat, Dec 20, 2014 at 09:48:01AM -0500, Peter Todd wrote:
Andrew Miller asked me to publish the following to the mailing list on his
behalf: (https://twitter.com/socrates1024/status/546819355565391872)
One of the main points in this note is that you can use a
"proof-of-publication" system to im
On Sun, Dec 21, 2014 at 5:07 PM, Peter Todd wrote:
> On Sun, Dec 21, 2014 at 12:25:36PM +0100, Jorge Timón 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
On Sun, Dec 21, 2014 at 06:10:47PM +, Adam Back wrote:
> Yes you could for example define a new rule that two signatures
> (double-spend) authorises something - eg miners to take funds. (And
> this would work with existing ECDSA addresses & unrestricted R-value
> choices).
>
> I wasnt really m
Yes you could for example define a new rule that two signatures
(double-spend) authorises something - eg miners to take funds. (And
this would work with existing ECDSA addresses & unrestricted R-value
choices).
I wasnt really making a point other than an aside that it maybe is
sort-of possible to
On Sun, Dec 21, 2014 at 12:25:36PM +0100, Jorge Timón 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
I could play the game where I say, "You don't understand," and, like you,
not address any of your points.
First, there is no dependence on implementation in my arguments. If a
system can prevent replay by some set of rules, it necessarily must be able
to answer the question if a message is publis
On Sun, Dec 21, 2014 at 03:11:32PM +0800, Mark Friedenbach wrote:
> On Sun, Dec 21, 2014 at 3:01 PM, Peter Todd wrote:
>
> > Right, so Freimarkets is deliberately insecure.
> >
>
> Please define your terms, particularly what your security requirements are
> here. In the architecture we created u
On Sun, Dec 21, 2014 at 10:01:37AM +, Adam Back wrote:
> On 20 December 2014 at 14:48, Peter Todd wrote:
> > We need the following primitives operating on message m, pubkey p, and a
> > valid signature sig1 for m, p:
> >
> > AntiReplaySign(m, p, sig1) -> sig2
> > VerifyAntiReplaySig(m,
On Sun, Dec 21, 2014 at 07:49:17AM -0600, paul snow wrote:
> On Dec 20, 2014 8:49 AM, "Peter Todd" wrote:
> >
> > However the converse is not possible: anti-replay cannot be used to
> implement proof-of-publication. Knowing that no conflicting message exists
> says nothing about who be in posessio
On Dec 20, 2014 8:49 AM, "Peter Todd" wrote:
>
> However the converse is not possible: anti-replay cannot be used to
implement proof-of-publication. Knowing that no conflicting message exists
says nothing about who be in posession of that message, or indeed, any
message at all. Thus anti-replay is
st
On Sun, Dec 21, 2014 at 6:52 AM, Peter Todd 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
On 20 December 2014 at 14:48, Peter Todd wrote:
> We need the following primitives operating on message m, pubkey p, and a
> valid signature sig1 for m, p:
>
> AntiReplaySign(m, p, sig1) -> sig2
> VerifyAntiReplaySig(m, p, sig2) -> True or False
>
> Additionally once AntiReplaySign() has b
13 matches
Mail list logo
