path: root/b9/55ebf176f9eb1f5813065682e85e27d35316f7

Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
	helo=mx.sourceforge.net)
	by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <matthew@roberts.pm>) id 1Z3fCt-0003hi-1w
	for bitcoin-development@lists.sourceforge.net;
	Sat, 13 Jun 2015 06:46:19 +0000
X-ACL-Warn: 
Received: from mail-vn0-f42.google.com ([209.85.216.42])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1Z3fCr-0006H3-Dp
	for bitcoin-development@lists.sourceforge.net;
	Sat, 13 Jun 2015 06:46:19 +0000
Received: by vnbg62 with SMTP id g62so9038137vnb.4
	for <bitcoin-development@lists.sourceforge.net>;
	Fri, 12 Jun 2015 23:46:11 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:date:message-id:subject:from:to
	:content-type;
	bh=O3LoyPA9ZpyR9oMK/lN+PbhFCTRxYxXRiq5yP7Z4lDw=;
	b=RLY74Gjdis0X9bCb3G+uczY1lz5au18zibt4COqAiS4DBOwrLjd9JXak2IpYjTynsv
	5WizB3rpjAE/LCsL8/7vyaWm5jLRcrS8nhlqrqxsYRh025JNQzYg+xKCey12B89HS8HR
	JuVcOwrW5+9/qCAKU+5HqEB/pyJ9HqXgzJ0oUxmeDR5XnTCmPKksyR0s7tmsf20gUPgS
	zSXo7PNVf0I9rMXZuesycVyN2FpXxJb7pmgR0wb+t0cdW0VgY0Gy8N0aSXSEHBmmezPR
	D+i+i7RUQjLGc71wlhXMcamBU+S+WT1f1cqeg8sCa77X31uayxolXgw2DaIkmrO6hIfl
	5Z0A==
X-Gm-Message-State: ALoCoQmVS4vQXHkHT4oGXLz7/8CMrDP70HsTlm5e6sbVgi5voDnT9OycLQ8jVyHRsi+EfhVS90ut
MIME-Version: 1.0
X-Received: by 10.52.136.9 with SMTP id pw9mr22448672vdb.44.1434176437314;
	Fri, 12 Jun 2015 23:20:37 -0700 (PDT)
Received: by 10.31.191.205 with HTTP; Fri, 12 Jun 2015 23:20:37 -0700 (PDT)
X-Originating-IP: [121.216.12.250]
Date: Sat, 13 Jun 2015 16:20:37 +1000
Message-ID: <CAAEDBiGbEJhfOXTbk-bre-wAUTqWUzWO8vKapZrbuSMkt-hKoA@mail.gmail.com>
From: Matthew Roberts <matthew@roberts.pm>
To: bitcoin-development@lists.sourceforge.net
Content-Type: multipart/alternative; boundary=bcaec52e658b17823505186039e1
X-Spam-Score: 1.0 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	1.0 HTML_MESSAGE           BODY: HTML included in message
X-Headers-End: 1Z3fCr-0006H3-Dp
Subject: [Bitcoin-development] The timechain: an idea to solve TX
 malleability in smart contract protocols without requiring a fork.
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: Sat, 13 Jun 2015 06:46:19 -0000

--bcaec52e658b17823505186039e1
Content-Type: text/plain; charset=UTF-8

I've been tossing around an idea in my head that involves time-locked
encryption [0] and I wondered what the devs here think about it. In a
nutshell: the timechain is a serial chain of time-lock encrypted GPG keys
at N minute intervals (meaning that it requires N minutes to decrypt a
single link / key in the chain and each link must be fully decrypted before
decryption can start on the next link.) For those not aware of how
time-lock encryption works it goes something like this:

1. Choose some random, unique text - this is the initialisation vector or
IV.

2. Hash that text -> output.

3. Hash the output -> output.

4. Hash the output -> output.

5. ...

6. Process is repeated for N minutes.

7. Result is then used to generate encryption keys and the public key can
be used to time-lock encrypt an arbitrary number of plaintexts.

8. All intermediary results are discarded -- only the pub key is kept and
giving out the IV forces an individual to have to repeat the same amount of
work used to generate the encryption key.

What's interesting about this is that the keys can be generated in parallel
and then "stitched" together to form a single serial chain of keys. So
potentially, if a person had access to a GPU cluster then they could
generate a years worth of work in only 5 minutes. Now imagine if one were
to stitch these keys together into a chain of keys at five minute intervals
(a structure I refer to as the "timechain"): you could use this structure
to encrypt ECDSA keys which could then be used in multi-signature contract
schemes as a 100% decentralized, trustless way to execute refunds in
contract protocols.

Unexpected benefit: time-lock encryption can be used to build unbreakable
DACs.

Peter Todd has already done work on using Bitcoin to incentivize the
decryption process of time-lock encryption [1] but what he may not be aware
of is how important this process is for the construction of DACs.

Imagine a true peer-to-peer cryptocurrency exchange [2] that time-lock
encrypts a chain of ECDSA keys using the timechain and then sets up
contracts to pay a small portion of their fees "into" the ECDSA keys.
Essentially the exchange has created a DAC that pays its participants to
decrypt itself. This is the incentive for the decryption. The reason for
the incentive is that another chain of keys can be generate at 5 minute
intervals which can be used in contract protocols in place of nTimeLocked
refund transactions (which are vulnerable to transaction malleability.)

Sample contract using the timechain:

3 of 4 multi-sig: Owner, Owner, Recipient, Timelock

Pay N coins to recipient sequentially (micropayment channel) before [time /
date], otherwise fall back on timelock decrypted refund key to give full
leverage back to owner. This is how smart contracts would work using the
timechain for refunds (instead of nTimeLock TXs.)

Using the DAC, it might also be possible to force participants to reveal
their solutions to the decryption of the timechain (otherwise the first
person who starts on the chain would receive all the fees which isn't very
fair.) One way to do this would be to use the public key for the fee ECDSA
key as the IV used to generate the next key on the chain. To spend the fees
would therefore require revealing the public key if the fees were paid to a
pay-to-pub-key-hash transaction.

A further precaution would be to generate the pay to fee transaction in
such a way that the amount needs to be redeemed otherwise another
transaction would burn the coins. (I haven't worked out the full details
for this but similar schemes have been used successfully, for example in
BitHalo [3]. The Lightning Network [4] offers another potential solution.)
Perhaps a custom blockchain or sidechain could also be used to award coins
for successful (and timely solutions) but this is a subject for future work.

In conclusion: I have described a simple way to solve the TX malleability
problem in smart contract protocols without requiring a fork or relying on
a third-party escrow scheme to manage coins. My solution doesn't require
any trust beyond the initial need for the timechain to be generated in a
secure cluster and the solution remains secure so long as participants
stick to using future keys in the chain regardless of how far along
decryption is.

What do you think of the idea so far?

Obviously the biggest flaw here is that the integrity of a timechain can't
be known before-hand but if a timechain were to be generated securely by a
reputable party, the biggest benefit of using it is that it basically runs
itself: it does not require any third-party to manage its functionality and
the entity which originally generated it can completely disappear without
interrupting service. This could, for instance - allow companies to create
entirely secure and reliable systems that couldn't be hacked as the
behaviour of a timechain is deterministic. I think this is a huge
improvement over existing systems which require third-parties to be
perpetually trusted with managing key-pairs on their web servers.

Anyway, that's the basic idea. Let me know what you think.


Sources:

[0] http://www.gwern.net/Self-decrypting%20files

[1]
https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg05547.html

[2] http://www.uptrenda.com/uptrenda.pdf

[3] https://bithalo.org/wp-content/uploads/2014/06/whitepaper_twosided.pdf

[4] https://lightning.network/lightning-network-paper-DRAFT-0.5.pdf

--bcaec52e658b17823505186039e1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">


=09
=09
=09
=09


<p style=3D"margin-bottom:0cm">I&#39;ve been tossing around an idea in my
head that involves time-locked encryption [0] and I wondered what the
devs here think about it. In a nutshell: the timechain is a serial
chain of time-lock encrypted GPG keys at N minute intervals (meaning
that it requires N minutes to decrypt a single link / key in the
chain and each link must be fully decrypted before decryption can start on
the next link.) For those not aware of how time-lock encryption works
it goes something like this:</p>
<br>
<p style=3D"margin-bottom:0cm">1. Choose some random, unique text -
this is the initialisation vector or IV.</p>
<p style=3D"margin-bottom:0cm">2. Hash that text -&gt; output.</p>
<p style=3D"margin-bottom:0cm">3. Hash the output -&gt; output.</p>
<p style=3D"margin-bottom:0cm">4. Hash the output -&gt; output.</p>
<p style=3D"margin-bottom:0cm">5. ...</p>
<p style=3D"margin-bottom:0cm">6. Process is repeated for N minutes.</p>
<p style=3D"margin-bottom:0cm">7. Result is then used to generate
encryption keys and the public key can be used to time-lock encrypt
an arbitrary number of plaintexts.</p>
<p style=3D"margin-bottom:0cm">8. All intermediary results are
discarded -- only the pub key is kept and giving out the IV forces an
individual to have to repeat the same amount of work used to generate
the encryption key.</p>

<p style=3D"margin-bottom:0cm">What&#39;s interesting about this is that
the keys can be generated in parallel and then &quot;stitched&quot;
together to form a single serial chain of keys. So potentially, if a
person had access to a GPU cluster then they could generate a years worth o=
f work in only 5 minutes. Now imagine if one were to stitch these keys toge=
ther into a chain of
keys at five minute intervals (a structure I refer to as the
&quot;timechain&quot;): you could use this structure to
encrypt ECDSA keys which could then be used in multi-signature
contract schemes as a 100% decentralized, trustless way to execute
refunds in contract protocols.</p>

<p style=3D"margin-bottom:0cm">Unexpected benefit: time-lock encryption can=
 be
used to build unbreakable DACs.</p>

<p style=3D"margin-bottom:0cm">Peter Todd has already done work on
using Bitcoin to incentivize the decryption process of time-lock
encryption [1] but what he may not be aware of is how important this
process is for the construction of DACs.</p>

<p style=3D"margin-bottom:0cm">Imagine a true peer-to-peer
cryptocurrency exchange [2] that time-lock encrypts a chain of ECDSA
keys using the timechain and then sets up contracts to pay a small
portion of their fees &quot;into&quot; the ECDSA keys. Essentially
the exchange has created a DAC that pays its participants to decrypt itself=
. This is the incentive for the decryption. The reason for the
incentive is that another chain of keys can be generate at 5 minute
intervals which can be used in contract protocols in place of
nTimeLocked refund transactions (which are vulnerable to transaction
malleability.)</p>

<p style=3D"margin-bottom:0cm">Sample contract using the timechain:</p>
<p style=3D"margin-bottom:0cm">3 of 4 multi-sig: Owner, Owner,
Recipient, Timelock</p>
<p style=3D"margin-bottom:0cm">Pay N coins to recipient sequentially
(micropayment channel) before [time / date], otherwise fall back on
timelock decrypted refund key to give full leverage back to owner.
This is how smart contracts would work using the timechain for
refunds (instead of nTimeLock TXs.)</p>

<p style=3D"margin-bottom:0cm">Using the DAC, it might also be
possible to force participants to reveal their solutions to the
decryption of the timechain (otherwise the first person who starts on
the chain would receive all the fees which isn&#39;t very fair.) One way
to do this would be to use the public key for the fee ECDSA key as
the IV used to generate the next key on the chain. To spend the fees
would therefore require revealing the public key if the fees were
paid to a pay-to-pub-key-hash transaction.</p>

<p style=3D"margin-bottom:0cm">A further precaution would be to
generate the pay to fee transaction in such a way that the amount
needs to be redeemed otherwise another transaction would burn the
coins. (I haven&#39;t worked out the full details for this but similar sche=
mes
have been used successfully, for example in BitHalo [3]. The Lightning Netw=
ork [4] offers another potential solution.) Perhaps a
custom blockchain or sidechain could also be used to award coins for
successful (and timely solutions) but this is a subject for future
work.</p>

<p style=3D"margin-bottom:0cm">In conclusion: I have described a
simple way to solve the TX malleability problem in smart contract
protocols without requiring a fork or relying on a third-party escrow
scheme to manage coins. My solution doesn&#39;t require any trust beyond
the initial need for the timechain to be generated in a secure
cluster and the solution remains secure so long as participants stick
to using future keys in the chain regardless of how far along
decryption is.</p>

<br><p style=3D"margin-bottom:0cm">What do you think of the idea so far?</p=
>

<p style=3D"margin-bottom:0cm">Obviously the biggest flaw here is that
the integrity of a timechain can&#39;t be known before-hand but if a
timechain were to be generated securely by a reputable party, the
biggest benefit of using it is that it basically runs itself: it does
not require any third-party to manage its functionality and the
entity which originally generated it can completely disappear without
interrupting service. This could, for instance - allow companies to
create entirely secure and reliable systems that couldn&#39;t be hacked
as the behaviour of a timechain is deterministic. I think this is a
huge improvement over existing systems which require third-parties to
be perpetually trusted with managing key-pairs on their web servers.</p>

<p style=3D"margin-bottom:0cm">Anyway, that&#39;s the basic idea. Let me kn=
ow what you think.<br></p>

<p style=3D"margin-bottom:0cm"><br>Sources:</p>
<p style=3D"margin-bottom:0cm">[0]
<a href=3D"http://www.gwern.net/Self-decrypting%20files">http://www.gwern.n=
et/Self-decrypting%20files</a></p>
<p style=3D"margin-bottom:0cm">[1]
<a href=3D"https://www.mail-archive.com/bitcoin-development@lists.sourcefor=
ge.net/msg05547.html">https://www.mail-archive.com/bitcoin-development@list=
s.sourceforge.net/msg05547.html</a></p>
<p style=3D"margin-bottom:0cm">[2]
<a href=3D"http://www.uptrenda.com/uptrenda.pdf">http://www.uptrenda.com/up=
trenda.pdf</a></p>
<p style=3D"margin-bottom:0cm">[3]
<a href=3D"https://bithalo.org/wp-content/uploads/2014/06/whitepaper_twosid=
ed.pdf">https://bithalo.org/wp-content/uploads/2014/06/whitepaper_twosided.=
pdf</a></p><p style=3D"margin-bottom:0cm">[4] <a href=3D"https://lightning.=
network/lightning-network-paper-DRAFT-0.5.pdf">https://lightning.network/li=
ghtning-network-paper-DRAFT-0.5.pdf</a><br></p><p style=3D"margin-bottom:0c=
m"><br></p>

</div>

--bcaec52e658b17823505186039e1--