[Bitcoin-ml] Can we decide on a roadmap now?

Christoph Bergmann christoph.bergmann at mailbox.org
Sun Sep 3 10:12:03 UTC 2017


Imho the roadmap discussion is too much narrowed down on scalability.
Not that this topic is not important, but Bitcoin Cash already enables
8MB blocks, we are optimistic, that the network will survive this, and
there is a lot of space left to fill. So scalability should not be a
pressing issue for the next years. You solved it for now, congratulation.

Thus parallel transaction validation and dynamic blocksize are not
issues to worry / hardfork now. Mallebility fix maybe, if we want to
have LN. If not, we don't need it. Schnorr is nice to have, but since we
scale well and free blockspace is a far better environment for CoinJoin
than a discount in congested blocks, this is no pressing issue.

Since scalability seems to be ok for the next years, it could be worth
more venturing into other areas to make Bitcoin Cash the most attractive
digital cash that is possible. Some examples:

# Multi-client development
While Bitcoin Core is based on one implementation created by many
developers, Bitcoin Cash is build of multiple implementations with less
developers (XT, Classic, BU, ABC, hopefully parity, bcoin and more).
This is a new structure and needs a lot of communication, cooperation,
organization and so on. Is it comparable with the Ubuntus? And will the
different implementation specialize on areas? Will there be a main
consensus implementation defining a minimum set of changes? How can
changes be imported to non c++ implementations? There are a lot of
things to discuss and think about. Maybe a weekly / monthly developer
chat, like Core does, is helpful.

# Payment Protocol
This seems to be a forgotten area, despite high promises in enhancing
usability. TomTomTom and CSW voiced some nice ideas about it, and I
still like the spirit of Mike Hearns announcement of it on bitcointalk.
In the long term the Payment Protocol can have a lot of benefits,
including the introduction of better human readable address replacements
and the revitalizing of pay-to-IP. Also I can imagine integrating
multisig in it to make escrow more easy, or adding op_return messages
encrypted with the public key of the receiver.

# Privacy
The C in Bitcoin Cash stands for Cash. And Cash means anonymity and
privacy. Don't forget this point. Free block space is a major
requirement for blockchain privacy, as it enables a comeback of several
mixing technologies. Could it be possible to use the payment protocol to
integrate coinjoin in the transaction propagation of nodes? Can
JoinMarket be brought back to live? Even Confidential Transactions or
zcash like zero knowledge proofs, a no-go with full blocks, could be
integrated thanks to free block space, and maybe some kb / mb space can
be reserved for such transactions, for which users compete with fees?
(which would help paying for PoW long term)..

# Metalayers
I think you should discuss how to deal with layers on top of Bitcoin,
like Counterparty, Colored Coins etc. Free blockspace will attract them.
This should be up to discuss, but personally I think blockchain capacity
should be restricted to monetary usecases. If a metalayers makes money
better, great. If it does something else (building a blockchain based
market, tracking supply chains with blockchain, building decentralized
poker), bad. Same goes for smart contracts.

# SPV support
Large blocks make running a node harder, and for users a SPV node is
more comfortable anyway. So any reasonable roadmap should heavily care
about how to make SPV and Light Wallets as good as it can be. Bloom
Filters are a clever concept, but they either lose privacy or waste
bandwidth, and they seem to be not compatible with stealth addresses.
Maybe a UTXO-only SPV-wallet could be a good alternative? To get this,
UTXO-commitments and some RPC-call to get the UTXO can be important. But
that's just a blind shot of a non-technical person (me) ...

That's just what spontanously comes to mind. I'm sure there are a lot of
other exciting areas to dig into. I have to admit that I don't know
anything about the technical challenges which come along with these
points. So please excuse me if I wrote some fairy-tale unicorn-wishing
daydreaming bullshit.

Christoph


Am 02.09.2017 um 11:02 schrieb Nagai via bitcoin-ml:
> If you don't have a better idea, I suggest you Feb 1. We can't hard
> fork on December and January, due to Christmas payments.
>
> What should that hard fork bring us?
>
> My suggestions (feel free to criticise) :
>
> Parallel transaction validation
> New difficulty adjustment algorithm
> Simple Malleability Fix
>
> Then we can make another hard fork on Nov 1 2018 / Feb 1 2019
>
> FlexTrans
> Dynamic Blocksize
>
> How about this?
>
>
> _______________________________________________
> bitcoin-ml mailing list
> bitcoin-ml at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml

-- 
Christoph Bergmann
Bitcoinblog.de
christoph.bergmann at mailbox.org
2C18 DD55 1D85 A487 652B 943F 0693 B927 00B1 BAF8

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-ml/attachments/20170903/3ccf86e2/attachment-0001.html>


More information about the bitcoin-ml mailing list