5

There are benefits to both users and developers to having Bitcoin Core split into separate node, wallet and GUI processes. As Alyssa Hertig outlines here the benefit to users will be being able to run the Bitcoin Core node on a different machine to the Bitcoin Core wallet rather than being forced to run them on the same machine. A user could leave a node ...


4

The scriptSig field of a coinbase transaction is special. It doesn't need any signatures at all, as no coins are being spent. The ability to produce new coins, which that input represents, is inherent to the protocol - every block is allowed some fixed amount of produced coins. Requiring a signature on it would be wasteful and pointless. Which key should we ...


4

When you import a key, you can mark it as trusted. Usually, you would do this after meeting the owner of a key and verifying that they actually control the key, e.g. at a CryptoParty. Since it is infeasible for each user to verify every other user in person, PGP/GPG leverages a "web-of-trust" to establish connections between keys. E.g. Alice has ...


3

MAST/TAPROOT SCHNORR These improvements are specified in BIP340, BIP341, and BIP342. These documents are fairly mature, and there seems to be community traction for them (though, disclaimer: I may be biased as I'm a co-author), but it's inherently hard to predict when activation will happen. Submarine Swaps This is a Lightning feature, as far as I know. ...


2

NOTES: Heigh and Version fields Fields height and version are needed to identify Outputs if they are last spent in the Transaction outputs. In older revxx.dat files, only if Output was last unspent in a Transaction it's height will be there together with it’s Transaction’s Version. If it's a regular Output then the height field will be 0 (00 HEX in Varint ...


2

It does not need to as the coinbase transaction of each block does not spend any other transaction, hence does not need to satisfy the conditions set by the scriptPubKey of an existing output.


2

BIP 342 does exactly this (Thanks Pieter)


2

Since it was set to an error by Satoshi and not a SUCCESS, this would be a hardfork for all clients in-between no matter if this was already used onchain before. Just imagine a miner with the new software (which redefines VER as SUCCESS) mining a transaction containing such an OP. All the clients between 0.3.5 and the new one would refuse the block, while ...


1

No because the opcode 186 (0xba) is undefined for SegWit version 0 spends. You can only take advantage of this opcode in SegWit version 1 spends. If you included this opcode in your SegWit version 0 transaction script any attempt to spend it would encounter this script error.


1

It is De facto standard that address should not be reused. Indeed. and even Bitcoin officially emphasis address should not be reused. There is nothing official, anywhere, in Bitcoin. Does the same condition apply for Multi-signature address ? Yes. If Yes apart from privacy what is the need ? Privacy - for you and those you interact with - is pretty ...


Only top voted, non community-wiki answers of a minimum length are eligible