I suppose Cypherdoc will hallucinate and postulate the possible possibilities (excluding the impossible impossibilities) that Martin Armstrong was in a thread discussion with Meni Rosenfeld and Adam Back in 2014. Or he will ululate that Armstrong using my name TPTB_need_war is claiming to be AnonyMint who was actually another person. Or any permutation thereof including but not limited to the introduction to the plot some Space Cowboys horseback on UFO pixie dust flying carpets dressed in dainty lace lingerie and rawhide boots singing "I'm Too Sexy, for this coin".
The offline double-spend of Chaum reveals identity. Brands also has a mechanism to do that (reveal private key and all attributes, one of which could be identity).
...
The main problem with doing that in bitcoin is if you accidentally send twice (because your client crashes) you lose money. And people keep reusing addresses. These extended addresses would "discourage" address reuse (which some would say is a good thing:)
Note Adam Back replied to me (AnonyMint). The bolded statement (my emphasis) is incorrect. Numerous copies of a signature can be sent without changing the signature. Instead, the reason that penalizing double-spending by revealing the private key won't work for crypto-currency is because we need an ordering of transactions so we know which of the double-spend(s) are invalid, so that the first person paid attains probablistic non-repudiation after waiting for sufficient confirmations. This attribute remains in my radical redesign of mining despite the fact that certain censorship critical attributes can't be 50% attacked as they can be in all existing PoW schemes that I am aware of. In other words, you could create an alternative chain with a 50% attack in my radical redesign of PoW, but if you tried to actually achieve anything with it, the undesired effects would be filtered out. This is what modular design achieves.
I think I conflated with the "respendable commited-tx". The homomorphic encryption was 5 slides above that. So perhaps the HE does not have the flaw I assumed. So it hides payment amounts but doesn't mix outputs from numerous entities. You'd still need CoinJoin for that, which is unscalable. And if you add on-chain ring sigs, then you don't need the HE. Also I don't understand how hiding the amount helps when the amount needs to be same for all those who are mixing in CoinJoin
(otherwise analysis of permutations between input and output amounts can decrease the anonymity set).
So far this looks like another one of those half-baked Gregory Maxwell ideas.
I await clarification.
Links:
https://bitcointalk.org/index.php?topic=509674.0
https://bitcointalk.org/index.php?topic=305791.0
I was pushing too hard for too many days (and too many calories feeding those bad bacteria which drive immunological inflammation), M.S. inflammation flaring-up due to it, thus the incorrect "analysis" above was the result of delirium:
I will be posting a new analysis next.
Thanks Meni for sharing that.
On the historical technical level (not applicable to be implemented in Bitcoin), Adam Back did not mention the double-spending solution where the person who double-spends would expose their identity.
Hal Finney summarized it.
On the historical technical level (not applicable to be implemented in Bitcoin), Adam Back did not mention the double-spending solution where the person who double-spends would expose their identity.
Hal Finney summarized it.
The offline double-spend of Chaum reveals identity. Brands also has a mechanism to do that (reveal private key and all attributes, one of which could be identity).
...
The main problem with doing that in bitcoin is if you accidentally send twice (because your client crashes) you lose money. And people keep reusing addresses. These extended addresses would "discourage" address reuse (which some would say is a good thing:)
Note Adam Back replied to me (AnonyMint). The bolded statement (my emphasis) is incorrect. Numerous copies of a signature can be sent without changing the signature. Instead, the reason that penalizing double-spending by revealing the private key won't work for crypto-currency is because we need an ordering of transactions so we know which of the double-spend(s) are invalid, so that the first person paid attains probablistic non-repudiation after waiting for sufficient confirmations. This attribute remains in my radical redesign of mining despite the fact that certain censorship critical attributes can't be 50% attacked as they can be in all existing PoW schemes that I am aware of. In other words, you could create an alternative chain with a 50% attack in my radical redesign of PoW, but if you tried to actually achieve anything with it, the undesired effects would be filtered out. This is what modular design achieves.
In any case, the concept is sort of inane. Who ever receives a payment can trace all the way back through the chain of payment history of obscured amounts. So afaics the anonymity breaks down over time to eventually 0. Please correct me if I am mistaken.
I think I conflated with the "respendable commited-tx". The homomorphic encryption was 5 slides above that. So perhaps the HE does not have the flaw I assumed. So it hides payment amounts but doesn't mix outputs from numerous entities. You'd still need CoinJoin for that, which is unscalable. And if you add on-chain ring sigs, then you don't need the HE. Also I don't understand how hiding the amount helps when the amount needs to be same for all those who are mixing in CoinJoin
(otherwise analysis of permutations between input and output amounts can decrease the anonymity set).So far this looks like another one of those half-baked Gregory Maxwell ideas.
I await clarification.Links:
https://bitcointalk.org/index.php?topic=509674.0
https://bitcointalk.org/index.php?topic=305791.0
I was pushing too hard for too many days (and too many calories feeding those bad bacteria which drive immunological inflammation), M.S. inflammation flaring-up due to it, thus the incorrect "analysis" above was the result of delirium:
I will be posting a new analysis next.