I’d be happy to help create stupid amounts of transactions. I’m in the works for setting up 2 more wallets (one at work, one on digitalocean.com) and using the same simple script to keep up the theoretical push to the transaction limits…
Also, whenever I read your posts, it’s in an Australian accent…
Gnasher bmp02050 The WinXP wallet always greets me with a surprise… I’m glad we tried it out. I was sending a few millions to the Mountain Lion 10.8.3 wallet (btw that can also be added to the testing, it’s mwUpCVp8xuJiZ9rCUULawUg3Pf3mB8rPN4) and all was going smooth until it was XP’s turn. I got a “TX too large” error when trying to send 1MM so i sent 1k instead… which happened to contain around 400 UTXOs:
It went through so i repeated the procedure and got this:
I tried again and it eventually went through (0.075 RDD fee and also around 400 UTXOs), but the failed one is now showing as conflicted:
The next TX was too large at 1k rdd so i did just 500. Fee was 0.037 and ~200 UTXOs.
I have stopped here and still have 4809 inputs so please feel free to advice on what to do next; i’m stopping now that i have the wallet at the “sweet spot”.
Haha thanks i guess… but if there’s one thing i like to do is to push stuff to its limits, and beyond if possible. That’s why i have no girlfriend or wife i guess.
Gnasher Yeah, you told me that BTC 0.9 introduced that… thanks. I’m just wondering why does the wallet/network think i’m trying to double spend, aside from the sheer number of inputs / size of the block.
Didi depending on how fast you are generating transactions, it could be when selecting a large number of transactions that the conflict occurs.
Consider if you create the 2 transactions, between the block time generation (so within 60sec).
Both transactions will be competing to get into the next block.
it would seem that the failed transaction tried to select some of the same UTXOs
Didi Gnasher I have noticed that my inputs have substantially decreased on my wallet with a few thousand inputs per address overnight. I’m not sure, but I think that it has to do with staking. I’ll have to respam my accounts and start taking screenshots of the wallet’s inputs. Finally able to consolidate the few hundred inputs into one address though now…
bmp02050 if your wallet did stake, and it was full of small inputs, they most likely were swept up to make a staking amount. The addree will attempt to maintain pooled amounts in each wallet between 3.6M and 1.5M
For the issue you reported, any other information you could add.
What was the wallet doing at the time? log file.
Can confirm that staking slowly consolidates inputs but it takes lots of time and CPU trashing but then again this is testnet… extremely uneven distribution and really unstable network. On mainnet though this could be a problem… can’t scripts be detected somehow? Services like exchanges and faucets will stil create a lot of burst TXs though so i don’t know how could this be approached.
thanks Didi. When there are lots of inputs, there will be additional work as the wallet looks for transaction inputs (is one of the reasons for txindex being enabled to improve performance).
I might suggest that what you and bmp02050 have been doing with testing is out of the ordinary (in its current form reddcoin network doesnt experience this). But that said, I think this is exactly what BTC network has been hit with in recent weeks. Filling blocks with many low cost transactions. One approach would be to incorporate rate limiting on transactions to slow down acceptance into the network and delay it to a block in the future. On one side we have a network that is already 10 times more capacity than BTC (1 min blocktime vs 10min blocktime) so spilling excess transactions into the next block may be an option.
As I mentioned previously, in block size discussion, this is some of the thoughts that we need to consider in order to grow the network.
Increasing block size is actually a relatively easy task, but we need to consider
impact on storage (increasing 2/4/ 8MB will take extra storage)
impact on CPU to process transactions,
Impact on memory to run a node
impact of incorporating the additional transactions introduced
impact of spamming the network with many low cost transactions
The work that you and bmp02050 have been doing with bombarding the network has been great. And this is the type of actively required to stress test the network. And shake out ideas.
I recently had 2 blocks generated on one of my wallets. Strangely,
this TXID: aefeda60ed48ff21a5f1285282ea7a4b734b9620d81ede917345467b84cf10a4-000 and
this TXID: ea3ab1ddbc863448202d238ca2756188f8fe87469a1f3e81d60ec58a8715a942-000 are within a minute of each other and the generated amounts are exactly the same, right down the the 8th decimal place… This CSV File shows all the generated coins. Not sure if this is a bug, or some sort of absolutely phenomenal coincidence. Either way, I feel as though I should purchase a lottery ticket…
bmp02050 i think you hit an astronomical coincidence
i looked at both transactions that you provided, and they are very similar in value,
given the time between staking, the probability of also getting the same amount would be quite high
Hey, I haven’t been testing the last version of the wallet but on my current one, when looking for recent transactions incoming the from part is “unknown”. So last night I received a substantial amount but cannot thanks the benefactor.
Will it be possible to see who is sending the reddcoin to you in the 2.0 version ?
Also, It just pop-up in my mind, is it schedule to have a live conversion rate in BTC, USD (or other live currency of the user choice) (and taken from poloniex) just under or near the actual total amount of the wallet ?
Hi DeadPool
I am assuming you are looking at the transaction list.
In the current version (v1.4.1), this is not available and as such operates like most other wallets
In the new version (v2.0), this feature is not yet scheduled.
The goal for the first release of v2.0 will be to complete the requirements for the backend and without any of the frontend ReddID code changes.
I will be introducing the frontend to the browser wallet first
So basically for the QT wallet
need v2.0 for the backend services
need v2.1 for the frontend
Browser Wallet
next release will contain ReddID front end features