On topic:
I am still hesitant about the postmine, but if other methods like the crowdfunding do not work and it has to be done, then I propose we simply move emission from *before* the tail starts to the present.
Say a bootstrap block with reward X to the devfund is generated "soon". Then if X represents y% of the "total" 18.6M emission, it can be covered slowly by reducing mining reward by >y% until the deficit is covered. Thus the net effect would be that the core devs make a "loan" of X from "nowhere" at 0% interest, and then repay it back by burning part of future emission. This would make the bootstrap a contained problem, since it is a localized, surgical change in the emission schedule. To the first order, any injustice will only last until the devfund would have "repaid" the "loan".
But smooth, both for the crowdfunding attempt and as justification for the "loan", that spreadsheet needs to be done and it nobody but the core team that can do it.
For the bootstrap I was thinking along the same lines. I was using 18.4M total emissions and the suggestion of 1% or 184k for X. 3.5M has been mined so for the 14.9M remaining the block reward would need to be reduced, I assume this is what you meant by burning, by ~1.23%. If burning till the end is too long for the "injustice" the % would need to be increased. For 4 years from the genesis block I get 1.47% and for 3 years I get 1.67% for 16M and 14.5M mined respectively. In one month from now it goes up to 1.28%, 1.53% and 1.75% respectively due to an additional ~1/2M more coins that will have been mined. I don't do math but hopefully I got the arithmetic correct. The idea of 1% for the devs going forward has been suggested in addition which is getting a bit steep. I am not suggesting anything but just putting some numbers out for perspective. As David said we don't have to do just one thing but IMO it needs to be done soon. I am using the original definition of soon. |
|
|
|
I'm a fan of setting things on stone unless its a bug or catastrophic problem, whatever you guys decide to do, not making it default enabled (except the mix count that need to be forced to a minimal of 1 as discussed before) is a must imo to keep xmr trust intact, but thats just my opinion.
People seem to think and I agree.....it's problem. |
|
|
|
Hi, guys , how should I join in #Monero-Dev Fireside Chat? Thanks
|
|
|
|
|
The number of coins being talked about is 9 days worth of emissions at the present rate.
|
|
|
|
Updated all. Thanks.
You have pa in the correct category but the amount is wrong. |
|
|
|
... I said I'm leaning towards it being sincere manic ramblings.
... I'm saying just that. More likely than not he's sincere. Not sure why we're stuck on this. Sincere......................................... http://www.youtube.com/watch?v=5JXUA8oFWCc |
|
|
|
The above post by fluffypony should put this funding discussion in perspective. He lists approximately $200,000 in costs. 3,500,000 coins have been mined and 1% is 35,000. At a generous exchange rate of $2 equals $70,000. So 1% of all the coins ever mined equals 1/3 of the most important costs listed.
I'd rather work with 1/3 of the costs than work with 1/30, which is approximately what has been received in donations. The former at least allows prioritizing, scaling down some items (at least temporarily), etc. and still getting a significant portion of the work done, plus as I said it need not be the only funding source (and some work will I'm sure continue to be done by community volunteers who are interested in doing it). smooth, I agree. Also to anyone mining, there is a pool that donates 100% of it's 1% fee to the devs. |
|
|
|
How much money BTC/xmr/$ in donations is (approx) needed to get an ETA of the following:
- Embedded DB solution/implementation --> $14 500 (as posted on reddit)
- Convertion of C-code
- Finished (official) GUI
- C++ version of the I2P router (IP obfuscation)
- ... (blockchain bloat issue?)
It might help to have some funding goals, so that as a community, we can work to certain points more rapidly. Maybe the Monero Committee (or whatever is called) can do something with this?
I'm thumb-sucking numbers, don't take these guesstimates as anything actual or realistic. - Embedded DB solution/implementation - 6 man weeks is a pretty solid guess, so I'll leave the $14 500 - Convertion of C-code - it's not as simple as this. Apart from this specific item, there needs to be an incremental audit and refactor. Just because the bug was lurking in a piece of C code with this doesn't mean there can't be a bug elsewhere, it's just easier to obfuscate it in C. Holistically this is an active, ongoing task, that will likely end up costing in the $80k - $140k range over many, many months. - Finished (official) GUI - assuming all the other pieces are in place, then dEBRUYNE is correct - anything from $15k - $20k. - C++ version of the I2P router (IP obfuscation) - this is already making rapid progress: https://github.com/PrivacySolutions/i2pd. To get it to a point where it's usable and implementable as submodule / library I'd imagine is easily a $50k job, but I'm guessing at what orignal's hourly is. - ... (blockchain bloat issue?) - not really an issue, and I'm unsure as to what we'd consider "solving" it. A linear reduction? A lightweight access methodology that heavily reduces the need for local storage / bandwidth? The amount of experimentation and research needed here to find a cryptographically sound "solution" makes it hard to pin a value down. The above post by fluffypony should put this funding discussion in perspective. He lists approximately $200,000 in costs. 3,500,000 coins have been mined and 1% is 35,000. At a generous exchange rate of $2 equals $70,000. So 1% of all the coins ever mined equals 1/3 of the most important costs listed. |
|
|
|
ah fuck this
* cutting looses *
When I bought my new computer in April one of the first things I did was add BitcoinWisdom to my favorites. It shows the bitstamp price when I did so which is 445.75 So my btc are only worth what they were 5 months ago. |
|
|
|
|
"they" are FUDing the "new" (from July) XMR (CN) exploit in the Polo trollbox.
I couldn't help myself and bought more at what looks like the panic bottom of 382
|
|
|
|
|
After updating to 8.8.4 and receiving no error messages I woke up to the following. I just checked the log and it started over an hour ago.
Before going to sleep I sent another small donation.
2014-Sep-17 11:08:37.602952 [P2P7]ERROR c:\users\ric_000\desktop\bitmonero\contr
ib\epee\include\net\abstract_tcp_server2.inl:307 send que size is more than ABST
RACT_SERVER_SEND_QUE_MAX_COUNT(1000), shutting down connection
2014-Sep-17 11:08:37.612959 [P2P7]ERROR c:\users\ric_000\desktop\bitmonero\contr
ib\epee\include\net\abstract_tcp_server2.inl:307 send que size is more than ABST
RACT_SERVER_SEND_QUE_MAX_COUNT(1000), shutting down connection
2014-Sep-17 11:08:48.546157 [P2P4]ERROR c:\users\ric_000\desktop\bitmonero\contr
ib\epee\include\net\abstract_tcp_server2.inl:307 send que size is more than ABST
RACT_SERVER_SEND_QUE_MAX_COUNT(1000), shutting down connection
2014-Sep-17 11:08:48.599194 [P2P4]ERROR c:\users\ric_000\desktop\bitmonero\contr
ib\epee\include\net\abstract_tcp_server2.inl:307 send que size is more than ABST
RACT_SERVER_SEND_QUE_MAX_COUNT(1000), shutting down connection
2014-Sep-17 11:09:07.189484 [P2P5]ERROR c:\users\ric_000\desktop\bitmonero\contr
ib\epee\include\net\abstract_tcp_server2.inl:307 send que size is more than ABST
RACT_SERVER_SEND_QUE_MAX_COUNT(1000), shutting down connection
2014-Sep-17 11:09:07.199491 [P2P5]ERROR c:\users\ric_000\desktop\bitmonero\contr
ib\epee\include\net\abstract_tcp_server2.inl:307 send que size is more than ABST
RACT_SERVER_SEND_QUE_MAX_COUNT(1000), shutting down connection
2014-Sep-17 11:09:49.791634 [P2P9]ERROR c:\users\ric_000\desktop\bitmonero\contr
ib\epee\include\net\abstract_tcp_server2.inl:307 send que size is more than ABST
RACT_SERVER_SEND_QUE_MAX_COUNT(1000), shutting down connection
2014-Sep-17 11:09:49.832649 [P2P9]ERROR c:\users\ric_000\desktop\bitmonero\contr
ib\epee\include\net\abstract_tcp_server2.inl:307 send que size is more than ABST
RACT_SERVER_SEND_QUE_MAX_COUNT(1000), shutting down connection
|
|
|
|
|
Sent another 0.04 btc. Current price is 390, rounding up to 400. Please add 10 XMR to my total.
txid: 418a5533f8ac788560f893df9d60b264b26e32b4e2e259939300d18f5f8e0632
I only regret that I will lose my designation of 1st kyu monero supporters with a bale of high quality hygiene paper.
|
|
|
|
Bitcoin is about to race up to $1500 very soon. Something is brewing and it's not the news which will trigger it.
Are you keeping the not the news secret? I heard it was going to be $5000 this past July/August |
|
|
|
|
I have $58.90 in the bank and $103 in my pocket. That accounts for all my fiat.
|
|
|
|
So anyway, we're just a few days away from an event that should begin to provide buying pressure to Bitcoin. Still a chance we could go a great deal lower until this happens. After that, I expect the ramp up that began on 10/2/2013. I'll let you know when the day hits.
Wasn't 2013 last year? Never mind I be idiot |
|
|
|
|
TY Smooth I have my new wallet!! I have backed up the keys file.
It created a new seed. I just updated all my btc and XMR info today and put it in a safe deposit box as well as another location. Now I need to update again.
Thanks again Smooth.
|
|
|
|
|
[/quote]
simplewallet --wallet name-of-your-keys-file-without-.keys
[/quote]
So just type in the name of my wallet?
There is a reason I am The Drooling Masses® although I am motivated.
I'm restarting the daemon which will take a few minutes.
|
|
|
|
I have the keys file.
If you have the keys file that's all you need. 1. Backup keys file securely before messing with it (make sure to back up any other wallets as well). 2. Make sure there are no conflicting wallet files with the same name 3. Load the keys file into simplewallet normally. It will regenerate the wallet.bin file. I don't understand #3 How do I load the keys file into simple wallet "normally"? |
|
|
|
|
Show Posts
