102400+ entries in 0.751s

mircea_popescu: it doesn't illustrate all pressables that are, but
a sort of all pressables that could ever be.
mircea_popescu: so if we're drawing and leaf Z requires
a in state 3 and we're at state 4, that's it for Z.
mircea_popescu: anywya : as the graph progresses past the antecedent of
a leaf, it therefore goes outside the event horizon of that leaf.
mircea_popescu: (event horizon is the boundry whithin which phenomena can affect the observer) << this is
a much less intuitive, if technically correct affirmative statement.
mircea_popescu: ok, more practically speaking : the graphatron is
a visualizer of individual patches event horizons. how about that.
phf: antecedent relationship goes backwards though. x<-y perhaps means y points at x as
a parent without x's knowledge
phf: the second meaning is, and that one comes up since we have multiple files to
a patch, in order to press x i need both y and z.
mircea_popescu: right. and in the example given, X->Z (or rather, Z > X) is not
a connection to origin.
phf: and ~not~ anything related to
a working press
mircea_popescu: i mean socially. whether we have
a technical problem or not is part of the problem.
mircea_popescu: and phf has
a point in that it's not even
a very well understood one.
mircea_popescu: still, this is
a problem in search of
a good solution.
mircea_popescu: back to the issue of substance. the idea is that whatever any current implementation may do,
a situation where : 1) X takes
A from 1 to 2 and B from 1 to 2 ; 2) Y takes
A from 2 to 3 and B from 3 to 3 and 3) Z takes
A from 2 to 4 and B from 3 to 4 should be represented as X->Y->Z only, and not as X->Y->Z, X->Z
phf: well, there's no issue with that graph presentation, because it produces correct press. it's just that graph is "meaningless" without the toposort. visualizing it doesn't answer any question beyond "this and that share
a hash"
mircea_popescu: irl fragile parts like windows get
a paint X on them, but here no such luck.
a111: Logged on 2016-05-08 14:15 phf: that's the behavior of the original v where the graph doesn't communicate any additional information beyond "shares
a hash"
phf: that's the behavior of the original v where the graph doesn't communicate any additional information beyond "shares
a hash"
☟︎ phf: mircea_popescu: i don't think that's
a bug, that's more of
a conceptual thing.
mircea_popescu: phf so basically you found
a bug in mod6's perl implementation of v ?
phf: so the fact that Z requires b 3 is irrelevant, since Z also requires
a 1
phf: in v's definition of antecedent, the only requirement is "share
a single hash"
ben_vulpes:
http://archive.is/637lm << unrelatedly, don't you want to stay at the cow cave? the akita house? perhaps the host of the kangaroo treehouse's beguiling pose will entice you into
a rental. if none of those appeal, consider pug palace, cow boat, or the cottage cheese cottage
mod6: ben_vulpes: is there
a way to get around this?
mod6: Oh, and
a cat! Which, in absolute fairness, was by far the most intelligent local present. << haha
mircea_popescu: back in ro glory days there were
a few people in various ministries doing just that
mod6: shinohai: dangit. i curl'd that wotpaste and i got
a different hash output
ben_vulpes: it's only ever made sense to me in the context of pressing
a specific patch.
phf: i need to just write this stuff up, but at this point i'm leaning towards the idea that you can't really make
a better graph than "shares
a hash", and all that communicates is that "this guy uses content from this other guy"
phf: v's graph says "these two patches share
a common hash", but that doesn't mean that one can be pressed on top of another in isolation
phf: so you can do
a single pass (and that's what my graph does) to eliminate all the edges that have conflicts
phf: X and Z share
a's hash, but they have conflicting b hashes
phf: because X and Z share
a's hash, X and Y share b's hash, Y and Z share b's hash
phf: patch Z takes
a from 1 to 8, b from 3 to 4
phf: patch X takes
a from null to 1, b from null to 2
phf: say you have two files,
a b. patch X takes
a from null to hash 0 and b from null to hash 0
ben_vulpes: > press as
a graph transition << would you elaborate?
phf: but that doesn't guarantee
a clean press as
a graph transition. it only guarantees clean press when you topo sort the graph
phf: in ascii's v graph edge means "share
a common hash"
mod6: thats not
a bad test we wanna try to break this fucker
ben_vulpes: that edges mean patches share
a common hash
mod6: i just tried dumping
a priv key from an invalid bitcoin address, error says: 'error {"code":-5,"message":"Invalid bitcoin address"}'
mod6: some day im gonna have to write
a boatload more cucumber tests for this shit
mod6: i just tested trying to dump
a key from an address not in the wallet and it says:
phf: note that the graph edge can actually have multiple different meanings. on mod6 graph, an edge means "patches share
a common hash". on my graph edge means "patch can be applied on top of other patch without conflict"
mod6: heh, that's
a good thing (tm)
shinohai: back, yeah sometimes it acts
a little weird when you import keys, like mine will hang
a really long time.
mod6: not the end of the world. the whole thing needs
a rewrite anyway.
mod6: i tried to reimport that same key - it gave me an error, which, it probably should, but it's
a bit non-descript.
mod6: ok so this thing dumped out
a privkey just fine.
mod6: it's
a bug though. gotta dig into it. we have
a ticket for it.
shinohai wishes we still had testnet in
a way. :/
mod6: (its been running for /
a while/)
mod6: if I use the raw patch from the deal press pukes on an unmatched hash. (
a new feature! lol)
mod6: shinohai: that dpaste above was for you, should be good to go, need to recompile the orchastra with this included and test
a bit...
mod6: is there
a base link to this page? should be something like trb.btcbase.org or something
mod6: b: your link with patchset=stable looks correct at
a glance. your chart is
a bit different than mine
mod6: alright. so,
a: i was looking at whatever was listed at btcbase.org/patches/funken_prikey_tools/
phf: so i suspect that whatever differences in press are
a result of press algo. also funken is in an experimental set, and that's all the patches that i saw floating around that are not in the official release and not have been explicitly deprecated
mod6: that'll get me
a good review of the code changes anyway.
mod6: ;;later tell trinque your thoughts on this are much appreciated. hit me up when you get
a chance to think on it.
a111: Logged on 2016-05-07 19:50 mircea_popescu: apparently there's
a /download/ too but not linked from anywhere.
mircea_popescu: apparently there's
a /download/ too but not linked from anywhere.
☟︎ mircea_popescu: to click... or not to click. this is the BingoBoingolema. whether tis safer in silence to suffer the links and twinkles of outrageous rotundity, or to take
a stand against
a sea of blubber and, by refusing to click, forever disown them.
mod6: shinohai: ha, that guy made
a mint for that.
mod6: i'll be back in
a bit
mod6: alright Gentlemen, i gotta run to do this yard trimmings here for
a bit.
shinohai: Not hard to setup, I just need
a btc addy I can use for signing only. I tend not to reuse addys and misplace them >.<
shinohai: I need to make
a damned coinbr account this weekend too if I'm gonna continue my Qntra experiment.
mod6: pm worked for me yesterday when i got booted from 'sandstorm' or whatever. i have noticed from time to time though, it just takes
a bit to respond.
shinohai: I can put list of trusted nodes, etc on my site if we need them. Not sure who said they were going to make
a new wiki page. :/
mod6: don't hesitate to drop me
a line if you find something thatneeds an update.
mod6: oh good, thanks for reviewing those. there's
a bunch of work in there we really need.
shinohai: Some of the foundation pages need tweaking too, I think I noticed old #b-
a refs in them
mod6: was just looking for non b-
a steps for rain to follow to get reg'd in deedbot