Both would benefit immensely of removing the transaction ordering constraints (in fact, graphene doesn't work at all with the current transaction ordering).
Really? I thought they'd just additionally transmit the ordering. There's a pending PR for BU, so I guess they have a plan to work around that. But I didn't look into the details yet.
This also has implication for sharding as it allows proof of absence. Peter Rizun and Tom Zander are in opposition to this change, so if you want to move this forward, talk to them.
I talked to
@Peter R regarding this and AFAIR he was hesitant, like I am, but not 100% opposed forever. I am not sure yet whether we have all the implications on the map yet regarding changing the ordering. For example, lexicographic by-hash ordering would make some operations regarding weakblocks O(n log n) instead of O(n) and generally introduce more complexity.
Might be a worthwhile trade-off for improvements in other areas such as proof absence - but yeah, I must say it is exactly one of these things that we should let stew a bit more, IMO.
I also don't see how it is fundamental to address the improvement suggestions that I made above. I see at least a dozen fruits hanging low enough to fix first without changing this.
==================
Sure, I hope you can read the massive amounts of docs/backlogs etc scattered around the net.
But that is the issue. I am looking for an architectural introduction,
overview documentation. Below, you write "has been very little more than creating a multi-threaded framework" but where is the documentation on that?
That the issue. "The code is the documentation" doesn't cut it anymore IMO. It might have been o.k. for Satoshi's initial release, but some doxygen doc hints plus gitlogs plus unit tests is a
mess to read.
Sorry for being so blunt. But that's simply not how it should work regarding docs and I think this is also the main issue that keeps you from gaining more followers and devs for flowee, if that is what you intend.
What I imagine is something like the "Protocol" page on the bitcoin wiki, but for your multi-threaded hub thingy in flowee.
And don't take it the wrong way: I am not aiming to shoot down flowee here, nor I am trying to downplay what you did. I simply do not know what is available in flowee - and then there's the license issue.
In most codebases we use flags for this. Same effect solving the issue you seem to have.
So I can set a flag and have a bitcoin-mempoold talking to a bitcoin-networkd? That's news to me ...
Is that possible in flowee? Where can I find that out? What is the protocol spoken between mempoold and networkd? Where is that documented? See above ...
For me the GPLv3 serves two purposes. First is that I want code I write in my spare time to stay free and not some company or clone-coin or government to adopt it and make it closed source.
I understand. I made the voting tool for BU GPL-licensed, after all. (And I even got paid by BU for writing parts of it; there's also other reasons why I think the GPL is a good fit). But with BCH, I see some positive effect on my net worth from the coins I hold and thus I am incentivized even when companies 'steal' my code. And MIT is simply default.
Second is that this license is much more friendly to the authors wrt patenting. As this is a hot topic, maybe you don't want to reject this license so quickly.
Fair point, but that is not to say that patent issues can not be addressed outside the scope of the GPL!
The other way around doesn't work, and its a fact that the majority of the successful open source projects use GPL, code flowee can now copy. The benefits are real.
I understand. But the same symmetry keeps me from basing off of flowee. I hope you can see why.
Licensing issues can be completely avoided as well for extra components. The idea of having different components run in different processes also isolates them from licensing issues.
Agreed. But for that we need independent daemons. Also the protocols between them (likely a set of IPC calls with 0mq or so...) need to be
... properly defined and documented ...
==================
This is why we are a minority fork. Strategically, we suck, you and a few other being an exception.
I don't think we suck, and also not strategically. Stuff takes time. As Tom said, you won't get a coherent message from all BCHlers. What do you expect here, that people are all shutting their mouths about Core going towards POW forks or cheering them on?
If I look on reddit, I see half of the folks cheering on Core doing a POW fork, and half of the folks saying that it is stupid and will backfire.
It is the public. It is the market place of ideas. You'll hear a lot of noise, a lot of different opinions and, unless it is a very contrived, arcane or otherwise obscure plan, chances are that your "Monte Carlo sampling of opinions" will cover most angles.
