In theory aeternity transactions are written to the blockchain in 3 seconds or less.
In practice however, how long does it really take a transaction to become “effective”?
Let me expand on this. Most exchanges consider btc txs to be finalized after 6 confirmation at least, dash may requires 20 confirmations, doge required 100 and, as an extreme example, as of right now energi requires 5000 confirmations due to some network instability.
however, Dash has instant send that allows merchants to consider a transaction valid in way less block confirmations.
it is clear to me that aeternity has times as fast as the dash instantsend without needing masternodes, but how secure/safe is it? if I were a business and I got paid in aeternity would I need to wait for it to be in the blockchain? for 7 confirmations? for 20?just one?
I don’t even really understand completely how aeternity manages splits, or if any split chain has had longer blocks. I have seen orphan blocks and transactions moving from one block to another but never a full revert on a given transaction (though I mamight be wrong or may have missed it) since the chain is already mature enough is this somethign that can be calculated?
2 Likes
不要老发问题，好歹你也是社区管理员，要想中国社区管理员学习一下，只拿工资，没事翻译一下，不要这么辛苦，老是提问题，让团队难堪，好么？反正团队也不会正面回答你！你所有的问题目前都是这种状态
I am not a community administrator, I do not get paid by aeternity nor have I gotten paid by them before. I have received donations sometimes, and did make some rewards. I don’t understand where do you get that I have a title of community administrator tho.
1 Like
Yeah, I am an admin in the aeternity group and my only job is to clean out the channel from spam, scams and insults. Basically keeping it clean of trash. But this does not mean I am a member of aetertinity core team, doesn’t mean I get paid for it, and doesn’t mean I am a “community admin”. if anything I am a volunteer telegram janitor.
i don’t appreciate your assumptions and attacks without proof. if you looked at the forum you would see I am of the most aggressive community members (hence why I am a hedgehog) and that I question the aeternity core team all the time.
2 Likes
I haven’t done the math, so these are my personal observations…
Except for one or two exceptional cases (while we were down to effectively only two large mining pools and one of them had bad connectivity to the AE-network) I haven’t seen more than two blocks in chain being orphaned. So most of the time waiting for two key-blocks should be good, of course it depends on what is at stake for larger transactions I’d wait longer maybe 5 key-blocks (on avg 15 minutes) or perhaps even 10.
Since AE uses Bitcoin-NG consensus, with a fast stream of micro-blocks, it is expected to have these micro-forks, as we call them, where the last few (often one or two, but sometimes a handful or more) micro-blocks are discarded when a new key-block is mined. However, since the transaction pool is normally well propagated, and the miners normally prioritize transactions the same, the transactions in the discarded blocks are quickly put into new micro-blocks by the new leader. I.e. transactions quite often shift around but very rarely gets evicted. In theory, since the transaction in case of a micro-fork is moved from one height to the next, it could be that the transaction isn’t valid at the new height and thus doesn’t get re-applied.
2 Likes
Isn’t there a section of this forum for those that are unwilling to communicate in English?
4 Likes
In my middleware I index 1 block behind, as in I intentionally stay away from the top block to prevent the workers to say there are no longer any transactions and that they are done with the block.
This solved most of the cases, but then I had a few where a transaction would be tagged in a block height but it won’t be at that height in the blockchain or where the transaction disappears because it was done in the next block and, as such, has a new transacion hash, for this inconsistency I purge the generation and rescan it. I have seen this a few times but I can’t tell how far back this has happened.
I am seriously thinking I could start a worker that checks if all transaction hashes are valid (for the most recent # blocks? or maybe just the last # transactions) to check for changes in the written blockchain.
But I really wanted someone else to chime in, thank you @hanssv.chain Your information was really useful
I think the confirmation period is strongly dependent on the importance of the transaction for me personally. If it comes with a high amount or it is a contract call that I consider to be important somehow - I would wait for more time. The State Channels’ FSM has a modifyable confirmation period for all on-chain transactions that has a default value of 5. It is a compromise between speed and fork-safety and we expect the default of 5 to be OK for most cases.
Micro forks are the price that we pay for the quick first cofirmation time so those should be expected and all software shall be fork-aware (as it should be anyways).
This solved most of the cases, but then I had a few where a transaction would be tagged in a block height but it won’t be at that height in the blockchain or where the transaction disappears because it was done in the next block and, as such, has a new transacion hash, for this inconsistency I purge the generation and rescan it.
This sounds odd at least. The transaction hash is computed according to the transaction’s contents (authentication method included). It stays the same when the transaction is in the transaction pool of unconfirmed transactions, if it had been included in a block, rejected in a (micro) fork and included again in a different block. Since the transaction stays the same, its hash does not change after the transaction had been authenticated. This is how we track the transaction’s progresss, really. @Kryztoval if this happens again to you, please write a github issue or contact me personally.
Maybe I remember it incorrectly? this was back in Sept 2019.
There were a few transactions that jumped blocks, and I think that the block height was part of the transaction hash, maybe I am mistaken. But I will keep an out out to see if the transaction hash changes, since I really want to show the transaction hashes of the pending transactions.
1 Like
If transaction hashes change depending on which block they’re included that would be a bug, and a particularly nasty one. Please keep an eye on it and if it happens - shout to the core team as loud as you can 
1 Like
