Should maxblocksize increase? Which proposal do you prefer? (Voting closes: September 04, 2015, 01:06:49 PM)
https://bitcointalksearch.org/topic/blocksize-survey-1144606
Topic: Gold collapsing. Bitcoin UP. - page 35. (Read 2032247 times)
well now i am just insulted. i thought they spent all their time here?! 
I think I can speak for the majority of the Alt section when I say "we wish they did" 
Yes I'm sure they would. Because 90% or more of the Alt section are a bunch of lying, thieving, plagiarizing, instamining rip-off artists. They would very much like it people such as iCE and myself were not there, so they could scam without being challenged over it.
Or scroll back through his post history and notice how which competitors this 'core dev' for Monero and now AEON is attacking: https://bitcointalksearch.org/user/smooth-13813
Yes please do. For example, one of them is currently plagiarizing Bitcoin Core's code, complete with identical bugs, stripping out the copyright messages, reformatting it, and passing it off as it's own work. Here is the link to that, with evidence
When I call them out for that, I'm attacked as a troll, and blobafett2 adds that to his list of reasons I have a "conflict of interest" and takes it upon himself to "investigate" it.
Well, I just happen to think these scammers need to be called out when they do things like that.
This has nothing to with iCE. There is no tag team (for example I don't think iCE has commented on the plagiarizing, reformatting scam at all), except that we both happen to hold blobafett2's favorite scam, Dash, to the same level of scrutiny and it drives them crazy.
So now he is stalking me by following me around and posting his personal attacks on each and thread I ever post on now, whether related or not to his agenda or subject matter in any way whatsoever.
Smooth - Like I said I don't know anything about 'VNL', but I know that yesterday you threatened the entire Dash community on their official thread that if the 'media' doesn't agree to your demands you will spam their thread every day until they do, about a topic you have already posted about 1000s of times and was resolved by the community 18 months ago.
public service announcement
Dash (formerly xcoin and darkcoin) had a significant fastmine over the first 48 hours of its existence (~2 million coins). These facts should not be glossed over by those seeking a fairly launched coin, so until the dash media reflects these facts, this warning will be posted every 24 hours on the BCT dash thread. This warning will not be posted when the media reflects these facts. For those seeking more information Monero Developer Smooth has created a thread with the pertinent facts: https://bitcointalksearch.org/topic/why-the-darkcoindashdashpay-instamine-matters-999886
Dash (formerly xcoin and darkcoin) had a significant fastmine over the first 48 hours of its existence (~2 million coins). These facts should not be glossed over by those seeking a fairly launched coin, so until the dash media reflects these facts, this warning will be posted every 24 hours on the BCT dash thread. This warning will not be posted when the media reflects these facts. For those seeking more information Monero Developer Smooth has created a thread with the pertinent facts: https://bitcointalksearch.org/topic/why-the-darkcoindashdashpay-instamine-matters-999886
That would be great, except you are the core dev of 2 smaller 'anon coin' competitors who's communities talk more about 'beating Dash and Bitcoin' than they do about your coins, so who looks like the scammer with this kind of unethical, unprofessional, and gutter-level type of behaviour?
Calling me a scammer is going to be a hard one, I have never asked anyone for money, and I busted the Mintpal scammer (who you remind me of lol) on my own time to try to help people after realizing I got scammed myself: https://bitcointalksearch.org/topic/moolah-scam-on-mintpal-reporting-missing-coins-824211
I already showed how your web wallet MyMonero.com was sending user's private keys to the server, contrary to your mantra that '"everything is client side and private keys never go to the server' so actually there is not security at all - and since I revealed that and your lead dev acknowledged it, nothing was said to your community who are still in the dark.
If you care about privacy and are not a scammer, why didn't you warn your users that their keys / funds could have been compromised - nothing was ever announced on your thread, and people are still using it
I don't want to argue with you on this thread Smooth as that's not fair, if you want to talk more come to the other thread where you are nicely contained from harming the rest of the BCT community. https://bitcointalksearch.org/topic/xmraeon-developer-smooth-investigation-1151565
Or scroll back through his post history and notice how which competitors this 'core dev' for Monero and now AEON is attacking: https://bitcointalksearch.org/user/smooth-13813
Yes please do. For example, one of them is currently plagiarizing Bitcoin Core's code, complete with identical bugs, stripping out the copyright messages, reformatting it, and passing it off as it's own work. Here is the link to that, with evidence
When I call them out for that, I'm attacked as a troll, and blobafett2 adds that to his list of reasons I have a "conflict of interest" and takes it upon himself to "investigate" it.
Well, I just happen to think these scammers need to be called out when they do things like that.
This has nothing to with iCE. There is no tag team (for example I don't think iCE has commented on the plagiarizing, reformatting scam at all), except that we both happen to hold blobafett2's favorite scam, Dash, to the same level of scrutiny and it drives them crazy.
So now he is stalking me by following me around and posting his personal attacks on each and thread I ever post on now, whether related or not to his agenda or subject matter in any way whatsoever.
sounds like what i'm going thru on Reddit.
if i had to guess who was behind the /u/shiller1235 and /u/exposing_shills troll accts, i would have to guess it was /u/marcus_of_augustus who is the OP of his linked BCT thread.
well now i am just insulted. i thought they spent all their time here?!
I think I can speak for the majority of the Alt section when I say "we wish they did" Or scroll back through his post history and notice how which competitors this 'core dev' for Monero and now AEON is attacking: https://bitcointalksearch.org/user/smooth-13813
Yes please do. For example, one of them is currently plagiarizing Bitcoin Core's code, complete with identical bugs, stripping out the copyright messages, reformatting it, and passing it off as it's own work. Here is the link to that, with evidence
When I call them out for that, I'm attacked as a troll, and blobafett2 adds that to his list of reasons I have a "conflict of interest" and takes it upon himself to "investigate" it.
Well, I just happen to think these scammers need to be called out when they do things like that.
This has nothing to with iCE. There is no tag team (for example I don't think iCE has commented on the plagiarizing, reformatting scam at all), except that we both happen to hold blobafett2's favorite scam, Dash, to the same level of scrutiny and it drives them crazy.
So now he is stalking me by following me around and posting his personal attacks on each and thread I ever post on now, whether related or not to his agenda or subject matter in any way whatsoever.
…
At this point I'd say just find a way to put the forks on the market and let's arbitrage it out. I will submit if a fork cannot gain the market cap advantage, and I suspect the small-blockers will likewise if Core loses it. Money talks.
At this point I'd say just find a way to put the forks on the market and let's arbitrage it out. I will submit if a fork cannot gain the market cap advantage, and I suspect the small-blockers will likewise if Core loses it. Money talks.
I had a strange idea recently: what if we don't even bother with BIP100, BIP101, etc., or trying to come to "consensus" in some formal way. What if, instead, we just make it very easy for node operators to adjust their block size limit. Imagine a drop down menu where you can select "1 MB, 2 MB, 4 MB, 8 MB, … ." What would happen?
Personally, I'd just select some big block size limit, like 32 MB. This way, I'd be guaranteed to follow the longest proof of work chain, regardless of what the effective block size limit becomes. I'd expect many people to do the same thing. Eventually, it becomes obvious that the economic majority is supporting a larger limit, and a brave miner publishes a block that is 1.1 MB is size. We all witness that indeed that block got included into the longest proof of work chain, and then suddenly all miners are confident producing 1.1 MB blocks. Thus, the effective block size limit slowly creeps upwards, as this process is repeated over and over as demand for block space grows.
TL/DR: maybe we don't need a strict definition for the max block size limit.
that's just a re-write of what i've been advocating; lift the limit entirely.
but yeah, your idea is great b/c it would give full node operators a sense of being in charge via a pull down menu. i like it.
don't forget that mining pools are just huge hashing overlays of full nodes which they operate and could use to do the same type of voting.
Yes, you have been essentially advocating the same thing.
We could take this idea further: in addition to the drop-down menu where node operators and miners select the max block size they'll accept, we could add two new features to improve communication of their decisions:
1. The max block size selected by a node would be written into the header of any blocks the node mines.
2. The P2P protocol would be extended so that nodes could poll other nodes to find out their block size limit.
This would be a highly decentralized way of coming to consensus in a very flexible and dynamic manner.
It would be a recognition that the block size limit is not part of the consensus layer, but rather part of the transport layer, as sickpig suggested:
you know what I can't stop thinking that the max block size is a transport layer constraint that have crept in consensus layer.
The network would dynamically determine the max block size as the network evolves by expressing the size of the blocks they will accept with the drop-down menu on their client.
So…is this a good idea? If there are no obvious "gotchas" then perhaps we should write up a BIP.
So would this essentially be a voting mechanism on current block size (of course it can change dynamically on the next block)?
What % would determine that a block size has "consensus"?
Interesting idea...
I would look at this as a signalling mechanism rather than as a voting mechanism.
Here's the difference:
In BIP100, the result of voting affects the behaviour of the software in a pre-defined way.
In this new proposal, the signalling doesn't have any effect on the software. Instead, it is used as a way to communicate the maximum block size the network will accept to people (albeit in a fuzzy way).
It is sort of like NewLiberty's idea of a feedback-loop based block size limit, but the feedback is achieved by the actions of people rather than by the behaviour of code.
the more you talk about this the more i like it, Peter.
it seems the avg Bitcoiner can't bear to hear or even discuss "possible" messy scenarios as Mike is quite rightfully willing to do.
It's pretty clear that Mike doesn't understand what an economic majority means. If you have the economic majority, you don't need to enforce a "technical mess" to fix anything.
I still don't understand how anyone interested in Bitcoin can support anything associated with Hearn after hearing anything the guy has to say, unless they actually want to turn Bitcoin into something completely unrecognizable.
I'm not completely opposed to bigger blocks, but I am completely opposed to BitcoinXT and anything Hearn.
yeah, if you look in his redlist thread you'll see me in there as one of the most vocal against tracking coins.
i get the concern. if i had my choice, i'd have Gavin be the lead for XT. but it appears he doesn't want the job inexplicably to the Cripplecoiner's shouts of "benevolent dictator". so it looks like we'll just have to trust what he says about not wanting or having time to lead much. good thing is Gavin does have commit access. we can always fork away from him if he abuses his power but certainly that is not the preferred scenario. all i know is that i don't want to be under a regime with folks like gmax, Back, and LukeJr in charge. those guys have already abused their power afaic.
You may also need to add a mechanism to alert the user when the network does fork away from their limit.
Agreed. Anything that helps node operators track the consensus of the network would be a positive. Mengerian spoke to this here.
…
At this point I'd say just find a way to put the forks on the market and let's arbitrage it out. I will submit if a fork cannot gain the market cap advantage, and I suspect the small-blockers will likewise if Core loses it. Money talks.
At this point I'd say just find a way to put the forks on the market and let's arbitrage it out. I will submit if a fork cannot gain the market cap advantage, and I suspect the small-blockers will likewise if Core loses it. Money talks.
I had a strange idea recently: what if we don't even bother with BIP100, BIP101, etc., or trying to come to "consensus" in some formal way. What if, instead, we just make it very easy for node operators to adjust their block size limit. Imagine a drop down menu where you can select "1 MB, 2 MB, 4 MB, 8 MB, … ." What would happen?
Personally, I'd just select some big block size limit, like 32 MB. This way, I'd be guaranteed to follow the longest proof of work chain, regardless of what the effective block size limit becomes. I'd expect many people to do the same thing. Eventually, it becomes obvious that the economic majority is supporting a larger limit, and a brave miner publishes a block that is 1.1 MB is size. We all witness that indeed that block got included into the longest proof of work chain, and then suddenly all miners are confident producing 1.1 MB blocks. Thus, the effective block size limit slowly creeps upwards, as this process is repeated over and over as demand for block space grows.
TL/DR: maybe we don't need a strict definition for the max block size limit.
that's just a re-write of what i've been advocating; lift the limit entirely.
but yeah, your idea is great b/c it would give full node operators a sense of being in charge via a pull down menu. i like it.
don't forget that mining pools are just huge hashing overlays of full nodes which they operate and could use to do the same type of voting.
Yes, you have been essentially advocating the same thing.
We could take this idea further: in addition to the drop-down menu where node operators and miners select the max block size they'll accept, we could add two new features to improve communication of their decisions:
1. The max block size selected by a node would be written into the header of any blocks the node mines.
2. The P2P protocol would be extended so that nodes could poll other nodes to find out their block size limit.
This would be a highly decentralized way of coming to consensus in a very flexible and dynamic manner.
It would be a recognition that the block size limit is not part of the consensus layer, but rather part of the transport layer, as sickpig suggested:
you know what I can't stop thinking that the max block size is a transport layer constraint that have crept in consensus layer.
The network would dynamically determine the max block size as the network evolves by expressing the size of the blocks they will accept with the drop-down menu on their client.
So…is this a good idea? If there are no obvious "gotchas" then perhaps we should write up a BIP.
So would this essentially be a voting mechanism on current block size (of course it can change dynamically on the next block)?
What % would determine that a block size has "consensus"?
Interesting idea...
I would look at this as a signalling mechanism rather than as a voting mechanism.
Here's the difference:
In BIP100, the result of voting affects the behaviour of the software in a pre-defined way.
In this new proposal, the signalling doesn't have any effect on the software. Instead, it is used as a way to communicate the maximum block size the network will accept to people (albeit in a fuzzy way).
It is sort of like NewLiberty's idea of a feedback-loop based block size limit, but the feedback is achieved by the actions of people rather than by the behaviour of code.
^ I apologize for the presence of the stalker who follows me around and spams his "warning" wherever I post, no matter how off topic he might be. He's upset because I regularly call out his favorite heavily-isntamined shitcoin (Dash, formerly Darkcoin) and is conducting this campaign as retaliation. It's sad to see him bring that there.
I trust people's intelligence enough to be able to do their own research Smooth. You are a prolific troll in the BCT alt section with 1000s of posts attacking your competitors, for example:
Example Day of forum attacks by Smooth (today, 12th Aug 2015)
Attacking his competitors:
Dash thread: 28 posts (competing with the anon feature)
Vanilla threads: 20 posts (competing for Poloniex volume)
Bytecoin thread: 4 posts (competing "Anon coin")
Posting on his own threads:
AEON: 3 posts
Monero: 0 posts
Smooth's competitors attacking his coins on any threads:
Dash devs: 0 posts
Vanilla devs: 0 posts
Bytecoin devs: 0 posts
Whilst at the same time pretending to be a Monero core-dev, when the only development you did in one year for Monero is 30 lines of code which is mostly adding comments, inseting and removing preprocessor directives,and 2 IF statements:
https://github.com/monero-project/bitmonero/commits?author=iamsmooth
Nov 9, 2014 Change 6 lines of codes, temporary bug fix
Nov 11, 2014 Commented out 2 lines of code
March 5, 2015 4 lines to change a variable and add IF statement
March 5, 2015 Added 4 lines of code, in the form of a comment
March 6, 2015 Added one line of code (a checkpoint)
March 10, 2015 Changing a default value and an IF statement, 6 lines of code
Apr 5, 2015 4 lines of code and a comment
Apr 5, 2015 2 lines of code to handle a rounding
Apr 14, 2015 Remove a define, 1 line changed
...And that's an issue because you are using your cache as a Monero 'core team' dev to build up a new competitor to Monero (AEON) with the same features and only 2% of the market cap:
The funny thing is, Smooth the Monero core-dev has now personally taken over Aeon development, a tiny-marketcap competitor to Monero with the same the Bytecoin features / codebase, and has acquired at least 2.5% of the supply, has done 2 releases in the last month, is working on a GUI, his OP is advertising AEON as "the next generation of anonymous cryptocurrency" with no mention of his Monero involvement, and AEON market cap is gaining fast with 4x the volume of Monero on Bittrex[/url] - while Monero hasn't released anything for 9 months. Oh, and he spends the other half of his day providing unbiased "investment advice" to sell Dash and buy Monero (and now AEON )
From an ethical perspective, here is a dev of one coin, taking over a smaller competitor and using his position from Monero to pump the price of AEON which he owns a huge stake in (as well as try to crash the threads of his larger competitors to disrupt their functioning and slander them for being scams).
So what happens as AEON market cap grows closer to Moneros, and investors realize the Monero dev is doing more work on AEON than Monero, and they have the same features or AEON starts to get ahead? And nothing is being mentioned on the Monero thread or the AEON OP, and the Monero community seems happy with this!!!
)From an ethical perspective, here is a dev of one coin, taking over a smaller competitor and using his position from Monero to pump the price of AEON which he owns a huge stake in (as well as try to crash the threads of his larger competitors to disrupt their functioning and slander them for being scams).
So what happens as AEON market cap grows closer to Moneros, and investors realize the Monero dev is doing more work on AEON than Monero, and they have the same features or AEON starts to get ahead? And nothing is being mentioned on the Monero thread or the AEON OP, and the Monero community seems happy with this!!!
I am just posting this here for visibility Smooth.
You go around offering 'free investment advice' to the communities of all your competitors, in the form of sell them and buy Monero - with Dash, you are now even posting a 'warning' message each day and holding the community to ransom until the 'media' comply with your demands (lol), so if you are offering investment advice here I think this is relevant, and I think users here are smart enough to read between the lines and do their own research, because if you are here, there is no doubt some scheme going on to direct $ back to yourself and your projects like Monero / AEON and everything you say has that as it's main motive.
https://bitcointalksearch.org/topic/xmraeon-developer-smooth-investigation-1151565
Thanks
i read your link and the thing that jumped out at me was the link you drew btwn iCEBLOW and Smooth. do you think that iCEBLOW and Smooth tend to work together and if so, why?
Mainly because they are the most prolific tag-team troll-duo in the Alt section of BCT... most of their day is spent attacking Monero competitors main thread's with the same scam accusation repeated dozens of times regardless of any response or critical debate anyone provides to them. The common factor is if there is a coin that has more value than Monero and is anything to do with 'anon', or is a contender for the top-volume slots on Poloniex, you will find Icebreaker and Smooth there trolling which ramps up the morethose coins prices or volume is rising.
Just a few examples I pulled out where they are trolling in tandem...(these are attack-Dash threads as that is their largest target and also how I 'bumped' into them as a Dash supporter)
Re: Why the darkcoin/dash instamine matters
DASH (aka DARKCOIN) vicitim resources
Spamming the CoinMarketCap.com thread to get Dash listed as a premine
Darkcoin aka DASH - The biggest ongoing SCAM in crypto
Re: Dash's Instamined/Partly Premined Beginnings
BTW, I was the user BlockaFett that helped expose the Mintpal scam and return some of the user's coins, including all of the XMR that was stolen by Alex Green aka Ryan Kennedy: https://bitcointalksearch.org/topic/moolah-scam-on-mintpal-reporting-missing-coins-824211
More info on Smooth's activity here: https://bitcointalksearch.org/topic/xmraeon-developer-smooth-investigation-1151565.0
Or scroll back through his post history and notice how which competitors this 'core dev' for Monero and now AEON is attacking: https://bitcointalksearch.org/user/smooth-13813
Apologies to this thread for any disruption, Smooth is the biggest ALT-troll right now whilst at the same time trying to get investors into 2 competing alt-coin schemes he is running, I have just posted this because I think he needs a little light shone under his rock, and I doubt any of his BCT activities are for the reasons he gives so there is probably some reason he is here too...
well now i am just insulted. i thought they spent all their time here?!
…
At this point I'd say just find a way to put the forks on the market and let's arbitrage it out. I will submit if a fork cannot gain the market cap advantage, and I suspect the small-blockers will likewise if Core loses it. Money talks.
At this point I'd say just find a way to put the forks on the market and let's arbitrage it out. I will submit if a fork cannot gain the market cap advantage, and I suspect the small-blockers will likewise if Core loses it. Money talks.
I had a strange idea recently: what if we don't even bother with BIP100, BIP101, etc., or trying to come to "consensus" in some formal way. What if, instead, we just make it very easy for node operators to adjust their block size limit. Imagine a drop down menu where you can select "1 MB, 2 MB, 4 MB, 8 MB, … ." What would happen?
Personally, I'd just select some big block size limit, like 32 MB. This way, I'd be guaranteed to follow the longest proof of work chain, regardless of what the effective block size limit becomes. I'd expect many people to do the same thing. Eventually, it becomes obvious that the economic majority is supporting a larger limit, and a brave miner publishes a block that is 1.1 MB is size. We all witness that indeed that block got included into the longest proof of work chain, and then suddenly all miners are confident producing 1.1 MB blocks. Thus, the effective block size limit slowly creeps upwards, as this process is repeated over and over as demand for block space grows.
TL/DR: maybe we don't need a strict definition for the max block size limit.
You know that you can do this now, right? And always could.
The code is open source, you can (of course) just change it and compile.
We were discussing writing a BIP for the idea where the block size limit is removed from the consensus layer, and each client manually selects the max block size that they are willing to accept. If this idea truly makes sense and can gain some mindshare, then perhaps to go along with a BIP, we could fork Bitcoin Core to create a "reference implementation" for the new idea? Like Awemany said, it wouldn't require much coding.
I'd probably run it too, because by setting my personal block size limit high, I would always get dragged along with the longest proof-of-work chain. Who knows, it could actually catch on more widely too…
We'd also need a name for this implementation.
You may also need to add a mechanism to alert the user when the network does fork away from their limit.
I'm actually quite excited about this idea. It has a sort of inevitable feel to it.
Yes. Since anyone can run any software they want to interact with the Bitcoin network, this idea does seem like a logical development.
It also seems like one of those counter-intuitive anti-fragility things, where the seeming chaos and instability at a micro level will actually lead to a more predictable and stable behaviour at the macro level.
If it became more common for individual nodes to be able to tweak consensus parameters, then I think that would actually lead to more predictable and stable consensus behaviour in the long run. The worst thing that can happen to a node operator is to fall out of consensus with the rest of the network, so individual node operators would be strongly incentivised to develop methods to ensure they can track the status of the network, and deal with any potential consensus forks.
As it stands now, consensus behaviour is based on the specific implementation details of Bitcoin Core. The software is not designed with the assumption that hard consensus forks are a likely event, and when they do happen nodes are not designed to handle it gracefully. The accidental hard form of March 2013 happened because of an obscure implementation detail in the Core software, and was only possible because the software monoculture created a "single point of failure". A more diverse implementation of consensus rules might result in more frequent consensus divergences and orphaned blocks, but each one would be non-catastrophic, and would lead toward a more stable and resilient network in the long run.
Great insight!
You bring up an interesting point: rather than viewing forks as something that must be avoided, let's view them as something inevitable and necessary for the evolution of Bitcoin, and then work to find ways to make convergence of consensus in the presence of forks as robust as possible.
I think you're right that this "seeming chaos and instability at a micro level will actually lead to a more predictable and stable behaviour at the macro level."
well, Gavin has always encouraged alternative implementations of Bitcoin, such as btc-d as a form of resiliency.
it seems the avg Bitcoiner can't bear to hear or even discuss "possible" messy scenarios as Mike is quite rightfully willing to do.
It's pretty clear that Mike doesn't understand what an economic majority means. If you have the economic majority, you don't need to enforce a "technical mess" to fix anything.
I still don't understand how anyone interested in Bitcoin can support anything associated with Hearn after hearing anything the guy has to say, unless they actually want to turn Bitcoin into something completely unrecognizable.
I'm not completely opposed to bigger blocks, but I am completely opposed to BitcoinXT and anything Hearn.
+1
^ I apologize for the presence of the stalker who follows me around and spams his "warning" wherever I post, no matter how off topic he might be. He's upset because I regularly call out his favorite heavily-isntamined shitcoin (Dash, formerly Darkcoin) and is conducting this campaign as retaliation. It's sad to see him bring that there.
I trust people's intelligence enough to be able to do their own research Smooth. You are a prolific troll in the BCT alt section with 1000s of posts attacking your competitors, for example:
Example Day of forum attacks by Smooth (today, 12th Aug 2015)
Attacking his competitors:
Dash thread: 28 posts (competing with the anon feature)
Vanilla threads: 20 posts (competing for Poloniex volume)
Bytecoin thread: 4 posts (competing "Anon coin")
Posting on his own threads:
AEON: 3 posts
Monero: 0 posts
Smooth's competitors attacking his coins on any threads:
Dash devs: 0 posts
Vanilla devs: 0 posts
Bytecoin devs: 0 posts
Whilst at the same time pretending to be a Monero core-dev, when the only development you did in one year for Monero is 30 lines of code which is mostly adding comments, inseting and removing preprocessor directives,and 2 IF statements:
https://github.com/monero-project/bitmonero/commits?author=iamsmooth
Nov 9, 2014 Change 6 lines of codes, temporary bug fix
Nov 11, 2014 Commented out 2 lines of code
March 5, 2015 4 lines to change a variable and add IF statement
March 5, 2015 Added 4 lines of code, in the form of a comment
March 6, 2015 Added one line of code (a checkpoint)
March 10, 2015 Changing a default value and an IF statement, 6 lines of code
Apr 5, 2015 4 lines of code and a comment
Apr 5, 2015 2 lines of code to handle a rounding
Apr 14, 2015 Remove a define, 1 line changed
...And that's an issue because you are using your cache as a Monero 'core team' dev to build up a new competitor to Monero (AEON) with the same features and only 2% of the market cap:
The funny thing is, Smooth the Monero core-dev has now personally taken over Aeon development, a tiny-marketcap competitor to Monero with the same the Bytecoin features / codebase, and has acquired at least 2.5% of the supply, has done 2 releases in the last month, is working on a GUI, his OP is advertising AEON as "the next generation of anonymous cryptocurrency" with no mention of his Monero involvement, and AEON market cap is gaining fast with 4x the volume of Monero on Bittrex[/url] - while Monero hasn't released anything for 9 months. Oh, and he spends the other half of his day providing unbiased "investment advice" to sell Dash and buy Monero (and now AEON )
From an ethical perspective, here is a dev of one coin, taking over a smaller competitor and using his position from Monero to pump the price of AEON which he owns a huge stake in (as well as try to crash the threads of his larger competitors to disrupt their functioning and slander them for being scams).
So what happens as AEON market cap grows closer to Moneros, and investors realize the Monero dev is doing more work on AEON than Monero, and they have the same features or AEON starts to get ahead? And nothing is being mentioned on the Monero thread or the AEON OP, and the Monero community seems happy with this!!!
)From an ethical perspective, here is a dev of one coin, taking over a smaller competitor and using his position from Monero to pump the price of AEON which he owns a huge stake in (as well as try to crash the threads of his larger competitors to disrupt their functioning and slander them for being scams).
So what happens as AEON market cap grows closer to Moneros, and investors realize the Monero dev is doing more work on AEON than Monero, and they have the same features or AEON starts to get ahead? And nothing is being mentioned on the Monero thread or the AEON OP, and the Monero community seems happy with this!!!
I am just posting this here for visibility Smooth.
You go around offering 'free investment advice' to the communities of all your competitors, in the form of sell them and buy Monero - with Dash, you are now even posting a 'warning' message each day and holding the community to ransom until the 'media' comply with your demands (lol), so if you are offering investment advice here I think this is relevant, and I think users here are smart enough to read between the lines and do their own research, because if you are here, there is no doubt some scheme going on to direct $ back to yourself and your projects like Monero / AEON and everything you say has that as it's main motive.
https://bitcointalksearch.org/topic/xmraeon-developer-smooth-investigation-1151565
Thanks
i read your link and the thing that jumped out at me was the link you drew btwn iCEBLOW and Smooth. do you think that iCEBLOW and Smooth tend to work together and if so, why?
Mainly because they are the most prolific tag-team troll-duo in the Alt section of BCT... most of their day is spent attacking Monero competitors main thread's with the same scam accusation repeated dozens of times regardless of any response or critical debate anyone provides to them. The common factor is if there is a coin that has more value than Monero and is anything to do with 'anon', or is a contender for the top-volume slots on Poloniex, you will find Icebreaker and Smooth there trolling which ramps up the morethose coins prices or volume is rising.
Just a few examples I pulled out where they are trolling in tandem...(these are attack-Dash threads as that is their largest target and also how I 'bumped' into them as a Dash supporter)
Re: Why the darkcoin/dash instamine matters
DASH (aka DARKCOIN) vicitim resources
Spamming the CoinMarketCap.com thread to get Dash listed as a premine
Darkcoin aka DASH - The biggest ongoing SCAM in crypto
Re: Dash's Instamined/Partly Premined Beginnings
BTW, I was the user BlockaFett that helped expose the Mintpal scam and return some of the user's coins, including all of the XMR that was stolen by Alex Green aka Ryan Kennedy: https://bitcointalksearch.org/topic/moolah-scam-on-mintpal-reporting-missing-coins-824211
More info on Smooth's activity here: https://bitcointalksearch.org/topic/xmraeon-developer-smooth-investigation-1151565.0
Or scroll back through his post history and notice how which competitors this 'core dev' for Monero and now AEON is attacking: https://bitcointalksearch.org/user/smooth-13813
Apologies to this thread for any disruption, Smooth is the biggest ALT-troll right now whilst at the same time trying to get investors into 2 competing alt-coin schemes he is running, I have just posted this because I think he needs a little light shone under his rock, and I doubt any of his BCT activities are for the reasons he gives so there is probably some reason he is here too...
…
At this point I'd say just find a way to put the forks on the market and let's arbitrage it out. I will submit if a fork cannot gain the market cap advantage, and I suspect the small-blockers will likewise if Core loses it. Money talks.
At this point I'd say just find a way to put the forks on the market and let's arbitrage it out. I will submit if a fork cannot gain the market cap advantage, and I suspect the small-blockers will likewise if Core loses it. Money talks.
I had a strange idea recently: what if we don't even bother with BIP100, BIP101, etc., or trying to come to "consensus" in some formal way. What if, instead, we just make it very easy for node operators to adjust their block size limit. Imagine a drop down menu where you can select "1 MB, 2 MB, 4 MB, 8 MB, … ." What would happen?
Personally, I'd just select some big block size limit, like 32 MB. This way, I'd be guaranteed to follow the longest proof of work chain, regardless of what the effective block size limit becomes. I'd expect many people to do the same thing. Eventually, it becomes obvious that the economic majority is supporting a larger limit, and a brave miner publishes a block that is 1.1 MB is size. We all witness that indeed that block got included into the longest proof of work chain, and then suddenly all miners are confident producing 1.1 MB blocks. Thus, the effective block size limit slowly creeps upwards, as this process is repeated over and over as demand for block space grows.
TL/DR: maybe we don't need a strict definition for the max block size limit.
You know that you can do this now, right? And always could.
The code is open source, you can (of course) just change it and compile.
We were discussing writing a BIP for the idea where the block size limit is removed from the consensus layer, and each client manually selects the max block size that they are willing to accept. If this idea truly makes sense and can gain some mindshare, then perhaps to go along with a BIP, we could fork Bitcoin Core to create a "reference implementation" for the new idea? Like Awemany said, it wouldn't require much coding.
I'd probably run it too, because by setting my personal block size limit high, I would always get dragged along with the longest proof-of-work chain. Who knows, it could actually catch on more widely too…
We'd also need a name for this implementation.
it seems the avg Bitcoiner can't bear to hear or even discuss "possible" messy scenarios as Mike is quite rightfully willing to do.
It's pretty clear that Mike doesn't understand what an economic majority means. If you have the economic majority, you don't need to enforce a "technical mess" to fix anything.
I still don't understand how anyone interested in Bitcoin can support anything associated with Hearn after hearing anything the guy has to say, unless they actually want to turn Bitcoin into something completely unrecognizable.
I'm not completely opposed to bigger blocks, but I am completely opposed to BitcoinXT and anything Hearn.
I'm actually quite excited about this idea. It has a sort of inevitable feel to it.
Yes. Since anyone can run any software they want to interact with the Bitcoin network, this idea does seem like a logical development.
It also seems like one of those counter-intuitive anti-fragility things, where the seeming chaos and instability at a micro level will actually lead to a more predictable and stable behaviour at the macro level.
If it became more common for individual nodes to be able to tweak consensus parameters, then I think that would actually lead to more predictable and stable consensus behaviour in the long run. The worst thing that can happen to a node operator is to fall out of consensus with the rest of the network, so individual node operators would be strongly incentivised to develop methods to ensure they can track the status of the network, and deal with any potential consensus forks.
As it stands now, consensus behaviour is based on the specific implementation details of Bitcoin Core. The software is not designed with the assumption that hard consensus forks are a likely event, and when they do happen nodes are not designed to handle it gracefully. The accidental hard form of March 2013 happened because of an obscure implementation detail in the Core software, and was only possible because the software monoculture created a "single point of failure". A more diverse implementation of consensus rules might result in more frequent consensus divergences and orphaned blocks, but each one would be non-catastrophic, and would lead toward a more stable and resilient network in the long run.
Great insight!
You bring up an interesting point: rather than viewing forks as something that must be avoided, let's view them as something inevitable and necessary for the evolution of Bitcoin, and then work to find ways to make convergence of consensus in the presence of forks as robust as possible.
I think you're right that this "seeming chaos and instability at a micro level will actually lead to a more predictable and stable behaviour at the macro level."
"frap.doc" smear.
As an observer I can tell you that I can't really tell the difference between this and your ICEblow stuff. I just see hate flying back and forth between you.
I have no idea who started it or what.
don't get me wrong. i don't hate iCE at all. i think i actually like him. he's an intelligent fellow; i just hate his tactics and over the top bombastic bile and vomit. i think there is an agenda there but i can't be sure what it is.
The reason is that I don't find your answers convincing, nor rigorously analyzed or presented, for the most part. That even applies to Peter R, in terms of many of his answers on this. His paper was good but it only addressed a small part of the larger set of questions.
then i'm sure you'll except the fact that i find your fears even less rigorously presented.
Sure. I haven't claimed otherwise, and I don't really think most of my posts on this should be convincing to anyone. They are generally conversational in tone and not trying to be authoritative. Although occasionally I do point out clear errors on specific points.
The thing is, I see this as a really hard problem to answer in a rigorous way. As I said, Peter R's paper was really good but only looked a small portion of the relevant concerns. I imagine it was also a fair amount of work. Now imagine five or so more papers like that looking at other aspects of the problem, and finally some additional papers looking at the entire thing at a system level. That's what is really needed. I don't think we are going to get that before this issue or the conflict over it becomes a serious problem one way or another.
We are trying to design an airplane upgrade while the plane is in the air, without any real knowledge of aerodynamics.
I agree with everything you said above, and I appreciate having people like you who understand how scientific progress is made incrementally by analyzing a small part of a larger and more complex problem.
However, I'm not sure I agree with everything you might have implied (correct me if I'm wrong). I agree we do not yet have sufficient knowledge to choose the best course of action regarding the block size limit, but that applies equally well--and perhaps more so--to keeping the limit constant at 1 MB.
I personally think we should increase the limit in some way while we continue to perform the research you suggested above. This seems like the least bad way to move forward. Do you disagree?
Yes I do. I've said a number of times I do support a 2-3 MB bump. I'm a bit perplexed by (what I perceive to be) the opposition to BIP102. I understand there were some technical issues with it, but fixing that should be straightforward. There seems to be more behind the hostility to it. That was when I first started to believe (somewhat) the conspiracy-ish theories about the motives of the small block side of the debate.
Jump to: