103800+ entries in 0.025s
mircea_popescu: well in fact, to demand that hashes cover the patch and its context, not merely the patch.
mircea_popescu: you propose we both write the same code on the same patch ? then yes, they come out the same. this is fine.
mircea_popescu: look : your patch will be sha512(#Patch bfffhlerghhl\nalf's words\n) and my patch will be sha512(#Patch bfffhlerghhl\nmp's words\n)
mircea_popescu: nono, just previous patch hash. whenever you sit down to write a patch, you sit down to write it atop a press, or at any rate the situation resulting from a press. that has a "last item pressed" by necessity, and THAT will be your header.
mircea_popescu: that it was supported by some implementation at some point doesn't actually provide it with cognitive content.
mircea_popescu: but this is a->b->c->d(=b). the only reason d is confused with b is because we don't hash correctly.
mircea_popescu: because exactly : yours is legal and fine ; mine is trouble.
mircea_popescu: per doctrine you're supposed to rebase. can still keep for "historical purpose"
mircea_popescu: asciilifeform i specifically want a cycle (n >1) where one element traces back to genesis. it seems to me that because one patch can only identify one antecedent, it is not possible to create cycles for the ~same reason organic chemistry doesn't work on hydrogen and oxygen only.
mircea_popescu: so now. how would one make a cycle whereof at least one element actually traces back to genesis ?
mircea_popescu: but that is not ~the~ genesis ; that is merely the same string of code.
mircea_popescu: thinking about it, is it actually possible to make a cycle where at least one element traces back to genesis ?
mircea_popescu: ordering is provided by hashing ; we're currently not actually using this, no idea why, but whatever. i really mean it when i say the discussion's exhausted itself, im not gonna sit here an' retrace the same circle witcha.
mircea_popescu: you're very kind, but the problem doesn't need that redefinition.
mircea_popescu: (also that it's not currently implemented anywhere, but that's minor. the reason it's not implemented is that it doesn't, at least to my eyes, make much sense.)
mircea_popescu: but any any rate, i think this discussion's exhausted itself, we'll have to see later on what we do about this.
mircea_popescu: ~so long as we ban niggers, politics will work ok. sure, the issue is how to ban them.
mircea_popescu: actually, because of how we build the presses, ALL contexts are "so short" as this one ; in the sense the antecedent hash always suffices.
mircea_popescu: this is because the "same" string (Foo Genesis, modified.) is NOT THE SAME string, depending on the contemplated context. it is a string in 846fdf... and ANOTHER string in whatever other context.
mircea_popescu: i was supposed to go sha512(#846fdfb9d99724efbc97b1d2b519a221df9724dec3375c54913c1853af221c8e5ad5b5b8c38fffe4b654066071eafd8194fe7b86faa5fbadfbf1c5b872e81410 "Foo Genesis, modified.")
mircea_popescu: no, because when I hashed to check your hashes i went sha512("Foo Genesis, modified.")
mircea_popescu: so then all strings S must incluide the antecedent hash. and in this definition string S = foo.txt ; nothing else.
mircea_popescu: then therefore, do you agree with the proposition that signing S as long as S consists strtictly of computer code with no indication of context is a meaningless at best and dangerous at worst activity ?
mircea_popescu: let me approach this matter from a different pov. do you agree that a string S consisting of computer code can be, depending on the context in which it is patched, the right thing or a deliberate subversion ?
mircea_popescu: i don't actually see any of these. to start with, "hash everything" is exactly not what was done in the example. it hashed ~the text~, it did not hash ~the antecessor's hash~. this is the problem. that it doesn't hash everything, but just the text.
mircea_popescu: pff. all items are later than all other items whose hashes they know.
mircea_popescu: yes. this is the point - that order can be introduced by hashing. all items are earlier than all other items whose hashes they know.
mircea_popescu: earlier a knowing later b's hash is equivalent to either time travel or hash breaking.
mircea_popescu: yes, but ordering can be actually implemented by hashing
mircea_popescu: it's not altogether clear why the "hash whole thing, not just parts like fucking bitcoin blocks do" isn't a better solution. moves the clock externality to a strong hash externality
mircea_popescu: yes but this is one of those things you eminently do not wish to solve by human arbitrariety i dun think.
mircea_popescu: but in any case, turns out v actually has a previously poorly understood externality, in the sense of, requires a clock.
mircea_popescu: again : there's no point in discussing solutions as part of discussing problems.
mircea_popescu: because a) conventionally cycle-closing patches aren't to be released and b) anyone involved in a closed cycle gets hung ?
mircea_popescu: in any case i don't want to discuss problems in a marriage with proposed solutions.
mircea_popescu: well this immediately is problematic, because a cycle could be claimed to have been closed more than one way, is the point.
mircea_popescu: asciilifeform so your contention here is that it is not possible to link a to g through a (b..f) set of patches such that (b..f) is a cycle and that two different paths exist from g to a ?
mircea_popescu: i'm not making a positive argument here, and haven't throughout. just trying to examine this thing.
mircea_popescu: you also get guaranteed limited production of patches to 1 per block.
mircea_popescu: (similarly, from a different pov - does this scheme open up cycle-negrate-arbutrage whereby an attacker could go around closing cycles and hoping we misidentify the culprit because of timing issues ?)
mircea_popescu: a is a genesis ; b is built on a ; c is built on b ; d is built on c ; e is built on d ; f is built on b ; g is built on d. now both g->d->e->f->b->a and g->d->c->b->a are valid presses.
mircea_popescu: see, basically the fear here is that we DON'T escape the "swelf aware monstrosity" no matter what we do ; we may merely choose whether its in the comments or "somewhere else" magically.
mircea_popescu: yeah it does add quite a bit of unwanted complexity doesn't it.
mircea_popescu: well yes, but if you do hash mine for them we change the hash.
mircea_popescu: if all patches are required to change a comment line in all files they touch, so that it contains the hash of that patch's intended antecessor ; then it is no longer possible to build cycles without deliberately hash-mining for them (because to close the cycle you will have to at one point claim as anterior an ulterior item).
mircea_popescu: so then why not make it so they are actually impossible ?
mircea_popescu: yes but why should this be enforced at the promise level.
mircea_popescu: specifically whether it shouldn't include a comment requirement as above.
mircea_popescu: this is fine, but the question is whether the specification as extent is correct
mircea_popescu: suppose we had a rule stating that "all patches must include as a comment the patch upon they are to be applied" ?
☟︎ mircea_popescu: yes. so what started all of this in my head, i been trying to lead like three times with "but the problem is :" - we may have a very bitcoin block-esque problem on our hands. specifically, the fact that the hash of a block doth not include the intended hash of its antecessor opens up to a problem we needn't be open to.
mircea_popescu: hm, actually, the hashes don't even check out. how was 702d... produced ?
mircea_popescu: what you can't do is go back in time and agree at the juncture you actually meant to ; but the important point here is :
mircea_popescu: well, you just did my a->b b->a in three elements of which one is spurious after claiming a->b b->a is not it.