maybe a proposal due to the heaty debate on monero/speculation
xcp/counterparty was for maybe two or three months as hard to use as monero is now - they released a web wallet which did not work that well at the beginning but included several new users, even at this point of time some function only work in counterpartyd and not in the webwallet.
I think it would be more clever to even release a wallet which is not fully functional than to release a wallet with is functional and a distant future.
Topic: [XMR] Monero - A secure, private, untraceable cryptocurrency - page 1293. (Read 4671575 times)
November 07, 2014, 07:09:20 PM
November 07, 2014, 03:33:34 PM
Two questions:
1.) Will the command_server functionality on the development branch be merged into master and rolled out with 0.8.8.5?
2.) If not, has any or all of the following fixes been incorporated into the development branch?: the spam attack patch; block 202612 attack patch; block 202612 attack mitigation and fork fix (via a whole new block blob hash checkpointing system)
Either one of these items would help move things forward on the Monero Client .NET GUI.
Reason being is that, at the moment, we can't use the test version of Monero Client .NET because it requires the command_server functionality in the daemon to properly function. Unfortunately, the latest available bitmonerod.exe binary from the development branch that has this also doesn't have the aforementioned patches incorporated into it, meaning that we can't use it anymore.
On the other hand, the most recent version of Monero Client .NET that does NOT require the binary from the development branch also contains a number of bugs (that have since been fixed in the test version) that make it annoying to use.
1.) Will the command_server functionality on the development branch be merged into master and rolled out with 0.8.8.5?
2.) If not, has any or all of the following fixes been incorporated into the development branch?: the spam attack patch; block 202612 attack patch; block 202612 attack mitigation and fork fix (via a whole new block blob hash checkpointing system)
Either one of these items would help move things forward on the Monero Client .NET GUI.
Reason being is that, at the moment, we can't use the test version of Monero Client .NET because it requires the command_server functionality in the daemon to properly function. Unfortunately, the latest available bitmonerod.exe binary from the development branch that has this also doesn't have the aforementioned patches incorporated into it, meaning that we can't use it anymore.
On the other hand, the most recent version of Monero Client .NET that does NOT require the binary from the development branch also contains a number of bugs (that have since been fixed in the test version) that make it annoying to use.
November 07, 2014, 02:58:17 PM
Quote from: monero
We are not going to enforce a block-point hard fork, but we would appreciate it if major pools could upgrade by Monday.
Which is best strategy to make upgrade?a. About per-kb fee (2)* - compile it in Linux as usual. For Windows and FreeBSD wait for the CMake thing (3)* to be ready (if you don't want to lose a week of your time to just compile it).
For now please test the Linux version for non-critical nodes (large pools and exchanges please hold off!) if you are able to do so and help us out with any feedback.
Which is best strategy to make upgrade?b. About the database (1)* - for non-critical nodes see a). If you are an exchange or a large pool then DON'T DO IT!
*See Monday-ish Monero Missives - November 2nd, 2014
Disclaimer: Not tested. Try it on your own risk. Backup your wallet first.
November 07, 2014, 02:55:56 PM
For now please test the Linux version for non-critical nodes (large pools and exchanges please hold off!) if you are able to do so and help us out with any feedback.
Which is best strategy to make upgrade?
The first comment (quote from monero) was about the per-kb fees that is in master, the second (quote from me) about the database branch, which is not in master.
The recommended strategy is to plan to deploy the per-kb Monday but only test the database branch experimentally on non-critical nodes.
November 07, 2014, 01:20:46 PM
For now please test the Linux version for non-critical nodes (large pools and exchanges please hold off!) if you are able to do so and help us out with any feedback.
Which is best strategy to make upgrade?
November 07, 2014, 01:04:41 PM
Coupled with the relatively shared feeling that we may have touched the bottom, these significant news may finally trigger an upside.
If the news materialize into visible soon, we may definitely break this long fall and get back to growth mode. Growing the community will be up to each of us then.
I feel some positives vibes in the air too!
If the news materialize into visible soon, we may definitely break this long fall and get back to growth mode. Growing the community will be up to each of us then.
I feel some positives vibes in the air too!
November 07, 2014, 10:03:05 AM
There are definitely some positive vibes in the air. Thanks a lot for the update!
November 07, 2014, 09:44:51 AM
Some good progress being made guys, well done.
November 07, 2014, 07:16:55 AM
GUI will make a difference for average people, Memory usage is also a problem atm.
November 07, 2014, 07:12:35 AM
Check out binary options on polo's XMR price:
BTCBINS
It works great and the support is good.
Maybe it can help move the market a bit.
BTCBINS
It works great and the support is good.
Maybe it can help move the market a bit.
November 07, 2014, 06:28:46 AM
Nice one guys! Thanks for the update and keep up the good work.
November 07, 2014, 06:18:52 AM
2. Per-kb fees are ready to go, and has been merged into the master repository! The per-kb fee has initially been set at 0.01 XMR per kb, and we are confident that this will be a suitable fee for the moment. We are not going to enforce a block-point hard fork, but we would appreciate it if major pools could upgrade by Monday. Thereafter, exchanges and users can upgrade over the course of next week as Monero 0.8.8.5 is released.
Yesssss! Thank you!
A n00bish question though: how many kb actually I can expect to have a small-normal transaction? What will be the min fee? 0.1 XMR?
You can click through some blocks here and look at txs: http://chainradar.com/xmr
Looks like typical txs are < 1 kb up to 5 or 6 kb, so it should definitely help reduce the fee paid on most transactions by at least a factor of two and up to an order of magnitude.
November 07, 2014, 06:08:31 AM
2. Per-kb fees are ready to go, and has been merged into the master repository! The per-kb fee has initially been set at 0.01 XMR per kb, and we are confident that this will be a suitable fee for the moment. We are not going to enforce a block-point hard fork, but we would appreciate it if major pools could upgrade by Monday. Thereafter, exchanges and users can upgrade over the course of next week as Monero 0.8.8.5 is released.
Yesssss! Thank you!
A n00bish question though: how many kb actually I can expect to have a small-normal transaction? What will be the min fee? 0.1 XMR?
November 07, 2014, 04:28:44 AM
Any plans to make that database integrated into GUI wallet, so people can use it simple?
For users who car run only "click and done", you'll (we'll) need that, so we can get more people in.
This way as it works now, it's too complicated for a lot of people.
For users who car run only "click and done", you'll (we'll) need that, so we can get more people in.
This way as it works now, it's too complicated for a lot of people.
Yes eventually the there will be a client with a simple GUI setup. There were some screen shots of the prototype start wizard here: https://bitcointalksearch.org/topic/m.8835838
We definitely agree it is too complicated now for a lot of people. The current software is designed and intended solely for crypto enthusiasts and other technically inclined users.
The GUI looks great. But I can imagine that you focus on the internals first.
They are being done by different people at the moment, so both are proceeding, but yes improving the maturity of the internals is the highest priority for now.
November 07, 2014, 04:26:58 AM
Any plans to make that database integrated into GUI wallet, so people can use it simple?
For users who car run only "click and done", you'll (we'll) need that, so we can get more people in.
This way as it works now, it's too complicated for a lot of people.
For users who car run only "click and done", you'll (we'll) need that, so we can get more people in.
This way as it works now, it's too complicated for a lot of people.
Yes eventually the there will be a client with a simple GUI setup. There were some screen shots of the prototype start wizard here: https://bitcointalksearch.org/topic/m.8835838
We definitely agree it is too complicated now for a lot of people. The current software is designed and intended solely for crypto enthusiasts and other technically inclined users.
The GUI looks great. But I can imagine that you focus on the internals first.
November 07, 2014, 04:12:51 AM
great work guys !!
November 07, 2014, 04:05:29 AM
Monday-ish Monero Missives
November 2nd, 2014
............... SKIPPED ...................
Dev Diary
Core: LMDB implementation is complete, and is undergoing testing for drastic rollbacks and edge cases. Please grab and test (link is above)
Core: per-kb fees merged into master, and switchover to the new fee structure is hoped to happen next week.
Until next week!
- updated by fluffypony
November 2nd, 2014
............... SKIPPED ...................
Dev Diary
Core: LMDB implementation is complete, and is undergoing testing for drastic rollbacks and edge cases. Please grab and test (link is above)
Core: per-kb fees merged into master, and switchover to the new fee structure is hoped to happen next week.
Until next week!
- updated by fluffypony
Thank you for great work guys!
Fluffypony, it is absolutely not a problem, if you have decided to take vacations. It is absolutely no problem if all you devs are travelling for a week!
But simply notify us that next missive will be delayed. It is just few words to post here!
Note, it is not our decision to switch missives to per-weekly basis. It is *YOUR* decision, dear devs!
Do not give us a promise that next missive will come "in 12 hours at most". And then be late more than 50 hours. We do not claim promises!
Better, describe what has been already made.
If missives' per-weekly basis is uncomfortable for you - discard it.
But whatever you decide - NOTIFY US as soon as possible.
Encore, great thanks for LMDB progress!
November 07, 2014, 03:32:35 AM
Any plans to make that database integrated into GUI wallet, so people can use it simple?
For users who car run only "click and done", you'll (we'll) need that, so we can get more people in.
This way as it works now, it's too complicated for a lot of people.
For users who car run only "click and done", you'll (we'll) need that, so we can get more people in.
This way as it works now, it's too complicated for a lot of people.
Yes eventually the there will be a client with a simple GUI setup. There were some screen shots of the prototype start wizard here: https://bitcointalksearch.org/topic/m.8835838
We definitely agree it is too complicated now for a lot of people. The current software is designed and intended solely for crypto enthusiasts and other technically inclined users.
November 07, 2014, 03:25:41 AM
Any plans to make that database integrated into GUI wallet, so people can use it simple?
For users who car run only "click and done", you'll (we'll) need that, so we can get more people in.
This way as it works now, it's too complicated for a lot of people.
For users who car run only "click and done", you'll (we'll) need that, so we can get more people in.
This way as it works now, it's too complicated for a lot of people.
November 07, 2014, 02:55:17 AM
Thank you.
How much work is needed to make the DB windows and OS X compatible?
How much work is needed to make the DB windows and OS X compatible?
That is the purpose of LMDB implementation
Yes LMDB certainly works on Windows and OS X. There are a few system specific details to be worked out such as build scripts, and I would say it should be straightforward, except that these something can always go wrong, so better to not promise anything until it is actually done.
For now please test the Linux version for non-critical nodes (large pools and exchanges please hold off!) if you are able to do so and help us out with any feedback.
Jump to: