Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - theoretical

Pages: 1 [2] 3 4
16

When BitUSD first launched, BitShares had an unrestricted short pricing policy whereby shorts were not charged interest and could be placed at any price.  This can be viewed as shorts competing by offering a discount to BitUSD buyers, with the largest discount orders getting filled first.

However, the unrestricted short pricing policy was later ended because a lop-sided market [1] was causing the discounts to be so large that they were effectively breaking the peg.

Currently, shorts only execute at the feed price, and compete based on the interest rate they offer.

These schemes both consist of shorts offering something to longs.  However there are two key differences:

- With unrestricted short pricing, the bid that matches the short gets the benefit.  With the current short interest implementation, the interest paid by the shorts is spread evenly across all BitUSD holders.
- With unrestricted short pricing, the shorter pays the BitUSD holder immediately.  With the current short interest implementation, the shorts pay the longs over time.

I'll discuss the implications, and possible design modifications, in a future post.

[1] In this case, many more BTS bulls were shorting the dollar than BTS bears buying BitUSD.

17
Stakeholder Proposals / Proposal: Coordinate mandatory upgrades on-chain
« on: November 14, 2014, 03:43:29 pm »

Currently, mandatory upgrades [1] are implemented by updated clients changing semantics on a hard coded block number.

This has the disadvantage that non-updated clients aren't aware of the upgrade taking place, rather they eventually see all delegates signing off on a malformed chain when the new semantics eventually allow a previously invalid transaction.

I propose allowing delegates to publish the following transaction types:

    wallet_delegate_propose_upgrade upgrade_name upgrade_id upgrade_quorum proposal_expiration_block upgrade_effective_block
    wallet_delegate_support_upgrade upgrade_id

upgrade_id is the hash of a JSON object hard-coded in updated clients, specifying the upgrade's parameters.

    blockchain_get_upgrade_support upgrade_id

The upgrade process then looks like this:

- Developers create code to implement new semantics
- Developers create upgrade_id
- upgrade_quorum is the number of delegates which need to sign the upgrade (usually 51)
- After proposal_expiration_block passes, wallet_delegate_support_upgrade operations on this upgrade_id become invalid
- upgrade_effective_block is the block when the new semantics go into effect

Currently checking whether an upgrade is enabled is done by statements like this:

    if( pending_block_num == BTS_V0_4_17_FORK_BLOCK_NUM )
    if( pending_block_num > BTS_V0_4_21_FORK_BLOCK_NUM )

The hardcoded constant BTS_Vx_y_z_FORK_BLOCK_NUM will simply be replaced by get_upgrade_effective_block(upgrade_id).

The get_upgrade_effective_block() function will be the upgrade_effective_block if at least upgrade_quorum delegates issued wallet_delegate_support_upgrade transactions before the proposal_expiration_block.

[1] "Mandatory upgrade" is preferred to "hardfork" for marketing reasons.

18
General Discussion / VerSum: Verifiable Computations over Large Public Logs
« on: November 13, 2014, 04:32:27 pm »
An interesting paper on a new data structure [1] was mentioned on HN [2].

If I read this right, it's a cheap challenge-response protocol for verifying a node performed a computation honestly.

I picture this as being able to potentially solve the "every node must compute every instruction of every transaction" scalability issue with Turing-complete Ethereum-like networks.

The core design idea I had was to publicly post the result of some computation, then if any nodes disagree they can challenge.  In a challenge, both sides post a bond, then you run the challenge-response protocol in the paper on the blockchain.  The loser forfeits their bond.

You could have a standing bond attached to the posted result which will be forfeit on any successful challenge.  You could have every standing bond accumulate inflationary shares proportional to its size, thus incentivizing people to certify third-party computations by bonding their funds to those results.  You should independently verify the computation before posting such a bond, however, since if you post your bond to an incorrect result then you will lose the bond because someone will be able to successfully challenge you.

I'm not sure how feasible any of this is in practice, I just wanted to post about some of the ways this paper directed my thoughts.

[1] http://people.csail.mit.edu/nickolai/papers/vandenhooff-versum.pdf

[2] https://news.ycombinator.com/item?id=8598244

19
General Discussion / UI / UX idea for account registration
« on: November 12, 2014, 12:39:14 am »

Much discussion has been devoted to the user account registration experience [1].

I propose the following:  On the account page for an unregistered account, there should be a space for the user to enter a registration provider's domain, and click "Register with this provider".

If btsregprovider.example.com is the domain name the user enters, then the "Register with this provider" button should open the OS's web browser to a webpage like:

https://btsregprovider.example.com/bts-register-acct?name=bob&pubkey=XTS7YjtxhJJaWHKo8hrJMwjtHkAFhLyxibgzpjDSwa2jpJb1y1WTb

where the name "bob" and the pubkey are filled in by the client.  Then the btsregprovider.com can do any user validation they desire.  When btsregprovider.example.com has decided the user is legitimate, the provider simply registers the account on the blockchain [2] and directs the user to return to the wallet.

Since the GUI wallet is browser based, we don't even need the OS browser -- we could simply load the https://btsregprovider.example.com/bts-register-acct URL in the wallet GUI.  But this would provide a number of potential attack vectors to a malicious registration provider; the security implications would need to be carefully considered.

[1] https://bitsharestalk.org/index.php?topic=11087.0

[2] The provider can register an account for the user without knowing the user's private key by adding the user as a contact account:

wallet_add_contact_account bob "XTS7YjtxhJJaWHKo8hrJMwjtHkAFhLyxibgzpjDSwa2jpJb1y1WTb"
wallet_account_register bob btsregprovider

20

For those of us who build from source, using git as intended to update old directories instead of cloning afresh each time, you may be getting this error message:

Code: [Select]
Unable to checkout '27ac054883f1ddfd2853e2439209171f3abe6853' in submodule path 'libraries/fc'

The reason is that the URL for the FC library has been updated from https://github.com/InvictusInnovations/fc to https://github.com/bitshares/fc

The .gitmodules should take care of fresh clones, but older clones may have to manually update the URL as follows:

Code: [Select]
cd libraries/fc
git remote set-url origin https://github.com/bitshares/fc.git
cd ../..
git submodule update

21

Obviously the forums are great.  But they're less than ideal for communicating important messages:

- There are a lot of subforums that fragment everything
- People tend to stop re-reading the sticky titles on every visit, so new stickies are hard to notice
- There's often good back-and-forth Q&A and discussion between community members and developers, but insightful posts tend to get buried in pages of people giving their +5% or general chatter

We've discussed various ways of improving our communication in the past.  I'm thinking we should have three different channels aimed at different groups:

- End-user announcements:  Announcements of policy changes and mandatory upgrades.  Tell end-users and delegates about changes that will directly affect them.
- Development announcements:  Discussion of planned features, changes to the long-term road map, and development activities.  Keep community members involved in development and I3 members working remotely informed.
- Marketing blog:  Discussion of current BitShares features, project philosophy, the rationale for changes, and How To explanations.  Explain all the goodness of BitShares to casual BitShares users who might not be aware of all our features, and crypto-enthusiasts considering getting involved in the BitShares ecosystem.

End-user announcements sort of exists as a sticky at https://bitsharestalk.org/index.php?topic=7067.0 however, when we implement changes to short mechanics, users also want to know the details of the new rules.  So something like e.g. https://bitsharestalk.org/index.php?topic=9521.msg125135 (note:  illustrative purposes only, the content of this post is out of date) should be included in the announcement.

The marketing blog already basically exists at http://bitshares.org/blog/

As for development announcements, Github tickets are useful for tracking individual implementation issues but aren't as useful at providing a big picture.  For example, the Github tickets show what kinds of bugs are being worked on related to BitShares Mail, but developers who aren't privy to I3 internal discussions are likely wondering about the overall design and vision of BitShares Mail.

This is just my personal opinion and doesn't reflect any I3 consensus.

22
General Discussion / If you just moderated my post, please send me a PM
« on: November 05, 2014, 05:12:14 pm »
I just made a post that seems to have gotten lost.  If this was due to moderator action instead of a forum software hiccup, please PM me.  If I don't hear from a mod, I'll repost it.

23
General Discussion / Proposed UIA changes for mid-November upgrade
« on: October 31, 2014, 08:24:39 pm »

EDIT:  Could we get a comment from bytemaster or vikram on the UIA changes implemented for https://github.com/BitShares/bitshares/issues/826 ?

24
General Discussion / drltc's User Issued Asset Proposal
« on: October 26, 2014, 06:35:24 pm »

We are exploring the possibility of reducing the fee for user-created assets when we merge the chains.  bytemaster has expressed openness to reducing the fee to 10 BTSX or even less.  In this post, I would like to address the implications of such a policy.

Disclaimer:  While I am now officially a member of the I3 team, this post has not yet been adopted as an official I3 policy.  As of this writing, we have not yet reached internal consensus at I3 about how to handle the issues I raise in this post.

In terms of network resources, processing user-created asset transactions costs no more or less than processing transactions for built-in BitAssets. From a technical standpoint, implementing issuing, transferring, and market matching of bids/asks for user-created digital tokens already exists in the code.  Reducing the fee charged for these transactions to reflect their cost to the network will encourage new applications and keep someone from forking BitShares and "eating our lunch".

The main problem is that currently user-issued assets and built-in assets live in a shared global namespace.  I think the cleanest way to deal with the problem is to separate the system into two parts.  (1) Internally, each asset should have a unique identifier, a hex string which is the hash of a JSON "asset descriptor" object describing the purpose of the asset, how many are issued, etc.  (2) Then we should provide a mapping mechanism allowing names in a more human-friendly namespace to be mapped to asset descriptor hashes.

Under the mapping mechanism, short or memorable names in the namespace are scarce resources.  A market-based mechanism is the best way to discover their value.  Fortunately, in the merged chain we are already planning to implement a market mechanism allowing price discovery for allocation of names in a namespace -- that is the entire purpose of DNS / KeyID.

I propose the following mapping mechanism:

- All one-to-four character entries in the global namespace come into existence as market-based assets when a majority of delegates publish an asset descriptor indicating their support.
- Five or more character entries belong to the owner of the corresponding .coin domain and are allocated by the DNS auction process.
- Per-account entries such as drltc.titan/mytoken can be allocated to the owner of the corresponding TITAN account.
- .coin URL's such as drltc.coin/mytoken can be allocated to the owner of the corresponding .coin domain.

Each of these namespaces serves a different market.  One-to-four character entries are likely the same as real-world stocks and commodities. The cost and setup time is high -- adding a token requires convincing a majority of delegates to support it.

Five-or-more character entries are usable by people who want tokens inscribed with their brand.  The cost and setup time is medium -- they must obtain a DNS name, which is substantially less difficult than convincing 51 delegates, but substantially more time-consuming and expensive than a single transaction fee.

Per-account or TLD entries are most suitable for small experiments or private-issue tokens.  For these applications, branding is not a concern so long as the coin has *some* human-readable, globally unique identifier.  Speedy turnaround time and low cost are still desirable.  The cost and setup time is small -- simply paying a transaction fee.

For simplicity of implementation, the name-to-asset-descriptor mapping should only be mutable if all tokens have been burned.

On Friday, at I3 we internally discussed an idea based on a hard-coded list of one-to-four letter names representing real-world stocks and commodities.  Upon reflection, I've come to believe that such a scheme is inherently brittle, essentially requiring a hardfork if the hard-coded list is incomplete.

25
General Discussion / drltc is joining the BitShares team
« on: October 21, 2014, 03:51:32 pm »

In response to my previous thread [1], Toast invited me to come hang out with the BitShares team for a week in real life.  bytemaster invited me to join the BitShares team, and I accepted.

I'm impressed with the team's potential, and things will only get better with me on board.  Despite recent market movements, great things are ahead for BitShares!

[1] https://bitsharestalk.org/index.php?topic=9899.msg128766

26

I think that it should, in principle, be possible to run BitShares on a completely open source system where the user could theoretically audit the source code of any component.  In particular, there should be no closed-source or pre-compiled components in the BitShares toolkit itself.  The BitShares Toolkit should allow users to audit every line of code that could potentially gain access to the private keys controlling their funds.

Of course, if some individual user want to make an individual choice based on individual convenience / security tradeoff preferences, they should also be free to choose to trust OS vendors, binary package repos, PPA's, precompiled binaries, etc.

There is a binary blob in the BitShares toolkit source tree at https://github.com/BitShares/bitshares_toolkit/tree/c58b14c6dc923929368022af6c1c54a45b67dc2f/CrashRpt/bin.  This binary blob is apparently used for crash reporting functionality.  I requested it to be removed.  This request was overruled; see https://github.com/BitShares/bitshares_toolkit/issues/658.  (However, the dependency was made optional in the build.)  The issue has not been revisited in approximately two months since then.  I'm starting this thread to discuss why it's still there and try to build consensus about how to satisfy the goal of making the source code (in principle) more auditable by (if possible) removing the binary blobs.

What is stopping us from managing this CrashRpt dependency the same way we manage OpenSSL dependency?  We don't put precompiled OpenSSL binaries in the source tree.  Instead we have DLL's, so's or statically linked libraries that come from somewhere else (the package manager on Ubuntu; I'm not really sure what Windows and Mac do, perhaps they require the user to separately, perhaps manually, download and compile OpenSSL from source?).

What is stopping us from managing this CrashRpt dependency the same way we manage LevelDB dependency?  We don't put precompiled LevelDB binaries in the source tree.  Instead we have the LevelDB source code in a submodule, and its build is integrated with the main project's build.

27
General Discussion / NewShares: "Testnet for economics"
« on: October 12, 2014, 10:38:05 pm »

BTSX has shown there are two problems with traditional testnets:

- Usage of testnet is very light, problems often don't surface until features hit mainnet
- Testnet can test mechanics, but can't test economics

Both of these are due to the fact that testnet coins have no value.  I'm thinking of fixing this as follows:

- Create a new DAC called DevShares.  DevShares have permanent value; every two months there is a scheduled hardfork that adds new features.
- Create another new DAC called NewShares.  A NewShares network includes bleeding-edge features and may be frequently hardforked (like BTSX shortly after BitUSD release).

NewShares is a "tempnet":  It has a finite lifetime like a testnet.  But unlike a testnet, NewShares shutdown time is hard coded from launch.  Honest NewShares clients will stop accepting blocks after the hardcoded shutdown time, which will be approximately a week before the next DevShares hardfork.  NewShares is snapshotted at the last block, and (inflationary) DevShares are issued to all NewShares holders.  Thus, another difference between NewShares and a testnet is that NewShares are intended to have a nonzero value (because NewShares represent the right to receive DevShares in the near future, which will have nonzero value provided DevShares themselves have nonzero value).

After a NewShares shutdown, a new genesis block for a new NewShares network may be issued.  (The new genesis block's height field will continue after the previous NewShares net's final block field, which may make certain implementation issues easier.)

So basically features go from testnet -> NewShares -> DevShares -> stable DAC's, where "stable DAC's" are BTSX, DNS, Music, etc.

Even though the NewShares network is temporary like a testnet, the economics of NewShares will hopefully be realistic because NewShares will be converted into DevShares which have permanent value.  DevShares must be a new DAC because its inflationary model is different, and existing DAC's have already made promises to investors about their inflation model.

DevShares will themselves have substantial value because their feature set will be updated much faster than BTSX.  With the DAC "business delegate" model, some of DevShares' value can be siphoned off to support development.  Also we can airdrop genesis block NewShares on each NewShares tempnet to holders of other DAC's that support the business delegate model.  This encourages wide participation in NewShares and DevShares, and (quite indirectly) funds development:  The regular airdrops to DAC's that support the business delegate model may increase the price of those DAC's.

Basically the purpose of NewShares is to allow trying out features and economic experiments without having to commit to supporting them forever, or risking the entire market cap of BTSX on some unproven concept for e.g. different shorting mechanics.  And alleviate the pain of hard forking by scheduling them (in the case of DevShares) and separating out people who are willing to keep up with hardforks into their own network (in the case of NewShares).  Of course critical security issues may still require an unscheduled hard fork.

There's an analogy to the typical organization of software projects:  You can think of NewShares as the "development branch" (very new features, sometimes compat-breaking), DevShares as the "master branch" (pretty new features that the devs regard as final but have not received as much real-world testing from users as the stable branch), and BTSX as the "stable branch" (receives bug fixes and security fixes, and new features when they have been thoroughly tested by more adventurous users).

Also, the NewShares model alleviates the problem of requiring many different versions of the validation logic / market engine:  After NewShares shutdown, the next NewShares net starts from a "clean slate" and doesn't need the obsolete validation logic because it's not required to be backward compatible with the old net which has been shut down.  The details of NewShares mechanics never make it into DevShares code.  DevShares only knows about the shutdown block distribution of NewShares, it doesn't need to know anything about the semantics of the NewShares transactions that caused the transitions from the genesis block to the shutdown state.

28
General Discussion / I want to join the BitShares team. Who do I contact?
« on: October 10, 2014, 11:12:45 pm »
I'm a long-time forum member with lots of contributions to the forum and Github.  I've made several suggestions that have been implemented, bug reports that have been fixed, and pull requests that have been merged.

I'd like to take my contributions to the next level by joining the BitShares team as a developer.

I've tried asking bytemaster about joining the team privately by PM and email, but I have not received any reply.

Who should I contact, and what is the ETA on some reply?

Thanks.

29
General Discussion / Video of Inside Bitcoins keynote?
« on: October 06, 2014, 07:31:54 pm »

For those of us who can be there only in spirit, are there plans to record video of tomorrow's keynote?  FTR it's tomorrow, October 7, at 11:45 AM (I assume that's in the Las Vegas timezone).

If there aren't any such plans, maybe you should make some :)  It doesn't have to be anything fancy.  Someone in a different thread said there are 8 people there, presumably 7 of them will be sitting in the audience -- I assume at least 1 of them has a cell phone or tablet capable of recording video.

Heck, audio and slides would work nearly as well.

30
General Discussion / The lemonade stand
« on: October 04, 2014, 02:30:27 am »
Let me tell you a little story.

Alice and Bob run a lemonade stand.  Each invested $50 capital, and the lemonade stand turns a profit of $10 per day.

Their cash register is a small basket full of bills and coins.  On odd-numbered days, Alice runs the stand.  On even-numbered days, Bob runs the stand.  They agree that whoever is running the stand will be paid by getting half the contents of the basket at the end of the day.

This system works very well.  Taking profits on alternating days allows Alice and Bob to buy lots of candy and soda.  Bob gets a little more in the beginning, but the dividends quickly even out, and they are not very worried about it.

Over the winter, Bob decides that next summer he's going to buy a bike -- the model he has his eye on costs $150.  He knows this is about what he makes from the lemonade stand, so he no longer wants to take profits daily, instead letting his share accrue in the basket so he's not tempted to blow the money on sweets.  Alice is less of a long-term thinker and wants to still get her share of profits every day, however.

Continued in the next post...

Pages: 1 [2] 3 4