I actually don't think there's anything wrong with SPV or the current state of the ecosystem (minus some centralization concerns, but that's for another time)! How many transactions could the current ecosystem handle if we utilized every blockchain at once. This is going to be much easier to explain if we start using daily throughput instead of MB per block, which is a terrible metric.
I'm sort of agnostic on this but the standard argument against is that it loses on network effect both protocol-wise and in terms of unit of account. If you are a Bitcoin user and you want to pay a Litecoin user that means doing an exchange, which adds many kinds of overhead. This puts this sort of heterogenous solution at a competitive disadvantage to a single network that is able to service both customers. Likewise if you slice the other way and say that every user is both a Bitcoin and Litecoin user (meaning you can just choose any chain to transact), again that adds (slightly different) overhead. Certainly if you have infinite chains you can have infinite total capacity but that also creates infinite overhead. As for "Digital Gold", he didn't coin the phrase, but he set the expectation that it works like gold: "The steady addition of a constant of amount of new coins is analogous to gold miners expending resources to add gold to circulation" Cherry picking his quotes is not really helpful. He also said: The bandwidth might not be as prohibitive as you think. A typical transaction would be about 400 bytes (ECC is nicely compact). Each transaction has to be broadcast twice, so lets say 1KB per transaction. Visa processed 37 billion transactions in FY2008, or an average of 100 million transactions per day. That many transactions would take 100GB of bandwidth, or the size of 12 DVD or 2 HD quality movies, or about $18 worth of bandwidth at current prices.
If the network were to get that big, it would take several years, and by then, sending 2 HD movies over the Internet would probably not seem like a big deal.
and (pre-SPV) The current system where every user is a network node is not the intended configuration for large scale. That would be like every Usenet user runs their own NNTP server. The design supports letting users just be users. The more burden it is to run a node, the fewer nodes there will be. Those few nodes will be big server farms. The rest will be client nodes that only do transactions and don't generate. and I anticipate there will never be more than 100K nodes, probably less. It will reach an equilibrium where it's not worth it for more nodes to join in. The rest will be lightweight clients, which could be millions. and Forgot to add the good part about micropayments. While I don't think Bitcoin is practical for smaller micropayments right now, it will eventually be as storage and bandwidth costs continue to fall. If Bitcoin catches on on a big scale, it may already be the case by that time. Another way they can become more practical is if I implement client-only mode and the number of network nodes consolidates into a smaller number of professional server farms. Whatever size micropayments you need will eventually be practical. I think in 5 or 10 years, the bandwidth and storage will seem trivial. all of which, among others, make it clear he expected Bitcoin to scale and be used for many routine transactions, including increasingly-small micropayments, by millions of users, not just settlements between gold vaults. He may have been wrong, but that was his expectation. |
|
|
|
|
Pretty much agree with Johnny Mnemonic although we can't prove it was a bullshit justification. I'm pretty sure the justification was only give after getting pushback from the community though.
It is certainly true that fast block times were all the rage, and many of the clone shitcoins were being launched with 30 second or one minute block times.
|
|
|
|
I didnt understand the answer of why a 5 or 6 minute block would be bad, other than a very small increase in orphan rate and delaying any txfee auction market for a while The answer was that the asymmetry is such that making the time too short (given network parameters, which are not really measurable and not stable) is much, much worse than making it too long. I continue to assert that reducing the time should not be confused with increasing capacity. A block time reduction by a factor of two, all else being equal, would also be accompanied by a reduction in the block size by a factor of two. Looking at the data, it seems the negatives of 5 minute block are pretty small and that would give 2MB of blockspace per 10 minutes. So if we assume the error rate difference between 5 and 10 minutes is small enough to being considered equal enough, then having 2 1MB blocks in a 10 minute period sure seems like double the tx capacity per 10 minutes. Not sure why the blocksize is reduced at half the time, that would defeat the purpose. given the assumption that 5 and 10 minutes are equal enough, then why would the blocksize need to be cut in half? We can also assume that 1MB per 5 minutes is not any problem for the nodes' bandwidth and wouldnt increase the error rates appreciably. What error rate at 5 minutes requires cutting the size in half. If there is no need to cut the size in half, then how is it not a doubling in capacity? Confused... James To answer your last question, if you increase the capacity then you are doubling the bandwidth and storage requirements. If you want to do that, and you have buy-in to do that from the relevant stakeholders, then you might as well just increase the block size. What you are are ignoring in "the data" is this: The scaling of this depends on factors like network hashpower distribution and latencies which are hard to measure and which change. Since 5 minutes is "reasonably close" to the inflection point on the graph where being too low becomes much worse and being too high becomes only slightly worse, it seems quite reasonable in light of the above quote to err on the side of (possibly) too high and just implement a 2x capacity increase with an increase in block size rather than a reduction in block time. In all honesty, and lacking in hard data, I do believe that 5 minutes would be fine, but what's the point? Going well below 5 minutes would most likely not be fine, so that limits any available capacity increase via that method to roughly 2x. Increasing the block size has no such limit. |
|
|
|
Alternatively, hit the ask a little every day for a month or two.
That's exactly how I got my minnow-sized holding of Aeon, now 10'000 worth. The advantage of doing it this way is that it inclines you to think longer-term about the price; it induces you to be patient. Formalized, this way is known as " dollar-cost averaging" and it does work. Sometimes you buy high, sometimes you buy low, but in the end you tend to get a better average price than the average punter. Good approach. I'd add that another good way to build a minnow-sized holding (and support and improve the strength of the network) is through patient mining. I've built this up entirely though solo mining, mostly full time on one small (fanless) computer, plus part time on a few other ones: Refresh done, blocks received: 632 balance: 16801.72 ********************************************************************** Use "help" command to see the list of available commands. ********************************************************************** Over 16000 Aeon from solo mining is a pretty nice reward for helping to keep the network decentralized. I don't want to give a false impression: That's over the course of a year or more almost a year. I don't exactly remember when I started, and like I said sometimes i've thrown some other computers on it, so it isn't entirely from one computer, but most of it is. (EDIT: Just checked -- first block in May 2015.) Maybe I should start mining Yes! |
|
|
|
And maybe they learn that Bitcoin is a pain in the ass, is unreliable and complicated, and go elsewhere.
I'm not saying that the system has failed or that it will definitely fail. I'm saying that it is starting to fail right now, because there is a mismatch between the infrastructure and user-education requirements of the system and its ability to function effectively. That is absolutely the case. At best it is poor planning and deployment.
Bitcoin needs to just accept it can't grow fast enough to do everything for everyone in the entire ecosystem. Satoshi said it was suppose to be a type of Digital Gold, maybe we need to go back to that way of thinking. That's a great accomplishment... but, when you have gold, you don't move it around all of the time. Why can't Bitcoin handle the larger value transactions in the space and all of the alts can handle the smaller day-to-day transactions. The ecosystem is already setup to scale to infinity. Everyone wins. It could, but it is currently out of step with that vision. SPV wallets were built up (in part by Satoshi, by the way) as a way to make the system easily accessible to people making routine transactions including buying coffee and using vending machines (plus many others of course). So you have have many end users doing exactly that, having adopted Bitcoin as a transactional medium, not something limited to high powered bankers and cryptocurrency experts. Perhaps that was a bad idea, but it's too late to erase that from history. That worked just fine until very recently, and now you still have those users trying to transact but without the tools to do so effectively. Even if one fully buys in to your Evolution concept (as one example of several), and believes that Evolution is the way that the ecosystem will scale to infinity, Evolution isn't here. Even Bitcoin wallets with the ability to effectively set fees and increase fees if needed after the fact don't exist in any widely-deployed form. So the whole thing is quite a mess right now. In the future I have no doubt it will get better, but where we are today is not pretty. Either an earlier and more effective push should have been made to get the tools out there faster to manage block space scarcity and shift transactions off the Bitcoin main chain, or there should have been some sort of block size increase to buy the time that is needed. Having done neither is an objectively poor outcome, and therefore one must fairly rate the process of having reached this outcome as ineffective. EDIT: BTW, Satoshi never said that Bitcoin was supposed to be digital gold (that description was invented later by others). His only mention of gold in the white paper related to the steady release of new coins, and in an email he compared Bitcoin to "base metal as scarce as gold" that could be sent over the internet. It is very clear he intended it to be for end-user payments. Opinions differ over whether that vision has turned out to be impractical or Bitcoin has been hijacked by people who want to develop it in a different direction. |
|
|
|
My worry is that if this model actually does succeed wildly, it establishes precedent for a thousand scammy IPO 'dapp' currencies popping up (as we already see) and bilking people of money. It also will hurt the reputation of crypto as a whole.
 I agree of course. This is inevitable (and already happening). Best advice is to ignore the noise unless you are very good at short-term trading against the mob and stick with the fundamentally strong assets. Over time they will do better. |
|
|
|
Alternatively, hit the ask a little every day for a month or two.
That's exactly how I got my minnow-sized holding of Aeon, now 10'000 worth. The advantage of doing it this way is that it inclines you to think longer-term about the price; it induces you to be patient. Formalized, this way is known as " dollar-cost averaging" and it does work. Sometimes you buy high, sometimes you buy low, but in the end you tend to get a better average price than the average punter. Good approach. I'd add that another good way to build a minnow-sized holding (and support and improve the strength of the network) is through patient mining. I've built this up entirely though solo mining, mostly full time on one small (fanless) computer, plus part time on a few other ones: Refresh done, blocks received: 632 balance: 16801.72 ********************************************************************** Use "help" command to see the list of available commands. ********************************************************************** |
|
|
|
It is designed to replace BTC subsidy with fees at some unspecified time, probably in the reasonably-distant future when BTC subsidy is much smaller than it is today. There is zero evidence it was ever designed to replace for example 3600 BTC/day in subsidy. This can only be a gradual process / not an on-off switch where fees suddenly spike upwards 100x.... Yes but your comment that fees need to rise (as denominated in BTC) is not supported by any evidence, including the chart you linked. I don't follow... What evidence do you need? That's the design of BTC: Fees have to take over from subsidy. It is a known element of how it works. Yes, but that does not mean that fees have to increase. Where is your evidence that fees have to increase? There is a glide path in place in reducing subsidy so that fee increases don't go from zero to max overnight when coin distribution is (practically) over. Nearly over? I don't think so. We've had a grand total of one halving. On this chart we are in reward era 2 out of 34. If the designer of the system felt that subsidy must be replaced at an end point, and only then, there would be no glide path in diminishing subsidy. Emission would be flat, at a certain rate, until the last coins are issued. Do you understand that wallet software and even user education, are part of the system?
If you take the broader view, how about taking an even broader view: Do you understand that trial and error represent a lesson in user education? Every user at some point will have a moment where his tx takes a long time because he forgot to pay fees, clicked the "send as zero fee if possible" etc etc. That's the moment when he learned why fees are useful. That's part of his learning. And maybe they learn that Bitcoin is a pain in the ass, is unreliable and complicated, and go elsewhere. I'm not saying that the system has failed or that it will definitely fail. I'm saying that it is starting to fail right now, because there is a mismatch between the infrastructure and user-education requirements of the system and its ability to function effectively. That is absolutely the case. At best it is poor planning and deployment. 0.0001/KB = 0.01$ for a 250b tx. It's an extremely low fee and there is no way to spin it around that it isn't.
Actually the very common rule is to set the fee at 0.0001 per any part of a KB. You can see this easily by looking at a block explorer and seeing how many of the transactions have fees of 0.0001, 0.0002, etc. 0.0001 BTC is around 0.04 USD. Whether that is tiny in absolute terms or not is somewhat subjective, but the fact remains that it is not tiny relative to established practice over the past few years (as I said that was consistently a high priority rate until very recently) and for that reason lot of very widely deployed infrastructure is now failing. |
|
|
|
I didnt understand the answer of why a 5 or 6 minute block would be bad, other than a very small increase in orphan rate and delaying any txfee auction market for a while The answer was that the asymmetry is such that making the time too short (given network parameters, which are not really measurable and not stable) is much, much worse than making it too long. I continue to assert that reducing the time should not be confused with increasing capacity. A block time reduction by a factor of two, all else being equal, would also be accompanied by a reduction in the block size by a factor of two. |
|
|
|
It wasn't my assumption, it was something that appeared to have been calculated in the posted paper.
The paper is trying to be "conservative" in how limited they believe capacity increases from re-parameterization can come... meaning they're leaping for the largest possible increases, without regard to many considerations... e.g. how far before the existing system will certainly go off the rails. They use this approach so they can then argue that even that much isn't enough-- a conclusion I strongly agree with. That doesn't mean that those parameters are actually workable, however. In terms of the interblock time, decreases have dramatic effects once you consider an adversarial setting-- honest miners end up diluted working on many forks more often, while a high hashpower attacker stays focused. Decreased interblock times also increase the pressure to consolidate mining to a few (or one pools) by making it more profitable to do so. Many of the tools to increase reliability of shorter interblock times, like GHOST, increase other problems like selfish mining that crop up once you are considering rational actors (instead of just honest/altruistic ones). If you chart out a simulation of how long a user has to wait for (e.g. 99.9999%) confidence that their transaction won't be reversed, as a function of the expected interblock time you end up with a chart that looks like this(ignore the scaling):  (flip vertically for 'wait time goes up'). The scaling of this depends on factors like network hashpower distribution and latencies which are hard to measure and which change. The key take away is the derivative: if the time is somewhat longer than optimal for the network-reality, it has a fairly small effect on time-until-security ... but if it's shorter than optimal it rapidly destroys security. This is why it's important to be relatively conservative with the interblock interval. Where did the data for that chart come from? I'm interested in examining it in greater detail, along with seeing the full set of assumptions and parameters. |
|
|
|
It is designed to replace BTC subsidy with fees at some unspecified time, probably in the reasonably-distant future when BTC subsidy is much smaller than it is today. There is zero evidence it was ever designed to replace for example 3600 BTC/day in subsidy. This can only be a gradual process / not an on-off switch where fees suddenly spike upwards 100x.... Yes but your comment that fees need to rise (as denominated in BTC) is not supported by any evidence, including the chart you linked. I had a 24 hour confirm receiving a transaction that was sent by another ordinary user (with a fee that would under previously-normal conditions nearly-always result in 1st- or 2nd-block confirmation), and that placed me in a position of providing poor service to my customer by waiting a lot time to deliver, or assume the risk of transaction reversal. From my perspective as an ordinary user, Bitcoin is starting to fail as a transactional medium.
Bitcoin, as a network, is operating fine. Your customer's wallet software failed him in that it used a very low fee. In this regard, wallet software must have two features: 1) Good fee estimation 2) An option to rebroadcast the tx with higher fee Do you understand that wallet software and even user education, are part of the system? Yes it is possible to develop improvements that deal better with fee volatility. Those don't exist (in a well-deployed manner) today, which means there is a mismatch and dysfunction. As an ordinary user who is in no position to fix these things, the system is starting to fail. EDIT: Also, the wallet didn't use "a very low fee". It used 0.0001/KB which has been a very common fee calculation that has provided high priority service (1-2 blocks usually) for at least the past 2 years. It was only slightly below (maybe 20-30% below) what was needed to clear the transaction in a few hours, but remained below for 24 hours. |
|
|
|
It is designed to replace BTC subsidy with fees at some unspecified time, probably in the reasonably-distant future when BTC subsidy is much smaller than it is today. There is zero evidence it was ever designed to replace for example 3600 BTC/day in subsidy. I had a 24 hour confirm receiving a transaction that was sent by another ordinary user (with a fee that would under previously-normal conditions nearly-always result in 1st- or 2nd-block confirmation), and that placed me in a position of providing poor service to my customer by waiting a lot time to deliver, or assume the risk of transaction reversal. From my perspective as an ordinary user, Bitcoin is starting to fail as a transactional medium. |
|
|
|
I see no real benefit in a standalone miner without a pool. But a pool means botnets means hashrate skyrocketing.
Also I don't see any easy optimisation to get better hashrate, even with a custom miner.
There are no easy optimizations, sure, but when YVG released a CPU miner for Memorycoin (very similar algorithm), it was 2X or 3X more efficient, and was equal to GPU miners. YVG is a real giant of CPU optimizations and I think I can hear YVG yawning and stretching and wiping the sleep out of his eyes . . . . Was that YAM closed miner? Or was it opensource? If open, I will have a look. And, I promise I will publish my findings :-) YAM's miners have always been closed source afaik. |
|
|
|
It has been discussed. There are threads here about it.
Does not really help with anything. The shorter block time has a comparable effect to larger blocks in terms of relay latency sensitivity. The bandwidth and storage requirements are unchanged.
There is an advantage in terms of faster confirmations, but a disadvantage in terms of longer header chains for SPV clients.
So overall, maybe worth considering, but overall kind of pointless.
doubling tx capacity is pointless? What I mean is halving the block time vs. doubling the block size is largely pointless. supposedly dealing with the massive 1MB blocks are the issue that creates resistance to increasing the blocksize. Establishing a txfee market has nothing to do with this resistance. The miners absolutely dont want to make more money by forcing txfees up.
5 minute blocks of 1MB doubles the tx capacity and delays the txfee market that the miners say they dont want, since the block reward is all they care about. Whats a few satoshis worth of txfees anyway?
I don't think you will find it any easier to double the block rate than double the block size. Just my opinion. |
|
|
|
correct me if i am wrong is it possible to see the balance of any monero address on the online explorer  No |
|
|
|
It's about an Aeon node outside, not yours. I encountered the same issue with the node (IP: 46.228.6.*) so I had to block it from sync with my node. ah! thanks for clarifying that  so do i just block it through the .conf file? There is no manual blocking. If the node misbehaves it will get blocked automatically, although there are probably some sorts of misbehavior that don't get blocked. If you want a manual block, you would have to use a firewall such as ufw. also how do i get any kind of feedback that the miner works? anything like working on this or that. i mean the daemon terminal won't show anything else than "sync" messages
If you mean the built-in solo miner you can get a hash rate display with show_hr (turn off with hide_hr). |
|
|
|
|
It has been discussed. There are threads here about it.
Does not really help with anything. The shorter block time has a comparable effect to larger blocks in terms of relay latency sensitivity. The bandwidth and storage requirements are unchanged.
There is an advantage in terms of faster confirmations, but a disadvantage in terms of longer header chains for SPV clients.
So overall, maybe worth considering, but overall kind of pointless.
|
|
|
|
If someone put a big buy wall (maybe 20BTC+) at the current price do you think it would just sit there or would people dump into it?
Asking for a friend.
How many AEONs is that? I'm pretty sure that a lot of the mined coins get dumped so they would probably eat away at the wall. |
|
|
|
|
Show Posts
