247800+ entries in 0.164s
mircea_popescu: yes,
that's a settled
thing and i see no need
to drag it into
this other discussion and muddy it up.
mircea_popescu: the
thing i proposed would fall in between, so
this'd be
three.
mircea_popescu is contemplating writing an article of
these, with pros and cons etc.
mircea_popescu: anyway.
to not get entirely sidetracked :
the exact sense in which wallet should be separated from rest of
trb needs a lot more
thinking.
mircea_popescu: anyway.
the case
that
the current set of derps doing
the mining will be allowed
to continue remains dubious.
mircea_popescu: thopugh i suspect
the words urge and resist are misemployed.
mircea_popescu: because you simply can't get
the
taint out of
the stupid head. it's born with it, will die with it.
mircea_popescu: this is quite likely how it works,
though
the
taint is currently attached
to
the
txn itself rather
than
the inputs. while supplies last, anyway.
mircea_popescu: notwithstanding
that
those
txn are valid in all respects.
mircea_popescu: anyway,
the point being,
the miner cartel brink-of-war event didn't proceed, but "equipment" derived from it is now widely deployed, and as you can observe it can selectively disappear
txn from
the mempool.
mircea_popescu: unless
there's 17 btc
to dream about and blood in
the water from decapitated project nobody actually gives a shit about
the network.
mircea_popescu: pretty eggregious nonsense, vaguely surprised nobody gave a shit about it
then, but w/e.
mircea_popescu: notwithstanding
that
they are reported as doublespends.
mircea_popescu: now high-s are doublespent automatically by
transactions
that oficially "do not exist",
mircea_popescu: and unsurprisingly,
the one
that got 0est of prb effort.
mircea_popescu: BUT! coinbase selection is
the MOST IMPORTANT part of bitcoin privacy
phf: that seems
tricky, as far as my work is concerned, definitely version 3
mircea_popescu: asciilifeform i don';t
think
the wallet should do only signing. it should also do coinbase selection.
mircea_popescu: or any blocks in general. only you can spend,
therefore only your updates are interesting
to it.
phf: well you have a concept of an airgapped node already. it's
the one where you rely on a whole different networked node
to build a blockchain for you, and inject blocks into your airgapped node for you.
there's hell of attack vector here
though
mircea_popescu: MAYBE something like "only open port is X and only process connects
to it is Y and ALL Y does is push data out so and so" may work.
mircea_popescu: they do not belong on an internet-connected machine,
to be clear.
mircea_popescu: it's just somehow assumed it does ; but
there's no reason for it
to.
mircea_popescu: asciilifeform also acceptable. but in neither
these designs does wallet have access
to blockchain.
mircea_popescu: phf yes but it seems it was at least
tacitly agreed a package of
tools is acceptable rather
than monolith.
phf: but i
think asciilifeform also had an imperative of keeping
trb canonical sourth of all btc knowledge, so
that wallet stays in (so
that you can read and know what wallet even is), but you solve
the separation by starting
the daemon with different flags indicating intended usecase
mircea_popescu: asciilifeform 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."
mircea_popescu: IF
the wallet is correctly implemented (as discussed,
text files etc),
then fixing any problem is
trivial for
the operator.
mircea_popescu: i'm not altogether sure such a drastic separation can be implemented - but it seems
theoretically possible
mircea_popescu: phf in principle wallet has all
the knowledge of blockchain it cares about.
phf: afaik wallet relies on some knowledge of blockchain, so airgapped solution will be a combination of blockchain eater and an augmented wallet. so you have
two parallel nodes red and black. black sits on
the wire and receives
transaction, spitting blocks. you batch carry blocks
to red, red eats
them, you do your wallet operations, pick up serialized byte lists, carry
them back
to black, inject. etc
mircea_popescu: alternatively, wallet could run as entirely separate process, and relay its
txn by connecting
to a node as if it were a node. except it asks for no
txn.
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
a111: Logged on 2016-11-02 03:16 ben_vulpes:
http://btcbase.org/log/2016-11-01#1561232 << 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:
http://btcbase.org/log/2016-11-02#1561808 << 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
☝︎ mircea_popescu:
https://archive.is/LCAnf << even
the most rabid socialists.
the
tinge of schadenfreude, delicious as it may be, is still
the only distinguishing decoration between "tory" and labour.
mircea_popescu: asciilifeform weirdly enough,
the uk press moved
to a "trump will win" stance, from sky
to
telegraph etc.
mircea_popescu: i dunno why
they find it remarkable, it's
the end game for middle class womanhood since well before
the french revolution.
BingoBoingo: In other news Qntra has been sitting at 2100 comments for some
time now.
There's a Qntest going on, so pls
to correct.
mircea_popescu: BingoBoingo
the Alert system having long been long purged << extra words!!!
a111: Logged on 2016-11-02 03:16 ben_vulpes:
http://btcbase.org/log/2016-11-01#1561232 << 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.
mircea_popescu: prolly
the linchpin of
the entire
thing, if we can actually use off
the shelf fs we can almost even proceed.
a111: Logged on 2016-11-02 01:55 mod6: ok, well, at least i've got some breadcrumbs back
to
that great convo lastnight.
jhvh1: BingoBoingo:
Time since last block: 49 minutes and 39 seconds
ben_vulpes: my personal preference, if you can't spot
the foreshadowing in my work, is
to index
the entire set of outputs on "to whom was
this sent"
a111: Logged on 2016-11-01 03:47
trinque: I will be interesting
to hear what ben_vulpes has
to say about
this, given recent block-parsing adventures
ben_vulpes:
http://btcbase.org/log/2016-11-01#1561232 << 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.
☝︎☟︎☟︎ BingoBoingo of
the monthly dispatches most eagerly awaits S.NSA as usual
mod6: ok, well, at least i've got some breadcrumbs back
to
that great convo lastnight.
☟︎ tb0t: Project:
trb, ID: 8,
Type: C, Subject: Remove BDB and integrate BitcoinFS, Antecedents: 6,7,33, Notes: Change
ticket
to integrate
the BitcoinFS, once implemented.
mod6: !%e
trb 8 C "Remove BDB and integrate BitcoinFS" "Change
ticket
to integrate
the BitcoinFS, once implemented." 6,7,33