public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
* [bitcoin-dev] Segregated Witness features wish list
@ 2015-12-10  6:47 jl2012
  2015-12-10  8:26 ` Gregory Maxwell
                   ` (4 more replies)
  0 siblings, 5 replies; 13+ messages in thread
From: jl2012 @ 2015-12-10  6:47 UTC (permalink / raw)
  To: bitcoin-dev

It seems the current consensus is to implement Segregated Witness. SW 
opens many new possibilities but we need a balance between new features 
and deployment time frame. I'm listing by my priority:

1-2 are about scalability and have highest priority

1. Witness size limit: with SW we should allow a bigger overall block 
size. It seems 2MB is considered to be safe for many people. However, 
the exact size and growth of block size should be determined based on 
testing and reasonable projection.

2. Deployment time frame: I prefer as soon as possible, even if none of 
the following new features are implemented. This is not only a technical 
issue but also a response to the community which has been waiting for a 
scaling solution for years

3-6 promote safety and reduce level of trust (higher priority)

3. SIGHASH_WITHINPUTVALUE [1]: there are many SIGHASH proposals but this 
one has the highest priority as it makes offline signing much easier.

4. Sum of fee, sigopcount, size etc as part of the witness hash tree: 
for compact proof of violations in these parameters. I prefer to have 
this feature in SWv1. Otherwise, that would become an ugly softfork in 
SWv2 as we need to maintain one more hash tree

5. Height and position of an input as part of witness will allow compact 
proof of non-existing UTXO. We need this eventually. If it is not done 
in SWv1, we could softfork it nicely in SWv2. I prefer this earlier as 
this is the last puzzle for compact fraud proof.

6. BIP62 and OP_IF malleability fix [2] as standardness rules: 
involuntary malleability may still be a problem in the relay network and 
may make the relay less efficient (need more research)

7-15 are new features and long-term goals (lower priority)

7. Enable OP_CAT etc:
OP_CAT will allow tree signatures described by [3]. Even without Schnorr 
signature, m-of-n multisig will become more efficient if m < n.

OP_SUBSTR/OP_LEFT/OP_RIGHT will allow people to shorten a payment 
address, while sacrificing security.

I'm not sure how those disabled bitwise logic codes could be useful

Multiplication and division may still considered to be risky and not 
very useful?

8. Schnorr signature: for very efficient multisig [3] but could be 
introduced later.

9. Per-input lock-time and relative lock-time: define lock-time and 
relative lock-time in witness, and signed by user. BIP68 is not a very 
ideal solution due to limited lock time length and resolution

10. OP_PUSHLOCKTIME and OP_PUSHRELATIVELOCKTIME: push the lock-time and 
relative lock-time to stack. Will allow more flexibility than OP_CLTV 
and OP_CSV

11. OP_RETURNTURE which allows softfork of any new OP codes [4]. It is 
not really necessary with the version byte design but with OP_RETURNTURE 
we don't need to pump the version byte too frequently.

12. OP_EVAL (BIP12), which enables Merkleized Abstract Syntax Trees 
(MAST) with OP_CAT [5]. This will also obsolete BIP16. Further 
restrictions should be made to make it safe [6]:
a) We may allow at most one OP_EVAL in the scriptPubKey
b) Not allow any OP_EVAL in the serialized script, nor anywhere else in 
the witness (therefore not Turing-complete)
c) In order to maintain the ability to statically analyze scripts, the 
serialized script must be the last push of the witness (or script 
fails), and OP_EVAL must be the last OP code in the scriptPubKey

13. Combo OP codes for more compact scripts, for example:

OP_MERKLEHASH160, if executed, is equivalent to OP_SWAP OP_IF OP_SWAP 
OP_ENDIF OP_CAT OP_HASH160 [3]. Allowing more compact tree-signature and 
MAST scripts.

OP_DUPTOALTSTACK, OP_DUPFROMALTSTACK: copy to / from alt stack without 
removing the item

14. UTXO commitment: good but not in near future

15. Starting as a softfork, moving to a hardfork? SW Softfork is a quick 
but dirty solution. I believe a hardfork is unavoidable in the future, 
as the 1MB limit has to be increased someday. If we could plan it ahead, 
we could have a much cleaner SW hardfork in the future, with codes 
pre-announced for 2 years.


[1] https://bitcointalk.org/index.php?topic=181734.0
[2] 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-November/011679.html
[3] https://blockstream.com/2015/08/24/treesignatures/
[4] https://bitcointalk.org/index.php?topic=1106586.0
[5] 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-September/010977.html
[6] https://bitcointalk.org/index.php?topic=58579.msg690093#msg690093


^ permalink raw reply	[flat|nested] 13+ messages in thread
* Re: [bitcoin-dev] Segregated Witness features wish list
@ 2015-12-14 12:32 Adam Back
  2015-12-14 12:50 ` Jonathan Toomim
  0 siblings, 1 reply; 13+ messages in thread
From: Adam Back @ 2015-12-14 12:32 UTC (permalink / raw)
  To: Jonathan Toomim; +Cc: Bitcoin Dev

I think people have a variety of sequences in mind, eg some would
prefer to deploy versionBits first, so that subsequent features can be
deployed in parallel (currently soft-fork deployment is necessarily
serialised).

Others think do seg-witness first because scale is more important.

Some want to do seg-witness as a hard-fork (personally I think that
would take a bit longer to deploy & activate - the advantage of
soft-fork is that it's lower risk and we have more experience of it).

I've seen a few people want to do BIP 102 first (straight move to 2MB
and only that) and then do seg-witness and other scaling work later.
That's possible also and before Luke observed that you could do a
seg-witness based block-size increase via soft-fork, people had been
working following the summary from the montreal workshop discussion
posted on this list about a loose plan of action, people had been
working on something like BIP 102 to 2-4-8 kind of space, plus
validation cost accounting.

So I think personally soft-fork seg-witness first, but hey I'm not
writing code at present and I'm very happy for wiser and more code and
deployment detail aware minds to figure out the best deployment
strategy, I wouldnt mind any of the above, just think seg-witness
soft-fork is the safest and fastest.  The complexity risk - well on
the plus side it is implemented and it reduces deployment risk, and
it's anyway needed work to have a robust malleability fix which is
needed for a whole range of bitcoin smart-contract, and scaling
features, including for example greenAddress like faster transactions
as used by BitPay?, BitGo and GreenAddress as well as lightning
related proposals and basically any smart-contract use that involves
multiple clauses and dependent transactions.  Also re complexity risk
Greg has highlighted that the complexity and overhead difference is
really minor.  About knock on code changes needed, a bunch of the next
steps for Bitcoin are going to need code changes, I think our scope to
improve and scale Bitcoin are going to be severely hampered if we
restricted ourselves with the pre-condition that we cant make protocol
improvements.  I think people in core would be happy to, and have done
this kind of thing multiple times in the past, to help people for free
on volunteer time integrate and fix up related code in various
languages and FOSS and commercial software that is affected.

As to time-line Luke I saw guestimated by march 2016 on reddit.
Others maybe be more or less conservative.  Probably a BIP and testing
are the main thing, and that can be helped by more eyes.  The one
advantage of BIP 102 like proposal is simplicity if one had to do a
more emergency hard-fork.  Maybe companies and power users, miners and
pool operators could help define some requirements and metrics about
an industry wide service level they are receiving relative to fees.

The other thing which is not protocol related, is that companies can
help themselves and help Bitcoin developers help them, by working to
improve decentralisation with better configurations, more use of
self-hosted and secured full nodes, and decentralisation of policy
control over hashrate.  That might even include buying a nominal (to a
reasonably funded startup) amount of mining equipment.  Or for power
users to do more of that.  Some developers are doing mining.
Blockstream and some employees have a little bit of hashrate.  If we
could define some metrics and best practices and measure the
improvements, that would maybe reduce miners concerns about
centralisation risk and allow a bigger block faster, alongside the
IBLT & weak block network protocol improvements.

Adam

On 14 December 2015 at 19:44, Jonathan Toomim via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> 1. I think we should limit the sum of the block and witness data to nBlockMaxSize*7/4 per block, for a maximum of 1.75 MB total. I don't like the idea that SegWit would give us 1.75 MB of capacity in the typical case, but we have to have hardware capable of 4 MB in adversarial conditions (i.e. intentional multisig). I think a limit to the segwit size allays that concern.
>
> 2. I think that segwit is a substantial change to how Bitcoin works, and I very strongly believe that we should not rush this. It changes the block structure, it changes the transaction structure, it changes the network protocol, it changes SPV wallet software, it changes block explorers, and it has changes that affect most other parts of the Bitcoin ecosystem. After we decide to implement it, and have a final version of the code that will be merged, we should give developers of other Bitcoin software time to implement code that supports the new transaction/witness formats.
>
> When you guys say "as soon as possible," what do you mean exactly?
>
> On Dec 10, 2015, at 2:47 PM, jl2012--- via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> It seems the current consensus is to implement Segregated Witness. SW opens many new possibilities but we need a balance between new features and deployment time frame. I'm listing by my priority:
>>
>> 1-2 are about scalability and have highest priority
>>
>> 1. Witness size limit: with SW we should allow a bigger overall block size. It seems 2MB is considered to be safe for many people. However, the exact size and growth of block size should be determined based on testing and reasonable projection.
>>
>> 2. Deployment time frame: I prefer as soon as possible, even if none of the following new features are implemented. This is not only a technical issue but also a response to the community which has been waiting for a scaling solution for years


^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2015-12-14 12:50 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-12-10  6:47 [bitcoin-dev] Segregated Witness features wish list jl2012
2015-12-10  8:26 ` Gregory Maxwell
2015-12-10  8:28 ` Bryan Bishop
2015-12-10  9:51 ` Gregory Maxwell
2015-12-13 15:25   ` jl2012
2015-12-13 18:07     ` Pieter Wuille
2015-12-13 18:41       ` jl2012
2015-12-10 12:54 ` Tamas Blummer
2015-12-12  0:43   ` Jannes Faber
2015-12-13 20:34     ` Rusty Russell
2015-12-14 11:44 ` Jonathan Toomim
2015-12-14 12:32 Adam Back
2015-12-14 12:50 ` Jonathan Toomim

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox