summaryrefslogtreecommitdiff
path: root/2e/e6f09214099f35138778e3973c67a20070a5ea
blob: 05d5778f8731b01a2d4a60b70ecc82691c4be80e (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
Return-Path: <james.hilliard1@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 8E423C000C
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 20 Jun 2021 02:00:07 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 751F3401E3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 20 Jun 2021 02:00:07 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.85
X-Spam-Level: 
X-Spam-Status: No, score=-1.85 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,
 FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001,
 RCVD_IN_DNSWL_NONE=-0.0001, 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 W47Z-B5p_Vrz
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 20 Jun 2021 02:00:06 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com
 [IPv6:2607:f8b0:4864:20::334])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 3C675400AB
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 20 Jun 2021 02:00:06 +0000 (UTC)
Received: by mail-ot1-x334.google.com with SMTP id
 v22-20020a0568301416b029044e2d8e855eso4632991otp.8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 19 Jun 2021 19:00:06 -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
 :content-transfer-encoding;
 bh=/pqWt3L3zJMM4n2EqU0p0HRMD76hcn9BE4oD+p6GZcE=;
 b=jmHlEb8Elp2Yt6p9bEnLD91v6W95jewyxnKjxb07en5+srJgri4hFH3WCNVIdy3VTF
 PntUBOTRscwp0RYZctDrIkC6ecPRhCYTToqfICoiU+5ZXqs7m7AZTFNcgZCEbplcDW5O
 9q4agDHt+1O04FTmO3ps/MGTrpCQvBPOk9V0+lU64fVHTH9j+Q8DDWfiKUhVyHmohFKR
 lFFZhM5wbU4maIWmnhIPYxaTJvRfL2hpu6hKKm/WbuQbFeU5QSkSy+UNA2NCwXE4B6v6
 PZ8VkWAyyhb/loy9Q085d+vG7ahdcGDbk4GK4PwvCMVudzF3Hj/6nQujYcZWIsNDckKy
 tMog==
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:content-transfer-encoding;
 bh=/pqWt3L3zJMM4n2EqU0p0HRMD76hcn9BE4oD+p6GZcE=;
 b=KQa6fkRFk+KKPYYBQY51wzjBP0zFFF2iNC3FOMno1zZDdhh8aYcK07vgGaNrOnC7Ig
 W8DO2TN0dSIr9I50SbWw0xTY27IJS7IrboE9TeXLzldZAzdeCItHrntuCZynV+jXiQSh
 4Efh2NlDOpt93B0HQBCDSdHcH17udug7f15vwzRQIcqmLeg9JhrEx9VaHT6wR495siHd
 2Kyeww2v2VAgA9UXHfaUM7UExNDnfY+yT+c92zCxGOJ+1eC1BgO7VdGJHYZEvee4PMvn
 CSdFKDs/mXZjqLJipjvvfv/n+iTuCBvc4VGx/k69YYgDKpsV5Ko2y8TvJtFttxTRvyJ7
 m57w==
X-Gm-Message-State: AOAM532Suv645idPHueyUiX4VIAW9F5pK8fgaiQ5uBYqoxhQ+ra+tsf3
 FoqXO82UNOe+quwsS1b7yey/C7/Mo8mFsRZttfU=
X-Google-Smtp-Source: ABdhPJxUYgQpP+UKXu9UzFa6MYuH70CwD/+2DHKPbJ7Zx48mzXVK9UDsYIgvEPv64H+KSBbyGRS197aB1WMLrOQJdVU=
X-Received: by 2002:a9d:6285:: with SMTP id x5mr15639422otk.278.1624154405107; 
 Sat, 19 Jun 2021 19:00:05 -0700 (PDT)
MIME-Version: 1.0
References: <bea8122aea550f1141170829aac252af@riseup.net>
In-Reply-To: <bea8122aea550f1141170829aac252af@riseup.net>
From: James Hilliard <james.hilliard1@gmail.com>
Date: Sat, 19 Jun 2021 19:59:54 -0600
Message-ID: <CADvTj4q42bQ0mTWwdMyJM9UpW57pV0feZk-vYynPu91N_aZSZw@mail.gmail.com>
To: raymo@riseup.net, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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: Sun, 20 Jun 2021 02:00:07 -0000

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? T=
he cheaters must come up in dividing that 1.2 Bitcoin between. After all th=
e 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 sol=
ve 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 perce=
nt 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 a=
void 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 sam=
e 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=3D5344020.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