Would this also work on a RPi B+?
No the ubuntu distro he is using is only for pi 2. It can be made to work and the static build has been compiled for a b+ but the instructions will be somewhat different. |
|
|
|
Anyone can help with synchronization? Cannot connect with network. Need seed nodes or file p2pstate.bin
Thanks!!
Minergate: 176.9.147.178:8380 |
|
|
|
I have noticed that too. Apparently there are wrong calculations...Which pool do you guys consider to be the best one right now?
Best pool by far is monero.crypto-pool.fr. No one denies that's the largest pool, but largest doesn't mean best. On smaller pools your payments will be less frequent, but bigger. On the long run you should be getting more or less the same amount of XMR from each pool (it's also been said that you would be getting a little more from smaller pools, but I don't have the theory to back it up). But most importantly, if you avoid largest pools you will be helping to the decentralization by spreading the network's hash power. You should look for a good pool with low latency in your location. Just make sure to ping the mining server address and not the web server, as they may not be in the same location. Also, if your mining software supports it, you should add a backup pool just in case your main pool becomes unavailable. Avoid small pools , difficulty oscillates by 10-30% during the day, if you mine at a small pool and it hits no blocks during the low diff period than you are at a loss. And if it does hit a block during a low-dificulty period you get a bit extra. Over several days it largely balances out. Mine at a pool that hits a block every 10-15mins
A few blocks per day is plenty imo. The most important factor for a pool is reliability and that you have low latency. Bigger payouts is helpful because it will reduce your transaction fees when you try to spend. One suggestion I remember from a while back that was pretty good is to mine in such a way that you get part of at least 50 blocks. That depends not only on the pool hash rate (or your own hash rate if solo mining) but also your time horizon. |
|
|
|
One thing though.... I tested the Berkeley DB implementation on my laptop and on a VPS, and it was taking ages to sync. Let me knows how it works out for you on the Raspberry Pi.
Hopefully LMDB issues for RPi will be fixed soon.
Yes, Berkeley database is slow. I think it's going to take about 4 days to sync fully. A large part of the performance issue on RPi is simply the device itself being extremely low performance (although it does have multiple cores which we aren't really using so that will improve at some point). With no database at all it is only about 2.5x as fast as with bdb. That's the ceiling on any database implementation right now, and the current lmdb implementation won't be close to that ceiling. 4 days is optimistic, I think. But what's the hurry? The thing uses 2 watts -- just let it run. |
|
|
|
It's interesting that the orderbook always has so much more liquidity on the buy side than the sell side even in times when clearly supply and demand are clearing with each other rather equitably (such as over the last couple weeks where we have been hovering in a 0.003-0.004 range). If there were really so many more buyers than sellers than we would not be trading in a range we would be going up. So the sellers are out there, they are just not accounted for on the order book. Any idea why?
I think they just dump. It is a sort of (temporary of course) equilibrium as rpietila pointed out. The sellers don't need to wait because the buy book is strong so they can just dump and the buyers don't need to bid up because of all the dumping. |
|
|
|
(NOT Coinbase, Bitpay, Dell, Microsoft -- they don't soak up supply. They juggle bitcoins and then throw them back onto the market.)
Coinbase is a bit different. A significant part of their account base is investors, maybe not big ones, but people buy some Bitcoins via Coinbase and leave them there. As for Dell, Microsoft, Overstock, etc. and most of Bitpay/Coinbase merchant customers (there maybe some exceptions there, not clear), not only do they not soak up Bitcoins, but their volume, after the initial publicity, is very close to zero. |
|
|
|
Let's conduct a thought experiment. Imagine that network splitted for 24 hours and there are 2 competing branches. Thousands transactions are processed, thousands goods are delivered to the buyers. Now the network is merged and we see that the longest chain contains only 30% of the transactions but the shortest the rest 70%. Which network will win? BCNext thinks that the shortest one, coz economic majority will decide to lose less than more (we assume that loss is proportional to number of rolled back transactions), and I tend to agree with him. The reader is free to have another opinion of coz.
Another experiment. 20% of Bitcoin economy that owns 65% of hashing power decided to fork Bitcoin and add unlimited supply of the coins. Let's assume that they would mine 25 BTC per block forever. There are no other differences. What blockchain will a new user download? Of coz the one with unlimited supply because "the longest chain wins". Will the user agree on that? I doubt he will chose 20% of economy instead of 80%. And again we see that economic laws are more important than "mathematical" ones.
These two cases are quite different. In the first case, both chains are valid according to the protocol definition. In the second case they are not. It is possible that "economic majority" would win over protocol in the first case, but I'm not sure about that. Although people conducting trade on the shorter branch stand to lose money, and that interest is stronger in the short term, it may still be the case that respecting the integrity of the protocol is viewed as more valuable because that is something that protects everyone, including those losing money in this particular instance, in the long term). In the second case there is no issue here. A chain that does not conform to the protocol is not a valid chain at all, therefore it can't be the longest chain. It's just garbage. There is a variation of the second case where the economic majority decides to change the protocol. That is more interesting. |
|
|
|
|
Enough eMunie unless there is an actual (open source) product to examine or at least a paper to read. Otherwise it is irrelevant to
Monero. Zero posts deleted
|
|
|
|
I am sorry that your explanation did not inspire confidence to invest in it. Despite my totally non-tech background, I know reasonably well how Monero operates, and it should not be impossible to gain the same understanding from emunie, although not from that explanation  Yes, I would not recommend anyone make investment decisions from random forum posts, but I suspect you already know that  Everyone needs to do their own research and make their own mind up. I was skeptical of emunie for a long while, but I am excited by their attempt to use the basic truth of the Quantity Theory of Money (MV=PQ) within a P2P network where all vaiables are known in real time, to achieve a worthwhile goal of price stability. Whether they achieve that is uncertain, but if they do then things will change quite a bit. Why is this simplistic economic equation MV=PQ so popular, even among many bitcoiners ? It's pseudo science in my opinion. Even? There is just as much pseudo science here as anywhere else. There is nothing wrong with MV=PQ. It is a tautology though. The issue comes when people try to make inferences using it, often holding values constant when they should not be. |
|
|
|
I am opposed, as I think that a project started as a Monero fork should remain a Monero fork absent some good reason for a change (such as Monero becoming unmaintained).
And as I said, I believe the demand for a Bytecoin fork is adequately met by dashcoin.
However, if there is strong community support for turning AEON into a Bytecoin fork I will step aside.
Since you are the current maintainer, your opinion should have higher weight, as I said I am really interested in multisig, what would you think about going the other way around, that is, including the multisig transactions in the monero fork? I like the idea. I don't like a license change that will make it impossible to deliver the code in a mobile app-store format (at least on iOS where static linking is required). This includes even lightweight wallets and transition signing tools (such as using multisig for 2FA) using the code base as a library. Note that Bytecoin does not suffer from this restriction because it is their own project so they can disregard the license. But with the change to LGPL they have inserted a bit of a poison pill for anyone else who wants to use their code. I'd rather see the effort going into a new multisig implementation with a less restrictive license. That I would be 100% behind, and I might even contribute some funding for it if that matters. Given that the Bytecoin multisig solution doesn't rely on advanced cryptography and is essentially a basic scripting system (as I understand it, but I haven't examined it carefully), I don't see this as being particularly difficult. I guess I will have to dive inside the original source and the current monero codebase then This will take some time. I can point out the issue. The original cryptonote white paper and the transaction types defined in cryptonote_basic.h allow for scripts but it was never implemented. So the task consists of implementing either enough of a scripting language (can be the one from the white paper or another, possibly even simpler, one) or just a special hard coded (no script) transaction type that allows for N/M multisigs. Then modifying the valid transaction type check and implementing code to verify the signatures. Overall it's a fairly simple task. The hard part is very careful coding and testing. You can read a brief summary of some of the license issues here: http://stackoverflow.com/questions/459833/which-open-source-licenses-are-compatible-with-the-apples-iphone-and-its-offici |
|
|
|
I am opposed, as I think that a project started as a Monero fork should remain a Monero fork absent some good reason for a change (such as Monero becoming unmaintained).
And as I said, I believe the demand for a Bytecoin fork is adequately met by dashcoin.
However, if there is strong community support for turning AEON into a Bytecoin fork I will step aside.
Since you are the current maintainer, your opinion should have higher weight, as I said I am really interested in multisig, what would you think about going the other way around, that is, including the multisig transactions in the monero fork? I like the idea. I don't like a license change that will make it impossible to deliver the code in a mobile app-store format (at least on iOS where static linking is required). This includes even lightweight wallets and transaction signing tools (such as using multisig for 2FA) using the code base as a library. Note that Bytecoin does not suffer from this restriction because it is their own project so they can disregard the license. But with the change to LGPL they have inserted a bit of a poison pill for anyone else who wants to use their code. I'd rather see the effort going into a new multisig implementation with a less restrictive license. That I would be 100% behind, and I might even contribute some funding for it if that matters. Given that the Bytecoin multisig solution doesn't rely on advanced cryptography and is essentially a basic scripting system (as I understand it, but I haven't examined it carefully), I don't see this as being particularly difficult. |
|
|
|
|
I am opposed, as I think that a project started as a Monero fork should remain a Monero fork absent some good reason for a change (such as Monero becoming unmaintained).
And as I said, I believe the demand for a Bytecoin fork is adequately met by Dashcoin.
Finally, if for some reason you don't like Dashcoin, and you don't feel being a Monero fork is a good path, you can start a new Bytecoin fork.
However, if there is strong community support for turning AEON into a Bytecoin fork I will step aside.
|
|
|
|
I'd like to make the suggestion that possibly getting in contact with any game developers, likely MMORPG game developers might be a good route to pursue if you're looking to study the effects of various inflations on the value of simulated currencies revolving around simplistic economic models.
Obviously, CKG would be a comparison, but its infancy would likely not yield enough information.
Anyone know anyone that works at Blizzard?
I don't know about Blizzard but the Valve economist guy is somewhat busy right nowYou mean he's busy pumping litecoin with the crappiest arguments you can find even in the deep bitcointalk mud? (watch at 1'10): https://www.youtube.com/watch?v=JLu1yAeWNtwWow worst call ever. LTC in December 2013. LOL |
|
|
|
I'd like to make the suggestion that possibly getting in contact with any game developers, likely MMORPG game developers might be a good route to pursue if you're looking to study the effects of various inflations on the value of simulated currencies revolving around simplistic economic models.
Obviously, CKG would be a comparison, but its infancy would likely not yield enough information.
Anyone know anyone that works at Blizzard?
I don't know about Blizzard but the Valve economist guy is somewhat busy right now |
|
|
|
Is the 1 BTC + 500 XMR bounty still available for an open source AMD miner?
My pledge is still good. I can't speak for the others and no funds have been collected so it is up to them. |
|
|
|
This is getting a bit off topic but one idea that has been proposed is to simply emit one unit per hash of proof-of-work. (No magic numbers at all!)
The bold part is sarcastic, right? No, not really. 1 hash = 1 unit removes the magic numbers from things like inflation rate, coin supply, etc. That doesn't make it a good approach necessarily. It sounds as abritrary as anything else to me. Has the "advantage" of being a round number, but that's all. EDIT: I mean arbitrary as "magic number". The growth rate is tied directly to a physical property. Advantage? Disadvantage? I'm not sure, but it is different from just setting a mathematical growth rate as with Bitcoin or Monero. |
|
|
|
This is getting a bit off topic but one idea that has been proposed is to simply emit one unit per hash of proof-of-work. (No magic numbers at all!)
The bold part is sarcastic, right? No, not really. 1 hash = 1 unit removes the magic numbers from things like inflation rate, coin supply, etc. That doesn't make it a good approach necessarily. |
|
|
|
So no economic reasoning whatsoever to the choice of approx 0.9% inflation?
There is plenty of economic reasons, first being to secure the network,[/b] without network no transactions, like rpietila said its close to what gold is now. 1% is bellow the long-run ideal inflation on a large scale economy (believed to be 2%). 1% runs of the risk of deflation with eventual lost coins it will become de-facto deflationary in the long run. I didn't say tail emission was a bad idea. I agree with it. It just shouldn't be a "magic number" value. And Monero is NOT gold. Most everything about it is quite different than gold. There seems to be no logical reason to choose that value based on "that's how gold is". It wasn't logical, it was indeed a magic number (at least 1% was; 0.3 coins/minute is derived from the 1%/year) chosen at the start more or less arbitrary manner based on subjective views of what was useful to do. If it turns out to be a disastrous choice with horrible consequences, then Monero will fail. This is an experiment. Sure, we can just say "hey it is an experiment". But wouldn't it be nicer to have a logical economic reasoning with maybe not precisely predictable results, but at least an intelligently planned results? I already see interesting brain storming in the last few posts. Generally the less magic numbers, the better. Something for Monero Research Labs maybe... EDIT: If I'm dragging this on in the wrong thread just ask and I'll happily move it elsewhere. I think its somewhat relevant to speculation in that if you think the parameters are extremely poor, the coin will likely fail. If you think that just picking a (vague reasonable) number and going and implementing something to see if it might succeed is a hopeless approach, you likely also think the coin will fail. |
|
|
|
|
This is getting a bit off topic but one idea that has been proposed is to simply emit one unit per hash of proof-of-work. (No magic numbers at all!)
This is obviously terrible for value stability in the short term. Moore's Law means that the money supply will inflate at something like 60% per year. Longer term though, when Moore's Law hits the wall, it should slow way down and also inflate somewhat faster during periods when the demand for money increases (due to more R&D going to faster hashing).
|
|
|
|
So no economic reasoning whatsoever to the choice of approx 0.9% inflation?
There is plenty of economic reasons, first being to secure the network,[/b] without network no transactions, like rpietila said its close to what gold is now. 1% is bellow the long-run ideal inflation on a large scale economy (believed to be 2%). 1% runs of the risk of deflation with eventual lost coins it will become de-facto deflationary in the long run. I didn't say tail emission was a bad idea. I agree with it. It just shouldn't be a "magic number" value. And Monero is NOT gold. Most everything about it is quite different than gold. There seems to be no logical reason to choose that value based on "that's how gold is". It wasn't logical, it was indeed a magic number (at least 1% was; 0.3 coins/minute is derived from the 1%/year) chosen at the start more or less arbitrary manner based on subjective views of what was useful to do. If it turns out to be a disastrous choice with horrible consequences, then Monero will fail. This is an experiment. |
|
|
|
|
Show Posts
