4 ms·

> Some coins post fake blockchain entries to hamper surveillance I don't get this. How do you post fake entries? Wouldn't the ledger be out of balance, or unba

> Some coins post fake blockchain entries to hamper surveillance I don't get this. How do you post fake entries? Wouldn't the ledger be out of balance, or unbalanced or whatever the correct term for that is? And how are fake transactions identified by the faker?

thisisit 9y ago
I guess the writer got an ELIF and hence the whole thing was simplified a lot. Here's my understanding of Monero - It has the concept of ring signatures. I guess this is what the author is referring to. When a transaction is posted to blockchain it is assigns coins to a public key (generally known as the address). Now what Monero does is that it obscures the end address and hides who the transaction went to. That said, blockchain doesn't exactly use the concept of double boook keeping. So, you don't really have things going to out of balance. I am writing an article on how cryptocurrency transactions work. It it still WIP.
- justboxing 9y ago
  Thanks! LMK when you publish your article.
ubernostrum 9y ago
In other fields, fuzzing data while still maintaining accuracy is a well-established practice. A simple example that fits closely to debits/credits is the "vote fuzzer" on reddit. This was important back when reddit allowed you to easily access not just the point score of a post but also the count of up and down votes. The points are calculated as (upvotes - downvotes), but spambots could take advantage of that to figure out if their votes were really being counted, or being thrown away by the spam detection systems. So suppose the score on a post is currently 20 points with 30 up, 10 down votes. Reload, and you might see 32/12. Or 37/17. The fuzzer would give back fictional always-increasing counts of up/down votes which happened to add up to the correct score. It would also add phantom votes to offset spambots it had detected, so a spambot might see 32/12, issue an upvote, and then see 33/13, where the 13th downvote was a complete fiction invented by the fuzzer, to cover up for throwing away the bot's upvote. Apple's differential-privacy implementation in iOS does something similar; it boils down the metrics it will submit into a fixed-size data structure, then randomly flips some bits before submitting. But the weighting and occurrence of the bit flips is set up so that on average for every time, say, the third bit of a given submission flips from 1 to 0, there will be another submission that flipped its third bit from 0 to 1. This preserves the overall statistics while making it impossible to know which bits of any submission were "real" versus which were flipped by the fuzzer.

thisisit 9y ago

I guess the writer got an ELIF and hence the whole thing was simplified a lot. Here's my understanding of Monero - It has the concept of ring signatures. I guess this is what the author is referring to. When a transaction is posted to blockchain it is assigns coins to a public key (generally known as the address). Now what Monero does is that it obscures the end address and hides who the transaction went to. That said, blockchain doesn't exactly use the concept of double boook keeping. So, you don't really have things going to out of balance. I am writing an article on how cryptocurrency transactions work. It it still WIP.

justboxing 9y ago
Thanks! LMK when you publish your article.

ubernostrum 9y ago

In other fields, fuzzing data while still maintaining accuracy is a well-established practice. A simple example that fits closely to debits/credits is the "vote fuzzer" on reddit. This was important back when reddit allowed you to easily access not just the point score of a post but also the count of up and down votes. The points are calculated as (upvotes - downvotes), but spambots could take advantage of that to figure out if their votes were really being counted, or being thrown away by the spam detection systems. So suppose the score on a post is currently 20 points with 30 up, 10 down votes. Reload, and you might see 32/12. Or 37/17. The fuzzer would give back fictional always-increasing counts of up/down votes which happened to add up to the correct score. It would also add phantom votes to offset spambots it had detected, so a spambot might see 32/12, issue an upvote, and then see 33/13, where the 13th downvote was a complete fiction invented by the fuzzer, to cover up for throwing away the bot's upvote. Apple's differential-privacy implementation in iOS does something similar; it boils down the metrics it will submit into a fixed-size data structure, then randomly flips some bits before submitting. But the weighting and occurrence of the bit flips is set up so that on average for every time, say, the third bit of a given submission flips from 1 to 0, there will be another submission that flipped its third bit from 0 to 1. This preserves the overall statistics while making it impossible to know which bits of any submission were "real" versus which were flipped by the fuzzer.