2016-Jan-02 20:05:06.652046 [RPC1]ERROR C:/msys64/DISTRIBUTION-BUILD/src/crypton
ote_core/miner.cpp:239 Starting miner but it's already started
Isn't this clear? Your daemon is already mining. The wallet has commands to start and stop mining but once you start, as long as the daemon is still running it will continue to mine even after the wallet exits. |
|
|
|
|
"We would be trying to predict what the market would decide, rather than vying over control of the One Ring of Power - the official/reference implementation of Bitcoin. Much rancor could be dispensed with."
@Zangelbert Bingledack, I'm somewhat sympathetic to your cause but I don't really see how the market mechanism operates here, outside of a very broad definition of "market" which encompasses politics. Node voting doesn't work at all. Without that you are still reduced to politics and whoever shouts the loudest in trying to convince miners what block size they should use.
|
|
|
|
1) So I fire up 2000 nodes, all selecting 200MB as cap.
2) I make the miners belive this is the prefered block size.
Why do you believe that miners are really that stupid? My point is that it opens up to sybil attack. My suggestion is obviously a quick and dirty model. Okay, I agree with that. EDIT: How would miners actually know what the "real" consensus is? Ask around on the forum? What if I set the blocksize to 14MB. That would still knock off plenty of nodes.
See my post above. I think I read somewhere a Peter R post where he suggested the case of miners with BU sticking with 1 MB for a while. Then (especially when there is fee pressure) one brave miner might deem it worth the risk and try 1.1 MB to see what happens. If "nothing bad" happens, other miners would likely follow. Extrapolate from there. |
|
|
|
1) So I fire up 2000 nodes, all selecting 200MB as cap.
2) I make the miners belive this is the prefered block size.
Why do you believe that miners are really that stupid? |
|
|
|
Current situation: blocksize cap for the network is set by miners/nodes converging on either Core, XT or something else by downloading and running Core, XT, etc. ... and making the decision not to modify this code. |
|
|
|
Nodes will then have to follow the rules ascribed by miners, and their vote is pointless as consensus is formed by those who mine. Which means, Adam will still get kicked off the network, when the winning miners decide on 2MB blocks, and Adam only accepts 1.1MB.
You go wrong in thinking that miners are all-important. I clearly stated "the majority of nodes decide the consensus", not only miners. As other have stated multiple times in this thread, miners have to be sensitive to where the real money comes from, ultimately. As such, the "vote" expressed by BU nodes through the settings they choose to run, is an important piece of information to miners. It is certainly not pointless. It would be pointless to ignore it, as a miner. If it is supposed to be a "vote" then I agree with the other comments here that it is trivially sybil attackable and pointless. If it is supposed to be an anti-spam protection that avoids having your node flooded by huge blocks that the longest chain does not accept, that is not necessarily pointless. In the latter case, the miners will have to come to their own conclusions as to the "best" block size to produce, almost entirely independently of this propertied "vote" (using market research, experimentation, etc.). I agree with you that a "vote" of nodes is information, but it is almost worthless information so it should be almost entirely ignored. |
|
|
|
It matters because miners do not have an economic interest in forcing end users off the network. End users provide fees and demand for the currency which is how miners make money.
But if BU will switch to the longest chain eventually anyway, then what exactly is the point of your limit? Your limit is a function of the resources you want your node to consume. Above that limit, your node either rejects large blocks that are spam (not accepted by the longest chain), or drops off the network because it can't keep up. You can't blindly accept a 2 Mb block just because it's below your limit, as it might be orphaned because no other miner agreed on it.
How does this differ from any other block? So you will still have to wait like 6 blocks.
I don't remember seeing anything about BU promising faster (statistical) finality than regular Bitcoin. |
|
|
|
You still need a delay to see what size the miners picked, so your limit doesn't matter.
It matters because miners do not have a direct economic interest in forcing end users off the network. End users provide fees and demand for the currency which is how miners make money. There may be indirect interests though. |
|
|
|
In the interest of this "review", I will point out a point commonly not understood by those new to BU:
BU follows the longest chain.
That is my limited understanding of BU. In fact I believe I was the one (as part of an interaction with Peter R) on the GcBU thread who pointed out that the satoshi whitepaper can be read as effectively miners making all the rules on what constitutes a valid block. End user nodes would also implement verification for protection against short term chain forks, but they would validate based on rules set entirely by miners. So as an end user, if miners change the rules, you would simply need to implement those changes in your node, or you would be unable to process the longest chain, and therefore no longer a participant. This is certainly a different security model than what many in the Bitcoin community have come to understand over the past several years, where forks are accepted by an "economic majority" and "longest chain" is replaced with "longest valid chain". But it seems that (maybe) BU proponents want to adopt a stricter "longest chain" rule that vests all of the rule-making power with miners. I'm neither agreeing nor disagreeing here; I'm trying to state the position to see if I understand it. Now in the case of BU specifically, I'm not sure I understand how this works when the user has configured a smaller block limit than is present on the longest chain? Does their node switch into an "offline" state based on block headers? The user then has a choice to adjust their setting (and network bandwidth, etc.) or stay off the network? And longest chain is a rule set by nodes, correct? As I understand it, the rule is solely set by proof-of-work (i.e. large sum off difficulty). Any node that is off the chain with the most work is considered off the network. In that case it would be sybil proof, because proof-of-work can't be replicated. Let's see if I'm right. |
|
|
|
The Ring CT work and the GUI work are completely independent. Multisig is likely getting combined with Ring CT at this point. I thought the GUI release was being held until Multisig? I'm not promising any schedules here, I'm just pointing out that the work requires different skills sets and will likely be done by different people. Once we finish wrapping up some loose ends from the release we'll begin to work more on the forward roadmap. Well, my question really relates to the roadmap as I would assume we can now start the next crowd fund. There should be some updates soon, and I guess funding proposals. That's not really something I follow closely. |
|
|
|
The Ring CT work and the GUI work are completely independent. Multisig is likely getting combined with Ring CT at this point. I thought the GUI release was being held until Multisig? I'm not promising any schedules here, I'm just pointing out that the work requires different skills sets and will likely be done by different people. Once we finish wrapping up some loose ends from the release we'll begin to work more on the forward roadmap. |
|
|
|
The Ring CT work and the GUI work are completely independent. Multisig is likely getting combined with Ring CT at this point. |
|
|
|
I have replaced Monero 0.9 beta files with the ones in the final release. Started bitmonerd.exe to sync block chain. After fully sync-ed for a while, Monero still occupied 1,300,000 - 1,600,000 K (1.2GB - 1.5GB RAM) for Working Set (shareable memory) and 56,000K (55 MB Privating Working Set)
Yes the so-called shareable memory is caching of the database file, and will be freed up as needed by the OS. It is called shareable because theoretically there could be multiple applications accessing the database sharing that memory, although that isn't the case in this particular usage. |
|
|
|
Thank you King! Not that I have listed all my contributions, but today gave 1,000 CKG (valued about 900 XMR) to the Monero House. Just wanted to bump the thread  Thank you all the devs for making it happen! |
|
|
|
Hydrogen Helix runs fantastic on OSX.
Any plans for implementing the terminal buttons? (Tab for filling in, and up arrow for last command)?
Thanks!
rlwrap works on Linux (mentioned at the end of the README file). I don't know if there is an equivalent utility on OSX. |
|
|
|
Interesting comment from Shen about multisig yep - very likely will be implemented in conjunction with the ring ct stuff
Following the "written up" link in the Ring CT post, section 4.4 of the paper describes how to implement "Ring multisignature". Some of the other CryptoNote coins have multisig, but only with 0 mixin. Very nice work being done on the crypto front. |
|
|
|
Is the daemon supposed to pass blocks synced during a session out of memory?
The blockchain is stored on disk first and foremost. Your OS might or might not also keep some portion of it in memory as a form of caching, depending on the amount of other memory usage on your computer. The synced blocks during my sessions have been appearing in memory and grow until my memory is maxed out. These are cleared only when I exit the daemon. The blockchain itself is being saved to disk, but my ram usage grows with each reported synced block. I am syncing from nothing. My programs hang as the memory becomes maxed out. Is this a bug? That does not sounds like you are using the current version. I'll try resyncing from scratch again, as I'm almost caught up. The version I am using is the HH release from github yesterday, windows. It put 1.59 GB from my most recent session into memory over one hour. Note this is not what It starts up with, which is around 200 Mb. Just figured I'd ask, because I remembered you posting that it only took up a few hundred mb as well. In total it took 1.79 Gb before I restarted it. TY smooth. As I said it will use what you have. If no other programs are using the memory, then your OS will give it more (especially during sync). If other programs need RAM, the memory usage for the node will shrink down to almost nothing (especially once synced). However, you shouldn't see anything hang. That was what I thought pointed to a problem. |
|
|
|
Is the daemon supposed to pass blocks synced during a session out of memory?
The blockchain is stored on disk first and foremost. Your OS might or might not also keep some portion of it in memory as a form of caching, depending on the amount of other memory usage on your computer. The synced blocks during my sessions have been appearing in memory and grow until my memory is maxed out. These are cleared only when I exit the daemon. The blockchain itself is being saved to disk, but my ram usage grows with each reported synced block. I am syncing from nothing. My programs hang as the memory becomes maxed out. Is this a bug? That does not sound like you are using the current version. The usage, as I said, may increase if your OS decides to keep some of the blockchain in RAM as a cache. But that should not cause anything to hang. The memory usage should be freed up if needed. But perhaps there is some other problem. It is hard to say on a forum. Maybe go freenode IRC, channel #monero, and see if someone can help you figure out what is going wrong. https://webchat.freenode.net |
|
|
|
Congratulations and thanks to all who made v0.9 possible! I downloaded the linux64 binaries today as well as blockchain.raw. I used this to create the blockchain (used my actual path to download.raw): sudo blockchain_import --input-file /path/to/your/download.raw --verify 0After that process completed, I ran this command: sudo ./bitmonerod...and got this error message: Creating the logger system
2016-Jan-02 00:43:04.712691 Initializing cryptonote protocol...
2016-Jan-02 00:43:04.712868 Cryptonote protocol initialized OK
2016-Jan-02 00:43:04.713234 Initializing p2p server...
[1451713384] libunbound[4214:0] info: warning: unsupported algorithm for trust anchor . DS IN
[1451713384] libunbound[4214:0] warning: trust anchor . has no supported algorithms, the anchor is ignored (check if you need to upgrade unbound and openssl)
2016-Jan-02 00:43:04.743525 Set limit-up to 2048 kB/s
2016-Jan-02 00:43:04.743885 Set limit-down to 8192 kB/s
2016-Jan-02 00:43:04.744098 Set limit-up to 2048 kB/s
2016-Jan-02 00:43:04.744425 Set limit-down to 8192 kB/s
2016-Jan-02 00:43:04.745453 Binding on 0.0.0.0:18080
2016-Jan-02 00:43:04.745744 Net service bound to 0.0.0.0:18080
2016-Jan-02 00:43:04.745867 Attempting to add IGD port mapping.
2016-Jan-02 00:43:08.832162 Added IGD port mapping.
2016-Jan-02 00:43:08.832325 P2p server initialized OK
2016-Jan-02 00:43:08.832571 Initializing core rpc server...
2016-Jan-02 00:43:08.832728 Binding on 127.0.0.1:18081
2016-Jan-02 00:43:08.832939 Core rpc server initialized OK on port: 18081
2016-Jan-02 00:43:08.833045 Initializing core...
2016-Jan-02 00:43:08.833459 Loading blockchain from folder /home/mike/.bitmonero/lmdb ...
2016-Jan-02 00:43:08.833574 option: fastest
2016-Jan-02 00:43:08.833667 option: async
2016-Jan-02 00:43:08.833759 option: 1000
2016-Jan-02 00:43:08.834491 LMDB memory map needs resized, doing that now.
2016-Jan-02 00:43:08.834707 LMDB Mapsize increased. Old: 10215MiB, New: 11239MiB
2016-Jan-02 00:43:08.908128 Error attempting to retrieve a hard fork version from the db
2016-Jan-02 00:43:08.908449 ERROR /DISTRIBUTION-BUILD/src/daemon/daemon.cpp:146 Uncaught exception! Error attempting to retrieve a hard fork version from the db
2016-Jan-02 00:43:08.908585 Deinitializing rpc server...
2016-Jan-02 00:43:08.908876 Deinitializing p2p...
2016-Jan-02 00:43:08.910596 Deinitializing core...
2016-Jan-02 00:43:08.911011 Closing IO Service.
2016-Jan-02 00:43:08.957527 Deinitializing cryptonote_protocol...
Any ideas? EDIT: All files in the log directory were empty. Looks like maybe a problem with the import tool. While it is being investigated I suggest you just sync from the network instead. Most people have found that to be fast and efficient. Also, you shouldn't really need to sudo for the daemon, it should work fine without privileges, though now that you have done it once the permissions on your .bitmonero folder might be messed up. Try renaming it to something else. |
|
|
|
|
Show Posts
