I'm there but the chat that is most live I don't think is a place for outsiders to ask questions or make helpful suggestions.

Can one really trust a new language to create working solutions when that language itself has never produced a real world product before?
Can't existing languages just create new objects and functions to do what you need to do?

"I need to clarify. We have to make a distinction between decentralized in the sense that there is no node in charge vs decentralized meaning that you grow the network one piece at a time."

Ok, so I must say I am a bit disgruntled at the recent happenings.  That video is very revealing.  I urge everyone with a large vested interest to watch carefully:
https://www.youtube.com/watch?v=FLrvV2YKbZg

This is a toxic relationship among the core team because they have lost trust in each other.  Synereo cannot move forward with this type of angst between close founders.  This disagreement isn't about the technical theories, this is about fundamental relationship of the members and the way they are operating.  

Here's an analogy - a couple may disagree and argue about various topics like where to vacation, where to live, what to eat, what to do for fun... but at the end of the day, they still love each other despite surface issues... but if they question each others' loyalty, trust or commitment, they are questioning the foundation of the marriage or partnership, which is dangerous... and how can one count on the other to deliver thereafter, if there is a loss of trust?

As much as I hate to say this (especially since I know Greg personally, which as honest as I've been on this forum about my IRL persona), I think he has to go (good thing I'm not using my real name here ha).  As a fellow developer, I have been in these kinds of disputes and it doesn't end well.  This is not a disagreement about the technical fundamentals as we may have seen with other coin founder teams, this is an issue where the founders no longer trust each other, namely Dor does not trust Greg to deliver on deadlines, which continue to be delayed.

And sadly, Greg is pulling a typical developer move, trying to take credit for docs and pushing the technicals without real prototypes/demos, which honestly is something I've been guilty of doing myself.  But as an investor, even though I made quite a bit in the early days, over the past few months I lost roughly $43k USD worth of AMPs and today I am officially out of this, but there is an upside.  

First, I have to call out Greg on his bullshit.  He is stalling, using funds to drive his own development, because he's a perfectionist and self-centered.  

Second, this disagreement is super dangerous to Synereo - the development was heavily based on Greg's proprietary theories and code.  So if Greg has to leave, he takes the only real code with him.  Greg is trying to maintain credit on all the technical fundamentals, so he is essentially the technical team for Synereo.  If they must part ways, which I believe is the only way forward), then what is left, a marketing team?  A CEO who has no technical background whatsoever (though I think Dor is awesome at funding/marketing considering he's been pitching an empty promise for the past 2 years and despite that got huge funding and mainstream media press).  Even if he stays, the relationship going forward will be poisoned by the criticisms thrown around, which question the nature of the partnership.  It will be a very thin layer of ice that Dor would have to walk on, to constantly avoid Greg holding the project technical/code hostage.  Greg is in the position to easily blackmail Dor - that's really bad, and I have to stick with my Jewish brothers on this one.  Dor really trusted Greg putting that much control in him, but Greg broke that trust, even from day one.  

But anway, financially, here's the upside.  I'm out of Synereo, because Greg is planning to leave Synereo and take the code with him.  There is a strong possibility of this.  This is what he has been pondering, based on a conversation I had with a close mutual friend on Skype very recently.  That's why I decided to sell today, for a huge loss, and I probably caused the dump in the last few minutes dropping it from 7k satoshi to 6k, though I'm sure the rise of BTC is not helping either.

Just want everyone to know this is not a 'whale' accumulation phase.  Unless Dor and Greg are amazing actors making this up (including everyone in my mutual inner circle), then this is about to go lower, and you should save what little you have left and stay in BTC while it rises a bit.  Synereo may cease to exist, especially if Greg leaves with the code and all the partners come knocking and blaming Dor for deadlines and missed promises (which already seems to be happening).

Good luck everyone.

It's only serious because of the threat to the system, not because of the technical issue that's the ostensible point of contention.

We need bigger blocks since that's the only way to let bitcoin survive. 1MB blocks will hinder adoption and will make bitcoin obsolete over time.

Satoshi chose the 10 minute block interval as another careful, conservative limit. Sergio is an incredibly accomplished computer scientist, he would not suggest this change if he wasn't confident that Satoshi's concerns can be mitigated.

I'm not sure how much this helps though; it's two broad issues rolled into one, so it has the potential to just create a whole new set of arguments. However, if 95% of people agreed to do this tomorrow, and the technical aspects were convincing to me, I'd get on board.

The problem is that, as I tried to explain, there will not be a "Gavincoin" and an "Adamcoin".  Even if the chain splits, and the 1 MB branch survives for a while, there will be just a two-headed bitcoin. Even if you could trade and speculate on each coin separately, you cannot attack one in the market without harming the other.  

I'm also not to sure whether any actual company have thus far come out to support a specific 'software' implementation. I know many are supporting larger blocks but so do most of us.

With that said, I like this idea. We are past the point where bitcoin was just a project to be 'played' and 'toyed' with. There is serious money invested in bitcoin and the developers of core, xt or whatever implementation needs to understand that their actions could have serious consequences.

I'm not saying that the 'developers' are not taking this seriously but it's maybe time that all are given a wakeup call as to how serious this matter truly is.

As recently proposed by Core developer Sergio Lerner, is to hold onto the 1 megabyte limit, but speed up the block interval. If 1 megabyte blocks are found every five minutes instead of 10, that would allow for double the amount of transactions on the network while also decreasing confirmation times.

There is a difference between supporting increasing the maximum block size and supporting XT. They are NOT THE SAME. Please check again and see if you can find anything about these companies that explicitly state they support BitcoinXT, not just support an increase of the maximum blocksize. Implicit statements such as supporting the max block size may not hold up in court.

Of course, I don't think this will actually work, but good luck.

You're not understanding the point. Older blocks are valid by virtue of the software using older rules. The version in the header specifies which set of rules to use. A version 1 block with version 1 in the header is still valid, even if version 1 blocks are not valid when labeled with a newer version.


So? Then their block is validated under those rules, assuming new blocks under old rules are even considered valid after a certain point.


That has its own overhead. I'm not sure how it would ever outweigh the drawbacks. 4 bytes isn't that much, unless you're still hand-soldering discrete 74XX76 flip-flops together for memory.

The protocol would be more complicated.  The protocol must be able to understand all of the blocks in Bitcoin's history.

Attempting to remove 3 bytes from the block header would likely render all ASIC mining hardware worthless, at a saving of 200kB per year of disk space.

Most of the contents of the block chain are hashes (uncompressible) and ECDSA signatures (uncompressible).

Older blocks may no longer be considered valid blocks under new rules

If the version numbers did not exist, then we would have an issue where some v2 blocks are no longer valid under v3 rules and the clients would get all screwed up because they have historic blocks that don't validate.

Version numbers also help to facilitate miner voting. Miners voted for using BIP66 rules by producing v3 blocks. BitcoinXT nodes vote for BitcoinXT by producing blocks with 0x20000007 set as the version.