All of these numbers and formulas are wrong (except smooth, who is just giving rough numbers anyway). Risto's is admittedly labeled as a simplification. With 2.5% of the network hash rate, you have about a 60% chance of getting one or more double blocks each day. On average, you should get 27 double blocks per month. Every time you get a double block, you have a chance to get a triple block, so you end up with something like (per month): - a 50.4806% chance of no triple
- a 34.9481% chance of one triple
- a 11.6494% of two triples
- a 2.9219% chance of three or more triples
Again, this is just on an average month and obviously assumes your % hash rate remains constant. The chance of getting at least two blocks in a row is 90%. If you count only double blocks that are not part of triple blocks, the probability is lower than 90%. I haven't worked it out. No, it's not. The math you used to arrive at 90% (.025 x .025 x 1440) is not how probabilities work. 60% is much closer to the actual number. |
|
|
|
So quick question
Running the new 0-9-0-0
looking at the limit
I'm getting 8194 kB/s down 2047 kB/s up
what is the command for increasing down limit? Thanks for help.
Have you tried using --help in bitmonerod.exe (the deamon)? If I recall correctly, the command for adjusting up/down limits is in that list. It's not "--help" *in* the daemon, just "help". Though, if you launch with "bitmonerod --help", you'll get launch parameters. Inside, you'll get internal commands. With that said, you can change speed limits with: 1. --limit-rate-down [number] (launch param) 2. limit_down [number] (internal command) |
|
|
|
All of these numbers and formulas are wrong (except smooth, who is just giving rough numbers anyway). Risto's is admittedly labeled as a simplification. With 2.5% of the network hash rate, you have about a 60% chance of getting one or more double blocks each day. On average, you should get 27 double blocks per month. Every time you get a double block, you have a chance to get a triple block, so you end up with something like (per month): - a 50.4806% chance of no triple
- a 34.9481% chance of one triple
- a 11.6494% of two triples
- a 2.9219% chance of three or more triples
Again, this is just on an average month and obviously assumes your % hash rate remains constant. |
|
|
|
ArticMine 1000 votes. Proposal for the orderly dissolution of the MEW. That the MEW be dissolved and the corresponding funds be refunded to each member as follows: Members shall have 15 days from the date of the end of voting to provide: 1) An XMR address and transaction ID for refund. or2) The name of a Crypto Kingdom character account to be credited with the funds. Any remaining unclaimed funds after the 15 day period has elapsed shall be credited as follows: Crypto Kingdom account MoneroHouse 50% Crypto Kingdom account Town 50% This proposal allows each member to identify how their portion of the funds will be allocated and provides a balanced approach for disposition of the unclaimed funds. For those unfamiliar with Crypto Kingdom, the MoneroHouse account is used to support Monero development. Edit: Those wishing that their portion of the funds go to Monero development could choose 1 and provide the Monero donation address. 46BeWrHpwXmHDpDEUmZBWZfoQpdc6HaERCNmx1pEYL2rAcuwufPN9rXHHtyUA4QVy66qeFQkn6sfK8aHYjA3jk3o1Bv16em . Those wishing to donate to Crypto Kingdom can choose 2 and specify "Town" as the Crypto Kingdom character account. This will minimize administration time and transaction fees 100 votes. I support this. I'd like my portion to be given to my CK character. |
|
|
|
Yeah I have come across that program but I am unsure how to feed it the hash of my wallet pass. It doesn't work with the 'keys' file. Still trying to get a handle on all this, not my forte. As I said super dumb.
You can be pretty sure nothing exists to do this, at least not public. It also shouldn't be too hard to code something up, but then you're looking at someone's time and they're may be cost involved. Depends on how much value is locked away, etc. In any case you can keep the wallet files indefinitely and maybe you'll remember it later or the value will increase. |
|
|
|
... That's right, you can safely delete blockchain.bin. As for the size of the LMDB database, some things are stored more than once, for speed, but some stuff is also wasted, so there is some scope to shrink it a bit. There's other stuff that needs changing in there, so I'm not saying it'll be smaller when all is said and done, but... maybe  The database also uses sparse files. Here, for instance, the logical size of data.mdb is 14 GB, but the actual data is 8 GB. There are "holes" in the file (0 filled preallocated data) that some filesystems use for other stuff, but some don't. I'm not sure whether Windows' filesystem does things cleverly or dumbly there. Compressing the .bitmonero directory on Ubuntu GNU/Linux with 7z produces a compressed size of 4.5 GB. The uncompressed size is 14.1 GB. The Windows file system is likely applying some compression on the fly to get the file size down from 14 GB to 8 GB. I am using bitmonero v0.8.8.7-9292c1e. The Windows one is 10 GB rather than 8, but I think the allocation might happen at a different rate between the two, accounting for 14 GB vs 10. |
|
|
|
So I have fully synchronized with the monero blockchain on 0.9 beta windows. These are inconsistencies I have noticed:
1) The private working set of memory is now manageable and small, unfortunately the whole working set is the same as in previous versions of bitmonerod. Around 8Gb and machine is struggling.
2) I now have a blockchain.bin of around 4.8Gb but also a Db file of another 10Gb which is unacceptable in storage terms.
3) The beta does not work with any of the gui versions but that is to be expected and I assume rectified shortly in development.
The speed of the sync was actually quite faster that I expected and there is good connectivity of nodes which is good as well.
Has anyone else running the beta code noticed issues similarly?
[1] Are you sure it isn't still syncing? Check the blockheight at the daemon and compare that with the blockheight on https://moneroblocks.eu. I think the green line in bitmonerod (stating something like, you are now fully synced and are able to use simplewallet) already appears somewhat before you are fully synced. LMDB only takes what it can take (during syncing). If much of your RAM is already allocated, LMDB won't take it while syncing. In other words, it won't get stuck like for instance the old binaries. After syncing it only takes <100 MB. [2] That seems to be correct, the RAW file is around 2.3 GB. The size reported by you is the database representation used by the daemon. In my opinion, 14 GB isn't that much if you have a decent PC with a decent HDD/SSD. Currently, most of them have plenty of GBs and 14 GB is relatively small compared to that. [3] If you mean the third party GUIs, that is correct. I think the developers of them will merge LMDB when it is officially released. Well blockchain.bin is the old one and isn't needed. The DB is ~10GB on Windows currently. Note that a lot of data is duplicated right now, and there is room for more clever optimizations in the future. LMDB will indeed take memory if it's available, not just during syncing. My working set for example is ~4.5GB right now, but only ~52MB of that is private. The rest is ready to be given to other processes if they need it. |
|
|
|
|
Edit edit: **nonchalant whistling**
As the crowd dissipates a bit, the Marquess takes his new prized possession into his office for care and protection (unicorns are very clean creatures).
|
|
|
|
210 mil
Well played Sir I will need to think of another Royal Holiday Fund gift idea Thanks. I was busy, came back and refreshed the page, saw the bids and the time, and scrambled. |
|
|
|
It is Quaid's wish, and no doubt the duke's as well, that the buyer of the unicorn take good care of such a noble animal.
With much recognition to the esteemed duke, the auction is resumed, and the end is pushed to wednesday, 21 GMT.
Edit: please reply to this thread with your bids. Reserve price is 30mil.
Roo bids 35mil for the Unicorn. James Daniel bids 100 mil. (I almost decided to let this one slip but 35 mil is just so ridiculous a price for the best horse possible in the game. I am so old to have seen 320 mil bid on a NPC; and there are 20 NPC in level N9 and only 4 horses in level H9. Unicorns are also presumed to be immortal.) I don't know what the Unicorn does or is good for, but Rome bids 110 mil. |
|
|
|
Prepare scantable took: 216320ms What does it mean? It is very slow to me Wow, what are you running on? 2015-Dec-14 11:36:33.957095 [P2P4]Prepare scantable took: 4 ms |
|
|
|
Decent electricity rates should mean better than BE is easily possible; just don't expect to quickly pay off new hardware. This is no different than any crypto right now (this isn't December 2013!). |
|
|
|
Not sure about any of the numbers above, but 32.9 mHash/s (assuming the m stands for M) is higher than the total net hash (last I looked, 11 MH/s, might have moved now), so if you could sustain that you'd be getting maybe 7000 monero a day (order of magnitude). So no. A desktop i7 should be getting you between 50 and 500 hashes a second (order of magnitude again), and 1 monero a day (oom yet again). So 27 seems very wrong.
first i also calculated 7000 xmr a day but i didnt believe it I must knew how much exactly i cant get by day before buy this cpu i am confused New CPUs are extremely expensive on a price-per-hash basis. Don't buy it expecting to break even in a reasonable amount of time. Also note that "bitcoin mining score" is an entirely useless measure for mining Monero. I'd guess that CPU to be not faster than 400h/s (300-400 possibly). if it is 400 h/s so can make 0.33744434 XMR daily are you make sure ? Yup, sounds right. |
|
|
|
Not sure about any of the numbers above, but 32.9 mHash/s (assuming the m stands for M) is higher than the total net hash (last I looked, 11 MH/s, might have moved now), so if you could sustain that you'd be getting maybe 7000 monero a day (order of magnitude). So no. A desktop i7 should be getting you between 50 and 500 hashes a second (order of magnitude again), and 1 monero a day (oom yet again). So 27 seems very wrong.
first i also calculated 7000 xmr a day but i didnt believe it I must knew how much exactly i cant get by day before buy this cpu i am confused New CPUs are extremely expensive on a price-per-hash basis. Don't buy it expecting to break even in a reasonable amount of time. Also note that "bitcoin mining score" is an entirely useless measure for mining Monero. I'd guess that CPU to be not faster than 400h/s (300-400 possibly). |
|
|
|
ok when i think about it its not so bad at all, since timestamps are visible no? so if i want to declare my potential xmr salary, it is difficult to fake because i would need to make real transactions every month so it looks plausible, correct? ok it could be the same money all the time..xmr washing machine  someone should make a 18 million viewkey on testnet  I think this is a really critical point: It is sufficient for general auditing because you can demand that the owner account for everything that was received.
It is still easy to prove and/or require proof for all outputs; it's just not a 1-and-done-for-all-time thing. The needed data is simple enough that I think a good UX should still be completely achievable. |
|
|
|
To expand, it is theoretically possible to, when sending a tx, create the tx in such a way that the tx key is derivable by the owner of the view secret key. That way, the watch only wallet would see both incoming txes, and those outgoing txes. If your goal is to view your normal wallet usage, then it'd work fine. I had a patch to do that, which worked IIRC. However, this requires that the spender is not an adversary, as the spender is free to build a tx that does not follow this scheme, in which case the watch wallet user will not see the spend. So in that sense, it is voluntary, and works if the user of both wallets is you, which is a common use case.
If you hold a spend key, and want to give the view key to an adversary, such that the adversary can be sure you can't spend without it being able to tell, there are roundabout ways. A prominent one which was dissussed involves making an unspendable tx (or several) with all your allegedly unspent coins, and give it to the adversary, which can then check the blockchain for the key images. Unspendable in this case means that the tx must be valid, but unredeemable. The easiest way is to double spend an extra output I guess.
That method has the advantage that such snooping is only done at the particular time the spender sends that checking tx. This means that, should a company change auditors, the auditor will not be able to see spends in the future, since no "checking tx" will be sent to them later. Though they will still see incoming txes as they have the view key.
Maybe sending a signed bunch of key images would also just work, not sure.
Bolded above: this should be the proper way to do it. 0-mixin ring sign a hash of the viewkey (or anything else) for all of your inputs. For creating a "monitor friendly" wallet, we should probably put a bit more thought into it, but mooo's general idea should work. More work needs to go into the bolded portion as well. It has the same negative effects as any other 0-mixin transaction if widely used and disclosed these key image lists are disclosed. The original purpose for which this was proposed at the end of MRL-0004 was for an auditor to verify privately and then destroy. Even that is somewhat dangerous if the same auditor is auditing many clients. Absolutely. If large lists of key image<>output mappings are made public, that's a potentially big reduction in the anonymity set. i did not know this about the viewkey.
doesnt this take all the magic away? i mean maybe i misunderstood, but if you cant see outgoing transactions with the viewkey, how is it usefull at all?
the information that something was there once is not enough for auditing.
It isn't sufficient for proof-of-solvency. To do that you need a more interactive protocol where the site moves the coins or discloses key images. It is sufficient for general auditing because you can demand that the owner account for everything that was received. The owner can prove what was spent and can then disclose that proof (either publically or privately to an auditor). Just for reference, this has been discussed somewhat in depth quite some time ago, so it's not a new discovery. It might not be widely known outside this thread though. |
|
|
|
To expand, it is theoretically possible to, when sending a tx, create the tx in such a way that the tx key is derivable by the owner of the view secret key. That way, the watch only wallet would see both incoming txes, and those outgoing txes. If your goal is to view your normal wallet usage, then it'd work fine. I had a patch to do that, which worked IIRC. However, this requires that the spender is not an adversary, as the spender is free to build a tx that does not follow this scheme, in which case the watch wallet user will not see the spend. So in that sense, it is voluntary, and works if the user of both wallets is you, which is a common use case.
If you hold a spend key, and want to give the view key to an adversary, such that the adversary can be sure you can't spend without it being able to tell, there are roundabout ways. A prominent one which was dissussed involves making an unspendable tx (or several) with all your allegedly unspent coins, and give it to the adversary, which can then check the blockchain for the key images. Unspendable in this case means that the tx must be valid, but unredeemable. The easiest way is to double spend an extra output I guess.
That method has the advantage that such snooping is only done at the particular time the spender sends that checking tx. This means that, should a company change auditors, the auditor will not be able to see spends in the future, since no "checking tx" will be sent to them later. Though they will still see incoming txes as they have the view key.
Maybe sending a signed bunch of key images would also just work, not sure.
Bolded above: this should be the proper way to do it. 0-mixin ring sign a hash of the viewkey (or anything else) for all of your inputs. For creating a "monitor friendly" wallet, we should probably put a bit more thought into it, but mooo's general idea should work. |
|
|
|
In either one of those cases, the halving will occur. The price will drop a little bit. Over weeks the difficulty will drop as older hardware is taken offline. When the difficulty drops enough, the big mining firms will fire up their unnannounced, non-released 2 nm asics, driving more small miners off the network.
So, the halving will facilitate centralization really.
Really, after the halving, the price will depend on how much fiat the big players have available to burn on electricity as they wait for prices to increase. If they have to sell their bitcoin to cover electricity then they are done, as well as the price of bitcoin. However, if the big mining firms have arranged with other big players in the network for some type of service contract (see exchange <-> mining described above), then they can probably hold out for a while and not sell as *much* of their BTC to cover the electricity, which will keep the supply of available bitcoin limited.
None of this makes any sense to me. |
|
|
|
|
Show Posts
