log☇︎
2500+ entries in 0.235s
mircea_popescu: http://btcbase.org/log/2017-01-01#1595094 << wallet needs to be fixed, which yes reduces to not much reuse of the current item, but you can't have trb without a means to pay. the miner is iffier business, and really i can't conceive why it'd be a priority. let it be, do useful things besides. ☝︎
asciilifeform: and no, turning python into a trb dependency is not sane.
a111: Logged on 2017-01-01 10:33 davout: ben_vulpes: can you point me to the thread where "keep the miner in trb" was discussed?
davout: ben_vulpes: can you point me to the thread where "keep the miner in trb" was discussed? ☟︎
davout: in other news imma sink some time in documenting the merciless wallet code excision that I think is the right(tm) approach for TRB
asciilifeform: (spoiler: it comes from your system clock +/- the voodoo delta that trb comes up with using peers)
asciilifeform: ergo no trb node will ever reject a tx for reasons pertaining to 'locktime' garbage.
mircea_popescu: davout trb does not implement any of the prbisms. this means that ANY innovation included by the power rangers is a "while it lasts" thing, and building on top of it is setting one up for tears.
davout: asciilifeform: so you're saying a block including a transaction with locktime > block height is considered valid by trb ?
mircea_popescu: no, actually, trb should apply the above scheme EXACTLY like how v applies patches : you populate a wot with acceptable addresses
davout: trb should be able to shit list of unspent outputs, optionally filtered by address
davout: anyway, i guess my position basically boils down to: "as far as trb proper is concerned, best wallet is no wallet. but sane indexing mechanisms"
a111: Logged on 2016-12-30 19:46 davout: trb being able to list utxos given a bunch of addresses would be pretty obviously needed
ben_vulpes: any sane trb that doesn't index tx on output address i suppose
asciilifeform: and in any sane future trb.
asciilifeform: even in the oldest trb.
davout: trb being able to list utxos given a bunch of addresses would be pretty obviously needed ☟︎
asciilifeform: my contention is that a trb with entirely removed unspent-selector is not usable-naked.
asciilifeform: if trb is not usable NAKED, it ain't trb !
davout: i didn't say it had to come *with* trb
davout: script it on top of trb, don't integrate it directly in there is what I think is the correct solution
davout: i content that these should be the ~only~ knobs at trb level
davout: yeah, ben_vulpes told me in your very chan, if i can help it i'd be happy to, it does sound like a pretty good starting point for me to hack on trb
davout: hence my previous questions about the state of this particular functionality in trb
mod6: jurov: http://thebitcoin.foundation/trb-howto.html
davout: i'm still curious what would make this kind of setup where i script "prb dumpblock | hex2bin | trb eatblock" much faster than syncing from network if the bottleneck is indeed the block verification?
ben_vulpes: http://btcbase.org/log/2016-12-30#1593697 << scripting is too much work, just manually dump every block and then manually load it into trb once the previous eat completes. nice meditative activity ☝︎
davout: but then, how can it vastly improve sync time to feed blocks from same machine instead of letting trb suck them from the network?
davout: what's the syncing bottleneck on trb's side?
davout: ah yeah, i'm currently syncing off ben_vulpes, i was wondering if dumping blocks from prb and then eating them with trb would work
davout: http://btcbase.org/log/2016-12-30#1593472 <<< trb -> trb only possibru, or could prb -> trb also work? ☝︎
asciilifeform: mircea_popescu: if you think trb is a hard nut to crack, picture reading, grasping postgres.
a111: Logged on 2016-12-30 09:13 davout: out of curiosity, how long did it take trb node operators to fully sync?
davout: out of curiosity, how long did it take trb node operators to fully sync? ☟︎
a111: Logged on 2016-12-29 23:08 asciilifeform: also i see some 'connect() failed after select(): Connection refused' which iirc is bleeding edge prb kicking trb out
ben_vulpes: otherwise trb may decide to ask utter randos for blocks
davout 's trb node is now up and apparently syncing at 62.210.206.141
asciilifeform: but it is also not clear to me whether this can be done and the result still referred to as 'trb'.
asciilifeform: one theoretical solution to every type of blackhole other than the (theoretical) 'nsa sprays shit directly into the pipe on the backbone' is to make trb actually multiprocess
asciilifeform: i suppose for completeness one ought to include a '5' -- foolish folx who think that 4GB / non-ECC ddr4 / etc. is a trb node
asciilifeform: type2 ( pete_dushenski's ) is the garden variety shitflood. which is sometimes solved by ip ban, but only in the case of 'shrapnel addressed to occupant', i.e. idiot prb nodes wildly spamming crapolade, and not in the 'bullet with your name on it' case, where somebody actually has a sybil constellation drowning your trb node in liquishit, with no SINGLE ip misbehaving in any way ☟︎
mircea_popescu: this'd make some fine subject of a priority work order, the only problem is that it's so intricate and we aren't fans of doing the work n times. but once trb sits down on a sql-fs it would all fall in place.
ben_vulpes: asciilifeform: any idea how prb identifies a trb node?
asciilifeform: also i see some 'connect() failed after select(): Connection refused' which iirc is bleeding edge prb kicking trb out ☟︎
pete_dushenski: mircea_popescu: i don't disagree from a philosophical standpoint but nor can i tolerate having dead fucking trb nodes. that i should have to reboot a machine ~daily~ is the death of bitcoin. yukoners never had it so bad.
asciilifeform: no diff on trb
pete_dushenski: now-frozen machine has lots of cores, lots of ram, and is running trb.
asciilifeform: davout: it was exactly the same snore as in early trb
pete_dushenski: speaking of tagging, looksee what i spotted at the base of a lamp pole recently : http://www.contravex.com/wp-content/uploads/2016/12/TRB-everywhere.jpg
mircea_popescu: you know, exactly how trb work proceeds also.
mircea_popescu: the legacy bdb is still in trb TO THIS DAY
phf: it follows the existing naming convention of thing-genesis with "genesis" reserved for trb
asciilifeform: and asciilifeform doesn't even sit in trb-foundation!
asciilifeform: i already get grumbles that trb is an asciilifeform-vertical.
asciilifeform: mircea_popescu: this destroys the ability to see that we in fact returned to genesis. has it occurred to you to wonder why even to have patches at all? why not everyone just signs the entire hindenburg titanic of trb every time he changes a line ?!
asciilifeform: (i.e. stuffing all of, e.g., trb, into one long document)
mircea_popescu: ben_vulpes which of the trb genesis seals are seal and which reseal ?
jurov: to introduce it into trb would, in my understanding, would make folks apoplectic
mircea_popescu: i perceive no benefit to, eg, getting everyone to use mod6's or alf's or anyone else's v implementation, as opposed to the present situation ; just as i perceive no advantage to getting everyone to make "his own" trb.
mircea_popescu: http://btcbase.org/log/2016-12-22#1587923 << i am fwiw satisfied that it's qutie mroe than this : vs aren't on btcbase because they don't fundamentally belong on btcbase, because unlike public trb "we all use this" they're private "my girl will dance the way ~i~ want her to dance and stfu". there's a much more limited set of rules re what vtrons should do ; than re what trbs should do. ☝︎
asciilifeform: ( recall, we had been trb-ing with exclusively signed patches since start of trb, but folx other than asciilifeform were having headache determining the correct order to apply in )
mod6: and in the context of trb, I would end up with, currently, just genesis.vpatch pressed out in 'output_press_dir'
mircea_popescu: asciilifeform to be precise : i can't turn the greek string into an english string for you for the same reason you can't turn trb into lisp code for me. "but alf, it compiles! a lisp version must exist!" hurr. i don't propose "because you can't take object code and make me lisp source it follows no c sources existed" do i ?
asciilifeform: 'trb condom'
asciilifeform: looks almost as if it'd be a skin , front end running tcpwise in front of trb node
a111: Logged on 2016-12-20 20:10 asciilifeform: at a certain point, if you attempt the operation, you start to ask 'why is there satoshi crapolade in my bitcoin2.0' rather than 'ooh neato, a repaired trb!'
asciilifeform: at a certain point, if you attempt the operation, you start to ask 'why is there satoshi crapolade in my bitcoin2.0' rather than 'ooh neato, a repaired trb!' ☟︎
asciilifeform: and then realized that the resulting patch WILL be 50,000 lines, and the output will look ~nothing like trb, and gave up.
asciilifeform: which is where a trb node is actually hanging for 10-50% of a given day.
asciilifeform: mircea_popescu, ben_vulpes, et al : the pill that would be needed to cure the locks retardation once and for all (and enable, e.g., queueing) while preserving semantics, would be to go through each and every function call in trb and determine if it A) Reads state B) Modifies state C) both D) neither
ben_vulpes: all of a sudden i want to collect data on how long trb takes to return from a simple getinfo call, per your above protocol
asciilifeform: at one time i ran a barbaric experiment where same box would run ~two separate~ instances of trb
asciilifeform: the one caveat is that this is probably not doable while preserving trb semantics.
asciilifeform: i'll add to this that in trb as we have it, you ONLY need blockchain to verify a potential mempool tx
tb0t: Project: trb, ID: 35, Type: I, Subject: Investigate blackhole, Antecedents: , Notes: Investigate what might be occuring with the so-called black-hole, described here: btcbase.org/log/2016-12-20#1586635
mod6: !%p trb 35
mod6: !%a trb I "Investigate blackhole" "Investigate what might be occuring with the so-called black-hole, described here: btcbase.org/log/2016-12-20#1586635"
mircea_popescu: at the very least block digestion and peering must be cleaved in trb ☟︎
asciilifeform: mod6: trb isn't multithreaded in the, e.g., apache, sense. it services clients round-robin style, and if it gets stuck at any point, this is what you get
ben_vulpes: might be interesting to patch trb to dump relevant connection's self-identification string
ben_vulpes: but i mean blackholing as artifact of some other poorly written client, instead of script opening sockets to trb nodes
ben_vulpes: sure, trb shoulda been aborted
tb0t: Project: trb, ID: 33, Type: F, Subject: Possible DB Replacement with UNIX Filesystem, Antecedents: , Notes: http://btcbase.org/log/2016-11-01#1561093
mod6: !%p trb 33
tb0t: Project: trb, ID: 34, Type: F, Subject: Configure Checkpoints by Configuration File, Antecedents: , Notes: Allow for a user to set a given checkpoint within a configuration file. See discussion: btcbase.org/log/2016-12-20#1586436
mod6: !%p trb 34
mod6: !%a trb F "Configure Checkpoints by Configuration File" "Allow for a user to set a given checkpoint within a configuration file. See discussion: btcbase.org/log/2016-12-20#1586436"
mod6: <+davout> did we just add tmsr-db on the todo? << there is a ticket for this: http://thebitcoin.foundation/tickets/trb_tickets.html#6
ben_vulpes: entirely unrelatedly to anything else, does trb's `getmemorypool' actually work?
trinque: speaking of killing yourself, the db design for trb deserves *long* thought
trinque: worked fine; I move deedbot to trb to lean on trb
asciilifeform: davout: chances are there is a crackpot pseudoimplementation of bitcoin in every language, cobol, malbolge, befunge, by this point. they are of 0 interest because not trb !
asciilifeform: it is in re the earlier gedankenexperiment. say trb operators stuck to the 'grandfather's pistol' principle entirely, and kept no record, other than current copy of blockchain, of the past. no checksums, etc.
asciilifeform: well presently trb nodes ~aren't~ operating strictly on 'race to the swiftest', they have the ancient checkpoint thing.
asciilifeform: current trb, by default, nails down the early (300k?) blox
asciilifeform: well not per current trb!
asciilifeform: ben_vulpes: i have nfi why you and mod6 did not pick it for a release, can only answer for myself. yes, the hardcoded header checksums thing is ridiculous. but no, there is such a thing as a historic, immutable planet earth blockchain, and trb ought to include default-on sanity check of ~some~ kind for long-ago blocks.
ben_vulpes: embarassing as it is that i'm only now finding that trb doesn't solipsistically mine, i did determine that it validates the whole chain.
asciilifeform: ben_vulpes: all of the blocks in my chain validate per trb. (at one time i suspected that they would not -- but they do.)
asciilifeform: incidentally all of asciilifeform's public trb nodes descend from that one.