path: root/0d/7d63d4048802c7fee1d18ea0aff1ffc30e0e19

Return-Path: <fmerli1@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 6AD7DC000D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 10 Sep 2021 09:30:45 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 5935B401D2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 10 Sep 2021 09:30:45 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 0.852
X-Spam-Level: 
X-Spam-Status: No, score=0.852 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_ENVFROM_END_DIGIT=0.25, 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: smtp2.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id oeRE5FBB-qKn
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 10 Sep 2021 09:30:43 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-il1-x133.google.com (mail-il1-x133.google.com
 [IPv6:2607:f8b0:4864:20::133])
 by smtp2.osuosl.org (Postfix) with ESMTPS id A0FF640167
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 10 Sep 2021 09:30:43 +0000 (UTC)
Received: by mail-il1-x133.google.com with SMTP id s16so1367147ilo.9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 10 Sep 2021 02:30:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
 bh=0qPBNG0m1vJxY2GF6tFehAFQhTpvuvqm+gJMYFIoq3E=;
 b=h3Q2a8b+vrD239gNfeMo+SORrR70PSdKmZiyLq33DPXg1YxVCOMZecr/xipbvzu4qr
 KufmsLSEUnfj6fvEhBGM2VQNdsyWg1DPtFCL7CzxXwaSeLuddQC7Je8mXXpcasxhY3/E
 XoWOMDwxKks5Xz6lMT9pFEuArq7MZFf+8/udto1+yFooQOP9KgYYFem+C9BBmSKmMMFB
 JYWGUPJC21l7ySRpx3GCUxUwdXRrqz5agCdiTrSw17AV+HujVEagD7tsd1xjwHjkrSD3
 jfgraW2ssPbQRrOpeXTpMGHCMFHYycjefh0COuaRFZtV2mZDR0IVgRIpkB3/bMpMWpqD
 MaBA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to;
 bh=0qPBNG0m1vJxY2GF6tFehAFQhTpvuvqm+gJMYFIoq3E=;
 b=1s/vgkczuTGRiAwp3Dq76RVsojUSoPDetJmLRXBVlAhY8kGCZLbw4pSZgG8ubc5Pz2
 A2gLxXVRzpVu+DtPppP83RgKoPm/EAoFXQ7+YEY/OC8ufdqBsaR284fvxkSaddkF+hWW
 6D6xChmgXVEvBZZtjOi8EYASlXiCXxh3lU8WrMxPYkQNPRv/pt26/4vi04IFStrOVtZM
 9M8W1unhabxtIf+26kA6YyS/BkLPUOcTE1ApbJoDM0ANxD5Aqo6tlvnQYva9w4NOhiFw
 qD4Aa5IQbH7ODCNRTfKlrSf38rMJZL6/25+va3YdzP4Zto1Cn5/aLVKqxvDzjNsO/Kws
 6wSw==
X-Gm-Message-State: AOAM532H55DuDYY2Vcpk+nV+axsMsxQ7SISU+Abp9WzE8V4PFLmGl8Oe
 0f/rckYqzUNF1sFDp4suLBk3kYPBRnExESeVFvJhm7+1
X-Google-Smtp-Source: ABdhPJytuGHLuOln9REV9piN1IJXkoLndLIFzM2oc6fJ+r+RmgWpPpPiSmaZ4EfPUyfR5ae51ZSDeh/+N9QFITFheio=
X-Received: by 2002:a05:6e02:20e7:: with SMTP id
 q7mr5988639ilv.212.1631266242630; 
 Fri, 10 Sep 2021 02:30:42 -0700 (PDT)
MIME-Version: 1.0
References: <MiuahdA--3-2@tutanota.de>
 <ceFmn7ZHyPHN70rDuE66lnPEwjgjQ7LtZLwyFgIVUpPvPDvSZSsLHUf_yiBvXTpjdEju4UxAOnDgilZaQAMvQzYcUbOkZsYvOIpuBG7japo=@protonmail.com>
 <edbbb44e247d4e639659e1b9b989dd84-kohli@ctemplar.com>
In-Reply-To: <edbbb44e247d4e639659e1b9b989dd84-kohli@ctemplar.com>
From: Filippo Merli <fmerli1@gmail.com>
Date: Fri, 10 Sep 2021 11:30:31 +0200
Message-ID: <CAO1K=nnGXasdu_M4NgCkcCFMB16sW5r-Xd462d6jfR9mBBCgSA@mail.gmail.com>
To: pool2win <kohli@ctemplar.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000ed1a5005cba0c493"
X-Mailman-Approved-At: Fri, 10 Sep 2021 09:52:47 +0000
Subject: Re: [bitcoin-dev] Braidpool: Proposal for a decentralised mining
	pool
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: Fri, 10 Sep 2021 09:30:45 -0000

--000000000000ed1a5005cba0c493
Content-Type: text/plain; charset="UTF-8"

Hi!

From the proposal it is not clear why a miner must reference other miners'
shares in his shares.
What I mean is that there is a huge incentive for a rogue miner to not
reference any share from
other miner so he won't share the reward with anyone, but it will be paid
for the share that he
create because good miners will reference his shares.
The pool will probably become unprofitable for good miners.

Another thing that I do not understand is how to resolve conflicts. For
example, using figure 1 at
page 1, a node could be receive this 2 valid states:

1. L -> a1 -> a2 -> a3 -> R
2. L -> a1* -> a2* -> R

To resolve the above fork the only two method that comes to my mind are:

1. use the one that has more work
2. use the longest one

Btw both methods present an issue IMHO.

If the longest chain is used:
When a block (L) is find, a miner (a) could easily create a lot of share
with low difficulty
(L -> a1* -> a2* -> ... -> an*), then start to mine shares with his real
hashrate (L -> a1 -> a2)
and publish them so they get referenced. If someone else finds a block he
gets the reward cause he
has been referenced. If he finds the block he just attaches the funded
block to the longest chain
(that reference no one) and publishes it without sharing the reward
(L -> a1* -> a2* -> ... -> an* -> R).

If is used the one with more work:
A miner that has published the shares (L -> a1 -> a2 -> a3) when find a
block R that alone has more
work than a1 + a2 + a3 it just publish (L -> R) and he do not share the
reward with anyone.

On Wed, Sep 8, 2021 at 1:15 PM pool2win via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> > A thing I just realized about Braidpool is that the payout server is
> still a single central point-of-failure.
>
> > However, this probably complicates the design too much, and it may be
> more beneficial to get *something* working now.
>
> You have hit the nail on the head here and Chris Belcher's original
> proposal for using payment channels does provide a construction for
> multiple hubs [1]. In the Braidpool proposal however, the focus is on a
> single hub to describe the plan for an MVP.
>
> Decentralising hubs is the end goal here, and either Belcher's multiple
> hubs construction or a leadership election based construction along the
> lines you propose might be a good way forward. Belcher's idea has the added
> advantage that the required liquidity at each hub is reduced as more hubs
> join, with the cost that in case of a hubs defecting, it takes longer for
> miners to do cascading close on channels to all hubs. TBH, it might be a
> cost worth paying in the absence of better ideas. But as braidpool is
> built, more ideas will be appear as well.
>
> [1] Payment Channel Payouts: An Idea for Improving P2Pool Scalability:
> https://bitcointalk.org/index.php?topic=2135429.0
>
> ---------- Original Message ----------
> On Tue, September 7, 2021 at 11:39 PM,  ZmnSCPxj via bitcoin-dev<
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> Good morning all,
>
> A thing I just realized about Braidpool is that the payout server is still
> a single central point-of-failure.
>
> Although the paper claims to use Tor hidden service to protect against
> DDoS attacks, its centrality still cannot protect against sheer accident.
> What happens if some clumsy human (all humans are clumsy, right?) fumbles
> the cables in the datacenter the hub is hosted in?
> What happens if the country the datacenter is in is plunged into war or
> anarchy, because you humans love war and chaos so much?
> What happens if Zeus has a random affair (like all those other times),
> Hera gets angry, and they get into a domestic, and then a random thrown
> lightning bolt hits the datacenter the hub is in?
>
> The paper relies on economic arguments ("such an action will end the pool
> and the stream of future profits for the hub"), but economic arguments tend
> to be a lot less powerful in a monopoly, and the hub effectively has a
> monopoly on all Braidpool miners.
> Hashers might be willing to tolerate minor peccadilloes of the hub, simply
> to let the pool continue (their other choices would be even worse).
>
> So it seems to me that it would still be nicer, if it were at all
> possible, to use multiple hubs.
> I am uncertain how easily this can be done.
>
> Perhaps a Lightning model can be considered.
> Multiple hubs may exist which offer liquidity to the Braidpool network,
> hashers measure uptime and timeliness of payouts, and the winning hasher
> elects one of the hubs.
> The hub gets paid on the coinbase, and should send payouts, minus fees, on
> the LN to the miners.
>
> However, this probably complicates the design too much, and it may be more
> beneficial to get *something* working now.
> Let not the perfect be the enemy of the good.
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> 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
>

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

<div dir=3D"ltr"><div>Hi!<br><br>From the proposal it is not clear why a mi=
ner must reference other miners&#39; shares in his shares.<br>What I mean i=
s that there is a huge incentive for a rogue miner to not reference any sha=
re from<br>other miner so he won&#39;t share the reward with anyone, but it=
 will be paid for the share that he<br>create because good miners will refe=
rence his shares.<br>The pool will probably become unprofitable for good mi=
ners.<br><br>Another thing that I do not understand is how to resolve confl=
icts. For example, using figure 1 at<br>page 1, a node could be receive thi=
s 2 valid states:<br><br>1. L -&gt; a1 -&gt; a2 -&gt; a3 -&gt; R<br>2. L -&=
gt; a1* -&gt; a2* -&gt; R<br><br>To resolve the above fork the only two met=
hod that comes to my mind are:<br><br>1. use the one that has more work<br>=
2. use the longest one<br><br></div><div>Btw both methods present an issue =
IMHO.<br><br>If the longest chain is used:<br>When a block (L) is find, a m=
iner (a) could easily create a lot of share with low difficulty<br>(L -&gt;=
 a1* -&gt; a2* -&gt; ... -&gt; an*), then start to mine shares with his rea=
l hashrate (L -&gt; a1 -&gt; a2)<br>and publish them so they get referenced=
. If someone else finds a block he gets the reward cause he<br>has been ref=
erenced. If he finds the block he just attaches the funded block to the lon=
gest chain<br>(that reference no one) and publishes it without sharing the =
reward<br>(L -&gt; a1* -&gt; a2* -&gt; ... -&gt; an* -&gt; R).<br><br>If is=
 used the one with more work:<br>A miner that has published the shares (L -=
&gt; a1 -&gt; a2 -&gt; a3) when find a block R that alone has more</div><di=
v>work than a1 + a2 + a3 it just publish (L -&gt; R) and he do not share th=
e reward with anyone.</div></div><br><div class=3D"gmail_quote"><div dir=3D=
"ltr" class=3D"gmail_attr">On Wed, Sep 8, 2021 at 1:15 PM pool2win via bitc=
oin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoi=
n-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">&gt; A thing I just realized about Braidpo=
ol is that the payout server is still a single central point-of-failure.<br=
>
<br>
&gt; However, this probably complicates the design too much, and it may be =
more beneficial to get *something* working now.<br>
<br>
You have hit the nail on the head here and Chris Belcher&#39;s original pro=
posal for using payment channels does provide a construction for multiple h=
ubs [1]. In the Braidpool proposal however, the focus is on a single hub to=
 describe the plan for an MVP.<br>
<br>
Decentralising hubs is the end goal here, and either Belcher&#39;s multiple=
 hubs construction or a leadership election based construction along the li=
nes you propose might be a good way forward. Belcher&#39;s idea has the add=
ed advantage that the required liquidity at each hub is reduced as more hub=
s join, with the cost that in case of a hubs defecting, it takes longer for=
 miners to do cascading close on channels to all hubs. TBH, it might be a c=
ost worth paying in the absence of better ideas. But as braidpool is built,=
 more ideas will be appear as well.<br>
<br>
[1] Payment Channel Payouts: An Idea for Improving P2Pool Scalability: <a h=
ref=3D"https://bitcointalk.org/index.php?topic=3D2135429.0" rel=3D"noreferr=
er" target=3D"_blank">https://bitcointalk.org/index.php?topic=3D2135429.0</=
a><br>
<br>
---------- Original Message ----------<br>
On Tue, September 7, 2021 at 11:39 PM,=C2=A0 ZmnSCPxj via bitcoin-dev&lt;<a=
 href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bi=
tcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
Good morning all,<br>
<br>
A thing I just realized about Braidpool is that the payout server is still =
a single central point-of-failure.<br>
<br>
Although the paper claims to use Tor hidden service to protect against DDoS=
 attacks, its centrality still cannot protect against sheer accident.<br>
What happens if some clumsy human (all humans are clumsy, right?) fumbles t=
he cables in the datacenter the hub is hosted in?<br>
What happens if the country the datacenter is in is plunged into war or ana=
rchy, because you humans love war and chaos so much?<br>
What happens if Zeus has a random affair (like all those other times), Hera=
 gets angry, and they get into a domestic, and then a random thrown lightni=
ng bolt hits the datacenter the hub is in?<br>
<br>
The paper relies on economic arguments (&quot;such an action will end the p=
ool and the stream of future profits for the hub&quot;), but economic argum=
ents tend to be a lot less powerful in a monopoly, and the hub effectively =
has a monopoly on all Braidpool miners.<br>
Hashers might be willing to tolerate minor peccadilloes of the hub, simply =
to let the pool continue (their other choices would be even worse).<br>
<br>
So it seems to me that it would still be nicer, if it were at all possible,=
 to use multiple hubs.<br>
I am uncertain how easily this can be done.<br>
<br>
Perhaps a Lightning model can be considered.<br>
Multiple hubs may exist which offer liquidity to the Braidpool network, has=
hers measure uptime and timeliness of payouts, and the winning hasher elect=
s one of the hubs.<br>
The hub gets paid on the coinbase, and should send payouts, minus fees, on =
the LN to the miners.<br>
<br>
However, this probably complicates the design too much, and it may be more =
beneficial to get *something* working now.<br>
Let not the perfect be the enemy of the good.<br>
<br>
Regards,<br>
ZmnSCPxj<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>
_______________________________________________<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>

--000000000000ed1a5005cba0c493--