im stumped by this… how is 2 seconds possible when 1 block takes more than a minute?
In Bitcoin, a block takes 10 minutes, but the transaction arrives as soon as it’s sent to Mempool. It also happens, for example, with transparent Zcash. If you try to send a transaction to yourself on Trezor, for example, you’ll see the incoming in a couple seconds because their server reads mempool data directly. But with shielded transactions it’s much more complicated. My knowledge is not enough to understand further what the idea is.
Some zec disappear from t1 and the same amount happen to appear at t2?
It is pretty simple to figure out that t1 and t2 are linked.
Ah the “zero confirmation” payment detection.
I had this for my Zebra Racing Game (now discontinued)
It detects a transaction as soon as it arrives on the mempool. In the video (minute 1:38) you can see it takes only 4 seconds for the bet to be detected after the transactions is sent.
But it’s unsafe to assume a mempool transactions is valid. Since it’s prone to double-spending attack.
If the user sends a transaction, and somehow force it to be evicted, the service will detect the transaction on the mempool, but the transaction will never complete, since it no longer exist, the $ZEC will go back to the original sender, then they can use the same $ZEC again.
Yes you are right. Unlike transparent outputs, shielded outputs can only be used after they are included in a block. That prevents “chaining” shielded transactions. I buy a cup of coffee and a bagel in two shops. If I haven’t split my notes in advance, the bagel has to wait.
Hello Hanh, thank you first of all.
This process refers to the fact that the same user is behind t1 and t2 and of course it is also possible that t1 is a user and t2 is a new user,
that means you can send to yourself according to this principle but also to another person
the moment this action is carried out there is no publicly visible notice except the note that at an address “buried ” and a new address “reborn”
But there is no direct connection ain. The only way to see this process is if you explzit know the new address.
Otherwise this buried/reborn transaction is encrypted see example below:
Encrypting the transaction with a symmetric key that is only known to the two addresses involved could actually result in the transaction only being visible to those two addresses.
Here are some possible steps to achieve this:
Key exchange: the two addresses (address A and address B) exchange their public keys.
Symmetric key: The two addresses generate a symmetric key that is known only to them.
Transaction encryption: The transaction is encrypted with the symmetric key.
Transaction transmission: The encrypted transaction is transmitted over the network.
Decryption: Only address B can decrypt the transaction as it knows the symmetric key.
This approach has some challenges and limitations:
Key management: It must be ensured that the keys are generated, stored and transmitted securely.
Privacy: the transaction is only visible to the two addresses involved.
Security: The use of symmetric keys can provide a high level of security.
It is also no problem to hold a large amount of Zec at a transparent address. It’s just important that nobody knows about it and nobody knows it as long as you send or receive your coins according to this principle. Let’s say I have 300k Zec at a transparent address. Now I want to spend 10 Zec, but I don’t want anyone to know that I still have 299990 Zec.
Then 10 Zec must be buried and reborn at a new address of mine. You will never know the address with the 299990 Zec unless I make a normal transaction from that address to you.
Yes, of course, t1 and t2 will always remain visible, but as long as you send and receive via bury/reborn, there is no direct connection unless you explicitly know the new address beforehand and this is not possible or only the case if you perform a normal transaction. Other advantages of this method are the number or quantity of transactions and the coins or addresses that are always in motion…
Of course, this is just a rough idea for now and you are all welcome to contribute to solutions