Re: [bitcoin-dev] BIP sighash_noinput
On Tue, Jul 03, 2018 at 02:26:53PM +0930, Rusty Russell via bitcoin-dev wrote: > Gregory Maxwell via bitcoin-dev > writes: > > On Mon, Apr 30, 2018 at 4:29 PM, Christian Decker via bitcoin-dev > > wrote: > >> Hi all, > >> > >> I'd like to pick up the discussion from a few months ago, and propose a new > >> sighash flag, `SIGHASH_NOINPUT`, that removes the commitment to the > >> previous > > > > I know it seems kind of silly, but I think it's somewhat important > > that the formal name of this flag is something like > > "SIGHASH_REPLAY_VULNERABLE" or likewise or at least > > "SIGHASH_WEAK_REPLAYABLE". > > I agree with the DO_NOT_WANT-style naming. REUSE_VULNERABLE seems to > capture it: the word VULNERABLE should scare people away (or at least > cause them to google further). The problem with that name is `SIGHASH_REUSE_VULNERABLE` tells you nothing about what the flag actually does. What name are we going to give a future flag that does something different, but is also replay vulnerable? -- https://petertodd.org 'peter'[:-1]@petertodd.org signature.asc Description: PGP signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP sighash_noinput
Gregory Maxwell via bitcoin-dev writes: > On Mon, Apr 30, 2018 at 4:29 PM, Christian Decker via bitcoin-dev > wrote: >> Hi all, >> >> I'd like to pick up the discussion from a few months ago, and propose a new >> sighash flag, `SIGHASH_NOINPUT`, that removes the commitment to the previous > > I know it seems kind of silly, but I think it's somewhat important > that the formal name of this flag is something like > "SIGHASH_REPLAY_VULNERABLE" or likewise or at least > "SIGHASH_WEAK_REPLAYABLE". I agree with the DO_NOT_WANT-style naming. REUSE_VULNERABLE seems to capture it: the word VULNERABLE should scare people away (or at least cause them to google further). Thanks, Rusty. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] An efficient re-implementation of Electrum Server in Rust
Hello all, I was working on this project for the last few months, so a user could run his own Electrum server, with required hardware resources not much beyond those of a full node (using ideas from ElectrumX [1], Electrum Personal Server [2] and bitcoincore-indexd [3]). The code and usage instructions can be found here: https://github.com/romanz/electrs The server indexes the entire Bitcoin blockchain, and the resulting index [4] enables fast queries for any given user wallet, allowing the user to keep real-time track of his balances and his transaction history using the Electrum wallet [5]. Since it runs on the user's own machine, there is no need for the wallet to communicate with external Electrum servers, thus preserving the privacy of the user's addresses and balances. Features: * Supports latest Electrum protocol [6]. * Maintains an index of transaction inputs and outputs, allowing fast balance queries * Fast synchronization of the Bitcoin blockchain (~2.5 hours for ~185GB @ June 2018) on modest hardware [7] * Low CPU & memory usage (after initial indexing) * Low index storage overhead (~20%), relying on a local full node for transaction retrieval * Efficient mempool tracker allowing better fee estimation [8]. * `-txindex` is not required for the Bitcoin node * Uses `rust-bitcoin` library [9] for efficient serialization/deserialization of Bitcoin transactions * Uses a single RocksDB [10] database, for better consistency and crash recovery Hope you'll find it useful :) Questions, suggestions and pull requests are welcome! [1] https://github.com/kyuupichan/electrumx [2] https://github.com/chris-belcher/electrum-personal-server [3] https://github.com/jonasschnelli/bitcoincore-indexd [4] https://github.com/romanz/electrs/blob/master/doc/schema.md [5] https://electrum.org [6] https://electrumx.readthedocs.io/en/latest/protocol.html [7] https://gist.github.com/romanz/cd9324474de0c2f121198afe3d063548 [8] https://github.com/spesmilo/electrum/blob/59c1d03f018026ac301c4e74facfc64da8ae4708/RELEASE-NOTES#L34-L46) [9] https://github.com/rust-bitcoin/rust-bitcoin [10] https://github.com/spacejam/rust-rocksdb ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Alert key disclosure
The bitcoin alert keys are disclosed in this email, followed by a disclosure of various known vulnerabilities in what was once the alert system. The bitcoin alert system has been completely retired. The network is not at risk and this warning may be safely ignored if you do not have an ancient node (running v0.12.x or older) using the deprecated bitcoin alert system or its public keys. mainnet public key: 04fc9702847840aaf195de8442ebecedf5b095cdbb9bc716bda9110971b28a49e0ead8564ff0db22209e0374782c093bb899692d524e9d6a6956e7c5ecbcd68284 mainnet private key: 30820113020101042053cdc1e0cfac07f7e1c312768886f4635f6bceebec0887f63a9d37a26a92e6b6a081a53081a2020101302c06072a8648ce3d0101022100fffefc2f300604010004010704410479be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798483ada7726a3c4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b8022100fffebaaedce6af48a03bbfd25e8cd0364141020101a14403420004fc9702847840aaf195de8442ebecedf5b095cdbb9bc716bda9110971b28a49e0ead8564ff0db22209e0374782c093bb899692d524e9d6a6956e7c5ecbcd68284 testnet public key: 04302390343f91cc401d56d68b123028bf52e5fca1939df127f63c6467cdf9c8e2c14b61104cf817d0b780da337893ecc4aaff1309e536162dabbdb45200ca2b0a testnet private key: 308201130201010420474d447aa6f46b4f45f67f21180a5de2722fc807401c4c4d95fdae64b3d6c294a081a53081a2020101302c06072a8648ce3d0101022100fffefc2f300604010004010704410479be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798483ada7726a3c4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b8022100fffebaaedce6af48a03bbfd25e8cd0364141020101a14403420004302390343f91cc401d56d68b123028bf52e5fca1939df127f63c6467cdf9c8e2c14b61104cf817d0b780da337893ecc4aaff1309e536162dabbdb45200ca2b0a These are openssl-serialized private keys. In 2016, a plan was proposed[1] for the completion of the retirement of the bitcoin alert system which included the idea of revealing the alert system private keys. The proposal still contains good information regarding the purpose and intention of alert system retirement and motivation for the disclosure of the private keys. Additionally, an overview of the alert system retirement and its timeline is available on the web at [2]. This disclosure was recently discussed in an IRC meeting logs at [3]. A media site also recently discussed this topic[4]. One of the reasons for disclosure of the keys is to mitigate the effects of unknown dissemination and proliferation of the keys. By broadcasting the values to make them available to everyone, the value of the keys is intended to be to be eliminated, since now everyone could feasibly sign messages, the value of the signed messages becomes zero. [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-September/013104.html [2] https://bitcoin.org/en/alert/2016-11-01-alert-retirement [3] http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-06-21-19.00.log.html#l-30 [4] https://www.coindesk.com/long-secret-bitcoin-key-finally-revealed/ # Vulnerabilities in the bitcoin alert system The following text[5] discloses a number of known vulnerabilities in the alert system. Writeup contributed by achow101. [5] https://gist.github.com/achow101/18a2dfc371c421419d494a3ae0447f66 The Alert System previously utilized by Bitcoin has several issues (some of which may be classified as vulnerabilities). These issues no longer exist in Bitcoin as of network protocol version 700013 which was released with Bitcoin Core 0.13.0. Many altcoins and Bitcoin client implementations were notified of the Alert System's removal and have since removed the alert system themselves or transitioned to using an Alert system that does not share an Alert Key with Bitcoin. All of the issues described below allow an attacker in possession of the Alert Key to perform a Denial of Service attack on nodes that still support the Alert system. These issues involve the exhaustion of memory which causes node software to crash or be killed due to excessive memory usage. Many of these issues were not known until the Alert System was removed as developers inspected the code for vulnerabilities prior to releasing the Alert Key. Due to these issues, the publication of the Alert Key was delayed and affected altcoins and software were notified. As of this writing, less than 4% of Bitcoin nodes are vulnerable. Furthermore, the Bitcoin Core developers have created a "final alert" which is a maximum ID number alert which overrides all previous alerts and displays a fixed "URGENT: Alert key compromised, upgrade required" message on all vulnerable software. The Bitcoin Core developers believe that so few vulnerable nodes are present on the network, and risks to those nodes so minor, that it is safe to publish the Alert Key. An Alert contains these fields: int32_t nVersion; int64_t nRelayUntil; // when n
Re: [bitcoin-dev] SIGHASH2 for version 1 witness programme
On Thu, May 31, 2018 at 6:35 PM, Johnson Lau via bitcoin-dev wrote: > The bit 0 to 3 of hashtype denotes a value between 0 and 15: > > • If the value is 1, the signature is invalid. > • If the value is 3 or below, hashPrevouts is the hash of all input, > same as defined in BIP143. Otherwise, it is 32-byte of 0x... > • If the value is 7 or below, outpoint is the COutPoint of the > current input. Otherwise, it is 36-byte of 0x... > • If the value is 0, hashSequence is the hash of all sequence, same > as defined in BIP143. Otherwise, it is 32-byte of 0x... > • If the value is even (including 0), nSequence is the nSequence of > the current input. Otherwise, it is 0x. > • If the value is 6, 7, 10, 11, 14, or 15, nInputIndex is 0x. > Otherwise, it is the index of the current input. > • If the value is 11 or below, nAmount is the value of the current > input (same as BIP143). Otherwise, it is 0x. > > The bit 4 and 5 of hashtype denotes a value between 0 and 3: > > • If the value is 0, hashOutputs is same as the SIGHASH_ALL case in > BIP143 as a hash of all outputs. > • If the value is 1, the signature is invalid. > • If the value is 2, hashOutputs is same as the SIGHASH_SINGLE case > in BIP143 as a hash of the matching output. If a matching output does not > exist, hashOutputs is 32-byte of 0x... > • If the value is 3, hashOutputs is 32-byte of 0x... > If bit 6 is set (SIGHASH2_NOFEE), nFees is 0x. Otherwise, it > is the fee paid by the transaction. > If bit 7 is set (SIGHASH2_NOLOCKTIME), nLockTime is 0x. Otherwise, it > is the transaction nLockTime. > > If bit 8 is set (SIGHASH2_NOVERSION), nVersion is 0x. Otherwise, it > is the transaction nVersion. > > If bit 9 is set (SIGHASH2_NOSCRIPTCODE), scriptCode is an empty script. > Otherwise, it is same as described in BIP143. > > Bits 10 to 15 are reserved and ignored, but the signature still commits to > their value as hashtype. > > hashtype of 0 is also known as SIGHASH2_ALL, which covers all the available > options. In this case the singnature MUST be exactly 64-byte. > > hashtype of 0x3ff is also known as SIGHASH2_NONE, which covers nothing and is > effectively forfeiting the right related to this public key to anyone. This seems fairly complicated and yet-- if I don't misunderstand-- it doesn't capture the one special output masking case that I've seen actual applications want (which itself, is one out of the only two special sighash cases I've seen applications want-- the other being no-input). The case I think this is missing is SIGHASH_SINGLE | SIGHASH_LAST_OUTPUT e.g. "Sign the matching output, and the last output regardless of its index". The application for this style is "kickstarter" joint-payment transactions where you wish to sign both your change output (SIGHASH_SINGLE) and the joint-payment output (SIGHASH_LAST_OUTPUT). Without it, this kind of usage requires usually a chain of depth two for each input to split off the change. I came back around to your post at Sipa's recommendation because I was musing on is there a _simple_ set of enhanced sighash flags that capture real useful behaviour without falling down a rathole of specifying a totally general behaviour. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP sighash_noinput
On Mon, Apr 30, 2018 at 4:29 PM, Christian Decker via bitcoin-dev wrote: > Hi all, > > I'd like to pick up the discussion from a few months ago, and propose a new > sighash flag, `SIGHASH_NOINPUT`, that removes the commitment to the previous I know it seems kind of silly, but I think it's somewhat important that the formal name of this flag is something like "SIGHASH_REPLAY_VULNERABLE" or likewise or at least "SIGHASH_WEAK_REPLAYABLE". This is because noinput is materially insecure for traditional applications where a third party might pay to an address a second time, and should only be used in special protocols which make that kind of mistake unlikely. Otherwise, I'm worried that wallets might start using this sighash because it simplifies handling malleability without realizing that when a third party reuses a script pubkey, completely outside of control of the wallet that uses the flag, funds will be lost as soon as a troublemaker shows up (but not, sadly, in testing). This sort of risk is magnified because the third party address reuser has no way to know that this sighash flag has (or will) be used with a particular scriptpubkey. So, one could even argue that the possibility that someone might use this flag means that it's generally unsafe to reuse a scriptpubkey. I don't think the same argument applies for NONE or the single-bug because they render even a single use insecure... The best mitigation I can think of is defence in depth to ensure that anyone who uses this sighash flag understands the consequences. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
