The direct lead to this article was discussion continued since yesterday. The fundamental basis for it is the observation that the job of the wallet sits in tension with the rest of TRB's use and function, and this tension must be resolved.
The two identifiable ends of the dubious chimera in question are the node and the wallet. The job of the node is to connect to others via the Internet, and to exchange information with them.i The job of the wallet is to prevent others from connecting via the Internetii, which makes the tension quite evident. Getting in the way of a clean cut is the unfortunate circumstance that the wallet actually needs some knowledge of the state of the world.iii
There were to date three approaches proposed, as follows :
I. That the wallet become strictly a signature mechanism, as exactly homomorphic to PGP as possible ; the operator will create the transactions he wishes signed elsewhere (practically speaking, on the node), will convey them over through the method of his choice, the wallet will sign them and the resulting bytepile will be ferried over and be injected into the node.
This option then requires that most of the work involved in transaction creation (importantly - the coinbase selection!) will be done by the node, which is definitionally a low security environmentiv. What's worse, the logical implementation would then have wallet function maintain continuity with the present nonsense, with "more secure" functionality being available as an optional (ie, disusedv) add-on. We might stubbornly insist to call it "the true wallet", but what's in a name ?
II. That the wallet become a solipsistic node. As per previous discussion, fixing the horrible format of the inherited Bitcoin will allow the operator to inject coinbases he owns into his own wallet at leisure (a node can safely track addresses and produce a digest - this is no loss of security). The wallet will then proceed to optimallyvi select coinbases for an arbitrary payment, sign it, and spit out the resulting transaction ready to be conveyed to a node.
This wallet will not "automatically" discover new payments incoming ; but it is my considered opinion that the conflation of the wallet and of that functionality is dumbvii.
III. That the wallet become separated from the node. To quote the author,
a111 Logged on 2016-11-02 03:16 ben_vulpes: log/2016-11-01 << merely that wallet might reasonably be muntzed out of bitcoind proper into block-muncher-and-tx-indexer. topologically very similar to "reindex" and friends, but could eschew "wallet" idiocies involving change addresses and sensible address reuse.
phf i got prototype for that. there's only one method called from entire wallet codebase that injects the prepped up transaction into the general pool. i replaced it (or rather, right now it's augmented) with a shiva foreign call that takes a list of bytes, deserailizes it into transaction, and does the injection
asciilifeform consider posting this
phf yeah, it needs some more work. i think that wallet needs to be augmented do operations via shiva, but then instead of injecting it should do a call out into shiva of a byte list of transaction. once i get there, i'll do a post
This has the advantage that it's so much easier to do. It does resolve most of the primary driver of everyone's work polishing the turd - in that it drains some of the insane swamp that Satoshi left us. Nevertheless it does not actually address the fundamental problem, which is the security profile tension between the two identified ends of the cojoined item.
A possible mix between II and III could be realised in practice, with minimal expense and tools already available - by running two TRB nodes, of which the 2nd is the only one operating a wallet and only connects to the first, the operator realises most of the OpSec benefits of II while also realising most of the savings offered by III.
- The current implementation of this job, to serve all comers equally well and trust their words to the same degree periodically comes under fire in the log, and has in time become somewhat of a cause celebre to illustrate various generalized statements of the larger conceptual problems of socialism. [↩]
- In its most recent formulation,
asciilifeform: it really depends on what you expect out of 'wallet'
mircea_popescu: EXACT same as the derps doing nuke security explained they expect in yest linked article. "that the authorised people can launch easily and no one else can period." bitcoin wallet is very literally superset of nuclear briefcase.
- Unlike say PGP, which is why it works so well on airgapped machines and also how it ended up the fundament of the Republic, and which also should explain why USGtronic innovations intended to undermine this quality (such as "expiring" keys) are so dimly regarded by the discerning lord. [↩]
- And the introduction of value promises to induce the growth of warts and kludges on it. For instance, if the node only does noding, the value for an attacker of getting you confused as to the balance of an address is V. If the node does noding and walleting, the value of the same is V'. Because V' > V, it then follows some extra security measures will have to be taken. Except the node is not prepared to be secure, conceptually, and so basically we've just lied to ourselves here : we pretend to have solved a problem through resolving it nominally, while the thing that the name used to name before we "resolved" things continues to lurk and cause mischief. [↩]
- "Ah man, I dunno about bothering with an airgapped machine, seems overkill. Isn't this 2FA Yubikey good enough ?"
Insecurity by design is too close to USG practice for my taste. [↩]
- The exact criteria for the optimization should be exposed to the operator. Criteria, plural, the space of possibilities should be well covered. If I want to send only from addresses containing a "W" on Wednesdays, I should be able to! [↩]
- If the misfortunes of a fat kid with delusions of technological leadership and his Magic The Gathering Exchange didn't convince you, there's little I can say. [↩]