I'm trying to work out a way to run a Monero node on a portable device.
That's certainly a viable option, and indeed it removes the dependency on a fixed node altogether. The hardware you mentioned seems like it should handle it. 64 GB of storage should be enough for the blockchain for a good long time. Of course it requires working out the details but it should be doable. |
|
|
|
I think you forgot Bitshares is deterministic block production, so it would have some pretty big difficulties incorporating mining for transaction fees. Especially when the only coin anyone currently uses for economic activity to cause transaction fees to exist is Bitcoin.
When you said "mining for block reward" I thought you had already assumed dumping Bitshares' closed-system validation. My point was that you need mining, but not necessarily (subsidy/inflationary) rewards. Fair point that economically-significant transaction fees are almost nonexistent, which basically agrees with what I said in the second paragraph above. |
|
|
|
I get the distinct impression that, besides me, few to none of the participants here are constant travelers.
I don't have the option of setting up a node. I don't know where I'll be next week. Even carrying a laptop around is a burden; I use mobile devices almost exclusively.
There are literally billions of people around the world who can't set up Monero nodes, but they have computing power in the form of smartphones. For most of them, it's not because of an itinerant lifestyle, but what does the reason matter?
If you can't set up a node, you can't set up a node.
People who can't realistically be expected to run a Monero node outnumber the likes of you people by an order of magnitude.
Isn't that exactly what Mininero is supposed to address? Anything that fully preserves the unlinkability and untraceability of Monero is fine with me. If MiniNero accomplished that, then it wouldn't be necessary to run a full node. Still, one has to find a trusted node to connect to, yes? You either have to run your own node, or trust someone else's? I think the idea is run your own node on a free VPS or a small low-power device or something, while making it easy and automatic to do so. I don't know the details, but I guess more will be filled in later when it is less of a work in progress. |
|
|
|
I get the distinct impression that, besides me, few to none of the participants here are constant travelers.
I don't have the option of setting up a node. I don't know where I'll be next week. Even carrying a laptop around is a burden; I use mobile devices almost exclusively.
There are literally billions of people around the world who can't set up Monero nodes, but they have computing power in the form of smartphones. For most of them, it's not because of an itinerant lifestyle, but what does the reason matter?
If you can't set up a node, you can't set up a node.
People who can't realistically be expected to run a Monero node outnumber the likes of you people by an order of magnitude.
Isn't that exactly what Mininero is supposed to address? |
|
|
|
While an interesting option a webmaster can always host affiliate banners him or her self and Adblockers can do nothing about it. Adsense and other networks can be blocked but self hosted banners cannot.
Doubtful. Task-specific AI has reached the point where I'd guess you could block ad banners of any source with >95% accuracy rate. If they are a standard size, which the nature of ad networks and mass distribution more or less requires, then it would easily approach 100% |
|
|
|
More deceptive and misleading statements about the instamine that Dash continues to use to scam investors even now, this time an in "Official Communication". https://dashpay.atlassian.net/wiki/display/OC/Dash+Instamine+Issue+ClarificationRepeats many of the unsupportable or false claims mentioned in the OP from the old Darkcoin FAQ such as coins being redistributed, the nature of the distribution, and where and how large holders obtained their coins. Omits critical information about key events surrounding the instamine such as the early launch and the deliberate withholding of development plans until after the instamine was complete. Also mischaracterizes the origin of the instamine coins as being the Litecoin difficulty adjustment algorithm which is absolutely false. Most of the "extra coins" came from the absurdly-high block rewards due to a "bug" (500 coins/block IIRC, roughly 285 times higher than now). If Dash had constant block rewards as did Litecoin (for four years), its instamine would have been very small, as Litecoin's was (in fact even smaller, since the Dash had a difficulty adjustments at 4x the frequency of Litecoin). |
|
|
|
Mining with a block reward is definitely required (either with transaction fees as block reward, perma inflation, or both). If you don't know why, read my thread: IOTA - Permissioned ledger Russian extortion schemehttps://bitcointalk.org/index.php?topic=1414866.0If you think a blockchain can work at all without a block reward then you probably don't need one for permissioned mining. A miner can enter the system by mining for tx fees, which must be paid by existing participants in order to transact. This does have the unfortunately (failure) equilibrium you pointed out in a slightly different context, where no one transacts but everyone just hodls at some high fantasy price and pretends they are rich. |
|
|
|
If the price is guaranteed to rise significantly after the halving, why aren't you buying as many coins as you can now How do you know he's not? Why wouldn't the smart money buy up all the cheap coins now, up to the post-halving price, and therefore pricing in the halving jump in advance? The answer would be there is not enough 'smart' money playing in this market, relative to the amount of 'dumb' money that incorrectly doubts r0ach's theory. I don't really agree with this, but the argument can be made. |
|
|
|
Hiho!
It seems my simplewallet got corrupted I'm getting "Error: Blockchain can't be saved: possible lost connection to daemon" can anyone help me here? it is much appreciated!!!
Not being able to save sounds like low disk space or something like that. |
|
|
|
Floating point is quite adequate for financial computations -- if the programmer understands how it works.
According to the IEEE floating-point standard, that is used by all major makers since the 1980s, a double-precision float can represent all integers up to 2^53 exactly, with no rounding. It turns out that 21 million BTC is just below 2^51 satoshis. That means it is safe to store BTC amounts as doubles, and even do simple math on them, if one stores them internally as satoshi amounts, rather than fractional BTC amounts.
(The only theory I know for why Satoshi limited the max issuance to 21 million BTC is that he knew this fact, and was aware that Excel, Awk, Python, Matlab, and many other languages and formats used IEEE doubles for all numbers, integer or real. Een though he did not use floating point in the bitcoin protocol, he must have felt necessary to accommodate those languages.)
Based on the above, should there be any attack vectors or exploit for altcoins like dogecoin, which went beyond 2^53, issuing in the hundreds of millions or billions? (Litecoin should be slightly below 2^53). If they are just cloning code that wasn't meant for their use case, perhaps vulnerabilities exist or arise at some point (?). Doge isn't actually referencing total coint count anywhere though, so it doesn't matter. All Doge does is say, this block we will unload a dump truck of Doges of whatever size on your doorstep, then the algorithm will gradually decrease the size of the dump truck until reaching a minimum of 10,000. Maybe if a single block reward exceeded 2^53 you might run into some issues, but no coins do that. The Bitcoin coin count is modeled more around value of 1 satoshi should it become a world reserve currency than other issues like this that can be side stepped. There is no issue with 2^53 inside the coin code itself, which never uses floating point. The issue would only be with quantities handled externally. DOGE is still divisible to 8 decimal places, so 2^53 is only around 90 million DOGE; not very much. |
|
|
|
Floating point is quite adequate for financial computations -- if the programmer understands how it works.
According to the IEEE floating-point standard, that is used by all major makers since the 1980s, a double-precision float can represent all integers up to 2^53 exactly, with no rounding. It turns out that 21 million BTC is just below 2^51 satoshis. That means it is safe to store BTC amounts as doubles, and even do simple math on them, if one stores them internally as satoshi amounts, rather than fractional BTC amounts.
(The only theory I know for why Satoshi limited the max issuance to 21 million BTC is that he knew this fact, and was aware that Excel, Awk, Python, Matlab, and many other languages and formats used IEEE doubles for all numbers, integer or real. Een though he did not use floating point in the bitcoin protocol, he must have felt necessary to accommodate those languages.)
Based on the above, should there be any attack vectors or exploit for altcoins like dogecoin, which went beyond 2^53, issuing in the hundreds of millions or billions? (Litecoin should be slightly below 2^53). If they are just cloning code that wasn't meant for their use case, perhaps vulnerabilities exist or arise at some point (?). The issue is not with the coin itself but with external systems that process coin amounts. Yes that can be an issue with those other coins, if those external systems use floating point, which as I already explained it is a bad idea (and jstolfi added the condition that the programmer also doesn't understand how floating point works, which I would note is unfortunately extremely common). In theory even 64 bit integers can overflow too though. COBOL used packed decimal, meaning storing one digit in each half of a byte, and arbitrary precision by using sufficient bytes to store values of the necessary range (defined by the programmer). This is slightly inefficient but avoids all hidden overflow and rounding issues. Today programmers are often lazy and use whatever numeric types happen to be convenient be it floating point, 64 bit ints, etc. In some better written code occasionally you do see bigints/bigdecimal or even numbers stored as strings but that is rare. |
|
|
|
I do think companies like poloniex are at risk of this sort of crackdown. It is what prompted me to move all my XMR out of them last year when the rumors of a crackdown started.
Blessing in disguise. Another good reason (if one is needed) to get your coins off the exchange and store them securely in your own wallet. |
|
|
|
so... why monero dev seem so obsessed with law and regulation  what would happen if law and regulation forbid anonitmity Which monero dev do you think is obsessed with law and regulation? If you are referring to the starter of this thread, he's not a monero dev at all. If you mean me, I've made a few (I think 3-4) comments here but I'd hardly call that obsessed. Some awareness of law and regulation is absolutely necessary to understanding the world whether you agree with them or not, as they do exist and affect how people behave. |
|
|
|
Indeed floating point should almost never be used in financial transactions (unfortunately the programming error of doing so is made often).
Floating point is quite adequate for financial computations -- if the programmer understands how it works. According to the IEEE floating-point standard, that is used by all major makers since the 1980s, a double-precision float can represent all integers up to 2^53 exactly, with no rounding. It turns out that 21 million BTC is just below 2^51 satoshis. That means it is safe to store BTC amounts as doubles, and even do simple math on them, if one stores them internally as satoshi amounts, rather than fractional BTC amounts. (The only theory I know for why Satoshi limited the max issuance to 21 million BTC is that he knew this fact, and was aware that Excel, Awk, Python, Matlab, and many other languages and formats used IEEE doubles for all numbers, integer or real. Een though he did not use floating point in the bitcoin protocol, he must have felt necessary to accommodate those languages.) In the 1990s, smart programmers used floating-point to do integer computations, because the FPU multiplication and division units in typical CPU chips were much faster than the corresponding integer units. (I don't know whether this is still true today.) The infamous Pentium Divide Bug was discovered by a mathematician who used that trick in his investigation of some number theory conjecture. A floating point number is actually just two integers packed together into a single data element. That can still be done when needed on top of integers.
Yes in theory, but the full IEEE floating-point representation is quite complicated. Simulating it in software is no easy task. Fortunately, one does not need to understand any of that complexity when storing integers up to 2^53 or so. If you are just going to store integers (such as satoshis or cents), there is no point (with modern CPUs with fast 64 bit integer operations). If you store fractional currency amounts such as cents then you will run into all the various pitfalls that make using floating point for currency a bad idea. Also, Python does not use floating point for all numbers. Maybe some very old version did, but since 2.x it has 64 bit ints and that is 15 years old. |
|
|
|
I've read some of the suggestions in that link but it doesn't make sense to me how it can replace a lot of use cases (except, as I have suspected, that catastrophic failures can occur by the use of fp). Granted I'm not a programmer, I'm currently asking for ...lessons here  Let's say I lend someone 0.15$ and have 0.3% daily interest. Ok, let's pretend dollars aren't dollars, but they are cents (thus 15 = integer). Even if the interest was a floating point setting (I guess there is an equivalent mechanism to make decimal stuff like interest into integers - after all the cpus do that stuff all day long at the binary level), and we did the math, then 15 cents + 0.3% = still 15 cents at the end of the day. And in the end of the next day. And the end of the next day as well. So I've lent my 15 cents into a money lending platform, and instead of getting compound interest, I'm stuck at 15-15-15-15 every day... So, after a year I should have 44.7 cents (tripling my money) but now I have just 15 cents - so I'm robbed. It seems this is pretty bad and very close to a rounding error that is always against me - kind of. If you are running a lending platform that calculates daily interest and deals with loan amounts in cents, then you can easily make your minimum unit be thousands of cents or smaller. Some of the bitcoin exchanges, for example, use sub-satoshi units (< 10 -8) internally and only convert to satoshis for external transfers. |
|
|
|
Hash rate is also somewhat useless due to its fluctuating nature. While the fluctuation is lower for bigger coins, it can swing very wildly for smaller to medium coins.
And because of multipools the hashrate follows the current price very closely so if there's a price increase the hashrate follows.
So if we were to use hashrate as a metric similar to marketcap then a spike in hashrate/price would push the price/hashrate even higher becaue of newbies making irrational investments based on hashrate.
I agree that a single point-in-time snapshot may not be representative. If my suggestion from a few posts back of creating a graph were adopted then this variability would be visible. |
|
|
|
I found it extremely hard to believe that floating point can't be supported. Floating point is required in a lot of financial transactions.
Fixed (decimal) point suffices in most cases, which is easily represented with integers. Indeed floating point should almost never be used in financial transactions (unfortunately the programming error of doing so is made often). https://www.quora.com/What-is-the-best-way-to-handle-floating-point-problems-with-financial-calculations-in-JavaScriptHe also didn't say that floating point can't be supported only that it isn't supported natively. A floating point number is actually just two integers packed together into a single data element. That can still be done when needed on top of integers. |
|
|
|
I thus suggest an idea for a new metric for ranking altcoins.
Sqrt(M x H)
M = Mean transactions fees paid per unit time to decentralized proof-of-work miners
H = hash rate (normalized in electricity cost per hash to SHA256).
Using M = Sent avg. per hour, H = Hashrate (normalized): | 1.Bitcoin | 6.5×10¹² | | 2.Namecoin | 8.6x10¹⁰ | | 3.Ethereum | 6.6x10¹⁰ | | 4.Litecoin | 1.3x10¹⁰ | | 5.Dash | 9.8x10⁹ | | 6.Blackcoin | 7.4x10⁸ | | 7.Dogecoin | 6.1x10⁸ | | 8.Auroracoin | 5.8x10⁶ | | |
One of the reasons that Bitcoin is 100X higher than the altcoins is because its "Sent avg. per hour" is so much higher than its Volume(24h)/24, which indicates that Bitcoin has a much higher level of transactions that aren't occurring on known exchanges that report volume. In other words, Bitcoin has more real adoption for use cases other than speculative trading, which is one of the attributes I wanted to capture with my proposed metric. What this seems to indicate is that altcoins are nothing compared to Bitcoin, which is what I expected but a 100X greater wow. Unfortunately I couldn't find the "Sent avg. per hour" data for the others altcoins. Note I am using transaction value as a proxy for transaction fees paid, which isn't entirely accurate. I believe for example that Monero has higher transactions fees to mitigate spam which could be used to reduce anonymity sets. It isn't accurate at all because with very low fees you can definitely have spam but you can also have transactions that are spewed as manipulation to make the coin seem used. (Even high fees would be irrelevant if the insiders also control the mining, but this wouldn't generally correlate with a high hash rate.) Bytecoin is a good example of this. It has tiny fees and junk transactions generated by some automated process 24x7. But then, a lot of exchange volume (especially in China) is also documented to be fake, so it very hard to make these comparisons meaningful. On this in particular: In other words, Bitcoin has more real adoption for use cases other than speculative trading Certainly true, but as far as magnitude, the data must be interpreted with caution. A huge portion of Bitcoin blockchain transactions are tied (by various published blockchain analysis) in some way to mining or trading (moving coins between exchanges for example). Mining is larger in size (and therefore mining-related txs are also larger in aggregate) simply because Bitcoin has higher value, so you are measuring a proxy for market cap in some ways here. Bitcoin also has various spam attacks over the past year or so that seem to be a outgrowth of the blocksize politics. Anyway, interesting chart here, but as always inputs are not so trustworthy. https://blockchain.info/charts/tx-trade-ratio |
|
|
|
Also increased hashrate implies increased security against a 50% attack, assuming the hashrate is well distributed.
That's a pretty big assumption. I like to say that network hash rate specifies the maximum possible level of security, but as the hash rate becomes more concentrated the actual level declines from the maximum. I haven't thought through your valuation metric itself. It is somewhat a tradition on this forum (especially in the Bitcoin section) that people make up their own metrics and post the results, generally in the form of graphs. Sometimes these are viewed as useful and are followed for years, sometimes they fall flat and are quickly forgotten. You might want to try that. |
|
|
|
|
tromp's reply didn't really answer the question. Basic floating point operations are supposed to be deterministic anyway. The question was whether a hardware bug causing incorrect/different results (in operations that are used in Ethereum) could fork the network and the answer is yes.
Of course this could happen in another coin too. A hardware bug, in theory, could cause a valid signature to appear invalid on some hardware and therefore cause the majority chain to appear invalid, which would then result in a persistent fork.
|
|
|
|
|
Show Posts
