+Return-Path: <tensiam@hotmail.com>

+Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org

+ [172.17.192.35])

+ by mail.linuxfoundation.org (Postfix) with ESMTPS id 50AF0D99

+ for <bitcoin-dev@lists.linuxfoundation.org>;

+ Tue, 16 Jul 2019 21:28:05 +0000 (UTC)

+X-Greylist: whitelisted by SQLgrey-1.7.6

+Received: from EUR03-DB5-obe.outbound.protection.outlook.com

+ (mail-oln040092071038.outbound.protection.outlook.com [40.92.71.38])

+ by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E6F28892

+ for <bitcoin-dev@lists.linuxfoundation.org>;

+ Tue, 16 Jul 2019 21:28:03 +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:X-MS-Exchange-SenderADCheck;

+ bh=xAxtJaFgSM7j/OJJwiDPRu9WbpkdBkjcXuRcwoks4xU=;

+ b=KiieSMBfOdsr5RQjUJOtlcSJ3jUAFecKcZi1ykynm32uTDH9rprfR0IyloXftbo3jgIj6Hqj3H4CQESLybodStWZh6g48NP2gi0jizvC1nF+wDgoEJ2gyAIEGdlevMTU+uzffndKNfwo9nWtiWMEqDEmdlGUd40lU/ZuB3lN4ciYm3bayv+jsRDEXRz0MwakSw4H3j39q0bq5rvq04Nhiy9glvlyDqTJpicMjwrrjrX39sHhj8SAylG7z2W8IkPYWvJzir/5cy3UdTkM6R6P3DANs2LNKXws/+MPgeAnpiigT0AaaeW1gsPVy14OV/TNPAQjz2P/gZDCWI0/kxhDyQ==

+Received: from AM5EUR03FT008.eop-EUR03.prod.protection.outlook.com

+ (10.152.16.51) by AM5EUR03HT239.eop-EUR03.prod.protection.outlook.com

+ (10.152.16.209) with Microsoft SMTP Server (version=TLS1_2,

+ cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2052.18;

+ Tue, 16 Jul 2019 21:28:02 +0000

+Received: from DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM (10.152.16.52) by

+ AM5EUR03FT008.mail.protection.outlook.com (10.152.16.123) with

+ Microsoft SMTP

+ Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id

+ 15.20.2052.18 via Frontend Transport; Tue, 16 Jul 2019 21:28:01 +0000

+Received: from DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM

+ ([fe80::c5ee:488e:37fb:4be5]) by

+ DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM

+ ([fe80::c5ee:488e:37fb:4be5%4]) with mapi id 15.20.2073.012;

+ Tue, 16 Jul 2019 21:28:01 +0000

+From: "Kenshiro []" <tensiam@hotmail.com>

+To: Oscar Lafarga <otech47@gmail.com>, Bitcoin Protocol Discussion

+ <bitcoin-dev@lists.linuxfoundation.org>

+Thread-Topic: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin

+Thread-Index: AQHVN+X3lOGGRtlWh0GqqwNnOoz9LabNvC2AgAAIwng=

+Date: Tue, 16 Jul 2019 21:28:01 +0000

+Message-ID: <DB6PR10MB1832257D676DDA7B4F55E658A6CE0@DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM>

+References: <DB6PR10MB183264613ED0D61F2FBC6524A6F30@DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM>,

+ <CAO7Y_eWDcFHWQMSL3h4Nz1a4FVsMq04YsGph5RR6khWzzdAyOg@mail.gmail.com>

+In-Reply-To: <CAO7Y_eWDcFHWQMSL3h4Nz1a4FVsMq04YsGph5RR6khWzzdAyOg@mail.gmail.com>

+Accept-Language: en-US, es-ES

+Content-Language: en-US

+X-MS-Has-Attach:

+X-MS-TNEF-Correlator:

+x-incomingtopheadermarker: OriginalChecksum:6DB4DFC73963C7B0DD91341B8F32F87D926DABD85236F6BE85AC9D9F0B13BB81;

+ UpperCasedChecksum:69E551AEC4AB3A9D11A665CD375E0649A40A8AAAE183E0872DA2567414821694;

+ SizeAsReceived:6901; Count:42

+x-tmn: [v9KVNw9LFshfb7O9SqLSoAN9R0C60YMJ]

+x-ms-publictraffictype: Email

+x-incomingheadercount: 42

+x-eopattributedmessage: 0

+x-microsoft-antispam: BCL:0; PCL:0;

+ RULEID:(2390118)(5050001)(7020095)(20181119110)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031322404)(2017031323274)(2017031324274)(1601125500)(1603101475)(1701031045);

+ SRVR:AM5EUR03HT239;

+x-ms-traffictypediagnostic: AM5EUR03HT239:

+x-ms-exchange-purlcount: 3

+x-microsoft-antispam-message-info: of85H1nZGLp/b8GB4bTo8ZGvBiSg20g6R51bakH/7CFtyljMKbUEolJDCZko48RhPEzbLWkHf4sFkt/NWbqTZDz9ppnDpOSxumQEYcrJbGJbALuAMQsQ4inSNt6BPi8GLzpxh2jnWFecMXeA96pPcMbkISSR5Pu5umNXz6B/We7Ih+3s6/9liS9DqyE6i0mJ

+Content-Type: multipart/alternative;

+ boundary="_000_DB6PR10MB1832257D676DDA7B4F55E658A6CE0DB6PR10MB1832EURP_"

+MIME-Version: 1.0

+X-OriginatorOrg: hotmail.com

+X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000

+X-MS-Exchange-CrossTenant-Network-Message-Id: 0a3b074d-e5cd-4cec-3fbd-08d70a347b17

+X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000

+X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jul 2019 21:28:01.4883 (UTC)

+X-MS-Exchange-CrossTenant-fromentityheader: Internet

+X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa

+X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5EUR03HT239

+X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,

+ DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,

+ RCVD_IN_DNSWL_NONE 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: Wed, 17 Jul 2019 07:52:04 +0000

+Subject: Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin

+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: Tue, 16 Jul 2019 21:28:05 -0000

+

+--_000_DB6PR10MB1832257D676DDA7B4F55E658A6CE0DB6PR10MB1832EURP_

+Content-Type: text/plain; charset="iso-8859-1"

+Content-Transfer-Encoding: quoted-printable

+

+Hi Oscar,

+

+Thank you for your answer. Just to clarify my proposal:

+

+1 - It's a full change to Proof of Stake protocol to avoid the energy waste=

+ and to prevent a 51% history rewrite attack, even if the attacker has 99% =

+of coins.

+

+2 - The hardcoded checkpoints could be set by each bitcoin node client, not=

+ only Bitcoin Core. No matter if the checkpoints are different, only that t=

+hey are frequent. They are there to prevent Long Range attacks. Checkpoints=

+ are public just like the rest of the software, they don't require any trus=

+t. A bad checkpoint would be detected by the community.

+

+3 - There are several PoS coins working just now and as far as I know they =

+don't have any problem. NXT coin implements the moving checkpoint system an=

+d others the hardcoded checkpoints.

+

+4 - In any given block, only one staker gets the authorization to create th=

+at block, so other stakers can't spam the network with many different block=

+s as they are illegal.

+

+5 - The block explorer is only required during a 51% attack, and only for n=

+odes that are updating blocks during the attack. Updated nodes are protecte=

+d thanks to the moving checkpoints.

+

+Regards,

+

+________________________________

+From: Oscar Lafarga <otech47@gmail.com>

+Sent: Tuesday, July 16, 2019 22:35

+To: Kenshiro []; Bitcoin Protocol Discussion

+Subject: Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin

+

+Hi Kenshiro,

+

+I don't think your proposal would require any changes to the Bitcoin Core i=

+mplementation. This system you describe seems like it would operate as an i=

+ndependent addition, rather than an alternative to the Proof of Work consen=

+sus code that runs within Bitcoin now. It introduces security risk in the s=

+election of block explorer and to the Bitcoin Core release dispatch system,=

+ reducing the trustlessness of the current network. Also, without the const=

+raints that PoW places on block creation, you increase the vector space for=

+ attacks since it is trivial to spam blocks to node on the network (see Syb=

+il attack<https://en.wikipedia.org/wiki/Sybil_attack#>).

+

+I believe many other software projects have tried similar checkpointing sch=

+emes that have resulted in hard forks or overall weakened consensus. I have=

+n't dug too deeply, but I'm not aware of any cases where these schemes acco=

+mplish anything useful to improve the bitcoin network.

+

+Best,

+

+On Tue, Jul 16, 2019 at 5:33 AM Kenshiro [] via bitcoin-dev <bitcoin-dev@li=

+sts.linuxfoundation.org<mailto:bitcoin-dev@lists.linuxfoundation.org>> wrot=

+e:

+

+Hi,

+

+

+After studying several Proof of Stake implementations I think it's not only=

+ an eco-friendly (and more ethical) alternative to Proof of Work, but corre=

+ctly implemented could be 100% secure against all 51% history rewrite attac=

+ks. Over a "standard" PoS protocol like PoS v3.0, only 2 extra improvements=

+ are required:

+

+

+- Hardcoded checkpoints: each Bitcoin Core release (each few months) should=

+ include a hardcoded checkpoint with the hash of the current block height i=

+n that moment. This simple measure protects the blockchain up to the last c=

+heckpoint, and prevents any Long-Range attack.

+

+

+- Moving checkpoints: the nodes only allow chain reorgs not deeper than N b=

+locks. If N is 10 blocks, then the nodes ignore any hard fork starting at a=

+ny block under nodeBlockHeight - N. This fully protects nodes that are onli=

+ne and updated. Nodes that are not fully updated need some extra rule to be=

+ protected between the last hardcoded checkpoint and the current blockchain=

+ height. This extra rule could be connecting to a block explorer to downloa=

+d the hash of the current block height, or ask some trusted source like a f=

+riend and enter the hash manually. After being fully updated, the user can =

+always check that he is in the correct chain checking with a block explorer=

+.

+

+

+Someone could have 99% of the coins and still would be unable to use the co=

+ins to do any history rewrite attack. The attacker could only slow down the=

+ network not creating his blocks, or censor transactions in his blocks.

+

+

+What do you think? :)

+

+

+Regards

+

+_______________________________________________

+bitcoin-dev mailing list

+bitcoin-dev@lists.linuxfoundation.org<mailto:bitcoin-dev@lists.linuxfoundat=

+ion.org>

+https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

+

+

+--

+Oscar Lafarga

+https://www.setlife.network

+<https://www.setdev.io/>

+

+--_000_DB6PR10MB1832257D676DDA7B4F55E658A6CE0DB6PR10MB1832EURP_

+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;margin-bo=

+ttom:0;} </style>

+</head>

+<body dir=3D"ltr">

+<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=

+ color: rgb(0, 0, 0);">

+Hi Oscar,</div>

+<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=

+ color: rgb(0, 0, 0);">

+<br>

+</div>

+<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=

+ color: rgb(0, 0, 0);">

+Thank you for your answer. Just to clarify my proposal:</div>

+<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=

+ color: rgb(0, 0, 0);">

+<br>

+</div>

+<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=

+ color: rgb(0, 0, 0);">

+1 - It's a full change to Proof of Stake protocol to avoid the energy waste=

+ and to prevent a 51% history rewrite attack, even if the attacker has 99% =

+of coins.</div>

+<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=

+ color: rgb(0, 0, 0);">

+<br>

+</div>

+<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=

+ color: rgb(0, 0, 0);">

+2 - The hardcoded checkpoints could be set by each bitcoin node client, not=

+ only Bitcoin Core. No matter if the checkpoints are different, only that t=

+hey are frequent. They are there to prevent Long Range attacks. Checkpoints=

+ are public just like the rest of

+ the software, they don't require any trust. A bad checkpoint would be dete=

+cted by the community.</div>

+<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=

+ color: rgb(0, 0, 0);">

+<br>

+</div>

+<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=

+ color: rgb(0, 0, 0);">

+3 - There are several PoS coins working just now and as far as I know they =

+don't have any problem. NXT coin implements the moving checkpoint system an=

+d others the hardcoded checkpoints.&nbsp;</div>

+<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=

+ color: rgb(0, 0, 0);">

+<br>

+</div>

+<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=

+ color: rgb(0, 0, 0);">

+4 - In any given block, only one staker gets the authorization to create th=

+at block, so other stakers can't spam the network with many different block=

+s as they are illegal.&nbsp;</div>

+<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=

+ color: rgb(0, 0, 0);">

+<br>

+</div>

+<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=

+ color: rgb(0, 0, 0);">

+5 - The block explorer is only required during a 51% attack, and only for n=

+odes that are updating blocks during the attack. Updated nodes are protecte=

+d thanks to the moving checkpoints.</div>

+<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=

+ color: rgb(0, 0, 0);">

+<br>

+</div>

+<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=

+ color: rgb(0, 0, 0);">

+Regards,</div>

+<div>

+<div id=3D"appendonsend"></div>

+<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=

+or:rgb(0,0,0)">

+<br>

+</div>

+<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> Oscar Lafarga &lt;ote=

+ch47@gmail.com&gt;<br>

+<b>Sent:</b> Tuesday, July 16, 2019 22:35<br>

+<b>To:</b> Kenshiro []; Bitcoin Protocol Discussion<br>

+<b>Subject:</b> Re: [bitcoin-dev] Secure Proof Of Stake implementation on B=

+itcoin</font>

+<div>&nbsp;</div>

+</div>

+<div>

+<div dir=3D"ltr">Hi Kenshiro,<br>

+<br>

+I don't think your proposal would require any changes to the Bitcoin Core i=

+mplementation. This system you describe seems like it would operate as an i=

+ndependent addition, rather than an alternative to the Proof of Work consen=

+sus code that runs within Bitcoin

+ now. It introduces security risk in the selection of block explorer and to=

+ the Bitcoin Core release dispatch system, reducing the trustlessness of th=

+e current network. Also, without the constraints that PoW places on block c=

+reation, you increase the vector

+ space for attacks since it is trivial to spam blocks to node on the networ=

+k (see

+<a href=3D"https://en.wikipedia.org/wiki/Sybil_attack#">Sybil attack</a>).<=

+br>

+<br>

+I believe many other software projects have tried similar checkpointing sch=

+emes that have resulted in hard forks or overall weakened consensus. I have=

+n't dug too deeply, but I'm not aware of any cases where these schemes acco=

+mplish anything useful to improve

+ the bitcoin network.<br>

+<br>

+Best,</div>

+<br>

+<div class=3D"x_gmail_quote">

+<div dir=3D"ltr" class=3D"x_gmail_attr">On Tue, Jul 16, 2019 at 5:33 AM Ken=

+shiro [] via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfound=

+ation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>

+</div>

+<blockquote class=3D"x_gmail_quote" style=3D"margin:0px 0px 0px 0.8ex; bord=

+er-left:1px solid rgb(204,204,204); padding-left:1ex">

+<div dir=3D"ltr">

+<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=

+or:rgb(0,0,0)">

+</div>

+<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=

+or:rgb(0,0,0)">

+<p style=3D"margin:0px; padding:0px 0px 0.25em; font-size:14px; font-family=

+:&quot;Noto Sans&quot;,Arial,sans-serif; color:rgb(26,26,27); background-co=

+lor:rgb(255,255,255)">

+Hi,</p>

+<p style=3D"margin:0px; padding:0.25em 0px; font-size:14px; font-family:&qu=

+ot;Noto Sans&quot;,Arial,sans-serif; color:rgb(26,26,27); background-color:=

+rgb(255,255,255)">

+<br>

+</p>

+<p style=3D"margin:0px; padding:0.25em 0px; font-size:14px; font-family:&qu=

+ot;Noto Sans&quot;,Arial,sans-serif; color:rgb(26,26,27); background-color:=

+rgb(255,255,255)">

+After studying several Proof of Stake implementations I think it's not only=

+ an eco-friendly (and more ethical) alternative to Proof of Work, but corre=

+ctly implemented could be 100% secure against all 51% history rewrite attac=

+ks. Over a &quot;standard&quot; PoS protocol

+ like PoS v3.0, only 2 extra improvements are required:</p>

+<p style=3D"margin:0px; padding:0.25em 0px; font-size:14px; font-family:&qu=

+ot;Noto Sans&quot;,Arial,sans-serif; color:rgb(26,26,27); background-color:=

+rgb(255,255,255)">

+<br>

+</p>

+<p style=3D"margin:0px; padding:0.25em 0px; font-size:14px; font-family:&qu=

+ot;Noto Sans&quot;,Arial,sans-serif; color:rgb(26,26,27); background-color:=

+rgb(255,255,255)">

+<span style=3D"margin:0px">- Hardcoded checkpoints:</span><span>&nbsp;</spa=

+n>each Bitcoin Core release (each few months) should include a hardcoded ch=

+eckpoint with the hash of the current block height in that moment. This sim=

+ple measure protects the blockchain up

+ to the last checkpoint, and prevents any Long-Range attack.</p>

+<p style=3D"margin:0px; padding:0.25em 0px; font-size:14px; font-family:&qu=

+ot;Noto Sans&quot;,Arial,sans-serif; color:rgb(26,26,27); background-color:=

+rgb(255,255,255)">

+<br>

+</p>

+<p style=3D"margin:0px; padding:0.25em 0px; font-size:14px; font-family:&qu=

+ot;Noto Sans&quot;,Arial,sans-serif; color:rgb(26,26,27); background-color:=

+rgb(255,255,255)">

+<span style=3D"margin:0px">- Moving checkpoints: the nodes only allow chain=

+ reorgs not deeper than N blocks. If N is 10 blocks, then the nodes ignore =

+any hard fork starting at any block under nodeBlockHeight - N. This fully p=

+rotects nodes that are online and

+ updated. Nodes that are not fully updated need some extra rule to be prote=

+cted between the last hardcoded checkpoint and the current blockchain heigh=

+t. This extra rule could be connecting to a block explorer to download the =

+hash of the current block height,

+ or ask some trusted source like a friend and enter the hash manually. Afte=

+r being fully updated, the user can always check that he is in the correct =

+chain checking with a block explorer.</span></p>

+<p style=3D"margin:0px; padding:0.25em 0px; font-size:14px; font-family:&qu=

+ot;Noto Sans&quot;,Arial,sans-serif; color:rgb(26,26,27); background-color:=

+rgb(255,255,255)">

+<span style=3D"color:rgb(26,26,27); font-family:&quot;Noto Sans&quot;,Arial=

+,sans-serif; font-size:14px"><br>

+</span></p>

+<p style=3D"margin:0px; padding:0.25em 0px; font-size:14px; font-family:&qu=

+ot;Noto Sans&quot;,Arial,sans-serif; color:rgb(26,26,27); background-color:=

+rgb(255,255,255)">

+<span style=3D"color:rgb(26,26,27); font-family:&quot;Noto Sans&quot;,Arial=

+,sans-serif; font-size:14px">Someone could have 99% of the coins and still =

+would be unable to use the coins to do any history rewrite attack. The atta=

+cker could only slow down the network not creating

+ his blocks, or censor transactions in his blocks.</span><br>

+</p>

+<p style=3D"margin:0px; padding:0.25em 0px; font-size:14px; font-family:&qu=

+ot;Noto Sans&quot;,Arial,sans-serif; color:rgb(26,26,27); background-color:=

+rgb(255,255,255)">

+<br>

+</p>

+<p style=3D"margin:0px; padding:0.25em 0px 0px; font-size:14px; font-family=

+:&quot;Noto Sans&quot;,Arial,sans-serif; color:rgb(26,26,27); background-co=

+lor:rgb(255,255,255)">

+What do you think? :)</p>

+<p style=3D"margin:0px; padding:0.25em 0px 0px; font-size:14px; font-family=

+:&quot;Noto Sans&quot;,Arial,sans-serif; color:rgb(26,26,27); background-co=

+lor:rgb(255,255,255)">

+<br>

+</p>

+<p style=3D"margin:0px; padding:0.25em 0px 0px; font-size:14px; font-family=

+:&quot;Noto Sans&quot;,Arial,sans-serif; color:rgb(26,26,27); background-co=

+lor:rgb(255,255,255)">

+Regards</p>

+<br>

+</div>

+</div>

+_______________________________________________<br>

+bitcoin-dev mailing list<br>

+<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=

+bitcoin-dev@lists.linuxfoundation.org</a><br>

+<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =

+rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=

+man/listinfo/bitcoin-dev</a><br>

+</blockquote>

+</div>

+<br clear=3D"all">

+<div><br>

+</div>

+-- <br>

+<div dir=3D"ltr" class=3D"x_gmail_signature">

+<div dir=3D"ltr">

+<div>

+<div dir=3D"ltr">

+<div>

+<div dir=3D"ltr">

+<div dir=3D"ltr">

+<div dir=3D"ltr"><span style=3D"font-size:12.8px">Oscar Lafarga</span>

+<div style=3D"font-size:12.8px"><a href=3D"https://www.setdev.io/" target=

+=3D"_blank">https://www.setlife.network<br>

+</a></div>

+</div>

+</div>

+</div>

+</div>

+</div>

+</div>

+</div>

+</div>

+</div>

+</div>

+</body>

+</html>

+

+--_000_DB6PR10MB1832257D676DDA7B4F55E658A6CE0DB6PR10MB1832EURP_--

+