dApp idea share thread

Well … pray to Saint Google, I do not speak enough English to write in my own words, but I hope you understand.

An application for anonymous payments.

1-Direct shipping - with confidence between the parties -:

  • A wallet is created with an amount to transfer - for example, 5 ethers.
  • The secret contract picks up the private key and sends it, encrypted, to the receiver, k already owns that address without actually having made a transfer.

2- Exchange - without trust between the parties -:

  • The application receives a private key from an Alice wallet (of any crypto, but with the exact amount plus expenses of 2 subsequent shipments) and automatically sends it to a new address (intermediate / floating) created by the secret contract where it sends the amount instantly. In that same shipment the crypto is defined and the value that will close the agreement, as well as the reception address.

  • The offer is published in the exchange.

  • Bob accepts it, sends the corresponding amount to Alice’s address plus the value of 1 tx.

  • Alice receives the payment for her offer … plus one of the two tx that she advanced (Both pay 1 tx in total)

  • The secret contrac sends Bob, encrypted, the private key of the new generated address.

  • If Alice cancels its offer before getting a buyer, it receives, encrypted, the private key of the address that was generated in step 1, with the amount of its offer and the second tx, which was never used.

No mixes, pools, or more work. I’m not a programmer, but, although I’m sure it will be very simple, I hope the idea serves. I just wanted to participate, because I follow the project a long time ago and I go crazy for using applications already.

Greetings and thank you.

2 Likes

Can you be more specific with what type of Events you’re thinking of? A secret contracts can call a function within an ethereum contract with a computation result. However, if you are designing an application that requires event triggers, it may be more efficient to have a relayer model. This way, users submit signed messages to the relayer, the relayer looks for an event or trigger, and when it occurs passes the messages to the secret contract. Feel free to DM me too if you’d rather.

If I understand correctly, the gist of the proposed protocol is that both parties send Enigma encrypted key material – say a wallet key for Ethereum or a tx key for Bitcoin – along with trade metadata. Then, Enigma orchestrates the trade settlement by creating the requisite raw transactions and submitting them to their respective chains. In scenario 2, the proceeds are held by anonymous pseudonym generated for Alice.

If so, yes this pattern makes sense and is well suited for Enigma. We’re currently evaluating an analogous approach for cross-chain atomic swaps (e.g. XMR <=> ERC-20, BTC <=> ERC-20).

I understand how such trade might constitute anonymous payment if one of the chains involved preserves privacy. For example, if Alice buys ETH from Bob in exchange for XMR, she now owns ETH under a pseudonym (which won’t be traceable back to her unless she de-anonymizes it). However, if both sides of the trade involve a public chain, even if Enigma sends Alice’s coins to a newly generated pseudonym, it would be possible to trace back the inputs with relative ease by observing the ledgers. As you alluded to, this issue can be circumvented by integrating something like CoinJoin into the trade settlement, but it sounds like your solution aims to avoid this. Can you please clarify how? Please let me know if I’m missing the point.

1 Like

@ainsley I also assumed that the proposed protocol implies that operators (aka relayers) would coordinate each trade, but this is a good question and I’d like to understand the intent as well. I agree that the operator pattern is well suited for this.

As usual with this pattern, the risk is censorship but it can be mitigated by maintaining a registry of operators. If an operator exerts censorship, the incident will be immediately obvious to the user who may simply select another operator, and report back using the governance mechanism in place.

1 Like

@fredfortier

Unfortunately, I totally ignore any technicalities. I have posted the suggestion because I thought it invited to expose applications including the user’s optics. My apologies if it is not like that - please, indicate it, thank you -.

Otherwise, my approach tried to stress that the classic anonymous blockchains are especially persecuted / monitored because they are supposedly that, payments likely not to be declared … and that is an argument in favor of the regulator, in the eyes of the public, to take measurements.

However, ENIGMA does not involve anonymous / private payments / transactions … but private communications … which is infinitely less fiscally blameworthy and outright legitimate from a personal freedom and privacy point of view … and, therefore, less legally chased by a whimsical regulator. And that always seemed like a good point in favor of Enigma being more “elusive” to regulators capricious.

Once at that point, what I see is that the ideal is to reduce transactions to the maximum possible (although the original approach was a kind of DEX with automatic Scrow valid for exchanges crypto even between different blockchains). And any variable that eliminates creating a new address would limit it even more. (for example: I do not know if an existing address can be converted to “multifirm”, for example … the issue is that if this is possible, transactions could be made without even creating a new address, but rather making it easier for the "receiver "It would have a complementary mechanism on an address, and a quantity stored in it, of course … already existing - which would generate immense financial independence and the impossibility of demonstrating a transfer that, facing the blockchain, would never have been carried out. , although the de facto “possessor” of those funds would have changed -).

In short: A multifirm address - which I suppose is a sum of private keys - must be from its genesis … or could that state be altered on an address whose origin was a single signature? Because we would be talking not only about the impossibility of knowing the owners of a transaction … but of not even being able to demonstrate that such a transaction has existed - which created a contribution of privacy of the most positive before the competition -. (Obviously, the second signature would be created so that the original transmitter, owner of the private keys, could not operate on the original address - the receiver would know the old and the new password … but the one that sends initially, not -)

Anyway, as I do not know if what I propose is absolute technical barbarity, I prefer to leave it in transmitting the general concept that I see in ENIGMA about the privacy of communication … and not of value transaction, an issue that I consider a huge advantage. Surely with those premises, someone with more criteria than me can propose improvements in that direction.

Anyway … Saint Google, pray for us … and that this message, I suppose already complicated by itself, comes in understandable English. :wink:

Greetings and thanks for attention.