[XMR] Monero - A secure, private, untraceable cryptocurrency

[ArticMine]

It's taking 12 hours now to get transactions processed? It seems the block size adjustment algorithm wasn't designed with these sorts of massive swings in public interest in mind.

It isn't working properly and will be adjusted to address this. A quick fix will come with the upcoming hardfork (April 15 most likely) where the minimum blocksize limit will be raised to 300 kB as far as I know. In addition, see:

https://github.com/JollyMort/monero-research/blob/master/Monero%20Dynamic%20Block%20Size%20and%20Dynamic%20Minimum%20Fee/Monero%20Dynamic%20Block%20Size%20and%20Dynamic%20Minimum%20Fee%20-%20DRAFT.md

https://www.reddit.com/r/Monero/comments/5zoadt/new_fork_around_april_15th_fixes_high_fees_and/

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.

[1714163152]

1714163152

[1714163152]

1714163152

[1714163152]

1714163152

[miningpoolhub]

You must have many small chunks of XMR if you want to send small amounts.
Else, if you have, say, chunks of 50 or 100 the mixin will select them and then you must wait for the balance to mature (become spendable) again.
It's not a bug.

Yeah, thanks.
Is there any way to have more small chunks?
Maybe changing mixin parameter would do some similar effect?

[miningpoolhub]

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.

[Millionero]

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 monero has pioneered a relatively smooth method for rolling out forks so maybe we should consider?

Please bring it to the attention of Fluffypony.

[iCEBREAKER]

Monero is great and I've heavily invested into it

That's hard to verify because I don't see your name here.

https://getmonero.org/getting-started/donate/hall-of-fame

If you are not satisfied with the pace of development, get on that list along with the rest of us who are heavily invested.

[dEBRUYNE]

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.

[dEBRUYNE]

It's taking 12 hours now to get transactions processed? It seems the block size adjustment algorithm wasn't designed with these sorts of massive swings in public interest in mind.

It isn't working properly and will be adjusted to address this. A quick fix will come with the upcoming hardfork (April 15 most likely) where the minimum blocksize limit will be raised to 300 kB as far as I know. In addition, see:

https://github.com/JollyMort/monero-research/blob/master/Monero%20Dynamic%20Block%20Size%20and%20Dynamic%20Minimum%20Fee/Monero%20Dynamic%20Block%20Size%20and%20Dynamic%20Minimum%20Fee%20-%20DRAFT.md

https://www.reddit.com/r/Monero/comments/5zoadt/new_fork_around_april_15th_fixes_high_fees_and/

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.

[throwaway]

Fluffy would have done well to require 2FA on that site

Given that your password is pretty much the equivalent of your spend key, 2FA would add absolutely zero security.

And before someone says "then your password shouldn't be your spend key", that would require the server to store your keys for you; if that's what you want you could just as well use poloniex or whatever to store your xmr.

[miningpoolhub]

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.

Yeah. pool should have plenty of small inputs but did not.
That's why I'm still curious about it.

I'll try multiple payouts in one transaction.

Just one question. Would this multiple payouts cost more fee than sending one by one? less? or same?


Thanks.

[kingorbust]

how high can monero go?

[kingorbust]

that was quite a dump,... same as ethereum but monero didnt recover..ethereum instantly did.

[agario]

Monero is great and I've heavily invested into it

That's hard to verify because I don't see your name here.

https://getmonero.org/getting-started/donate/hall-of-fame

If you are not satisfied with the pace of development, get on that list along with the rest of us who are heavily invested.

Wait what ?   Hhahaha. So you're trying to imply that this is a proper governance model ? Donation based ? Oh, my...

[owlcatz]

Monero is great and I've heavily invested into it

That's hard to verify because I don't see your name here.

https://getmonero.org/getting-started/donate/hall-of-fame

If you are not satisfied with the pace of development, get on that list along with the rest of us who are heavily invested.

Wow, I used to be on that list as I remember donating a bit over 100 XMR at one point long ago back before the forum existed, and that was on a bitcointalk post I think?

Oh well, I've been here a long time and have tried to help when & where possible, not a big deal I guess.

Wait what ?   Hhahaha. So you're trying to imply that this is a proper governance model ? Donation based ? Oh, my...

This coin has no premine, so where else is the $ going to come from? Are you new here or something?

[dEBRUYNE]

that was quite a dump,... same as ethereum but monero didnt recover..ethereum instantly did.

how high can monero go?

Please use this thread for price related talk:

https://bitcointalk.org/index.php?topic=753252.0

[dEBRUYNE]

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.

Yeah. pool should have plenty of small inputs but did not.
That's why I'm still curious about it.

I'll try multiple payouts in one transaction.

Just one question. Would this multiple payouts cost more fee than sending one by one? less? or same?


Thanks.

A bit less as far as I know. A typical RingCT transaction has 2 inputs and 2 outputs and will be approximately 13 kB. For example:

https://xmrchain.net/tx/1d042333217e7e7062e5aadac701daec64c703e62e33f534a516ccbd0586b9c8

If, however, you look at this transaction it has 2 inputs and 6 outputs:

https://xmrchain.net/tx/15ce266893d2a1c7048d091892d6d0576e40575027dcbc382979d7fea0bc4c95

Therefore, it is likely that this is a payout to 5 different recipients (probably miners) and the change output. From the transaction we can see that the size is approximately 38 kB. By contrast, 5 separate transactions would probably have a bigger cumulative size. Thus, most likely you will save some on fees due to the size of the single transaction being smaller than cumulative size of the separate transactions.

[Hueristic]

that was quite a dump,... same as ethereum but monero didnt recover..ethereum instantly did.

not really if you know how to look at it.

https://poloniex.com/exchange#usdt_xmr

[XbladeX]

Guys i have question.
I have wallet from very old time versions like ~0.2 (2014y) . And that wallet is like 1MB "name" no addons key or bin.
How to recover such wallet . Is there anywhere any tutorial to do it ?

[owlcatz]

Guys i have question.
I have wallet from very old time versions like ~0.2 (2014y) . And that wallet is like 1MB "name" no addons key or bin.
How to recover such wallet . Is there anywhere any tutorial to do it ?

Wow... depending how much you have in the wallet, you may want to hit up the #monero or #monero-dev IRC channels and ask there for the fastest advice. Good luck, that's an old version!

[NattyLiteCoin]

So I was refreshing on an initial install and got about 1/2 through. My computer ran out of juice and when it came back up I ran ./monerod again and got

Code:

2017-03-17 20:43:38.876	    7fb53e709780	INFO 	global	contrib/epee/src/mlog.cpp:145	New log categories: *:WARNING,net:FATAL,net.p2p:FATAL,global:INFO,verify:FATAL,stacktrace:INFO
2017-03-17 20:43:38.877	    7fb53e709780	INFO 	global	src/daemon/main.cpp:282	Monero 'Wolfram Warptangent' (v0.10.2.1-release)
2017-03-17 20:43:38.877	    7fb53e709780	INFO 	global	src/daemon/protocol.h:55	Initializing cryptonote protocol...
2017-03-17 20:43:38.877	    7fb53e709780	INFO 	global	src/daemon/protocol.h:60	Cryptonote protocol initialized OK
2017-03-17 20:43:38.878	    7fb53e709780	INFO 	global	src/daemon/p2p.h:63	Initializing p2p server...
2017-03-17 20:43:40.853	    7fb53e709780	INFO 	global	src/daemon/p2p.h:68	P2p server initialized OK
2017-03-17 20:43:40.853	    7fb53e709780	INFO 	global	src/daemon/rpc.h:58	Initializing core rpc server...
2017-03-17 20:43:40.853	    7fb53e709780	INFO 	global	contrib/epee/include/net/http_server_impl_base.h:70	Binding on 127.0.0.1:18081
2017-03-17 20:43:40.854	    7fb53e709780	INFO 	global	src/daemon/rpc.h:63	Core rpc server initialized OK on port: 18081
2017-03-17 20:43:40.854	    7fb53e709780	INFO 	global	src/daemon/core.h:73	Initializing core...
2017-03-17 20:43:40.854	    7fb53e709780	INFO 	global	src/cryptonote_core/cryptonote_core.cpp:316	Loading blockchain from folder /home/nattyonelight/.bitmonero/lmdb ...
2017-03-17 20:43:40.855	    7fb53e709780	WARN 	blockchain.db.lmdb	src/blockchain_db/lmdb/db_lmdb.cpp:1138	LMDB memory map needs to be resized, doing that now.
2017-03-17 20:43:40.855	    7fb53e709780	INFO 	global	src/blockchain_db/lmdb/db_lmdb.cpp:487	LMDB Mapsize increased.  Old: 6765MiB, New: 7789MiB
2017-03-17 20:43:40.855	    7fb53e709780	WARN 	blockchain.db.lmdb	src/blockchain_db/lmdb/db_lmdb.cpp:71	Failed to query m_blocks: MDB_BAD_TXN: Transaction must abort, has a child, or is invalid
2017-03-17 20:43:40.861	    7fb53e709780	ERROR	cn	src/cryptonote_core/cryptonote_core.cpp:385	Error opening database: Failed to query m_blocks: MDB_BAD_TXN: Transaction must abort, has a child, or is invalid
2017-03-17 20:43:40.861	    7fb53e709780	INFO 	global	src/daemon/rpc.h:90	Deinitializing rpc server...
2017-03-17 20:43:40.861	    7fb53e709780	INFO 	global	src/daemon/p2p.h:90	Deinitializing p2p...
2017-03-17 20:43:40.866	    7fb53e709780	INFO 	global	src/daemon/core.h:89	Deinitializing core...
2017-03-17 20:43:40.868	    7fb53e709780	ERROR	daemon	src/daemon/core.h:94	Failed to deinitialize core...
2017-03-17 20:43:40.868	    7fb53e709780	INFO 	global	src/daemon/protocol.h:77	Stopping cryptonote protocol...
2017-03-17 20:43:40.868	    7fb53e709780	INFO 	global	src/daemon/protocol.h:81	Cryptonote protocol stopped successfully
Daemon stopped successfully

I downloaded and received the same message, any ideas?

[owlcatz]

So I was refreshing on an initial install and got about 1/2 through. My computer ran out of juice and when it came back up I ran ./monerod again and got

Code:

2017-03-17 20:43:38.876	    7fb53e709780	INFO 	global	contrib/epee/src/mlog.cpp:145	New log categories: *:WARNING,net:FATAL,net.p2p:FATAL,global:INFO,verify:FATAL,stacktrace:INFO
2017-03-17 20:43:38.877	    7fb53e709780	INFO 	global	src/daemon/main.cpp:282	Monero 'Wolfram Warptangent' (v0.10.2.1-release)
2017-03-17 20:43:38.877	    7fb53e709780	INFO 	global	src/daemon/protocol.h:55	Initializing cryptonote protocol...
2017-03-17 20:43:38.877	    7fb53e709780	INFO 	global	src/daemon/protocol.h:60	Cryptonote protocol initialized OK
2017-03-17 20:43:38.878	    7fb53e709780	INFO 	global	src/daemon/p2p.h:63	Initializing p2p server...
2017-03-17 20:43:40.853	    7fb53e709780	INFO 	global	src/daemon/p2p.h:68	P2p server initialized OK
2017-03-17 20:43:40.853	    7fb53e709780	INFO 	global	src/daemon/rpc.h:58	Initializing core rpc server...
2017-03-17 20:43:40.853	    7fb53e709780	INFO 	global	contrib/epee/include/net/http_server_impl_base.h:70	Binding on 127.0.0.1:18081
2017-03-17 20:43:40.854	    7fb53e709780	INFO 	global	src/daemon/rpc.h:63	Core rpc server initialized OK on port: 18081
2017-03-17 20:43:40.854	    7fb53e709780	INFO 	global	src/daemon/core.h:73	Initializing core...
2017-03-17 20:43:40.854	    7fb53e709780	INFO 	global	src/cryptonote_core/cryptonote_core.cpp:316	Loading blockchain from folder /home/nattyonelight/.bitmonero/lmdb ...
2017-03-17 20:43:40.855	    7fb53e709780	WARN 	blockchain.db.lmdb	src/blockchain_db/lmdb/db_lmdb.cpp:1138	LMDB memory map needs to be resized, doing that now.
2017-03-17 20:43:40.855	    7fb53e709780	INFO 	global	src/blockchain_db/lmdb/db_lmdb.cpp:487	LMDB Mapsize increased.  Old: 6765MiB, New: 7789MiB
2017-03-17 20:43:40.855	    7fb53e709780	WARN 	blockchain.db.lmdb	src/blockchain_db/lmdb/db_lmdb.cpp:71	Failed to query m_blocks: MDB_BAD_TXN: Transaction must abort, has a child, or is invalid
2017-03-17 20:43:40.861	    7fb53e709780	ERROR	cn	src/cryptonote_core/cryptonote_core.cpp:385	Error opening database: Failed to query m_blocks: MDB_BAD_TXN: Transaction must abort, has a child, or is invalid
2017-03-17 20:43:40.861	    7fb53e709780	INFO 	global	src/daemon/rpc.h:90	Deinitializing rpc server...
2017-03-17 20:43:40.861	    7fb53e709780	INFO 	global	src/daemon/p2p.h:90	Deinitializing p2p...
2017-03-17 20:43:40.866	    7fb53e709780	INFO 	global	src/daemon/core.h:89	Deinitializing core...
2017-03-17 20:43:40.868	    7fb53e709780	ERROR	daemon	src/daemon/core.h:94	Failed to deinitialize core...
2017-03-17 20:43:40.868	    7fb53e709780	INFO 	global	src/daemon/protocol.h:77	Stopping cryptonote protocol...
2017-03-17 20:43:40.868	    7fb53e709780	INFO 	global	src/daemon/protocol.h:81	Cryptonote protocol stopped successfully
Daemon stopped successfully

I downloaded and received the same message, any ideas?

Did your system crash during the initial sync or anything, like a random restart without saving? Usually, when I see that, I have to delete the blockchain folder and resync. Having an SSD now makes all the difference too. Good luck.