<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
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.<br>
<br>
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.<br>
<br>
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:<br>
<br>
# Multi-client development<br>
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.<br>
<br>
# Payment Protocol<br>
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.<br>
<br>
# Privacy<br>
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)..<br>
<br>
# Metalayers<br>
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. <br>
<br>
# SPV support<br>
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) ...<br>
<br>
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.<br>
<br>
Christoph<br>
<br>
<br>
<div class="moz-cite-prefix">Am 02.09.2017 um 11:02 schrieb Nagai
via bitcoin-ml:<br>
</div>
<blockquote type="cite"
cite="mid:iyn7u2T1efpvzgjbwEXWpfjxRYrZ3n26Qd2rgIna2D7qezCD4_ORg-cE-lYO9uHN9Rl1ig0LCyR_etJYEI0S8Tif-5QD8Me5FA65YQTr6HE=@protonmail.ch">
<div>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.<br>
</div>
<div><br>
</div>
<div>What should that hard fork bring us?<br>
</div>
<div><br>
</div>
<div>My suggestions (feel free to criticise) :<br>
</div>
<div><br>
</div>
<div>Parallel transaction validation<br>
</div>
<div>New difficulty adjustment algorithm<br>
</div>
<div>Simple Malleability Fix<br>
</div>
<div><br>
</div>
<div>Then we can make another hard fork on Nov 1 2018 / Feb 1 2019<br>
</div>
<div><br>
</div>
<div>FlexTrans<br>
</div>
<div>Dynamic Blocksize<br>
</div>
<div><br>
</div>
<div>How about this?</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
bitcoin-ml mailing list
<a class="moz-txt-link-abbreviated" href="mailto:bitcoin-ml@lists.linuxfoundation.org">bitcoin-ml@lists.linuxfoundation.org</a>
<a class="moz-txt-link-freetext" href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Christoph Bergmann
Bitcoinblog.de
<a class="moz-txt-link-abbreviated" href="mailto:christoph.bergmann@mailbox.org">christoph.bergmann@mailbox.org</a>
2C18 DD55 1D85 A487 652B 943F 0693 B927 00B1 BAF8</pre>
</body>
</html>