Author Topic: BitShares X Status Update  (Read 369635 times)

0 Members and 1 Guest are viewing this topic.

Offline BTSdac

  • Hero Member
  • *****
  • Posts: 1219
    • View Profile
  • BitShares: K1
Today we had an in person all day Invictus company meeting with 8 team members from across the country.   Great things discussed and progress made.  No new coding updates however.

Miami will be awesome! 
     some people invest 3I company  and many people inverst AGS, how to do deal the relationship , and how do you  banlance the interste of them
github.com :pureland
BTS2.0 API :ws://139.196.37.179:8091
BTS2.0 API 数据源ws://139.196.37.179:8091

Offline bytemaster

Today we had an in person all day Invictus company meeting with 8 team members from across the country.   Great things discussed and progress made.  No new coding updates however.

Miami will be awesome! 
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline Liberty

  • Jr. Member
  • **
  • Posts: 23
    • View Profile
If using rationals was an option I could simply switch to 128 bit representation as it would have identical storage requirements and move the rounding errors so that they are so small as to not even matter.

Rationals are inherently imprecise no matter how many bits they are represented in. A value like 0.125 behaves as if it were 0.124999999999999992 because of this representational imprecision. Consider how rounding and truncating operations will not behave as expected due to this imprecision. You can only round as expected by reducing the precision each time. The problems with rationals are worse than with integers. You will still be off by satoshis even if you use rationals, but rounded and truncated rationals carry imprecision into subsequent computations in ways that are more harmful for accuracy of comparison operations. The common way to deal with the extra is have a rule for which side gets them. Yes you could siphon the rounding imprecision into a separate account as a "fee" (like in the movie Superman 3), but that is less fair than having a standard way to decide which participant gets them. It was genius that Satoshi Nakamoto knew to use integers.

« Last Edit: January 11, 2014, 03:37:03 pm by Liberty »

Offline bytemaster

Today I completely reworked the bid/ask/short matching system to address the issues discovered yesterday and the result appears to be working as expected except for an integer rounding error which is proving to be very challenging to address.  The problem is that all prices are 'ratios' and if you use bids or asks with a price of '3 usd/bts' then you end up with numbers like 3333.33333 and 6666.66666 which when rounded turn into 6667 and when multiplied by say 2, propagates the error resulting in 13334 rather than the expected 13333 and if you truncate it then you get 13332.   

What is an extra satoshi lost or gained here and there between friends?   

I am having to perform a careful audit of the code to make sure that these kinds of rounding errors are properly avoided.  Isn't fixed point 128 bit math fun!

Would it be a problem to express prices as satoshis/satoshis and only complete trades in full increments of the price?

It would significantly complicate the code and not provide that much extra benefit.
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline Troglodactyl

  • Hero Member
  • *****
  • Posts: 960
    • View Profile
Today I completely reworked the bid/ask/short matching system to address the issues discovered yesterday and the result appears to be working as expected except for an integer rounding error which is proving to be very challenging to address.  The problem is that all prices are 'ratios' and if you use bids or asks with a price of '3 usd/bts' then you end up with numbers like 3333.33333 and 6666.66666 which when rounded turn into 6667 and when multiplied by say 2, propagates the error resulting in 13334 rather than the expected 13333 and if you truncate it then you get 13332.   

What is an extra satoshi lost or gained here and there between friends?   

I am having to perform a careful audit of the code to make sure that these kinds of rounding errors are properly avoided.  Isn't fixed point 128 bit math fun!

Would it be a problem to express prices as satoshis/satoshis and only complete trades in full increments of the price?

Offline Markus

  • Sr. Member
  • ****
  • Posts: 366
    • View Profile
… With a little careful work I can always round down so that these rounding errors act as a kind of extra 'fee' the network charges users and no new coin ever gets created.

I think rounding down both sides and destroying a few satoshis is the best way.

Offline phoenix

  • Sr. Member
  • ****
  • Posts: 275
    • View Profile
I have posted an updated blockchain dump to demonstrate my progress.  The major step forward here is handling many bids and asks at once. 

http://the-iland.net/static/chain.html

looks good
Protoshares: Pg5EhSZEXHFjdFUzpxJbm91UtA54iUuDvt
Bitmessage: BM-NBrGi2V3BZ8REnJM7FPxUjjkQp7V5D28

Offline bytemaster

I have posted an updated blockchain dump to demonstrate my progress.  The major step forward here is handling many bids and asks at once. 

http://the-iland.net/static/chain.html

For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline bytemaster

Today I have provided a temporary work-a-round in the comparison method that resolves these rounding issues.   So long as the rounding errors are in amounts that are effectively 0 economic value (1 or 2 satoshis) and greater than the minimum transaction fee this would not be a viable means of attack.   The total 'inflation' from rounding would be limited to 4 BTC / year if this were bitcoin and all rounding errors went were positive and all transactions had rounding errors.   Given that 90% of transactions have no rounding errors and 50% of the transactions round the other way, the net effect should average 0.   With a little careful work I can always round down so that these rounding errors act as a kind of extra 'fee' the network charges users and no new coin ever gets created.

If using rationals was an option I could simply switch to 128 bit representation as it would have identical storage requirements and move the rounding errors so that they are so small as to not even matter.



For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline coolspeed

  • Hero Member
  • *****
  • Posts: 536
    • View Profile
    • My Blog
Today I completely reworked the bid/ask/short matching system to address the issues discovered yesterday and the result appears to be working as expected except for an integer rounding error which is proving to be very challenging to address.  The problem is that all prices are 'ratios' and if you use bids or asks with a price of '3 usd/bts' then you end up with numbers like 3333.33333 and 6666.66666 which when rounded turn into 6667 and when multiplied by say 2, propagates the error resulting in 13334 rather than the expected 13333 and if you truncate it then you get 13332.   

What is an extra satoshi lost or gained here and there between friends?   

I am having to perform a careful audit of the code to make sure that these kinds of rounding errors are properly avoided.  Isn't fixed point 128 bit math fun!

Can we use Symbolic Computation just like matlab? :D
Or a new data structure to save a Rational.
So we can precisely describe a Rational.

Maybe this is too much......... ;D

I think it may be a good idea. Especially to face the Dividends 2.0.
The python rational number which is in python standard library may be enough. If not, there's still sympy -- Python symbolic library. And GiNaC -- C++ symbolic library.
Please vote for  delegate.coolspeed    dac.coolspeed
BTS account: coolspeed
Sina Weibo:@coolspeed

Offline logxing

Today I completely reworked the bid/ask/short matching system to address the issues discovered yesterday and the result appears to be working as expected except for an integer rounding error which is proving to be very challenging to address.  The problem is that all prices are 'ratios' and if you use bids or asks with a price of '3 usd/bts' then you end up with numbers like 3333.33333 and 6666.66666 which when rounded turn into 6667 and when multiplied by say 2, propagates the error resulting in 13334 rather than the expected 13333 and if you truncate it then you get 13332.   

What is an extra satoshi lost or gained here and there between friends?   

I am having to perform a careful audit of the code to make sure that these kinds of rounding errors are properly avoided.  Isn't fixed point 128 bit math fun!

Can we use Symbolic Computation just like matlab? :D
Or a new data structure to save a Rational.
So we can precisely describe a Rational.

Maybe this is too much......... ;D
BTS Account:logxing

Offline bytemaster

Today I completely reworked the bid/ask/short matching system to address the issues discovered yesterday and the result appears to be working as expected except for an integer rounding error which is proving to be very challenging to address.  The problem is that all prices are 'ratios' and if you use bids or asks with a price of '3 usd/bts' then you end up with numbers like 3333.33333 and 6666.66666 which when rounded turn into 6667 and when multiplied by say 2, propagates the error resulting in 13334 rather than the expected 13333 and if you truncate it then you get 13332.   

What is an extra satoshi lost or gained here and there between friends?   

I am having to perform a careful audit of the code to make sure that these kinds of rounding errors are properly avoided.  Isn't fixed point 128 bit math fun!
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline alt

  • Hero Member
  • *****
  • Posts: 2821
    • View Profile
  • BitShares: baozi
add oil
Today I have enhanced covering of short positions and started work on adding additional margin to open short positions.  In this process I realized that I could easily add margin, but there was no effective way to remove margin using only the context of the transaction because I must enforce collateral requirements with respect to the current market price.   

I discovered some bugs in my bid/ask matching when the ask is lower than the bid.  Apparently I got my price ratios for bids/asks backwards and so they were sorted wrong and therefore only working when the bid/ask matched perfectly.   The good news is that I know know how to fix it and can apply these changes tomorrow.   

Overall I have been gradually increasing the number of test cases that pass and making steady progress.

Offline voldemort628

  • Full Member
  • ***
  • Posts: 117
    • View Profile
Overall I have been gradually increasing the number of test cases that pass and making steady progress.

keep up the good work! :)

Offline bytemaster

Today I have enhanced covering of short positions and started work on adding additional margin to open short positions.  In this process I realized that I could easily add margin, but there was no effective way to remove margin using only the context of the transaction because I must enforce collateral requirements with respect to the current market price.   

I discovered some bugs in my bid/ask matching when the ask is lower than the bid.  Apparently I got my price ratios for bids/asks backwards and so they were sorted wrong and therefore only working when the bid/ask matched perfectly.   The good news is that I know know how to fix it and can apply these changes tomorrow.   

Overall I have been gradually increasing the number of test cases that pass and making steady progress.
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.