path: root/40/d9b401b6a5656fdfd35c16e3b36d83d534a590

Return-Path: <angus@toaster.cc>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 14407C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 19 Oct 2022 13:49:58 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id EFA2041793
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 19 Oct 2022 13:49:56 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org EFA2041793
Authentication-Results: smtp4.osuosl.org; dkim=pass (2048-bit key,
 unprotected) header.d=toaster.cc header.i=@toaster.cc header.a=rsa-sha256
 header.s=protonmail3 header.b=2Vaj8BzK
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level: 
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001,
 SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id Riel9DDiVM6F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 19 Oct 2022 13:49:55 +0000 (UTC)
X-Greylist: delayed 00:08:52 by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org F0DE541736
Received: from mail-4321.protonmail.ch (mail-4321.protonmail.ch [185.70.43.21])
 by smtp4.osuosl.org (Postfix) with ESMTPS id F0DE541736
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 19 Oct 2022 13:49:53 +0000 (UTC)
Date: Wed, 19 Oct 2022 13:40:35 +0000
Authentication-Results: mail-4321.protonmail.ch;
 dkim=pass (2048-bit key) header.d=toaster.cc header.i=@toaster.cc
 header.b="2Vaj8BzK"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toaster.cc;
 s=protonmail3; t=1666186846; x=1666446046;
 bh=11vHVRPUvgbeoQd1iifGgO7Xiu0m7F+jnzFq/4iWTnQ=;
 h=Date:To:From:Subject:Message-ID:In-Reply-To:References:
 Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
 Message-ID;
 b=2Vaj8BzK4zK9SRq5e8aSpW1GWyTo8g8agGXMUl/XV7jrr7w6zxX8oEGXhyOpg/wvM
 W6+8Wszafo0vad7JjmGQisedTXKEmCBhE6t7UjttlW1l2sWMvTSSrWIT9HQbOoZ+dJ
 212H61iXodyatokSsrBUx/j98KK2YZytq6txzzdULo2SDMgZj97k0KBctFKMX7YYEG
 5pIQ7f22wyJjU6bd+Z6nlszs6HOY3Uwli/NKe91eG9BfMdP+fs7XbTJdvc35czwUZB
 wgPWb+TRAte8qdvkc190ua2DsDaXm/Zwmi11GusgqlwyuReOtr6BnZYaBZ0ACvjZ9j
 1mazHy40eCr1g==
To: mm-studios <mm@mm-studios.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: angus <angus@toaster.cc>
Message-ID: <WTqdd9tnmdk1Pww8LuBjgyeiHh-wxZT8zNJ8fShakKG1-ObkKQsSy3eRBo3MdfcuBZAducykgUxYMwDyp8ywBsfREMMJXhLnWutF0nDVr6Y=@toaster.cc>
In-Reply-To: <mOBAWIbHTgkSrCJ9IEBJgArqUNYcNSDQawhUzaiYyliaPDQT_YDfI5CLoDPZgEt43mePJof-CJfxzFxgXMUe6ONDJ4j5Bzk1QGjd50S9gb8=@mm-studios.com>
References: <mOBAWIbHTgkSrCJ9IEBJgArqUNYcNSDQawhUzaiYyliaPDQT_YDfI5CLoDPZgEt43mePJof-CJfxzFxgXMUe6ONDJ4j5Bzk1QGjd50S9gb8=@mm-studios.com>
Feedback-ID: 10272201:user:proton
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pgp-signature";
 micalg=pgp-sha512;
 boundary="------e337235ccd9c55017fd2accb1649b99d499b1b9749b47cf4231f6b2d5bb52d44";
 charset=utf-8
X-Mailman-Approved-At: Wed, 19 Oct 2022 13:52:30 +0000
Subject: Re: [bitcoin-dev] brickchain
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
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: Wed, 19 Oct 2022 13:49:58 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------e337235ccd9c55017fd2accb1649b99d499b1b9749b47cf4231f6b2d5bb52d44
Content-Type: multipart/mixed;boundary=---------------------8aa1a726925524c8a7e9d24d4d370652

-----------------------8aa1a726925524c8a7e9d24d4d370652
Content-Type: multipart/alternative;boundary=---------------------57ce92a6886c839a698089bb95fb80cb

-----------------------57ce92a6886c839a698089bb95fb80cb
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;charset=utf-8



> Let's allow a miner to include transactions until the block is filled, l=
et's call this structure (coining a new term 'Brick'), B0. [brick=3Dblock =
that doesn't meet the difficulty rule and is filled of tx to its full capa=
city]
> Since PoW hashing is continuously active, Brick B0 would have a nonce co=
rresponding to a minimum numeric value of its hash found until it got fill=
ed.


So, if I'm understanding right, this amounts to "reduce difficulty require=
d for a block ('brick') to be valid if the mempool contains more than 1 bl=
ock's worth of transactions so we get transactions confirmed faster" using=
 'bricks' as short-lived sidechains that get merged into blocks?

This would have the same fundamental problem as just making the max blocks=
ize bigger - it increases the rate of growth of storage required for a ful=
l node, because you're allowing blocks/bricks to be created faster, so the=
re will be more confirmed transactions to store in a given time window tha=
n under current Bitcoin rules.

Bitcoin doesn't take the size of the mempool into account when adjusting t=
he difficulty because the time-between-blocks is 'more important' than avo=
iding congestion where transactions take ages to get into a block. The fee=
 mechanism in part allows users to decide how urgently they want their tx =
to get confirmed, and high fees when there is congestion also disincentivi=
ses others from transacting at all, which helps arrest mempool growth.

I'd imagine we'd also see a 'highway widening' effect with this kind of pr=
oposal - if you increase the tx volume Bitcoin can settle in a given time,=
 that will quickly be used up by more people transacting until we're back =
at a congested state again.

> Fully filled brick B0, with a hash that doesn't meet the difficulty rule=
, would be broadcasted and nodes would have it on in a separate fork as us=
ual.


How do we know if the hash the miner does find for a brick was their 'best=
 effort' and they're not just being lazy? There's an element of luck in th=
e best hash a miner can find, sometimes it takes a long time to meet the d=
ifficulty requirement and sometimes it happens almost at instantly.

How would we know how 'busy' the mempool was at the time a brick from mont=
hs or years ago was mined?

Nodes have to be able to run through the entire history of the blockchain =
and check everything is valid. They have to do this using only the previou=
s blocks they've already validated - they won't have historical snapshots =
of the mempool (they'll build and mutate a UTXO set, but that's different)=
. Transactions don't contain a 'created-at' time that you could compare to=
 the block's creation time (and if they did, you probably couldn't trust i=
t).

With the current system, Nodes can calculate what the difficulty should be=
 for every block based on those previous blocks' times and difficulties - =
but how would you know an old brick was valid if its difficulty was low bu=
t at the time the mempool was busy, vs. getting a fraudulent brick that is=
 actually invalid because there isn't enough work in it? You can't solve t=
his by adding some mempoolsize field to bricks, as you'd have to blindly t=
rust miners not to lie about them.

If we can't be (fairly) certain that a miner put a minimum amount of work =
into finding a hash, then you lose all the strengths of PoW.

If you weaken the difficulty requirement which is there so that mining blo=
cks is hard so that it is very hard to intentionally fork the chain, re-mi=
ne previous blocks, overtake the other fork, and get the network to re-org=
 onto your chain - then there's no Proof of work undergirding consensus in=
 the ledger's state.

Secondly, where does the block reward go? Do brick miners get a fraction o=
f the reward proportionate to the fraction of the difficulty they got to? =
Later when bricks become part of a block, who gets the block reward for th=
at complete block? Who gets the fees? No miner is going to bother mining a=
 merge-bricks-into-block block if the reward isn't the same or better than=
 just mining a regular block, but each miner of the bricks in it would als=
o want a reward. But, we can't give them both a block reward as that'd inc=
rease Bitcoin's issuance rate, which might be the only thing people are mo=
re strongly opposed to than increasing the blocksize! xD

> At this point, instead of discarding transactions, our miner would start=
 working on a new brick B1, linked with B0 as usual.
> =


> Nodes would allow incoming regular blocks and bricks with hashes that do=
n't satisfy the difficulty rule, provided the brick is fully filled of tra=
nsactions. Bricks not fully filled would be rejected as invalid to prevent=
 spam (except if constitutes the last brick of a brickchain, explained bel=
ow).
> =


> Let's assume that 10 minutes have elapsed and our miner is in a state wh=
ere N bricks have been produced and the accumulated PoW calculated using m=
athematics (every brick contains a 'minimum hash found', when a series of =
'minimum hashes' is computationally equivalent to the network difficulty i=
s then the full 'brickchain' is valid as a Block.


But the brick sidechain has to become part of the main blockchain - and as=
 you've got N bricks in the time that there should be 1 block, and each br=
ick is a full block, it feels like this is just a convoluted way to increa=
se the blocksize? Every transaction has to be in the ledger somewhere to b=
e confirmed, so even if the block itself is small and stored references to=
 the bricks, Nodes are going to have to use storage to keep all those full=
 bricks.

It also seems that you'd have to require the bricks sidechain to always be=
 merged into the next actual block - it wouldn't work if the brick chain c=
ould keep growing and at the same time the actual blockchain advances (bec=
ause there'd be risks of double-spends where one tx is in the brick chain =
and the other in the new block). Which I think further makes this feel lik=
e a roundabout way of increasing the blocksize

Despite my critique, this was interesting to think about - and hopefully t=
his is useful (and hopefully I've not seriously misunderstood or said some=
thing dumb)

Angus
-----------------------57ce92a6886c839a698089bb95fb80cb
Content-Type: multipart/related;boundary=---------------------3671fdda17013703c8a9f6e08cdc58d4

-----------------------3671fdda17013703c8a9f6e08cdc58d4
Content-Type: text/html;charset=utf-8
Content-Transfer-Encoding: base64

PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxNHB4OyI+PHA+
PC9wPjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTRweDsi
Pjxicj48L2Rpdj4KPGRpdiBjbGFzcz0icHJvdG9ubWFpbF9zaWduYXR1cmVfYmxvY2sgcHJvdG9u
bWFpbF9zaWduYXR1cmVfYmxvY2stZW1wdHkiIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNh
OyBmb250LXNpemU6IDE0cHg7Ij4KICAgIDxkaXYgY2xhc3M9InByb3Rvbm1haWxfc2lnbmF0dXJl
X2Jsb2NrLXVzZXIgcHJvdG9ubWFpbF9zaWduYXR1cmVfYmxvY2stZW1wdHkiPgogICAgICAgIAog
ICAgICAgICAgICA8L2Rpdj4KICAgIAogICAgICAgICAgICA8ZGl2IGNsYXNzPSJwcm90b25tYWls
X3NpZ25hdHVyZV9ibG9jay1wcm90b24gcHJvdG9ubWFpbF9zaWduYXR1cmVfYmxvY2stZW1wdHki
PgogICAgICAgIAogICAgICAgICAgICA8L2Rpdj4KPC9kaXY+CjxwPjwvcD4KPGJsb2NrcXVvdGU+
CjxwPkxldCdzIGFsbG93IGEgbWluZXIgdG8gaW5jbHVkZSB0cmFuc2FjdGlvbnMgdW50aWwgdGhl
IGJsb2NrIGlzIGZpbGxlZCwgbGV0J3MgY2FsbCB0aGlzIHN0cnVjdHVyZSAoY29pbmluZyBhIG5l
dyB0ZXJtICdCcmljaycpLCBCMC4gW2JyaWNrPWJsb2NrIHRoYXQgZG9lc24ndCBtZWV0IHRoZSBk
aWZmaWN1bHR5IHJ1bGUgYW5kIGlzIGZpbGxlZCBvZiB0eCB0byBpdHMgZnVsbCBjYXBhY2l0eV08
YnI+ClNpbmNlIFBvVyBoYXNoaW5nIGlzIGNvbnRpbnVvdXNseSBhY3RpdmUsIEJyaWNrIEIwIHdv
dWxkIGhhdmUgYSBub25jZSBjb3JyZXNwb25kaW5nIHRvIGEgbWluaW11bSBudW1lcmljIHZhbHVl
IG9mIGl0cyBoYXNoIGZvdW5kIHVudGlsIGl0IGdvdCBmaWxsZWQuPC9wPgo8L2Jsb2NrcXVvdGU+
CjxwPjxicj4KU28sIGlmIEknbSB1bmRlcnN0YW5kaW5nIHJpZ2h0LCB0aGlzIGFtb3VudHMgdG8g
InJlZHVjZSBkaWZmaWN1bHR5IHJlcXVpcmVkIGZvciBhIGJsb2NrICgnYnJpY2snKSB0byBiZSB2
YWxpZCBpZiB0aGUgbWVtcG9vbCBjb250YWlucyBtb3JlIHRoYW4gMSBibG9jaydzIHdvcnRoIG9m
IHRyYW5zYWN0aW9ucyBzbyB3ZSBnZXQgdHJhbnNhY3Rpb25zIGNvbmZpcm1lZCBmYXN0ZXIiIHVz
aW5nICdicmlja3MnIGFzIHNob3J0LWxpdmVkIHNpZGVjaGFpbnMgdGhhdCBnZXQgbWVyZ2VkIGlu
dG8gYmxvY2tzPzxicj4KPGJyPgpUaGlzIHdvdWxkIGhhdmUgdGhlIHNhbWUgZnVuZGFtZW50YWwg
cHJvYmxlbSBhcyBqdXN0IG1ha2luZyB0aGUgbWF4IGJsb2Nrc2l6ZSBiaWdnZXIgLSBpdCBpbmNy
ZWFzZXMgdGhlIHJhdGUgb2YgZ3Jvd3RoIG9mIHN0b3JhZ2UgcmVxdWlyZWQgZm9yIGEgZnVsbCBu
b2RlLCBiZWNhdXNlIHlvdSdyZSBhbGxvd2luZyBibG9ja3MvYnJpY2tzIHRvIGJlIGNyZWF0ZWQg
ZmFzdGVyLCBzbyB0aGVyZSB3aWxsIGJlIG1vcmUgY29uZmlybWVkIHRyYW5zYWN0aW9ucyB0byBz
dG9yZSBpbiBhIGdpdmVuIHRpbWUgd2luZG93IHRoYW4gdW5kZXIgY3VycmVudCBCaXRjb2luIHJ1
bGVzLjxicj4KPGJyPgpCaXRjb2luIGRvZXNuJ3QgdGFrZSB0aGUgc2l6ZSBvZiB0aGUgbWVtcG9v
bCBpbnRvIGFjY291bnQgd2hlbiBhZGp1c3RpbmcgdGhlIGRpZmZpY3VsdHkgYmVjYXVzZSB0aGUg
dGltZS1iZXR3ZWVuLWJsb2NrcyBpcyAnbW9yZSBpbXBvcnRhbnQnIHRoYW4gYXZvaWRpbmcgY29u
Z2VzdGlvbiB3aGVyZSB0cmFuc2FjdGlvbnMgdGFrZSBhZ2VzIHRvIGdldCBpbnRvIGEgYmxvY2su
IFRoZSBmZWUgbWVjaGFuaXNtIGluIHBhcnQgYWxsb3dzIHVzZXJzIHRvIGRlY2lkZSBob3cgdXJn
ZW50bHkgdGhleSB3YW50IHRoZWlyIHR4IHRvIGdldCBjb25maXJtZWQsIGFuZCBoaWdoIGZlZXMg
d2hlbiB0aGVyZSBpcyBjb25nZXN0aW9uIGFsc28gZGlzaW5jZW50aXZpc2VzIG90aGVycyBmcm9t
IHRyYW5zYWN0aW5nIGF0IGFsbCwgd2hpY2ggaGVscHMgYXJyZXN0IG1lbXBvb2wgZ3Jvd3RoLjxi
cj4KPGJyPgpJJ2QgaW1hZ2luZSB3ZSdkIGFsc28gc2VlIGEgJ2hpZ2h3YXkgd2lkZW5pbmcnIGVm
ZmVjdCB3aXRoIHRoaXMga2luZCBvZiBwcm9wb3NhbCAtIGlmIHlvdSBpbmNyZWFzZSB0aGUgdHgg
dm9sdW1lIEJpdGNvaW4gY2FuIHNldHRsZSBpbiBhIGdpdmVuIHRpbWUsIHRoYXQgd2lsbCBxdWlj
a2x5IGJlIHVzZWQgdXAgYnkgbW9yZSBwZW9wbGUgdHJhbnNhY3RpbmcgdW50aWwgd2UncmUgYmFj
ayBhdCBhIGNvbmdlc3RlZCBzdGF0ZSBhZ2Fpbi48YnI+CjwvcD4KPGJsb2NrcXVvdGU+CjxwPkZ1
bGx5IGZpbGxlZCBicmljayBCMCwgd2l0aCBhIGhhc2ggdGhhdCBkb2Vzbid0IG1lZXQgdGhlIGRp
ZmZpY3VsdHkgcnVsZSwgd291bGQgYmUgYnJvYWRjYXN0ZWQgYW5kIG5vZGVzIHdvdWxkIGhhdmUg
aXQgb24gaW4gYSBzZXBhcmF0ZSBmb3JrIGFzIHVzdWFsLjwvcD4KPC9ibG9ja3F1b3RlPgo8cD48
YnI+CkhvdyBkbyB3ZSBrbm93IGlmIHRoZSBoYXNoIHRoZSBtaW5lciBkb2VzIGZpbmQgZm9yIGEg
YnJpY2sgd2FzIHRoZWlyICdiZXN0IGVmZm9ydCcgYW5kIHRoZXkncmUgbm90IGp1c3QgYmVpbmcg
bGF6eT8gVGhlcmUncyBhbiBlbGVtZW50IG9mIGx1Y2sgaW4gdGhlIGJlc3QgaGFzaCBhIG1pbmVy
IGNhbiBmaW5kLCBzb21ldGltZXMgaXQgdGFrZXMgYSBsb25nIHRpbWUgdG8gbWVldCB0aGUgZGlm
ZmljdWx0eSByZXF1aXJlbWVudCBhbmQgc29tZXRpbWVzIGl0IGhhcHBlbnMgYWxtb3N0IGF0IGlu
c3RhbnRseS48YnI+Cjxicj4KSG93IHdvdWxkIHdlIGtub3cgaG93ICdidXN5JyB0aGUgbWVtcG9v
bCB3YXMgYXQgdGhlIHRpbWUgYSBicmljayBmcm9tIG1vbnRocyBvciB5ZWFycyBhZ28gd2FzIG1p
bmVkPzxicj4KPGJyPgpOb2RlcyBoYXZlIHRvIGJlIGFibGUgdG8gcnVuIHRocm91Z2ggdGhlIGVu
dGlyZSBoaXN0b3J5IG9mIHRoZSBibG9ja2NoYWluIGFuZCBjaGVjayBldmVyeXRoaW5nIGlzIHZh
bGlkLiBUaGV5IGhhdmUgdG8gZG8gdGhpcyB1c2luZyBvbmx5IHRoZSBwcmV2aW91cyBibG9ja3Mg
dGhleSd2ZSBhbHJlYWR5IHZhbGlkYXRlZCAtIHRoZXkgd29uJ3QgaGF2ZSBoaXN0b3JpY2FsIHNu
YXBzaG90cyBvZiB0aGUgbWVtcG9vbCAodGhleSdsbCBidWlsZCBhbmQgbXV0YXRlIGEgVVRYTyBz
ZXQsIGJ1dCB0aGF0J3MgZGlmZmVyZW50KS4gVHJhbnNhY3Rpb25zIGRvbid0IGNvbnRhaW4gYSAn
Y3JlYXRlZC1hdCcgdGltZSB0aGF0IHlvdSBjb3VsZCBjb21wYXJlIHRvIHRoZSBibG9jaydzIGNy
ZWF0aW9uIHRpbWUgKGFuZCBpZiB0aGV5IGRpZCwgeW91IHByb2JhYmx5IGNvdWxkbid0IHRydXN0
IGl0KS48YnI+Cjxicj4KV2l0aCB0aGUgY3VycmVudCBzeXN0ZW0sIE5vZGVzIGNhbiBjYWxjdWxh
dGUgd2hhdCB0aGUgZGlmZmljdWx0eSBzaG91bGQgYmUgZm9yIGV2ZXJ5IGJsb2NrIGJhc2VkIG9u
IHRob3NlIHByZXZpb3VzIGJsb2NrcycgdGltZXMgYW5kIGRpZmZpY3VsdGllcyAtIGJ1dCBob3cg
d291bGQgeW91IGtub3cgYW4gb2xkIGJyaWNrIHdhcyB2YWxpZCBpZiBpdHMgZGlmZmljdWx0eSB3
YXMgbG93IGJ1dCBhdCB0aGUgdGltZSB0aGUgbWVtcG9vbCB3YXMgYnVzeSwgdnMuIGdldHRpbmcg
YSBmcmF1ZHVsZW50IGJyaWNrIHRoYXQgaXMgYWN0dWFsbHkgaW52YWxpZCBiZWNhdXNlIHRoZXJl
IGlzbid0IGVub3VnaCB3b3JrIGluIGl0PyBZb3UgY2FuJ3Qgc29sdmUgdGhpcyBieSBhZGRpbmcg
c29tZSBtZW1wb29sc2l6ZSBmaWVsZCB0byBicmlja3MsIGFzIHlvdSdkIGhhdmUgdG8gYmxpbmRs
eSB0cnVzdCBtaW5lcnMgbm90IHRvIGxpZSBhYm91dCB0aGVtLjxicj4KPGJyPgpJZiB3ZSBjYW4n
dCBiZSAoZmFpcmx5KSBjZXJ0YWluIHRoYXQgYSBtaW5lciBwdXQgYSBtaW5pbXVtIGFtb3VudCBv
ZiB3b3JrIGludG8gZmluZGluZyBhIGhhc2gsIHRoZW4geW91IGxvc2UgYWxsIHRoZSBzdHJlbmd0
aHMgb2YgUG9XLjxicj4KPGJyPgpJZiB5b3Ugd2Vha2VuIHRoZSBkaWZmaWN1bHR5IHJlcXVpcmVt
ZW50IHdoaWNoIGlzIHRoZXJlIHNvIHRoYXQgbWluaW5nIGJsb2NrcyBpcyBoYXJkIHNvIHRoYXQg
aXQgaXMgdmVyeSBoYXJkIHRvIGludGVudGlvbmFsbHkgZm9yayB0aGUgY2hhaW4sIHJlLW1pbmUg
cHJldmlvdXMgYmxvY2tzLCBvdmVydGFrZSB0aGUgb3RoZXIgZm9yaywgYW5kIGdldCB0aGUgbmV0
d29yayB0byByZS1vcmcgb250byB5b3VyIGNoYWluIC0gdGhlbiB0aGVyZSdzIG5vIDxlbT5Qcm9v
ZjwvZW0+IG9mIHdvcmsgdW5kZXJnaXJkaW5nIGNvbnNlbnN1cyBpbiB0aGUgbGVkZ2VyJ3Mgc3Rh
dGUuPGJyPgo8YnI+ClNlY29uZGx5LCB3aGVyZSBkb2VzIHRoZSBibG9jayByZXdhcmQgZ28/IERv
IGJyaWNrIG1pbmVycyBnZXQgYSBmcmFjdGlvbiBvZiB0aGUgcmV3YXJkIHByb3BvcnRpb25hdGUg
dG8gdGhlIGZyYWN0aW9uIG9mIHRoZSBkaWZmaWN1bHR5IHRoZXkgZ290IHRvPyBMYXRlciB3aGVu
IGJyaWNrcyBiZWNvbWUgcGFydCBvZiBhIGJsb2NrLCB3aG8gZ2V0cyB0aGUgYmxvY2sgcmV3YXJk
IGZvciB0aGF0IGNvbXBsZXRlIGJsb2NrPyBXaG8gZ2V0cyB0aGUgZmVlcz8gTm8gbWluZXIgaXMg
Z29pbmcgdG8gYm90aGVyIG1pbmluZyBhIG1lcmdlLWJyaWNrcy1pbnRvLWJsb2NrIGJsb2NrIGlm
IHRoZSByZXdhcmQgaXNuJ3QgdGhlIHNhbWUgb3IgYmV0dGVyIHRoYW4ganVzdCBtaW5pbmcgYSBy
ZWd1bGFyIGJsb2NrLCBidXQgZWFjaCBtaW5lciBvZiB0aGUgYnJpY2tzIGluIGl0IHdvdWxkIGFs
c28gd2FudCBhIHJld2FyZC4gQnV0LCB3ZSBjYW4ndCBnaXZlIHRoZW0gYm90aCBhIGJsb2NrIHJl
d2FyZCBhcyB0aGF0J2QgaW5jcmVhc2UgQml0Y29pbidzIGlzc3VhbmNlIHJhdGUsIHdoaWNoIG1p
Z2h0IGJlIHRoZSBvbmx5IHRoaW5nIHBlb3BsZSBhcmUgbW9yZSBzdHJvbmdseSBvcHBvc2VkIHRv
IHRoYW4gaW5jcmVhc2luZyB0aGUgYmxvY2tzaXplISB4RDxicj4KPC9wPgo8YmxvY2txdW90ZT4K
PHA+QXQgdGhpcyBwb2ludCwgaW5zdGVhZCBvZiBkaXNjYXJkaW5nIHRyYW5zYWN0aW9ucywgb3Vy
IG1pbmVyIHdvdWxkIHN0YXJ0IHdvcmtpbmcgb24gYSBuZXcgYnJpY2sgQjEsIGxpbmtlZCB3aXRo
IEIwIGFzIHVzdWFsLjwvcD4KPHA+Tm9kZXMgd291bGQgYWxsb3cgaW5jb21pbmcgcmVndWxhciBi
bG9ja3MgYW5kIGJyaWNrcyB3aXRoIGhhc2hlcyB0aGF0IGRvbid0IHNhdGlzZnkgdGhlIGRpZmZp
Y3VsdHkgcnVsZSwgcHJvdmlkZWQgdGhlIGJyaWNrIGlzIGZ1bGx5IGZpbGxlZCBvZiB0cmFuc2Fj
dGlvbnMuIEJyaWNrcyBub3QgZnVsbHkgZmlsbGVkIHdvdWxkIGJlIHJlamVjdGVkIGFzIGludmFs
aWQgdG8gcHJldmVudCBzcGFtIChleGNlcHQgaWYgY29uc3RpdHV0ZXMgdGhlIGxhc3QgYnJpY2sg
b2YgYSBicmlja2NoYWluLCBleHBsYWluZWQgYmVsb3cpLjwvcD4KPHA+TGV0J3MgYXNzdW1lIHRo
YXQgMTAgbWludXRlcyBoYXZlIGVsYXBzZWQgYW5kIG91ciBtaW5lciBpcyBpbiBhIHN0YXRlIHdo
ZXJlIE4gYnJpY2tzIGhhdmUgYmVlbiBwcm9kdWNlZCBhbmQgdGhlIGFjY3VtdWxhdGVkIFBvVyBj
YWxjdWxhdGVkIHVzaW5nIG1hdGhlbWF0aWNzIChldmVyeSBicmljayBjb250YWlucyBhICdtaW5p
bXVtIGhhc2ggZm91bmQnLCB3aGVuIGEgc2VyaWVzIG9mICdtaW5pbXVtIGhhc2hlcycgaXMgY29t
cHV0YXRpb25hbGx5IGVxdWl2YWxlbnQgdG8gdGhlIG5ldHdvcmsgZGlmZmljdWx0eSBpcyB0aGVu
IHRoZSBmdWxsICdicmlja2NoYWluJyBpcyB2YWxpZCBhcyBhIEJsb2NrLjwvcD4KPC9ibG9ja3F1
b3RlPgo8cD48YnI+CkJ1dCB0aGUgYnJpY2sgc2lkZWNoYWluIGhhcyB0byBiZWNvbWUgcGFydCBv
ZiB0aGUgbWFpbiBibG9ja2NoYWluIC0gYW5kIGFzIHlvdSd2ZSBnb3QgTiBicmlja3MgaW4gdGhl
IHRpbWUgdGhhdCB0aGVyZSBzaG91bGQgYmUgMSBibG9jaywgYW5kIGVhY2ggYnJpY2sgaXMgYSBm
dWxsIGJsb2NrLCBpdCBmZWVscyBsaWtlIHRoaXMgaXMganVzdCBhIGNvbnZvbHV0ZWQgd2F5IHRv
IGluY3JlYXNlIHRoZSBibG9ja3NpemU/IEV2ZXJ5IHRyYW5zYWN0aW9uIGhhcyB0byBiZSBpbiB0
aGUgbGVkZ2VyIHNvbWV3aGVyZSB0byBiZSBjb25maXJtZWQsIHNvIGV2ZW4gaWYgdGhlIGJsb2Nr
IGl0c2VsZiBpcyBzbWFsbCBhbmQgc3RvcmVkIHJlZmVyZW5jZXMgdG8gdGhlIGJyaWNrcywgTm9k
ZXMgYXJlIGdvaW5nIHRvIGhhdmUgdG8gdXNlIHN0b3JhZ2UgdG8ga2VlcCBhbGwgdGhvc2UgZnVs
bCBicmlja3MuPGJyPgo8YnI+Ckl0IGFsc28gc2VlbXMgdGhhdCB5b3UnZCBoYXZlIHRvIHJlcXVp
cmUgdGhlIGJyaWNrcyBzaWRlY2hhaW4gdG8gYWx3YXlzIGJlIG1lcmdlZCBpbnRvIHRoZSBuZXh0
IGFjdHVhbCBibG9jayAtIGl0IHdvdWxkbid0IHdvcmsgaWYgdGhlIGJyaWNrIGNoYWluIGNvdWxk
IGtlZXAgZ3Jvd2luZyBhbmQgYXQgdGhlIHNhbWUgdGltZSB0aGUgYWN0dWFsIGJsb2NrY2hhaW4g
YWR2YW5jZXMgKGJlY2F1c2UgdGhlcmUnZCBiZSByaXNrcyBvZiBkb3VibGUtc3BlbmRzIHdoZXJl
IG9uZSB0eCBpcyBpbiB0aGUgYnJpY2sgY2hhaW4gYW5kIHRoZSBvdGhlciBpbiB0aGUgbmV3IGJs
b2NrKS4gV2hpY2ggSSB0aGluayBmdXJ0aGVyIG1ha2VzIHRoaXMgZmVlbCBsaWtlIGEgcm91bmRh
Ym91dCB3YXkgb2YgaW5jcmVhc2luZyB0aGUgYmxvY2tzaXplPGJyPgo8YnI+CkRlc3BpdGUgbXkg
Y3JpdGlxdWUsIHRoaXMgd2FzIGludGVyZXN0aW5nIHRvIHRoaW5rIGFib3V0IC0gYW5kIGhvcGVm
dWxseSB0aGlzIGlzIHVzZWZ1bCAoYW5kIGhvcGVmdWxseSBJJ3ZlIG5vdCBzZXJpb3VzbHkgbWlz
dW5kZXJzdG9vZCBvciBzYWlkIHNvbWV0aGluZyBkdW1iKTxicj4KPGJyPgpBbmd1czxicj4KPC9w
PjwvZGl2Pg==
-----------------------3671fdda17013703c8a9f6e08cdc58d4--
-----------------------57ce92a6886c839a698089bb95fb80cb--
-----------------------8aa1a726925524c8a7e9d24d4d370652--

--------e337235ccd9c55017fd2accb1649b99d499b1b9749b47cf4231f6b2d5bb52d44
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: ProtonMail

wnUEARYKAAYFAmNP/kMAIQkQwiXKZc88nVQWIQSalAAog9TgKl9o88rCJcpl
zzydVL1kAPoDBQPMOnEvBPTL4jYDhNgaBkRSykQb43hbhJd0Odx8vQD/cFFJ
7QRDLFh9nsA1HFvTtq+/Sf+70fRp50yLp3HqtgI=
=7/OW
-----END PGP SIGNATURE-----


--------e337235ccd9c55017fd2accb1649b99d499b1b9749b47cf4231f6b2d5bb52d44--