This issue is the ratio of the min RingCT tx size ~13000 bytes to the min effective blocksize 60000 bytes. This forces a very high penalty for an additional tx and causes the backlog. The hardfork addresses this by increasing the min blocksize to 300000 bytes which will allow a RingCT tx ~13000 bytes to pay its penalty if the tx is added at just over the new 300000 byte min effective blocksize provided this tx uses the new 4x default fee or a higher fee. The new default fee at 4x when the median blocksize is below 300000 bytes is 80% of the old default fee at 1x when the median blocksize was below 60000 bytes. This should allow for smooth blocksize scaling for txs that pay the default or higher fee. The result is that a tx paying the default fee (4x) should under normal circumstances have no problems getting mined. There is a now a cheaper option (1x) where in exchange for the lower fee the sender accepts the risk of delay and under certain rare circumstances the possibility it may not get mined at all. I should point out that if there is a very sudden sharp increase in tx demand and a fast confirmation is important then paying the higher 20x fee or even 166x fee may be appropriate. That is after all the purpose of the higher fee levels. Thanks for the deeper explanation. While I'm talking to someone on the development team (assuming the little tag under your username tells it true) I've been wondering something. With regard to the question of scaling, as it stands right now I have websites requesting values like 0.1232827374 XMR and it makes the transaction have so many senseless inputs. It makes me wonder. Has there been any thought on the part of the development team of restricting the denominations? If it were restricted down to around the value of a penny or a dime or some smallish but not too small denomination, and permanently ratcheted up one decimal place every time the minimum resolution became to course, it would help with scaling a great deal I think. This may have been a tall order in the past, due to the friction associated with rolling out forks, but FP has pioneered a relatively smooth method for rolling out forks so maybe we should consider? You are correct that, without RingCT, such a transfer would have caused a lot of outputs (because Monero used denominations to the power of 10 for "conventional" transactions), which are subsequently used as inputs and cause the transaction size to grow. That is, the more inputs are used in a transaction, the bigger the transaction will be (ceteris paribus). However, with RingCT enabled you can use that 0.1232827374 XMR as a single input in a subsequent transaction. Thus, with RingCT enabled (and later on enforced) it would be unnecessary to restrict the number of decimal places. |
|
|
|
When I send 1 XMR, 100 XMR is sent and 99 XMR comes back.
How can I limit or lower the amount for sending coin?
It's quite annoying that I can't send next payout immediately because all coins are sent temporarily.
Is a bug from wallet daemon? Or intended?
I'm using v0.10.1.0-release.
That entirely depends on the kind of inputs your wallet owns. Think of inputs as bills. If you only have a $100 bill and try to buy something worth 1$ you'd need to use the $100 bill and you'll receive $99 as change. Monero works similiarly. If your wallet only has a 100 XMR input it will use this input to transfer 1 XMR to the recipient. The change will then be 99 XMR minus the fee. Thus, this is simply how Monero works and intended. I presume you are running a mining pool. Therefore, over time, you should receive a lot of (relatively) smaller inputs from the coinbase transactions (block rewards + fees of transactions included in the block). I'd advise the simply be patient. Your situation will eventually resolve itself and you'll be able to make quicker payments. Yeah you are right. This is pool's wallet. I also thought like your answer before because I've experienced with other similar coins. Monero pool was launched at last december, ran about less than 3 months, found 1892 blocks currently. What I don't understand is that pool was able to send coins frequently at pool launch. But now I see more and more bigger chunks as time passes. Almost all coins are sent and came back for just 1~3 payouts. So I have to wait for them to arrive. Problem is getting bigger, not smaller. This is weird from my perspective. So I assumed that maybe I configured something wrongly. Maybe some recommended parameters for sending coin? mixin? unlock_time? And is it recommended to use "sweep_dust" method? or not? FYI, I used v0.10.2.0 and downgraded to v0.10.1.0 due to fork issue some days ago. Maybe problem started after that. Then you should have sufficient small inputs to make consistent payouts to your miners. However, it could be that the selection algorithm is picking the big input. Adjusting those parameters won't make a difference for the selection algorithm. Also, it seems unlikely that the downgrade caused your problem. Like I said before, it will probably resolve over time. Alternatively, if you aren't already doing so, try to payout to multiple addresses (recipients) in a single transaction. If you don't know how to do this type "help" into monero-wallet-cli and subsequently scroll down to the "transfer" command. There will be an explanation on how to pay out to multiple addresses (recipients) in a single transaction. |
|
|
|
When I send 1 XMR, 100 XMR is sent and 99 XMR comes back.
How can I limit or lower the amount for sending coin?
It's quite annoying that I can't send next payout immediately because all coins are sent temporarily.
Is a bug from wallet daemon? Or intended?
I'm using v0.10.1.0-release.
That entirely depends on the kind of inputs your wallet owns. Think of inputs as bills. If you only have a $100 bill and try to buy something worth 1$ you'd need to use the $100 bill and you'll receive $99 as change. Monero works similiarly. If your wallet only has a 100 XMR input it will use this input to transfer 1 XMR to the recipient. The change will then be 99 XMR minus the fee. Thus, this is simply how Monero works and intended. I presume you are running a mining pool. Therefore, over time, you should receive a lot of (relatively) smaller inputs from the coinbase transactions (block rewards + fees of transactions included in the block). I'd advise the simply be patient. Your situation will eventually resolve itself and you'll be able to make quicker payments. |
|
|
|
Can I delete p2pstate.bin.unportable and poolstate.bin.unportable ?
I'd just leave them for convenience. Is there any reason you'd want to delete them? |
|
|
|
I finally got around to installing win64 monerod 0.10.2.1 'ERROR - block recognized as orphaned and rejected' It's trying and failing to update my 0.9.4 blockchain lmdb. Incompatible? Is there a quick fix, or should I delete and start over? I wasn't paying attention in class  I think the 0.10.x release moved from leveldb to lmdb, as a default option, and this option has now been removed. There are blockchain import/export tools you could use, or start a fresh blockchain download instead. Monero has always used LMDB as its database (well, since the first Hydrogen Helix release (0.9.0)). If I recall correctly, the database format changed though between version 0.9.4 and 0.10.0. @explorer, it's generally advised to resync from scratch if you are coming from 0.9.4. Thus, delete your old blockchain (data.mdb) and monerod will automatically resync from scratch. |
|
|
|
Do you guys ever have delayed sends from the Monero Windows GUI wallet? I sent 4 transactions in 20 minute period (2 large and 2 small) and the 2 small ones were sent quickly and the other 2 disappeared for 2 hrs and then were shown in my transaction history with a time 2 hrs past the other small ones.
For visibility, I posted this in the speculation thread: The 2 smaller ones were probably included in a block earlier, hence the perceived delay. This, for instance, could've been caused by those transactions having a more attractive fee per kB ratio. Alternatively, it could've been simply random. If you enter your transaction hashes into https://xmrchain.net/ you can see in which block they were included. |
|
|
|
Do you guys ever have delayed sends from the Monero Windows GUI wallet? I sent 4 transactions in 20 minute period (2 large and 2 small) and the 2 small ones were sent quickly and the other 2 disappeared for 2 hrs and then were shown in my transaction history with a time 2 hrs past the other small ones.
The 2 smaller ones were probably included in a block earlier, hence the perceived delay. This, for instance, could've been caused by those transactions having a more attractive fee per kB ratio. Alternatively, it could've been simply random. If you enter your transaction hashes into https://xmrchain.net/ you can see in which block they were included. |
|
|
|
Ever seen an error like this when running monerod? ERROR {2} {p1} 2017-02-23 10:29:33.958635 [abstract_tcp_server2.inl+515 ::do_send_chunk] send que size is more than ABSTRACT_SERVER_SEND_QUE_MAX_COUNT(1000), shutting down connectionCould you paste the outputs of the "diff" and "status" command? Also, is it still fetching new blocks? |
|
|
|
To prevent this, I'd suggest to comment on the Github issue too. Stuff on reddit gets buried pretty fast. In addition, the search function isn't optimal in my opinion. |
|
|
|
This explorer, unfortunately, doesn't seem to fetch any new blocks since approximately a week ago. |
|
|
|
not good,
i checked "ä", "ü", "ae" and "ue".
password : fail!
put in 25 seed word: "Error: Electrum-style word list failed verification"
When typing the first 3 chars was no autoupdate.
Does somebody has any idea.
Yeah... But... how much xmr are you talking about here roughly?  4.6 XMR are in the pot. Could you try to type your full (25 word) mnemonic seed in notepad first and subsequently paste it to the CLI? |
|
|
|
|
Show Posts
