hi
how can I change the directory
where to store the database?
there is an option I think --data-dir or something like that (sorry I can't check right now). Also, if you are on linux you can symlink .bitmonero to somewhere else. |
|
|
|
IMHO the only reason why orphans are bad is because they are rising the efficiency-gap between miners/pools with slower bandwith vs miners/pools with higher ones which would lead to more mining centralization but please correct me if thats wrong - its just my head trying to figure out p2p  edit: i have seen this happen live with an early p2pool version and bitcoin. p2pool has many many small blocks (they call them shares). my p2pool node was on my server - many have run it at home. i had WAY less orphans and was much more efficient (to a point where i was more efficient than i should be - effectively stealing some btc from people with a bad connection - i stopped mining there then [well i completely stopped mining btc and sold my two remaining gpus]). It's not the only reason but it is one reason, and its a huge one. Decentralization is the entire reason for these coins to exist at all. Without that the entire system is a huge waste of resources. It also increases resource use (especially for lightweight wallets) and makes the network less resilient to failing altogether. A common change in altcoins is to increase the block frequency, due to a misunderstanding of the purpose and meaning of transaction confirmations. This increases the frequency of minor blockchain forks (which result in stale blocks and wasted mining power) and also increases the bandwidth and validation costs of non-mining nodes. Both of these tend to increase centralization.
If the block frequency is very high, new blocks will be produced faster than blocks can be transmitted and verified. This destroys consensus since nodes are essentially always seeing competing blockchains in the past. (Remember that consensus time is measured by total blockchain difficulty, roughly, blockheight.) Therefore the first chain that they see will always appear longer than the others, and every node will have a different idea of the best chain.
This happened to feathercoin, which had 60-second blocks. They were unable to achieve distributed consensus, so the network was changed to require developer signatures on all blocks. |
|
|
|
please don`t judge me and don`t blame me more, i don`t want to participate in that fud discussion and i don`t want my good name to be used in such a lists! @smooth, my old friend, hello, and please, protect me  I had nothing to do with that list I'm not sure why you even mentioned me. And hello danteT. I would by lying if I said I did not have some fond memories of you and the rest of the group from first days of the Bytecoin 'mystery'. @Rias: Sure there might be stuff around from 2014, or even possibly late 2013 when bytecoin was finished and launched. I see no independently verifiable evidence of anything from 2012. |
|
|
|
Yeah, so
TL;DR
1 minute blox is gude
I'm reasonably sure I discussed this in the LTB podcast, but basically TFT's decision for a 1 minute block time was nonsensical. We don't know why he chose it, but it definitely wasn't based on any form of logic. Personally, if I had to do it over I'd probably go for a 3 minute block time or so. We're also not closed to changing Monero's block time to 2 minutes, for eg., and doubling block rewards to match. However, it's low priority at the moment, and will require more research before we put a peg in the sand on that. Possibly the outcome of that research is "the current affect is not drastic, and technology is changing so rapidly that we don't see a need to change it", but we can only know once we get to it:) I have only a slightly different view. If the decision was nonsensical and wasn't based on logic, then it should just be changed to something sensible at the earliest convenient opportunity. There is no need to do research to undo something that was nonsense and had no research supporting it to begin with. Every opportunity that goes by without fixing it is a decision that is being made without research to continue what TFT started. Then, once that is out of the way, it certainly makes sense to do research into whether it should be changed again, how to improve things, and so forth. There is little practical difference at the moment, as it certainly isn't a convenient opportunity to make such a change, with the DB and other more urgent items in play. |
|
|
|
Is this new wallet open source because I never download crypto-related binaries, and most serious crypto investors are the same. It's much too dangerous.
LOL, on the main Bytecoin thread all you scream is this coin is a scam, and in here you sound like an interested supporter ...... its obvious that your only interested if the wallet is open source... aren't you one of the XMR dev ? I am part of the Monero Core team. I also have mined BCN on various occasions and I still have some. I won't use anything for any crypto that is not open source though and that has nothing to do with BCN or XMR. |
|
|
|
ArticMine is right, Monero being the electronic cash of the future needs the 1 min confirmation time. 30 secs would be good but theres no reason to change imo. When tail emission kicks in and blocks are 0.3 XMR, the 1 min confirmation time will make even more sense.
Sure, but whether or not Monero needs it matters less than whether or not it's currently possible (without sacrifice). Ultimately, I believe point-of-sale transactions will eventually be handled off-chain, which makes the case for 1 minute block time somewhat irrelevant. OK here is another scenario. You fund an account to make an off chain point of sale transaction. A 5 min wait time is acceptable while a 30 min wait time is not. There is a tradeoff here and we need to find the optimal solution. The problem is you can't really guarantee 5 minutes or even 30 minutes. Several weeks ago I was moving some Bitcoin and it took over an hour for one confirmation. And then a week later I did the same thing and I waited close to an hour for one confirmation again. The probabilistic nature makes it very hard to use confirmations to meet any kind of real-time requirement. Granted if you are conservative enough (multiples of the target time), there are some targets you can meet with high probability that you can't meet with a slower target. In that sense I agree with ArticMine and Anon136 to a point, I just find those cases to be of limited value compared to the inherent disadvantages of an aggressively fast block time right now. |
|
|
|
a transaction with 10 blocks in 10 minutes is 512 times more secure than a single block in 10 minutes.
No, it isn't 512 times "more secure" it has a 512 times smaller result using this particular probabilistic model of one aspect of security. That is not the same thing at all. For example, a less decentralized network is "less secure" because it violates the assumption in proof of work of any actor having a "small" share of the hash rate (an inconvenient truth that is conveniently ignored in Bitcoin and most if not all other PoW coins today). There is also an upper bound on practical security from the absolute hash rate (regardless of how it is broken up into blocks) because an attacker can just buy or build the necessary hash rate to defeat an arbitrarily large number of confirms. So as discussed on that thread I linked, these results only apply directly when: 1. Orphans are not a major consideration 2. The absolute hash rate is high The context there was Bitcoin with 10 minute blocks (orphans not a major considerations) and a hash rate cost in the hundreds of millions of dollars (absolute hash rate is high). Neither of those applies to Monero today. |
|
|
|
ok here is the formula. a = percentage of the total network hash rate controlled by attacker (expressed in decimal notation) b = # of blocks n = likelihood of discovering b # of blocks for a % of total network hashrate before anyone else f(n)=a^(b-1) (im sure this can be simplified but w/e it works) So back to our 2 blockchains. If the attacker wants to double-spend and has 25% of the total network hashrate, than his chances of discovering 1 block are 25%. 2 blocks in a row is 12.5%. and after 60 minutes like bitcoin wants you to wait. its 4.3368087e-19. So the point is that there is an inherent advantage to security resulting from fast blocks. As such the acceptable orphan rate would be a reasonable trade off. It wouldn't come from some effort to approach as close to 0 as you can. Once its too high of course single actors get a bigger advantage since they dont have to wait to start mining ontop of their own block. But the preferable trade off would probably be a higher orphan rate than most people think. You would have to develop some models to get a good idea, but probably 5% is totally reasonable. These time scales just don't matter. If you want 5 second transactions, you can't get it this way. If you have to wait an hour for effective finality, you can wait a few hours. There is no significant benefit that would offset the disadvantages of an unstable network and pressure toward centralization. Ok well its completely wrong to say the timescales dont matter. This is a black and white fallacy. There is no on off switch here between hours and seconds. Its a smooth sliding scale all the way across the spectrum between them. At each point on that scale there is a marginal consumer somewhere. I don't agree. The significant benefit is from real time (up to maybe 30 seconds) and then pretty much everything else is a minor benefit from going faster or slower because it isn't real time. 10 minutes vs. 20 minutes is really not a game changer. This has been discussed pretty widely in the context of Bitcoin recently. You should review some of those discussions (I don't remember exactly where but I saw them on reddit) because they apply in almost exactly the same way to Monero. Even a block time of 30 seconds doesn't give you "real time" 1-confirm transactions because it is random. You could have to wait several times the average (and that will happen regularly). |
|
|
|
ok here is the formula. a = percentage of the total network hash rate controlled by attacker (expressed in decimal notation) b = # of blocks n = likelihood of discovering b # of blocks for a % of total network hashrate before anyone else f(n)=a^(b-1) (im sure this can be simplified but w/e it works) So back to our 2 blockchains. If the attacker wants to double-spend and has 25% of the total network hashrate, than his chances of discovering 1 block are 25%. 2 blocks in a row is 12.5%. and after 60 minutes like bitcoin wants you to wait. its 4.3368087e-19. So the point is that there is an inherent advantage to security resulting from fast blocks. As such the acceptable orphan rate would be a reasonable trade off. It wouldn't come from some effort to approach as close to 0 as you can. Once its too high of course single actors get a bigger advantage since they dont have to wait to start mining ontop of their own block. But the preferable trade off would probably be a higher orphan rate than most people think. You would have to develop some models to get a good idea, but probably 5% is totally reasonable. These time scales just don't matter. If you want 5 second transactions, you can't get it this way. If you have to wait an hour for effective finality, you can wait a few hours. There is no significant benefit that would offset the disadvantages of an unstable network and pressure toward centralization. |
|
|
|
This is really good! But what does it have to do with monero? It's inspired by the war thread and it's also a great branding and promotional tool. How many coins have their own mixes? |
|
|
|
I am trying to find some statistics on the the current orphan rate for Monero.
It's hard to do because they aren't propagated. If your node is close to the "center" of the network you may see very few, but nodes with slower propagation will see a lot. The winning fork will likely be the one that propagates to >50% of the network. If you're usually in that >50% portion, you will see few reorgs. Nodes outside that "center" will see more. Also the optimum appears the be the smallest time that gives close to zero orphans even in a decentralized network (not just a few pools with fast connections to each other)
That is somewhat hypothetical, but certainly desirable. |
|
|
|
they've just blocked Internet Archive from crawling bytecoin.org, this means any archive it had is not accessible anymore: https://web.archive.org/web/*/http://bytecoin.org They probably did that to reduce load on their web server /s |
|
|
|
|
The issue with orphans isn't just lost hash rate, it that orphans represent a symptom of the failure of the network to stay in consensus.
The way orphans happen is the network splits into parts, and during that time both (or all if >2) parts have an equal length chain. Eventually the split is resolved "orphaning" one of the chains, but not until one or the other becomes decisively longer, which may be two, three or more blocks later (it always takes at least two). During this time not only is there a natural break in consensus but an attacker can piggyback on that (by opportunisticaly waiting until a fork naturally occurs, then starting the attack). So for example, if an attacker is trying to create a 6-block fork, but the network has already created a 3-block fork, the attacker need only create a 3-block fork on top of it). Selfish mining is a variation of this.
Also, in terms of mining centralization, non-trivial orphans are bad because they give an advantage to larger miners/pools. You won't ever orphan your own blocks so if you have 30% of the hash rate you will have at least 30% fewer orphans and be that much (3% in this case) more profitable than smaller miners/pools. With naturally thin mining margins that is an enormous advantage.
|
|
|
|
Personally, I believe that the project was created in 2012 in a rough minimum viable product, which simply did not take off.
Show me even a sliver of independently verifiable evidence. That does not include web sites and onion sites that were first reported to exist in 2015, shortly before the release of a Bytecoin update. |
|
|
|
Sounds more like conspiracy theory to me. I'd say there's something more behind the Bytecoin story, and there are more things pointing to 2012 as a project launch year rather to the smooth's version of events. Personally, I believe that the project was created in 2012 in a rough minimum viable product, which simply did not take off. I tend to agree with Halon's razor in this case. Nope, already contradicted by statements made by Bytecoin supporters. Not going to explicitly point them out though (for now) I've said before that the more bullshit they spin up the more contradictions will be created, and that is true. They should really stop digging. But a good portion of all of this is merely speculation. For all we know the people you say are creating the backwards statements arent even involved in the creation. Isn't it possible for others to perpetuate all of this without truly having anything to do with the coin itself, something like a takeover. This is no different than Satoshi creating bitcoin and everything to include updates and posts being handled by others. In a sense it doesn't matter at all who "created" it (could be aliens!). We know who is promoting it, and we know they are lying scammers, if only because of their own contradictions. Also, the official bytecoin web site at one point claimed that a Princeton professor was part of the team and gave biographical information (I saw it). Someone did the research and figured out that no such professor existed (I checked this and confirmed it). It was pure fraud. They took the alleged "team member" off the web site which was likely a good idea because institutions such as Princeton are quite powerful and don't take kindly to their name being falsely used to promote scams. There is also from the weight of the evidence as evaluated by credible independent objective observers, such as actual professors that really exist: I have no horses in the XMR race (but I do hold some BBR), but let me say that independent of the OP -- and with a little less venom and swearing -- it was very clear from the code that the bytecoin premine was fake. Nothing to do with the whitepaper, and you can find the obsfucated and slowed-down code in the git history of XMR and Bytecoin. I have no comment about the other coins, and personally believe both that the XMR dev team is reasonably clean and that BBR was a good-faith effort to create something non-scammy, but I don't have a technical basis for that conclusion. I don't want you to buy any coin (and I'd never advise anyone to put money on cryptocurrencies unless they want to gamble). But I do believe it's worthwhile suggesting to people somewhat emphatically that they stay the heck away from BCN and tread carefully with some of the clones that just copy-pasted that code, as much as they should be careful with any alt that just copy-pastes the Bitcoin code and tweaks a few parameters. Most are at best worthless and at worst outright scams. The thing that adds potential value to a coin that's not actively used is its development, community (consider dogecoin as an example of the latter, and both BBR and XMR as examples of the former), and in some cases, its underlying technical innovations (cryptonote broadly speaking). And before you fling accusations, I'm quite sure I'm not a sock puppet: http://www.cs.cmu.edu/~dga/crypto/not_a_sock_puppet.htmlThat's enough for me. The right razor to use here is not Hanlon's it is Occam's (though perhaps Hanlon's too with the stupidity of the fraud), and all the lies are causing Good Ol' Occam to lose his voice with how loudly he's shouting fraud here. |
|
|
|
...
If you look at the analysis by Meni Rosenfeld and more recent work by others, the optimum appears the be the smallest time that gives close to zero orphans even in a decentralized network (not just a few pools with fast connections to each other). That's probably something like 5-10 minutes (10 minutes was close when Bitcoin was designed and latency seems to have roughly dropped by half since). This assumes not using modified protocols such as "GHOST" which address the orphaning issue but create or don't address enough other problems that they aren't generally viewed as a desirable upgrade, yet.
I am taking a look at the article. It does raise the question of where we expect network latency to go in the future, so a confirmation time that is sub optimal today could become optimal in the future. Some part of latency is just literally the speed of light and that will never be a point-to-point distance in a decentralized system. Consider one minute when you want orphans to be <1%. That only allows a few hundred ms for propagation. That's really not too likely to ever happen. Algorithmic improvements that address the issue in a different way are more likely to yield success with lower block times, likely coupled with other methods such as payment channels or cosigning for actual fast transactions (one minute isn't even close to fast enough for point-of-sale purposes). |
|
|
|
I really like Monero blocks being 1 min, I dont understand what it means negatively for mining but for the end user it means its fast! That being said I would not care if it was changed to a more "optimal" 2 or 3 min (with emission accordingly).
The perceived speed is just psychological since a 1 minute confirmation is worth half as much as a 2 minute confirmation for establishing consensus. The key is that the faster confirmation of 1 min allows for a finer grade of security in the confirmation of transactions. So with 1 minute block a merchant can choose between 0min 0 (confirmations) 1 min (1 confirmation 2 min (2 confirmations0 etc while with a two minute block the merchant only has the choice of 0min (0 confirmations) 2 min (1 confirmation equivalent to the previous 2 confirmations) etc. This can be critical for certain applications such as XMR.TO. The trade off is orphan blocks, which depends to a large degree on network speed and latency. If you look at the analysis by Meni Rosenfeld and more recent work by others, the optimum appears the be the smallest time that gives close to zero orphans even in a decentralized network (not just a few pools with fast connections to each other). That's probably something like 5-10 minutes (10 minutes was close when Bitcoin was designed and latency seems to have roughly dropped by half since). This assumes not using modified protocols such as "GHOST" which address the orphaning issue but create or don't address enough other problems that they aren't generally viewed as a desirable upgrade, yet. |
|
|
|
Yes. that's what it means, unless the block time target is changed higher or lower than one minute, in which case all rewards including that one will be scaled accordingly. That is the base reward, but there will still be penalties for having blocks that are >median so the actual reward may be lower (in fact this is one of several reasons it is necessary to have a maintenance reward).
I really like Monero blocks being 1 min, I dont understand what it means negatively for mining but for the end user it means its fast! That being said I would not care if it was changed to a more "optimal" 2 or 3 min (with emission accordingly). Well you'd like lower right? If the state of technology gets there, lower might be a feasible optimum. In the current structure it really isn't, just something thankful_for_today did against the objections of everyone. eizh: there are some ways that two one-minute confirmations are worth more than one two-minute confirmation, but it's not terrible significant when the overall hash rate is fairly low and especially once it is low enough for latancy to be significant. Discussed by Meni Rosenfeld here: https://bitcointalk.org/index.php?topic=260180.msg2781832#msg2781832 |
|
|
|
Sounds more like conspiracy theory to me. I'd say there's something more behind the Bytecoin story, and there are more things pointing to 2012 as a project launch year rather to the smooth's version of events. Personally, I believe that the project was created in 2012 in a rough minimum viable product, which simply did not take off. I tend to agree with Halon's razor in this case. Nope, already contradicted by statements made by Bytecoin supporters. Not going to explicitly point them out though (for now) I've said before that the more bullshit they spin up the more contradictions will be created, and that is true. They should really stop digging. |
|
|
|
When - what date or what blockheight - would the tail emission kick in ?
It is hard to know the exact date/block because it depends on penalties. Each block's reward is a function of the actual number of coins created so far. It will kick in whenever the reward according to the formula would be less than 0.3 XMR (approx 0.9% annually), which is expected some time around year 8. Why 0.9%? Edit: I guess what I'm asking is, what is the actual formula for the tail emission, the resultant inflation year over year and why was that amount chosen? The formula is "0.3" The amount was chosen based on being a round number within and close to the <1% inflation maintenance reward specified in the ANN OP. I found this on github+#define FINAL_SUBSIDY_PER_MINUTE ((uint64_t)300000000000) // 3 * pow(10, 11) Does this mean a constant block reward = 0.3XMR ? Yes. that's what it means, unless the block time target is changed higher or lower than one minute, in which case all rewards including that one will be scaled accordingly. That is the base reward, but there will still be penalties for having blocks that are >median so the actual reward may be lower (in fact this is one of several reasons it is necessary to have a maintenance reward). |
|
|
|
|
Show Posts
