path: root/0d/5b61b224523d7953af368e1037040e28b9c139

Return-Path: <fresheneesz@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id E414DC000E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 22 Jun 2021 18:21:10 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id BC00683B03
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 22 Jun 2021 18:21:10 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 0.602
X-Spam-Level: 
X-Spam-Status: No, score=0.602 tagged_above=-999 required=5
 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id QH-NIAWpdy3q
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 22 Jun 2021 18:21:09 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com
 [IPv6:2a00:1450:4864:20::535])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 3AB9483B02
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 22 Jun 2021 18:21:09 +0000 (UTC)
Received: by mail-ed1-x535.google.com with SMTP id df12so62874edb.2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 22 Jun 2021 11:21:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=MN41pQmR94uh/JpRz15N5BXz78TNZuqBTY34/7jzuhE=;
 b=uPLdubdxZyI5s6zvks5HKQ9CnbVHp0KRk7sXJjUgEGP+iUyhnHBC82VW/3w5/IMwM5
 wepkONqFO02yPcmkv8xFwIPaxLhCZifrLcnd9otGddGsGmBhKJcky28XVkL/57cjW5tF
 ZVrmv9FEeVB8uIi+auXHuBv8Gs6Pu3sbIl1pNsjCJoevI2EHP1zM5KdEA63x0ERnGD9C
 IqCF6TYOxh8A2J7jfiW7rW4xaUEKZ/93173lvceURpcWRzVHbZiUHKHNN+qBv1Ek0tIM
 gntTweKtq+Q6NeknebkLFArqPftxpDa7dVys+Txn0O2uquVSeSsnPa4SfuoxWQJhYoch
 HAvA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=MN41pQmR94uh/JpRz15N5BXz78TNZuqBTY34/7jzuhE=;
 b=eQI3lXf9+4zyCpkdvFCjuukX1WPdtu+0opfiZi8w0HM8vheO9YRbZP2/2HzD76sckJ
 qk3SJig7GEhSoBFIMZVBIm/BEcenb37zKtr05O8i7PnCHD4DesO0trJlUEyWEjx//Ke8
 7v54GWBjfgbubhhdnJKQ9yY54mg5wrJrlKGtOz3o7pL9876z5hRMGwaj2H+Hzw1uwIOE
 bsz7wRLuOa7S7EgEJBNOl/7/OO4o5MARPfDmZrKahFnbTAs/rYw4E83sPIRmY1RTqXNl
 5P0I29Pzqso30CcMcNctnIngZSmWPPMCtv9LdbPSOFYhLeDV73EeyAvUXgTk3HDY9TUJ
 M3Tg==
X-Gm-Message-State: AOAM531tCdc+59pMMvbNP2IjLQSMEEkeOHKin3d/TENU7ciWlcmCjv6r
 7QQDRG022s1t1FjO+cD1TNxV7jeBhYq8HgV//Fs=
X-Google-Smtp-Source: ABdhPJwA12W3ycISoJttoPI59EnuF7HL34qHOl8UkRmCgORo+9K8906I8udbwc7oFybu/DuAj3kfJvQ3RHkHTEyjdO4=
X-Received: by 2002:a05:6402:1c1a:: with SMTP id
 ck26mr6897795edb.230.1624386067415; 
 Tue, 22 Jun 2021 11:21:07 -0700 (PDT)
MIME-Version: 1.0
References: <bea8122aea550f1141170829aac252af@riseup.net>
 <CADvTj4q42bQ0mTWwdMyJM9UpW57pV0feZk-vYynPu91N_aZSZw@mail.gmail.com>
In-Reply-To: <CADvTj4q42bQ0mTWwdMyJM9UpW57pV0feZk-vYynPu91N_aZSZw@mail.gmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Tue, 22 Jun 2021 11:20:51 -0700
Message-ID: <CAGpPWDZtRnnv-Hinn4x=9ukJcuHkZv-6Yt32AK-9e+BJ=6r-kA@mail.gmail.com>
To: James Hilliard <james.hilliard1@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000086c52605c55edacf"
X-Mailman-Approved-At: Wed, 23 Jun 2021 02:52:08 +0000
Subject: Re: [bitcoin-dev] Boost Bitcoin circulation,
 Million Transactions Per Second with stronger privacy
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: Tue, 22 Jun 2021 18:21:11 -0000

--00000000000086c52605c55edacf
Content-Type: text/plain; charset="UTF-8"

I would be interested in seeing some more information about the benefits of
this approach vs alternatives up front in this write up. Eg how does the
security, cost, usability, and privacy compare to the lightning network,
which would be the most likely competitor to this idea. It seems clear that
there is more counterparty risk here, so it would probably also be very
helpful to compare against traditional custodial solutions as well. If you
have specific claims on how this system is better than eg lightning in
certain contexts, it would be far easier to evaluate the protocol against
those claims, and would also be a lot easier for readers to be motivated to
read the whole protocol and do a more full analysis.

I agree with others that using email is probably not appropriate for a
protocol like this. I would highly recommend making your protocol
transport-agnostic, allowing users of your protocol to use any transport
they want.

On Sat, Jun 19, 2021 at 7:00 PM James Hilliard via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I think you're making a number of assumptions about mining that are
> not accurate.
>
> > First of all, how much chance in finding next block the corrupted miners
> have? One percent of all Bitcoin hash powers? Or maximum 5 percent or 10?
> The cheaters must come up in dividing that 1.2 Bitcoin between. After all
> the risk/reward must fit them. They can not be a big mining pool since
> there is no benefit, so they will be small miners with low hash rate. If
> they solve the puzzle and broadcast the block, no one in the entire Bitcoin
> network has block transactions or seen it before in their mempool!
>
> You're making the assumption that miners won't build on top of a block
> with transactions they have not seen before or transactions that may
> contain double spends of unconfirmed inputs, this is not how mining
> works, as long as the block passes the consensus rules effectively all
> miners will mine on top of it by default, this behavior is fundamental
> to how mining currently works and is fairly deeply baked into the
> current mining infrastructure.
>
> > Will they accept this block? In theory it is possible and have 0.01
> percent chance but we can eliminate this small possibilities by a simple
> BIP for miners.
>
> What would this BIP look like? I don't see how this could work in a
> decentralized way as you would need another way of reaching consensus
> on what defines a valid block. Right now the chance is nearly 100
> percent that a miner will mine on top of the latest valid block, many
> pools(most last I checked) will even mine on the next block before
> they validate the latest block fully(ie validationless mining) to
> reduce their orphan rates.
>
> > We suppose the miners always control transactions with doc-watchers and
> avoid accepting transaction with same UTXO but different output.
>
> Miners have different mempool policy/rules for what transactions they
> themselves mine but all miners must mine on the most work chain of
> valid blocks otherwise they risk their own blocks being orphaned, any
> miner that does not do this is effectively guaranteed to have their
> block orphaned right now.
>
> > Because of high Bitcoin transaction fee, this guarantee transaction will
> take place in next block, even if other transaction which are using the
> same UTXO as input existed in mempool.
>
> When a new transaction is broadcast miners do not immediately start
> mining on a block template that includes that transaction, the
> template won't even be generated immediately when it enters a miners
> mempool in practice, for bandwidth/network efficiency reasons mining
> pools batch update the stratum templates/jobs they mine against so
> there can be significant latency between the time a transaction is
> actually broadcast and hits the miners mempool and the time the miners
> actually switch to mining on top it, these batched updates are
> essentially like point in time snapshots of the mempool and typically
> remain valid(as in the pool will accept shares submitted against that
> job as valid) until the bitcoin network finds the next block. I don't
> think these batch updates are done more often than every 30 seconds
> typically, while often it is on the order of multiple minutes
> depending on the pool.
>
> Regards,
> James
>
> On Thu, Jun 17, 2021 at 2:14 PM raymo via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> > Hi,
> > I have a proposal for improve Bitcoin TPS and privacy, here is the post.
> >
> https://raymo-49157.medium.com/time-to-boost-bitcoin-circulation-million-transactions-per-second-and-privacy-1eef8568d180
> > https://bitcointalk.org/index.php?topic=5344020.0
> > Can you please read it and share your idea about it.
> >
> > Cheers
> > Raymo
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr">I would be interested in seeing some more information abou=
t the benefits of this approach vs alternatives up front in this write up. =
Eg how does the security, cost, usability, and privacy compare to the light=
ning network, which would be the most likely=C2=A0competitor to this idea. =
It seems clear that there is more counterparty risk here, so it would proba=
bly also be very helpful to compare against traditional custodial solutions=
 as well. If you have specific claims on how this system is better than eg =
lightning in certain contexts, it would be far easier to evaluate the proto=
col against those claims, and would also be a lot easier for readers to be =
motivated to read the whole protocol and do a more full analysis.=C2=A0<div=
><br></div><div>I agree with others that using email is probably not approp=
riate for a protocol like this. I would highly recommend making your protoc=
ol transport-agnostic, allowing users of your protocol to use any transport=
 they want.=C2=A0</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr=
" class=3D"gmail_attr">On Sat, Jun 19, 2021 at 7:00 PM James Hilliard via b=
itcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bit=
coin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid r=
gb(204,204,204);padding-left:1ex">I think you&#39;re making a number of ass=
umptions about mining that are<br>
not accurate.<br>
<br>
&gt; First of all, how much chance in finding next block the corrupted mine=
rs have? One percent of all Bitcoin hash powers? Or maximum 5 percent or 10=
? The cheaters must come up in dividing that 1.2 Bitcoin between. After all=
 the risk/reward must fit them. They can not be a big mining pool since the=
re is no benefit, so they will be small miners with low hash rate. If they =
solve the puzzle and broadcast the block, no one in the entire Bitcoin netw=
ork has block transactions or seen it before in their mempool!<br>
<br>
You&#39;re making the assumption that miners won&#39;t build on top of a bl=
ock<br>
with transactions they have not seen before or transactions that may<br>
contain double spends of unconfirmed inputs, this is not how mining<br>
works, as long as the block passes the consensus rules effectively all<br>
miners will mine on top of it by default, this behavior is fundamental<br>
to how mining currently works and is fairly deeply baked into the<br>
current mining infrastructure.<br>
<br>
&gt; Will they accept this block? In theory it is possible and have 0.01 pe=
rcent chance but we can eliminate this small possibilities by a simple BIP =
for miners.<br>
<br>
What would this BIP look like? I don&#39;t see how this could work in a<br>
decentralized way as you would need another way of reaching consensus<br>
on what defines a valid block. Right now the chance is nearly 100<br>
percent that a miner will mine on top of the latest valid block, many<br>
pools(most last I checked) will even mine on the next block before<br>
they validate the latest block fully(ie validationless mining) to<br>
reduce their orphan rates.<br>
<br>
&gt; We suppose the miners always control transactions with doc-watchers an=
d avoid accepting transaction with same UTXO but different output.<br>
<br>
Miners have different mempool policy/rules for what transactions they<br>
themselves mine but all miners must mine on the most work chain of<br>
valid blocks otherwise they risk their own blocks being orphaned, any<br>
miner that does not do this is effectively guaranteed to have their<br>
block orphaned right now.<br>
<br>
&gt; Because of high Bitcoin transaction fee, this guarantee transaction wi=
ll take place in next block, even if other transaction which are using the =
same UTXO as input existed in mempool.<br>
<br>
When a new transaction is broadcast miners do not immediately start<br>
mining on a block template that includes that transaction, the<br>
template won&#39;t even be generated immediately when it enters a miners<br=
>
mempool in practice, for bandwidth/network efficiency reasons mining<br>
pools batch update the stratum templates/jobs they mine against so<br>
there can be significant latency between the time a transaction is<br>
actually broadcast and hits the miners mempool and the time the miners<br>
actually switch to mining on top it, these batched updates are<br>
essentially like point in time snapshots of the mempool and typically<br>
remain valid(as in the pool will accept shares submitted against that<br>
job as valid) until the bitcoin network finds the next block. I don&#39;t<b=
r>
think these batch updates are done more often than every 30 seconds<br>
typically, while often it is on the order of multiple minutes<br>
depending on the pool.<br>
<br>
Regards,<br>
James<br>
<br>
On Thu, Jun 17, 2021 at 2:14 PM raymo via bitcoin-dev<br>
&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bla=
nk">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt;<br>
&gt; Hi,<br>
&gt; I have a proposal for improve Bitcoin TPS and privacy, here is the pos=
t.<br>
&gt; <a href=3D"https://raymo-49157.medium.com/time-to-boost-bitcoin-circul=
ation-million-transactions-per-second-and-privacy-1eef8568d180" rel=3D"nore=
ferrer" target=3D"_blank">https://raymo-49157.medium.com/time-to-boost-bitc=
oin-circulation-million-transactions-per-second-and-privacy-1eef8568d180</a=
><br>
&gt; <a href=3D"https://bitcointalk.org/index.php?topic=3D5344020.0" rel=3D=
"noreferrer" target=3D"_blank">https://bitcointalk.org/index.php?topic=3D53=
44020.0</a><br>
&gt; Can you please read it and share your idea about it.<br>
&gt;<br>
&gt; Cheers<br>
&gt; Raymo<br>
&gt; _______________________________________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.linuxfoundation.org</a><br>
&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org=
/mailman/listinfo/bitcoin-dev</a><br>
_______________________________________________<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>

--00000000000086c52605c55edacf--