2300+ entries in 0.235s
hanbot:
http://btcbase.org/log/2017-02-19#1615687 << fwiw, receiving wallet does see amt sent. meanwhile
trb restarted with -rescan shows same balance as before, which we now realize *had changed* following transaction just...not by amt sent. to wit, listtransactions sees original balance, sees correct sent amt with fee, nevertheless balance via getinfo has mystery-difference. which shows as a negative, and only value, via listaccounts.
☝︎ mircea_popescu: i'm not entirely sure, but afaik
trb still imports original satoshi assumptive boneheadedness in that it will not consider tx updating its own wallet which it didn't issue itself.
mircea_popescu: i don't think
trb updates your wallet balance in this case. it updates it when it sends something, it doesn't rescan for doublespends.
hanbot: i mean the amt sent to non-
trb wallet is still included in
trb wallet.
hanbot: test tx via
trb using sendtoaddress fails to send diddly squat, meanwhile @ blockchain.info: transaction rejected by our node. Reason:Script resulted in a non-true stack: []
a111: Logged on 2017-02-16 02:49 hanbot: what's the proper name to ascribe to this super fun phenomenon wherein
trb node happily catches up on blocks until 99.x% and then drops connections and stops seeing new blocks after <10mins?
ben_vulpes: so in light of the triviality with which the
TRB node to which mimisbrunnr talks is taken out by even moderately determined actors, i'm considering taking the whole thing down until i have a more robust data collector system in place.
BingoBoingo: Coding patch to simply say "no" to compact blocks and restore
TRB/PRB communion would likely be trivial, BUT setting that precedent is impossibru
hanbot: what's the proper name to ascribe to this super fun phenomenon wherein
trb node happily catches up on blocks until 99.x% and then drops connections and stops seeing new blocks after <10mins?
☟︎ a111: Logged on 2017-02-08 20:46 Reuel: mircea_popescu, i am geting blocks so i guess i built
TRB, what would you suggest i do next? you mentioned mimisbrunnr, looking at that now, anything practical I could do except read?
Reuel: mircea_popescu, i am geting blocks so i guess i built
TRB, what would you suggest i do next? you mentioned mimisbrunnr, looking at that now, anything practical I could do except read?
☟︎ Reuel: does
trb have the bitcoin-cli rpc stuff like the other implementation?
shinohai: Reuel: I'd say Gentoo myself, though
trb *has* built countless times for me on Ubuntu/Debian
Reuel: When I am looking at the
TRB site seals, I see more than one for each patch, does that mean code has been reviewed?
thestringpuller: as of current looks like there are no
TRB nodes responding
shinohai: Strange wheezy won't build
trb ... I did it < month ago without issue.
thestringpuller: mod6: wheezy doesn't want to build
TRB anymore. ping me if you have a specific image that you recommend from the wheezy era
pete_dushenski: my own recent efforts at coding are going less productively. trying to implement polarbeard's 'getpeerinfo' patch and can't even get
trb to show the option on the help menu nevermind implement the functionality
pete_dushenski , very late to the party, wishes for getpeerinfo in
trb ben_vulpes: pete_dushenski: the most i can imagine you'll learn about the differences between prb and
trb without reading the source is that the latter doesn't have a gui
pete_dushenski: i have no such software in operation atm. though i may fire one up just to see what i can learn about the cuts
trb ultimately made.
mod6: I need to get the ball rolling for something like that with
TRB as well.
mircea_popescu: ah. well, from a simple "cs competency" perspective, doing a
trb build first is very good practice. i'll familiarize you with what's here a minimal bar of qualification and anywhere else above the reach of graduate students somehow. and it'll show you the power of the tools and the quality of the engineering.
mircea_popescu: do you understand the bitcoin end of things ? are you running a client ? ever got a v-build of
trb to run for instance ?
a111: Logged on 2017-01-27 19:32 ben_vulpes: davout: reference miner is still in
trb bin.
trinque: the wallet merely generates inputs
trb will validate or not independently of it
davout: asciilifeform:
trb is about keeping the core, prb is about "moar featurez"
ben_vulpes: davout: what /currently/ compiles as the single binary "
trb"
davout: i'm not really sure whether transaction signature itself should stay in
trb or be extracted out
ben_vulpes: i am still not sold on moving the wallet outside of what compiles as "
trb"
davout: asciilifeform: if
trb provides sane endpoints the wallet can be written in whatever floats anyone's boat
davout: if you ~must~ verify one of those sigs you pull up a
trb that can ~fin~
davout: maybe we can have
trb-classic then trollface.jpg
trinque: there are goals at odds here. to fix the nightmare that is current
trb, gotta start slashing til you have something that's able to be comprehended
trinque: "nothing but this particular arrangement of driftwood counts as actual reference
trb"
davout: asciilifeform: the
trb tree has a "continuity-preserving" mission, not "current
trb official version"
davout: asciilifeform: archaeologists can build a verifymessage-capable
trb, couldn't they?
trinque: I don't see that it'd be a terrible sin to have multiple branches descending from current
trb thestringpuller: is there a way to scrape the UTXO set in
TRB or do you have to do that manually as of now?
ben_vulpes: davout: why would you even consider releasing a patch that leaves
trb unable to cook and transmit transactions? keep it on your table where it's useful to you.
davout: asciilifeform: can use same openssl as
trb ben_vulpes: davout:
trb cannot exist in a state where "user must supply code for x"
davout: asciilifeform: to me
trb just has to provide "return txouts spendable by arbitrary set of addresses", "add this transaction to mempool"