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

Pages: 1 2 3 4 5 6 7 [8] 9 10 11 12 13 14 15 ... 42
107
General Discussion / For those who want a test net...
« on: August 04, 2015, 02:32:44 pm »
https://graphene.bitshares.org/

There are still bugs all over the place in the wallet.   This isn't an official test net by any stretch of the imagination.   

We are still working out kinks in the wallet import functionality.   

108
General Discussion / Updates on Compact Confidential Transactions
« on: July 23, 2015, 08:05:43 pm »
This white paper was last updated early July.   I would like some help finding the latest status of this approach, in particular are there any working implementations?

http://voxelsoft.com/dev/cct.pdf


110
The USD/BitUSD market is currently offering a premium for BitUSD with thousands of dollars above $1.00. 


111
General Discussion / Peercoin? What's going on with it?
« on: July 09, 2015, 10:30:10 pm »
I see it is up 45% today!   

Goes to show that you can never count anyone out and that BTS could make a big move at any time.   

112
General Discussion / Status Update
« on: July 09, 2015, 10:21:42 pm »
We have been doing a lot of internal tests and today we started an internal test network operating over the internet.   This test network uses a snapshot from BitShares on July 9. 

So far things are running very smoothly.   The total RAM usage after importing all of BitShares and registering 100,000 new accounts is still under 222 MB of memory, which with OSX memory compression enabled actually compresses a large part of that down to just 115MB.   With our modest flooding of the network at 10 transactions per second CPU usage was less than 2%.   When I compare this to BTS1.0 I see it uses 1.5 MB of memory and with compression 632 MB resides in active use.   So the is an 83% memory reduction for the same amount of data.

We are putting the finishing touches on the protocol as we prepare to launch a public test network.   

Thank you all for hanging in there.  We don't get many opportunities to completely revamp a protocol and so we are taking our time to make sure we can live with what we have for a long time.   This means designing in features for expansion. 

Things we have left to do prior to a wide spread public test network:
1. Release BitShares 0.9.3 with extra API for dumping private keys for an account to facilitate easy importing into Graphene.
2. A lot of GUI work is left to be done.
3. The CLI wallet needs some usability improvements to expose all of the features.

In the spirit of getting things released and upgraded in a timely manner, we have decided to delay the bond market feature until 2.1 which will be the first feature enabled by stakeholder approval.  This decision is mostly based around minimizing the surface area that we need to test prior to launch.   

See you all in mumble tomorrow!

113
With all of our focus on gateways, how is the P2P routing of payments through ripple handled?

114
General Discussion / Announcing Brownie Points (BROWNIE.PTS)
« on: July 02, 2015, 06:33:38 pm »
Announcing Brownie Points (BROWNIE.PTS)

Today I am happy to announce a new way of giving credit to those who contribute to the BitShares community, Brownie Points.   According to Wikipedia, brownie points are a hypothetical social currency, which can be acquired by doing good deeds or earning favor in the eyes of another.   

Normally brownie points are not tracked, but with the advent of BitShares it is now possible for us to actually track brownie points.  I have created a digital asset called BROWNIE.PTS on the BitShares network.   Brownie Points will be given away liberally to anyone who does anything positive for the BitShares community or Cryptonomex as recognition for earning my favor.

Everyone who attends a Friday Mumble sessions will be awarded with 100 BROWNIE.PTS, everyone who makes a useful, positive post on the forum will earn 10 BROWNIE.PTS.  Everyone who finds and reports an actual bug on github will be rewarded with 100 BROWNIE.PTS.   Anyone who resolves a legitimate issue on GitHub will be rewarded with major BROWNIE.PTS.   

I will award brownie points for just about anything that I appreciate and in proportion to the amount that I appreciate it.   If you are interested in helping me dole out BROWNIE.PTS then please contact me because I would really appreciate the help!   

What are Brownie Points Good for?

Technically all Brownie Points mean is that you are on my good side.  Brownie Points are not redeemable for anything and do not create any obligations between me and anyone else.   BROWNIE.PTS is a tool that allows me to keep track of everyone who is in my good favor and to what extent.   You will want to make sure you claim your BROWNIE.PTS because it would just be rude to refuse the BROWNIE.PTS and one day you may regret it; Karma can be a Bitch.       


Claiming Past Brownie Points

If you have contributed to BitShares over the past two years, please post in this thread with a detailed description of the work you have done and an estimate of how much time and money you spent doing that work.  Include your BTS account name and you may find some BROWNIE.PTS in your wallet.   

No Obligations

BROWNIE.PTS is merely a tool for my own use and I may choose to stop issuing brownie points at any time for any reason.   I may reward them (or not) as I see fit, in the amounts I see fit, for the reasons I see fit.   I may also seize brownie points from any account if you fall out of favor and anyone who complains in any way about how Brownie Points are issued or how I use Brownie Points is certainly not in my favor and may lose any Brownie Points they have earned.   

115
General Discussion / $500 BitUSD Bounty - ECC Blinded Signatures
« on: June 30, 2015, 02:23:50 pm »
I am looking for the following algorithm to be made available in fc using libsecp256k if possible:

I remember Oleg Andreev working on an ECC blind signatures scheme.
http://blog.oleganza.com/post/77474860538/blind-signatures

It seems he has a working implementation based on obj-c.
https://github.com/oleganza/CoreBitcoin/blob/master/CoreBitcoin/BTCBlindSignature.h

Proposed/Expected API

Code: [Select]
fc::ecc::extended_private_key  bob;
fc::ecc::extended_private_key  alice;
fc::ecc::extended_public_key   bob_pub = bob.extended_public_key();

// a public key that only bob has the ability to generate blinded signatures for
fc::ecc::public_key    pub_key = fc::ecc::blind_public_key(  alice, bob_pub, i );

fc::sha256  digest;

int i = 0;

fc::ecc::blinded_hash          blind_digest =  fc::ecc::blind_hash( alice, bob_pub, digest, i );
fc::ecc::blind_signature       blind_sig      =  fc::ecc::blind_sign( bob, blind_digest, i );
fc::ecc::compact_signature unblind_sig  =  fc::ecc::unblind_signature( alice, bob_pub, blind_sig, i );
 
FC_ASSERT( fc::ecc::public_key( digest, unblind_sig ) == pub_key )



116
General Discussion / Blinded Signature Schemes
« on: June 29, 2015, 09:09:05 pm »
I am looking for the best blinded signature scheme similar to:

http://anoncvs.aldigital.co.uk/lucre/

Are there any based on ECC.  I am particularly interested in any libraries that already do the work.

117
General Discussion / BitLicense
« on: June 24, 2015, 08:48:16 pm »
Please brainstorm every rationale why you think Cryptonomex needs to apply for a BitLicense.

How might it apply to us and our partners?

119
General Discussion / Blog being included in a Book
« on: June 19, 2015, 05:52:23 pm »
I would welcome the communities input in finding and correcting errors / grammar in this document which will be included in a major new book about the Bitcoin industry...

https://docs.google.com/document/d/1bVSvTDn4XE53feECiFtvQfgZcVwFAYPzrurk_JEnn90/edit

Help make us look good! 

120
Stakeholder Proposals / Short Order Refactoring
« on: June 16, 2015, 03:12:17 pm »
Under BitAssets 2.0 all that matters is that you maintain sufficient collateral.  Initial collateral is effectively meaningless.   Users could at any time short to themselves and then manually reduce their collateral.   

In the interest of simplifying the protocol and the user experience I propose the following:

1. Get rid of "short orders" entirely
2. Allow users to borrow any amount of BitUSD by locking up collateral.
3. Margin call the positions like always
4. Users can adjust their debt and collateral at any time provided the ratio between the two is sufficient.

To "short" you would first borrow the BitUSD and then place a standard limit order.   

This would greatly simplify all market operations and history and result in fewer potential bugs. 

I wanted to run the concept by everyone before committing to the approach.

Pages: 1 2 3 4 5 6 7 [8] 9 10 11 12 13 14 15 ... 42