eduffield
Core Developer
The green clock means the inputs got locked up and are safe from double spending, the check mark means the transaction was included into a block. So there simply was no block event on the network while I was testing.
V12 Testing Thread
- Thread starter eduffield
- Start date
The green clock means the inputs got locked up and are safe from double spending, the check mark means the transaction was included into a block. So there simply was no block event on the network while I was testing.
qwizzie
Well-known member
the checkmarks appeared after he put in a sleep command to wait a few miliseconds between each command .. but IX goes so fast its hard to see that.
So it starts with checkmark, get 5 IX confirmations (pretty much immediately) and will then wait for 6th pow confirmation to conclude the transaction.
eduffield
Core Developer
Fun huh? It's really satisfying to see it work 300 times in a row in 30 seconds :grin:
Sub-Ether
Well-known member
Scary thought, you could empty a mainnet wallet in seconds with a block of IX commands, have to be careful testing that one
eduffield
Core Developer
I take it back, my stress test did get checkmarks (block confirmation) while I was testing:
http://test.explorer.darkcoin.qa/bl...939ce14e1f3cd70ed1ea6c3fc45bcafd1c38db979e538
http://test.explorer.darkcoin.qa/bl...70d4ff37b326fd39597e88bd46dce2ec902e111858d2e
http://test.explorer.darkcoin.qa/bl...939ce14e1f3cd70ed1ea6c3fc45bcafd1c38db979e538
http://test.explorer.darkcoin.qa/bl...70d4ff37b326fd39597e88bd46dce2ec902e111858d2e
eduffield
Core Developer
Yep. Unless you see the green clock without IX, then it's somewhat less safe.
Lukas_Jackson
Active member
:sad:
Sub-Ether
Well-known member
:sad:
Yes I just got that as well after increasing the hash rate by 10 meg, was the network or memory pool overloaded with the higher transaction rate ?
I turned it off btw (Udjin is going to be really upset now)
Lukas_Jackson
Active member
Those itx doesn't hit the blockchain in the first seconds. They are locked by MNs. What is the limit of tx a single MN can lock in the same time? Is there any cap?
Someone please clear that for me.
Someone please clear that for me.
eduffield
Core Developer
It's currently 60 minutes, then it clears the lock. I want to change the way that works in 12.1 though, so it will keep the lock until 6 confirmations. We could have a pretty big backlog and the transactions would still be safe if they were IX confirmed with that in place. That's probably the weakest like of the system at this point.
eduffield
Core Developer
:sad:
Someone is restarting 100 masternodes atm. I saw them drop a few minutes ago. That will break IX
moli
Well-known member
But how many InstantX transactions can one single MN lock in at the same time?
eduffield
Core Developer
Single masternodes can't lock any transactions. First they have to be assigned to a quorum the task of reviewing a transaction, as part of that quorum they can lock 1 transaction. So for example, if there's 3000 masternodes and 3000 transactions , that means each masternode on average would take part in 300 quorums (they're quorums of 10 nodes each).
moli
Well-known member
Thanks, Evan, this is a valuable info to know.
Lukas_Jackson
Active member
So how many tx a quorum(10 MNs) can take? Is it a matter of bandwidth or...please axplain??
If 30000 or more itx hit MN network, what then? Can a MN on average be a part of 3000 quorums or more?
Last edited by a moderator:
eduffield
Core Developer
Sure, the only limit to the system is the amount of memory we have available. But then again, we have a 2-tier network... so we can just require beefy masternodes.