summaryrefslogtreecommitdiff
path: root/fc/ac07f566fd4fc67c14b99d9a2311b66aba3301
blob: c92b955436089c2e34663c50328d680fef0c6de5 (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
Return-Path: <ctpacia@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 97A5486D
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed,  6 Jun 2018 01:26:38 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qt0-f177.google.com (mail-qt0-f177.google.com
	[209.85.216.177])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 137FD2D5
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed,  6 Jun 2018 01:26:38 +0000 (UTC)
Received: by mail-qt0-f177.google.com with SMTP id p23-v6so4724288qtn.6
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 05 Jun 2018 18:26:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=subject:to:references:from:message-id:date:user-agent:mime-version
	:in-reply-to:content-transfer-encoding:content-language;
	bh=zgMxyO++qXBC3Hy+O5Qu2vW0hgiKk6YwnUXVizVTqRY=;
	b=WGXj2yMGN2QyzSoQ03VG24/0htORKx0c3eLpfkh/XDgG8KMohMQQT5jebaqfP4Mu4P
	+1gYioLhVRqqMybGrBcRrJ4PQnNPniezGfb6MFUiUrZbf0A4PR0O8V8a8r75TunjK8MN
	Ezsa76KLuJJQCLEYgeUg+omvU8r1vZ3HHdJMepZpCyLYkl5NrYcjF87JuNJv3QDPRCSV
	lY8bgrWTJHDz4FHHOnUn9fq7hM88jKg16N8xEcPJpzLRH2dFY0E5sWAkXgTv+EmOAqUC
	E9tAcrIWjLAjGxxB/0tzVWPgpsrN2Ez3TnUeC8TC7jnSml32XabP9ZB2AmpRvOe2wUik
	3W1g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:subject:to:references:from:message-id:date
	:user-agent:mime-version:in-reply-to:content-transfer-encoding
	:content-language;
	bh=zgMxyO++qXBC3Hy+O5Qu2vW0hgiKk6YwnUXVizVTqRY=;
	b=EZzEB39A9bSTqNKX4VUT7ogZN3VrTudcR1AGMhl0cKm0qykOeNWKVD2wCkBkmD6G7v
	8j4O+9hlRhc+9K1PQIhrE8/qEzY+sIwz81g75rAs7LVYjBN2A3YlDRxzOwCvqscsHUWP
	T4bjBYZJX1/6i9n6NUyI67R3hYKJIQTPuz1p6AgYWM2EDds0z9fQYaxIu5zvAGgWRLrt
	GK4Ci/HnnW8Wak6M8G88+sqK+A72u7cgG8WcPGKTxio4azmMpoALrgliI/UziAkMbEx7
	wOXgssfxLIsrmqEiCDdjxdBBEeWeAfqbfNN/UscD6HftIX8zo/DgX5Sj77gOLjGPGFYO
	/bSA==
X-Gm-Message-State: APt69E2FPldT3CgK6Rnw5jkVax4NbGXnWpGBL7fUzA9wi7iOpDR/puUk
	wICwdRrfw29SWSGI+eMsGSUACdAC
X-Google-Smtp-Source: ADUXVKJk+kl+9TMwDKx45/QeCH2iWUeF5qZl7l3mW3HnBZE70/WinFr8vKVxBgWcHpBEbJZughHSxA==
X-Received: by 2002:ac8:2ce3:: with SMTP id 32-v6mr956886qtx.236.1528248396884;
	Tue, 05 Jun 2018 18:26:36 -0700 (PDT)
Received: from ?IPv6:2601:18d:8a01:1110:14e8:31fd:2dfc:6393?
	([2601:18d:8a01:1110:14e8:31fd:2dfc:6393])
	by smtp.gmail.com with ESMTPSA id
	b71-v6sm26220244qkj.89.2018.06.05.18.26.36
	for <bitcoin-dev@lists.linuxfoundation.org>
	(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Tue, 05 Jun 2018 18:26:36 -0700 (PDT)
To: bitcoin-dev@lists.linuxfoundation.org
References: <92215b88-75a4-6be7-dec6-89c567a74a9a@mattcorallo.com>
From: Chris Pacia <ctpacia@gmail.com>
Message-ID: <039bd3d3-c71c-8d40-7456-bc78fc0c7123@gmail.com>
Date: Tue, 5 Jun 2018 21:26:35 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
	Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <92215b88-75a4-6be7-dec6-89c567a74a9a@mattcorallo.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM,
	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
Subject: Re: [bitcoin-dev] [BIP Proposal] BetterHash Mining Protocol
 Replacements
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: Wed, 06 Jun 2018 01:26:38 -0000

Really like that you're moving forward with this. A few months ago I was 
working on something similar as it seemed like nobody else was interested.

In regards to the specific proposal, would it make sense to offer a tx 
subscription endpoint in addition to TRANSACTION_DATA_REQUEST? Such an 
endpoint could respond to the subscription with the current full list of 
transactions and then push the diff every time a new template is pushed. 
A client that wants to inspect and modify the transactions would use 
quite a bit less data than polling the request endpoint.


On 06/05/2018 02:44 PM, Matt Corallo via bitcoin-dev wrote:
> Been working on this one for a while, so its already been through a few
> rounds of feeback (thanks to all those who already have provided feedback)!
>
> At a high level, this meets a few goals:
>
> 1) Replace getblocktemplate with something that is both more performant
> (no JSON encoding, no full transactions sent over the wire to update a
> job, hence we can keep the same CTransactionRef in Bitcoin Core making
> lots of validation things way faster), more robust for consensus changes
> (no need to add protocol changes to add commitments ala SegWit in the
> future), and moves more block-switching logic inside of the work
> provider (allowing Bitcoin Core to better optimize work switching as it
> knows more than an outside pool server, specifically we can play more
> games with how we do mempool eviction, empty block mining, and not
> mining fresh transactions more easily by moving to a more "push" model
> from the normal "pull" getblocktemplate implementation).
>
> 2) Replace Stratum with something more secure (sign messages when
> applicable, without adding too much overhead to the pool), simpler to
> implement (not JSON-wrapped-hex, no 32-byte-swapped-per-4-byte-byteorder
> insanity), and better-defined (a clearly written spec, encompassing the
> various things shoved backwards into stratum like suggested difficulty
> in the password field and device identification by setting user to
> "user.device") with VENDOR_MESSAGEs provided for extensibility instead
> of conflicting specifications from various different vendors.
>
> 3) Provide the ability for a pool to accept work which the users of the
> pool selected the transactions for, providing strong decentralization
> pressure by removing the network-level centralization attacks pools can
> do (or be compromised and used to perform) while still allowing them
> full control of payout management and variance reduction.
>
> While (1) and (2) stand on their own, making it all one set of protocols
> to provide (3) provides at least the opportunity for drastically better
> decentralization in Bitcoin mining in the future.
>
> The latest version of the full BIP draft can be found at
> https://github.com/TheBlueMatt/bips/blob/betterhash/bip-XXXX.mediawiki
> and implementations of the work-generation part at
> https://github.com/TheBlueMatt/bitcoin/commits/2018-02-miningserver and
> pool/proxy parts at https://github.com/TheBlueMatt/mining-proxy (though
> note that both implementations are currently on a slightly out-of-date
> version of the protocol, I hope to get them brought up to date in the
> coming day or two and make them much more full-featured. The whole stack
> has managed to mine numerous testnet blocks on several different types
> of hardware).
>
> Matt
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>