Forking Features

[xeroc]

For my savings I'd like to see Lamport Signaturs to secure against broken ECC
https://bitcointalk.org/index.php?topic=262694.0

[Troglodactyl]

...
All of that said I think BTSX will gain more from feature stability with perhaps annual updates after massive test nets than it will from rapid addition of features.

This.

I started this mainly to encourage people to think about the features they want that require forks in terms of getting them scheduled well in advance for more infrequent updates.  Once no hard forks are needed to fix anything that's broken, I think hard forks should be rare. Once enough features have accumulated to justify a fork, it's just a matter of getting as much progress into it as possible, limited by the number of features that can be completed and thoroughly tested in time.

[GaltReport]

Some features I can think of off the top of my head which I am not sure if they are already in the code yet or will require a future fork:

• Changing votes with BTSX held as collateral in short position.
• Attaching arbitrary(?) length messages in a transaction to another account beyond the small memo field (both encrypted and plain-text versions). Is this still planned?
• Public balances for accounts (although this may already be possible on the blockchain without a fork).

And then there is of course the nearly endless items on my personal wishlist that will either not happen or it will be a long time before they do happen:

• Restructure block headers to implement lightweight client verification.
• Delegate proposals with shareholder ratification where the ratified proposals modify the rules of the DAC. This includes all the wonderful features that come along with it such as: inflation caps, BitAsset yield rate caps, workers, hard-fork proposals, etc.
• Cover short position through a BitAsset market buy order using collateral in short position as payment.
• A fair and monotonic BitAsset yield distribution (linear interest is fine if continuous compounding complicates the implementation too much).
• Automatic conversion of network fees using internal exchanges to get DAC revenue in the form of the BitAsset/BTSX desired for either payment to delegates/workers or payment to BitAsset yields.
• Time-based multisig where spending a transaction requires a 2-of-3 multsig between t0 <= t < t0 + 6 months, and a 1-of-1 sig can be used in addition to the 2-of-3 multisig after t >= t0 + 6 months. This allows for beneficiaries to claim the funds of a deceased benefactor after 6 months of inactivity.
• Allow delegates to take a vacation / retire from their delegate role and take back a percentage of their submitted delegate registration fee (called the surety bond portion), and if they want to go back to being a valid delegate candidate, they need to repost that surety bond. Then, the DAC should allow anyone to submit proof of a double-sign of a block by an active delegate to the blockchain which will automatically ban that delegate and claim the surety bond as revenue for the DAC. This increases the opportunity cost of misbehaving for any active delegate who is tired of being a delegate and wants to quit anyway.
• Separation of private keys to update BTSX votes and transfer BTSX stake. This allows for keeping the vote updating keys on the hot client while keeping the keys controlling the movement of the funds safely in cold storage.
• Implementation of BTSX yield (similar to BitAsset yield) instead of the current buyback mechanism for providing shareholder dividends in order to financially incentivize updates of votes by, for example, withholding yields on BTSX balances that have not moved for over a year. Potentially a 5% inactivity fee on balances that haven't been updated for a year could work as substitute.
• An inactivity fee on BitAssets and BTSX (regardless of the above point) to reclaim value lost due to missing private keys. Lost BitAsset value cannot be claimed by letting the market factor it in (it could only act as a black swan fund). While lost BTSX could be factored in by the market in the price of BTSX, it is better to be 100% sure it is lost by just claiming old inactive funds. I suggest not touching balances with less than 5 years of inactivity, and then claiming 100% of the funds by year 6 starting with 0% claimed at the beginning of year 5 and interpolating linearly with time.
  
• Many more...

Quite the list you have there...

I could add a dozen more hard-fork features...
1) Using BitAssets as collateral for shorts
2) Allowing reverse shorting (BTSX... etc)
3) Allow publishing of price feeds in USD per GLD to reduce update frequency compared to BTSX vs GLD...
4) Ring Signatures like Crypto-Note...

All of that said I think BTSX will gain more from feature stability with perhaps annual updates after massive test nets than it will from rapid addition of features.

+100% (exception being features that provide SIGNIFICANT increase in BitAsset usability/marketability).

[arhag]

1) Using BitAssets as collateral for shorts
2) Allowing reverse shorting (BTSX... etc)

I still haven't understood the purpose behind those two. There was some hand-wavy explanation about market symmetry, but I don't quite understand why this is necessary. Also, would we need a fixed 300% reserve requirement even when shorting BitUSD with BitCNY for example? Seems way overkill considering the relatively small volatility between USD and CNY (or any national currency pairs). So, then do we want different minimum collateral ratios for each BitAsset pair? Seems to get complicated fast, and again I don't really get what problem it is supposed to solve.

3) Allow publishing of price feeds in USD per GLD to reduce update frequency compared to BTSX vs GLD...

Oh yeah, that is pretty clever. It goes back to the relative volatility comment I made above. Ideally we only need one rapid price feed for BTSX vs some other relatively stable asset like Gold, then everything else can be a slower price feed for X vs Gold (where X is USD, CNY, EUR, SLV, WTI, etc.).

4) Ring Signatures like Crypto-Note...

That would be really amazing. I wonder how it affects performance? And I would imagine it significantly complicates the lightweight client implementation. The client would have to somehow (trust required?) get a list of valid public keys it can hide within to protect the user's privacy. I would love to see this feature but I imagine it will be quite a while before it happens.

Also, another feature along the same lines are the ring signatures you previously mentioned to implement legally compliant (but still privacy respecting) cryptostocks. Although that is more likely to be in a separate DAC launched explicitly for that purpose rather than a future mandatory upgrade of BitShares X.

All of that said I think BTSX will gain more from feature stability with perhaps annual updates after massive test nets than it will from rapid addition of features.

I agree. Although I think there are a few really important features (other than stability and fixing bugs) that BitShares X needs as soon as possible. This includes mostly things that are purely on the client side (user-friendly multisig and cold storage with offline transaction signing) as well as the one big hard-fork change to get lightweight clients working (which will also be essential to the critical task of creating a secure mobile client). And some of these require setting up some infrastructure (risk-management companies to sign the multisig transactions and the mail server infrastructure to reliably inform the user of new incoming transactions as well as perhaps facilitating the secure transfer of partially signed transactions for various multisig parties to sign). With these in place (as well as easy on-ramps/off-ramps and a beautiful user-friendly client available on Windows, Mac OS X, iOS, Android, and the web browser) BitShares X might finally be ready to be adopted by the larger population of non-tech-savvy investors/consumers. All the other awesome features can then come later, ideally funded quickly by rapid growth in the value of BTSX.

[BldSwtTrs]

Some features I can think of off the top of my head which I am not sure if they are already in the code yet or will require a future fork:

• Changing votes with BTSX held as collateral in short position.
• Attaching arbitrary(?) length messages in a transaction to another account beyond the small memo field (both encrypted and plain-text versions). Is this still planned?
• Public balances for accounts (although this may already be possible on the blockchain without a fork).

And then there is of course the nearly endless items on my personal wishlist that will either not happen or it will be a long time before they do happen:

• Restructure block headers to implement lightweight client verification.
• Delegate proposals with shareholder ratification where the ratified proposals modify the rules of the DAC. This includes all the wonderful features that come along with it such as: inflation caps, BitAsset yield rate caps, workers, hard-fork proposals, etc.
• Cover short position through a BitAsset market buy order using collateral in short position as payment.
• A fair and monotonic BitAsset yield distribution (linear interest is fine if continuous compounding complicates the implementation too much).
• Automatic conversion of network fees using internal exchanges to get DAC revenue in the form of the BitAsset/BTSX desired for either payment to delegates/workers or payment to BitAsset yields.
• Time-based multisig where spending a transaction requires a 2-of-3 multsig between t0 <= t < t0 + 6 months, and a 1-of-1 sig can be used in addition to the 2-of-3 multisig after t >= t0 + 6 months. This allows for beneficiaries to claim the funds of a deceased benefactor after 6 months of inactivity.
• Allow delegates to take a vacation / retire from their delegate role and take back a percentage of their submitted delegate registration fee (called the surety bond portion), and if they want to go back to being a valid delegate candidate, they need to repost that surety bond. Then, the DAC should allow anyone to submit proof of a double-sign of a block by an active delegate to the blockchain which will automatically ban that delegate and claim the surety bond as revenue for the DAC. This increases the opportunity cost of misbehaving for any active delegate who is tired of being a delegate and wants to quit anyway.
• Separation of private keys to update BTSX votes and transfer BTSX stake. This allows for keeping the vote updating keys on the hot client while keeping the keys controlling the movement of the funds safely in cold storage.
• Implementation of BTSX yield (similar to BitAsset yield) instead of the current buyback mechanism for providing shareholder dividends in order to financially incentivize updates of votes by, for example, withholding yields on BTSX balances that have not moved for over a year. Potentially a 5% inactivity fee on balances that haven't been updated for a year could work as substitute.
• An inactivity fee on BitAssets and BTSX (regardless of the above point) to reclaim value lost due to missing private keys. Lost BitAsset value cannot be claimed by letting the market factor it in (it could only act as a black swan fund). While lost BTSX could be factored in by the market in the price of BTSX, it is better to be 100% sure it is lost by just claiming old inactive funds. I suggest not touching balances with less than 5 years of inactivity, and then claiming 100% of the funds by year 6 starting with 0% claimed at the beginning of year 5 and interpolating linearly with time.
  
• Many more...

Quite the list you have there...

I could add a dozen more hard-fork features...
1) Using BitAssets as collateral for shorts
2) Allowing reverse shorting (BTSX... etc)
3) Allow publishing of price feeds in USD per GLD to reduce update frequency compared to BTSX vs GLD...
4) Ring Signatures like Crypto-Note...

All of that said I think BTSX will gain more from feature stability with perhaps annual updates after massive test nets than it will from rapid addition of features.

Adoption of Ring Signatures would get BTSX a lot attention from the BTC and altcoins communities.

[bytemaster]

Some features I can think of off the top of my head which I am not sure if they are already in the code yet or will require a future fork:

• Changing votes with BTSX held as collateral in short position.
• Attaching arbitrary(?) length messages in a transaction to another account beyond the small memo field (both encrypted and plain-text versions). Is this still planned?
• Public balances for accounts (although this may already be possible on the blockchain without a fork).

And then there is of course the nearly endless items on my personal wishlist that will either not happen or it will be a long time before they do happen:

• Restructure block headers to implement lightweight client verification.
• Delegate proposals with shareholder ratification where the ratified proposals modify the rules of the DAC. This includes all the wonderful features that come along with it such as: inflation caps, BitAsset yield rate caps, workers, hard-fork proposals, etc.
• Cover short position through a BitAsset market buy order using collateral in short position as payment.
• A fair and monotonic BitAsset yield distribution (linear interest is fine if continuous compounding complicates the implementation too much).
• Automatic conversion of network fees using internal exchanges to get DAC revenue in the form of the BitAsset/BTSX desired for either payment to delegates/workers or payment to BitAsset yields.
• Time-based multisig where spending a transaction requires a 2-of-3 multsig between t0 <= t < t0 + 6 months, and a 1-of-1 sig can be used in addition to the 2-of-3 multisig after t >= t0 + 6 months. This allows for beneficiaries to claim the funds of a deceased benefactor after 6 months of inactivity.
• Allow delegates to take a vacation / retire from their delegate role and take back a percentage of their submitted delegate registration fee (called the surety bond portion), and if they want to go back to being a valid delegate candidate, they need to repost that surety bond. Then, the DAC should allow anyone to submit proof of a double-sign of a block by an active delegate to the blockchain which will automatically ban that delegate and claim the surety bond as revenue for the DAC. This increases the opportunity cost of misbehaving for any active delegate who is tired of being a delegate and wants to quit anyway.
• Separation of private keys to update BTSX votes and transfer BTSX stake. This allows for keeping the vote updating keys on the hot client while keeping the keys controlling the movement of the funds safely in cold storage.
• Implementation of BTSX yield (similar to BitAsset yield) instead of the current buyback mechanism for providing shareholder dividends in order to financially incentivize updates of votes by, for example, withholding yields on BTSX balances that have not moved for over a year. Potentially a 5% inactivity fee on balances that haven't been updated for a year could work as substitute.
• An inactivity fee on BitAssets and BTSX (regardless of the above point) to reclaim value lost due to missing private keys. Lost BitAsset value cannot be claimed by letting the market factor it in (it could only act as a black swan fund). While lost BTSX could be factored in by the market in the price of BTSX, it is better to be 100% sure it is lost by just claiming old inactive funds. I suggest not touching balances with less than 5 years of inactivity, and then claiming 100% of the funds by year 6 starting with 0% claimed at the beginning of year 5 and interpolating linearly with time.
  
• Many more...

Quite the list you have there...

I could add a dozen more hard-fork features...
1) Using BitAssets as collateral for shorts
2) Allowing reverse shorting (BTSX... etc)
3) Allow publishing of price feeds in USD per GLD to reduce update frequency compared to BTSX vs GLD...
4) Ring Signatures like Crypto-Note...

All of that said I think BTSX will gain more from feature stability with perhaps annual updates after massive test nets than it will from rapid addition of features. 

[arhag]

Some features I can think of off the top of my head which I am not sure if they are already in the code yet or will require a future fork:

• Changing votes with BTSX held as collateral in short position.
• Attaching arbitrary(?) length messages in a transaction to another account beyond the small memo field (both encrypted and plain-text versions). Is this still planned?
• Public balances for accounts (although this may already be possible on the blockchain without a fork).

And then there is of course the nearly endless items on my personal wishlist that will either not happen or it will be a long time before they do happen:

• Restructure block headers to implement lightweight client verification.
• Delegate proposals with shareholder ratification where the ratified proposals modify the rules of the DAC. This includes all the wonderful features that come along with it such as: inflation caps, BitAsset yield rate caps, workers, hard-fork proposals, etc.
• Cover short position through a BitAsset market buy order using collateral in short position as payment.
• A fair and monotonic BitAsset yield distribution (linear interest is fine if continuous compounding complicates the implementation too much).
• Automatic conversion of network fees using internal exchanges to get DAC revenue in the form of the BitAsset/BTSX desired for either payment to delegates/workers or payment to BitAsset yields.
• Time-based multisig where spending a transaction requires a 2-of-3 multsig between t0 <= t < t0 + 6 months, and a 1-of-1 sig can be used in addition to the 2-of-3 multisig after t >= t0 + 6 months. This allows for beneficiaries to claim the funds of a deceased benefactor after 6 months of inactivity.
• Allow delegates to take a vacation / retire from their delegate role and take back a percentage of their submitted delegate registration fee (called the surety bond portion), and if they want to go back to being a valid delegate candidate, they need to repost that surety bond. Then, the DAC should allow anyone to submit proof of a double-sign of a block by an active delegate to the blockchain which will automatically ban that delegate and claim the surety bond as revenue for the DAC. This increases the opportunity cost of misbehaving for any active delegate who is tired of being a delegate and wants to quit anyway.
• Separation of private keys to update BTSX votes and transfer BTSX stake. This allows for keeping the vote updating keys on the hot client while keeping the keys controlling the movement of the funds safely in cold storage.
• Implementation of BTSX yield (similar to BitAsset yield) instead of the current buyback mechanism for providing shareholder dividends in order to financially incentivize updates of votes by, for example, withholding yields on BTSX balances that have not moved for over a year. Potentially a 5% inactivity fee on balances that haven't been updated for a year could work as substitute.
• An inactivity fee on BitAssets and BTSX (regardless of the above point) to reclaim value lost due to missing private keys. Lost BitAsset value cannot be claimed by letting the market factor it in (it could only act as a black swan fund). While lost BTSX could be factored in by the market in the price of BTSX, it is better to be 100% sure it is lost by just claiming old inactive funds. I suggest not touching balances with less than 5 years of inactivity, and then claiming 100% of the funds by year 6 starting with 0% claimed at the beginning of year 5 and interpolating linearly with time.
  
• Many more...

[bytemaster]

Excellent!

So I guess the only remaining planned fork now is for switching from collateral to interest for shorts?

Yes

[Troglodactyl]

Excellent!

So I guess the only remaining planned fork now is for switching from collateral to interest for shorts?

[hpenvy]

Blockchain supports multisig, wallet does not

Thank you.

[toast]

Blockchain supports multisig, wallet does not

[Troglodactyl]

It is already there no fork required

I remember seeing a developer on here mentioned we weren't able to do Open Bazaar because we lacked multi sig. Am I confusing something? If so, I apologize.

He probably means the interest payments are already there, in which case multi sig would be the only remaining change I know of that will require a fork.

Are there any others already planned?

[hpenvy]

It is already there no fork required

I remember seeing a developer on here mentioned we weren't able to do Open Bazaar because we lacked multi sig. Am I confusing something? If so, I apologize.

[bytemaster]

It is already there no fork required

[Troglodactyl]

What features besides multi sig and payments from shorts to longs are on the list that require a fork?  To minimize forking updates, I think we should get them all listed here and try to bundle them as much as possible.

Is it plausible that multi sig could be ready in time to roll out with short interest payments?