Quote from: marcelbit on December 19, 2017, 11:14:47 PM

Some of the complaints of the author contra Bitcoin Core:

This will be the millionth time I have to respond to the same completely false and fabricated ideas. All of these "complaints" are false.

Quote from: marcelbit on December 19, 2017, 11:14:47 PM

a) Bitcoin Core via the BlockStream team is too much influenced by investors like AXA. As a traditional insurance company AXA's interest may not be the best for the Bitcoin future.
Link: https://blockstream.com/about/#investors

Blockstream does not "control" a majority of contributors to Bitcoin Core nor do they have any control over what goes into Bitcoin Core. The maintainers are all independent of Blockstream (MIT DCI or Chaincode labs). The only person who has commit access to Bitcoin Core that works for Blockstream is Pieter Wuille, and he has had commit access since long before he co-founded Blockstream.

Quote from: marcelbit on December 19, 2017, 11:14:47 PM

b) The upcomming Lightning Network is patented software. The patent is held by BlockStream.
Remark: I have read BlockStreams explanation why they patent their software (https://blockstream.com/about/patent_pledge/). Which leads me to a sub-question:

The Lightning Network is not patented at all by Blockstream or anyone else. It is a free and open standard that is being developed by multiple development teams. In fact, a lot of development is led by non-Blockstream companies like Lightning Labs and ACINQ.

Quote from: marcelbit on December 19, 2017, 11:14:47 PM

b2) Wouldn't it then make sense for most Bitcoin devs and open-source devs in general to patent their software? Which I assume would not be compatible with the spirit of open source, would it?

Patents are not really in the spirit of open source, and anyone who tells you that Blockstream or any Bitcoin Core developer has patented anything related to Bitcoin is lying to you.

Quote from: marcelbit on December 19, 2017, 11:14:47 PM

c) The Lightning Network could impair the decentralisation of Bitcoin. Citation: "To reach anyone in a big network with a series of branching channel connections, you either need a large number of channels [-> users have to divide up their funds and cant do anything except tiny purchases], or a large number of hops [-> everyones money will be tied up routing everybody elses money]."
One conceivable solution: "the system depends on large centralized hubs"

In general, each user will have several open Lightning channels and that should all be handled by the client you are running. Even with several open channels, while each channel may not be able to make a single large purchase, it is possible for you to make a large payment by sending money through multiple channels.

While there may be several large hubs, it certainly does not introduce that much centralization. Hubs can't change the amount of money that you have and can't dictate anything that you do. If a hub is misbehaving, you can simply stop using them and use someone else or just not use LN.

Quote from: marcelbit on December 19, 2017, 11:14:47 PM

d) The feature "Replace By Fee" broke the much more useful (for daily life transactions) feature "Zero-Conf". Zero-Conf would very quickly allow to see that a transaction is triggered. Instead with RBF a receiver of a payment needs to wait until a transaction is really processed by miners in order to be sure that the transaction will be made. Since with RBF a dishonest payer could overwrite a transaction and send it to a different address.

"Zero conf" was never a feature and unconfirmed transactions were never meant to be accepted. It was already fairly easy to double spend an unconfirmed transaction without it signalling RBF. Furthermore, RBF is node policy, not a consensus rule, so even if Bitcoin Core didn't implement it, miners could still enforce RBF by running modified software. With Opt-in RBF (which is what we have now), it is very clear whether a transaction is more likely to be replaced as it explicitly signals that it can be replaced. If you are a merchant, then you can look at such transactions and hold off on accepting the payment. Since Opt-in RBF is opt in, you can just make transactions that don't opt in, and keep in mind that such transactions are still easily double spendable.

Quote from: marcelbit on December 19, 2017, 11:14:47 PM

Further assertion of another author:
e) SegWit could decrease the security of transactions. (https://bitcrust.org/blog-incentive-shift-segwit)

No. That is based on a fundamental misunderstanding of how Segwit works.

Quote from: marcelbit on December 19, 2017, 11:14:47 PM

As far as I understand with SegWit miners could be motivated not to verify transactions securely.

That does not matter. Nodes will reject invalid blocks. Nodes are enforcing the consensus rules (which includes Segwit). If a miner produces a consensus-invalid block because they failed to verify the transactions, then nodes will reject it and that block will not be added to the Bitcoin blockchain.

Quote from: marcelbit on December 19, 2017, 11:14:47 PM

On the other hand:
f) In one video Andreas Antonopoulis explains that just increasing the block size (like Bitcoin Cash) is a too simple, short-term solution. If some day Bitcoin may have tens of thousands of transactions per second the blocks would be in the high gigabyte range - every ten minutes! Which could barely be processed by common nodes and lead to a centralisation trend as with mining today.

That is correct. Just increasing the block size limit is not a feasible long term solution. It is, effectively "kick the can down the road" and "let someone else later deal with it". Increasing the block size limit comes with a lot more consequences than you think it does and there is a whole lot more nuance to increasing Bitcoin's capacity than you think there is.