From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
To: Damian Williamson <willtech@live.com.au>
Cc: "bitcoin-dev@lists.linuxfoundation.org"
<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP Proposal: UTWFOTIB - Use Transaction Weight For Ordering Transactions In Blocks
Date: Thu, 07 Dec 2017 01:46:08 -0500 [thread overview]
Message-ID: <oVWjxK8fBoFl02giOtDPEQ7kAnp9TIRlAJKT14xJ6-VRRVJhT6-UsYLXqBARKUZi-fgRuKgymoTpHuQB5pluZRauX9dPOniJLAC5F6d0jo4=@protonmail.com> (raw)
In-Reply-To: <PS2P216MB0179BC1CDE30F00D73DAA10F9D320@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>
[-- Attachment #1: Type: text/plain, Size: 2084 bytes --]
Good morning Damian,
>As I understand it, each node would be aware independently of x transactions waiting for confirmation, the transaction pool.
Each long-running node would have a view that is roughly the same as the view of every other long-running node.
However, suppose a node, Sleeping Beauty, was temporarily stopped for a day (for various reasons) then is started again. That node cannot verify what the "consensus" transaction pool was during the time it was stopped -- it has no view of that. It can only trust that the longest chain is valid -- but that means it is SPV for this particular rule.
>If next blocksize is broadcast with the completed block it would be a simple matter to back confirm that.
It would not. Suppose Sleeping Beauty slept at block height 500,000. On awakening, some node provides some purported block at height 500,001. This block indicates some "next blocksize" for the block at height 500,002. How does Sleeping Beauty know that the transaction pool at block 500,001 was of the correct size to provide the given "next blocksize"? The only way, would be to look if there is some other chain with greater height that includes or does not include that block: that is, SPV confirmation.
How does Sleeping Beauty know it has caught up, and that its transaction pool is similar to that of its neighbors (who might be lying to it, for that matter), and that it should therefore stop using SPV confirmation and switch to strict fullnode rejection of blocks that indicate a "next blocksize" that is too large or too small according to your equation? OR will it simply follow the longest chain always, in which case, it trusts miners to be honest about how loaded (or unloaded) the transaction pool is?
-------
As a general rule, consensus rules should restrict themselves to:
1. The characteristics of the block.
2. The characteristics of the transactions within the block.
The transaction pool is specifically those transaction that are NOT in any block, and thus, are not safe to depend on for any consensus rules.
Regards,
ZmnSCPxj
[-- Attachment #2: Type: text/html, Size: 2501 bytes --]
next prev parent reply other threads:[~2017-12-07 6:46 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-03 4:07 [bitcoin-dev] BIP Proposal: UTWFOTIB - Use Transaction Weight For Ordering Transactions In Blocks Damian Williamson
2017-12-06 5:18 ` Jim Renkel
2017-12-07 6:34 ` Damian Williamson
2017-12-06 5:46 ` ZmnSCPxj
2017-12-06 9:27 ` Damian Williamson
2017-12-07 6:46 ` ZmnSCPxj [this message]
2017-12-07 8:13 ` Damian Williamson
2017-12-07 20:49 ` Damian Williamson
2017-12-07 21:39 ` Erik Aronesty
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='oVWjxK8fBoFl02giOtDPEQ7kAnp9TIRlAJKT14xJ6-VRRVJhT6-UsYLXqBARKUZi-fgRuKgymoTpHuQB5pluZRauX9dPOniJLAC5F6d0jo4=@protonmail.com' \
--to=zmnscpxj@protonmail.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=willtech@live.com.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox