diff options
| author | Christopher Jeffrey <chjj@purse.io> | 2017-04-05 09:54:05 -0700 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2017-04-05 16:54:48 +0000 |
| commit | 640bbfb4152386b4d8aecaa52c9cd7e3f349bc04 (patch) | |
| tree | f3ce8b4fcf7ee640ba867bd2105a711de3ee36a6 | |
| parent | 82a9348d1833dc5919f9f1f5432aa3aa18e3f93c (diff) | |
| download | pi-bitcoindev-640bbfb4152386b4d8aecaa52c9cd7e3f349bc04.tar.gz pi-bitcoindev-640bbfb4152386b4d8aecaa52c9cd7e3f349bc04.zip | |
Re: [bitcoin-dev] Extension block proposal by Jeffrey et al
| -rw-r--r-- | aa/9c137c0d2c34a7e47a13cc075ed770296c1f9a | 367 |
1 files changed, 367 insertions, 0 deletions
diff --git a/aa/9c137c0d2c34a7e47a13cc075ed770296c1f9a b/aa/9c137c0d2c34a7e47a13cc075ed770296c1f9a new file mode 100644 index 000000000..e2b30d3eb --- /dev/null +++ b/aa/9c137c0d2c34a7e47a13cc075ed770296c1f9a @@ -0,0 +1,367 @@ +Return-Path: <chjj@purse.io> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 5F8288D9 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 5 Apr 2017 16:54:48 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-pg0-f41.google.com (mail-pg0-f41.google.com [74.125.83.41]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5FB5314F + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 5 Apr 2017 16:54:47 +0000 (UTC) +Received: by mail-pg0-f41.google.com with SMTP id 21so10869745pgg.1 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 05 Apr 2017 09:54:47 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=purse.io; s=google; + h=date:from:to:subject:message-id:mail-followup-to:mime-version + :content-disposition:in-reply-to:user-agent; + bh=NisEK0HQyjN/NwldYWaZ08SDqiH68YLZG8txFWpQj9g=; + b=Zvreg1GL2M5X8o1I2fdmAteq2kkuPg9sfZqD3ekANidXbDhILO/l8+TMDV2vBdv+d9 + 3x3dNC/wSqLU73nfoDf971JrcnaRPiiImyvN8QcGxImiYOh2vCItruF+8fVuWwbEduv/ + KZ/jLFek0u3HFqtjwpw4x7KNExb1ZdACP45tw= +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20161025; + h=x-gm-message-state:date:from:to:subject:message-id:mail-followup-to + :mime-version:content-disposition:in-reply-to:user-agent; + bh=NisEK0HQyjN/NwldYWaZ08SDqiH68YLZG8txFWpQj9g=; + b=SNQnl3E7+boJR28zpxg6Gs2svefco9LqQTrJGlhunxUgWFxuyUcm7nLxEwSwHISnPB + oz3KQ93lh8KsLdbgqbBTsEw9Z2KsDuwJe4vIxurhJJ6vvXhko0I591HtmwlVCA/jO/Eu + 63OrTxGeVu7qZoZR0ewg+23FqW7Dt66wj6a5p5cDRhfhMgGKanYgic3SUtdGIlY0vAfU + Ne2O8tcI2K4Am0IC12kCo5F1iYV/thKLYgBzHCd1MsKww98KEikQebseKUyu5H7bYCxm + /2OQtsymEf7OAC7zVCqD0752uT/FdawvoTTj6jjC2MYdb6m7WMA8AZHJiK7bpJ3CLDJl + NNfQ== +X-Gm-Message-State: AFeK/H3a/WuFTmVfnhee+W8qQxzNaLDd8yZLzPIUEx6O7AtYZkVcvmhe63Fpe5bonk0jJQ== +X-Received: by 10.98.215.70 with SMTP id v6mr29955669pfl.121.1491411286724; + Wed, 05 Apr 2017 09:54:46 -0700 (PDT) +Received: from gmail.com (96-82-67-198-static.hfc.comcastbusiness.net. + [96.82.67.198]) by smtp.gmail.com with ESMTPSA id + 22sm11555574pfv.42.2017.04.05.09.54.44 + (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); + Wed, 05 Apr 2017 09:54:45 -0700 (PDT) +Date: Wed, 5 Apr 2017 09:54:05 -0700 +From: Christopher Jeffrey <chjj@purse.io> +To: bitcoin-dev@lists.linuxfoundation.org +Message-ID: <20170405165405.GA28519@gmail.com> +Mail-Followup-To: bitcoin-dev@lists.linuxfoundation.org +MIME-Version: 1.0 +Content-Type: multipart/signed; micalg=pgp-sha256; + protocol="application/pgp-signature"; boundary="n8g4imXOkfNTN/H1" +Content-Disposition: inline +In-Reply-To: <201704041803.57409.luke@dashjr.org> +User-Agent: Mutt/1.8.0 (2017-02-23) +X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, + DKIM_VALID, DKIM_VALID_AU, FAKE_REPLY_C, + 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 +X-Mailman-Approved-At: Wed, 05 Apr 2017 16:55:30 +0000 +Subject: Re: [bitcoin-dev] Extension block proposal by Jeffrey et al +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, 05 Apr 2017 16:54:48 -0000 + + +--n8g4imXOkfNTN/H1 +Content-Type: text/plain; charset=utf-8 +Content-Disposition: inline +Content-Transfer-Encoding: quoted-printable + +Hi Luke, + +Thank you for the review. Many of these points should definitely be +addressed in the spec. Although extension blocks has working code, the +spec is currently still in a draft state now and could really use all +the feedback it can get. A few rules are still up in the air before we +setup a public testnet for it. + +There's understandable confusion about this, but this proposal is not +meant to be a BIP. If it were meant to be a BIP, we still might not have +even submitted it yet as it needs a bit more revision still. + +I'm just going to go over a lot of these and explain the reasoning. + +> This breaks the ability to spend unconfirmed funds in the same block +> (as is required for CPFP). + +Yeah, child-pays-for-parent is practically impossible for exiting +outputs. I don't see a good way around this. We tried to figure out a +decent solution while initially drafting this. It's possible with tons +of trickery, but likely not worth it. + +> The extension block's transaction count is not cryptographically +> committed-to anywhere. (This is an outstanding bug in Bitcoin today, +> but impractical to exploit in practice; however, exploiting it in an +> extension block may not be as impractical, and it should be fixed +> given the opportunity.) + +Yes. The merkle commitments are something we could definitely improve. +Open to suggestions. Personally, I don't consider myself a merkle +expert. + +> This needs to elaborate how the merkle tree is constructed. Are all +> the txids followed by all the wtxids (tx hashes)? Are they alternated? +> Are txid and wtxid trees built independently and merged at the tip? + +As of right now, the reference implementation uses the former, but +again, the merkle commitments are something up in the air. It'd be nice +to keep it as flexible as possible for SPV proofs on either the txids or +wxtids. + +> Why? This prevents extblock users from sending to bare multisig or +> other various possible destinations. (While static address forms do +> not exist for other types, they can all be used by the payment +> protocol.) + +Requiring only p2pkh and p2sh for exits reduces the possibility of more +UTXO set size bloat (at least slightly). Non-standard scripts are a +problem since they cannot be compressed for storage. I don't see it as +important to allow naked multisig outputs. Currently, if users wanted to +use a naked multisig (why?), they can always use the 1mb chain directly. + +> Additionally, this forbids datacarrier (OP_RETURN), and forces spam to +> create unprovably-unspendable UTXOs. Is that intentional? + +All outputs within the extension block are meant to be witness programs. +This was done for simplicity. The 1mb chain is still usable for any +OP_RETURNs committed to the chain. More thought on this would be good +though. + +> > The maximum extension size should be intentionally high. +> +> This has the same "attacks can do more damage than ordinary benefit" +> issue as BIP141, but even more extreme since it is planned to be used +> for future size increases. + +> What is a "point"? What does it mean multiplied by a factor of 8? Why +> not just say "8 points"? + +Just for consistency of wording. + +The notion of cost creates a system of points which are multiplied by a +factor chosen by the witness program version. Unknown witness programs +have a factor of 1. If, in the future, we soft-fork in a new witness +program version, its chosen factor could be 7 or 6. The idea being, +future versions could add less "cost" to the block, allowing for +relaxing dos limits over time via soft-fork. + +I would much rather have people arguing over whether to soft-fork dos +limits than whether to hard-fork dos limits. + +So the idea here is, we have a hard limit (say 6mb) for quick sanity +checking and DoS prevention, and a soft-forkable soft limit (e.g. 2mb). + +Having unknown witness program versions be worth only 1 point does +enable the possibility that a worst case block could be up to the "hard" +max extension size limit. This is also a possibility with segwit, but +yes, less severe with segwit assuming the max ext. block size is above +3mb. + +More discussion and running of numbers is probably necessary before we +come up with optimal limits here. + +> Please define "accurately counted" here. Is this using BIP16 static +> counting, or accurately counting sigops during execution? + +It's meant to refer to BIP16 static counting. I believe the actual +argument passed to the function in Bitcoin Core is called `fAccurate`. +Many other implementations use the same terminology. The counting during +execution proposed by Gavin's hardfork BIP isn't widely implemented as +far as I know. + +> Is the size rounded up or down? If down, 72-byte scripts will carry 0 +> points...) + +Rounded up. The code included this earlier, but I took the whole +weighing against size out temporarily. Will be updated to match the +spec. + +> BIPs must be in MediaWiki format, not Markdown. They should be +> submitted for discussion to the bitcoin-dev mailing list, not social +> media and news. + +Yeah, that's sort of a bias of mine. I prefer markdown, and everyone +else helping out with the spec seemed to be okay with my preference. The +mediawiki format is offensive to me. In any case, this isn't really +meant to be a BIP. + +> Extension blocks are more of a hard-fork IMO. + +Could you expand on why you consider this a hardfork? + +> Block time seems entirely unrelated to this spec. Motivation is +> unclear. + +Transaction throughput is related to this spec. Block time and size are +both related to transaction throughput. It's meant to say something to +the effect of "changing retargetting is likely infeasible with a +soft-fork, but changing block size may not be as much of a problem." +Could be reworded. + +> As stated in the next paragraph, the rules in BIP 141 are +> fundamentally incompatible with this one, so saying BIP 141 is +> activated is confusingly incorrect. + +True. Should be reworded. + +> Extension blocks should be compatible with BIP 141, there doesn=E2=80=99t +> appear to be any justification for not making them compatible. + +The implementation initially seemed a lot simpler when moving all segwit +behavior to the extension block. The initial conception was to have all +witness programs be entrances into and scripts within the extension +block, but I guess there's no reason we couldn't do something like +Johnson proposed and have different witness program versions be the +ext-block-only programs. It just involves me rewriting a bit of code in +the reference implementation, and backporting a lot of code to the +original branch. + +> > Note that canonical blocks containing entering outputs MUST contain +> > an extension block commitment (all zeroes if nothing is present in +> > the extension block). +> +> Please explain why in Rationale. + +This can be removed, and something I initially added to my own code +during initial implementation as a simple check ahead of time to check +for entering outputs. + +> > Coinbase outputs MUST NOT contain witness programs, as they cannot +> > be sweeped by the resolution transaction due to previously existing +> > consensus rules. +> +> Seems like an annoying technical debt. I wonder if it can be avoided. + +I think there is a way around it, just not a real viable way: requiring +miners to resolve the witness program outputs in the coinbase 100 blocks +ago. But this will cause miners to attack each other, since they're now +potentially adding size to another miners block. It also causes a load +of other issues with wallets. + +I don't see the coinbase output rule as that much of an issue though. +The 1mb chain will remain the realm of miners and long-term hodlers for +sure. If they want to switch to the ext. block, they can always just +sweep their outputs. + +> Why? Unlike the coinbase, this seems to create additional technical +> debt with no apparent purpose. Better to just have a consensus rule +> every input must be null. + +It's a pretty simple consensus check, and might be a fun extra to have. +The genesis block has a pretty unique mystique to it. Might be fun to +replicate that in the genesis resolution. + +> Transaction versions are signed, so I assume this is actually simply +> -1. (While signed transaction versions seemed silly to me, using it +> for special cases like this actually makes sense.) + +Yeah, transaction versions are just bits as far as I'm concerned. It +depends on how you want to interpret them. But yeah, it would be `-1` if +you were to consider it an int32. My own code just treats them as +unsigned. + +> Should specify that spending such an exit must use the resolution +> txid, not the extblock's txid. + +Agreed. + +> BIPs should not specify policy at all. Perhaps prefix "For the +> avoidance of doubt:" to be clear that miners may perform any fee logic +> they like. + +Mentioning policy as an aside seemed useful here for now for a clearer +understanding. A good deal of this spec may be separated out as some +kind of commentary on implementation details eventually. + +> Since extblock transactions are all required to be segwit, why +> wouldn't this be mandatory? + +That was originally only referring to serialization (segwit allows empty +witness vectors in serialization). I will reword this to refer to +verification only. + +> Note this makes adoption slower: wallets cannot use the extblock until +> the economy has updated to support segwit-native addresses. + +Nested P2SH would be hard to do for the ext. block, short of some added +trickery (miners only redeeming that output for entrance once the redeem +script is revealed). + +> Please explain why 73 bytes in Rationale. + +DER-formatted signature size. "Inputs cost" was originally designed to +reflect sigops. To prevent tons of garbage data in the witness vector, +the vector's size is also considered a "sigop/cost" for every 73 bytes. +It should probably start weighing sigops points and size points +differently though, or treat them as separate metrics. + +> > A consensus dust threshold is now enforced within the extension +> > block. +> +> Why? + +Another measure to potentially reduce UTXO spam. Will clarify. + +> Why wouldn't users set this on all transactions? + +It looks like Laolu beat me to commenting on this. Both Joseph and Laolu +will have better commentary on this than me, so I'll let them handle +this. + +> > The "deactivation" deployment's start time... +> +> What about timeout? None? To continue the extension block, must it be +> deactivated and reactivated in parallel? + +Timeout of 1 year. That may have gotten lost in the frequent revisions +we did. + +Once voting has successfully activated the deactivation bit, the +locked-in time is 26 retarget intervals (approx. 1 year). + +So, the simplest proposal for deactivation we came up with returns the +OP_TRUE to being anyone-can-spend. By that time, a future softfork +(activated in the same versionbit) can introduce code to handle the +migration of funds elsewhere. The anyone-can-spend part does sound +pretty odd at first glance, but it's the only way to get new behavior in +here without a hardfork. + +The merkle proof proposal is tougher, because we would have to write +code _now_ to handle the migration. And since we don't know what future +extension blocks might look like or how they might behave, this is +pretty difficult. + +--- + +I will open a few issues on the repo for some of the points made here. + +-- +Christopher Jeffrey (JJ) <chjj@purse.io> +CTO & Bitcoin Menace, purse.io +https://github.com/chjj + +--n8g4imXOkfNTN/H1 +Content-Type: application/pgp-signature; name="signature.asc" + +-----BEGIN PGP SIGNATURE----- + +iQEzBAEBCAAdFiEEtLH2LbrAhOMz86BKiWKrneZma70FAljlIS0ACgkQiWKrneZm +a73j7wgAlzcw3vge5FhIP9nlB0T/+peLIzuFOwCfeO7YHq1zCOLili8l2WiWXaxR +mpEEh+IAtbe6/3eNsNPkHqQ1gE4Wb5lPL7rzaZnSEvqBeZCWP9Kiu1APoKngkKmN +2ulXqbK3qeiQQLPv0DK2LUnBDuVkMX9RU5bvrfPflgh3QnbNmGveT+JMlCFZjFzW +nDRzvCNehTwCswarUmokPeqgbPTiS2LU2iZ0y20EvcYcm773xz+PIeWiIKYAn2Ad +rXMtimHtPlCWvKG1oPfWCJ359BtBoC+9qieNZxe1ZJHAeBEVB0umlWPsAU5SKGbR +Icj5K8T+wFBRE5QHUCH5vWNQe3QxdA== +=W9mV +-----END PGP SIGNATURE----- + +--n8g4imXOkfNTN/H1-- + |