From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id BD9D5B09 for ; Sun, 10 Mar 2019 17:31:52 +0000 (UTC) X-Greylist: delayed 00:29:19 by SQLgrey-1.7.6 Received: from newmail.dtrt.org (li1228-87.members.linode.com [45.79.129.87]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 243902C4 for ; Sun, 10 Mar 2019 17:31:52 +0000 (UTC) Received: from harding by newmail.dtrt.org with local (Exim 4.89) (envelope-from ) id 1h31qJ-0006aE-U6; Sun, 10 Mar 2019 13:02:31 -0400 Date: Sun, 10 Mar 2019 13:01:34 -0400 From: "David A. Harding" To: Karl-Johan Alm , Bitcoin Protocol Discussion Message-ID: <20190310170134.wtml7zuezfadb6hu@email> References: <939C132D-8599-4258-8F14-62E992BA9F51@mattcorallo.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="vetfcgxswkvxammn" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 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: Mon, 11 Mar 2019 16:43:23 +0000 Subject: Re: [bitcoin-dev] Signet X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2019 17:31:52 -0000 --vetfcgxswkvxammn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Mar 10, 2019 at 09:43:43AM +0900, Karl-Johan Alm via bitcoin-dev wr= ote: > Keeping the PoW rule and moving the signature would mean DoS attacks > would be trivial as anyone could mine blocks without a signature in > them Sure, but anyone could also just connect their lite client to a trusted node (or nodes) on signet. The nodes would protect the clients from missing/invalid-signature DoS and the clients wouldn't have to implement any more network-level changes than they need to now for testnet. For people who don't want to run their own trusted signet nodes, there could be a list of signet nodes run by well-known Bitcoiners (and this could even be made available via a simple static dns seeder lite clients could use). > On Sat, Mar 9, 2019 at 5:20 AM Matt Corallo > wrote: > > A previous idea regarding reorgs (that I believe Greg came up with) > > is to allow multiple keys to sign blocks, with one signing no reorgs > > and one signing a reorg every few blocks, allowing users to choose > > the behavior they want. >=20 > Not sure how this would work in practice. This post from Maxwell could be the idea Corallo is describing: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-August/016= 348.html I read it as: - Trusted signer Alice only signs extensions of her previous blocks - Trusted signer Bob periodically extends one of Alice's blocks (either the tip or an earlier block) with a chain that grows faster than Alice's chain, becoming the most-PoW chain. At some point he stops and Alice's chain overtakes Bob's fork as the most-PoW chain - User0 who wants to ignore reorg problems starts his node with -signet -signers=3D"alice", causing his node to only accept blocks from Alice. - User1 who wants to consider reorg problems starts his node with -signet -signers=3D"alice,bob", causing his node to accept blocks from both Alice and Bob, thus experiencing periodic reorgs. - There can also be other signing keys for any sort of attack that can be practically executed, allowing clients to test their response to the attack when they want to but also ignore any disruption it would otherwise cause the rest of the time. - As an alternative to particular signing keys, there could just be flags put in the header versionbits, header nonce, or generation transaction indicating how the block should be classified (e.g. no_reorg, reorg_max6, reorg_max144, merkle_vulnerability, special0, special1, etc...) (If something like this is implemented, I propose reserving one of the signing keys/classification flags for use by any of Bitcoin's more devious devs in unannounced attacks. Having to occasionally dig through weird log messages and odd blocks with other Bitcoin dorks on IRC in order to figure out why things went horribly sideways in our signet clients sounds to me like an enjoyable experience. :-) -Dave --vetfcgxswkvxammn Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEgxUkqkMp0LnoXjCr2dtBqWwiadMFAlyFQu4ACgkQ2dtBqWwi adOvtQ//aPjfLL7Vfw/5ggiPoukEVhAHpc0hB8gHHWHqGa4aQUcCtkJhRhkTsFdf r/dYRh2XUX2eYh9sE2ZSnaKH1rJ6jo+gM+UxoTWYWv9eJbEobObgMaMg4qqch3JA I0INwljXXbuOYbRZGUp0/F0jB0Kc0kqsVpEbDorsUt0x+zFOuC5XDzIzEo2hJm8I N58UNDOi8TO5Rn2oL1PvH5p/hoDdb8RqSNSefFcMvEgLQ3XBJYV0hgpSBPXJhKpj k0joHgm+qL0lRW8mIFA/ZrTsMlHc2GDBkbA935egQ1xWSbBWxmPezUte+Ch2UFmI aCjdWe5awgtsd8JWI4essqJlLfQ0Q9QkHJtEiniZAPk17A4b93XGQRkewW5zwjom T2DYu5LGAS+hAqX4/Imjm1Xon224Dd+AvzyY8tioqeHy/v6Zm1iNaCdX4CgMnJaD SV8ENEyMIIyd+1IRcOH5IXRislSAxUe72ebHzXN9k61PWf1ceZOEQ/0sQekrYpiQ FKkZkYTlvPCEvduwoMUYILea2YvS0SlyltAHcJ1FLdtFVk+Iyo69D6+lPfCSCJyB 7E6zoxFSm8xprtzEqzIKDsTsusfch5vnWUoss9X6ao/Fvx3ogS+BAG4xtWLeahDY 3aMwRHid+YDVLbeM3kKgGxykm9u3tf1J6/S7mWwpEZaU5wz5Cos= =WUai -----END PGP SIGNATURE----- --vetfcgxswkvxammn--