path: root/77/58fce2495767a43cd69b354fb4dd0af01caeef

Return-Path: <luvb@hotmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 8F59F958
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu,  6 Apr 2017 12:30:59 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from APC01-PU1-obe.outbound.protection.outlook.com
	(mail-oln040092254076.outbound.protection.outlook.com [40.92.254.76])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 849601D9
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu,  6 Apr 2017 12:30:54 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com;
	s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; 
	bh=r6AsudJ7gP4sgx+hpuHsZYUtCvujNzETal1NCoT/R/E=;
	b=XnMW6yJsUc4rbAA50Y5KE/lQegCKf1zier4JR1nOMThqdlP5zVymmDlKeAg2oHnW5j/wy5f8BdJQy6FRaFldJZjvUmBqRtTh95dbYlW4WQDxk7CdaQG59nI2oYfjrTwk+WFK75KI8zQ0GOynqYmiR0Pp9u2In7LR7wevsvHWczT5feuYd/kLbuCQjXmowj0ludT1nKvSGtq325IsOWOaSUybBR8yz2DgsJRlrmGq7tP2HwYSUbK+Js7/fOJDeGOpaLwgr2DvJQ/40bFmYh28ICXDV8MzAQh9ruh/3flcxhn37dgo2/hUY9W3/BfPg441RLJ81+vXI1hBaN1zyAj23w==
Received: from SG2APC01FT049.eop-APC01.prod.protection.outlook.com
	(10.152.250.59) by SG2APC01HT214.eop-APC01.prod.protection.outlook.com
	(10.152.251.11) with Microsoft SMTP Server (version=TLS1_2,
	cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1005.5;
	Thu, 6 Apr 2017 12:30:51 +0000
Received: from SINPR04MB1949.apcprd04.prod.outlook.com (10.152.250.56) by
	SG2APC01FT049.mail.protection.outlook.com (10.152.251.207) with
	Microsoft SMTP Server (version=TLS1_2,
	cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1019.14 via
	Frontend Transport; Thu, 6 Apr 2017 12:30:51 +0000
Received: from SINPR04MB1949.apcprd04.prod.outlook.com
	([fe80::478:e8f6:541:de19]) by SINPR04MB1949.apcprd04.prod.outlook.com
	([fe80::478:e8f6:541:de19%18]) with mapi id 15.01.1019.014;
	Thu, 6 Apr 2017 12:30:51 +0000
From: Luv Khemani <luvb@hotmail.com>
To: Gregory Maxwell <greg@xiph.org>, Luv Khemani <luvb@hotmail.com>, "Bitcoin
	Protocol Discussion" <bitcoin-dev@lists.linuxfoundation.org>
Thread-Topic: [bitcoin-dev] BIP proposal: Inhibiting a covert attack on	the
	Bitcoin POW function
Thread-Index: AQHSrtGgZSg1ytegi06CfcuqjUFCXA==
Date: Thu, 6 Apr 2017 12:30:51 +0000
Message-ID: <SINPR04MB1949C5A408F7B6EC4D8D298BC20D0@SINPR04MB1949.apcprd04.prod.outlook.com>
References: <CAAS2fgR84898xD0nyq7ykJnB7qkdoCJYnFg6z5WZEUu0+-=mMA@mail.gmail.com>,
	<SINPR04MB19493BB6268FBC75F107C2BAC20D0@SINPR04MB1949.apcprd04.prod.outlook.com>
In-Reply-To: <SINPR04MB19493BB6268FBC75F107C2BAC20D0@SINPR04MB1949.apcprd04.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-slblob-mailprops: ajGO1BpsH8oi4qo+0ir54/DYcM6EPhV9TL2Cy5fYhiLjsY/Yb+0uwsDwHypnlukCL/3fRz0dLUQTqGbkGQPwVw1HMIenJeXayx8dXGWf9yndPCJb6V80PvHa2bIApLUDD0XsUO10T9g/8AIk9/eRuzqHXkx2nRfujrDInOn2av++Q6X9AjhrxaaEAPNfxS2hU5IgIF22K+yAiIzP0EUPDC/scz3OvEtbCGzNxGP9L7dhUkAihDt09DT1yOUQs05wHnsNsw6620FOI8ihx7Xzhipyv9wkPu60C+awcOIVNOwZoNet4Unxeuz1XTbgQHVy9gJX9Xw+ZY/pSIDgvEy2ddKuPmHXkQE3NULclINyCQkWWkOSAwtD2fzhmdV/Zug2jNAw4/Tdrjx7bcx+jVVzpBqz9iLrYxsMpfbanCSlzDw7oPld+5UbNsQX1gKK+yd5NjCJ3ixoh4towGnUd9OhcB6qg7vcTftD68SXyHmTUe14uxdH+Wk/ANes4SDp9+f+nRP5KVOyXBrZ92bu0uS3FXjDYAAJfdRqge/YVbE1aENOKX5Ov3euDkEX566wFVume8nC/ls7379hnzmRiOk71DJGcO5PJhWDc7ssua/ixO8++IYyi6l1Cz/7fsOcjZjavJqnYpDC7NlcqapoONTSQgy+eaYvEOIR/aOar+I4j+YxtmmC4rxZIyDTZeRRbNw00j0Lmf1sKwienAZy8tlTNC2M0Q6v+wnQ+ag3JTWu39VH7UeQbqCc1jt4QF33NTkg0x7QUB3VtPMMQmVhbuqnpUrcPFbGA086QdYbZ5jSAW4aZvbswbFrqDH4z1CLx5TBkSCaLISVuwhwifdI/axDi0H5c+3bKWVQvUhNGNqU2YU=
authentication-results: xiph.org; dkim=none (message not signed)
	header.d=none; xiph.org; dmarc=none action=none header.from=hotmail.com;
x-incomingtopheadermarker: OriginalChecksum:DCF057A21D1DECC5D452609005D644E5D11034FFD4DAF22BF66623F1DB0022D6;
	UpperCasedChecksum:C535D9D30C1B4309E04588147485EB210EE215A69787AF6B0F3B2C5D84EDD0A6;
	SizeAsReceived:9202; Count:43
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [UAQZ6PjPcynIO7Ob+hlkC0b2Qnv+QX9r]
x-microsoft-exchange-diagnostics: 1; SG2APC01HT214;
	5:x9pVP09RCKVUazuunsYkM8+d+dlAWiTJOdepWN2Nv6BoKqpuEY2qi91icMymzcPlvGr43IpUPEgQOYh/B4UdScNYb4EB/aPisE2Ph98LyuEFuelmIF8fWJrfCOFCNzfgRg81UnSgR3gek5C+cbniTw==;
	24:3u+BRK71/BEof3t2A1lXOFZyBLGlQqOLzMXwjCDBjKfvD79/xEzgd2a8VMiq2lc01Rmw6NSTx0u9XWfaP0CHE7Hn1tALiUw6ujYfZ1Nls/M=;
	7:SmMz95tsRsE5X2KKd5NbRUg8Fc/txFJmy9wbiCmVJF0lBQxsHSKypFwyaDoxdZBvqGGiTlrquDTDklvQg7LYJtRkm65Gz/2YGY18l/IjSO27Acgp8e+PZkWIcZXNC0/qlETIwS/KxUXx6AklaZASJaLWMiAqc+RkRoZL1npgExQX+YnRh7RB0qcgYC0wF8RuFTzT6cXMeAKTcecV3LokbU9M+uVTiDwZ5nwuzmFqLqEwYOeI4WIk4Jvmn2BD4S5YyveGAeHAJp7sQ8tBC2+M8BdDFZjzXhh6CgURjpLYbjhSfI5rXKNUmUVMyAIUe3uU
x-incomingheadercount: 43
x-eopattributedmessage: 0
x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(7070007)(98901004);
	DIR:OUT; SFP:1901; SCL:1; SRVR:SG2APC01HT214;
	H:SINPR04MB1949.apcprd04.prod.outlook.com; FPR:; SPF:None;
	LANG:en; 
x-ms-office365-filtering-correlation-id: d35f1679-95ba-416c-685b-08d47ce8c2fa
x-microsoft-antispam: UriScan:; BCL:0; PCL:0;
	RULEID:(22001)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(201702181274)(2017031322274)(1603101448)(1601125374)(1701031045);
	SRVR:SG2APC01HT214; 
x-ms-exchange-slblob-mailprops: sZBRelcYSIM9O2NH0QjizbYwxwckKKNOjVwOQMsQN6zS4HGxChWNKQj4rKFTHdRYESKX0+tWchUT+yjn3XI1KC3YZMX+SAp4ZHeJ0QYso3NE84qmq+ICt0oqYXs1R8WAjwCuAaQfb52UUFO44KGOL5c8PDRCJ3i9xEYJCFAy95K5OKkWcyI02bguAs30ds/wfv7Shc5M6HPRWwQou9RGPi2uirfrtgbsBuwI164CJ4lEZ/yfZddrdfTOympo9n6F7HMlSJTNJTnkklYpPjlfFVVel/WlaO4xlJsZ8d/5KPrIkW8XIB7CTnV/Bdkd2SNMPFfJh6WJCQw7R3+gViUhPw3AZTwAQAEqUdE1nDLYi6oRI0xpZZXHaWa8mTQWLX7iuNLjpAh43Vkg8h2EZ14k1kT7Mpuv/FWPjcSu9/SGDVW7vdyRPJpKRTMJEfd+I/qK7ThhY6et4uut9FhaHC81RGVR7KkbJcfxVUIfJUNI5OjLetluTl7meD8lMNaOGcqN0qR8EC9MtQEfPiuC/qx/IoylxnYSHKMPxk0DklE6Qovr4fxbv/S4ced2ASXWzGB1vJ38sZoaGz4mk0QqG6cwLVTmgIGOkRwarQV2WRE+TEg+y86V8/tqrmOovkNNMhzX93wGrMC+Irowwjv2HrezrFX9/0TYK8pthPsWl93Mwp9II0i1dKVXITJ4Axyj9xmgPZUthtfJt4tiIUfoKHWofhxdyCnJsmvlexs5vgXWVKgkdXdQzbhuBKZYCbF+zoXnVKvWTBv9IP9wEjlEh4OVT3kCJG33kCZaGHqdX3vs3Ck2j1RIsx+pguYRvBHYs+M+n9x1HX/BYFI=
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031);
	SRVR:SG2APC01HT214; BCL:0; PCL:0; RULEID:; SRVR:SG2APC01HT214; 
x-forefront-prvs: 02698DF457
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative;
	boundary="_000_SINPR04MB1949C5A408F7B6EC4D8D298BC20D0SINPR04MB1949apcp_"
MIME-Version: 1.0
X-OriginatorOrg: hotmail.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Apr 2017 12:30:51.0748 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SG2APC01HT214
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,LOTS_OF_MONEY,
	RCVD_IN_DNSWL_NONE,T_MONEY_PERCENT autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Thu, 06 Apr 2017 14:57:34 +0000
Subject: Re: [bitcoin-dev] BIP proposal: Inhibiting a covert attack
	on	the	Bitcoin POW function
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Apr 2017 12:30:59 -0000

--_000_SINPR04MB1949C5A408F7B6EC4D8D298BC20D0SINPR04MB1949apcp_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Just to add on to the ethical issue of blocking this.


If blocking the covert form of ASICBOOST is seen as unethical, then the sam=
e can be said about libsecp256k1, various client optimisations, Compactbloc=
ks.

All of which seek to reduce the efficacy of large miners and selfish mining=
.


I also find it very ironic that the author of the Selfish Mining paper who =
rang alarm bells about miner centralisation in 2013 is now opposing attempt=
s to reduce miner centralisation.


________________________________
From: bitcoin-dev-bounces@lists.linuxfoundation.org <bitcoin-dev-bounces@li=
sts.linuxfoundation.org> on behalf of Luv Khemani via bitcoin-dev <bitcoin-=
dev@lists.linuxfoundation.org>
Sent: Thursday, April 6, 2017 8:02 PM
To: Gregory Maxwell; Bitcoin Protocol Discussion
Subject: Re: [bitcoin-dev] BIP proposal: Inhibiting a covert attack on the =
Bitcoin POW function


Hi Greg


Great work in discovering this!


> A month ago I was explaining the attack on Bitcoin's SHA2 hashcash which
is exploited by ASICBOOST and the various steps which could be used to
block it in the network if it became a problem.


Could you elaborate on why you consider ASICBOOST to be an attack? Attack h=
ere implies ill-intent by the practitioner towards the network as a primary=
 motivating factor.

Personally, i see this as a miner acting in his self-interest and had i bee=
n a miner and knew about the covert method, i would use it too.

So while i'm no fan of Bitmain/Jihan, i do not condone the vilification he =
has received over the use of ASICBOOST to gain an edge.

I know i'm griping over semantics, but in the current political climate, th=
ey can be amplified by some to cause more drama than is healthy.


Other thoughts:


Several people have commented that blocking the use of this covert techniqu=
e is unethical or "wrong".
To quote Emin:

>Taking action to block this is similar to the government taking measures t=
o block Elon Musk's more efficient electric cars. Specifically prosecuting =
a chosen miner, in the current political climate, would send a terrible mes=
sage of absolute centralization in the hands of one particular developer gr=
oup, and it would severely damage Bitcoin mining and the coin's security.

This is a poor analogy and extremely misleading as the the basis for blocki=
ng has nothing to do with efficiency and more to do with the following:

1) Blocking upgrades to the protocol that are deemed by the vast majority o=
f the technical community/Bitcoin Businesses as being the best way forward

2) An advantage by a miner/group, especially one with majority hashrate is =
a threat to decentralisation and security of the network and it is entirely=
 justifiable for devs to nullify such an advantage.
You can see it as an arms race where miners are always finding ways to gain=
 an edge and devs trying to discover such edges and nullify them to level t=
he playing field.
This is how the game works and it should not be viewed in a political angle=
 or taken personally by either party. Miners are acting in their self-inter=
est and Devs are trying to secure the network and increase decentralisation=
.
Both are doing their job.

Just by revealing the info, you have effectively ensured the nullification =
of any edge enjoyed by miners using the covert technique in the medium to l=
ong term.
Either miners not using the technique will all start signalling for SegWit =
to nullify their competitors edge or they will procure hardware which has t=
he edge.

Given the threat to decentralisation, i also believe UASF will gain more mo=
mentum as users seek to protect the network from further miner centralisati=
on.


________________________________
From: bitcoin-dev-bounces@lists.linuxfoundation.org <bitcoin-dev-bounces@li=
sts.linuxfoundation.org> on behalf of Gregory Maxwell via bitcoin-dev <bitc=
oin-dev@lists.linuxfoundation.org>
Sent: Thursday, April 6, 2017 5:37 AM
To: Bitcoin Dev
Subject: [bitcoin-dev] BIP proposal: Inhibiting a covert attack on the Bitc=
oin POW function

A month ago I was explaining the attack on Bitcoin's SHA2 hashcash which
is exploited by ASICBOOST and the various steps which could be used to
block it in the network if it became a problem.

While most discussion of ASICBOOST has focused on the overt method
of implementing it, there also exists a covert method for using it.

As I explained one of the approaches to inhibit covert ASICBOOST I
realized that my words were pretty much also describing the SegWit
commitment structure.

The authors of the SegWit proposal made a specific effort to not be
incompatible with any mining system and, in particular, changed the
design at one point to accommodate mining chips with forced payout
addresses.

Had there been awareness of exploitation of this attack an effort
would have been made to avoid incompatibility-- simply to separate
concerns.  But the best methods of implementing the covert attack
are significantly incompatible with virtually any method of
extending Bitcoin's transaction capabilities; with the notable
exception of extension blocks (which have their own problems).

An incompatibility would go a long way to explain some of the
more inexplicable behavior from some parties in the mining
ecosystem so I began looking for supporting evidence.

Reverse engineering of a particular mining chip has demonstrated
conclusively that ASICBOOST has been implemented
in hardware.

On that basis, I offer the following BIP draft for discussion.
This proposal does not prevent the attack in general, but only
inhibits covert forms of it which are incompatible with
improvements to the Bitcoin protocol.

I hope that even those of us who would strongly prefer that
ASICBOOST be blocked completely can come together to support
a protective measure that separates concerns by inhibiting
the covert use of it that potentially blocks protocol improvements.

The specific activation height is something I currently don't have
a strong opinion, so I've left it unspecified for the moment.

<pre>
  BIP: TBD
  Layer: Consensus
  Title: Inhibiting a covert attack on the Bitcoin POW function
  Author: Greg Maxwell <greg@xiph.org>
  Status: Draft
  Type: Standards Track
  Created: 2016-04-05
  License: PD
</pre>

=3D=3DAbstract=3D=3D

This proposal inhibits the covert exploitation of a known
vulnerability in Bitcoin Proof of Work function.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.

=3D=3DMotivation=3D=3D

Due to a design oversight the Bitcoin proof of work function has a potentia=
l
attack which can allow an attacking miner to save up-to 30% of their energy
costs (though closer to 20% is more likely due to implementation overheads)=
.

Timo Hanke and Sergio Demian Lerner claim to hold a patent on this attack,
which they have so far not licensed for free and open use by the public.
They have been marketing their patent licenses under the trade-name
ASICBOOST.  The document takes no position on the validity or enforceabilit=
y
of the patent.

There are two major ways of exploiting the underlying vulnerability: One
obvious way which is highly detectable and is not in use on the network
today and a covert way which has significant interaction and potential
interference with the Bitcoin protocol.  The covert mechanism is not
easily detected except through its interference with the protocol.

In particular, the protocol interactions of the covert method can block the
implementation of virtuous improvements such as segregated witness.

Exploitation of this vulnerability could result in payoff of as much as
$100 million USD per year at the time this was written (Assuming at
50% hash-power miner was gaining a 30% power advantage and that mining
was otherwise at profit equilibrium).  This could have a phenomenal
centralizing effect by pushing mining out of profitability for all
other participants, and the income from secretly using this
optimization could be abused to significantly distort the Bitcoin
ecosystem in order to preserve the advantage.

Reverse engineering of a mining ASIC from a major manufacture has
revealed that it contains an undocumented, undisclosed ability
to make use of this attack. (The parties claiming to hold a
patent on this technique were completely unaware of this use.)

On the above basis the potential for covert exploitation of this
vulnerability and the resulting inequality in the mining process
and interference with useful improvements presents a clear and
present danger to the Bitcoin system which requires a response.

=3D=3DBackground=3D=3D

The general idea of this attack is that SHA2-256 is a merkle damgard hash
function which consumes 64 bytes of data at a time.

The Bitcoin mining process repeatedly hashes an 80-byte 'block header' whil=
e
incriminating a 32-bit nonce which is at the end of this header data. This
means that the processing of the header involves two runs of the compressio=
n
function run-- one that consumes the first 64 bytes of the header and a
second which processes the remaining 16 bytes and padding.

The initial 'message expansion' operations in each step of the SHA2-256
function operate exclusively on that step's 64-bytes of input with no
influence from prior data that entered the hash.

Because of this if a miner is able to prepare a block header with
multiple distinct first 64-byte chunks but identical 16-byte
second chunks they can reuse the computation of the initial
expansion for multiple trials. This reduces power consumption.

There are two broad ways of making use of this attack. The obvious
way is to try candidates with different version numbers.  Beyond
upsetting the soft-fork detection logic in Bitcoin nodes this has
little negative effect but it is highly conspicuous and easily
blocked.

The other method is based on the fact that the merkle root
committing to the transactions is contained in the first 64-bytes
except for the last 4 bytes of it.  If the miner finds multiple
candidate root values which have the same final 32-bit then they
can use the attack.

To find multiple roots with the same trailing 32-bits the miner can
use efficient collision finding mechanism which will find a match
with as little as 2^16 candidate roots expected, 2^24 operations to
find a 4-way hit, though low memory approaches require more
computation.

An obvious way to generate different candidates is to grind the
coinbase extra-nonce but for non-empty blocks each attempt will
require 13 or so additional sha2 runs which is very inefficient.

This inefficiency can be avoided by computing a sqrt number of
candidates of the left side of the hash tree (e.g. using extra
nonce grinding) then an additional sqrt number of candidates of
the right  side of the tree using transaction permutation or
substitution of a small number of transactions.  All combinations
of the left and right side are then combined with only a single
hashing operation virtually eliminating all tree related
overhead.

With this final optimization finding a 4-way collision with a
moderate amount of memory requires ~2^24 hashing operations
instead of the >2^28 operations that would be require for
extra-nonce  grinding which would substantially erode the
benefit of the attack.

It is this final optimization which this proposal blocks.

=3D=3DNew consensus rule=3D=3D

Beginning block X and until block Y the coinbase transaction of
each block MUST either contain a BIP-141 segwit commitment or a
correct WTXID commitment with ID 0xaa21a9ef.

(See BIP-141 "Commitment structure" for details)

Existing segwit using miners are automatically compatible with
this proposal. Non-segwit miners can become compatible by simply
including an additional output matching a default commitment
value returned as part of getblocktemplate.

Miners SHOULD NOT automatically discontinue the commitment
at the expiration height.

=3D=3DDiscussion=3D=3D

The commitment in the left side of the tree to all transactions
in the right side completely prevents the final sqrt speedup.

A stronger inhibition of the covert attack in the form of
requiring the least significant bits of the block timestamp
to be equal to a hash of the first 64-bytes of the header. This
would increase the collision space from 32 to 40 or more bits.
The root value could be required to meet a specific hash prefix
requirement in order to increase the computational work required
to try candidate roots. These change would be more disruptive and
there is no reason to believe that it is currently necessary.

The proposed rule automatically sunsets. If it is no longer needed
due to the introduction of stronger rules or the acceptance of the
version-grinding form then there would be no reason to continue
with this requirement.  If it is still useful at the expiration
time the rule can simply be extended with a new softfork that
sets longer date ranges.

This sun-setting avoids the accumulation of technical debt due
to retaining enforcement of this rule when it is no longer needed
without requiring a hard fork to remove it.

=3D=3D Overt attack =3D=3D

The non-covert form can be trivially blocked by requiring that
the header version match the coinbase transaction version.

This proposal does not include this block because this method
may become generally available without restriction in the future,
does not generally interfere with improvements in the protocol,
and because it is so easily detected that it could be blocked if
it becomes an issue in the future.

=3D=3DBackward compatibility=3D=3D


=3D=3DImplementation=3D=3D


=3D=3DAcknowledgments=3D=3D


=3D=3DCopyright=3D=3D

This document is placed in the public domain.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
bitcoin-dev -- Bitcoin Protocol Discussion - Linux Foundation<https://lists=
.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
lists.linuxfoundation.org
Bitcoin development and protocol discussion. This list is lightly moderated=
. - No offensive posts, no personal attacks. - Posts must concern developme=
nt of bitcoin ...




--_000_SINPR04MB1949C5A408F7B6EC4D8D298BC20D0SINPR04MB1949apcp_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<style type=3D"text/css" style=3D"display:none;"><!-- P {margin-top:0;margi=
n-bottom:0;} --></style>
</head>
<body dir=3D"ltr">
<div id=3D"divtagdefaultwrapper" style=3D"font-size:12pt;color:#000000;font=
-family:Calibri,Arial,Helvetica,sans-serif;" dir=3D"ltr">
<p>Just to add on to the ethical issue of blocking this.</p>
<p><br>
</p>
<p>If blocking the covert form of ASICBOOST is seen as unethical, then the =
same can be said about
<span>libsecp256k1, various client optimisations, Compactblocks.&nbsp;</spa=
n></p>
<p><span>All of which seek to reduce the efficacy&nbsp;of large miners and =
selfish mining.</span></p>
<p><span><br>
</span></p>
<p><span>I also find it very ironic that the author of the Selfish Mining p=
aper who rang alarm bells about miner centralisation in 2013 is now opposin=
g attempts to reduce miner centralisation.</span></p>
<br>
<br>
<div style=3D"color: rgb(0, 0, 0);">
<hr tabindex=3D"-1" style=3D"display:inline-block; width:98%">
<div id=3D"divRplyFwdMsg" dir=3D"ltr"><font face=3D"Calibri, sans-serif" co=
lor=3D"#000000" style=3D"font-size:11pt"><b>From:</b> bitcoin-dev-bounces@l=
ists.linuxfoundation.org &lt;bitcoin-dev-bounces@lists.linuxfoundation.org&=
gt; on behalf of Luv Khemani via bitcoin-dev &lt;bitcoin-dev@lists.linuxfou=
ndation.org&gt;<br>
<b>Sent:</b> Thursday, April 6, 2017 8:02 PM<br>
<b>To:</b> Gregory Maxwell; Bitcoin Protocol Discussion<br>
<b>Subject:</b> Re: [bitcoin-dev] BIP proposal: Inhibiting a covert attack =
on the Bitcoin POW function</font>
<div>&nbsp;</div>
</div>
<div>
<div id=3D"divtagdefaultwrapper" dir=3D"ltr" style=3D"font-size:12pt; color=
:#000000; font-family:Calibri,Arial,Helvetica,sans-serif">
<p>Hi Greg</p>
<p><br>
</p>
<p>Great work in discovering this!</p>
<p><br>
</p>
<p>&gt;&nbsp;<span style=3D"font-family:Calibri,Arial,Helvetica,sans-serif,=
&quot;Apple Color Emoji&quot;,&quot;Segoe UI Emoji&quot;,NotoColorEmoji,&qu=
ot;Segoe UI Symbol&quot;,&quot;Android Emoji&quot;,EmojiSymbols; font-size:=
13.3333px">A month ago I was explaining the attack on Bitcoin's SHA2 hashca=
sh which</span><br style=3D"font-family:Calibri,Arial,Helvetica,sans-serif,=
&quot;Apple Color Emoji&quot;,&quot;Segoe UI Emoji&quot;,NotoColorEmoji,&qu=
ot;Segoe UI Symbol&quot;,&quot;Android Emoji&quot;,EmojiSymbols; font-size:=
13.3333px">
<span style=3D"font-family:Calibri,Arial,Helvetica,sans-serif,&quot;Apple C=
olor Emoji&quot;,&quot;Segoe UI Emoji&quot;,NotoColorEmoji,&quot;Segoe UI S=
ymbol&quot;,&quot;Android Emoji&quot;,EmojiSymbols; font-size:13.3333px">is=
 exploited by ASICBOOST and the various steps which could be used to</span>=
<br style=3D"font-family:Calibri,Arial,Helvetica,sans-serif,&quot;Apple Col=
or Emoji&quot;,&quot;Segoe UI Emoji&quot;,NotoColorEmoji,&quot;Segoe UI Sym=
bol&quot;,&quot;Android Emoji&quot;,EmojiSymbols; font-size:13.3333px">
<span style=3D"font-family:Calibri,Arial,Helvetica,sans-serif,&quot;Apple C=
olor Emoji&quot;,&quot;Segoe UI Emoji&quot;,NotoColorEmoji,&quot;Segoe UI S=
ymbol&quot;,&quot;Android Emoji&quot;,EmojiSymbols; font-size:13.3333px">bl=
ock it in the network if it became a problem.</span></p>
<p><span style=3D"font-family:Calibri,Arial,Helvetica,sans-serif,&quot;Appl=
e Color Emoji&quot;,&quot;Segoe UI Emoji&quot;,NotoColorEmoji,&quot;Segoe U=
I Symbol&quot;,&quot;Android Emoji&quot;,EmojiSymbols; font-size:13.3333px"=
><br>
</span></p>
<p><span style=3D"font-family:Calibri,Arial,Helvetica,sans-serif,&quot;Appl=
e Color Emoji&quot;,&quot;Segoe UI Emoji&quot;,NotoColorEmoji,&quot;Segoe U=
I Symbol&quot;,&quot;Android Emoji&quot;,EmojiSymbols; font-size:16px">Coul=
d you elaborate on why you consider ASICBOOST to be an attack? Attack here
 implies ill-intent by the practitioner&nbsp;towards the network as a prima=
ry motivating factor.</span><br>
</p>
<p><span style=3D"font-family:Calibri,Arial,Helvetica,sans-serif,&quot;Appl=
e Color Emoji&quot;,&quot;Segoe UI Emoji&quot;,NotoColorEmoji,&quot;Segoe U=
I Symbol&quot;,&quot;Android Emoji&quot;,EmojiSymbols; font-size:16px">Pers=
onally, i see this as a miner acting in his self-interest and had i been a
 miner and knew about the covert method, i would use it too.</span></p>
<p>So while i'm no fan of Bitmain/Jihan, i do not condone the vilification =
he has received over the use of ASICBOOST to gain an edge.</p>
<p>I know i'm griping over semantics, but in the current political climate,=
 they can be amplified by some to cause more drama than is healthy.</p>
<p><br>
</p>
<p>Other thoughts:</p>
<p><br>
</p>
Several people have commented that blocking the use of this covert techniqu=
e is unethical or &quot;wrong&quot;.
<div>To quote Emin:</div>
<div><br>
</div>
<div><i></i><span><i>&gt;Taking action to block this is similar to the gove=
rnment taking measures to block Elon Musk's more efficient electric cars. S=
pecifically prosecuting a chosen miner, in the current political climate, w=
ould send a terrible message of absolute
 centralization in the hands of one particular developer group, and it woul=
d severely damage Bitcoin mining and the coin's security.</i></span><br>
<br>
This is a poor analogy and extremely misleading&nbsp;as the the basis for b=
locking has nothing to do with efficiency and more to do with the following=
:</div>
<div><br>
</div>
<div>1) Blocking upgrades to the protocol that are deemed by the vast major=
ity of the technical community/Bitcoin&nbsp;Businesses as being the best wa=
y forward</div>
<div><br>
</div>
<div>2) An advantage by a miner/group, especially one with majority hashrat=
e is a threat to decentralisation and security of the network and it is ent=
irely justifiable for devs to nullify such an advantage.</div>
<div>You can see&nbsp;it as&nbsp;an arms race where miners are always findi=
ng ways to gain an edge and devs trying to discover such edges and nullify =
them to level the playing field.&nbsp;</div>
<div>This is how the game works and it should not be viewed in a political =
angle or taken personally by either party. Miners are acting in their self-=
interest and Devs are trying to secure the network and increase decentralis=
ation.</div>
<div>Both are doing their job.</div>
<div><br>
</div>
<div>Just by revealing the info, you have effectively ensured the&nbsp;null=
ification of any edge enjoyed by miners&nbsp;using&nbsp;the covert techniqu=
e in the medium to long term.</div>
<div>Either miners not using the technique will all start signalling for Se=
gWit to nullify their competitors&nbsp;edge or they will procure hardware w=
hich has the edge.&nbsp;</div>
<div><br>
</div>
<div>Given the threat to decentralisation, i also believe UASF will gain mo=
re momentum as users seek to protect the network from further miner central=
isation.</div>
<div><br>
</div>
<div><br>
<div style=3D"color:rgb(0,0,0)">
<div>
<hr tabindex=3D"-1" style=3D"display:inline-block; width:98%">
<div id=3D"x_divRplyFwdMsg" dir=3D"ltr"><font face=3D"Calibri, sans-serif" =
color=3D"#000000" style=3D"font-size:11pt"><b>From:</b> bitcoin-dev-bounces=
@lists.linuxfoundation.org &lt;bitcoin-dev-bounces@lists.linuxfoundation.or=
g&gt; on behalf of Gregory Maxwell via bitcoin-dev
 &lt;bitcoin-dev@lists.linuxfoundation.org&gt;<br>
<b>Sent:</b> Thursday, April 6, 2017 5:37 AM<br>
<b>To:</b> Bitcoin Dev<br>
<b>Subject:</b> [bitcoin-dev] BIP proposal: Inhibiting a covert attack on t=
he Bitcoin POW function</font>
<div>&nbsp;</div>
</div>
</div>
<font size=3D"2"><span style=3D"font-size:10pt">
<div class=3D"PlainText">A month ago I was explaining the attack on Bitcoin=
's SHA2 hashcash which<br>
is exploited by ASICBOOST and the various steps which could be used to<br>
block it in the network if it became a problem.<br>
<br>
While most discussion of ASICBOOST has focused on the overt method<br>
of implementing it, there also exists a covert method for using it.<br>
<br>
As I explained one of the approaches to inhibit covert ASICBOOST I<br>
realized that my words were pretty much also describing the SegWit<br>
commitment structure.<br>
<br>
The authors of the SegWit proposal made a specific effort to not be<br>
incompatible with any mining system and, in particular, changed the<br>
design at one point to accommodate mining chips with forced payout<br>
addresses.<br>
<br>
Had there been awareness of exploitation of this attack an effort<br>
would have been made to avoid incompatibility-- simply to separate<br>
concerns.&nbsp; But the best methods of implementing the covert attack<br>
are significantly incompatible with virtually any method of<br>
extending Bitcoin's transaction capabilities; with the notable<br>
exception of extension blocks (which have their own problems).<br>
<br>
An incompatibility would go a long way to explain some of the<br>
more inexplicable behavior from some parties in the mining<br>
ecosystem so I began looking for supporting evidence.<br>
<br>
Reverse engineering of a particular mining chip has demonstrated<br>
conclusively that ASICBOOST has been implemented<br>
in hardware.<br>
<br>
On that basis, I offer the following BIP draft for discussion.<br>
This proposal does not prevent the attack in general, but only<br>
inhibits covert forms of it which are incompatible with<br>
improvements to the Bitcoin protocol.<br>
<br>
I hope that even those of us who would strongly prefer that<br>
ASICBOOST be blocked completely can come together to support<br>
a protective measure that separates concerns by inhibiting<br>
the covert use of it that potentially blocks protocol improvements.<br>
<br>
The specific activation height is something I currently don't have<br>
a strong opinion, so I've left it unspecified for the moment.<br>
<br>
&lt;pre&gt;<br>
&nbsp; BIP: TBD<br>
&nbsp; Layer: Consensus<br>
&nbsp; Title: Inhibiting a covert attack on the Bitcoin POW function<br>
&nbsp; Author: Greg Maxwell &lt;greg@xiph.org&gt;<br>
&nbsp; Status: Draft<br>
&nbsp; Type: Standards Track<br>
&nbsp; Created: 2016-04-05<br>
&nbsp; License: PD<br>
&lt;/pre&gt;<br>
<br>
=3D=3DAbstract=3D=3D<br>
<br>
This proposal inhibits the covert exploitation of a known<br>
vulnerability in Bitcoin Proof of Work function.<br>
<br>
The key words &quot;MUST&quot;, &quot;MUST NOT&quot;, &quot;REQUIRED&quot;,=
 &quot;SHALL&quot;, &quot;SHALL NOT&quot;,<br>
&quot;SHOULD&quot;, &quot;SHOULD NOT&quot;, &quot;RECOMMENDED&quot;, &quot;=
MAY&quot;, and &quot;OPTIONAL&quot; in this<br>
document are to be interpreted as described in RFC 2119.<br>
<br>
=3D=3DMotivation=3D=3D<br>
<br>
Due to a design oversight the Bitcoin proof of work function has a potentia=
l<br>
attack which can allow an attacking miner to save up-to 30% of their energy=
<br>
costs (though closer to 20% is more likely due to implementation overheads)=
.<br>
<br>
Timo Hanke and Sergio Demian Lerner claim to hold a patent on this attack,<=
br>
which they have so far not licensed for free and open use by the public.<br=
>
They have been marketing their patent licenses under the trade-name<br>
ASICBOOST.&nbsp; The document takes no position on the validity or enforcea=
bility<br>
of the patent.<br>
<br>
There are two major ways of exploiting the underlying vulnerability: One<br=
>
obvious way which is highly detectable and is not in use on the network<br>
today and a covert way which has significant interaction and potential<br>
interference with the Bitcoin protocol.&nbsp; The covert mechanism is not<b=
r>
easily detected except through its interference with the protocol.<br>
<br>
In particular, the protocol interactions of the covert method can block the=
<br>
implementation of virtuous improvements such as segregated witness.<br>
<br>
Exploitation of this vulnerability could result in payoff of as much as<br>
$100 million USD per year at the time this was written (Assuming at<br>
50% hash-power miner was gaining a 30% power advantage and that mining<br>
was otherwise at profit equilibrium).&nbsp; This could have a phenomenal<br=
>
centralizing effect by pushing mining out of profitability for all<br>
other participants, and the income from secretly using this<br>
optimization could be abused to significantly distort the Bitcoin<br>
ecosystem in order to preserve the advantage.<br>
<br>
Reverse engineering of a mining ASIC from a major manufacture has<br>
revealed that it contains an undocumented, undisclosed ability<br>
to make use of this attack. (The parties claiming to hold a<br>
patent on this technique were completely unaware of this use.)<br>
<br>
On the above basis the potential for covert exploitation of this<br>
vulnerability and the resulting inequality in the mining process<br>
and interference with useful improvements presents a clear and<br>
present danger to the Bitcoin system which requires a response.<br>
<br>
=3D=3DBackground=3D=3D<br>
<br>
The general idea of this attack is that SHA2-256 is a merkle damgard hash<b=
r>
function which consumes 64 bytes of data at a time.<br>
<br>
The Bitcoin mining process repeatedly hashes an 80-byte 'block header' whil=
e<br>
incriminating a 32-bit nonce which is at the end of this header data. This<=
br>
means that the processing of the header involves two runs of the compressio=
n<br>
function run-- one that consumes the first 64 bytes of the header and a<br>
second which processes the remaining 16 bytes and padding.<br>
<br>
The initial 'message expansion' operations in each step of the SHA2-256<br>
function operate exclusively on that step's 64-bytes of input with no<br>
influence from prior data that entered the hash.<br>
<br>
Because of this if a miner is able to prepare a block header with<br>
multiple distinct first 64-byte chunks but identical 16-byte<br>
second chunks they can reuse the computation of the initial<br>
expansion for multiple trials. This reduces power consumption.<br>
<br>
There are two broad ways of making use of this attack. The obvious<br>
way is to try candidates with different version numbers.&nbsp; Beyond<br>
upsetting the soft-fork detection logic in Bitcoin nodes this has<br>
little negative effect but it is highly conspicuous and easily<br>
blocked.<br>
<br>
The other method is based on the fact that the merkle root<br>
committing to the transactions is contained in the first 64-bytes<br>
except for the last 4 bytes of it.&nbsp; If the miner finds multiple<br>
candidate root values which have the same final 32-bit then they<br>
can use the attack.<br>
<br>
To find multiple roots with the same trailing 32-bits the miner can<br>
use efficient collision finding mechanism which will find a match<br>
with as little as 2^16 candidate roots expected, 2^24 operations to<br>
find a 4-way hit, though low memory approaches require more<br>
computation.<br>
<br>
An obvious way to generate different candidates is to grind the<br>
coinbase extra-nonce but for non-empty blocks each attempt will<br>
require 13 or so additional sha2 runs which is very inefficient.<br>
<br>
This inefficiency can be avoided by computing a sqrt number of<br>
candidates of the left side of the hash tree (e.g. using extra<br>
nonce grinding) then an additional sqrt number of candidates of<br>
the right&nbsp; side of the tree using transaction permutation or<br>
substitution of a small number of transactions.&nbsp; All combinations<br>
of the left and right side are then combined with only a single<br>
hashing operation virtually eliminating all tree related<br>
overhead.<br>
<br>
With this final optimization finding a 4-way collision with a<br>
moderate amount of memory requires ~2^24 hashing operations<br>
instead of the &gt;2^28 operations that would be require for<br>
extra-nonce&nbsp; grinding which would substantially erode the<br>
benefit of the attack.<br>
<br>
It is this final optimization which this proposal blocks.<br>
<br>
=3D=3DNew consensus rule=3D=3D<br>
<br>
Beginning block X and until block Y the coinbase transaction of<br>
each block MUST either contain a BIP-141 segwit commitment or a<br>
correct WTXID commitment with ID 0xaa21a9ef.<br>
<br>
(See BIP-141 &quot;Commitment structure&quot; for details)<br>
<br>
Existing segwit using miners are automatically compatible with<br>
this proposal. Non-segwit miners can become compatible by simply<br>
including an additional output matching a default commitment<br>
value returned as part of getblocktemplate.<br>
<br>
Miners SHOULD NOT automatically discontinue the commitment<br>
at the expiration height.<br>
<br>
=3D=3DDiscussion=3D=3D<br>
<br>
The commitment in the left side of the tree to all transactions<br>
in the right side completely prevents the final sqrt speedup.<br>
<br>
A stronger inhibition of the covert attack in the form of<br>
requiring the least significant bits of the block timestamp<br>
to be equal to a hash of the first 64-bytes of the header. This<br>
would increase the collision space from 32 to 40 or more bits.<br>
The root value could be required to meet a specific hash prefix<br>
requirement in order to increase the computational work required<br>
to try candidate roots. These change would be more disruptive and<br>
there is no reason to believe that it is currently necessary.<br>
<br>
The proposed rule automatically sunsets. If it is no longer needed<br>
due to the introduction of stronger rules or the acceptance of the<br>
version-grinding form then there would be no reason to continue<br>
with this requirement.&nbsp; If it is still useful at the expiration<br>
time the rule can simply be extended with a new softfork that<br>
sets longer date ranges.<br>
<br>
This sun-setting avoids the accumulation of technical debt due<br>
to retaining enforcement of this rule when it is no longer needed<br>
without requiring a hard fork to remove it.<br>
<br>
=3D=3D Overt attack =3D=3D<br>
<br>
The non-covert form can be trivially blocked by requiring that<br>
the header version match the coinbase transaction version.<br>
<br>
This proposal does not include this block because this method<br>
may become generally available without restriction in the future,<br>
does not generally interfere with improvements in the protocol,<br>
and because it is so easily detected that it could be blocked if<br>
it becomes an issue in the future.<br>
<br>
=3D=3DBackward compatibility=3D=3D<br>
<br>
<br>
=3D=3DImplementation=3D=3D<br>
<br>
<br>
=3D=3DAcknowledgments=3D=3D<br>
<br>
<br>
=3D=3DCopyright=3D=3D<br>
<br>
This document is placed in the public domain.<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
bitcoin-dev@lists.linuxfoundation.org<br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
id=3D"LPlnk519544" previewremoved=3D"true">https://lists.linuxfoundation.or=
g/mailman/listinfo/bitcoin-dev</a>
<div id=3D"LPBorder_GT_14914779708460.1275889041172491" style=3D"margin-bot=
tom:20px; overflow:auto; width:100%; text-indent:0px">
<table id=3D"LPContainer_14914779708430.6391837727881977" cellspacing=3D"0"=
 style=3D"width:90%; background-color:rgb(255,255,255); overflow:auto; padd=
ing-top:20px; padding-bottom:20px; margin-top:20px; border-top:1px dotted r=
gb(200,200,200); border-bottom:1px dotted rgb(200,200,200)">
<tbody>
<tr valign=3D"top" style=3D"border-spacing:0px">
<td id=3D"TextCell_14914779708440.3747157755215689" colspan=3D"2" style=3D"=
vertical-align: top; padding: 0px; display: table-cell; position: relative;=
">
<div id=3D"LPRemovePreviewContainer_14914779708440.6010049460283657"></div>
<div id=3D"LPTitle_14914779708440.5364067327594058" style=3D"top:0px; color=
:rgb(0,120,215); font-weight:normal; font-size:21px; font-family:wf_segoe-u=
i_light,&quot;Segoe UI Light&quot;,&quot;Segoe WP Light&quot;,&quot;Segoe U=
I&quot;,&quot;Segoe WP&quot;,Tahoma,Arial,&quot;Apple Color Emoji&quot;,&qu=
ot;Segoe UI Emoji&quot;,NotoColorEmoji,&quot;Segoe UI Symbol&quot;,&quot;An=
droid Emoji&quot;,EmojiSymbols,sans-serif; line-height:21px">
<a id=3D"LPUrlAnchor_14914779708450.35914654150375735" href=3D"https://list=
s.linuxfoundation.org/mailman/listinfo/bitcoin-dev" target=3D"_blank" style=
=3D"text-decoration:none">bitcoin-dev -- Bitcoin Protocol Discussion - Linu=
x Foundation</a></div>
<div id=3D"LPMetadata_14914779708450.7480051946749007" style=3D"margin:10px=
 0px 16px; color:rgb(102,102,102); font-weight:normal; font-family:wf_segoe=
-ui_normal,&quot;Segoe UI&quot;,&quot;Segoe WP&quot;,Tahoma,Arial,&quot;App=
le Color Emoji&quot;,&quot;Segoe UI Emoji&quot;,NotoColorEmoji,&quot;Segoe =
UI Symbol&quot;,&quot;Android Emoji&quot;,EmojiSymbols,sans-serif; font-siz=
e:14px; line-height:14px">
lists.linuxfoundation.org</div>
<div id=3D"LPDescription_14914779708450.8262054407680588" style=3D"display:=
block; color:rgb(102,102,102); font-weight:normal; font-family:wf_segoe-ui_=
normal,&quot;Segoe UI&quot;,&quot;Segoe WP&quot;,Tahoma,Arial,&quot;Apple C=
olor Emoji&quot;,&quot;Segoe UI Emoji&quot;,NotoColorEmoji,&quot;Segoe UI S=
ymbol&quot;,&quot;Android Emoji&quot;,EmojiSymbols,sans-serif; font-size:14=
px; line-height:20px; max-height:100px; overflow:hidden">
Bitcoin development and protocol discussion. This list is lightly moderated=
. - No offensive posts, no personal attacks. - Posts must concern developme=
nt of bitcoin ...</div>
</td>
</tr>
</tbody>
</table>
</div>
<br>
<br>
</div>
</span></font></div>
</div>
</div>
</div>
</div>
</div>
</body>
</html>

--_000_SINPR04MB1949C5A408F7B6EC4D8D298BC20D0SINPR04MB1949apcp_--