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

Jan Nightingale turifex at protonmail.ch
Sun Sep 3 15:35:58 UTC 2017


>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?

Yes, absolutely!
In fact with signature aggregation there's going to be an added bonus of making transactions substantially smaller by that :) 32 bytes per input->output pair on the margin.
Every participant would have to be online and communicate. I was thinking of something like this:
- user sends a transaction, but is willing to wait for privacy/fee reasons, so he clicks a checkbox titled 'P2P transaction compression' or something
- his wallet starts communicating with other wallets/nodes interested in joining
- every 10 minutes (?) a coalesced transaction is finalized and broadcast

Theoretically for 8MB that could lead to ~250k 1->1 transactions in one block

> -------- Original Message --------
> Subject: Re: [Bitcoin-ml] Can we decide on a roadmap now?
> Local Time: September 3, 2017 12:12 PM
> UTC Time: September 3, 2017 10:12 AM
> From: bitcoin-ml at lists.linuxfoundation.org
> To: bitcoin-ml at lists.linuxfoundation.org
>
> 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/d5a4edd6/attachment-0001.html>


More information about the bitcoin-ml mailing list