summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorPieter Wuille <pieter.wuille@gmail.com>2012-06-10 01:10:55 +0200
committerbitcoindev <bitcoindev@gnusha.org>2012-06-09 23:11:04 +0000
commit00e9dc625dd4a315e2bcf1883fa82d8bb1e467a9 (patch)
tree4dccb9f3c236333617f693a348d89dcf26e382ee
parent9f742d58ad51e3c54f420ee9e2140d2d247f1205 (diff)
downloadpi-bitcoindev-00e9dc625dd4a315e2bcf1883fa82d8bb1e467a9.tar.gz
pi-bitcoindev-00e9dc625dd4a315e2bcf1883fa82d8bb1e467a9.zip
[Bitcoin-development] getmemorypool
-rw-r--r--c3/1eb0847cfaac7103214c750ccbd5bef21acf16167
1 files changed, 167 insertions, 0 deletions
diff --git a/c3/1eb0847cfaac7103214c750ccbd5bef21acf16 b/c3/1eb0847cfaac7103214c750ccbd5bef21acf16
new file mode 100644
index 000000000..97e255c07
--- /dev/null
+++ b/c3/1eb0847cfaac7103214c750ccbd5bef21acf16
@@ -0,0 +1,167 @@
+Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
+ helo=mx.sourceforge.net)
+ by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
+ (envelope-from <pw@vps7135.xlshosting.net>) id 1SdUoC-0000pn-GU
+ for bitcoin-development@lists.sourceforge.net;
+ Sat, 09 Jun 2012 23:11:04 +0000
+X-ACL-Warn:
+Received: from vps7135.xlshosting.net ([178.18.90.41])
+ by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
+ id 1SdUoB-0001hd-EE for bitcoin-development@lists.sourceforge.net;
+ Sat, 09 Jun 2012 23:11:04 +0000
+Received: by vps7135.xlshosting.net (Postfix, from userid 1000)
+ id B8F39618A3; Sun, 10 Jun 2012 01:10:55 +0200 (CEST)
+Date: Sun, 10 Jun 2012 01:10:55 +0200
+From: Pieter Wuille <pieter.wuille@gmail.com>
+To: bitcoin-development@lists.sourceforge.net
+Message-ID: <20120609231054.GA16966@vps7135.xlshosting.net>
+MIME-Version: 1.0
+Content-Type: text/plain; charset=us-ascii
+Content-Disposition: inline
+X-PGP-Key: http://sipa.ulyssis.org/pubkey.asc
+User-Agent: Mutt/1.5.20 (2009-06-14)
+X-Spam-Score: 1.2 (+)
+X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
+ See http://spamassassin.org/tag/ for more details.
+ 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
+ (pieter.wuille[at]gmail.com)
+ 0.0 DKIM_ADSP_CUSTOM_MED No valid author signature, adsp_override is
+ CUSTOM_MED
+ -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
+ domain 1.2 NML_ADSP_CUSTOM_MED ADSP custom_med hit,
+ and not from a mailing list
+X-Headers-End: 1SdUoB-0001hd-EE
+Subject: [Bitcoin-development] getmemorypool
+X-BeenThere: bitcoin-development@lists.sourceforge.net
+X-Mailman-Version: 2.1.9
+Precedence: list
+List-Id: <bitcoin-development.lists.sourceforge.net>
+List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
+ <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
+List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
+List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
+List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
+List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
+ <mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
+X-List-Received-Date: Sat, 09 Jun 2012 23:11:04 -0000
+
+Hello everyone,
+
+Luke's getmemorypool/BIP22 pull request has been open for a
+long time, and didn't receive too much discussion.
+
+I think that having a stable and flexible API for negotiating
+block generation is important to be standardized. The fact that
+it allows moving block generation to specialized programs is a
+step in the right direction. However, it seems to me that too
+few people (myself included) understand all the details of
+BIP22 (or don't care enough) to judge their necessity. I gave
+up trying to follow all design decisions some time ago, and as
+it seems I'm not alone, nobody liked merging support for it in
+the Satoshi client. This is a pity, and I hope the situation
+can be improved soon.
+
+I'm sorry for being this late with these comments, but I think
+it's essential that the standard is not more complex than
+necessary (making it as easy as possible to write either
+servers or clients for it), and perhaps even more important,
+that its purpose and intended use cases are clear.
+
+From what I understand, the three subrequests are template,
+proposal and submit. The general idea is that
+ 1) a miner requests a block template
+ 2) builds/modifies a block based on this, and optionally
+ uses propose to check whether the server is willing to
+ accept it before doing work
+ 3) submits when valid proof-of-work is found
+I'd like to see this process described in the BIP at least,
+it too me way too long to extract this.
+
+Regarding the block template: is there a particular reason
+for sending the full transactions (serialized in hex) both in
+templates and submissions? The server will always need to have
+access to the transaction database anyway, and clients will
+(afaics) rarely care about the actual transactions. My
+suggestion would be to just transfer txids - if the client is
+interested in the actual transactions, we have the
+gettransaction RPC call already. This seems to be captured by
+the several "submit/*" and "share/*" variations, but making
+it optional seems way more complex than just limiting the API
+to that way of working.
+
+That's another thing that bothers me in the standard: too many
+optional features. In particular, I understand the usefulness of
+having some flexibility in what miner clients are allowed to
+modify, but I'm unconvinced we need 10 individually selectable
+variations. In particular:
+* coinbase outputs: can we just add a list of required coinbase
+ outputs (amount + scriptPubKey) to the template? If no
+ generation+fee amount remains, nothing can be added.
+* coinbase input: put the required part in the template;
+ miners can always add whatever they like. Is there any known
+ use case where a server would not allow a client to add
+ stuff to the coinbase?
+* noncerange limiting: if coinbase input variation is not
+ limited, there is certainly no reason to limit nonceranges.
+ This adds unnecessary complexity to clients, in my option.
+* time/*: put a minimum and maximum timestamp in the template
+ (i believe those are already there anyway). Anything in
+ between is valid.
+* transactions/add: what is the use case?
+* transactions/remove: i'd just standarize on having all
+ transactions be removable (perhaps except those marked
+ 'required').
+* prevblock: one getmemorypool per new block shouldn't be
+ a problem imho, so do a longpoll instead of having the client
+ able to modify prevblock themselves.
+
+One more thing that I do not like is often several ways for
+specifying the same behaviour. For example, txrequires specifies
+that the first N transactions are mandatory, a 'required' field
+in the transaction list itself specifies that that transaction is
+mandatory, and the lack of transactions as variation means that
+they must not be touched at all. Pick one way that is flexible
+enough, and discard the others.
+
+In summary, I'd like to see the standard simplified. I have
+no problem merging code that makes getmemorypool compliant to
+a standard that is agreed upon, but like to understand it first.
+
+In my opinion - but I'm certainly open to discussion here - the
+standard could be simplified to:
+* getblocktemplate: create a new block template, and return it.
+ The result contains:
+ * bits, previousblockhash, version: as to be used in block
+ * curtime, maxtimeoff, maxtimeoff: client chooses a timestamp
+ between (curtime - local_time_at_receipt + local_time),
+ decreased by mintimeoff and increased maxtimeoff
+ * expires, sigoplimit, sizelimit: unchanged
+ * subsidy: amount generated (5000000000 for now)
+ * coinbaseaux: what generated coinbase's scriptSig must start
+ with
+ * coinbaseoutputs: list of objects, each specifying a required
+ coinbase output. Each has fields:
+ * amount: sent amount
+ * scriptPubKey: hex serialized of the output script
+ * transactions: list of object, each specifying a suggested
+ transaction (except for the coinbase) in the generated block.
+ Each has fields:
+ * txid: transaction id
+ * depends: list of dependencies (txids of earlier objects in
+ this same transactions list).
+ * fee: fee generated by this transaction, which increases the
+ max output of the coinbase.
+ * required: if present, transaction may not be dropped.
+* submitblocktemplate: submit an object containing a hex serialized
+ block header, hex serialized coinbase transaction, and a list of
+ txids. Returns true or string describing the problem. Proof of
+ work is checked last, so that error is only returned if there is
+ no other problem with the suggested block (this allows it to
+ replace both propose and submit).
+
+Are there important use cases I'm missing?
+
+--
+Pieter
+
+