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

[RentaMouse]

Code:

[quote author=RentaMouse link=topic=583449.msg8728806#msg8728806 date=1410185809]
Something else you could try is to specify a new data folder location for bitmonerod, if you create a new folder - e.g. D:\monerodata on your PC and copy blockchain.bin you can then run bitmonerod.exe with the --data-dir D:\monerodata option so it uses that instead of the default appdata\roaming.  

RentaMouse link, nothing change - sync of bitmonerod have stopped at block 208402!
 Bitmonerod have 6 outgoing connections on ports 18080, 8080 & 28080 but there is no traffic anymore...I  tried to sync from this blockchain.bin
http://monero.cc/downloads/blockchain/win/blockchain.bin
but i got the same result! It's an obsession...I don't know...

Did it write the logfile etc to the new data folder? If it couldnt access the data-dir location for some reason it goes back to the default location without telling you.

And is it still the same as before - logging just stops with no errors and you have to kill bitmonerod process to exit it?

I'm running out of ideas, makes it more confusing that you got it to start working by sharing the folder, but then it stopped again  

[tacotime]

I've updated to the new client ,now it just closes afterwards, any help?

2014-Sep-08 13:13:26.408649 bitmonero v0.8.8.3(0.1-g3c2b742)
2014-Sep-08 13:13:26.408649 Module folder: C:\Users\NEW MONERO\monero.win.x64.latest\bitmonerod.exe
2014-Sep-08 13:13:26.424249 Initializing p2p server...
2014-Sep-08 13:13:26.424249 Binding on 0.0.0.0:18080
2014-Sep-08 13:13:26.424249 Net service binded on 0.0.0.0:18080
2014-Sep-08 13:13:26.424249 Attempting to add IGD port mapping.
2014-Sep-08 13:13:27.641052 Added IGD port mapping.
2014-Sep-08 13:13:27.641052 P2p server initialized OK
2014-Sep-08 13:13:27.656652 Initializing cryptonote protocol...
2014-Sep-08 13:13:27.656652 Cryptonote protocol initialized OK
2014-Sep-08 13:13:27.672252 Initializing core rpc server...
2014-Sep-08 13:13:27.687852 Binding on 127.0.0.1:18081
2014-Sep-08 13:13:27.687852 Core rpc server initialized OK on port: 18081
2014-Sep-08 13:13:27.687852 Initializing core...
2014-Sep-08 13:13:27.703452 Loading blockchain...
2014-Sep-08 13:14:33.176767 CHECKPOINT PASSED FOR HEIGHT 22231 <7cb10e29d67e1c069e6e11b17d30b809724255fee2f6868dc14cfc6ed44dfb25>
2014-Sep-08 13:14:34.253169 CHECKPOINT PASSED FOR HEIGHT 29556 <53c484a8ed91e4da621bb2fa88106dbde426fe90d7ef07b9c1e5127fb6f3a7f6>
2014-Sep-08 13:14:35.922372 CHECKPOINT PASSED FOR HEIGHT 50000 <0fe8758ab06a8b9cb35b7328fd4f757af530a5d37759f9d3e421023231f7b31c>
2014-Sep-08 13:14:38.589976 CHECKPOINT PASSED FOR HEIGHT 80000 <a62dcd7b536f22e003ebae8726e9e7276f63d594e264b6f0cd7aab27b66e75e3>
2014-Sep-08 13:14:51.896800 ERROR ..\..\src\cryptonote_core\checkpoints.cpp:71 CHECKPOINT FAILED FOR HEIGHT 202612. EXPECTED HASH: <bbd604d2ba11ba27935e006ed39c9bfdd99b76bf4a50654bc1e1e61217962698>, FETCHED HASH: <520d272048b48cbf0e95ae03f88082c345a7637531ab5b1ab9791e966cdd7001>
2014-Sep-08 13:14:51.959200 ERROR ..\..\src\cryptonote_core\blockchain_storage.cpp:99 checkpoint fail, blockchain.bin invalid
2014-Sep-08 13:14:52.006000 ERROR ..\..\src\cryptonote_core\cryptonote_core.cpp:127 Failed to initialize blockchain storage
2014-Sep-08 13:14:52.021600 ERROR ..\..\src\daemon\daemon.cpp:190 Failed to initialize core
2014-Sep-08 13:14:52.364800 Mining has been stopped, 0 finished

If you were on the fork before and stored your blockchain, you will have to resync the chain or download one of the blockchains in OP.

[albert3]

ok thanks I'll delete the blockchain and resync 

[fluffypony]

When the 0.1 fee will be fixed ?

When we replace it with per-kb fees.

[rpietila]

When the 0.1 fee will be fixed ?

When we replace it with per-kb fees.

Just please make the fees high enough that the blockchain is not sold out too cheaply. It is possible to lower them when the price rises. The recent decision to up them by 20x did not lead to price crashing.

[smooth]

When the 0.1 fee will be fixed ?

When we replace it with per-kb fees.

Just please make the fees high enough that the blockchain is not sold out too cheaply. It is possible to lower them when the price rises. The recent decision to up them by 20x did not lead to price crashing.

I would like to hear your specific suggestions with supporting analysis.

[rpietila]

When the 0.1 fee will be fixed ?

When we replace it with per-kb fees.

Just please make the fees high enough that the blockchain is not sold out too cheaply. It is possible to lower them when the price rises. The recent decision to up them by 20x did not lead to price crashing.

I would like to hear your specific suggestions with supporting analysis.

If "you" was singular, I'd like to know many variables first, to start to analyze it:

- number of tx per day
- distribution of the sizes of tx, how much user can affect it
- does mixing factor affect it
- is there any reason to compete for space in 1 block as with Bitcoin
- is there any way the user could/should be able to affect the fee
- how did the recent 20x increase of fee affect tx
- what is the realistic upper limit of blockchain size now, in 1, 2, 3, 4, 5, etc years so that it is still usable
- blockchain prunable to what extent, when?

After these, I proceed to calculate if there is any need to limit the blockchain usage or if the antispam is the only reason for fees. If the limiting is required, then it takes some time to try to develop a "lifespan" for the coin by probably subsidising the fee now so that later Monero is so big that we can face the problem with larger resources. But I won't go into specifics without getting the information first.

ADD: Before even seeing the facts, I would say that there exists the following usage:

- Transfers. These are quite large and not much affected by the fees.
- Payments. These may be small but can be reconfigured such that they happen less often, which would reduce the usage given higher fee.
- Micropayments. These proliferate is the fees are small, and become uneconomic if they are raised. I don't believe there are many micropayment innovations functioning in Monero, and by keeping the fees high there will not be, either. It is a new thing that has not existed before, but seems that Monero blockchain is not the right place for it.
- Spam/Attacks.

If fee is set so high that people are grudging when making a transfer, it is a problem because they sell out of a coin that is too expensive to transact with. If fee is too high for payments, the coin loses economy/services. There were never any micropayments to begin with.

[qqqq]

When the 0.1 fee will be fixed ?

When we replace it with per-kb fees.

When you you replace it with ... ?

[wachtwoord]

When the 0.1 fee will be fixed ?

When we replace it with per-kb fees.

When you you replace it with ... ?

Fees based on the size (in kilobytes) of the transaction.

[smooth]

- number of tx per day
- distribution of the sizes of tx, how much user can affect it

Available on monerochain.info (first one chart, second one you will have to click around blocks, or use the API

- does mixing factor affect it

The mixing factor has a linear multiplier effect on a portion of the transaction size (input signatures).

- is there any reason to compete for space in 1 block as with Bitcoin

Yes if you are in a hurry. The block sizes can expand (in theory almost without limit but that doesn't work too well in a world with actual limits on bandwidth, latency, storage, etc.) so eventually tx with any reasonable fee will get in. However, that is a slow process, so if there are too many transactions for one block some will have to wait and if you want to compete for priority you will want a higher fee (as with Bitcoin).

- is there any way the user could/should be able to affect the fee

Same as Bitcoin, but not in the code yet. That will likely be added. How prominent it is in the UI is not decided. Some bitcoin wallets bury it down in the preferences where few ever change it.

One difference with Bitcoin is that it isn't feasible to do anti-spam with coin-age because age isn't uniquely determined with ring signatures, so there has to be at the very least a bare minimum fee for anti-spam purposes.

- how did the recent 20x increase of fee affect tx

See monerochain.info but my recollection is about 30% reduction.

- what is the realistic upper limit of blockchain size now, in 1, 2, 3, 4, 5, etc years

Who knows? Your guess is as good as anyone's.

- blockchain prunable to what extent, when?

Prunable is a tricky word (as has been discussed a bit on your altcoin thread). Satoshi defined it a certain way to mean removing already-spent outputs (and the transactions that created them) from the block chain. That can't be done directly because anonymity means it can't be determined when an output is spent (only possibly-spent) and it isn't isn't necessarily desirable because transaction outputs are reused to mix with other outputs because possibly-spent outputs don't become  "useless" the way spent outputs in Bitcoin do -- they are used for future mixing. However, there are certainly things that can be done to reduce usage by some linear factors like 2-5. There are concepts for doing something like pruning but they are a relatively long term proposition and not fully developed, so hard to say.

Transaction fees are both anti-spam and also resource management.

If you have other questions ask here or on IRC

[nioc]

When the 0.1 fee will be fixed ?

When we replace it with per-kb fees.

When you you replace it with ... ?

Fees based on the size (in kilobytes) of the transaction.

I don't think that answers his question of when.

The following was posted yesterday......

Can we still expect per KB fees until September ~15th?

Good job if everything else is now working properly again.

Any comment on this?

We've been reeling this week to weed out any effects of the attack, so hard to say. We'll regroup tomorrow and see where we're at with that, but it has/had been progressing quite nicely: https://github.com/mikezackles/bitmonero/tree/fees_wip

I guess that it will be happening soon®

[smooth]

Just to give a rough guide to our thinking on fees, we are currently considering 0.01/2 kb. 0.005 didn't work too well given the way dust is handled (it creates a lot of 0.005 change, although in the future we will probably improve dust handling). So most small transactions (<= 2 kb) would have a fee of 0.01, larger ones of around 20 kb would be close to the current 0.1 and continue to provide the same protection against spamming of large transactions.

For reference, at current prices

0.01 XMR is approx. 0.02 USD
0.0001 BTC is approx. 0.05 USD (common fee per kb used with bitcoin, though there is a range in use)

With this setting, we are about 5x cheaper than Bitcoin per kb. However, Bitcoin has the ability to send some zero-fee tx (though not all wallets support this or do it by default) and we don't. Also the 2 kb increment is larger than Bitcoin's 1 (typical) kb increment, which also increases effective fees somewhat, so 5x is an overestimate.

[coins101]

Just to give a rough guide to our thinking on fees, we are currently considering 0.01/2 kb. 0.005 didn't work too well given the way dust is handled (it creates a lot of 0.005 change, although in the future we will probably improve dust handling). So most small transactions (<= 2 kb) would have a fee of 0.01, larger ones of around 20 kb would be close to the current 0.1 and continue to provide the same protection against spamming of large transactions.

For reference, at current prices

0.01 XMR is approx. 0.02 USD
0.0001 BTC is approx. 0.05 USD (common fee per kb used with bitcoin, though there is a range in use)

With this setting, we are about 5x cheaper than Bitcoin per kb. However, Bitcoin has the ability to send some zero-fee tx (though not all wallets support this or do it by default) and we don't. Also the 2 kb increment is larger than Bitcoin's 1 (typical) kb increment, which also increases effective fees somewhat, so 5x is an overestimate.

Why not do both size and transaction level, or a variable combination.

If I can send $1m for the same cost as $1, that doesn't make sense.

You are trying to prevent spam, apply de minimis logic. Spammers are not going to use $10 per transaction (or whatever you decide upon).

Blow $10, use size. Above $10, make it a percentage of the tx. Maybe you just need to find a way to make it a moving target as prices change.

That will pay for the miners and nodes supporting the growth of the block chain, while having a way of making attacks expensive.

[xulescu]

Percentage fees are exactly the rent seeking behaviour that cryptos try to remove.

There is no way to access the price of a coin inside the coin's code, because it is an extrinsic property.

Maybe proof of work could be used instead of tx fees or somehow incorporated? Would it help if you had to hash something when sending?

[smooth]

Percentage fees are exactly the rent seeking behaviour that cryptos try to remove.

There is no way to access the price of a coin inside the coin's code, because it is an extrinsic property.

Maybe proof of work could be used instead of tx fees or somehow incorporated? Would it help if you had to hash something when sending?

Proof of work could probably be used. Not only could that be used directly to prevent p2p spam but also miners could possibly subtract the sum of transaction difficulties from the block difficulty. Thus miners wouldn't be paid directly for including transactions, they would be "paid" by making it easier to solve a block. The mechanism to do this might make transactions larger though, which then makes them more expensive in terms of actual costs (not necessarily a disqualifier).

But no one has worked out the details for this, so possibly a viable long term solution but not immediately usable.

Also, in Monero not only is the coin value unknown but the amount of the transaction itself is also unknown to a greater because there are multiple denominated inputs and outputs, with some unknown subset of the outputs being change (sort of true for Bitcoin as well).

[5w00p]

For 'thin' clients that will definitely be required for broad and widespread adoptance (mobile phones, etc), I think that the processing required for hashing some POW would be prohibitive.

[TheKoziTwo]

I coded a simple script which parsed this topic, boolberry, bytecoin, ducknote and darkcoin. Figured it would be interesting to see these results.

In this topic alone, a total of 1420 unique users has participated.

Below are users spread across the different user ranks:

Boolberry (198 pages)

Rank	Users
Staff	0	0.00%
Donator	0	0.00%
Legendary	5	1.09%
Hero_Member	19	4.14%
Sr.Member	83	18.08%
Full_Member	150	32.68%
Member	82	17.86%
Jr.Member	52	11.33%
Newbie	68	14.81%
Total users:	459

Bytecoin (195 pages)

Rank	Users
Staff	1	0.22%
Donator	0	0.00%
Legendary	4	0.87%
Hero_Member	19	4.17%
Sr.Member	54	11.84%
Full_Member	113	24.78%
Member	101	22.15%
Jr.Member	74	16.23%
Newbie	90	19.74%
Total users:	456

duckNote (78 pages)

Rank	Users
Staff	0	0.00%
Donator	0	0.00%
Legendary	2	0.72%
Hero_Member	5	1.81%
Sr.Member	40	14.49%
Full_Member	78	28.26%
Member	62	22.46%
Jr.Member	42	15.22%
Newbie	47	17.03%
Total users:	276

Monero (700 pages)

Rank	Users
Staff	1	0.07%
Donator	1	0.07%
Legendary	12	0.85%
Hero_Member	56	3.94%
Sr.Member	210	14.79%
Full_Member	362	25.49%
Member	288	20.28%
Jr.Member	203	14.3%
Newbie	287	20.21%
Total users:	1420

now the really interesting comparison....

Darkcoin (3029 pages)

Rank	Users
VIP	0	0.08%
Staff	0	0.00%
Donator	2	0.08%
Legendary	9	0.35%
Hero_Member	57	2.23%
Sr.Member	291	11.40%
Full_Member	772	30.24%
Member	545	21.35%
Jr.Member	342	13.40%
Newbie	533	20.88%
Total users:	2553

Notice the number of hero and legendary members? Darkcoin has 57 (2.23%) hero and 9 (0.35%) legendary versus Monero with 56 (3.94%) hero and 12 (0.85%) legendary. Percent wise monero has attracted more than twice legendary members and almost twice hero members.

In other words, it seems oldtimers gravitate towards monero/cryptonote and ignore darkcoin.

[bclcjunkie]

anyone else sees the same? can the devs confirm if i should resync or ignore those -4 days messages? sometimes it would continue syncing backwards until i have to close and restart the session again and then it gets synced properly... i've never seen this sort of behavior before.. wallet shows current block height and correct balance..

2014-Sep-09 09:28:29.695139 [P2P3][178.215.105.206:5222 INC]Sync data returned unknown top block: 209084 -> 209603 [519 blocks (0 days) behind]
SYNCHRONIZATION started2014-Sep-09 09:28:29.804339 [P2P4][221.226.86.116:56335 INC]Sync data returned unknown top block: 209084 -> 209603 [519 block
s (0 days) behind]SYNCHRONIZATION started
2014-Sep-09 09:28:29.632739 [P2P8][122.224.204.18:33488 INC]Sync data returned unknown top block: 209084 -> 209603 [519 blocks (0 days) behind]
SYNCHRONIZATION started
2014-Sep-09 09:28:29.866739 [P2P3][80.227.80.75:38606 INC]Sync data returned unknown top block: 209084 -> 209603 [519 blocks(0 days) behind]
SYNCHRONIZATION started
2014-Sep-09 09:28:29.913539 [P2P4][221.0.76.119:53130 INC]Sync data returned unknown top block: 209084 -> 209603 [519 blocks(0 days) behind]
SYNCHRONIZATION started
2014-Sep-09 09:28:29.975939 [P2P8][128.12.226.78:51255 INC]Sync data returned unknown top block: 209084 -> 209603 [519 blocks (0 days) behind]
SYNCHRONIZATION started
2014-Sep-09 09:28:30.022739 [P2P3][27.54.242.77:50537 INC]Sync data returned unknown top block: 209084 -> 202659 [6425 blocks (-4 days) ahead]
SYNCHRONIZATION started
2014-Sep-09 09:28:30.100740 [P2P4][82.26.208.174:25591 INC]Sync data returned unknown top block: 209084 -> 209603 [519 blocks (0 days) behind]
SYNCHRONIZATION started
2014-Sep-09 09:28:30.272340 [P2P4][109.165.173.237:28997 INC]Sync data returned unknown top block: 209084 -> 209603 [519 blocks (0 days) behind]
SYNCHRONIZATION started
2014-Sep-09 09:28:30.209940 [P2P3][50.46.245.237:60666 INC]Sync data returned unknown top block: 209084 -> 209603 [519 blocks (0 days) behind]
SYNCHRONIZATION started
2014-Sep-09 09:28:30.194340 [P2P8][88.87.92.102:38932 INC]Sync data returned unknown top block: 209084 -> 202659 [6425 blocks (-4 days) ahead]
SYNCHRONIZATION started
2014-Sep-09 09:28:30.334740 [P2P4][123.233.204.190:47049 INC]Sync data returned unknown top block: 209084 -> 209603 [519 blocks (0 days) behind]

[jwinterm]

I coded a simple script which parsed this topic, boolberry, bytecoin, ducknote and darkcoin. Figured it would be interesting to see these results.

...

Notice the number of hero and legendary members? Darkcoin has 57 (2.23%) hero and 9 (0.35%) legendary versus Monero with 56 (3.94%) hero and 12 (0.85%) legendary. Percent wise monero has attracted more than twice legendary members and almost twice hero members.

In other words, it seems oldtimers gravitate towards monero/cryptonote and ignore darkcoin.

Wow, very neat! Thanks for scraping and parsing like a boss

[smooth]

anyone else sees the same? can the devs confirm if i should resync or ignore those -4 days messages? sometimes it would continue syncing backwards until i have to close and restart the session again and then it gets synced properly... i've never seen this sort of behavior before.. wallet shows current block height and correct balance..

Ignore the -4 days messages. That means the peer is '-4 days ahead" meaning 4 days behind. i.e. they are stuck. Your node will drop them and continue working. As long as your height is correct (diff command in daemon or bc_height command in wallet) you are fine.

I'm not sure what you mean by syncing backwards unless your height is decreasing instead of increasing. I don't think that is possible. (If you see it, report it.)