I think it is Monero (XMR). The block time will increase and this will reduce the bloat of the block chain size. It also has good community support.
Wrong. It is adaptive blocksized. The bloat does not depend upon block time, but transaction count. Transaction size will even increase further when these two new features multisig and  (what's been the other? "CT"?) get included. Bloat depends a little on the block time because of headers and coinbase transactions, and the current 60 seconds adds a lot. The same observation has been made about Ethereum and even Ripple, though the latter is obviously very different technology. As for the new features, multisig will not increase transaction size, that is one of the advantages of Schnorr signatures. Ring CT is a bit of an open question. The signatures are larger, but you need fewer of them. It will probably net out slightly larger, but with better functionality. However, I don't think reduced bloat going forward is a enough of a reason to buy Monero. If you want to buy it, find more and better reasons. Just my opinion though. Do your own research. |
|
|
|
This fantastic image illustrates the feedback loops that lead to growth and success. It was originally created about Bitcoin but applies equally to Monero.
That's neat. It should also indicate higher price --> user adoption because higher prices allow each tx/block to perform more economic 'work' (ie transfer more information/value). Good point. It also, similarly, expands the potential user base to additional markets. Bitcoin at its present scale is completely uninteresting as a reserve currency, for example, even if the technology could handle that easily. It is entirely a function of price. I'm thinking about spending some time to rework the diagram a bit. I'll include that. |
|
|
|
Why do you think that they are wrong? What is your proposal?
They're wrong in so far as they both propose that one particular subset of the system has ultimate control over it (miners in the case of the first post and users in the case of the second). They all have varying degrees of influence; none has unilateral control. (Also "miners" and "users" are not really decision making entities which is another problem with both arguments -- fallacy of composition/division.) As far as my proposal, it doesn't really matter because they won't listen to me but I favor a hard fork to 2 MB followed by a slow automatic increase of maybe 10% per year for say 10-20 years. Slow enough that if it looks to be running out beyond hardware improvements it can be rolled back with 1-2 year lead time for another fork. Ultimately, though, it is up to the various interest groups to work it out or fight it out, because it won't work unless all are somehow on board. Messy and ugly but it is delusional and wishful thinking to think you can remove politics from this process. |
|
|
|
|
If MoneroHouse donations count (and I don't see why not), then 'pa' should get credit for 10 000 XMR worth.
|
|
|
|
Smooth QC (Brewery) report, dividend
As anticipated, conditions in the BEER market have continued to weaken with nearly half of last week's production remaining unsold and the remainder sold at around 4000, yielding 30% less profit than in previous weeks. The dividend is reduced to 10000 per share and has now been paid. Outlook remains negative. |
|
|
|
Regarding the quote. I'm not cryptographer, but Andersen said that this quote does not really make sense from the cryptographic point of view, and rather proves that Satoshi was not a cryptographer and had only high level knowledge of cryptography. Real cryptographers would never say something like this Source: https://www.youtube.com/watch?v=rQ3e1Pzu7iI&feature=youtu.be&t=748So not sure if this is really a quote that Monero want to use this quote from Satoshi, as apparently it has no sense. Indeed, to Gavin credit he doesn't say this quote does not make sense, but that this is the 101 of crypto. My understanding is that Gavin refers to the vague "informal" formulation in the quote, not to the meaning of it. The conclusion of Gavin just based on this poor formulation is really stretched though. The quote was actually a forum post so of course it's not formulated as a science paper. That makes sense. Also satoshi seemed somewhat unfamiliar with ring signatures but I've heard cryptographers say that they would be well known to most cryptographers. So that also suggests he was not a cryptographer, at least not a full time one. It is also widely speculated that 'satoshi' may be more than one person, in which case the person writing that one forum post might not be a cryptographer but some other member of the 'satoshi group' might be. |
|
|
|
There is also this quote from Satoshi, which touches on the importance of ring signatures that are used in Monero (and other CryptoNote currencies). Monero is the next generation of evolution in digital currency: private decentralized electronic cash. Crypto may offer a way to do "key blinding". I did some research and it was obscure, but there may be something there. "group signatures" may be related.
...
As an example, say some unpopular military attack has to be ordered, but nobody wants to go down in history as the one who ordered it. If 10 leaders have private keys, one of them could sign the order and you wouldn't know who did it.
Regarding the quote. I'm not cryptographer, but Andersen said that this quote does not really make sense from the cryptographic point of view, and rather proves that Satoshi was not a cryptographer and had only high level knowledge of cryptography. Real cryptographers would never say something like this Source: https://www.youtube.com/watch?v=rQ3e1Pzu7iI&feature=youtu.be&t=748So not sure if this is really a quote that Monero want to use this quote from Satoshi, as apparently it has no sense. Gavin is wrong. The quote makes perfect sense and Monero proves it by having implemented it (Cryptonote actually implemented it of course). Maybe what this shows is that Gavin is not a cryptographer (something I think he would agree with). |
|
|
|
However you can produce secure brain wallets with for instance a mechanism involving a large number of different hashing functions.
I doubt it. If enough people start doing that, password brute forcers will do it too, the same way they use combinations of words, phrases, common transformations, etc. All you are doing with these sorts of combinations is adding a relatively small number of entropy bits for the various ways that hash functions can be combined. Key stretching does work but that relies on the hash function being slow, which is somewhat fragile long term. |
|
|
|
There will also be no long term dilution because of the extremely slow and tapering supply expansion. I guess it depends what you mean by dilution. When one's share of a business is diluted by new investment, it means the percentage of ownership decreases, but it doesn't necessarily mean the value of your investment is smaller. The value may increase, decrease, or remain the same. It is pretty useful to be very precise about whether one is talking about money supply in nominal units or value of individual units (or something else). The confusion also comes up when people discuss "inflationary" or "deflationary" currencies and end up talking past each other because they are using different meanings. My comment about long-term dilution was referring to money supply units. if the average cryptouser starts caring about this minutia This seems like a questionable premise. Almost everyone agrees that for crypto to become more successful, the user base needs to grow dramatically, which probably means the average crypto user will have significantly less interest in monetary policy and such. |
|
|
|
A "strong" password helps a bit but most of the security comes from the coin ID itself.
If you want to be reasonably paranoid, you must assume that between production and shipping, the coin ID is compromised. I'd personally make sure the entropy of my password is fine by itself. If you're going to do that, you might as well just use a paper wallet (which I personally recommend). There is no way you will ever have a strong password that doesn't need to be written down. Brain wallets don't work. |
|
|
|
Once I lost (luckily small amount of) Bitcoin from address generated by some paperwallet site using 'brain wallet' shit option - custom phrase entered. So, in seconds after change from transaction went to that address it was withdrawn bo some clever bastard owner of 1LdUHTEVxWJhrhKfy4H3VuYDnTHQVjsdBn.
Therefore my question: is it safe to use custom entropy?
Given the stated use case above it should be safe, assuming you trust the manufacturer of the coin and the coin itself has been kept secure from disclosure of the coin ID. A "strong" password helps a bit but most of the security comes from the coin ID itself. Although....I'd suggest using slow hash for key stretching as the simplewallet password does. That all but precludes any useful brute forcing of passwords. I thought that was in the standard for physical coin keys, but maybe not. |
|
|
|
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.
BU does not always follow the longest chain. In general BU operates in the same way as in Core, BU nodes follow the longest valid chain. There is a slight difference with respect to the blocksize issue. It is possible BU nodes will follow the longest chain, where the blocksizes are arbitrarily large, but only under certain limited unusual conditions. There is an “N depth” idea in BU, where nodes switch from regarding one chain as valid to another chain, if the chain with larger blocks has a lead of N blocks. The default value of N is 4 and N could be manually set to any number, including infinity, when BU nodes will never switch to the longest chain. Only if N is manually changed to 1, does BU follow the longest chain with respect to any blocksize. Therefore the claim that BU always follows the longest chain is false. It is not false with respect to any setting other than infinity (but your point is valid since infinity is a apparently a valid setting). There is never a guarantee that any Bitcoin node will converge to the longest chain in finite time, only eventually. The exact same guarantee applies to BU, though it may take longer to agree on a chain than other implementations. |
|
|
|
And unfortunately, monero is not a store of value, it is transactional. Unless you think a perpetual emission magically prevents dilution. In 114 years there will be 36 million monero. And in 228 years there will be 54 million.
There will be no long term dilution because of lost coins. Eventually some equilibrium will be reached, probably around 35 million coins. Anyway, store of value doesn't mean a perfect store of value with no fluctuations or erosions in value whatsoever, and for Monero to function as any sort of store of value at all in a significant sense, or even to function transactionally, the value will need to increase a lot. 5 million USD market cap (or even 15 million if you project out to my estimate of long term supply) isn't going to cut it. The incentives for investing are there, as well as the risk that it doesn't function, interest is lost, and goes to zero. |
|
|
|
This fantastic image illustrates the feedback loops that lead to growth and success. It was originally created about Bitcoin but applies equally to Monero. One way it has been misinterpreted is giving the orientation some sort of significance (e.g. that "Hoarders" on the top the most important or fundamental). In reality the image could be arbitrarily rotated or otherwise transformed and still be correct, so none of the individual nodes are the "source" of growth (or favored point of reference in any way); they all are. It could probably be improved by adding development feedback loops, and maybe being a bit more explicit about speculation. EDIT: Interesting the hand-drawn original linked below did include dev support.  Credits: Image from here: http://themisescircle.org/blog/2013/02/19/end-the-fed-hoard-bitcoins/based on: |
|
|
|
Someone dumped 15 btc, then 3BTC, then 5BTC. Quite a strange move
Could be a group of people. They bough before the 0.9 release, waited a bit till price increase after the release, and they are dumping now. Pretty expected. Now that the release is out and just about everyone is aware of it, the immediate pump is over. Some short term traders are certainly going to bail out. Longer term we will see how the improved maturity and functionality of the software (and of course looking forward to next steps) can attract more demand to absorb the supply. That's the only way we can maintain higher prices going forward. |
|
|
|
It doesn't matter, except that nodes with a too-small limit will frequently have the latest blocks "on probation" waiting for them to reach an acceptance depth. A node which sees a block which is excessive (over its limit) will not relay or process it until it is buried under enough confirmations. BU nodes always track the chain tip with the most PoW.
So it sounds like you are using non-relaying by end user nodes as a form of soft pressure to discourage miners from creating blocks larger than node limits. How do you deal with the fact that miners will often want to have direct connections with other miners (due to the natural incentive to reduce "orphans"), making relay through end user nodes irrelevant? Setting aside the previous, have you done simulations or mathematical models to characterize how relaying will behave in practice given some distribution of nodes putting a block "on probation" while other nodes process and relay it? Can you characterize the cost of creating nodes that deliberately relay larger blocks than most of the end user nodes in an attempt to influence the orphan pressure on miners? Without doing any simulations or models, it intuitively seems to me that even a small number of such permissive nodes (either malicious or otherwise) can quickly relay blocks to nearly the entire portion of the network willing to process them, though operators of such nodes will incur bandwidth costs. A miner producing a block larger than emergent network consensus gets its block orphaned. Only if the block does not reach other miners. |
|
|
|
inserted by developers who excellent at what they do have no track record as incentive designers, economic parameter setters, etc. They do in fact have a track record. Various economic- and incentive-related decisions have been made in Bitcoin development over the past 6 years and it hasn't completely blown up yet. That includes both changes and decisions about what not to change. I guess this conclusion depends in part on how big a failure you think the "blocksize debate" represents. From where I sit, the blockchain is still working, transactions are being processed, etc. I don't see a major failure even in that. |
|
|
|
"We would be trying to predict what the market would decide, "
@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. Well that's how it is anyway, and even now the market does decide. My point is that there's market friction in the inconvenience barrier of users not being able to set the blocksize cap themselves. That gives artificial solidity to the Schelling point set by Core (as well as the one set by XT). If Core is doing the correct thing, it shouldn't mind putting it to the market test more fully, by taking its finger off the scale. How much is Core's finger really on the scale here? Well, for example, how many reasons are there to mistrust Mike Hearn? Some would say a lot. That means, as things stand now, even if you want BIP101, you can't really have it if you have a problem with Mike, because XT isn't an option for you. And because other people feel that way, you're further limited. The way Core (and XT) does it now makes it a power struggle, a popularity contest, and a package deal. Maybe Core could stall for a long time before people would finally give up and go with Mike. That's a lot of friction in the market. And small block adherents, imagine the reverse, if it were Mike and Gavin were running Core and Pieter, Wlad, and Maxwell had broken off and started their own implementation, with maybe Jeff going between. And people were sticking with Core and its giant block plan, heading for catastrophe. You might notice the market friction then. BU eliminates the power struggle by unbundling the setting of consensus parameters from the rest of the Code. It also of course makes for a lot more choices. If 1MB is too small and 8MB too big, what recourse is there? Roll your own and try to popularize it? Very hard. But propose 4MB and try to get people to agree? More doable. Or what if, like some Chinese miners were saying, 8MB is fine but the scaling to 8GB is ridiculous. What do you do? You have two options, and they are bundled up tightly with all the other aspects of the code and why you choose Core or XT. That's again a lot of market friction. I'm not disagreeing with you necessarily about a users setting the parameters on their own nodes, but I don't see how this market mechanism works, nor do I see how you have "eliminated" a power struggle. People will still struggle to influence the miners and users over what block size is being used. Developers will be under influence (internal and external) over what defaults to set (or are you going to remove defaults altogether and require end users to choose every possible parameter?). Whatever the merits of the idea, I don't see how you have made these decisions into significantly more of a market process. As we have agreed, users could always modify the code or choose what code to use, so the market already existed. The politics will certainly still exist, and perhaps become even more intense (and potentially, expensive, which brings its own issues) with respect to trying to convince users and miners (and possibly developers, as to defaults). Remove the hard code size limit? Okay, sure, maybe a good idea, maybe not. But beyond that you seem to be overselling the idea by a wide margin. |
|
|
|
|
Show Posts
