94400+ entries in 0.025s
mircea_popescu: give me a non-algebraic set with interesting operations instead.
mircea_popescu: anyway, the useful research in nonalgebraic sets is, at least to my (admittedly limited) knowledge entirely absent.
mircea_popescu: matters not. technological improvement is technological improvement.
mircea_popescu: this item definitely counts for your grand list of trb-isms. on the strength of that, "computable", i ask no more.
mircea_popescu: re the above line : all rings are right out, basically.
mircea_popescu: actually i suspect it can be proven that in any ordered set with two operations which admit distinct id operators / are commutative this property can't exist.
mircea_popescu: it's ~worth nothing that "hurr durr, riong signatures" when i can degraqde it by trying subgroups until i hit yours.
mircea_popescu: there's a very directly computable homomorphism, the item being you know, the algebraic ring.
mircea_popescu: that's where it fails, "but it can't be verified that any subgroup didn't own I5."
mircea_popescu: (i've been thinking about this thing ever since fluffypony first spoke in channel, but hey. i';ve nothing meaningful to show for it.)
mircea_popescu: for the needs of this contortion, K3, K4, K9, K11 is a subgroup of K3, K4, K7, K9
mircea_popescu: ie, if K3 owns input I5, and if K3 signs I5, then it can be verified that the ring composed of K3, K4, K7, K9 a) signed I5, and b) owned I5 to sign it ; but it can't be verified that any subgroup didn't own I5.
mircea_popescu: Let there be private keys K1...Kn. Let there be uxto associated with these, I1..Im so that any one I is associated with one and only one K. let there be a function S, so that the verification function V(Kx, S(Iy)) is always false, or uncomputable, or whatever whereas V(K1..Kn, S(Iy)) is always true if and only if the K Iy is associated to signed it.
mircea_popescu: it would be fine if the security actually grew through being snowed in (ie, 0 difficulty to separate them on block 1, and growing from there each block, for all txn)
mircea_popescu: whereby you can verify one signed, but to find out which requires unwinding the whole graph.
mircea_popescu: anyway. to get back to the discussion, maybe something in the vein of blum's scheme may be applied to the ring problem
mircea_popescu: i'm so fucking frustrated. no mention of hamiltonian cycles, no mention of blum who came up with it, nothing. what the fuck miserable idiot am i, can't reference anything properly.
mircea_popescu: because we were doing a review of possibly weaponizable known problems
mircea_popescu: you may be challenged to either show the hamiltonian in the homomorphic graph, or else to show the homomorphism between the graphs.
mircea_popescu: anyway. the encryption scheme is like this : you generate a large graph with a hamiltonian cycle ; and a homomorphic graph.
mircea_popescu: i derrided it for being impractical but i can't fucking find the discussion
mircea_popescu: and there was a scheme proposed whereby you either show the graphs or the relation ; op keeps challenging you ; each correct response increases the probabiling of truth by a factor of 2
mircea_popescu: well, deciding whether two given graphs are homomorphic is > np.
mircea_popescu: asciilifeform there's this scheme whereby i create a graph, A and a homomorphism of it A'. you get ot see A', and may challenge me
mircea_popescu: (note that the decomposition needn't be Vs but will likely be a homomorphism, which POSSIBLY tyakes us straight to the hardest code known to man, the see-or-pick homomorphisms)
mircea_popescu: tsk. not algebraically either. how the fuck would V(all) work so it's not decomposed into Vi(each)
mircea_popescu: asciilifeform re-reading i am pretty much convinced that the requirement that a) signatures are produced pairwise nevertheless b) no pairwise verification function exists yet c) verification works on a group of them is batshit insanity. might as well ask for a 5 smaller than 4.
mircea_popescu: in FACT, the MORE sigs it uses in a ring, the more expensive the tx fee should be.
mircea_popescu: V(K1, S1)=false, V(K2, S1)=false, .... BUT V(K1,K2,..,KN, S1) = true if and only if K1 signed S1 ; similarily with k2 and s2 all the way to n
mircea_popescu: it's worse than that, by any owner of any k in the list.
mircea_popescu: once stated the pipedream portion is pretty painfully obvious ; but nevertheless, maybe ?
mircea_popescu: asciilifeform this is an "idea" item not a technological object, so bear with me. a "ring signature" is a set of signatures with a) arbitrary cardinality n which has the property that b) while it can be verified the correct signature was offered it c) can't be established wich signature that is.
mircea_popescu: i would still love to see, for what it's work, PROPER ring signatures.
mircea_popescu: "all txn are 2 in 2 out" fixed width txn seems nailed down at this point. i can't see how an argument would work that'd offset the evident gains.
mircea_popescu: lubby coding. better than simple hashing for this purpose. deifnitely.
mircea_popescu: if you ever get kicked out of engineering tower should prolly try out the arts, become draughtsman
mircea_popescu: but just because we're all going to die it does not follow we should go around on stilts and weird beak masks either
mircea_popescu: i dunno. the further you go prng-away from the "quote the nth line in the log", the closer you getr to "my solution to mining is mining+mining"
mircea_popescu: you can't turn out your wife without being married to a whore, alfie.
mircea_popescu: cuz it'll be == the hashing if it's as hard as the hashing.
mircea_popescu: yes, but moreover he'll just keep a few blocks and go for new nonces more often