-
knaccc
UkoeHB_ yes, anyone could copy the subaddress tags and put them where they don't belong. i'm thinking that that could affect anyone that used the those duplicated tags, but not the actual person whose tags were used. therefore it's kinda like spamming the entire blockchain with outputs and hoping you control enough that someone you are targeting gets unlucky and uses lots of your sybil ouputs as
-
knaccc
decoys
-
UkoeHB_
knaccc: it could be a targeted attack, if you receive an output from someone and suspect they can be traced back EABE: E->B->A->E. Receive an output from B, then make some pollution outputs with the various subaddress tags found in B's transactions' inputs. If B sends some more transactions to E that use A-inputs, there is a good chance he will use E's pollution outputs as decoys, letting E narrow down the
-
UkoeHB_
real input.
-
knaccc
UkoeHB_ ah i see what you're saying, you're right. so there is a vulnerability to an active targeted attack that can be made on someone that sends you funds.
-
knaccc
UkoeHB_ i think this solves the problem: when anyone sends to an address, they take a hash of the address and treat it as a private key 'y'. They then publish Y=yG as the address tag, and a schnorr signature that demonstrates they knew the 'y' and therefore that they knew the address that the output was destined for. Now someone else can't pollute the blokcchain with outputs it is pretending are
-
knaccc
destined for that address tag, because it doesn't know what the address actually is
-
knaccc
now in an EABE scenario E could still pollute the blockchain with outputs destined for address tags that are the customers of the exchange, where it knew the addresses of those customers because E is sending outputs there
-
knaccc
but that does mean that those hundreds of subaddress owners would notice this pollution, and therefore notice that someone that knows some of their subaddresses is attempting to pollute the blockchain, and could warn others of the attack
-
knaccc
so if the exchange ever did try this attack, it would be noticed
-
tevador
knaccc: sounds interesting, although that would require about 96 bytes per output
-
gingeropolous
pretty cheap in the grand scheme of things. slap that together with some triptych and you got yourself a.... something
-
knaccc
tevador yes, although if you agree with the proposition that you may have seen discussed here before that schnorr signatures only need to be 48 bytes, then we can shave 16 bytes off
-
knaccc
still, any extra bytes per output sucks
-
knaccc
i.e. ed25519 has a security level of 128 bits, therefore having a hash >128 bits provides no benefit - see
neven.org/papers/schnorr.pdf end of page 2
-
knaccc
tevador re: syncing outputs in 20 mins, the surge in tx volume is relatively recent. If a device can do 1000 varbasescalarmults/sec (my high-end laptop tops out at about 3000), then at the current rate of 225k new outputs a week, that's only about 4 minutes per week of outputs right now. but if we go 50x tx volume from here, then that's a 3.1 hour wait for every week of txs that need to be
-
knaccc
scanned
-
knaccc
i.e. almost an entire week of CPU to scan a year of outputs
-
ErCiccione[m]
-
tevador
knaccc: yes, 128-bit scalar is enough, so that would be 80 bytes per output
-
tevador
knaccc: of course even GPU-accelerated sync doesn't come anywhere near the UX of "instant sync" that would be possible with tagging