path: root/c3/d44c237930c2cec5cc6d8567e0b8fab05ebc9c

Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <etotheipi@gmail.com>) id 1WDcv6-0001ra-Rj
	for bitcoin-development@lists.sourceforge.net;
	Wed, 12 Feb 2014 16:44:20 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.216.51 as permitted sender)
	client-ip=209.85.216.51; envelope-from=etotheipi@gmail.com;
	helo=mail-qa0-f51.google.com; 
Received: from mail-qa0-f51.google.com ([209.85.216.51])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1WDcv4-000820-T9
	for bitcoin-development@lists.sourceforge.net;
	Wed, 12 Feb 2014 16:44:20 +0000
Received: by mail-qa0-f51.google.com with SMTP id f11so14099753qae.24
	for <bitcoin-development@lists.sourceforge.net>;
	Wed, 12 Feb 2014 08:44:13 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.224.30.69 with SMTP id t5mr69927801qac.30.1392223453294;
	Wed, 12 Feb 2014 08:44:13 -0800 (PST)
Received: by 10.229.66.67 with HTTP; Wed, 12 Feb 2014 08:44:13 -0800 (PST)
Received: by 10.229.66.67 with HTTP; Wed, 12 Feb 2014 08:44:13 -0800 (PST)
In-Reply-To: <CAJfRnm5pVA+gd3t=bXO188S4uwtUvx5F8V_bO_YV+74Ev4Q9jg@mail.gmail.com>
References: <CAPg+sBgPG+2AMbEHSRQNFn6FikbRzxkWduj5MSZLz-O6Wh940w@mail.gmail.com>
	<20140210030048.GB31925@savin>
	<CAH2=CKzNGN7mpe1NLtsLRNSszSD2ZNwjoAsaH40EvGtA5ezDeQ@mail.gmail.com>
	<CALf2ePyDTZ_43uBfS9-5znhTyBR-5H10SpZ=N-z1DBacM_rDgA@mail.gmail.com>
	<CAJfRnm5pVA+gd3t=bXO188S4uwtUvx5F8V_bO_YV+74Ev4Q9jg@mail.gmail.com>
Date: Wed, 12 Feb 2014 11:44:13 -0500
Message-ID: <CALf2ePwc=es-aDSeJO2DZwu9kyHwq9dcp5TrMAhN-dvYwNjy-w@mail.gmail.com>
From: Alan Reiner <etotheipi@gmail.com>
To: Allen Piscitello <allen.piscitello@gmail.com>
Content-Type: multipart/alternative; boundary=047d7bf0e80061b51004f23848d2
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(etotheipi[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1WDcv4-000820-T9
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with
	malleability
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: Wed, 12 Feb 2014 16:44:21 -0000

--047d7bf0e80061b51004f23848d2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Agreed.  I'm not suggesting that malleability shouldn't be fixed or isn't a
problem.  I would love to be able to leverage chained TX for Bitcoin
contracts.  But that in its current state it doesn't have to be complicated
to deal with  it.

Changing the protocol to use these static IDs is a pretty fundamental
change that would never happen in Bitcoin.   But they can still be useful
at the application level to mitigate these issues.

Sent from my overpriced smartphone
On Feb 12, 2014 11:38 AM, "Allen Piscitello" <allen.piscitello@gmail.com>
wrote:

> While that solution does work for many use cases, it does make it much
> harder to do anything needing chained transactions.  Granted, this is the
> short term solution for current implementations, but having a transaction
> identifier that does not change does open up other use cases.
>
> For example, Alice wants to send coins to a multisignature address with
> Bob, such that both parties are required to spend the coins.  Alice also
> requires for Bob to send coins to this address as well before they will
> proceed.  Alice cannot guarantee that Bob will cooperate (and vice versa)=
,
> so before she broadcasts the transaction to send to A+B, she sends Bob a
> transaction that spends her incoming transaction back to herself, but has=
 a
> time lock of far into the future.  Bob signs this, returns it to Alice, a=
nd
> she broadcasts her funding transaction.  At this point, Bob disappears,
> loses his key, or just decides to spite Alice and her coins are locked.
>  Since she has a refund transaction, she can broadcast it in a month and
> get her coins back.  Except her funding transaction has been modified suc=
h
> that the txhash is different, so her refund is now invalid.  She would ne=
ed
> Bob to issue a new refund as soon as her funding transaction hits the
> blockchain if it is modified, which defeats the point of the trustless
> refund transaction.
>
> Longer term it would be more ideal have a canonical identifier for the
> transaction before it even gets to the chain to support these use cases,
> even if wallets are able to properly identify the status of it's
> transactions.  Obviously this is a difficult problem to solve and cannot =
be
> implemented without breaking changes, but it would be a nice goal to be
> able to completely remove malleability.  There are other important use
> cases where having a unique identifier just for internal accounting is
> insufficient.
>
> -Allen
>
>
> On Wed, Feb 12, 2014 at 10:22 AM, Alan Reiner <etotheipi@gmail.com> wrote=
:
>
>> I think the solution is simply to encourage Bitcoin software developers
>> to design their software to use this static ID, instead of the full
>> transaction hash.    If MtGox had talked those IDs instead of the TX ID,
>> their software would've correctly identified the mutated transactions an=
d
>> there would be  no problem.
>>
>> Armory is slightly different, since it doesn't deal with the same stuff
>> as exchanges do.  But it didn't have any problems with malleability beca=
use
>> it doesn't track anything by ID, it only pays attention to whether input=
s
>> and outputs are related to your wallets.  It's not necessarily hard to d=
o
>> it this way, people just have to be aware of it.
>>
>> -Alan
>>
>> Sent from my overpriced smartphone
>> On Feb 12, 2014 10:15 AM, "Rune Kj=E6r Svendsen" <runesvend@gmail.com>
>> wrote:
>>
>>> Instead of trying to remove the possibility of transaction
>>> malleability, would it make sense to define a new, "canonical
>>> transaction hash/ID" (cTxID), which would be a hash of the part of the
>>> transaction data which we know is not malleable, and have clients use
>>> this cTxID internally, thus making the traditional transaction hash
>>> irrelevant for a client to function correctly?
>>>
>>> We already have a non-malleable transaction hash: the hash that is
>>> signed, ie. the transaction with each scriptSig replaced by the
>>> scriptPubKey it redeems. This could be the cTxID.
>>>
>>> Or is this simply a too fundamental change to the way bitcoin-qt (and
>>> all other clients) work in order to be feasible?
>>>
>>> As far as I can see, it completely solves the issue of not having a
>>> canonical ID for a transaction, but it also increases the
>>> computational requirements for a node. For one, as far as I can see,
>>> it requires the node to index all transactions, because in order to
>>> calculate a cTxID, it would be necessary to fetch all transactions
>>> referred to by the transaction in question, in order to pull in the
>>> scriptPubKeys that are redeemed.
>>>
>>>
>>> On Mon, Feb 10, 2014 at 4:00 AM, Peter Todd <pete@petertodd.org> wrote:
>>> > On Mon, Feb 10, 2014 at 12:33:02AM +0100, Pieter Wuille wrote:
>>> >> Hello all,
>>> >>
>>> >> it was something I planned to do since a long time, but with the
>>> >> recent related issues popping up, I finally got around to writing a
>>> >> BIP about how we can get rid of transaction malleability over time.
>>> >>
>>> >> The proposed document is here: https://gist.github.com/sipa/8907691
>>> >>
>>> >> I expect most rules to not be controversial. Maybe rules 1 and 3, as
>>> >> they require modifications to wallet software (Bitcoin Core 0.9 and
>>> >> BitcoinJ already implement it, though) and potentially invalidate so=
me
>>> >> script functionality. However, these new rules remain optional and
>>> >> controlled by an nVersion increase.
>>> >>
>>> >> Comments please!
>>> >
>>> > You should probably add making CHECKMULTISIG require the dummy value =
to
>>> > be exactly equal to OP_FALSE; verifying that in the transaction itsel=
f
>>> is
>>> > laborious. A more subtle example is we may want both CHECKSIG and
>>> > CHECKMULTISIG to fail the transaction if the signature is invalid but
>>> > not exactly equal to OP_FALSE; some transaction forms are significant=
ly
>>> > more compact if you can have failed signatures, but that's a source o=
f
>>> > malleability. (are there counter examples people can think of?)
>>> >
>>> >
>>> > But as I said on IRC, I'm a bit hesitant to bake in assumptions about
>>> > malleability when we have no solid idea if ECC signatures are or are
>>> not
>>> > malleable on a fundemental level; if "whack-a-mole" anti-malleability
>>> is
>>> > all we've got it could be ugly if a break is found. Similarly, we may
>>> > find we missed something, or some needed change makes the malleabilit=
y
>>> > rules difficult to work with for some new script type that is require=
d.
>>> >
>>> > I'd rather see a new CHECKSIG mode for the case where malleability
>>> > absolutely must be eliminated - certain multi-party protocols - and f=
ix
>>> > wallet software instead. (the malleability problems people see are
>>> > closely related to inability to handle double-spends and reorgs) But =
I
>>> > can easily see that being an impossible goal engineering wise...
>>> >
>>> > --
>>> > 'peter'[:-1]@petertodd.org
>>> > 0000000000000001465bc2730ffed7493d166d18d288f6cf15e8cdb5d4a3c7b1
>>> >
>>> >
>>> -----------------------------------------------------------------------=
-------
>>> > Managing the Performance of Cloud-Based Applications
>>> > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls=
.
>>> > Read the Whitepaper.
>>> >
>>> http://pubads.g.doubleclick.net/gampad/clk?id=3D121051231&iu=3D/4140/os=
tg.clktrk
>>> > _______________________________________________
>>> > Bitcoin-development mailing list
>>> > Bitcoin-development@lists.sourceforge.net
>>> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>> >
>>>
>>>
>>> -----------------------------------------------------------------------=
-------
>>> Android apps run on BlackBerry 10
>>> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
>>> Now with support for Jelly Bean, Bluetooth, Mapview and more.
>>> Get your Android app in front of a whole new audience.  Start now.
>>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=3D124407151&iu=3D/4140/os=
tg.clktrk
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>
>>
>> ------------------------------------------------------------------------=
------
>> Android apps run on BlackBerry 10
>> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
>> Now with support for Jelly Bean, Bluetooth, Mapview and more.
>> Get your Android app in front of a whole new audience.  Start now.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=3D124407151&iu=3D/4140/ost=
g.clktrk
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>

--047d7bf0e80061b51004f23848d2
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">Agreed.=A0 I&#39;m not suggesting that malleability shouldn&=
#39;t be fixed or isn&#39;t a problem.=A0 I would love to be able to levera=
ge chained TX for Bitcoin contracts.=A0 But that in its current state it do=
esn&#39;t have to be complicated to deal with=A0 it. </p>

<p dir=3D"ltr">Changing the protocol to use these static IDs is a pretty fu=
ndamental change that would never happen in Bitcoin.=A0=A0 But they can sti=
ll be useful at the application level to mitigate these issues. </p>
<p dir=3D"ltr">Sent from my overpriced smartphone </p>
<div class=3D"gmail_quote">On Feb 12, 2014 11:38 AM, &quot;Allen Piscitello=
&quot; &lt;<a href=3D"mailto:allen.piscitello@gmail.com">allen.piscitello@g=
mail.com</a>&gt; wrote:<br type=3D"attribution"><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex">
<div dir=3D"ltr">While that solution does work for many use cases, it does =
make it much harder to do anything needing chained transactions. =A0Granted=
, this is the short term solution for current implementations, but having a=
 transaction identifier that does not change does open up other use cases. =
=A0<div>

<br></div><div>For example, Alice wants to send coins to a multisignature a=
ddress with Bob, such that both parties are required to spend the coins. =
=A0Alice also requires for Bob to send coins to this address as well before=
 they will proceed. =A0Alice cannot guarantee that Bob will cooperate (and =
vice versa), so before she broadcasts the transaction to send to A+B, she s=
ends Bob a transaction that spends her incoming transaction back to herself=
, but has a time lock of far into the future. =A0Bob signs this, returns it=
 to Alice, and she broadcasts her funding transaction. =A0At this point, Bo=
b disappears, loses his key, or just decides to spite Alice and her coins a=
re locked. =A0Since she has a refund transaction, she can broadcast it in a=
 month and get her coins back. =A0Except her funding transaction has been m=
odified such that the txhash is different, so her refund is now invalid. =
=A0She would need Bob to issue a new refund as soon as her funding transact=
ion hits the blockchain if it is modified, which defeats the point of the t=
rustless refund transaction.</div>

<div><br></div><div>Longer term it would be more ideal have a canonical ide=
ntifier for the transaction before it even gets to the chain to support the=
se use cases, even if wallets are able to properly identify the status of i=
t&#39;s transactions. =A0Obviously this is a difficult problem to solve and=
 cannot be implemented without breaking changes, but it would be a nice goa=
l to be able to completely remove malleability. =A0There are other importan=
t use cases where having a unique identifier just for internal accounting i=
s insufficient.</div>

<div><br></div><div>-Allen</div></div><div class=3D"gmail_extra"><br><br><d=
iv class=3D"gmail_quote">On Wed, Feb 12, 2014 at 10:22 AM, Alan Reiner <spa=
n dir=3D"ltr">&lt;<a href=3D"mailto:etotheipi@gmail.com" target=3D"_blank">=
etotheipi@gmail.com</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><p dir=3D"ltr">I think the solution is simpl=
y to encourage Bitcoin software developers to design their software to use =
this static ID, instead of the full transaction hash.=A0=A0=A0 If MtGox had=
 talked those IDs instead of the TX ID, their software would&#39;ve correct=
ly identified the mutated transactions and there would be=A0 no problem.=A0=
=A0 </p>



<p dir=3D"ltr">Armory is slightly different, since it doesn&#39;t deal with=
 the same stuff as exchanges do.=A0 But it didn&#39;t have any problems wit=
h malleability because it doesn&#39;t track anything by ID, it only pays at=
tention to whether inputs and outputs are related to your wallets.=A0 It&#3=
9;s not necessarily hard to do it this way, people just have to be aware of=
 it. </p>



<p dir=3D"ltr">-Alan </p>
<p dir=3D"ltr">Sent from my overpriced smartphone </p><div><div>
<div class=3D"gmail_quote">On Feb 12, 2014 10:15 AM, &quot;Rune Kj=E6r Sven=
dsen&quot; &lt;<a href=3D"mailto:runesvend@gmail.com" target=3D"_blank">run=
esvend@gmail.com</a>&gt; wrote:<br type=3D"attribution"><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">


Instead of trying to remove the possibility of transaction<br>
malleability, would it make sense to define a new, &quot;canonical<br>
transaction hash/ID&quot; (cTxID), which would be a hash of the part of the=
<br>
transaction data which we know is not malleable, and have clients use<br>
this cTxID internally, thus making the traditional transaction hash<br>
irrelevant for a client to function correctly?<br>
<br>
We already have a non-malleable transaction hash: the hash that is<br>
signed, ie. the transaction with each scriptSig replaced by the<br>
scriptPubKey it redeems. This could be the cTxID.<br>
<br>
Or is this simply a too fundamental change to the way bitcoin-qt (and<br>
all other clients) work in order to be feasible?<br>
<br>
As far as I can see, it completely solves the issue of not having a<br>
canonical ID for a transaction, but it also increases the<br>
computational requirements for a node. For one, as far as I can see,<br>
it requires the node to index all transactions, because in order to<br>
calculate a cTxID, it would be necessary to fetch all transactions<br>
referred to by the transaction in question, in order to pull in the<br>
scriptPubKeys that are redeemed.<br>
<br>
<br>
On Mon, Feb 10, 2014 at 4:00 AM, Peter Todd &lt;<a href=3D"mailto:pete@pete=
rtodd.org" target=3D"_blank">pete@petertodd.org</a>&gt; wrote:<br>
&gt; On Mon, Feb 10, 2014 at 12:33:02AM +0100, Pieter Wuille wrote:<br>
&gt;&gt; Hello all,<br>
&gt;&gt;<br>
&gt;&gt; it was something I planned to do since a long time, but with the<b=
r>
&gt;&gt; recent related issues popping up, I finally got around to writing =
a<br>
&gt;&gt; BIP about how we can get rid of transaction malleability over time=
.<br>
&gt;&gt;<br>
&gt;&gt; The proposed document is here: <a href=3D"https://gist.github.com/=
sipa/8907691" target=3D"_blank">https://gist.github.com/sipa/8907691</a><br=
>
&gt;&gt;<br>
&gt;&gt; I expect most rules to not be controversial. Maybe rules 1 and 3, =
as<br>
&gt;&gt; they require modifications to wallet software (Bitcoin Core 0.9 an=
d<br>
&gt;&gt; BitcoinJ already implement it, though) and potentially invalidate =
some<br>
&gt;&gt; script functionality. However, these new rules remain optional and=
<br>
&gt;&gt; controlled by an nVersion increase.<br>
&gt;&gt;<br>
&gt;&gt; Comments please!<br>
&gt;<br>
&gt; You should probably add making CHECKMULTISIG require the dummy value t=
o<br>
&gt; be exactly equal to OP_FALSE; verifying that in the transaction itself=
 is<br>
&gt; laborious. A more subtle example is we may want both CHECKSIG and<br>
&gt; CHECKMULTISIG to fail the transaction if the signature is invalid but<=
br>
&gt; not exactly equal to OP_FALSE; some transaction forms are significantl=
y<br>
&gt; more compact if you can have failed signatures, but that&#39;s a sourc=
e of<br>
&gt; malleability. (are there counter examples people can think of?)<br>
&gt;<br>
&gt;<br>
&gt; But as I said on IRC, I&#39;m a bit hesitant to bake in assumptions ab=
out<br>
&gt; malleability when we have no solid idea if ECC signatures are or are n=
ot<br>
&gt; malleable on a fundemental level; if &quot;whack-a-mole&quot; anti-mal=
leability is<br>
&gt; all we&#39;ve got it could be ugly if a break is found. Similarly, we =
may<br>
&gt; find we missed something, or some needed change makes the malleability=
<br>
&gt; rules difficult to work with for some new script type that is required=
.<br>
&gt;<br>
&gt; I&#39;d rather see a new CHECKSIG mode for the case where malleability=
<br>
&gt; absolutely must be eliminated - certain multi-party protocols - and fi=
x<br>
&gt; wallet software instead. (the malleability problems people see are<br>
&gt; closely related to inability to handle double-spends and reorgs) But I=
<br>
&gt; can easily see that being an impossible goal engineering wise...<br>
&gt;<br>
&gt; --<br>
&gt; &#39;peter&#39;[:-1]@<a href=3D"http://petertodd.org" target=3D"_blank=
">petertodd.org</a><br>
&gt; 0000000000000001465bc2730ffed7493d166d18d288f6cf15e8cdb5d4a3c7b1<br>
&gt;<br>
&gt; ----------------------------------------------------------------------=
--------<br>
&gt; Managing the Performance of Cloud-Based Applications<br>
&gt; Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.=
<br>
&gt; Read the Whitepaper.<br>
&gt; <a href=3D"http://pubads.g.doubleclick.net/gampad/clk?id=3D121051231&a=
mp;iu=3D/4140/ostg.clktrk" target=3D"_blank">http://pubads.g.doubleclick.ne=
t/gampad/clk?id=3D121051231&amp;iu=3D/4140/ostg.clktrk</a><br>
&gt; _______________________________________________<br>
&gt; Bitcoin-development mailing list<br>
&gt; <a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D=
"_blank">Bitcoin-development@lists.sourceforge.net</a><br>
&gt; <a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-develo=
pment" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitco=
in-development</a><br>
&gt;<br>
<br>
---------------------------------------------------------------------------=
---<br>
Android apps run on BlackBerry 10<br>
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.<br>
Now with support for Jelly Bean, Bluetooth, Mapview and more.<br>
Get your Android app in front of a whole new audience. =A0Start now.<br>
<a href=3D"http://pubads.g.doubleclick.net/gampad/clk?id=3D124407151&amp;iu=
=3D/4140/ostg.clktrk" target=3D"_blank">http://pubads.g.doubleclick.net/gam=
pad/clk?id=3D124407151&amp;iu=3D/4140/ostg.clktrk</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D"_bla=
nk">Bitcoin-development@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</blockquote></div>
</div></div><br>-----------------------------------------------------------=
-------------------<br>
Android apps run on BlackBerry 10<br>
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.<br>
Now with support for Jelly Bean, Bluetooth, Mapview and more.<br>
Get your Android app in front of a whole new audience. =A0Start now.<br>
<a href=3D"http://pubads.g.doubleclick.net/gampad/clk?id=3D124407151&amp;iu=
=3D/4140/ostg.clktrk" target=3D"_blank">http://pubads.g.doubleclick.net/gam=
pad/clk?id=3D124407151&amp;iu=3D/4140/ostg.clktrk</a><br>__________________=
_____________________________<br>


Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D"_bla=
nk">Bitcoin-development@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></blockquote></div><br></div>
</blockquote></div>

--047d7bf0e80061b51004f23848d2--