-
There has been an incredible amount of innovation over the past 2 months since we launched PTS and the ideas are scattered around the forum in many different threads. This thread is to bring it all home to one place and summarize what has changed over the past 2 months.
1) BitShares will no longer be mined nor will it use Proof of Work, instead it will use Consensus + Proof of Stake
a) This means that BTS will now pay 2x the dividend rate that the original spec called for.
b) This means that PTS holders stake in BTS will no longer be diluted by 45% due to mining rewards
c) This means that PTS holders benefit from allowing us to raise capital with the money previously spent on mining.
2) BitAssets will now receive a predictable, hardcoded 5% interest return, and short positions will pay a 5% borrowing cost.
3) Consensus algorithm means that confirmation times will be as quick as 30 seconds and no one node can manipulate the market.
4) We have identified a much simpler approach to implementing dividends
5) 50% of first BTS money supply will be allocated to PTS holders
6) 50% of first BTS money supply will be allocated to AGS holders.
7) Each BTS chain will support trading in about 16 assets
8) AGS and PTS will be used to initialize all BTS chains each trading in a subset of assets. Therefore, AGS and PTS is more valuable than owning a single BTS chain. They get you rights to all chains.
9) At the rate AGS is being funded we will have $3 million per month to spend developing BTS and are rapidly moving to accelerate the process.
Thanks everyone!
-
Thank you for doing this consolidation of info.
-
What I go out of this was: Everyone who holds even a few PTS will see their investment grow incredibly with a single DAC. I'm looking forward to Bitshares! 8)
-
9) At the rate AGS is being funded we will have $3 million per month to spend developing BTS and are rapidly moving to accelerate the process.
AGS uses should be cautious.It sounds like burning money.
-
thanks for the update..now thing getting more clear...
-
What I go out of this was: Everyone who holds even a few PTS will see their investment grow incredibly with a single DAC. I'm looking forward to Bitshares! 8)
What if you own less than a few? I only have 2.5 lol :( Wish I mined on day 1
-
Do Not splash the funded money.
-
I'm really confused...
No more solo mining for Protoshares, unless you have some magic to actually build the pool code.
No mining for Bitshares, this is oing to lock out a lot of the crypto crowd.
What will be the total number of Bitshares?
How are AGS different from PTS, aside from that AGS are centrally issued? <--- This is the most important question.
Thanks
-
What will be the total number of Bitshares?
400W = 200W(for PTS holders) + 200W(for AGS holders)
4M = 2M(for PTS holders) + 2M(for AGS holders)
How are AGS different from PTS, aside from that AGS are centrally issued? <--- This is the most important question.
Thanks
Guess you can find official answer here. http://invictus-innovations.com/social-concensus
-
What will be the total number of Bitshares?
400W = 200W(for PTS holders) + 200W(for AGS holders)
Sorry, what does the W notation stand for?
-
It's Chinese
1W=10 thousand
What will be the total number of Bitshares?
400W = 200W(for PTS holders) + 200W(for AGS holders)
Sorry, what does the W notation stand for?
-
It's Chinese
1W=10 thousand
Thank you.
-
What will be the total number of Bitshares?
400W = 200W(for PTS holders) + 200W(for AGS holders)
Sorry, what does the W notation stand for?
Errrr... 1W=10k in Chinese.
-
I am not understanding number 8
8) AGS and PTS will be used to initialize all BTS chains each trading in a subset of assets. Therefore, AGS and PTS is more valuable than owning a single BTS chain. They get you rights to all chains.
Could someone please explain this or point me to a thread that explains this.
Thanks
-
I am not understanding number 8
8) AGS and PTS will be used to initialize all BTS chains each trading in a subset of assets. Therefore, AGS and PTS is more valuable than owning a single BTS chain. They get you rights to all chains.
Could someone please explain this or point me to a thread that explains this.
Thanks
I think this works because every BitShares-chain is a separate DAC which will stick to the social contract and give shares to AGS and PTS holders.
-
I am not understanding number 8
8) AGS and PTS will be used to initialize all BTS chains each trading in a subset of assets. Therefore, AGS and PTS is more valuable than owning a single BTS chain. They get you rights to all chains.
Could someone please explain this or point me to a thread that explains this.
Thanks
I think this works because every BitShares-chain is a separate DAC which will stick to the social contract and give shares to AGS and PTS holders.
Ok thanks, I get it now. Your post helped and I had to read number 8 over a few times haha
-
Why would anybody short fiat at a 5% tax? It may be that volatile in the future but that seems crazy right now. If no one shorts it how is bitusd created?
-
Why would anybody short fiat at a 5% tax? It may be that volatile in the future but that seems crazy right now. If no one shorts it how is bitusd created?
You can short against any asset, 5% may not be so unreasonable if you think USD will fall against oil/bts/btc/gold/silver. That said, I think you have a point given how much of an emphasis on currencies there is in the current root chain plan.
-
Why would anybody short fiat at a 5% tax? It may be that volatile in the future but that seems crazy right now. If no one shorts it how is bitusd created?
You can short against any asset, 5% may not be so unreasonable if you think USD will fall against oil/bts/btc/gold/silver. That said, I think you have a point given how much of an emphasis on currencies there is in the current root chain plan.
That is awesome.
One more question. That is 5% a year right?
-
Why would anybody short fiat at a 5% tax? It may be that volatile in the future but that seems crazy right now. If no one shorts it how is bitusd created?
You can short against any asset, 5% may not be so unreasonable if you think USD will fall against oil/bts/btc/gold/silver. That said, I think you have a point given how much of an emphasis on currencies there is in the current root chain plan.
That is awesome.
One more question. That is 5% a year right?
Yes
-
Why would anybody short fiat at a 5% tax? It may be that volatile in the future but that seems crazy right now. If no one shorts it how is bitusd created?
You can short against any asset, 5% may not be so unreasonable if you think USD will fall against oil/bts/btc/gold/silver. That said, I think you have a point given how much of an emphasis on currencies there is in the current root chain plan.
That is awesome.
One more question. That is 5% a year right?
Yes
Why the 5% should be hard-coded? And how can we reach the consensus that 5% is not too much?
-
Why would anybody short fiat at a 5% tax? It may be that volatile in the future but that seems crazy right now. If no one shorts it how is bitusd created?
You can short against any asset, 5% may not be so unreasonable if you think USD will fall against oil/bts/btc/gold/silver. That said, I think you have a point given how much of an emphasis on currencies there is in the current root chain plan.
That is awesome.
One more question. That is 5% a year right?
Yes
Why the 5% should be hard-coded? And how can we reach the consensus that 5% is not too much?
5% may even be too little.
It would be a payoff.
What % fee is reasonable to charge someone to short a currency. (5% is rather cheap compared to the fees you would pay to other services to short order.) But here we need to get allot of people to short order so we can lend bitAssets into existence. So theres the first payoff.
Next we need to make a reasonable return for clients who want to store their money in as bitassets for the 5% return.
Here 5% may be too low. I am able to get between 4.9 and 8% annual return at my national bank's super safe, backed up, conservative money market account that doesnt require new understanding of technology or to stomach perceived risk.
-
Why would anybody short fiat at a 5% tax? It may be that volatile in the future but that seems crazy right now. If no one shorts it how is bitusd created?
You can short against any asset, 5% may not be so unreasonable if you think USD will fall against oil/bts/btc/gold/silver. That said, I think you have a point given how much of an emphasis on currencies there is in the current root chain plan.
That is awesome.
One more question. That is 5% a year right?
Yes
Why the 5% should be hard-coded? And how can we reach the consensus that 5% is not too much?
5% may even be too little.
It would be a payoff.
What % fee is reasonable to charge someone to short a currency. (5% is rather cheap compared to the fees you would pay to other services to short order.) But here we need to get allot of people to short order so we can lend bitAssets into existence. So theres the first payoff.
Next we need to make a reasonable return for clients who want to store their money in as bitassets for the 5% return.
Here 5% may be too low. I am able to get between 4.9 and 8% annual return at my national bank's super safe, backed up, conservative money market account that doesnt require new understanding of technology or to stomach perceived risk.
That's not the right perspective to look at this, IMO. Different asset classes have different interest rates. I doubt USD money markets would give you 8% return. I also doubt any bank in the world would give you 5% interest on gold deposits, denominated in gold. Bitcoin too, should have a very low interest rate, if at all, in the free market.
Also, 5% isn't much when you put a collateral against which you're loaning money. The cheapest brokerages, for instance, let you borrow USD at less than 1% against your stock portfolio.
From a saver's perspective, this seems like a good deal. I am not so sure about this from the speculator's perspective. The open market, with all its flaws, might yield better results.
I am not sure how this could be made better though. Can interest rates themselves be floating, as in market determined by some mechanism?
-
Why would anybody short fiat at a 5% tax? It may be that volatile in the future but that seems crazy right now. If no one shorts it how is bitusd created?
You can short against any asset, 5% may not be so unreasonable if you think USD will fall against oil/bts/btc/gold/silver. That said, I think you have a point given how much of an emphasis on currencies there is in the current root chain plan.
That is awesome.
One more question. That is 5% a year right?
Yes
Why the 5% should be hard-coded? And how can we reach the consensus that 5% is not too much?
5% may even be too little.
It would be a payoff.
What % fee is reasonable to charge someone to short a currency. (5% is rather cheap compared to the fees you would pay to other services to short order.) But here we need to get allot of people to short order so we can lend bitAssets into existence. So theres the first payoff.
Next we need to make a reasonable return for clients who want to store their money in as bitassets for the 5% return.
Here 5% may be too low. I am able to get between 4.9 and 8% annual return at my national bank's super safe, backed up, conservative money market account that doesnt require new understanding of technology or to stomach perceived risk.
That's not the right perspective to look at this, IMO. Different asset classes have different interest rates. I doubt USD money markets would give you 8% return. I also doubt any bank in the world would give you 5% interest on gold deposits, denominated in gold. Bitcoin too, should have a very low interest rate, if at all, in the free market.
Also, 5% isn't much when you put a collateral against which you're loaning money. The cheapest brokerages, for instance, let you borrow USD at less than 1% against your stock portfolio.
From a saver's perspective, this seems like a good deal. I am not so sure about this from the speculator's perspective. The open market, with all its flaws, might yield better results.
I am not sure how this could be made better though. Can interest rates themselves be floating, as in market determined by some mechanism?
This is a tough one. The 4.9 to 8% are the actual performance figures from a South African national bank for its money market fund.
So for a South African holding their rands in a real world bank would be more attractive.
I know that Chinese banks offer very little in terms of decent return savings accounts, so there is allot of potential there.
Given all the different situations in different countries it is very difficult to select an appropriate interest rate for a global bank.
-
Remember that interest (returns) rates are not hard-coded, it's the various fees that are. We should be looking at what the fees around the world are for short-selling, inactivity, etc, not what kinds of returns you can get
-
Yeah, eventually there needs to be a free market mecanism in place to replace the "hardcoded 5%"
-
Yeah, eventually there needs to be a free market mecanism in place to replace the "hardcoded 5%"
Yes, I agree. I will setup a prediction market to predict what the interest rate should be.
-
Awaiting for news! :D
-
What's the best ETA for Bitshares? I heard bytemaster say he's going to go in a cave for two weeks, but the change from POW to POS would mean a complete rework of the system. AngelShares gives them some money to get more coders, but all those people will need to be trained or caught up. I'm figuring we might be looking at around 6 months to a BitShares release. Especially since the security people still have to comb through everything. Does anyone have better estimates?
-
What's the best ETA for Bitshares? I heard bytemaster say he's going to go in a cave for two weeks, but the change from POW to POS would mean a complete rework of the system. AngelShares gives them some money to get more coders, but all those people will need to be trained or caught up. I'm figuring we might be looking at around 6 months to a BitShares release. Especially since the security people still have to comb through everything. Does anyone have better estimates?
Bump. Same, Estimated ETA would be great.
-
What's the best ETA for Bitshares? I heard bytemaster say he's going to go in a cave for two weeks, but the change from POW to POS would mean a complete rework of the system. AngelShares gives them some money to get more coders, but all those people will need to be trained or caught up. I'm figuring we might be looking at around 6 months to a BitShares release. Especially since the security people still have to comb through everything. Does anyone have better estimates?
Bump. Same, Estimated ETA would be great.
I concur. What is the approximate release date, tentatively?
-
What's the best ETA for Bitshares? I heard bytemaster say he's going to go in a cave for two weeks, but the change from POW to POS would mean a complete rework of the system. AngelShares gives them some money to get more coders, but all those people will need to be trained or caught up. I'm figuring we might be looking at around 6 months to a BitShares release. Especially since the security people still have to comb through everything. Does anyone have better estimates?
Bump. Same, Estimated ETA would be great.
I concur. What is the approximate release date, tentatively?
I will have a working command line alpha wallet + blockchain algorithm this month. I just checked in code that generates bids and short positions as well as transfers and builds a block chain. I have to implement the bid/ask matching engine which I will have roughed in this week. Now that I am focused entirely on this I hope to make rapid progress and will report in to this thread every day with my progress.
-
I can't wait!
What's the best ETA for Bitshares? I heard bytemaster say he's going to go in a cave for two weeks, but the change from POW to POS would mean a complete rework of the system. AngelShares gives them some money to get more coders, but all those people will need to be trained or caught up. I'm figuring we might be looking at around 6 months to a BitShares release. Especially since the security people still have to comb through everything. Does anyone have better estimates?
Bump. Same, Estimated ETA would be great.
I concur. What is the approximate release date, tentatively?
I will have a working command line alpha wallet + blockchain algorithm this month. I just checked in code that generates bids and short positions as well as transfers and builds a block chain. I have to implement the bid/ask matching engine which I will have roughed in this week. Now that I am focused entirely on this I hope to make rapid progress and will report in to this thread every day with my progress.
-
I will have a working command line alpha wallet + blockchain algorithm this month. I just checked in code that generates bids and short positions as well as transfers and builds a block chain. I have to implement the bid/ask matching engine which I will have roughed in this week. Now that I am focused entirely on this I hope to make rapid progress and will report in to this thread every day with my progress.
looks good! keep up the good work! :)
-
What's the best ETA for Bitshares? I heard bytemaster say he's going to go in a cave for two weeks, but the change from POW to POS would mean a complete rework of the system. AngelShares gives them some money to get more coders, but all those people will need to be trained or caught up. I'm figuring we might be looking at around 6 months to a BitShares release. Especially since the security people still have to comb through everything. Does anyone have better estimates?
Bump. Same, Estimated ETA would be great.
I concur. What is the approximate release date, tentatively?
I will have a working command line alpha wallet + blockchain algorithm this month. I just checked in code that generates bids and short positions as well as transfers and builds a block chain. I have to implement the bid/ask matching engine which I will have roughed in this week. Now that I am focused entirely on this I hope to make rapid progress and will report in to this thread every day with my progress.
I'm asking mainly for two reasons:
1, Gives me time to buy more PTS and plan ahead
2, Setup more hardware for mining BTS.
Even if you said 6 month or 1 year then its something for me to work towards?
Ta
-
What's the best ETA for Bitshares? I heard bytemaster say he's going to go in a cave for two weeks, but the change from POW to POS would mean a complete rework of the system. AngelShares gives them some money to get more coders, but all those people will need to be trained or caught up. I'm figuring we might be looking at around 6 months to a BitShares release. Especially since the security people still have to comb through everything. Does anyone have better estimates?
Bump. Same, Estimated ETA would be great.
I concur. What is the approximate release date, tentatively?
I will have a working command line alpha wallet + blockchain algorithm this month. I just checked in code that generates bids and short positions as well as transfers and builds a block chain. I have to implement the bid/ask matching engine which I will have roughed in this week. Now that I am focused entirely on this I hope to make rapid progress and will report in to this thread every day with my progress.
I'm asking mainly for two reasons:
1, Gives me time to buy more PTS and plan ahead
2, Setup more hardware for mining BTS.
Even if you said 6 month or 1 year then its something for me to work towards?
Ta
BTS won't be mined, just so you are aware. It's just AGS and PTS now.
-
In tonights update I am pleased to announce that the blockchain has created its first BitUSD after pairing a short and long. You can view the debug output to see how the transactions were structured here: http://the-iland.net/static/chain.html
Next up on the agenda is to enable the destruction of the BitUSD that was just created by covering the position.
More updates in the days ahead.
-
What's the best ETA for Bitshares? I heard bytemaster say he's going to go in a cave for two weeks, but the change from POW to POS would mean a complete rework of the system. AngelShares gives them some money to get more coders, but all those people will need to be trained or caught up. I'm figuring we might be looking at around 6 months to a BitShares release. Especially since the security people still have to comb through everything. Does anyone have better estimates?
Bump. Same, Estimated ETA would be great.
I concur. What is the approximate release date, tentatively?
I will have a working command line alpha wallet + blockchain algorithm this month. I just checked in code that generates bids and short positions as well as transfers and builds a block chain. I have to implement the bid/ask matching engine which I will have roughed in this week. Now that I am focused entirely on this I hope to make rapid progress and will report in to this thread every day with my progress.
I'm asking mainly for two reasons:
1, Gives me time to buy more PTS and plan ahead
2, Setup more hardware for mining BTS.
Even if you said 6 month or 1 year then its something for me to work towards?
Ta
BTS won't be mined, just so you are aware. It's just AGS and PTS now.
How will this work, exactly? How it the security of the blockchain maintained, who processes transactions, and how is the economy inflated?
-
bytemaster. You are a genius. So much of the success hedges on your pioneering work. Please be safe.
-
congratulation!
In tonights update I am pleased to announce that the blockchain has created its first BitUSD after pairing a short and long. You can view the debug output to see how the transactions were structured here: http://the-iland.net/static/chain.html
Next up on the agenda is to enable the destruction of the BitUSD that was just created by covering the position.
More updates in the days ahead.
-
bytemaster. You are a genius. So much of the success hedges on your pioneering work. Please be safe.
Yeah.. Could somebody like... guard his house or something?
Seriously we need to build a anti drone sam-site in his backyard haha.
-
In tonights update I can report that the BitShares wallet API now supports covering of your short positions. While implementing this code I realized that the transaction verification for processing the covering of short positions will be a bit more complicated than I had originally thought. Next on my agenda is to get a robust algorithm for validating transactions that cover multiple short positions at once.
Things get much more complicated when a single transaction can have many different units, shorts, longs, etc and I have to have robust validation that prevents these combined inputs from being used to manipulate the margin requirements. Ultimately I may have to place some limits on the number and kinds of inputs a transaction can have. I will continue to post daily updates.
-
In tonights update I can report that the BitShares wallet API now supports covering of your short positions. While implementing this code I realized that the transaction verification for processing the covering of short positions will be a bit more complicated than I had originally thought. Next on my agenda is to get a robust algorithm for validating transactions that cover multiple short positions at once.
Things get much more complicated when a single transaction can have many different units, shorts, longs, etc and I have to have robust validation that prevents these combined inputs from being used to manipulate the margin requirements. Ultimately I may have to place some limits on the number and kinds of inputs a transaction can have. I will continue to post daily updates.
Really great work! Every update will be transferred to Chinese sub forum immediately. (https://bitsharestalk.org/index.php?topic=1937)
-
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.
-
Overall I have been gradually increasing the number of test cases that pass and making steady progress.
keep up the good work! :)
-
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.
-
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!
-
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
-
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 (http://en.wikipedia.org/wiki/SymPy). And GiNaC -- C++ symbolic library. (http://www.ginac.de/)
-
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.
-
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
-
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
-
… 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.
-
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?
-
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.
-
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.
-
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!
-
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
-
Today was another long day of meetings with the core Invictus team.... much happened, but no code status to report. Many updates soon.
-
Wish a todolist for the MVP.
Today was another long day of meetings with the core Invictus team.... much happened, but no code status to report. Many updates soon.
-
Today I made some major progress on the MVP client. I have a CLI client without any network connectivity that allows me to place bids, asks, shorts, cover, and cancel open orders. It will print out user balances as well as their margin positions. This is combined with all of the work necessary to make sure I can quit and reload the my wallet and block chain. Items on the TODO list for MVP include:
1) Clean Up CLI interface and remove console SPAM
2) Add display of market data (order book and current prices)
3) Add automatic margin call functionality
4) Implement client/server model for network communications
5) Add calculation of interest due and earned for short/long positions
6) Add calculation of dividends earned on bts positions.
7) Integrate PTS and BTC wallet import tools
8) Initialize genesis block and validate I can spend AGS and PTS balances.
I will probably add new items to the list as I come across them.
-
Keep going! :D
-
Thx for sharing this info
keep fingers crossed:)
-
Can't wait to test, seems two loops going and the match_orders thread messed up the command screen...
Is there anyway to redirect the ilog() outputs?
Update: Found that default logger config output logs to stderr, so we can just ignore the match orders logs by redirect stderr to file, e.g. on windows:
bts_wallet.exe 2>ilog.txt
-
Thanks for your hard work!!!
may I ask about when could BTS be finished? ^_^
-
thx! We are more close to the target!
Today I made some major progress on the MVP client. I have a CLI client without any network connectivity that allows me to place bids, asks, shorts, cover, and cancel open orders. It will print out user balances as well as their margin positions. This is combined with all of the work necessary to make sure I can quit and reload the my wallet and block chain. Items on the TODO list for MVP include:
1) Clean Up CLI interface and remove console SPAM
2) Add display of market data (order book and current prices)
3) Add automatic margin call functionality
4) Implement client/server model for network communications
5) Add calculation of interest due and earned for short/long positions
6) Add calculation of dividends earned on bts positions.
7) Integrate PTS and BTC wallet import tools
8) Initialize genesis block and validate I can spend AGS and PTS balances.
I will probably add new items to the list as I come across them.
-
So fast you are!
Can't wait to test, seems two loops going and the match_orders thread messed up the command screen...
Is there anyway to redirect the ilog() outputs?
-
Things seem to be moving along very quickly! I think that if you keep moving at this speed, the value of angelshares will go up a lot, since there will be fewer angelshares than protoshares by the time bitshares are released, making each angelshare worth more bitshares! 8)
-
Can't wait to test, seems two loops going and the match_orders thread messed up the command screen...
Is there anyway to redirect the ilog() outputs?
Yes, the logging system supports redirecting everything to a file.
-
Today I fixed many bugs while cleaning up the console output which now dumps all log messages to a file. The display of market data is partially implemented, but I do not yet find the CLI interface intuitive so I cannot cross #2 off my list quite yet.
1) Clean Up CLI interface and remove console SPAM
2) Add display of market data (order book and current prices)
3) Add automatic margin call functionality
4) Implement client/server model for network communications
5) Add calculation of interest due and earned for short/long positions
6) Add calculation of dividends earned on bts positions.
7) Integrate PTS and BTC wallet import tools
8) Initialize genesis block and validate I can spend AGS and PTS balances.
9) Implement JSON-RPC API to go with CLI interface.
-
… 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.
I agree. Everything about BitShares thus far seems exceedingly elegant, and a rounding solution that might result in supply inflation doesn't fit.
Today I fixed many bugs while cleaning up the console output which now dumps all log messages to a file. The display of market data is partially implemented, but I do not yet find the CLI interface intuitive so I cannot cross #2 off my list quite yet.
1) Clean Up CLI interface and remove console SPAM
2) Add display of market data (order book and current prices)
3) Add automatic margin call functionality
4) Implement client/server model for network communications
5) Add calculation of interest due and earned for short/long positions
6) Add calculation of dividends earned on bts positions.
7) Integrate PTS and BTC wallet import tools
8) Initialize genesis block and validate I can spend AGS and PTS balances.
9) Implement JSON-RPC API to go with CLI interface.
- Where is Consensus + Proof of Stake in this list?
- I understand that we are talking about MVP, but explicitly adding a full security review at the end of the list seems like a good idea considering how ridiculously important this code is.
- With the new branding, is this thread now referring to BitShares BEX?
These updates are great. Please continue keeping your head down and churning out quality code as fast as possible.
-
proof of stake is mostly implemented.
consensus is post MVP but on the todo list.
We will launch a test network with bounties to find bugs prior to launching the final version. So this TODO list is only MVP for Test Network.
-
Today I made significant progress improving the usability of the command line interface and fixing many bugs that came up in the process. Rounding errors and imprecision continues to crop up when there are odd prices and so I spent some more time handling rounding.
-
Today I made significant progress improving the usability of the command line interface and fixing many bugs that came up in the process. Rounding errors and imprecision continues to crop up when there are odd prices and so I spent some more time handling rounding.
I don't know how it's done there. But Ripple must have (had) the same problem.
-
Today I made significant progress improving the usability of the command line interface and fixing many bugs that came up in the process. Rounding errors and imprecision continues to crop up when there are odd prices and so I spent some more time handling rounding.
Thanks for your hard work!
Could we know about when the BTS could be fininshed? just an approximate date would be great~
^_^
-
Today I managed to implement basic client/server support, new wallets connect, sync up, and can start processing transactions. I also finished cleanup the display of bids/asks/shorts on the command line interface.
1) Clean Up CLI interface and remove console SPAM
2) Add display of market data (order book and current prices)
3) Add automatic margin call functionality
4) Implement client/server model for network communications
5) Add calculation of interest due and earned for short/long positions
6) Add calculation of dividends earned on bts positions.
7) Integrate PTS and BTC wallet import tools
8) Initialize genesis block and validate I can spend AGS and PTS balances.
9) Implement JSON-RPC API to go with CLI interface.
10) Management of encrypted wallets.
11) Implement and validate fees for all transactions
As far as estimated time of completion goes, I no longer make public estimates. There will be a long testing period during which everyone will have a good idea of the status of the chain prior to freezing of PTS / AGS contributions to this chain.
-
I used two clients to test, and transfer assets from one to another(e.g. transfer 1 bts to newaddr_x), it seems that these two clients have some privkeys in common, and the balance doesn't show correctly due to this.
Different clients having same generated privkeys may caused by sharing the same test_genesis_private_key basekey and same child_idx. For easy of multi clients testing, some random might be needed to add to the function test_genesis_private_key().
Today I managed to implement basic client/server support, new wallets connect, sync up, and can start processing transactions. I also finished cleanup the display of bids/asks/shorts on the command line interface.
1) Clean Up CLI interface and remove console SPAM
2) Add display of market data (order book and current prices)
3) Add automatic margin call functionality
4) Implement client/server model for network communications
5) Add calculation of interest due and earned for short/long positions
6) Add calculation of dividends earned on bts positions.
7) Integrate PTS and BTC wallet import tools
8) Initialize genesis block and validate I can spend AGS and PTS balances.
9) Implement JSON-RPC API to go with CLI interface.
10) Management of encrypted wallets.
11) Implement and validate fees for all transactions
As far as estimated time of completion goes, I no longer make public estimates. There will be a long testing period during which everyone will have a good idea of the status of the chain prior to freezing of PTS / AGS contributions to this chain.
-
is there any performance test will be conducted on Bitshares and Keyhotee?
-
You are correct the wallets need to generate unique seed keys. That was on the agenda for today.
Yoda: Testing we will do yeess.
Sent from my iPhone using Tapatalk (http://tapatalk.com/m?id=1)
-
Today I took some time off from C++ development to help get our website under control before Miami. To that end I am pleased to share the latest draft of the BitShares X and Invictus.io site: http://invictus.io/bitsharesx.php
Obviously we have more work to do, but it is certainly better than anything we have had thus far.
-
Best site so far, clean design and simple, with great explanations as well.
-
Wonderful!
-
Today I took some time off from C++ development to help get our website under control before Miami. To that end I am pleased to share the latest draft of the BitShares X and Invictus.io site: http://invictus.io/bitsharesx.php
Obviously we have more work to do, but it is certainly better than anything we have had thus far.
How many developerS work for BTS
-
Today I took some time off from C++ development to help get our website under control before Miami. To that end I am pleased to share the latest draft of the BitShares X and Invictus.io site: http://invictus.io/bitsharesx.php
Obviously we have more work to do, but it is certainly better than anything we have had thus far.
Looks good! Might I suggest a little more of a clear separator between the "differences" columns.
-
Thanks for the update Dan, am really surprised/happy to hear about the progress and the current implementation of being able to place bids, asks, shorts, cover, and cancel open orders.
-
Today I implemented many major bug fixes that address the issues found by Hacker Fish earlier.
My target for initial alpha testing of a MVP is Feb 1st, but this is not a hard deadline and more of a personal goal that I may or may not achieve based upon schedule and time constraints. I am terrible at estimating things and of course bugs are unpredictable in the amount of time they take to track down.
On deck for tomorrow: margin calls.
Then implement fees.
Then interest payments on BitAssets.
Lastly everything related to block numbers and time stamps needs to be audited now that we have moved from 5 minute average blocks to 30 seconds or 1st transaction blocks.
-
Feb 1st? big surprise! I think I should change more ags, because 1 ags = 2 bts, if you release before 4.10.
Today I implemented many major bug fixes that address the issues found by Hacker Fish earlier.
My target for initial alpha testing of a MVP is Feb 1st, but this is not a hard deadline and more of a personal goal that I may or may not achieve based upon schedule and time constraints. I am terrible at estimating things and of course bugs are unpredictable in the amount of time they take to track down.
On deck for tomorrow: margin calls.
Then implement fees.
Then interest payments on BitAssets.
Lastly everything related to block numbers and time stamps needs to be audited now that we have moved from 5 minute average blocks to 30 seconds or 1st transaction blocks.
-
This would be the test network and not the pts snapshot. I will announce pts snapshot after we have had solid testing
Sent from my iPhone using Tapatalk (http://tapatalk.com/m?id=1)
-
Today I decided to focus on the JSON-RPC API so that people could start building block explorers, web wallets, and other user interfaces that interact with my backend. To that end there is now a relatively complete JSON-RPC interface for communicating with the wallet, though the documentation on how to use it is sparse. Perhaps someone can update wiki.invictus.io with information on this RPC interface?
I am pleased to announce an alpha test period available to anyone who can compile the code. If you generate an address I will send you some test BTS to play around with. At this point it is very likely that we will find many bugs so I may reset the chain every day while I get the bugs fixed and this is why I am not releasing binaries right now.
Margin calls, trx fees, and interest are still left to be implemented and the only BitAsset right now is USD.
Let the testing begin :)
-
I am in,btw,has p2p connectivity been implemented ?
Sent from my iPhone using Tapatalk (http://tapatalk.com/m?id=1)
-
I am in,btw,has p2p connectivity been implemented ?
Sent from my iPhone using Tapatalk (http://tapatalk.com/m?id=1)
I have some P2P code implemented but it is not being used at this time. Right now it is client/server.
-
If someone would like to volunteer to distribute test BTS while I am off line let me know so I can give you a wad.
-
If someone would like to volunteer to distribute test BTS while I am off line let me know so I can give you a wad.
Actually, I also can initialize the BTS genius block in local and test within my PC. How can the test BTS been distributed if p2p feature not yet implemented ?
Sent from my iPhone using Tapatalk (http://tapatalk.com/m?id=1)
-
My BTS address : GyYUzN3scTidqGtSvQZyoyX7Grj
Sent from my iPhone using Tapatalk (http://tapatalk.com/m?id=1)
-
I am in
BTS: GFoNYqtSBwpAojTon3Bj5wcQg5S
If someone would like to volunteer to distribute test BTS while I am off line let me know so I can give you a wad.
-
If someone would like to volunteer to distribute test BTS while I am off line let me know so I can give you a wad.
My BTS test address: HZALzeYWRUVeGAdqCbkxCYanfpL
Please give me some for testing, I could also help distribute when I could access internet, thanks.
-
My BTS address:P2aQJQavh9wJJjEfu5ynqciSHF8
-
162.243.45.158:4567
is above node available for test now?
-
I just sent everyone who posted an address 100 bts.
-
If someone would like to volunteer to distribute test BTS while I am off line let me know so I can give you a wad.
Actually, I also can initialize the BTS genius block in local and test within my PC. How can the test BTS been distributed if p2p feature not yet implemented ?
Sent from my iPhone using Tapatalk (http://tapatalk.com/m?id=1)
The test works with a single client/server model where everyone shares the same server and blockchain there is just no direct P2P communication. The purpose of this test is to validate the blockchain transaction and fancy P2P network code introduces other failure modes that I don't want to debug right now.
-
My test BTS address: NtosiApspKxsLUk5fk6XF4hAapQ
-
My test BTS address: NtosiApspKxsLUk5fk6XF4hAapQ
just sent you 100.
-
I see you all have been doing a few small test transactions... I would encourage everyone to really put it through its paces and help identify ways I can make it more intuitive and or where the result of your commands isn't what you had expected.
-
I posted a 1 PTS bug finding bounty for anyone who can identify a bug in how transactions are being processed on the test chain.
-
If someone would like to volunteer to distribute test BTS while I am off line let me know so I can give you a wad.
Thank you very much! Finally get the code run!
My test address HpKf1otw29QGS1pVRrDfMWFPZJc.
-
If someone would like to volunteer to distribute test BTS while I am off line let me know so I can give you a wad.
My BTS test address: HZALzeYWRUVeGAdqCbkxCYanfpL
Please give me some for testing, I could also help distribute when I could access internet, thanks.
How did you get the BTS testing adress
-
If someone would like to volunteer to distribute test BTS while I am off line let me know so I can give you a wad.
My BTS test address: HZALzeYWRUVeGAdqCbkxCYanfpL
Please give me some for testing, I could also help distribute when I could access internet, thanks.
How did you get the BTS testing adress
Compile from source code (https://github.com/InvictusInnovations), and run bts_wallet.exe, run command "newaddr"
-
BTS:RbV5cSF9BcnsBvxw4UwB8zhEXHX
test.
-
BTS:RbV5cSF9BcnsBvxw4UwB8zhEXHX
test.
just sent you 50 test bts
-
“market bts usd”
“market usd bts”
any different？
-
“market bts usd”
“market usd bts”
any different？
Not right now, but eventually I will simply have it switch the price things are quoted in.
-
Ok... someone created a transaction that broke my market making code.. and my server is dumping this out... I will have to resolve this bug before any new market transactions can go through:
2272621ms th_a blockchain_db.cpp:793 generate_next_block ] unable to use trx {"version":0,"stake":0,"timestamp":"20140121T063752","valid_after":"19700101T000000","valid_until":"19700101T000000","inputs":[{"output_ref":{"trx_hash":"96a8544d7815de22ef839c0cb8b1cb72caddbef0","output_idx":0},"input_data":""},{"output_ref":{"trx_hash":"2f0bd19b8295be1a3d0b1ad786048c490714bdc0","output_idx":0},"input_data":""},{"output_ref":{"trx_hash":"3ecb5d31c839b6e8da03296856534e7a1eade57d","output_idx":0},"input_data":""},{"output_ref":{"trx_hash":"c92a64bcac46aeeae22f9024456998a50f9214f1","output_idx":0},"input_data":""},{"output_ref":{"trx_hash":"579920471e2d25a2bfe59b27f6dfdd236c4b6506","output_idx":0},"input_data":""},{"output_ref":{"trx_hash":"e78356fd23b7ef495f61a266a06eda0c76cfacf8","output_idx":1},"input_data":""},{"output_ref":{"trx_hash":"3f23d2d9e98e8169d9fdb6f4e7050bb83ff7e82b","output_idx":1},"input_data":""},{"output_ref":{"trx_hash":"aebea67e0e26d68e34ddf4ece52ab716dc7f48ed","output_idx":0},"input_data":""}],"outputs":[{"amount":4999999,"unit":"usd","claim_func":"claim_by_signature","claim_data":{"owner":"Gd6kwpfW2h3wHDn86LEECTUR262"}},{"amount":50000000,"unit":"usd","claim_func":"claim_by_signature","claim_data":{"owner":"FbbX77ATPDcWCL1dWqEXcxva9yL"}},{"amount":100000000,"unit":"usd","claim_func":"claim_by_signature","claim_data":{"owner":"PwW5b8ngAjvFU67rPvQ9zQorYNZ"}},{"amount":4999999,"unit":"bts","claim_func":"claim_by_signature","claim_data":{"owner":"R6SnBCFdHMJLEWEdbFNYHJFTv7w"}},{"amount":499999976,"unit":"usd","claim_func":"claim_by_signature","claim_data":{"owner":"MzEHQpCNkMYDmCm4C2M2eiu92dy"}},{"amount":7921000890,"unit":"usd","claim_func":"claim_by_signature","claim_data":{"owner":"JsBgh3pAVyuLiEqnnPV1VAvmRgg"}},{"amount":5000000000,"unit":"usd","claim_func":"claim_by_signature","claim_data":{"owner":"FNA8woJepmELZUdHUMEVqmzNzza"}},{"amount":67522665,"unit":"bts","claim_func":"claim_by_long","claim_data":{"pay_address":"Dw9fjT8FMiEndofTqQ54yg35Ad1","ask_price":"100.0000000000000 usd/bts","min_trade":0}},{"amount":278011998,"unit":"bts","claim_func":"claim_by_cover","claim_data":{"payoff_unit":"usd","payoff_amount":13247733540,"owner":"Dw9fjT8FMiEndofTqQ54yg35Ad1"}}],"sigs":[]}
assert
sig_out != output_not_found: unable to find payment of 5.00000000 usd to MzEHQpCNkMYDmCm4C2M2eiu92dy
{"asset":"5.00000000 usd","pay_addr":"MzEHQpCNkMYDmCm4C2M2eiu92dy","in":{"source":{"block_num":40,"trx_idx":0},"output_num":0,"output":{"amount":10000000,"unit":"bts","claim_func":"claim_by_bid","claim_data":{"pay_address":"MzEHQpCNkMYDmCm4C2M2eiu92dy","ask_price":"50.0000000000000 usd/bts","min_trade":0}},"meta_output":{"trx_id":{"block_num":4294967295,"trx_idx":0},"input_num":255}}}
th_a trx_validation_state.cpp:313 validate_bid
validating bid input {"source":{"block_num":40,"trx_idx":0},"output_num":0,"output":{"amount":10000000,"unit":"bts","claim_func":"claim_by_bid","claim_data":{"pay_address":"MzEHQpCNkMYDmCm4C2M2eiu92dy","ask_price":"50.0000000000000 usd/bts","min_trade":0}},"meta_output":{"trx_id":{"block_num":4294967295,"trx_idx":0},"input_num":255}}
{"i":{"source":{"block_num":40,"trx_idx":0},"output_num":0,"output":{"amount":10000000,"unit":"bts","claim_func":"claim_by_bid","claim_data":{"pay_address":"MzEHQpCNkMYDmCm4C2M2eiu92dy","ask_price":"50.0000000000000 usd/bts","min_trade":0}},"meta_output":{"trx_id":{"block_num":4294967295,"trx_idx":0},"input_num":255}}}
th_a trx_validation_state.cpp:342 validate_bid
error validating input 4
{"i":4}
th_a trx_validation_state.cpp:56 validate
error validating transaction
{"state":{"trx":{"version":0,"stake":0,"timestamp":"20140121T063752","valid_after":"19700101T000000","valid_until":"19700101T000000","inputs":[{"output_ref":{"trx_hash":"96a8544d7815de22ef839c0cb8b1cb72caddbef0","output_idx":0},"input_data":""},{"output_ref":{"trx_hash":"2f0bd19b8295be1a3d0b1ad786048c490714bdc0","output_idx":0},"input_data":""},{"output_ref":{"trx_hash":"3ecb5d31c839b6e8da03296856534e7a1eade57d","output_idx":0},"input_data":""},{"output_ref":{"trx_hash":"c92a64bcac46aeeae22f9024456998a50f9214f1","output_idx":0},"input_data":""},{"output_ref":{"trx_hash":"579920471e2d25a2bfe59b27f6dfdd236c4b6506","output_idx":0},"input_data":""},{"output_ref":{"trx_hash":"e78356fd23b7ef495f61a266a06eda0c76cfacf8","output_idx":1},"input_data":""},{"output_ref":{"trx_hash":"3f23d2d9e98e8169d9fdb6f4e7050bb83ff7e82b","output_idx":1},"input_data":""},{"output_ref":{"trx_hash":"aebea67e0e26d68e34ddf4ece52ab716dc7f48ed","output_idx":0},"input_data":""}],"outputs":[{"amount":4999999,"unit":"usd","claim_func":"claim_by_signature","claim_data":{"owner":"Gd6kwpfW2h3wHDn86LEECTUR262"}},{"amount":50000000,"unit":"usd","claim_func":"claim_by_signature","claim_data":{"owner":"FbbX77ATPDcWCL1dWqEXcxva9yL"}},{"amount":100000000,"unit":"usd","claim_func":"claim_by_signature","claim_data":{"owner":"PwW5b8ngAjvFU67rPvQ9zQorYNZ"}},{"amount":4999999,"unit":"bts","claim_func":"claim_by_signature","claim_data":{"owner":"R6SnBCFdHMJLEWEdbFNYHJFTv7w"}},{"amount":499999976,"unit":"usd","claim_func":"claim_by_signature","claim_data":{"owner":"MzEHQpCNkMYDmCm4C2M2eiu92dy"}},{"amount":7921000890,"unit":"usd","claim_func":"claim_by_signature","claim_data":{"owner":"JsBgh3pAVyuLiEqnnPV1VAvmRgg"}},{"amount":5000000000,"unit":"usd","claim_func":"claim_by_signature","claim_data":{"owner":"FNA8woJepmELZUdHUMEVqmzNzza"}},{"amount":67522665,"unit":"bts","claim_func":"claim_by_long","claim_data":{"pay_address":"Dw9fjT8FMiEndofTqQ54yg35Ad1","ask_price":"100.0000000000000 usd/bts","min_trade":0}},{"amount":278011998,"unit":"bts","claim_func":"claim_by_cover","claim_data":{"payoff_unit":"usd","payoff_amount":13247733540,"owner":"Dw9fjT8FMiEndofTqQ54yg35Ad1"}}],"sigs":[]},"inputs":[{"source":{"block_num":63,"trx_idx":0},"output_num":0,"output":{"amount":50000000,"unit":"bts","claim_func":"claim_by_bid","claim_data":{"pay_address":"Gd6kwpfW2h3wHDn86LEECTUR262","ask_price":"0.1000000000000 usd/bts","min_trade":0}},"meta_output":{"trx_id":{"block_num":4294967295,"trx_idx":0},"input_num":255}},{"source":{"block_num":61,"trx_idx":0},"output_num":0,"output":{"amount":100000000,"unit":"bts","claim_func":"claim_by_bid","claim_data":{"pay_address":"FbbX77ATPDcWCL1dWqEXcxva9yL","ask_price":"0.5000000000000 usd/bts","min_trade":0}},"meta_output":{"trx_id":{"block_num":4294967295,"trx_idx":0},"input_num":255}},{"source":{"block_num":54,"trx_idx":0},"output_num":0,"output":{"amount":100000000,"unit":"bts","claim_func":"claim_by_bid","claim_data":{"pay_address":"PwW5b8ngAjvFU67rPvQ9zQorYNZ","ask_price":"1.0000000000000 usd/bts","min_trade":0}},"meta_output":{"trx_id":{"block_num":4294967295,"trx_idx":0},"input_num":255}},{"source":{"block_num":42,"trx_idx":0},"output_num":0,"output":{"amount":505000000,"unit":"usd","claim_func":"claim_by_bid","claim_data":{"pay_address":"R6SnBCFdHMJLEWEdbFNYHJFTv7w","ask_price":"101.0000000000000 usd/bts","min_trade":0}},"meta_output":{"trx_id":{"block_num":4294967295,"trx_idx":0},"input_num":255}},{"source":{"block_num":40,"trx_idx":0},"output_num":0,"output":{"amount":10000000,"unit":"bts","claim_func":"claim_by_bid","claim_data":{"pay_address":"MzEHQpCNkMYDmCm4C2M2eiu92dy","ask_price":"50.0000000000000 usd/bts","min_trade":0}},"meta_output":{"trx_id":{"block_num":4294967295,"trx_idx":0},"input_num":255}},{"source":{"block_num":37,"trx_idx":0},"output_num":1,"output":{"amount":89000010,"unit":"bts","claim_func":"claim_by_bid","claim_data":{"pay_address":"JsBgh3pAVyuLiEqnnPV1VAvmRgg","ask_price":"89.0000000000000 usd/bts","min_trade":0}},"meta_output":{"trx_id":{"block_num":4294967295,"trx_idx":0},"input_num":255}},{"source":{"block_num":33,"trx_idx":0},"output_num":1,"output":{"amount":50000000,"unit":"bts","claim_func":"claim_by_bid","claim_data":{"pay_address":"FNA8woJepmELZUdHUMEVqmzNzza","ask_price":"100.0000000000000 usd/bts","min_trade":0}},"meta_output":{"trx_id":{"block_num":4294967295,"trx_idx":0},"input_num":255}},{"source":{"block_num":38,"trx_idx":0},"output_num":0,"output":{"amount":200000000,"unit":"bts","claim_func":"claim_by_long","claim_data":{"pay_address":"Dw9fjT8FMiEndofTqQ54yg35Ad1","ask_price":"100.0000000000000 usd/bts","min_trade":0}},"meta_output":{"trx_id":{"block_num":4294967295,"trx_idx":0},"input_num":255}}],"ref_head":65,"balance_sheet":[{"in":"2.60000000 bts","neg_in":"0.00000000 bts","collat_in":"0.00000000 bts","out":"0.00000000 bts","neg_out":"0.00000000 bts","collat_out":"0.00000000 bts"},{"in":"5.05000000 usd","neg_in":"0.00000000 usd","collat_in":"0.00000000 bts","out":"0.00000000 usd","neg_out":"0.00000000 usd","collat_out":"0.00000000 bts"}],"used_outputs":[3,2,1,0],"required_sigs":[],"signed_addresses":[],"dividend_fees":"0.00000000 bts"}}
th_a trx_validation_state.cpp:99 validate
error evaluating transaction {"version":0,"stake":0,"timestamp":"20140121T063752","valid_after":"19700101T000000","valid_until":"19700101T000000","inputs":[{"output_ref":{"trx_hash":"96a8544d7815de22ef839c0cb8b1cb72caddbef0","output_idx":0},"input_data":""},{"output_ref":{"trx_hash":"2f0bd19b8295be1a3d0b1ad786048c490714bdc0","output_idx":0},"input_data":""},{"output_ref":{"trx_hash":"3ecb5d31c839b6e8da03296856534e7a1eade57d","output_idx":0},"input_data":""},{"output_ref":{"trx_hash":"c92a64bcac46aeeae22f9024456998a50f9214f1","output_idx":0},"input_data":""},{"output_ref":{"trx_hash":"579920471e2d25a2bfe59b27f6dfdd236c4b6506","output_idx":0},"input_data":""},{"output_ref":{"trx_hash":"e78356fd23b7ef495f61a266a06eda0c76cfacf8","output_idx":1},"input_data":""},{"output_ref":{"trx_hash":"3f23d2d9e98e8169d9fdb6f4e7050bb83ff7e82b","output_idx":1},"input_data":""},{"output_ref":{"trx_hash":"aebea67e0e26d68e34ddf4ece52ab716dc7f48ed","output_idx":0},"input_data":""}],"outputs":[{"amount":4999999,"unit":"usd","claim_func":"claim_by_signature","claim_data":{"owner":"Gd6kwpfW2h3wHDn86LEECTUR262"}},{"amount":50000000,"unit":"usd","claim_func":"claim_by_signature","claim_data":{"owner":"FbbX77ATPDcWCL1dWqEXcxva9yL"}},{"amount":100000000,"unit":"usd","claim_func":"claim_by_signature","claim_data":{"owner":"PwW5b8ngAjvFU67rPvQ9zQorYNZ"}},{"amount":4999999,"unit":"bts","claim_func":"claim_by_signature","claim_data":{"owner":"R6SnBCFdHMJLEWEdbFNYHJFTv7w"}},{"amount":499999976,"unit":"usd","claim_func":"claim_by_signature","claim_data":{"owner":"MzEHQpCNkMYDmCm4C2M2eiu92dy"}},{"amount":7921000890,"unit":"usd","claim_func":"claim_by_signature","claim_data":{"owner":"JsBgh3pAVyuLiEqnnPV1VAvmRgg"}},{"amount":5000000000,"unit":"usd","claim_func":"claim_by_signature","claim_data":{"owner":"FNA8woJepmELZUdHUMEVqmzNzza"}},{"amount":67522665,"unit":"bts","claim_func":"claim_by_long","claim_data":{"pay_address":"Dw9fjT8FMiEndofTqQ54yg35Ad1","ask_price":"100.0000000000000 usd/bts","min_trade":0}},{"amount":278011998,"unit":"bts","claim_func":"claim_by_cover","claim_data":{"payoff_unit":"usd","payoff_amount":13247733540,"owner":"Dw9fjT8FMiEndofTqQ54yg35Ad1"}}],"sigs":[]}
{"t":{"version":0,"stake":0,"timestamp":"20140121T063752","valid_after":"19700101T000000","valid_until":"19700101T000000","inputs":[{"output_ref":{"trx_hash":"96a8544d7815de22ef839c0cb8b1cb72caddbef0","output_idx":0},"input_data":""},{"output_ref":{"trx_hash":"2f0bd19b8295be1a3d0b1ad786048c490714bdc0","output_idx":0},"input_data":""},{"output_ref":{"trx_hash":"3ecb5d31c839b6e8da03296856534e7a1eade57d","output_idx":0},"input_data":""},{"output_ref":{"trx_hash":"c92a64bcac46aeeae22f9024456998a50f9214f1","output_idx":0},"input_data":""},{"output_ref":{"trx_hash":"579920471e2d25a2bfe59b27f6dfdd236c4b6506","output_idx":0},"input_data":""},{"output_ref":{"trx_hash":"e78356fd23b7ef495f61a266a06eda0c76cfacf8","output_idx":1},"input_data":""},{"output_ref":{"trx_hash":"3f23d2d9e98e8169d9fdb6f4e7050bb83ff7e82b","output_idx":1},"input_data":""},{"output_ref":{"trx_hash":"aebea67e0e26d68e34ddf4ece52ab716dc7f48ed","output_idx":0},"input_data":""}],"outputs":[{"amount":4999999,"unit":"usd","claim_func":"claim_by_signature","claim_data":{"owner":"Gd6kwpfW2h3wHDn86LEECTUR262"}},{"amount":50000000,"unit":"usd","claim_func":"claim_by_signature","claim_data":{"owner":"FbbX77ATPDcWCL1dWqEXcxva9yL"}},{"amount":100000000,"unit":"usd","claim_func":"claim_by_signature","claim_data":{"owner":"PwW5b8ngAjvFU67rPvQ9zQorYNZ"}},{"amount":4999999,"unit":"bts","claim_func":"claim_by_signature","claim_data":{"owner":"R6SnBCFdHMJLEWEdbFNYHJFTv7w"}},{"amount":499999976,"unit":"usd","claim_func":"claim_by_signature","claim_data":{"owner":"MzEHQpCNkMYDmCm4C2M2eiu92dy"}},{"amount":7921000890,"unit":"usd","claim_func":"claim_by_signature","claim_data":{"owner":"JsBgh3pAVyuLiEqnnPV1VAvmRgg"}},{"amount":5000000000,"unit":"usd","claim_func":"claim_by_signature","claim_data":{"owner":"FNA8woJepmELZUdHUMEVqmzNzza"}},{"amount":67522665,"unit":"bts","claim_func":"claim_by_long","claim_data":{"pay_address":"Dw9fjT8FMiEndofTqQ54yg35Ad1","ask_price":"100.0000000000000 usd/bts","min_trade":0}},{"amount":278011998,"unit":"bts","claim_func":"claim_by_cover","claim_data":{"payoff_unit":"usd","payoff_amount":13247733540,"owner":"Dw9fjT8FMiEndofTqQ54yg35Ad1"}}],"sigs":[]}}
th_a blockchain_db.cpp:663 evaluate_signed_transaction
-
Today I was pulled off of BitShares X development to focus on marketing and preps for Miami. You can check out my latest updates to invictus.io here:
http://invictus.io/
Tell me what you think of the updated website.
-
Today I was pulled off of BitShares X development to focus on marketing and preps for Miami. You can check out my latest updates to invictus.io here:
http://invictus.io/
Tell me what you think of the updated website.
I like it!!!
-
Built BitShares git source tree like a charm. I am really excited! Can someone send me some test BTS?
My BTS test address: MwMaVA8rVc2vgjnKN7nfW2kMtt7
-
Today I was pulled off of BitShares X development to focus on marketing and preps for Miami. You can check out my latest updates to invictus.io here:
http://invictus.io/
Tell me what you think of the updated website.
how many developer are working for BTS
AGS received a lot of PTS & BTC, should hire more developer for BTS.
AGS fund spend some PTS/BTS on Keyhotee, can you clarify the relationship between AGS and Keyotee?
-
Today I was pulled off of BitShares X development to focus on marketing and preps for Miami. You can check out my latest updates to invictus.io here:
http://invictus.io/
Tell me what you think of the updated website.
Good work! I like the intro feeling.
The "Reimagine Everything" title could be more smooth (cheesy fadein?), the font seems too plain for the audacious title. The three logos (bitshares, keyhotee, and bitshares conference) could be clickable, and perhaps bitshares conferences could be placed in a separate zone below bitshares and keyhotee (the logos could perhaps be larger also). Perhaps golden ratio between earthpic and the logo space. Our studio/contact/info could be more aesthetic, it feels like a barren end to the page, and if i click the wiki there's no real interesting information. "Contact us" could be its own stylized element "contact us!"
With a pinch of salt, I am not in any way an artist, and don't even know how this would look. But these are details, it's certainly good enough now. You might use your time better on BTS!
All the best!
-
would someone please sent me some test BTS to my BTS test address:Qumec4L6VLtpvCzAWcDtcV8Qptr ? thanks
-
have send you 100 bts
Built BitShares git source tree like a charm. I am really excited! Can someone send me some test BTS?
My BTS test address: MwMaVA8rVc2vgjnKN7nfW2kMtt7
-
100 bts to you
would someone please sent me some test BTS to my BTS test address:Qumec4L6VLtpvCzAWcDtcV8Qptr ? thanks
-
Ok... someone created a transaction that broke my market making code.. and my server is dumping this out... I will have to resolve this bug before any new market transactions can go through:
I'm afraid this transaction is created by me lol..
(https://dl.dropboxusercontent.com/u/5037011/bts_bug_002.png)
And I think this bug may caused by float round problems on client side? 10000000 * 50 - 499999976 >= 5
ilog( "delta ${d}", ("d",delta) );
if( abs(delta) < 5 && trx.outputs[i].unit == bal.unit )
{
if( trx.outputs[i].as<claim_by_signature_output>().owner == owner )
{
return i;
}
}
{"state":{"trx":{
"version":0,
"stake":0,
"timestamp":"20140121T063752",
"valid_after":"19700101T000000",
"valid_until":"19700101T000000",
"inputs":[
{"output_ref":{"trx_hash":"96a8544d7815de22ef839c0cb8b1cb72caddbef0","output_idx":0},"input_data":""},
{"output_ref":{"trx_hash":"2f0bd19b8295be1a3d0b1ad786048c490714bdc0","output_idx":0},"input_data":""},
{"output_ref":{"trx_hash":"3ecb5d31c839b6e8da03296856534e7a1eade57d","output_idx":0},"input_data":""},
{"output_ref":{"trx_hash":"c92a64bcac46aeeae22f9024456998a50f9214f1","output_idx":0},"input_data":""},
"output_ref":{"trx_hash":"579920471e2d25a2bfe59b27f6dfdd236c4b6506","output_idx":0},"input_data":""},
{"output_ref":{"trx_hash":"e78356fd23b7ef495f61a266a06eda0c76cfacf8","output_idx":1},"input_data":""},
{"output_ref":{"trx_hash":"3f23d2d9e98e8169d9fdb6f4e7050bb83ff7e82b","output_idx":1},"input_data":""},
{"output_ref":{"trx_hash":"aebea67e0e26d68e34ddf4ece52ab716dc7f48ed","output_idx":0},"input_data":""}],
"outputs":[
{"amount":4999999,"unit":"usd","claim_func":"claim_by_signature","claim_data":{"owner":"Gd6kwpfW2h3wHDn86LEECTUR262"}},
{"amount":50000000,"unit":"usd","claim_func":"claim_by_signature","claim_data":{"owner":"FbbX77ATPDcWCL1dWqEXcxva9yL"}},
{"amount":100000000,"unit":"usd","claim_func":"claim_by_signature","claim_data":{"owner":"PwW5b8ngAjvFU67rPvQ9zQorYNZ"}},
{"amount":4999999,"unit":"bts","claim_func":"claim_by_signature","claim_data":{"owner":"R6SnBCFdHMJLEWEdbFNYHJFTv7w"}},
{"amount":499999976,"unit":"usd","claim_func":"claim_by_signature","claim_data":{"owner":"MzEHQpCNkMYDmCm4C2M2eiu92dy"}},
{"amount":7921000890,"unit":"usd","claim_func":"claim_by_signature","claim_data":{"owner":"JsBgh3pAVyuLiEqnnPV1VAvmRgg"}},
{"amount":5000000000,"unit":"usd","claim_func":"claim_by_signature","claim_data":{"owner":"FNA8woJepmELZUdHUMEVqmzNzza"}},
{"amount":67522665,"unit":"bts","claim_func":"claim_by_long","claim_data":{"pay_address":"Dw9fjT8FMiEndofTqQ54yg35Ad1","ask_price":"100.0000000000000 usd/bts","min_trade":0}},
{"amount":278011998,"unit":"bts","claim_func":"claim_by_cover","claim_data":{"payoff_unit":"usd","payoff_amount":13247733540,"owner":"Dw9fjT8FMiEndofTqQ54yg35Ad1"}}],
"sigs":[]},
"inputs":[
{"source":{"block_num":63,"trx_idx":0},"output_num":0,
"output":{"amount":50000000,"unit":"bts","claim_func":"claim_by_bid",
"claim_data":{"pay_address":"Gd6kwpfW2h3wHDn86LEECTUR262","ask_price":"0.1000000000000 usd/bts","min_trade":0}},
"meta_output":{"trx_id":{"block_num":4294967295,"trx_idx":0},"input_num":255}},
{"source":{"block_num":61,"trx_idx":0},"output_num":0,"output":{"amount":100000000,"unit":"bts","claim_func":"claim_by_bid",
"claim_data":{"pay_address":"FbbX77ATPDcWCL1dWqEXcxva9yL","ask_price":"0.5000000000000 usd/bts","min_trade":0}},
"meta_output":{"trx_id":{"block_num":4294967295,"trx_idx":0},"input_num":255}},{"source":{"block_num":54,"trx_idx":0},
"output_num":0,"output":{"amount":100000000,"unit":"bts","claim_func":"claim_by_bid","claim_data":{"pay_address":"PwW5b8ngAjvFU67rPvQ9zQorYNZ","ask_price":"1.0000000000000 usd/bts","min_trade":0}},
"meta_output":{"trx_id":{"block_num":4294967295,"trx_idx":0},"input_num":255}},{"source":{"block_num":42,"trx_idx":0},"output_num":0,
"output":{"amount":505000000,"unit":"usd","claim_func":"claim_by_bid","claim_data":{"pay_address":"R6SnBCFdHMJLEWEdbFNYHJFTv7w","ask_price":"101.0000000000000 usd/bts","min_trade":0}},
"meta_output":{"trx_id":{"block_num":4294967295,"trx_idx":0},"input_num":255}},{"source":{"block_num":40,"trx_idx":0},
"output_num":0,"output":{"amount":10000000,"unit":"bts","claim_func":"claim_by_bid",
"claim_data":{"pay_address":"MzEHQpCNkMYDmCm4C2M2eiu92dy","ask_price":"50.0000000000000 usd/bts","min_trade":0}},"meta_output":{"trx_id":{"block_num":4294967295,"trx_idx":0},"input_num":255}},{"source":{"block_num":37,"trx_idx":0},"output_num":1,"output":{"amount":89000010,"unit":"bts","claim_func":"claim_by_bid","claim_data":{"pay_address":"JsBgh3pAVyuLiEqnnPV1VAvmRgg","ask_price":"89.0000000000000 usd/bts","min_trade":0}},"meta_output":{"trx_id":{"block_num":4294967295,"trx_idx":0},"input_num":255}},{"source":{"block_num":33,"trx_idx":0},"output_num":1,"output":{"amount":50000000,"unit":"bts","claim_func":"claim_by_bid","claim_data":{"pay_address":"FNA8woJepmELZUdHUMEVqmzNzza","ask_price":"100.0000000000000 usd/bts","min_trade":0}},"meta_output":{"trx_id":{"block_num":4294967295,"trx_idx":0},"input_num":255}},{"source":{"block_num":38,"trx_idx":0},"output_num":0,"output":{"amount":200000000,"unit":"bts","claim_func":"claim_by_long","claim_data":{"pay_address":"Dw9fjT8FMiEndofTqQ54yg35Ad1","ask_price":"100.0000000000000 usd/bts","min_trade":0}},"meta_output":{"trx_id":{"block_num":4294967295,"trx_idx":0},"input_num":255}}],"ref_head":65,"balance_sheet":[{"in":"2.60000000 bts","neg_in":"0.00000000 bts","collat_in":"0.00000000 bts","out":"0.00000000 bts","neg_out":"0.00000000 bts","collat_out":"0.00000000 bts"},{"in":"5.05000000 usd","neg_in":"0.00000000 usd","collat_in":"0.00000000 bts","out":"0.00000000 usd","neg_out":"0.00000000 usd","collat_out":"0.00000000 bts"}],
"used_outputs":[3,2,1,0],"required_sigs":[],"signed_addresses":[],"dividend_fees":"0.00000000 bts"}}
-
My BTS address: K3vor6u1oZJqe3Sw2neYHe7mZ11
Can someone send me some bts to play around. Thanks.
-
BTS:RbV5cSF9BcnsBvxw4UwB8zhEXHX
test.
just sent you 50 test bts
Thanks.
-
Today I was pulled off of BitShares X development to focus on marketing and preps for Miami. You can check out my latest updates to invictus.io here:
http://invictus.io/
Tell me what you think of the updated website.
New website is great!
-
My BTS address: K3vor6u1oZJqe3Sw2neYHe7mZ11
Can someone send me some bts to play around. Thanks.
just sent 50
-
At last, I made it.
My BTS address:
KJYjUPaErE4XUXiRoTFrbQKzNRD
Please someone send me some BTS.
-
At last, I made it.
My BTS address:
KJYjUPaErE4XUXiRoTFrbQKzNRD
Please someone send me some BTS.
Just sent you 5 bts. Have fun :D
-
At last, I made it.
My BTS address:
KJYjUPaErE4XUXiRoTFrbQKzNRD
Please someone send me some BTS.
Just sent you 5 bts. Have fun :D
I saw it before your post. Thank you ha : D
Could someone else give me some, too?
-
At last, I made it.
My BTS address:
KJYjUPaErE4XUXiRoTFrbQKzNRD
Please someone send me some BTS.
Just sent you 5 bts. Have fun :D
I saw it before your post. Thank you ha : D
Could someone else give me some, too?
just sent you 10 BTS,pls chech.
Sent from my iPhone using Tapatalk (http://tapatalk.com/m?id=1)
-
At last, I made it.
My BTS address:
KJYjUPaErE4XUXiRoTFrbQKzNRD
Please someone send me some BTS.
Just sent you 5 bts. Have fun :D
I saw it before your post. Thank you ha : D
Could someone else give me some, too?
just sent you 10 BTS,pls chech.
Sent from my iPhone using Tapatalk (http://tapatalk.com/m?id=1)
Thank you! :)
-
Today I was pulled off of BitShares X development to focus on marketing and preps for Miami. You can check out my latest updates to invictus.io here:
http://invictus.io/
Tell me what you think of the updated website.
New website is great!
I like it.
I lite the arts, the intro texts, symbol image and style.
Wish you good journey to Miami.
-
The network is stalled on a transaction validation error... I will let you know when transfers can resume.
-
The network is stalled on a transaction validation error... I will let you know when transfers can resume.
I can only see bids, shorts of myself and no others sell/buy info. Is this right?
-
The network is stalled on a transaction validation error... I will let you know when transfers can resume.
I can only see bids, shorts of myself and no others sell/buy info. Is this right?
Forget about it. I can see the whole market info after using command "market".
-
Today I was pulled off of BitShares X development to focus on marketing and preps for Miami. You can check out my latest updates to invictus.io here:
http://invictus.io/
Tell me what you think of the updated website.
Me like
-
I'm a fan of the latest invictus.io update as well! Here's some off the cuff feedback:
- I like the sunrise image on the home page, the dawn-of-a-new-day message is pretty easy to pick up on.
- The banner image on the Keyhotee page seems a bit fuzzy, maybe the resolution is a bit low?
- I am not 100% sold on the Keyhotee logo, simply because it does not look modern when juxtaposed with the BitShares logos (which happen to look fantastic)!
Despite my (very) minor gripes, I gotta say the page is looking much better. You guys are gonna kill it in Miami!
-
What a good status updates from development team !!
I finally get compiled wallet on ubuntu.
Can someone send me some test bitshares on my address GRukroLpAKRgPAQcmsbY4EKJaMM ?
-
BTS:RbV5cSF9BcnsBvxw4UwB8zhEXHX
test.
just sent you 50 test bts
Rollbacked?
Thanks.
-
My BTS address: SZn1p93TB31TWUJLmMdnMuDP8Jp
thx
Does the Bitshares code in git make keyhotee fail to build?
-
I have successfully compiled bitshares x on ubuntu 12.04. My address is:
HD98kN9Y3Hhep7ysGa1drLdR7ft
BTW, how can I view my generated addresses in the bts_wallet client?
-
Today I made no progress on BitShares X development, but our website has seen some more major updates.
BitShares vs Bitcoin
http://invictus.io/bitshares.php
Updated AGS Page
http://invictus.io/bitshares-ags.php
Checkout the counter!
-
My BTS address: K3vor6u1oZJqe3Sw2neYHe7mZ11
Can someone send me some bts to play around. Thanks.
just sent 50
thanks, got them
-
Sorry if this question is already answered somewhere in the forum but I just cant seem to find it. How do I actually get the BitShares client and how do I point my PTS address so that I can claim my BTS?
-
Sorry if this question is already answered somewhere in the forum but I just cant seem to find it. How do I actually get the BitShares client and how do I point my PTS address so that I can claim my BTS?
Actually, this is alpha test period. If you can compile the bitshares client code from here(https://github.com/InvictusInnovations/BitShares), you will join the testing.
Put your testing BTS address in this thread and someone will send you some test BTS to play around(not the real BTS unless the official Bitshares Client is released).
-
This is what I thought but was not sure. Thank you for clearing that out. I might join BTS alfa testing.
-
Today I made no progress on BitShares X development, but our website has seen some more major updates.
BitShares vs Bitcoin
http://invictus.io/bitshares.php
Updated AGS Page
http://invictus.io/bitshares-ags.php
Checkout the counter!
Good job.
May it bring us nice PR.
Sent from my iPhone using Tapatalk
-
Do I have to backup privkey before rebuild bts? Which file?
Sent from my iPhone using Tapatalk
-
Do I have to backup privkey before rebuild bts? Which file?
Sent from my iPhone using Tapatalk
not required if not clean build,but better to backup the wallet ,the wallet file is /bitshares/bts_wallet/release/datadir/wallet.bts
Sent from my iPhone using Tapatalk (http://tapatalk.com/m?id=1)
-
Please, can anybody send me some playing-BTS for testing?
GrKE9fvsiWrEJQX6UCAZaXParzu
Thanks!
-
is sending testing BTS terminated already? I have not received anything yet.
-
Im new to bitshares but am very enthusiastic about its potential as well as the potential of subsequent DACs. I'd like to invest however Im uncertain about the relative development stages of bitshares and its future competitors mastercoin and nxt. I particularly like the transparency of this company in comparison to the development of the other teams. I think that the idea of limiting 16 assets to a block makes bitshares more scalable than mastercoin which might be trying to do to much with the bit coin blockchain itself. It is also a good selling point for investors in pts and ags because they get a stake in each block chain. So im pretty much sold on bitshares over mastercoin, although i do like the idea of overlaying protocols in the same way as the internet. But im not entirely sure how nxt and bitshares differ. Nxt seems to provide the same services as invictus. Since i don't fully understand the technical aspects of transparent forging i am convinced that its either a great innovation that helps with scalability or its an equally great flaw the threatens the security of the block chain. Mr. Larimer, I know that you have said that you do not want to provide estimates on the timeframe of development but could you at all speculate on your companies relative stage of development when compared to your competitors. Additionally, I would like some clarity on the networks ability to store value, the fundamental problem with bitcoin. If i have read correctly, in order to lend bitassets into existence the client must have twice as much collateral in bitshares. If that is the case, ones money only gains half the stability of whatever their preferred assets might be while still maintaining half the volatility of bitshares. I imagine that bitshares could be more stable than bitcoin but its price is still a rather unpredictable variable. If i have indeed misunderstood and the collateral is only held for short positions then how can you guarantee that each long is paired to a short as i believe i have seen you state? Lastly this might be a stupid idea but in order to facilitate the adoption of bitshares is it possible to distinguish each new node so as to allocate bitshares amongst new users. I understand that you have switched to proof of stake and do not want to dilute ags and pts holders stake in the DAC but for the purposes of adoption, particularly because of the difficulty in acquiring bitcoin
Sent from my RM-917_nam_usa_100 using Tapatalk
-
And moreover the added difficulty and uncertainty in acquiring alt coins like pts. This promotional scheme would only be employed for a limited amount of time but would but both assuage concerns that bitshares is a ponzi scheme - i don't believe this but i have seen this argued- as well as help with adoption in a place like china where there is a fervent crypto community and even more fervently opposed government.
Sent from my RM-917_nam_usa_100 using Tapatalk
-
I have downloaded and compiled the source codes of bitshares X, and it works on my computer now. I am glad to see the initial version of the BTS product! It is a nice work!
I want to ask how to further participate in the alpha testing. How to interact with the other BTS testers? And where should I send suggestions/bugs to?
So far I have the following suggestions:
1. to compile the source code, except for the specified required packages, readline package is also needed. On ubuntu 12.04, I need to install libreadline-dev to make the compilation complete.
2. it is not clearly written down on how to use the software after successful compilation. e.g. two binary files (bts_server, bts_wallet) are generated, but users do not understand what bts_server stands for unless reading the source code. A brief introduction on how to use the software is preferred.
3. in bts_wallet, I find it impossible to get my private key.
4. although I can generate as many new addresses as I want, I cannot view these addresses again from bts_wallet. Please advise on how to view these address if I want to use it again.
Until now I have not received any test BTS yet. my addresses: HD98kN9Y3Hhep7ysGa1drLdR7ft
-
Im new to bitshares but am very enthusiastic about its potential as well as the potential of subsequent DACs. I'd like to invest however Im uncertain about the relative development stages of bitshares and its future competitors mastercoin and nxt. I particularly like the transparency of this company in comparison to the development of the other teams. I think that the idea of limiting 16 assets to a block makes bitshares more scalable than mastercoin which might be trying to do to much with the bit coin blockchain itself. It is also a good selling point for investors in pts and ags because they get a stake in each block chain. So im pretty much sold on bitshares over mastercoin, although i do like the idea of overlaying protocols in the same way as the internet. But im not entirely sure how nxt and bitshares differ. Nxt seems to provide the same services as invictus. Since i don't fully understand the technical aspects of transparent forging i am convinced that its either a great innovation that helps with scalability or its an equally great flaw the threatens the security of the block chain. Mr. Larimer, I know that you have said that you do not want to provide estimates on the timeframe of development but could you at all speculate on your companies relative stage of development when compared to your competitors. Additionally, I would like some clarity on the networks ability to store value, the fundamental problem with bitcoin. If i have read correctly, in order to lend bitassets into existence the client must have twice as much collateral in bitshares. If that is the case, ones money only gains half the stability of whatever their preferred assets might be while still maintaining half the volatility of bitshares. I imagine that bitshares could be more stable than bitcoin but its price is still a rather unpredictable variable. If i have indeed misunderstood and the collateral is only held for short positions then how can you guarantee that each long is paired to a short as i believe i have seen you state? Lastly this might be a stupid idea but in order to facilitate the adoption of bitshares is it possible to distinguish each new node so as to allocate bitshares amongst new users. I understand that you have switched to proof of stake and do not want to dilute ags and pts holders stake in the DAC but for the purposes of adoption, particularly because of the difficulty in acquiring bitcoin
Sent from my RM-917_nam_usa_100 using Tapatalk
Welcome to our forum. I post daily updates in this thread regarding the status of our development. I am glad you already see the scalability issues of everyone else attempting to do everything in a single chain. My sources tell me that Nxt is starting to encourage clones like we will.
Here is my analysis of Nxt's proof-of-stake system.... it is very good, perhaps the best of all 'mining' coins. Despite being proof-of-stake, Nxt still uses mining to decide who produces blocks and pays transaction fees to the miners. As far as I can tell, only Ripple and BitShares pay dividends to 'shareholders' where as everyone else either dilutes share holders or pays 100% of revenue to miners.
I consider Ripple style consensus to be superior to Nxt's approach for any blockchain that implements markets. The reason for this is that mining centralizes control of block contents one block at a time and in the case of Nxt... that miner has a high probability of knowing when they will get to select transactions and thus they can gain a market advantage. There is also block propagation delay.
Nxt assets are more like colored coins than decentralized market-pegged digital assets.
If I were a betting man I would consider myself more of the Steve Jobs of the Crypto industry with a strong sense of the importance of ease of use and Brian Page will probably become know as one of the leading marketers in the Bitcoin space as his work bears fruit over the course of the next several months.
Your understanding of BitAssets and how their peg works is incomplete, but there are other threads in this forum that will answer your questions. Effectively, if my understanding of economics is correct, BitUSD will fluctuate between +/-5% of the USD price depending upon relative flow into and out of the network. Much more stable than you believe.
As for our current development status, I would wager that we will have a minimal viable product out on the market prior to Mastercoin, Ethereum. Our products are different in function than Nxt and others and thus these other coins do not provide the same service and utility. In other words, they are selling cars and we are selling trucks.... while they both provide transportation they serve different markets. I think our market is bigger ;)
One major difference between us and the competition is that we have a half dozen different DAC models and more on our roadmap. Investing in AGS or PTS gives you so many ways to pivot where as investing in the competition gives you much less diversity.
Compared to the competition I believe we are currently the 2nd best capitalized (Mastercoin has more money due to getting their BTC prior to the 10x gain)... but with AGS I expect that we will excede Mastercoin's funding level before the Beyond Bitcoin Conference we are putting on in July.
No one else is doing dividends but Invictus and dividends will make all the difference in the years ahead.
-
I have downloaded and compiled the source codes of bitshares X, and it works on my computer now. I am glad to see the initial version of the BTS product! It is a nice work!
I want to ask how to further participate in the alpha testing. How to interact with the other BTS testers? And where should I send suggestions/bugs to?
So far I have the following suggestions:
1. to compile the source code, except for the specified required packages, readline package is also needed. On ubuntu 12.04, I need to install libreadline-dev to make the compilation complete.
2. it is not clearly written down on how to use the software after successful compilation. e.g. two binary files (bts_server, bts_wallet) are generated, but users do not understand what bts_server stands for unless reading the source code. A brief introduction on how to use the software is preferred.
3. in bts_wallet, I find it impossible to get my private key.
4. although I can generate as many new addresses as I want, I cannot view these addresses again from bts_wallet. Please advise on how to view these address if I want to use it again.
Until now I have not received any test BTS yet. my addresses: HD98kN9Y3Hhep7ysGa1drLdR7ft
The initial testing period is temporarily suspended until I fix a few bugs that have come up. The next testing period will come with more robust instructions, binaries, etc.
I would appreciate help from the community in documenting how to use the tools because there is a lot of work to be done and that will slow me down.
-
Ok, I have identified the problem that was hanging the blockchain market... more rounding issues. The problem arises when I have to revalidate price calculations using rounded or truncated data. There is no way around the fact that information has been lost and thus the validation step has to be 'fuzzy'.
My 'quick fix' was to increase the epsilon I use for comparing claim_by_cover outputs as the rounding error was 870 satoshi in this instance. This means I have to choose between lower meaningful divisibility or switching over to 128 bit numbers for all balances. I can then ignore the lower 64 bits for comparison purposes but still use them for price multiplication purposes. This would add an average of 16 bytes per bid/ask and keep all of the rounding errors so small as to be inconsequential. Perhaps 1000 satoshi is inconsequential for all practical purposes.
The changes required to fix this problem will require all testers to recompile and break the blockchain.
If you want to process the current blockchain you will have to update and recompile your client otherwise your client will fail to validate the hacked solution. After Miami I will probably convert all amounts over to 128 bit numbers and just eat the bandwidth and storage costs to provide reliable and meaningful calculations.
-
Ok, I have identified the problem that was hanging the blockchain market... more rounding issues. The problem arises when I have to revalidate price calculations using rounded or truncated data. There is no way around the fact that information has been lost and thus the validation step has to be 'fuzzy'.
My 'quick fix' was to increase the epsilon I use for comparing claim_by_cover outputs as the rounding error was 870 satoshi in this instance. This means I have to choose between lower meaningful divisibility or switching over to 128 bit numbers for all balances. I can then ignore the lower 64 bits for comparison purposes but still use them for price multiplication purposes. This would add an average of 16 bytes per bid/ask and keep all of the rounding errors so small as to be inconsequential. Perhaps 1000 satoshi is inconsequential for all practical purposes.
The changes required to fix this problem will require all testers to recompile and break the blockchain.
If you want to process the current blockchain you will have to update and recompile your client otherwise your client will fail to validate the hacked solution. After Miami I will probably convert all amounts over to 128 bit numbers and just eat the bandwidth and storage costs to provide reliable and meaningful calculations.
Thanks for all the updates and good luck at the conference
-
My sources tell me that Nxt is starting to encourage clones like we will.
Hi Dan, I dont doubt the reliability of your sources, however there have been trolls targeting Nxt and all those so called clones are nothing but trolls haha. I have stakes in both bts and nxt, so i follow the thread quite closely ;)
-
Ok, I have identified the problem that was hanging the blockchain market... more rounding issues. The problem arises when I have to revalidate price calculations using rounded or truncated data. There is no way around the fact that information has been lost and thus the validation step has to be 'fuzzy'.
My 'quick fix' was to increase the epsilon I use for comparing claim_by_cover outputs as the rounding error was 870 satoshi in this instance. This means I have to choose between lower meaningful divisibility or switching over to 128 bit numbers for all balances. I can then ignore the lower 64 bits for comparison purposes but still use them for price multiplication purposes. This would add an average of 16 bytes per bid/ask and keep all of the rounding errors so small as to be inconsequential. Perhaps 1000 satoshi is inconsequential for all practical purposes.
The changes required to fix this problem will require all testers to recompile and break the blockchain.
If you want to process the current blockchain you will have to update and recompile your client otherwise your client will fail to validate the hacked solution. After Miami I will probably convert all amounts over to 128 bit numbers and just eat the bandwidth and storage costs to provide reliable and meaningful calculations.
Nice work!
The latest source requires berkeleydb c++ library. In ubuntu, I installed libdb++-dev to make the compilation pass.
My new BTS address is: SGspNwacutDySLyC8h4x1gMXNHD
-
I have downloaded and compiled the source codes of bitshares X, and it works on my computer now. I am glad to see the initial version of the BTS product! It is a nice work!
I want to ask how to further participate in the alpha testing. How to interact with the other BTS testers? And where should I send suggestions/bugs to?
So far I have the following suggestions:
1. to compile the source code, except for the specified required packages, readline package is also needed. On ubuntu 12.04, I need to install libreadline-dev to make the compilation complete.
2. it is not clearly written down on how to use the software after successful compilation. e.g. two binary files (bts_server, bts_wallet) are generated, but users do not understand what bts_server stands for unless reading the source code. A brief introduction on how to use the software is preferred.
3. in bts_wallet, I find it impossible to get my private key.
4. although I can generate as many new addresses as I want, I cannot view these addresses again from bts_wallet. Please advise on how to view these address if I want to use it again.
Until now I have not received any test BTS yet. my addresses: HD98kN9Y3Hhep7ysGa1drLdR7ft
The initial testing period is temporarily suspended until I fix a few bugs that have come up. The next testing period will come with more robust instructions, binaries, etc.
I would appreciate help from the community in documenting how to use the tools because there is a lot of work to be done and that will slow me down.
Thks a lot. It readline troubled me for several hours.Now i make it.
My bts addresses:MwqnmRTubvptyorR1F7kGPVqgWC
-
Ok, I have identified the problem that was hanging the blockchain market... more rounding issues. The problem arises when I have to revalidate price calculations using rounded or truncated data. There is no way around the fact that information has been lost and thus the validation step has to be 'fuzzy'.
My 'quick fix' was to increase the epsilon I use for comparing claim_by_cover outputs as the rounding error was 870 satoshi in this instance. This means I have to choose between lower meaningful divisibility or switching over to 128 bit numbers for all balances. I can then ignore the lower 64 bits for comparison purposes but still use them for price multiplication purposes. This would add an average of 16 bytes per bid/ask and keep all of the rounding errors so small as to be inconsequential. Perhaps 1000 satoshi is inconsequential for all practical purposes.
The changes required to fix this problem will require all testers to recompile and break the blockchain.
If you want to process the current blockchain you will have to update and recompile your client otherwise your client will fail to validate the hacked solution. After Miami I will probably convert all amounts over to 128 bit numbers and just eat the bandwidth and storage costs to provide reliable and meaningful calculations.
Why don't you use two numbers to represent a quotients ?
This way you won't have rounding errors, and no need to deal with them !
The calculus will just be made on the UI for display purpose.
-
That has equal space and rounding issues.
Sent from my iPhone using Tapatalk (http://tapatalk.com/m?id=1)
-
hang again? reproduce:
1. short 1000usd , price 1000 usd/bts
2. buy 1000usd, price 0.0015 bts/usd
Ok, I have identified the problem that was hanging the blockchain market... more rounding issues. The problem arises when I have to revalidate price calculations using rounded or truncated data. There is no way around the fact that information has been lost and thus the validation step has to be 'fuzzy'.
My 'quick fix' was to increase the epsilon I use for comparing claim_by_cover outputs as the rounding error was 870 satoshi in this instance. This means I have to choose between lower meaningful divisibility or switching over to 128 bit numbers for all balances. I can then ignore the lower 64 bits for comparison purposes but still use them for price multiplication purposes. This would add an average of 16 bytes per bid/ask and keep all of the rounding errors so small as to be inconsequential. Perhaps 1000 satoshi is inconsequential for all practical purposes.
The changes required to fix this problem will require all testers to recompile and break the blockchain.
If you want to process the current blockchain you will have to update and recompile your client otherwise your client will fail to validate the hacked solution. After Miami I will probably convert all amounts over to 128 bit numbers and just eat the bandwidth and storage costs to provide reliable and meaningful calculations.
-
I have just compiled bitshares on my Mac.
My address is: MQreWtLDLAzZDZPD9tAiRjoDUSw
Please give me some bitshares for testing so I can start play :)
-
I have lose all my bts after a make clean :((
fortunately I have a backup, and left some bitusd, 100 bitusd have transfer to you
I have just compiled bitshares on my Mac.
My address is: MQreWtLDLAzZDZPD9tAiRjoDUSw
Please give me some bitshares for testing so I can start play :)
-
Can someone give me a small amount of BTS? Please~
address:MwqnmRTubvptyorR1F7kGPVqgWC
-
Just sent 100 usd
Can someone give me a small amount of BTS? Please~
address:MwqnmRTubvptyorR1F7kGPVqgWC
-
Thanks a lot! So my first command will backup my wallet.bts ;)
I have lose all my bts after a make clean :((
fortunately I have a backup, and left some bitusd, 100 bitusd have transfer to you
I have just compiled bitshares on my Mac.
My address is: MQreWtLDLAzZDZPD9tAiRjoDUSw
Please give me some bitshares for testing so I can start play :)
-
please send me some bts to play with, I have been waiting for several days but got no update...
my bts wallet is: SGspNwacutDySLyC8h4x1gMXNHD
-
I tried to send you some usd but I got this error:
cmd: transfer 10 usd to SGspNwacutDySLyC8h4x1gMXNHD
Output:
-----------------------------------------------
assert
!"Unable to collect sufficient unspent inputs":
{"min_amnt":"0.00000000 bts","total_collected":"0.00000000 bts"}
th_a blockchain_wallet.cpp:97 collect_inputs
10.00000000 usd to SGspNwacutDySLyC8h4x1gMXNHD
{"amnt":"10.00000000 usd","to":"SGspNwacutDySLyC8h4x1gMXNHD"}
th_a blockchain_wallet.cpp:336 transfer
-----------------------------------------------
My balance before the transfer command is:
0.00000000 bts
100.00000000 usd
But after the transfer command is:
0.00000000 bts
0.00000000 usd
If i close the client and reopen it I obtain again 100 usd of balance.
Could the problem arise because I have no bts?
please send me some bts to play with, I have been waiting for several days but got no update...
my bts wallet is: SGspNwacutDySLyC8h4x1gMXNHD
-
I tried to send you some usd but I got this error:
cmd: transfer 10 usd to SGspNwacutDySLyC8h4x1gMXNHD
Output:
-----------------------------------------------
assert
!"Unable to collect sufficient unspent inputs":
{"min_amnt":"0.00000000 bts","total_collected":"0.00000000 bts"}
th_a blockchain_wallet.cpp:97 collect_inputs
10.00000000 usd to SGspNwacutDySLyC8h4x1gMXNHD
{"amnt":"10.00000000 usd","to":"SGspNwacutDySLyC8h4x1gMXNHD"}
th_a blockchain_wallet.cpp:336 transfer
-----------------------------------------------
My balance before the transfer command is:
0.00000000 bts
100.00000000 usd
But after the transfer command is:
0.00000000 bts
0.00000000 usd
If i close the client and reopen it I obtain again 100 usd of balance.
Could the problem arise because I have no bts?
please send me some bts to play with, I have been waiting for several days but got no update...
my bts wallet is: SGspNwacutDySLyC8h4x1gMXNHD
Thank you for trying send me some bts! I checked my balance and it is still null. Let's wait for experts to reply :)
-
Just sent 100 usd and 10 bts
please send me some bts to play with, I have been waiting for several days but got no update...
my bts wallet is: SGspNwacutDySLyC8h4x1gMXNHD
-
Don't know why, my bts is back again.
maybe a bug in the bts wallet, it didn't show balance include all address sometime.
when I sent usd to others, the address come again, I guess it's come back for the change.
-
Yes, I see this msg too.
then I restart bts_wallet, my bts come back again...
sent you 10 bts for test.
I tried to send you some usd but I got this error:
cmd: transfer 10 usd to SGspNwacutDySLyC8h4x1gMXNHD
Output:
-----------------------------------------------
assert
!"Unable to collect sufficient unspent inputs":
{"min_amnt":"0.00000000 bts","total_collected":"0.00000000 bts"}
th_a blockchain_wallet.cpp:97 collect_inputs
10.00000000 usd to SGspNwacutDySLyC8h4x1gMXNHD
{"amnt":"10.00000000 usd","to":"SGspNwacutDySLyC8h4x1gMXNHD"}
th_a blockchain_wallet.cpp:336 transfer
-----------------------------------------------
My balance before the transfer command is:
0.00000000 bts
100.00000000 usd
But after the transfer command is:
0.00000000 bts
0.00000000 usd
If i close the client and reopen it I obtain again 100 usd of balance.
Could the problem arise because I have no bts?
please send me some bts to play with, I have been waiting for several days but got no update...
my bts wallet is: SGspNwacutDySLyC8h4x1gMXNHD
-
Ok thanks, now the command worked and I sent 1 usd to aasl.
Yes, I see this msg too.
then I restart bts_wallet, my bts come back again...
sent you 10 bts for test.
I tried to send you some usd but I got this error:
cmd: transfer 10 usd to SGspNwacutDySLyC8h4x1gMXNHD
Output:
-----------------------------------------------
assert
!"Unable to collect sufficient unspent inputs":
{"min_amnt":"0.00000000 bts","total_collected":"0.00000000 bts"}
th_a blockchain_wallet.cpp:97 collect_inputs
10.00000000 usd to SGspNwacutDySLyC8h4x1gMXNHD
{"amnt":"10.00000000 usd","to":"SGspNwacutDySLyC8h4x1gMXNHD"}
th_a blockchain_wallet.cpp:336 transfer
-----------------------------------------------
My balance before the transfer command is:
0.00000000 bts
100.00000000 usd
But after the transfer command is:
0.00000000 bts
0.00000000 usd
If i close the client and reopen it I obtain again 100 usd of balance.
Could the problem arise because I have no bts?
please send me some bts to play with, I have been waiting for several days but got no update...
my bts wallet is: SGspNwacutDySLyC8h4x1gMXNHD
-
Can I get some testShares to address PmP2PpHKrSbrBmfBf8wE6cGheNb ?
Thanks.
-
Just sent you 100 usd & 10 bts
Can I get some testShares to address PmP2PpHKrSbrBmfBf8wE6cGheNb ?
Thanks.
-
There has a bug happen when the wallet first address enough to pay transfer but not enough to pay transfer+fee, the result is the first address money miss in wallet.
There is my fix:
signed_trasaction wallet::transfer(...)
{
..........
if(total_in >= amnt +fee )
...............
else
{
mark_as_unspent(trx);
.............................
}
..........
}
void wallet::mark_as_unspent(const signed_transaction& trx)
{
for(auto itr=trx.inputs.begin(); itr!=inputs.end(); ++itr)
{
mark_as_unspent(itr->output_ref);
}
}
void wallet::mark_as_unspent(const output_reference& trx)
{
auto itr = my->_spent_outputs.find(r);
if(itr == my->_spent_outputs.end())
{
return;
}
my->_unspent_outputs[r] = itr->second;
my->_spent_outputs.erase(r);
}
and the make_as_spent function i suggest to change last two line into this way, it cause an error in running after i build by vs2010:
void make_as_spent()
{
.................
my->_spent_outputs[r] = itr->second;
my->_unspent_outputs.erase(r);
}
-
Just sent 100 usd and 10 bts
please send me some bts to play with, I have been waiting for several days but got no update...
my bts wallet is: SGspNwacutDySLyC8h4x1gMXNHD
Thank you, alt! I received 100 usd, but my wallet still shows 0 bts. I do not know why.
Just now I did a test: I generate a new address, and send some usd to the new address. Then I met the same problem as described in previous posts: some error message "unable to collect sufficient unspent input", and my amount turns to 0. when I restart, the money is back, but still I cannot send to my another address.
-
Ok thanks, now the command worked and I sent 1 usd to aasl.
Yes, I see this msg too.
then I restart bts_wallet, my bts come back again...
sent you 10 bts for test.
I tried to send you some usd but I got this error:
cmd: transfer 10 usd to SGspNwacutDySLyC8h4x1gMXNHD
Output:
-----------------------------------------------
assert
!"Unable to collect sufficient unspent inputs":
{"min_amnt":"0.00000000 bts","total_collected":"0.00000000 bts"}
th_a blockchain_wallet.cpp:97 collect_inputs
10.00000000 usd to SGspNwacutDySLyC8h4x1gMXNHD
{"amnt":"10.00000000 usd","to":"SGspNwacutDySLyC8h4x1gMXNHD"}
th_a blockchain_wallet.cpp:336 transfer
-----------------------------------------------
My balance before the transfer command is:
0.00000000 bts
100.00000000 usd
But after the transfer command is:
0.00000000 bts
0.00000000 usd
If i close the client and reopen it I obtain again 100 usd of balance.
Could the problem arise because I have no bts?
please send me some bts to play with, I have been waiting for several days but got no update...
my bts wallet is: SGspNwacutDySLyC8h4x1gMXNHD
Thank you, I received your 1 usd！
-
Please, send me some BTS USD to start testing
PGegJS8MJeyGpqRn7ixeDB9pXZn
-
Just sent you 100 usd + 10 bts
Please, send me some BTS USD to start testing
PGegJS8MJeyGpqRn7ixeDB9pXZn
-
I have met with another strange thing:
my account has 101 usd and 10 bts. I issue an order to buy 1 bts with 1 usd. After the order is submitted, my balance is like:
>>> balance
10.00000000 bts
100.00000000 usd
Margin Positions
0.00000000 usd total collateral: 0.00000000 bts avg call price: 0.0000000000000 usd/bts
===========================================================
Unspent Outputs:
d58189b26daadb25013bc47a9c09e7dc5b20b7df:2] 1.00000000 bts claim_by_signature SRG6Boi48RkGPhMxFzwER6kQkaT
d58189b26daadb25013bc47a9c09e7dc5b20b7df:1] 89.00000000 usd claim_by_signature SRG6Boi48RkGPhMxFzwER6kQkaT
5fd1b50fc7182543c0ce59187b02ef1de8e58948:0] 10.00000000 usd claim_by_signature K382iEepdJyCHDgYBZsx3uqRSyq
e00b5487be74a401895a678cc78127053a6112ac:0] 1.00000000 usd claim_by_signature SGspNwacutDySLyC8h4x1gMXNHD
c5383cd618110be0e8d235a564b487584bc6225f:1] 9.00000000 bts claim_by_signature KxZNzt8ZmL1vzrjyDHJNJeXTpgo
Open Bids:
d58189b26daadb25013bc47a9c09e7dc5b20b7df:0] 1.00000000 usd claim_by_bid 1.0000000000000 usd/bts owner: SRG6Boi48RkGPhMxFzwER6kQkaT min trade: 0
However, when I quite bts_wallet and restart, my balance becomes:
>>> balance
9.00000000 bts
11.00000000 usd
Margin Positions
0.00000000 usd total collateral: 0.00000000 bts avg call price: 0.0000000000000 usd/bts
===========================================================
Unspent Outputs:
5fd1b50fc7182543c0ce59187b02ef1de8e58948:0] 10.00000000 usd claim_by_signature K382iEepdJyCHDgYBZsx3uqRSyq
e00b5487be74a401895a678cc78127053a6112ac:0] 1.00000000 usd claim_by_signature SGspNwacutDySLyC8h4x1gMXNHD
c5383cd618110be0e8d235a564b487584bc6225f:1] 9.00000000 bts claim_by_signature KxZNzt8ZmL1vzrjyDHJNJeXTpgo
1 bts and 89 usd is lost after I submit my buying order! What is the cause of this problem?
-
Your change output has not been confirmed yet.
Sent from my iPhone using Tapatalk (http://tapatalk.com/m?id=1)
-
Just sent you 100 usd + 10 bts
Please, send me some BTS USD to start testing
PGegJS8MJeyGpqRn7ixeDB9pXZn
Thanks alt!
Im launching bts_wallet and the balance is not there yet.
(http://f.cl.ly/items/24283Q2q3P0i1k3o0p0x/Screen%20Shot%202014-01-27%20at%203.03.29%20PM.png)
I have some newbie questions.
- What is the equivalent of bitcoind in bitshares, bitshares_server?
- What is the bitshares_client?
- Where i can find an config example for bitshars_client?
-
Don't know why....
but I see it in the dump chainblock
{
"version": 0,
"prev": "d31dc1a891495cb5dc06971e3625f37ce85c56a6",
"block_num": 204,
"timestamp": "20140127T091234",
"total_shares": 992066829540,
"total_coindays_destroyed": 0,
"trx_mroot": "1c23664df107048c972b70c506bf638dca3b11bf",
"trxs": [{
"version": 0,
"stake": 2831228371,
"timestamp": "20140127T091227",
"valid_after": "19700101T000000",
"valid_until": "19700101T000000",
"inputs": [{
"output_ref": {
"trx_hash": "e0eeba44c402c92b42d625ffa43ea73f6f47d397",
"output_idx": 0
},
"input_data": ""
},{
"output_ref": {
"trx_hash": "452bf9de87d73be3a4ecc16361588bf88732f0b2",
"output_idx": 0
},
"input_data": ""
},{
"output_ref": {
"trx_hash": "fe5e42897048ce6e063af3a26a6cd32fe1c9e4ba",
"output_idx": 0
},
"input_data": ""
}
],
"outputs": [{
"amount": 10000000000,
"unit": "usd",
"claim_func": "claim_by_signature",
"claim_data": {
"owner": "PGegJS8MJeyGpqRn7ixeDB9pXZn"
}
},{
"amount": 90200000000,
"unit": "usd",
"claim_func": "claim_by_signature",
"claim_data": {
"owner": "NRCkHFFJPoumRXpZSrbJM5r9XAj"
}
},{
"amount": 100000000,
"unit": "bts",
"claim_func": "claim_by_signature",
"claim_data": {
"owner": "NRCkHFFJPoumRXpZSrbJM5r9XAj"
}
}
],
"sigs": [
"2036aa8efea946032731a2aa738c301d71dd85b5ce5e13b63ce6941cf1f92fbdffb9fbad542f270ab4e7b6ec75c5164ea5c81b4d9d6ccc55267ef2d3c2e39a9513",
"20510b2f97c3fcf1e66430678c374e3167ca0f874c4374e9ffb2feaf81c7465127110febe06695fd5aeaa0e676ea295da3a25b2f68cdb948cd373aa9dda5d156f7",
"20601b0259582ca20dbd233dddb046df99092ea9489f86b4fcd0991f74fb5d516b405d68048ceaa6758c517f83314a3c7780f11524ba30a8f5beee977a6c0df14a"
]
},{
"version": 0,
"stake": 2831228371,
"timestamp": "20140127T091233",
"valid_after": "19700101T000000",
"valid_until": "19700101T000000",
"inputs": [{
"output_ref": {
"trx_hash": "fbbc00d78311d5b92fb545bfd91d41ca25055d9b",
"output_idx": 1
},
"input_data": ""
}
],
"outputs": [{
"amount": 1000000000,
"unit": "bts",
"claim_func": "claim_by_signature",
"claim_data": {
"owner": "PGegJS8MJeyGpqRn7ixeDB9pXZn"
}
},{
"amount": 21860627992,
"unit": "bts",
"claim_func": "claim_by_signature",
"claim_data": {
"owner": "QiVUxNhCuVKi5RRpKde3T9mr6qq"
}
}
],
"sigs": [
"2001805c8723fc7386ea706214d9d4655462ed83f3de14dd73b630c117a4901c99b6a80609f931fc31c52ad9a095e71a71d52e451c44041ca5240011a33cdcb30c"
]
}
]
},
(modedit: code tag)
Just sent you 100 usd + 10 bts
Please, send me some BTS USD to start testing
PGegJS8MJeyGpqRn7ixeDB9pXZn
Thanks alt!
Im launching bts_wallet and the balance is not there yet.
(http://f.cl.ly/items/24283Q2q3P0i1k3o0p0x/Screen%20Shot%202014-01-27%20at%203.03.29%20PM.png)
I have some newbie questions.
- What is the equivalent of bitcoind in bitshares, bitshares_server?
- What is the bitshares_client?
- Where i can find an config example for bitshars_client?
-
Today I made no progress on BitShares X development, but our website has seen some more major updates.
BitShares vs Bitcoin
http://invictus.io/bitshares.php
Updated AGS Page
http://invictus.io/bitshares-ags.php
Checkout the counter!
That's really like I do over support.. sometimes...
"Manager.. today.. I did no work.. but.. I managed to sell.. this =)".
Keeps me minded about what IT/dev world is.. thanks.
Keep the BRUTAL work :P
-
Your change output has not been confirmed yet.
Sent from my iPhone using Tapatalk (http://tapatalk.com/m?id=1)
Hi Daniel. Thank you for your reply. Usually how long does it take to confirm a tx? Around one day has passed, but until now my banlance is still 9bts+11usd, 1bts+89usd still missing. what is strange is that, I offered 1 usd to buy 1 bts, why 1bts is also deducted from my account?
-
Your change output has not been confirmed yet.
Sent from my iPhone using Tapatalk (http://tapatalk.com/m?id=1)
Hi Daniel. Thank you for your reply. Usually how long does it take to confirm a tx? Around one day has passed, but until now my banlance is still 9bts+11usd, 1bts+89usd still missing. what is strange is that, I offered 1 usd to buy 1 bts, why 1bts is also deducted from my account?
1usd can not buy 1bts now,your order should be pending and not executed yet,pls check in the section "open bid" of your balance.
Sent from my iPhone using Tapatalk (http://tapatalk.com/m?id=1)
-
please is can I to have test bitshares for make do enormous tests
Rt6uNNtF5V6njhdCKo5Fz2NLiB8
-
Your change output has not been confirmed yet.
Sent from my iPhone using Tapatalk (http://tapatalk.com/m?id=1)
Hi Daniel. Thank you for your reply. Usually how long does it take to confirm a tx? Around one day has passed, but until now my banlance is still 9bts+11usd, 1bts+89usd still missing. what is strange is that, I offered 1 usd to buy 1 bts, why 1bts is also deducted from my account?
1usd can not buy 1bts now,your order should be pending and not executed yet,pls check in the section "open bid" of your balance.
Sent from my iPhone using Tapatalk (http://tapatalk.com/m?id=1)
The open bid lists nothing... I just use "buy" command to test, I thought I could cancel my bid. But it is strange that nothing is shown and the most the money is gone...
before I bid:
(http://i1136.photobucket.com/albums/n494/starrysl/bts/Untitled1_zpse59128d0.png)
Then I sent some amount to my newly generated address, for testing. all tx with no error.
But after I bid 1bts for 1usd:
(http://i1136.photobucket.com/albums/n494/starrysl/bts/Untitled_zpsb3a24f83.png)
-
Just sent 10bts + 100usd
please is can I to have test bitshares for make do enormous tests
Rt6uNNtF5V6njhdCKo5Fz2NLiB8
-
Today I finally got back to the code after spending the past 5 days traveling. I just checked in code that will break compatibility with all test wallets and the existing server. This new code uses 128 bit balances and does comparisons by rounding to 64 high bits. This should keep things cleaner than my old ad hoc rounding and provide more predictable / expected results when using odd numbers.
I will be resetting the server to launch a new test period later this week after I get a few more features in place.
-
switch to consensus algorithm as soon as you are able please
I'm sure testers and your new hires will have an easier time with market bugs than with ripple/PoS
-
Today I designed and mostly implemented my version of Ripple's consensus algorithm which I am calling Unity. It uses a slightly different algorithm that I think will converge faster. I took the view that the nodes in the UNL are like neurons in a fully connected neural network. The goal is to create a positive feedback loop that moves all nodes toward a stable steady state. Here is how the algorithm works:
1) Every node publishes their initial transaction set to all other nodes in the UNL
2) A node will then tally the votes each transaction got as a percentage of the maximum (a vote from every node)
3) A node will then calculate the average "consensus" of each proposal by every other node (the average of the values calculated in step 2 for each proposal. This average will then be used as the weight given to that transactions in that nodes proposal. The result is that proposals with higher average consensus get a higher weight than proposals with lower average consensus. If nodes want their opinion to carry weight they need to increase their average consensus in their next proposal.
4) I then recalculate the proposal for the current node by tallying the weighted votes each transaction got based upon the proposals it was included in.
5) I then take all transactions in the top 25% by weighted vote and publish them as my new proposal to all other nodes.
6) Once all transactions in my published proposal have at least 70% of the weighted vote convergence is guaranteed and a block can be produced and the process starts over.
I will be implementing a unit test that will throughly verify that this can be maintained at high speed, high volume, and a large number of nodes in the UNL for reasonable bandwidth.
-
What's the incentive for a node to have it's opinion carry weight?
How does this interact with POS?
-
What's the incentive for a node to have it's opinion carry weight?
How does this interact with POS?
The premise of Ripple's algorithm is that "failure to agree is agreeing to fail" and all nodes on the UNL are presumed to be trusted with the intention to reach an agreement. A node that does not move toward consensus can be identified, flagged, and removed from everyones UNL.
The consensus algorithm does not validate transactions, it merely selects a set of transactions some of which may fail to pass validation and thus be pruned by all nodes. The result is a deterministic generation of a common block.
In other words the UNL nodes are only "trusted" for a small task and no one node ever has as much power as miners get in the Bitcoin network (dictator for a block).
Once the Unity algorithm has run it will produce a block which must pass validation by everyone else in the network, even those not on the UNL. The rest of the network (normal users) then confirm the decision of the UNL nodes by referencing the head block's hash in their transactions. The coin-days-destroyed by everyone else broadcasting transactions after the consensus gradually makes the chain irreversible even by the UNL nodes.
-
1) Every node publishes their initial transaction set to all other nodes in the UNL
2) A node will then tally the votes each transaction got as a percentage of the maximum (a vote from every node)
3) A node will then calculate the average "consensus" of each proposal by every other node (the average of the values calculated in step 2 for each proposal. This average will then be used as the weight given to that transactions in that nodes proposal. The result is that proposals with higher average consensus get a higher weight than proposals with lower average consensus. If nodes want their opinion to carry weight they need to increase their average consensus in their next proposal.
4) I then recalculate the proposal for the current node by tallying the weighted votes each transaction got based upon the proposals it was included in.
5) I then take all transactions in the top 25% by weighted vote and publish them as my new proposal to all other nodes.
6) Once all transactions in my published proposal have at least 70% of the weighted vote convergence is guaranteed and a block can be produced and the process starts over.
Let's say a transaction is "popular" if it's in a lot of nodes' proposals, "unpopular" if only exists in a few nodes' proposals.
Won't your algorithm make unpopularity stable over time?
In other words, let's say there's a transaction that only exists on one node. Won't other nodes always choose not to include it in their proposals because it's unpopular?
Of course, in a real network, pretty much all transactions enter the network from a single node. So this analysis means no transaction will ever be accepted by any node other than its originator, and the network will be totally useless! This absurd result tells me my analysis is wrong -- but how is it wrong?
-
1) Every node publishes their initial transaction set to all other nodes in the UNL
2) A node will then tally the votes each transaction got as a percentage of the maximum (a vote from every node)
3) A node will then calculate the average "consensus" of each proposal by every other node (the average of the values calculated in step 2 for each proposal. This average will then be used as the weight given to that transactions in that nodes proposal. The result is that proposals with higher average consensus get a higher weight than proposals with lower average consensus. If nodes want their opinion to carry weight they need to increase their average consensus in their next proposal.
4) I then recalculate the proposal for the current node by tallying the weighted votes each transaction got based upon the proposals it was included in.
5) I then take all transactions in the top 25% by weighted vote and publish them as my new proposal to all other nodes.
6) Once all transactions in my published proposal have at least 70% of the weighted vote convergence is guaranteed and a block can be produced and the process starts over.
Let's say a transaction is "popular" if it's in a lot of nodes' proposals, "unpopular" if only exists in a few nodes' proposals.
Won't your algorithm make unpopularity stable over time?
In other words, let's say there's a transaction that only exists on one node. Won't other nodes always choose not to include it in their proposals because it's unpopular?
Of course, in a real network, pretty much all transactions enter the network from a single node. So this analysis means no transaction will ever be accepted by any node other than its originator, and the network will be totally useless! This absurd result tells me my analysis is wrong -- but how is it wrong?
All nodes attempt to fetch the transactions from all other nodes, ie: they are broadcast everywhere. The consensus process selects transactions that have fully propagated over those that are only partially propagated. Those not included in one block are likely to be included in the very next block.
-
So all transactions are broadcast by another process, this algorithm is used to try to determine a subset S of the transactions known to the current node, such that all transactions in S are known to a large fraction of other nodes. And then using this S as the set of transactions in the next block.
Why is this necessary at all? What's wrong with just having every node do its own proof-of-stake on the set of transactions it knows about?
Also, what exactly are UNL nodes? What is the process to become a UNL node? If it's easy to become a UNL node, doesn't that make UNL vulnerable to sibyls? If it's hard to become a UNL node, doesn't that make the network too centralized?
-
So all transactions are broadcast by another process, this algorithm is used to try to determine a subset S of the transactions known to the current node, such that all transactions in S are known to a large fraction of other nodes. And then using this S as the set of transactions in the next block.
Why is this necessary at all? What's wrong with just having every node do its own proof-of-stake on the set of transactions it knows about?
Also, what exactly are UNL nodes? What is the process to become a UNL node? If it's easy to become a UNL node, doesn't that make UNL vulnerable to sibyls? If it's hard to become a UNL node, doesn't that make the network too centralized?
All nodes must AGREE on the next block to make sure the block chain doesn't diverge. Bitcoin uses the lowest hash to decide what to agree on. As a result bitcoin is centralized one block at a time. Bitcoin is also centralized by 10 mining pools which approve 90% of the blocks and just 2 or 3 are required for 51% or more of the blocks.
The UNL list is specified manually so is not subject to Sybil attacks. To get on the list you just have to convince most of the existing nodes to add you to their list. In effect, new people are 'voted' into the consensus process by the original. I would aim to get about 100 nodes on the UNL list hosted in countries around the world.
The free market is the truest form of decentralization as every individual is free to adapt. The free market is based upon competition and thus freedom to compete must be the primary goal of all decentralized efforts. Anything that restricts or limits competition is known as a barrier to entry and will result in a move toward centralization. Mining power represents a form of barrier to entry that will be insurmountable by the average Joe once the government has tax payer funded mining factories full of ASICs, GPUs, and CPU/Memory. No one will be able to launch a proof of work coin again without these mining factories 'owning' it.
While the UNL list might appear centralized, all players at all times can change the UNL list and effectively elect a new management team. If the UNL list consists of nodes in many jurisdictions, owned by many different people, then they will not be able or likely to colude to defraud anyone. The only thing an 'evil' UNL group could do is 'stop transactions' in which case they can be replaced.
Thus decentralization is achieved through many competing chains with competing UNL groups and at no time does any chain get permanently locked in to one signing authority that just happens to control hash power.
-
I buy that Bitcoin's de facto centralization is something to be avoided if possible. But I also want to be sure that your cure isn't worse than the disease, hence the skeptical questions.
If I'm wasting your time with elementary questions, and there's documentation where this is already explained, please, feel free to point me to those resources instead.
Okay, so here are my next questions:
- How do nodes outside the UNL know what has been approved by the UNL? Do UNL nodes have hardcoded keys as well as hardcoded network addresses? Or is a connection to a UNL node necessary for a client to function?
- Say I'm a node outside the UNL. One of my peers feeds me a block that has a parent I've accepted and passes proof-of-stake signature, transaction validation, etc., but contains some transaction the UNL has never heard of. How do I establish that the UNL has never heard of it? What do I do with the block -- accept it, discard it, hold it for a while and see if the UNL eventually decides to like the transactions it contains, or something else?
- It seems like you might need a condition along the lines of "Most of the regular nodes (outside UNL) have to have nearly identical UNL lists" in order to avoid a fork. Is this true? If it is true, doesn't that mean your argument that "players can change the UNL" should be amended to disclose "players can change their UNL, but risk causing a hard-fork"?
- Shouldn't we build some kind of simulator or run a bunch of instances on localhost or something to observe e.g. the nodes reaching consensus?
- With respect to step 6 ("Once all transactions in my published proposal have at least 70% of the weighted vote convergence is guaranteed...") What precisely is meant by convergence, and how is convergence guaranteed? Mathematical proof, empirical simulation, practical experience (Ripple?), gut feeling, something else?
-
- How do nodes outside the UNL know what has been approved by the UNL? Do UNL nodes have hardcoded keys as well as hardcoded network addresses? Or is a connection to a UNL node necessary for a client to function?
The UNL list is a set of keys, not IPs.
- Say I'm a node outside the UNL. One of my peers feeds me a block that has a parent I've accepted and passes proof-of-stake signature, transaction validation, etc., but contains some transaction the UNL has never heard of. How do I establish that the UNL has never heard of it? What do I do with the block -- accept it, discard it, hold it for a while and see if the UNL eventually decides to like the transactions it contains, or something else?
Your peers cannot find a block, and all peers check that every block is signed by several of the UNL nodes as UNL nodes are the only ones that can generate a block and they all generate the same block.
- It seems like you might need a condition along the lines of "Most of the regular nodes (outside UNL) have to have nearly identical UNL lists" in order to avoid a fork. Is this true? If it is true, doesn't that mean your argument that "players can change the UNL" should be amended to disclose "players can change their UNL, but risk causing a hard-fork"?
A hard fork is the market solution to a misbehaving UNL set. Bitcoin would have to perform a hardfork if the government ever got enough control over miners to enforce tainted coins. The difference is that any bitcoin fork would also have to adopt a new POW that the government does not control and thus mean a massive coding change to something along the lines of a UNL.
- Shouldn't we build some kind of simulator or run a bunch of instances on localhost or something to observe e.g. the nodes reaching consensus?
Building that now.
- With respect to step 6 ("Once all transactions in my published proposal have at least 70% of the weighted vote convergence is guaranteed...") What precisely is meant by convergence, and how is convergence guaranteed? Mathematical proof, empirical simulation, practical experience (Ripple?), gut feeling, something else?
Assuming all nodes are running the algorithm they will have passed the tipping point where the 'rich get richer' and the 'poor get poorer' in terms of which nodes are included in the set. This will of course be verified by the test system I am putting together that will push 7 trx per second randomly generated by 100 nodes and insure they reach consensus.
-
The UNL list is a set of keys, not IPs.
A hard fork is the market solution to a misbehaving UNL set. Bitcoin would have to perform a hardfork if the government ever got enough control over miners to enforce tainted coins. The difference is that any bitcoin fork would also have to adopt a new POW that the government does not control and thus mean a massive coding change to something along the lines of a UNL.
This is the most informative thing I've heard yet. I was thinking of the UNL along the lines of "a hardcoded list of network addresses which facilitates bootstrapping peer connections for a distributed peer-to-peer network service." Instead, it seems it's more like "a set of authoritative signing keys which valid blocks will require."
Your peers cannot find a block
I'd like to elaborate to make sure I understand. What you're really trying to say is that the validation check for a block involves checking that the block is signed by the hardcoded UNL signing keys, and it is impossible [1] for a node not in possession of a UNL private key to reproduce such a signature. The code UNL nodes use to put together a block will be published, but the private keys will not. So, just like anyone can put together a Bitcoin block that's lacking enough leading zero bits in the hash and thus will fail to validate, anyone can put together a Byteshares block that's lacking the UNL signature and thus will fail to validate.
[1] Impossible for an attacker who can't break RSA or ECDSA or whatever signature algorithm you use.
-
Why is this necessary at all? What's wrong with just having every node do its own proof-of-stake on the set of transactions it knows about?
All nodes must AGREE on the next block to make sure the block chain doesn't diverge. Bitcoin uses the lowest hash to decide what to agree on.
What's wrong with arbitrating between two different forks by accepting the one with the "better" proof-of-stake (compare hash divided by target for all competing forks)?
As a result bitcoin is centralized one block at a time.
I see what you're trying to say, but only because I think (earlier in this thread, or maybe somewhere else) you said that a single miner can "dictate" a block. This is true, but it's a strength, not a weakness. If you have some transaction T that a censor wants the network to permanently reject [1] [2] , with UNL it suffices for the censor to control some fraction of the UNL (maybe a majority, maybe a supermajority, maybe less -- need a simulation or detailed mathematical analysis to say for sure). With PoS, we can assume 50% of the PoS-power will accept T [3], so the probability that T is not included in any of the next n blocks is at most (1/2)^n, which of course rapidly goes to zero. Why allow a transaction censorship attack to succeed by compromising the UNL, when we can force them to meet the much higher bar of a 51% attack?
Bitcoin is also centralized by 10 mining pools which approve 90% of the blocks and just 2 or 3 are required for 51% or more of the blocks.
I thought that PoS is supposed to be resistant to this phenomenon, because it's much harder to accumulate a significant fraction of a cryptocoin in circulation than it is to pool mining hardware.
[1] For example, the censor is a democratic government who believes, through due process of law, including good evidence obtained by Constitutionally approved methods and presented to an impartial judge / grand jury, that this transaction should be suppressed because it will be used for some despicable criminal activity.
[2] For example, the censor is an oppressive government whose intelligence service wants to invade privacy on a global scale by data-mining every financial transaction performed by every person in the world, and believes that this transaction should be suppressed because it does not contain sufficiently detailed information for its data mining system to confidently identify the sender, recipient, and nature of the transaction. NB, technology cannot distinguish this case from [1].
[3] If 51% of nodes reject the transaction the censor wants to be rejected, then the censor has successfully carried out a 51% attack. Because a 51% attack on PoS system implies that 51% of the money agrees with the censor, I would say this situation is better described as "the network voluntarily complied with the censor's desired policy" than "the censor launched a successful attack".
-
Today I made more progress on the Unity algorithm and have nodes talking to each other and am in the process of debugging the algorithm now so hopefully some time tomorrow I will have the bugs worked out.
-
I would aim to get about 100 nodes on the UNL list hosted in countries around the world.
This sounds very centralized to me.
Even international banks would have more branches (I know thats comparing apples and oranges) but 100 nodes sounds scary little (even though it would be more decentralized than bitcoin). Why would there only be 100, are their barriers to becoming a node.
Already with my limited technical knowledge I feel I will not be able to support the network by becoming a node. Am I missing something there?
-
I would aim to get about 100 nodes on the UNL list hosted in countries around the world.
This sounds very centralized to me.
Even international banks would have more branches (I know thats comparing apples and oranges) but 100 nodes sounds scary little (even though it would be more decentralized than bitcoin). Why would there only be 100, are their barriers to becoming a node.
Already with my limited technical knowledge I feel I will not be able to support the network by becoming a node. Am I missing something there?
The number of nodes can grow to any number that can support the bandwidth and latency requirements.
What is your concern regarding centralization with 100 nodes? What attack do you see being possible?
-
I would aim to get about 100 nodes on the UNL list hosted in countries around the world.
This sounds very centralized to me.
Even international banks would have more branches (I know thats comparing apples and oranges) but 100 nodes sounds scary little (even though it would be more decentralized than bitcoin). Why would there only be 100, are their barriers to becoming a node.
Already with my limited technical knowledge I feel I will not be able to support the network by becoming a node. Am I missing something there?
The number of nodes can grow to any number that can support the bandwidth and latency requirements.
What is your concern regarding centralization with 100 nodes? What attack do you see being possible?
I would be concerned that someone who wants to abuse/damage the system would invest in setting up 101 nodes.
-
I would aim to get about 100 nodes on the UNL list hosted in countries around the world.
This sounds very centralized to me.
Even international banks would have more branches (I know thats comparing apples and oranges) but 100 nodes sounds scary little (even though it would be more decentralized than bitcoin). Why would there only be 100, are their barriers to becoming a node.
Already with my limited technical knowledge I feel I will not be able to support the network by becoming a node. Am I missing something there?
The number of nodes can grow to any number that can support the bandwidth and latency requirements.
What is your concern regarding centralization with 100 nodes? What attack do you see being possible?
I would be concerned that someone who wants to abuse/damage the system would invest in setting up 101 nodes.
It isn't the number of nodes, it is the number of private keys. Effectively you start out with a trusted group of 5 nodes which share a common UNL list (UNL list is a set of private keys). These 5 people want to grow the group as large as possible to maximize the value of the currency and the security of the network. So every time a new individual wants to join the group they are vetted as being unique and added to the group.
By the time you get to 100 people the potential for collusion falls to 0, especially since the bad actors would have their signature on everything.
-
What is the benefit of being a node?
-
What is the benefit of being a node?
Full nodes would normally pair with other services such as block explorers and web wallets. By running a full node you have essentially been vetted by the community and by continuing to run a full node with integrity your reputation can grow and open up other doors.
I imagine full nodes could offer services such as APIs for light-weight clients, etc. So they profit indirectly rather than directly from running a full node. An example would be a full node running a web service that tracks the status of all other nodes participating in the unity algorithm, their latency, and automatically flags any misbehaving nodes. These extra services could earn ad revenue.
In the event that no one wants to run a full node the chain dies. Everyone with a vested interest in the chain's longevity would want to prevent this from happening.
-
ok :) Why not decentralize this and give a material incentive to the nodes to be nodes? Without an incentive the biggest stakeholders or those with non-material goals would run nodes. But the system itself doesn't guarantee that nodes are run.
-
ok :) Why not decentralize this and give a material incentive to the nodes to be nodes? Without an incentive the biggest stakeholders or those with non-material goals would run nodes. But the system itself doesn't guarantee that nodes are run.
What makes you think those with non-material goals wouldn't be making so much more? If we pay nodes to participate then everyone will want to be on the receiving side which means you need a fixed reward divided among all players.
Lets step back a second and reconsider everything... suppose you did something like this:
1) Use a mining algorithm like momentum where the difficulty is adjusted by square of the coin days destroyed by the block.
2) Pay a very small percentage of the fees to the miner.
3) If two blocks are found at once, the one with the most CDD wins.
The consequences of this approach are as follows:
1) block times return to 5 minute intervals rather than seconds...
2) if there are no transactions CDD is 0 and difficulty is infinity... therefore variation in transaction volume will have a bigger impact on the difficulty adjustment than adding or removing miners.
3) centralization one block at a time returns... but if you allow everyone's CDD to factor in then someone excluding transactions is unlikely to win. Thus the network errors on the side of including transactions rather than excluding them.
4) You end up increasing the expenses of operating the network (paying miners) and thus reducing the dividend.
I suspect that the mining reward can be as low as 1% of the transaction fees and it would be enough incentive for many people to mine in the background at some steady state. Mining will always be profitable because if it were not people would stop mining.
Overall I think I like this... though I lament the performance cost.
-
ok :) Why not decentralize this and give a material incentive to the nodes to be nodes? Without an incentive the biggest stakeholders or those with non-material goals would run nodes. But the system itself doesn't guarantee that nodes are run.
What makes you think those with non-material goals wouldn't be making so much more? If we pay nodes to participate then everyone will want to be on the receiving side which means you need a fixed reward divided among all players.
Lets step back a second and reconsider everything... suppose you did something like this:
1) Use a mining algorithm like momentum where the difficulty is adjusted by square of the coin days destroyed by the block.
2) Pay a very small percentage of the fees to the miner.
3) If two blocks are found at once, the one with the most CDD wins.
The consequences of this approach are as follows:
1) block times return to 5 minute intervals rather than seconds...
2) if there are no transactions CDD is 0 and difficulty is infinity... therefore variation in transaction volume will have a bigger impact on the difficulty adjustment than adding or removing miners.
3) centralization one block at a time returns... but if you allow everyone's CDD to factor in then someone excluding transactions is unlikely to win. Thus the network errors on the side of including transactions rather than excluding them.
4) You end up increasing the expenses of operating the network (paying miners) and thus reducing the dividend.
I suspect that the mining reward can be as low as 1% of the transaction fees and it would be enough incentive for many people to mine in the background at some steady state. Mining will always be profitable because if it were not people would stop mining.
Overall I think I like this... though I lament the performance cost.
This introduces a perverse incentive for nodes not to forward transactions... though I suspect the damage caused by this would be small..
-
Today I updated the proof of stake processing / calculation for blocks.
I also updated checks for block time stamps.
I restored the nonce + target difficulty settings
I implemented the algorithm to adjust the difficulty based upon total CDD
To summarize the latest changes with proof of stake I can say this:
If there are no CDD by a block then the difficulty is 1 million times harder than the 'target'.
As the CDD by a block approaches 1/4 the expected average the difficulty approaches the 'target'.
A miner that has some of their own CDD that they do not broadcast can get a mining advantage by destroying some of their own CDD to reduce difficulty. Of course all miners/owners have equal advantage here and thus this creates demand to consume at least 1/4 the average CDD per block.
Miners that don't own any shares must wait until enough transactions are broadcast before they can start mining effectively.
End result: on average enough CDD is destroyed every block to provide greater security than bitcoin provides every block and it is near impossible to produce significant chains in secret.
Because a mining advantage exists based upon how many shares you own, solo mining is more likely than pool mining. For pool mining to be effective, everyone would have to transfer their money to the pool operator.
I believe that NO ONE would be able to mine the chain continuously without at least 25% of the share supply because if you owned any less you would run out of CDD and mining difficulty would hit 1M times your hash power. We can thus conclude that someone with 1% of the shares would be unable to create a chain in secret longer than a few days assuming they also had 51% of the hashing power.
Overall I conclude the chain is more secure than BTC by an order of magnitude even though only a small fraction of the fees 1% are paid to miners for their efforts.
-
Bytemaster, appreciated for your effort on daily update w/ big progress on Bitshares X development. I'm really excited about it. One question: do you plan to update the white paper of Bitshares or/and POS recently? I think it makes sense to have this 2 documents updated before 2/28 Bitshares X public test/release then people could be clear about what's the detailed mechanism/logic of bitshares system operation. Thanks.
ok :) Why not decentralize this and give a material incentive to the nodes to be nodes? Without an incentive the biggest stakeholders or those with non-material goals would run nodes. But the system itself doesn't guarantee that nodes are run.
What makes you think those with non-material goals wouldn't be making so much more? If we pay nodes to participate then everyone will want to be on the receiving side which means you need a fixed reward divided among all players.
Lets step back a second and reconsider everything... suppose you did something like this:
1) Use a mining algorithm like momentum where the difficulty is adjusted by square of the coin days destroyed by the block.
2) Pay a very small percentage of the fees to the miner.
3) If two blocks are found at once, the one with the most CDD wins.
The consequences of this approach are as follows:
1) block times return to 5 minute intervals rather than seconds...
2) if there are no transactions CDD is 0 and difficulty is infinity... therefore variation in transaction volume will have a bigger impact on the difficulty adjustment than adding or removing miners.
3) centralization one block at a time returns... but if you allow everyone's CDD to factor in then someone excluding transactions is unlikely to win. Thus the network errors on the side of including transactions rather than excluding them.
4) You end up increasing the expenses of operating the network (paying miners) and thus reducing the dividend.
I suspect that the mining reward can be as low as 1% of the transaction fees and it would be enough incentive for many people to mine in the background at some steady state. Mining will always be profitable because if it were not people would stop mining.
Overall I think I like this... though I lament the performance cost.
This introduces a perverse incentive for nodes not to forward transactions... though I suspect the damage caused by this would be small..
-
Today I updated the proof of stake processing / calculation for blocks.
I also updated checks for block time stamps.
I restored the nonce + target difficulty settings
I implemented the algorithm to adjust the difficulty based upon total CDD
To summarize the latest changes with proof of stake I can say this:
If there are no CDD by a block then the difficulty is 1 million times harder than the 'target'.
As the CDD by a block approaches 1/4 the expected average the difficulty approaches the 'target'.
A miner that has some of their own CDD that they do not broadcast can get a mining advantage by destroying some of their own CDD to reduce difficulty. Of course all miners/owners have equal advantage here and thus this creates demand to consume at least 1/4 the average CDD per block.
Miners that don't own any shares must wait until enough transactions are broadcast before they can start mining effectively.
End result: on average enough CDD is destroyed every block to provide greater security than bitcoin provides every block and it is near impossible to produce significant chains in secret.
Because a mining advantage exists based upon how many shares you own, solo mining is more likely than pool mining. For pool mining to be effective, everyone would have to transfer their money to the pool operator.
I believe that NO ONE would be able to mine the chain continuously without at least 25% of the share supply because if you owned any less you would run out of CDD and mining difficulty would hit 1M times your hash power. We can thus conclude that someone with 1% of the shares would be unable to create a chain in secret longer than a few days assuming they also had 51% of the hashing power.
Overall I conclude the chain is more secure than BTC by an order of magnitude even though only a small fraction of the fees 1% are paid to miners for their efforts.
What's the deal with mining? I tough you eliminated it (as opposed to what nxt does; see your post here https://bitsharestalk.org/index.php?topic=1890.150) and stakeholders would be miners (POS).
-
Today I made more progress on the block generation and validation algorithm. The wallet has successfully mined a few blocks and the difficulty goes up when there is not enough Proof of Stake.
Tomorrow I will do the following:
1) Select inputs from your wallet oldest-first so that your transactions can be validated as quickly as possible and contribute the most to securing the chain.
2) Automatically generate transactions to yourself if it will generate enough CDD to reduce the difficulty to the minimum amount.
In response to the question about eliminating mining, I have concluded that ripple-style consensus would have more downsides than straight up POS mining. Namely, even with 100 nodes people would call it centralized. I will probably work on a consensus based system in the future, but the POS mining is easier now.
Unlike NXT most of the transactions fees are paid as dividends and only a small portion paid to miners. Also unlike NXT, everyone is contributing to the security of the network when they make a transaction.
-
Today I made more progress on the block generation and validation algorithm. The wallet has successfully mined a few blocks and the difficulty goes up when there is not enough Proof of Stake.
Tomorrow I will do the following:
1) Select inputs from your wallet oldest-first so that your transactions can be validated as quickly as possible and contribute the most to securing the chain.
2) Automatically generate transactions to yourself if it will generate enough CDD to reduce the difficulty to the minimum amount.
In response to the question about eliminating mining, I have concluded that ripple-style consensus would have more downsides than straight up POS mining. Namely, even with 100 nodes people would call it centralized. I will probably work on a consensus based system in the future, but the POS mining is easier now.
Unlike NXT most of the transactions fees are paid as dividends and only a small portion paid to miners. Also unlike NXT, everyone is contributing to the security of the network when they make a transaction.
the update bts wallet client unable to connect to bitshares network now, need any special setting?
-
If someone would like to volunteer to distribute test BTS while I am off line let me know so I can give you a wad.
BTS: GNMjoe397TTM59G8qWJshAs9Z3i
-
Today I made more progress on the block generation and validation algorithm. The wallet has successfully mined a few blocks and the difficulty goes up when there is not enough Proof of Stake.
Tomorrow I will do the following:
1) Select inputs from your wallet oldest-first so that your transactions can be validated as quickly as possible and contribute the most to securing the chain.
2) Automatically generate transactions to yourself if it will generate enough CDD to reduce the difficulty to the minimum amount.
In response to the question about eliminating mining, I have concluded that ripple-style consensus would have more downsides than straight up POS mining. Namely, even with 100 nodes people would call it centralized. I will probably work on a consensus based system in the future, but the POS mining is easier now.
Unlike NXT most of the transactions fees are paid as dividends and only a small portion paid to miners. Also unlike NXT, everyone is contributing to the security of the network when they make a transaction.
To my understanding, at least in the MVP, the Ripple style consensus and the neural network style positive feedback loop is abandoned. Am I wrong?
If it is true and you have already made the decision, I suppose a more clear and official announcement needs to be made.
-
+5%
And as I mentioned, I think we need to have the white papers updated before test chain(which might become real) starts.
Today I made more progress on the block generation and validation algorithm. The wallet has successfully mined a few blocks and the difficulty goes up when there is not enough Proof of Stake.
Tomorrow I will do the following:
1) Select inputs from your wallet oldest-first so that your transactions can be validated as quickly as possible and contribute the most to securing the chain.
2) Automatically generate transactions to yourself if it will generate enough CDD to reduce the difficulty to the minimum amount.
In response to the question about eliminating mining, I have concluded that ripple-style consensus would have more downsides than straight up POS mining. Namely, even with 100 nodes people would call it centralized. I will probably work on a consensus based system in the future, but the POS mining is easier now.
Unlike NXT most of the transactions fees are paid as dividends and only a small portion paid to miners. Also unlike NXT, everyone is contributing to the security of the network when they make a transaction.
To my understanding, at least in the MVP, the Ripple style consensus and the neural network style positive feedback loop is abandoned. Am I wrong?
If it is true and you have already made the decision, I suppose a more clear and official announcement needs to be made.
-
Today I decided to focus on the JSON-RPC API so that people could start building block explorers, web wallets, and other user interfaces that interact with my backend. To that end there is now a relatively complete JSON-RPC interface for communicating with the wallet, though the documentation on how to use it is sparse. Perhaps someone can update wiki.invictus.io with information on this RPC interface?
I am pleased to announce an alpha test period available to anyone who can compile the code. If you generate an address I will send you some test BTS to play around with. At this point it is very likely that we will find many bugs so I may reset the chain every day while I get the bugs fixed and this is why I am not releasing binaries right now.
Margin calls, trx fees, and interest are still left to be implemented and the only BitAsset right now is USD.
Let the testing begin :)
Please send some BTS or BitUSD,Thanks~
M6uPxhBuaRMHn7gJJn2mZ3Kh8RC
-
Today I made more progress on the block generation and validation algorithm. The wallet has successfully mined a few blocks and the difficulty goes up when there is not enough Proof of Stake.
Tomorrow I will do the following:
1) Select inputs from your wallet oldest-first so that your transactions can be validated as quickly as possible and contribute the most to securing the chain.
2) Automatically generate transactions to yourself if it will generate enough CDD to reduce the difficulty to the minimum amount.
In response to the question about eliminating mining, I have concluded that ripple-style consensus would have more downsides than straight up POS mining. Namely, even with 100 nodes people would call it centralized. I will probably work on a consensus based system in the future, but the POS mining is easier now.
Unlike NXT most of the transactions fees are paid as dividends and only a small portion paid to miners. Also unlike NXT, everyone is contributing to the security of the network when they make a transaction.
To my understanding, at least in the MVP, the Ripple style consensus and the neural network style positive feedback loop is abandoned. Am I wrong?
If it is true and you have already made the decision, I suppose a more clear and official announcement needs to be made.
+1
-
The latest changes to the client make it incompatible with earlier alpha test chains.
I will put together a new white paper before Valentines Day (Feb 14) which updates everything. I am effectively following the Trx as POS white paper Nov 28th with a few small tweaks.
-
The latest changes to the client make it incompatible with earlier alpha test chains.
I will put together a new white paper before Valentines Day (Feb 14) which updates everything. I am effectively following the Trx as POS white paper Nov 28th with a few small tweaks.
Excellent! Looking forward to all these great progress!
-
My BTS testing address:
SnXRh3rJLuWWEyDAcWSvJAUzV3s
Please send some Test Bitshares! :)
-
My BTS testing address:
LPfW6ExR2fzxzJj8fnSH8ejGP1z
Please send some Test Bitshares! :)
No testing is going on at the moment... but I will have a new test chain soon.
-
Is the latest BTS compatible with previous bts wallet? I compiled the latest code and import my previous bts wallet, but got this error when launching:
Out of Range(out_of_range)
read datastream of length 65 over by 18446744073709551613
error reading last item from database
error loading blockchain database datadir/chain
-
Is the latest BTS compatible with previous bts wallet? I compiled the latest code and import my previous bts wallet, but got this error when launching:
Out of Range(out_of_range)
read datastream of length 65 over by 18446744073709551613
error reading last item from database
error loading blockchain database datadir/chain
The code does not lie. I have tweaked the blockchain structure so the items in the database are not compatible.
-
Is the latest BTS compatible with previous bts wallet? I compiled the latest code and import my previous bts wallet, but got this error when launching:
Out of Range(out_of_range)
read datastream of length 65 over by 18446744073709551613
error reading last item from database
error loading blockchain database datadir/chain
The code does not lie. I have tweaked the blockchain structure so the items in the database are not compatible.
Does this mean that my testing bts and usd are gone? If so, can I get new testing bts and usd in the next testing period?
-
Is the latest BTS compatible with previous bts wallet? I compiled the latest code and import my previous bts wallet, but got this error when launching:
Out of Range(out_of_range)
read datastream of length 65 over by 18446744073709551613
error reading last item from database
error loading blockchain database datadir/chain
The code does not lie. I have tweaked the blockchain structure so the items in the database are not compatible.
Does this mean that my testing bts and usd are gone? If so, can I get new testing bts and usd in the next testing period?
Of course we will give fresh BTS for the new tests.
The next test chain will have margin call support and mining with Trx as Proof of Stake... I am working on the margin call code now.
-
Is the latest BTS compatible with previous bts wallet? I compiled the latest code and import my previous bts wallet, but got this error when launching:
Out of Range(out_of_range)
read datastream of length 65 over by 18446744073709551613
error reading last item from database
error loading blockchain database datadir/chain
The code does not lie. I have tweaked the blockchain structure so the items in the database are not compatible.
Does this mean that my testing bts and usd are gone? If so, can I get new testing bts and usd in the next testing period?
Of course we will give fresh BTS for the new tests.
The next test chain will have margin call support and mining with Trx as Proof of Stake... I am working on the margin call code now.
Great! I will wait for the new updates :)
-
Today I made some more progress on the margin call code. The majority of the code is in place and I am actively tracking down one bug at a time. The effort to setup the test cases is getting increasingly complex.
More updates to come tomorrow.
-
Today I made some more progress on the margin call code. The majority of the code is in place and I am actively tracking down one bug at a time. The effort to setup the test cases is getting increasingly complex.
More updates to come tomorrow.
+1
-
Initial bugs from margin calls have been resolved. I am sure there are a few more lurking in there..
Items on my todo list include:
1) Implement Trx Fees
2) Automate mining (it is currently manual and dependent upon manual trxs)
3) Dynamic fee adjustment based upon block size
4) Validate difficulty adjustment
5) Import bitcoin wallets and bitcoin private keys
6) Generate genesis block from PTS snapshot
7) Fix bugs / security / robustness of wallet.
Items I am leaving out of the MVP
1) Options
2) MultiSig Transactions
3) Cross Chain Trading
4) Escrow
5) Interest
I suspect that items 1 through 4 should be complete by Monday. I will be taking Friday through Sunday off to spend time with my kids. If all goes well we should be MVP feature complete by Valentines Day and can focus the last several of weeks on testing and robustness for a launch the first week of March.
-
Initial bugs from margin calls have been resolved. I am sure there are a few more lurking in there..
Items on my todo list include:
1) Implement Trx Fees
2) Automate mining (it is currently manual and dependent upon manual trxs)
3) Dynamic fee adjustment based upon block size
4) Validate difficulty adjustment
5) Import bitcoin wallets and bitcoin private keys
6) Generate genesis block from PTS snapshot
7) Fix bugs / security / robustness of wallet.
Items I am leaving out of the MVP
1) Options
2) MultiSig Transactions
3) Cross Chain Trading
4) Escrow
5) Interest
I suspect that items 1 through 4 should be complete by Monday. I will be taking Friday through Sunday off to spend time with my kids. If all goes well we should be MVP feature complete by Valentines Day and can focus the last several of weeks on testing and robustness for a launch the first week of March.
Is the first snapshot still 02/28?
-
Initial bugs from margin calls have been resolved. I am sure there are a few more lurking in there..
Items on my todo list include:
1) Implement Trx Fees
2) Automate mining (it is currently manual and dependent upon manual trxs)
3) Dynamic fee adjustment based upon block size
4) Validate difficulty adjustment
5) Import bitcoin wallets and bitcoin private keys
6) Generate genesis block from PTS snapshot
7) Fix bugs / security / robustness of wallet.
Items I am leaving out of the MVP
1) Options
2) MultiSig Transactions
3) Cross Chain Trading
4) Escrow
5) Interest
I suspect that items 1 through 4 should be complete by Monday. I will be taking Friday through Sunday off to spend time with my kids. If all goes well we should be MVP feature complete by Valentines Day and can focus the last several of weeks on testing and robustness for a launch the first week of March.
Is the first snapshot still 02/28?
Correct, Snapshot 2/28 launch shortly thereafter.
-
enjoy your family life :D
Initial bugs from margin calls have been resolved. I am sure there are a few more lurking in there..
Items on my todo list include:
1) Implement Trx Fees
2) Automate mining (it is currently manual and dependent upon manual trxs)
3) Dynamic fee adjustment based upon block size
4) Validate difficulty adjustment
5) Import bitcoin wallets and bitcoin private keys
6) Generate genesis block from PTS snapshot
7) Fix bugs / security / robustness of wallet.
Items I am leaving out of the MVP
1) Options
2) MultiSig Transactions
3) Cross Chain Trading
4) Escrow
5) Interest
I suspect that items 1 through 4 should be complete by Monday. I will be taking Friday through Sunday off to spend time with my kids. If all goes well we should be MVP feature complete by Valentines Day and can focus the last several of weeks on testing and robustness for a launch the first week of March.
-
Since my last post I have implemented the majority of trx fees including dynamic fee adjustment based upon blocksize. Tomorrow I will look for / fix bugs with the trx fee code and implement automated mining and importing keys from bitcoin.
-
Today I fixed several bugs, then got caught up getting things to build and compile using Apple's native clang++ rather than g++4.8 from macports.
-
Thank you a lot for the update. I have a question: will there be a GUI ready for early Mar. test?
-
Thank you a lot for the update. I have a question: will there be a GUI ready for early Mar. test?
I wouldn't bet on it. However, anyone is free to start developing the GUI as the API is available from the command-line version and there is a JSON-RPC interface.
Right now I am focused 100% on core functionality and robustness.
-
Thank you a lot for the update. I have a question: will there be a GUI ready for early Mar. test?
I wouldn't bet on it. However, anyone is free to start developing the GUI as the API is available from the command-line version and there is a JSON-RPC interface.
Right now I am focused 100% on core functionality and robustness.
Oh snap! Command-line version? I really hope there will be some instructions for us technically challenged.
-
Thank you a lot for the update. I have a question: will there be a GUI ready for early Mar. test?
I wouldn't bet on it. However, anyone is free to start developing the GUI as the API is available from the command-line version and there is a JSON-RPC interface.
Right now I am focused 100% on core functionality and robustness.
Oh snap! Command-line version? I really hope there will be some instructions for us technically challenged.
The command line version is actually not that difficult to use and we will have bounties for people to document how to use it for the masses on every OS.
-
Unfortunately today I spent on the phone with just about everyone on the team and thus didn't have any opportunity to write code. I will be spending time with my kids this weekend so there will be little progress for the next 2 days.
-
Enjoy a hugely deserved break 8)
-
Enjoy your well-deserved vacation. I have a question for you when you come back.
Correct me if I am wrong. BTS system has a main chain and several parallel chains. BTS is the currency on the main chain while coined BTS on the parallel chains. The main BTS currency is also an asset on each and every parallel chain. The parallel chains talk to the main one in order to enable cross-chain trading. My question is, what stops anyone from creating an exactly same alt parallel chain? I guess the question might better asks as: how are the communicating ports between the main chain and parallel chains protected? Or can anyone create a parallel chain?
-
Cross-chain communication is necessarily opt-in, so each chain can specify what you need to do to CTT with it. Two chains that are cross-tradeable have to both explicitly allow the other (whether directly or by some set of verification rules).
Also I'm pretty sure CTT does not mean that an asset leaves one chain and enters another, it just means two transfers on the two chains happen simultaneously and atomically (I send you BTS on BTSX in exchange for you sending me BitAPPL on BTSStocks).
-
Then BTS only needs to be on one chain? Why would parallel chains need their own currency?
Sent from my iPad using Tapatalk (http://tapatalk.com/m?id=1)
-
Then BTS only needs to be on one chain? Why would parallel chains need their own currency?
Sent from my iPad using Tapatalk (http://tapatalk.com/m?id=1)
I think they'd need their own share to have a unit of collateral? You can't short an asset into existence unless you have a base asset to short against
-
Then BTS only needs to be on one chain? Why would parallel chains need their own currency?
Sent from my iPad using Tapatalk (http://tapatalk.com/m?id=1)
The problem is space in the blockchain. Right now 16 different assets seems to be the max any one chain can handle. Because the market is in the chain this requires much more space than the with standard coins.
-
Hi bytemaster， need to speed up now. competitor Counterparty(XCP) has published its trading platform client for more than a month but we still do not have a barely working version client for BTSX.
https://bitcointalk.org/index.php?topic=395761.0 (https://bitcointalk.org/index.php?topic=395761.0)
-
Unfortunately today I spent on the phone with just about everyone on the team and thus didn't have any opportunity to write code. I will be spending time with my kids this weekend so there will be little progress for the next 2 days.
Am I wrong to assume that bytemaster is the only person working on this project? If this is the case, why?
-
http://invictus-innovations.com/s/News-Letter-05-February-2014.pdf
-
Unfortunately today I spent on the phone with just about everyone on the team and thus didn't have any opportunity to write code. I will be spending time with my kids this weekend so there will be little progress for the next 2 days.
Am I wrong to assume that bytemaster is the only person working on this project? If this is the case, why?
He is the main programer for btsx .
-
Unfortunately today I spent on the phone with just about everyone on the team and thus didn't have any opportunity to write code. I will be spending time with my kids this weekend so there will be little progress for the next 2 days.
Am I wrong to assume that bytemaster is the only person working on this project? If this is the case, why?
He is the main programer for btsx .
I understand that much. Question is: Is he the only programmer on btsx?
-
Unfortunately today I spent on the phone with just about everyone on the team and thus didn't have any opportunity to write code. I will be spending time with my kids this weekend so there will be little progress for the next 2 days.
Am I wrong to assume that bytemaster is the only person working on this project? If this is the case, why?
He is the main programer for btsx .
I understand that much. Question is: Is he the only programmer on btsx?
Arlen started 1 week ago and his first task is to help organize and hire more developers. He has made great progress and we now have several people that are working on BitShares X on a trial per-task basis prior to committing to hiring full time.
-
Unfortunately today I spent on the phone with just about everyone on the team and thus didn't have any opportunity to write code. I will be spending time with my kids this weekend so there will be little progress for the next 2 days.
Am I wrong to assume that bytemaster is the only person working on this project? If this is the case, why?
He is the main programer for btsx .
I understand that much. Question is: Is he the only programmer on btsx?
Arlen started 1 week ago and his first task is to help organize and hire more developers. He has made great progress and we now have several people that are working on BitShares X on a trial per-task basis prior to committing to hiring full time.
why not make another more official announcement that i3 is looking for developers on btt. I made one for the bounties but that sounded less official than if you or stan or someone would do it... I mean an announcement less associated with the bounties but more with a long term engagement...
-
According to the exiting margin call algorithm,if the bid price is much lower than the highest call price after matching the normal market order,is it possible that even the collateral BTS has been used up, but still can not cover the short position?
{
// consume the full call, leave change in the bid
auto cover_amount = payoff * call_price;
working_call.amount -= cover_amount; // is it possible the working_call.amount<=0
loan_amount += payoff;
collateral_amount += cover_amount + cover_amount;
working_bid.amount -= cover_amount;
market_trx.inputs.push_back( call_itr->location );
if( working_call.amount.get_rounded_amount() > 0 )
{
// TODO.. charge a 5% fee
market_trx.outputs.push_back(
trx_output( claim_by_signature_output( cover_claim.owner ), working_call.amount ) );
}
++call_itr;
if( call_itr != margin_positions.end() )
{
working_call = get_output( call_itr->location );
cover_claim = working_call.as<claim_by_cover_output>();
}
}
-
According to the exiting margin call algorithm,if the bid price is much lower than the highest call price after matching the normal market order,is it possible that even the collateral BTS has been used up, but still can not cover the short position?
{
// consume the full call, leave change in the bid
auto cover_amount = payoff * call_price;
working_call.amount -= cover_amount; // is it possible the working_call.amount<=0
loan_amount += payoff;
collateral_amount += cover_amount + cover_amount;
working_bid.amount -= cover_amount;
market_trx.inputs.push_back( call_itr->location );
if( working_call.amount.get_rounded_amount() > 0 )
{
// TODO.. charge a 5% fee
market_trx.outputs.push_back(
trx_output( claim_by_signature_output( cover_claim.owner ), working_call.amount ) );
}
++call_itr;
if( call_itr != margin_positions.end() )
{
working_call = get_output( call_itr->location );
cover_claim = working_call.as<claim_by_cover_output>();
}
}
Yes. It is possible for extreme market moves to leave some bit usd unbacked. These moves would have to be very quick (less than 1 hr) and very large ( greater than 50%) fall in value of bts.
However I believe that this will not break the peg because the network itself captures and destroys bit usd as part of normal trx fees. This lost bitusd puts upward pressure on the price of bitusd like someone holding infinite demand for this bitusd. Essentially there is never enough bitusd to cover all short positions and this provides some insurance against the times when there is not enough collateral to cover a short.
What this means effectively is that as long as you do not attempt to transact during a transient the peg will hold.
Sent from my iPhone using Tapatalk (http://tapatalk.com/m?id=1)
-
then does it mean such short position will never been covered if the user does not add margin?
-
then does it mean such short position will never been covered if the user does not add margin?
It means the losses are eaten by the network rather than the short position. The network earns the BitUSD necessary to cover these losses from transaction fees and in most cases accumulates a reasonable buffer prior to the event.
When a short positions runs out of collateral the network simply discards it as no rational actor would bother to pay additional losses.
Of course everyone trading must be aware of the assumptions baked into the blockchain prior to investing:
1) Rapid loss of value of 50% in hours is very rare, even for bitcoin (once the network is established)... can anyone show an example where Bitcoin lost 50% in hours (excluding the Mt. Gox flash crash)?
2) A loss of 50% is still break-even for the network, assuming everyone was fully collateralized before the 50% drop.
3) The most likely scenario for a 50% drop is after a large increase (bubble) which should be less likely given most shorts would use a BTS bubble as a covering opportunity (suppressing the bubble in the first place). The demand for BitUSD will increase as the bubble grows which keeps the bubble in check. Remember, BitUSD is the 'short' position against BTS.
4) The rise in value of BTS means that the collateral backing all existing BitUSD went up in value dramatically and thus a 50% fall is unlikely to even consume all of the collateral except for anyone who shorted BitUSD at the top of the BTS bubble. Few people would want to open a leverage position after such a massive run up and thus the amount of BitUSD that would lack sufficient margin to cover would be relatively small.
5) The worst case 50% fall that results in insufficient collateral would have to occur at a time when there was no recent run up and thus be triggered by something other than a bubble collapse. This would be like Bitcoin losing 50% of its value in an hour after having price stability for months. Possible trigger events include: finding a bug in the blockchain, shutdown of the internet, or some regulatory action. During such an event, perhaps after a long-slow fall in BTS value it is possible for many positions to start out with some loss and thus require less than 50% immediate drop to trigger an insufficient funds scenario.
6) The holder of BitUSD is not protected against systemic risks associated with all crypoto-currencies, only from the volatility that is independent of those systemic risks.
So what is the economic effect of having some shorts blow out and thus leaving more BitUSD in circulation than short positions that need covering? A fall in the value of BitUSD relative to BTS proportional to the unbacked BitUSD in existence. What is the economic effect of having some BitUSD destroyed by transaction fees? A rise in the value of BitUSD relative to BTS proportional to transaction fees destroyed.
However I believe that these supply driven theories of value will only play a part on the fringe / extreme cases and that the global consensus that BitUSD should be traded at a price point near real USD will have a far greater impact on the demand side of the equation.
Lastly I would like to make one last observation, large market moves that result in significant un-collateralized BitUSD will result in one-time devaluation of BitUSD.... but this one time devaluation would simply create a new constant offset from BitUSD and the market will continue to operate with very high correlation to real USD. In other words, BitUSD is useful as an investment vehicle due to its correlation and not its price. What we are pegging is the correlation and not the price.
Thus those long BitUSD have an insurance policy against BTS price drops with a maximum payout of 2x. They bear all risk beyond 2x.
-
1) Rapid loss of value of 50% in hours is very rare, even for bitcoin (once the network is established)... can anyone show an example where Bitcoin lost 50% in hours (excluding the Mt. Gox flash crash)?
I'm still crying for lack of buyorder @BTC-e today (http://bitcoinwisdom.com/markets/btce/btcusd).
The holder of BitUSD is not protected against systemic risks associated with all crypoto-currencies, only from the volatility that is independent of those systemic risks.
+3%
-
then does it mean such short position will never been covered if the user does not add margin?
It means the losses are eaten by the network rather than the short position. The network earns the BitUSD necessary to cover these losses from transaction fees and in most cases accumulates a reasonable buffer prior to the event.
When a short positions runs out of collateral the network simply discards it as no rational actor would bother to pay additional losses.
Of course everyone trading must be aware of the assumptions baked into the blockchain prior to investing:
1) Rapid loss of value of 50% in hours is very rare, even for bitcoin (once the network is established)... can anyone show an example where Bitcoin lost 50% in hours (excluding the Mt. Gox flash crash)?
2) A loss of 50% is still break-even for the network, assuming everyone was fully collateralized before the 50% drop.
3) The most likely scenario for a 50% drop is after a large increase (bubble) which should be less likely given most shorts would use a BTS bubble as a covering opportunity (suppressing the bubble in the first place). The demand for BitUSD will increase as the bubble grows which keeps the bubble in check. Remember, BitUSD is the 'short' position against BTS.
4) The rise in value of BTS means that the collateral backing all existing BitUSD went up in value dramatically and thus a 50% fall is unlikely to even consume all of the collateral except for anyone who shorted BitUSD at the top of the BTS bubble. Few people would want to open a leverage position after such a massive run up and thus the amount of BitUSD that would lack sufficient margin to cover would be relatively small.
5) The worst case 50% fall that results in insufficient collateral would have to occur at a time when there was no recent run up and thus be triggered by something other than a bubble collapse. This would be like Bitcoin losing 50% of its value in an hour after having price stability for months. Possible trigger events include: finding a bug in the blockchain, shutdown of the internet, or some regulatory action. During such an event, perhaps after a long-slow fall in BTS value it is possible for many positions to start out with some loss and thus require less than 50% immediate drop to trigger an insufficient funds scenario.
6) The holder of BitUSD is not protected against systemic risks associated with all crypoto-currencies, only from the volatility that is independent of those systemic risks.
So what is the economic effect of having some shorts blow out and thus leaving more BitUSD in circulation than short positions that need covering? A fall in the value of BitUSD relative to BTS proportional to the unbacked BitUSD in existence. What is the economic effect of having some BitUSD destroyed by transaction fees? A rise in the value of BitUSD relative to BTS proportional to transaction fees destroyed.
However I believe that these supply driven theories of value will only play a part on the fringe / extreme cases and that the global consensus that BitUSD should be traded at a price point near real USD will have a far greater impact on the demand side of the equation.
Lastly I would like to make one last observation, large market moves that result in significant un-collateralized BitUSD will result in one-time devaluation of BitUSD.... but this one time devaluation would simply create a new constant offset from BitUSD and the market will continue to operate with very high correlation to real USD. In other words, BitUSD is useful as an investment vehicle due to its correlation and not its price. What we are pegging is the correlation and not the price.
Thus those long BitUSD have an insurance policy against BTS price drops with a maximum payout of 2x. They bear all risk beyond 2x.
thank you very much for your further clarification!!!
Sent from my iPhone using Tapatalk
-
Do asset holders still get dividends from BTS backing them? How do you deal with fees in different assets?
-
Do asset holders still get dividends from BTS backing them? How do you deal with fees in different assets?
When I moved to implementing dividends by simply destroying the coins rather than managing micro payments I was no longer able to redirect dividends to bitassets. At this point in time I suggested switching to a hard coded 5%... Then there was the debate on whether the 5% meant anything other than a constant offset. I am going to start with 0% in the first chain for simplicity, then experiment with alternatives by implementing the interest rate later. Less things to go wrong in the initial release.
In the case of BitAssets they still require fees to be paid in BTS when they are transferred. When trading on the market some of the bitassets are kept as fees. This destroys the BitAssets and thus serves as a kind of dividend on bitassets.
-
In the case of BitAssets they still require fees to be paid in BTS when they are transferred.
If this is the case then there should be a way to buy enough BTS for the tx fee and perform the BitAsset transfer in one transaction, and the reference client should use that by default when you're only holding Assets
Most people will just want to hold BitCurrency and not worry about purchasing BTS for fees
-
In the case of BitAssets they still require fees to be paid in BTS when they are transferred.
If this is the case then there should be a way to buy enough BTS for the tx fee and perform the BitAsset transfer in one transaction, and the reference client should use that by default when you're only holding Assets
Most people will just want to hold BitCurrency and not worry about purchasing BTS for fees
Challenging task.
-
In the case of BitAssets they still require fees to be paid in BTS when they are transferred.
If this is the case then there should be a way to buy enough BTS for the tx fee and perform the BitAsset transfer in one transaction, and the reference client should use that by default when you're only holding Assets
Most people will just want to hold BitCurrency and not worry about purchasing BTS for fees
Challenging task.
For sure, I'm thinking that should happen the same time you make a GUI and/or web wallets, so not soon
-
Today I implemented most of the code required to automate proof of stake mining. All that remains on this task is to actually pay the mining reward to the miner for their CDD contributed to the block and to validate this mining reward.
-
In the case of BitAssets they still require fees to be paid in BTS when they are transferred.
If this is the case then there should be a way to buy enough BTS for the tx fee and perform the BitAsset transfer in one transaction, and the reference client should use that by default when you're only holding Assets
Most people will just want to hold BitCurrency and not worry about purchasing BTS for fees
Challenging task.
For sure, I'm thinking that should happen the same time you make a GUI and/or web wallets, so not soon
This sounds similar to what Ripple is like. You run out of XRP and suddenly your account is frozen because you can't afford to pay for transactions.
-
Today I implemented most of the code required to automate proof of stake mining. All that remains on this task is to actually pay the mining reward to the miner for their CDD contributed to the block and to validate this mining reward.
I am a big fan of 3I and BTS , thank you for your hard work. :)
-
I am going to start with 0% in the first chain for simplicity, then experiment with alternatives by implementing the interest rate later. Less things to go wrong in the initial release.
It should be [conceptually] easy to establish a loanable funds market. Consider that the price of an asset can be modeled as a function of the expected future benefit (F), the time that one has to wait for that benefit (t), and the prevailing interest rate (i), such that:
P = F / (1+i)^t
Note that F and t are fixed in the agreement; e.g., "Party A agrees to pay bearer $F t units of time from now.
BitShares determine P through the market process, leaving only i to be determined as the lone unknown. Basically, set up a market for BitLoans, and i pops out automatically.
In the case of BitAssets they still require fees to be paid in BTS when they are transferred. When trading on the market some of the bitassets are kept as fees. This destroys the BitAssets and thus serves as a kind of dividend on bitassets.
This is an elegant solution that gets around taxation issues in jurisdictions that have income taxes. If you pay a dividend, then that is a taxable event in many places, especially the places where BitShares early adopters live. However, if you burn BitAssets, then no one has receive a direct payment, and the gain takes the form of capital gains.
In places with 0% long-term capital gains, like Germany, this could result in a zero-tax gain for long-term BitAsset holders.
-
i wonder whether it's possible to have some BTS screenshots posted here, since the test launch will come in half a month. may be no GUI right now, command line is also OK.
-
Today I made progress on paying mining rewards and including extra transactions from your own wallet when there is insufficient CDD from 3rd party transactions.
I have a few small bugs to work out before I can completely check this item off of my list.
Tomorrow I will be focused on getting the BitShares XT white paper out for everyone. My goal is feature complete by Monday... actual milage may vary.
I will then produce some console captures for people that want to see what the command line experience is.
-
Hi Daniel. When does the next testing phase start? Feb 28?
-
Hi Daniel. When does the next testing phase start? Feb 28?
Hopefully next week.
-
Today I implemented most of the code required to automate proof of stake mining. All that remains on this task is to actually pay the mining reward to the miner for their CDD contributed to the block and to validate this mining reward.
I am a big fan of 3I and BTS , thank you for your hard work. :)
Thanks to 3I's efforts, the permanent support 3I！ ;D
-
Hi Daniel. When does the next testing phase start? Feb 28?
Hopefully next week.
when will you initial the test chain again? has the p2p feature been implemented?
-
Today I implemented most of the code required to automate proof of stake mining. All that remains on this task is to actually pay the mining reward to the miner for their CDD contributed to the block and to validate this mining reward.
Hi bytemaster,
Is the auto mine achieved by sending BTS to self addresses? I'm wandering whether it could cause the wallet.bts going large since new addresses are keeping being created when aotomine.
-
Today I made progress on paying mining rewards and including extra transactions from your own wallet when there is insufficient CDD from 3rd party transactions.
I have a few small bugs to work out before I can completely check this item off of my list.
Tomorrow I will be focused on getting the BitShares XT white paper out for everyone. My goal is feature complete by Monday... actual milage may vary.
I will then produce some console captures for people that want to see what the command line experience is.
What happens if 2 miners with significant amounts of cash (and CDD) find blocks ?
How do you determine how much "extra transactions from your own wallet" a miner should include to a block?
What if the other miner outbids you? Do you try again including more "extra transactions from your own wallet"?
-
i wonder whether it's possible to have some BTS screenshots posted here, since the test launch will come in half a month. may be no GUI right now, command line is also OK.
You can find some screenshots here:
https://bitsharestalk.org/index.php?topic=2515
though it is a little out of date.
-
Can I have some BTS please?
L738iyRDVx6YZx65Kj9tFjkHkBB
-
ETA on testnet with p2p and TAPOS?
-
Is anyone internally working on a GUI or are you leaving that up for an external bounty?
-
Is anyone internally working on a GUI or are you leaving that up for an external bounty?
We have one guy who has been tasked with working on a Qt GUI and whom we will be hiring in a few weeks. For now he is working on it in his spare time.
-
Today I have updated the BitShares X white paper... it is still a draft with many issues, but probably fewer issues than the original BitShares white paper.
https://docs.google.com/document/d/1RLcjSXWuU9vBJzzqLEXVACSCdn8zXKTTJRN_LfoCjNY/edit?pli=1#
-
ETA on testnet with p2p and TAPOS?
Monday. It is currently working in my local tests, but I want to do a few more tests before launching it for more people.
-
ETA on testnet with p2p and TAPOS?
Monday. It is currently working in my local tests, but I want to do a few more tests before launching it for more people.
+5%
-
Today I have updated the BitShares X white paper... it is still a draft with many issues, but probably fewer issues than the original BitShares white paper.
https://docs.google.com/document/d/1RLcjSXWuU9vBJzzqLEXVACSCdn8zXKTTJRN_LfoCjNY/edit?pli=1#
Dude... nice.
-
I don't understand why you think there needs to be dividends. And I dont understand how short positions are borrowing bitassets when bitassets dont exist. Otherwise everything else sounds pretty good.
-
A bit asset is an IOU 1usd worth of bts. It is no different than the old bank notes that were IOU 1 usd worth of gold.
The difference is the collateral and redemption method.
Given two otherwise identical dacs, one with dividends and one without which is more valuable to own?
Sent from my iPhone using Tapatalk (http://tapatalk.com/m?id=1)
-
It's not the same as a promissory note from a bank because no one is actually making a deposit to a bank. This not a bank! It is a contract between two parties that one party will take on all the risk/reward while the other party maintains price stability. Maybe I don't understand how this works within the blockchain, but it sounds like you're abstracting things so they appear analogous to a bank.
Also dividends are simply a ploy for getting people to invest in you're stock. You reward long term holders of your stock by reinvesting in youre company with whatever profits you make. Stockholders profit from increases in stock prices more than dividends if you reinvest profits appropriately. Look at Berkshire Hathaway. In the case of this DAC you raise transaction fees for the purpose of providing dividends, when you could reduce the transaction fee, provide further liquidity to the markets and consequently bolster the utility of the network.
Given two otherwise identical exchange networks, which is more viable the one with higher fees or lower fees?
-
It's not the same as a promissory note from a bank because no one is actually making a deposit to a bank. This not a bank! It is a contract between two parties that one party will take on all the risk/reward while the other party maintains price stability. Maybe I don't understand how this works within the blockchain, but it sounds like you're abstracting things so they appear analogous to a bank.
Also dividends are simply a ploy for getting people to invest in you're stock. You reward long term holders of your stock by reinvesting in youre company with whatever profits you make. Stockholders profit from increases in stock prices more than dividends if you reinvest profits appropriately. Look at Berkshire Hathaway. In the case of this DAC you raise transaction fees for the purpose of providing dividends, when you could reduce the transaction fee, provide further liquidity to the markets and consequently bolster the utility of the network.
Given two otherwise identical exchange networks, which is more viable the one with higher fees or lower fees?
Actually, I don't raise fees with the intent of increasing dividends because the network must have the lowest possible fees to be competitive in the market. A network must have fees to prevent spam and recognize that for a given level of decentralization there is a limit on the number of transactions per second that can be processed. Thus fees (and dividends) come from owning this scarce resource.
Your understanding of how BitAssets works is assuming two people with no middle man. The short and long positions are not contracts between TWO people. They are "contracts" with the network. A bank serves as an intermediary and allows people to transact in fungible notes rather than individual IOUs from a bunch of strangers. Likewise BitShares X makes everyones BitUSD fungible, divisible, etc. If the "contracts" were between two people they would both have to agree to unwind the contract at the same time. This is the CORE difference between what we are doing and what every single competitor is offering (Countyparty, etc).
-
If I were to eliminate "dividends" then it would not change the fees, I would just have to pick someone else to benefit.
In reality, I could use a different analogy, that of a stock buyback. This has the effect of boosting the value of the shares as there are fewer in circulation. In effect it is better than a dividend because it 'compounds' and thus accomplishes the same goal as 'reinvesting' in the network.
-
So if I cover my short position, the bitUSD still exists? But now that bitUSD doesn't have the same collateral backing it, or rather all the BitUSD in existence doesnt still have 200% collateral. How is this remedied?
In terms of transaction fees. Can anything else be done instead of destroying coins?
-
When you cover your position those BitUSD are destroyed... but if you lack enough collateral to cover it all then some BitUSD will be left in circulation despite your position being closed.
-
What is wrong with destroying coins? The value has to go somewhere... either the miner or everyone.
-
When you cover your position those BitUSD are destroyed... but if you lack enough collateral to cover it all then some BitUSD will be left in circulation despite your position being closed.
Can you use some sort of a queue for short positions so that bitassets do not need to be destroyed?
What is wrong with destroying coins? The value has to go somewhere... either the miner or everyone.
Nothing is wrong with destroying coins, its obviously better than paying all transaction fees to miners, particularly when they do not add to the security of the network. I just don't like the general idea of destroying things, but since you're destroying coin days all over the place, might as well destroy some coins also haha
-
Perhaps verbiage makes all the difference... we are decommissioning the shares..... holding them forever in a 'share heaven' where they will live happily ever after as God rewards them for sharing with others during their life on the chain.
-
Today I fixed some minor bugs, added support for reading a configuration file for bts_wallet and focused on updating the documentation which generated a whole host of new TODO items for me.
You can view the latest BitShares X wallet and JSON-RPC documentation here:
http://invictus.io/bitsharesx_wallet_docs.html
This documentation is a work in progress and I am missing many calls.
-
I just identified an missing feature that people will probably want / complain about if I don't fix. Right now you cannot use your collateral to buy BitUSD to cover your position. You must use additional funds to buy the BitUSD then use the BitUSD to recover your collateral. While I am sure market participants could work around and manage the requirement to have extra BTS around so they can cover their position, we may want to resolve this issue.
From where I sit this may require a new output type (bid with collateral) and thus this change is non-trivial to implement. This is probably a 2-3 day task in its own right.
-
I just identified an missing feature that people will probably want / complain about if I don't fix. Right now you cannot use your collateral to buy BitUSD to cover your position. You must use additional funds to buy the BitUSD then use the BitUSD to recover your collateral. While I am sure market participants could work around and manage the requirement to have extra BTS around so they can cover their position, we may want to resolve this issue.
From where I sit this may require a new output type (bid with collateral) and thus this change is non-trivial to implement. This is probably a 2-3 day task in its own right.
Put it off IMO, same class of feature as being able to pay tx fees in assets rather than bts
-
Today I fixed some minor bugs, added support for reading a configuration file for bts_wallet and focused on updating the documentation which generated a whole host of new TODO items for me.
You can view the latest BitShares X wallet and JSON-RPC documentation here:
http://invictus.io/bitsharesx_wallet_docs.html
This documentation is a work in progress and I am missing many calls.
According to this documentation, the feature to display transaction history seems missing.
-
Today I fixed some minor bugs, added support for reading a configuration file for bts_wallet and focused on updating the documentation which generated a whole host of new TODO items for me.
You can view the latest BitShares X wallet and JSON-RPC documentation here:
http://invictus.io/bitsharesx_wallet_docs.html
This documentation is a work in progress and I am missing many calls.
According to this documentation, the feature to display transaction history seems missing.
You are correct, it currently prints your unspent outputs with the balance output. I will have some significant wallet enhancements tomorrow that will address this.
-
Today I spent some time refining the wallet security and robustness. This work is incomplete but I can summarize some of the changes:
1) Address Book for send and recv addresses can now take a label
2) the wallet.bts file can be entirely encrypted (including all of your addressbook info) separately from your private keys.
3) private keys are now always stored encrypted.
4) added ability to enter passwords without echo to console
5) Improved tracking of transactions so that I can produce a meaningful transaction history.
The current code in github compiles but does not function, I will complete this task tomorrow.
-
I think something is not correct, but i can't write with english.
拿 bts /usd 市场看，假如现有很多买单了
10000 usd 0.01 bts/usd
800 usd 0.009 bts/usd
800 usd 0.008 bts/usd
.....
我先挂一个买单
100,000,000 usd 0.00000001 bts/usd
排在最末尾
然后我挂一个 short 操作
按 0.000000001 bts/usd 价格发行 1000,000,000 usd
是不是所有买单都能成交？大家都拿到了 bitusd，我自己也拿到了 100,000,000 bitusd。
然后下一次，我的 short 会被强制平仓，损失所有抵押的 1bts。
最终结果是 我会有1bts 抵押损失，留下大量 bitusd 空头，及 100,000,000 bitusd
应该改撮合算法。
对short 撮合算法应该按 bts 数量判断是否完成。
比如我 1bts 发行 100000 usd，只要我收到 1bts 就结束，最终结果不一定能发行 100000 usd，可能 100 usd 就结束了。
结果是2 bts 抵押 100 usd。
在系统刚运行，市场上没任何买单时，还是会有漏洞。
比如我自己做了唯一的买单是 1bts 1亿美金，唯一的 short 也是这个价。那我就是牺牲2个bts，拿到1亿美金。
程序可以限制 short 撮合算法必须在足够买单之后才能启动。
-
I think something is not correct, but i can't write with english.
拿 bts /usd 市场看，假如现有很多买单了
10000 usd 0.01 bts/usd
800 usd 0.009 bts/usd
800 usd 0.008 bts/usd
.....
我先挂一个买单
100,000,000 usd 0.00000001 bts/usd
排在最末尾
然后我挂一个 short 操作
按 0.000000001 bts/usd 价格发行 1000,000,000 usd
是不是所有买单都能成交？大家都拿到了 bitusd，我自己也拿到了 100,000,000 bitusd。
然后下一次，我的 short 会被强制平仓，损失所有抵押的 1bts。
最终结果是 我会有1bts 抵押损失，留下大量 bitusd 空头，及 100,000,000 bitusd
应该改撮合算法。
对short 撮合算法应该按 bts 数量判断是否完成。
比如我 1bts 发行 100000 usd，只要我收到 1bts 就结束，最终结果不一定能发行 100000 usd，可能 100 usd 就结束了。
结果是2 bts 抵押 100 usd。
在系统刚运行，市场上没任何买单时，还是会有漏洞。
比如我自己做了唯一的买单是 1bts 1亿美金，唯一的 short 也是这个价。那我就是牺牲2个bts，拿到1亿美金。
程序可以限制 short 撮合算法必须在足够买单之后才能启动。
Will someone translate this for me. Thanks.
Sent from my iPhone using Tapatalk (http://tapatalk.com/m?id=1)
-
do this:
buy 100,000,000 usd with 1bts
short 100,000,000 usd with 1bts
then I get 100,000,000 usd, 2bts will be margin call
-
do this:
buy 100,000,000 usd with 1bts
short 100,000,000 usd with 1bts
then I get 100,000,000 usd, 2bts will be margin call
That looks right to me... 2 bts is the collateral. Margin call would be at .66667 bts price point.
-
match_order for claim_long
if( ask_amount_usd < bid_amount_usd )
{ // then we have filled the ask
pay_asker += ask_amount_usd;
loan_amount += ask_amount_usd;
I think here should change to
if( ask_amount_bts < bid_amount_bts )
-
So I can get any usd if I want ....
because I can short usd with any price
do this:
buy 100,000,000 usd with 1bts
short 100,000,000 usd with 1bts
then I get 100,000,000 usd, 2bts will be margin call
That looks right to me... 2 bts is the collateral. Margin call would be at .66667 bts price point.
-
match_order for claim_long
if( ask_amount_usd < bid_amount_usd )
{ // then we have filled the ask
pay_asker += ask_amount_usd;
loan_amount += ask_amount_usd;
I think here should change to
if( ask_amount_bts < bid_amount_bts )
Reason?
-
current price is 1000usd/bts
here is the buy order:
buy 1000 usd with 1bts
buy 1001 usd with 1bts
buy 1002 usd with 1bts
.....
buy 1100 usd with 1bts
anytime I can give a buy order with
buy 1000000000 usd with 1bts
And I can give a short with
short 10000000000 usd with 1bts
this will match all buy order in the market
match_order for claim_long
if( ask_amount_usd < bid_amount_usd )
{ // then we have filled the ask
pay_asker += ask_amount_usd;
loan_amount += ask_amount_usd;
I think here should change to
if( ask_amount_bts < bid_amount_bts )
Reason?
-
So I can get any usd if I want ....
because I can short usd with any price
do this:
buy 100,000,000 usd with 1bts
short 100,000,000 usd with 1bts
then I get 100,000,000 usd, 2bts will be margin call
That looks right to me... 2 bts is the collateral. Margin call would be at .66667 bts price point.
When you are the only market participant then that is true. However, if you are not the only participant then you are constrained by others.
-
But I think I can match all buy orders in the market
Because I can short usd with any price.
So I can get any usd if I want ....
because I can short usd with any price
do this:
buy 100,000,000 usd with 1bts
short 100,000,000 usd with 1bts
then I get 100,000,000 usd, 2bts will be margin call
That looks right to me... 2 bts is the collateral. Margin call would be at .66667 bts price point.
When you are the only market participant then that is true. However, if you are not the only participant then you are constrained by others.
-
current price is 1000usd/bts
here is the buy order:
buy 1000 usd with 1bts
buy 1001 usd with 1bts
buy 1002 usd with 1bts
.....
buy 1100 usd with 1bts
anytime I can give a buy order with
buy 1000000000 usd with 1bts
And I can give a short with
short 10000000000 usd with 1bts
So there is a line of people each wanting to buy about 1000 usd for 1 bts ....
And along comes someone who wants to sell 1000,0000 usd for 1 bts....
Assuming he actually had this usd (ie it was a long/long sale) then the market should match him against all of the buys (4103 usd), give the seller his .0001 bts and earn 3.999 bts in fees for the network because the seller was an idiot and sold way below market.
Now in the event of a short position the result of this move should be...
Buyers get 4103 usd and the short seller ends up short -4103 with collateral of 4 bts (from buyers) + .0001 bts (from himself) which would seem to justify a margin call immediately... thus I need to adjust the short-sell code to always use the price of the bids to determine required collateral (bts) or this kind of abuse could carry on.
Let me look into it a tad more and if it pans out I will send 25 PTS your way for finding this.
-
no, short seller ends up short -(4103 + 1000000000) usd + 100000000usd + 4.001bts
after margin call, he left 1000000000usd
Buyers get 4103 usd and the short seller ends up short -4103 with collateral of 4 bts (from buyers) + .0001 bts (from himself) which would seem to justify a margin call immediately... thus I need to adjust the short-sell code to always use the price of the bids to determine required collateral (bts) or this kind of abuse could carry on.
Let me look into it a tad more and if it pans out I will send 25 PTS your way for finding this.
-
this is not enough.
It can't work at the beginning, just 2 order:
buy 10000000 usd with 1bts
short 10000000 usd with 1bts
so we should add two limit:
1. matching_order for claim_long only work when buy order is enough
2. can't short with price low than current price
match_order for claim_long
if( ask_amount_usd < bid_amount_usd )
{ // then we have filled the ask
pay_asker += ask_amount_usd;
loan_amount += ask_amount_usd;
I think here should change to
if( ask_amount_bts < bid_amount_bts )
-
What I really concern about is that there is always possibility(even it's very small, but not neglectable since we may just have a small market at beginning) that in one specific 5 min(time of producing a block), just a bit of (let's say) 10000000BitUSD/XTS vs. a same or similar ask, then we will have tremendous quantity of non-backing BitUSD. I think we need to find a way to resolve it, we may need to elimate the non-backing BitAssets at all since it may cause the collapse of the whole system.
-
bytemaster，now you would like to send me 25 PTS，or 23PTS and 2PTS to some Interpreter.
alt又把人绕进去了，变成先鸡生蛋还是先蛋生鸡的问题了。
很简单。其实，只要系统强制要求bta必须按与当时实物a价格挂钩的方法，规定用法币在系统外或系统本身设置的接口兑换取得bta，这样bta数量是有限的（随时间推移从小到大）。因此，没人会拿用真金白银买到的bta出过高的价格买你的天价BTS，更不会出现所说的上亿个无抵押bta。BTS是系统内已有的（也是有成本的），bta是外来的（不是凭空产生的，而是用法币买的），alt推论的前提不成立，推理无立足点，结论自然错了。
current price is 1000usd/bts
here is the buy order:
buy 1000 usd with 1bts
buy 1001 usd with 1bts
buy 1002 usd with 1bts
.....
buy 1100 usd with 1bts
anytime I can give a buy order with
buy 1000000000 usd with 1bts
And I can give a short with
short 10000000000 usd with 1bts
So there is a line of people each wanting to buy about 1000 usd for 1 bts ....
And along comes someone who wants to sell 1000,0000 usd for 1 bts....
Assuming he actually had this usd (ie it was a long/long sale) then the market should match him against all of the buys (4103 usd), give the seller his .0001 bts and earn 3.999 bts in fees for the network because the seller was an idiot and sold way below market.
Now in the event of a short position the result of this move should be...
Buyers get 4103 usd and the short seller ends up short -4103 with collateral of 4 bts (from buyers) + .0001 bts (from himself) which would seem to justify a margin call immediately... thus I need to adjust the short-sell code to always use the price of the bids to determine required collateral (bts) or this kind of abuse could carry on.
Let me look into it a tad more and if it pans out I will send 25 PTS your way for finding this.
-
bytemaster，now you would like to send me 25 PTS，or 23PTS and 2PTS to some Interpreter.
alt又把人绕进去了，变成先鸡生蛋还是先蛋生鸡的问题了。
很简单。其实，只要系统强制要求ＢＴＡ必须按与当时实物Ａ价格挂钩的方法，规定用法币在系统外或系统本身设置的接口兑换取得ＢＴＡ，系统内ＢＴＡ数量是有限的（从小到大）。这样，没人会拿用真金白银买到的ＢＴＡ出过高的价格买你的天价ＢＴＳ，更不会出现所说的上亿个无抵押ＢＴＡ。BTS是系统内已有的（也是有成本的），BTA是外来的（不是凭空产生的，而是用法币买的），alt推论的前提不成立，推理无立足点，结论自然错了。
current price is 1000usd/bts
here is the buy order:
buy 1000 usd with 1bts
buy 1001 usd with 1bts
buy 1002 usd with 1bts
.....
buy 1100 usd with 1bts
anytime I can give a buy order with
buy 1000000000 usd with 1bts
And I can give a short with
short 10000000000 usd with 1bts
So there is a line of people each wanting to buy about 1000 usd for 1 bts ....
And along comes someone who wants to sell 1000,0000 usd for 1 bts....
Assuming he actually had this usd (ie it was a long/long sale) then the market should match him against all of the buys (4103 usd), give the seller his .0001 bts and earn 3.999 bts in fees for the network because the seller was an idiot and sold way below market.
Now in the event of a short position the result of this move should be...
Buyers get 4103 usd and the short seller ends up short -4103 with collateral of 4 bts (from buyers) + .0001 bts (from himself) which would seem to justify a margin call immediately... thus I need to adjust the short-sell code to always use the price of the bids to determine required collateral (bts) or this kind of abuse could carry on.
Let me look into it a tad more and if it pans out I will send 25 PTS your way for finding this.
The individual who found the issue should receive the 23 pts and an interpreter should get 2 pts... let me know who should get what.
-
No, It's not the business about real USD.
bytemaster，now you would like to send me 25 PTS，or 23PTS and 2PTS to some Interpreter.
alt又把人绕进去了，变成先鸡生蛋还是先蛋生鸡的问题了。
很简单。其实，只要系统强制要求ＢＴＡ必须按与当时实物Ａ价格挂钩的方法，规定用法币在系统外或系统本身设置的接口兑换取得ＢＴＡ，系统内ＢＴＡ数量是有限的（从小到大）。这样，没人会拿用真金白银买到的ＢＴＡ出过高的价格买你的天价ＢＴＳ，更不会出现所说的上亿个无抵押ＢＴＡ。BTS是系统内已有的（也是有成本的），BTA是外来的（不是凭空产生的，而是用法币买的），alt推论的前提不成立，推理无立足点，结论自然错了。
-
It's a serious problem if I am not wrong.
Can I get the 25 pts? ;D
The individual who found the issue should receive the 23 pts and an interpreter should get 2 pts... let me know who should get what.
-
Can't build on linux now:
filesystem.cpp|415 col 44| error: ‘home_dir’ was not declared in this scope
don't know if it's ok to use QApplication::applicationDirPath() in bts_wallet/main.cpp
-
Can't build on linux now:
filesystem.cpp|415 col 44| error: ‘home_dir’ was not declared in this scope
don't know if it's ok to use QApplication::applicationDirPath() in bts_wallet/main.cpp
No, bts_wallet is free of Qt.
Update fc from github.
-
Can't build on linux now:
filesystem.cpp|415 col 44| error: ‘home_dir’ was not declared in this scope
don't know if it's ok to use QApplication::applicationDirPath() in bts_wallet/main.cpp
No, bts_wallet is free of Qt.
Update fc from github.
Got it, thx
-
没人翻译吗？12小时后我自己来。
bytemaster，now you would like to send me 25 PTS，or 23PTS and 2PTS to some Interpreter.
alt又把人绕进去了，变成先鸡生蛋还是先蛋生鸡的问题了。
很简单。其实，只要系统强制要求ＢＴＡ必须按与当时实物Ａ价格挂钩的方法，规定用法币在系统外或系统本身设置的接口兑换取得ＢＴＡ，系统内ＢＴＡ数量是有限的（从小到大）。这样，没人会拿用真金白银买到的ＢＴＡ出过高的价格买你的天价ＢＴＳ，更不会出现所说的上亿个无抵押ＢＴＡ。BTS是系统内已有的（也是有成本的），BTA是外来的（不是凭空产生的，而是用法币买的），alt推论的前提不成立，推理无立足点，结论自然错了。
current price is 1000usd/bts
here is the buy order:
buy 1000 usd with 1bts
buy 1001 usd with 1bts
buy 1002 usd with 1bts
.....
buy 1100 usd with 1bts
anytime I can give a buy order with
buy 1000000000 usd with 1bts
And I can give a short with
short 10000000000 usd with 1bts
So there is a line of people each wanting to buy about 1000 usd for 1 bts ....
And along comes someone who wants to sell 1000,0000 usd for 1 bts....
Assuming he actually had this usd (ie it was a long/long sale) then the market should match him against all of the buys (4103 usd), give the seller his .0001 bts and earn 3.999 bts in fees for the network because the seller was an idiot and sold way below market.
Now in the event of a short position the result of this move should be...
Buyers get 4103 usd and the short seller ends up short -4103 with collateral of 4 bts (from buyers) + .0001 bts (from himself) which would seem to justify a margin call immediately... thus I need to adjust the short-sell code to always use the price of the bids to determine required collateral (bts) or this kind of abuse could carry on.
Let me look into it a tad more and if it pans out I will send 25 PTS your way for finding this.
The individual who found the issue should receive the 23 pts and an interpreter should get 2 pts... let me know who should get what.
-
自己钻牛角尖了，死不承认。
No, It's not the business about real USD.
bytemaster，now you would like to send me 25 PTS，or 23PTS and 2PTS to some Interpreter.
alt又把人绕进去了，变成先鸡生蛋还是先蛋生鸡的问题了。
很简单。其实，只要系统强制要求ＢＴＡ必须按与当时实物Ａ价格挂钩的方法，规定用法币在系统外或系统本身设置的接口兑换取得ＢＴＡ，系统内ＢＴＡ数量是有限的（从小到大）。这样，没人会拿用真金白银买到的ＢＴＡ出过高的价格买你的天价ＢＴＳ，更不会出现所说的上亿个无抵押ＢＴＡ。BTS是系统内已有的（也是有成本的），BTA是外来的（不是凭空产生的，而是用法币买的），alt推论的前提不成立，推理无立足点，结论自然错了。
-
Today I implemented the code necessary to initialize the genesis block from the .json files being produced by this bounty: https://bitsharestalk.org/index.php?topic=2869.0
I implemented the output type required to claim based upon PTS or BTC addresses.
I fixed the bugs in the encrypted wallet loading and improved robustness of saving wallet data.
Tomorrow I will have the wallet import private keys using the various utility methods that have been produced by bounties and then display the starting balances as well as add the ability to spend BTC and PTS balances.
Then I have to look into the issue identified by Alt regarding short sell positions.
We are laying the groundwork for broad unit testing and nightly builds of all of our products so things should be more accessible to everyone by the end of the month.
-
I have an idea about margin call.
For example, I short 1000 usd with 2bts backing.
when the price is up to 1000 usd /1.5 bts, margin call excute.
forced execute a buy order: buy 1000 usd with price 1000usd/1.5bts.
this buy order can not be cancel.
and 5% fee of bts will assessed.
the one who hold bitusd have two choice: sell bitusd with 1000usd/1.5bts, or hold continue to sell for more high price.
From this we can avoid to create bitusd with no backing.
-
Dan/Invictus Team,
Can you provide a short summary of how the 3 million per month quoted for funding will be spent to develop Bitshares X?
-
In Bitshares X, Bitusd is designed to anchoring USD. While BTS already exists in the system, the first Bitusd will appear if and only if someone likes to buy it with 1 USD in currency exchange interface. So, the number of Bitusd is finite ( from small to large as time goes and cash inflows increases). No one would like to use his Bitusd (equivalent to real money) to buy 1 BTS with ceiling price such as alt listed, 10**10Bitusd,otherwise he would lost all. In conclusion, There will not be hundreds of millions of unsecured Bitusd.
[/quote]
The individual who found the issue should receive the 23 pts and an interpreter should get 2 pts... let me know who should get what.
[/quote]
-
2 issues seems are identified in margin call algorithm, please find the detail in highlighted below, not sure if i misunderstood the logic,please correct me if so.
issue 1:
if( payoff > bid_usd )
{ // consume the full bid, leaving a balance on the call
loan_amount += bid_usd;
collateral_amount += bid_usd * call_price;// line 474 of blockchain_db.cpp,why not double collateral in this short position?half from long bid, half from cover, should be bid_usd * call_price+bid_usd * call_price?
working_call.amount -= bid_usd * call_price;
cover_claim.payoff -= bid_usd;
// add bid as input, and give the bidder their new cover position
market_trx.inputs.push_back( bid_itr->location );
market_trx.outputs.push_back(
trx_output( claim_by_cover_output(loan_amount, bid_payout_address), collateral_amount) );
collateral_amount = asset();
loan_amount = asset( 0.0, quote );
// goto next bid
++bid_itr;
if( bid_itr != bids.rend() ) working_bid = get_output( bid_itr->location );
}
issue 2:
else // payoff == bidusd
{ // consume full call and bid..
auto cover_amount = bid_usd * call_price;
loan_amount += bid_usd;
collateral_amount += cover_amount + cover_amount; // collat from bid+cover
working_call.amount -= cover_amount;
market_trx.outputs.push_back(
trx_output( claim_by_cover_output( loan_amount, bid_payout_address ), collateral_amount) );
//line 521 of blockchain_db.cpp ,why needn't reset the variables collateral_amount and loan_amount after pushing short position output,won't it cause the incorrect output in next round matching, is following code required?
collateral_amount = asset();
loan_amount = asset( 0.0, quote );
if( working_call.amount.get_rounded_amount() > 0 )
{
// TODO.. charge a 5% fee
market_trx.outputs.push_back(
trx_output( claim_by_signature_output( cover_claim.owner ), working_call.amount ) );
}
market_trx.inputs.push_back( call_itr->location );
market_trx.inputs.push_back( bid_itr->location );
++bid_itr;
if( bid_itr != bids.rend() ) working_bid = get_output( bid_itr->location );
++call_itr;
if( call_itr != margin_positions.end() )
{
working_call = get_output( call_itr->location );
cover_claim = working_call.as<claim_by_cover_output>();
}
}
-
:o
On knowing the sell about 1_bts for 10000000 USD, I am shocked.
And I think there must be something wrong.
I read the white paper, but just understand a little.
Here share the logic in my head. It maybe totally wrong. :-[
------------------------
If no rule, the bitUSD is not USD, it is just a name.
It can be anything: cheap as DOGE, or expensive as 42Coin.
So there must be the rule:
You can create your BTA named bitAAA or bitXYZ, named anything.
But when you create BTA named bitUSD, it must equal to the real time USD value.
When you create BTA named bitBTC, it must equal to the real time BTC value.
So the BitShareX system already has the BTS with real time value.
If you want play in BitShareX, you must put in real USD or real BTS or real BTC.
How to put USD in/out BitShareX system ?
one method is using the public market(e.g. Bter);
Or using BTS_prepaid_code(e.g. BTER-code or BTCC-code or telephone recharge coupon) can buy with USD from the on-line/off-line shops
Then the game is starting: suppose USD==1 BTC==1000 BTS==100
UserA want buy 2 BTC
UserB want sell 2 BTC
UserC want keep 20 BTS
UserA checkin 2000_USD get 20_BTS; BitShareX increase 2000_bitUSD;
UserA use 20_BTS to buy 2_bitBTC.
UserA checkout 2_bitBTC get 2_BTC.
UserB checkin 2_BTC get 20_BTS, BitShareX increase 2_bitBTC;
UserB use 20_BTS to buy 2000_bitUSD.
UserB checkout 2000_bitUSD get 2000_USD.
UserC checkin 2000_USD get 20_BTS; BitShareX increase 2000_bitUSD;
1 year later, BTS==10,000;
UserB use 20_BTS to buy 200,000_bitUSD.
UserB checkout 200,000_bitUSD get 200,000_USD :)
:)
------------------------
-
I prefer another way for this position:
the order claim by long will not include by match progress ,
until it goes to next two block.(10 minutes or more)
Imagine this:
there is no one buy order in market at this moment.
If someone short 1 bts with 1billion usd(much lower then bitusd price...)
the buyer will see it, they have 10 minutes to decide what to do.
I think the marketing will give the short order a correct price.
this is not enough.
It can't work at the beginning, just 2 order:
buy 10000000 usd with 1bts
short 10000000 usd with 1bts
so we should add two limit:
1. matching_order for claim_long only work when buy order is enough
2. can't short with price low than current price
-
I assume on Feb 28th the BTS X will not have a graphic user interface, right? Although a friendly UI will absolutely stir the market more.
-
I assume on Feb 28th the BTS X will not have a graphic user interface, right? Although a friendly UI will absolutely stir the market more.
gui is secondary to widespread adoption. I think the idea is web based exchanges (for those that don't/can't/won't mess with their own wallets) and possible several different guis (some by I3 some by others). IF the backend is versatile and powerful enough, releasing a gui won't matter since someone will probably develop a better platform.
-
Today was spent handling other tasks and tomorrow we are having a company wide meeting focused on learning and putting into practice the concepts of David Allen, http://www.swissviet.com/Getting_Things_Done.pdf which comes highly recommended by Brian Page. Having seen how Brian gets things done I am very excited to learn his techniques.
Our workload is so high and the number of things going on in parallel is beyond anything I have dealt with in my life to date, so I am looking forward to streamlining my productivity and focus along with the rest of our management team.
-
ETA on testnet with p2p and TAPOS?
Monday. It is currently working in my local tests, but I want to do a few more tests before launching it for more people.
drumroll...
-
About the division.
Division come from the transactions fee which are destroyed.
For example:
I have 100 xts, the destroyed fee is 10000 xts, so my wallet will display 100 * 400/399 to me.
to be clear, I call the unit yts, I have 400 * 400/399 yts.
so all my operation should based on yts. I buy 1 yts, sell 1 yts, transfer 1 yts .....
Here is the question:
At the beginning(total 400 milion xts), I give an order: buy 1000 usd with my 1 yts. It's not matched. my balancce is:
99 yts can be use
1 yts claimed by sell for 1000 usd
Now the total xts is 399 million. my balance should be
100*400/399 - 1 yts can be use
1 yts claimed by sell for 1000 usd
So all the unit used in order_match() should based yts. include margin_call()
maybe all the asset in the code based unit xts should changed to yts
BTS网络可以赚取交易费盈利，从而给所有持有 xts 者分红。
所有被直接销毁的交易费就是BTS网络赚取的利润，因为xts总量减少，所以每个xts相对升值了。
客户端钱包显示的用户xts余额，实际上是 xts 数量*400万/(400万-总的销毁交易费)。为便于描述，我把单位定义为 yts吧。
下面问题就来了
比如我最开始挂了个单子，卖 1yts，换 1000 usd。这个单子一致没成交。现在 xts 分红了，总量只有399万了。
我这个卖单是继续 1yts 换 1000 usd，还是变成 400/399 yts 换100usd？
现在的代码中会按 400/399 yts 卖出去。就是把本该属于我的分红，通过降价转移到了买家那里。
经过和网友们讨论，yidaidaxie给出了一个方案，在成交算法中要考虑到分红。多出的 yts应退还给我。
除了成交算法，强制平仓里面也应该考虑这个因素，不要忽略分红导致的 xts 增值。
-
When do i need to make sure i have all my PTS in my wallet in order to receive BTS when it comes out? Is March 1st a good deadline?
-
Today was spent handling other tasks and tomorrow we are having a company wide meeting focused on learning and putting into practice the concepts of David Allen, http://www.swissviet.com/Getting_Things_Done.pdf which comes highly recommended by Brian Page. Having seen how Brian gets things done I am very excited to learn his techniques.
Our workload is so high and the number of things going on in parallel is beyond anything I have dealt with in my life to date, so I am looking forward to streamlining my productivity and focus along with the rest of our management team.
Take cognitive enhancing focus drugs like Adderall. :) It works wonders for people with ADHD and it works on normal people too.
-
When do i need to make sure i have all my PTS in my wallet in order to receive BTS when it comes out? Is March 1st a good deadline?
I think the snapshot is February 28, therefore you should have all your PTS in your wallet before that day.
-
Today we had an excellent training session on how to increase our productivity. It will be paying dividends in the weeks ahead.
I also solved a major issue in the design of BitShares X as it relates to how we handle the case where the collateral is insufficient to back the short position and thus the result is unbacked BitUSD in circulation. Considering the value of BitShares X is directly related to the degree to which the holders of BitShares X are willing to guarantee the purchasing power of BitUSD it seems that a decentralized Bank should take the same approach as their centralized counterparts... Sell new shares in the bank to raise capital to cover the losses. In effect all BTS holders would provide 'insurance' against the 50% discontinuity event that would blow out a short position. The reason why BTS longs would insure the BTS shorts is because they entire value proposition of BitShares X is derived from the promise of BitUSD remaining pegged. If the BTS holders can increase the value of BTS by providing this insurance against a very rare event, it should in turn increase confidence and thus increase the value of BTS.
This change would shift the losses that BitUSD holders would currently pay to the BTS holders and thus collectively BTS holders are backing all BitUSD and BitUSD holders have something with much lower risks.
-
Today we had an excellent training session on how to increase our productivity. It will be paying dividends in the weeks ahead.
I also solved a major issue in the design of BitShares X as it relates to how we handle the case where the collateral is insufficient to back the short position and thus the result is unbacked BitUSD in circulation. Considering the value of BitShares X is directly related to the degree to which the holders of BitShares X are willing to guarantee the purchasing power of BitUSD it seems that a decentralized Bank should take the same approach as their centralized counterparts... Sell new shares in the bank to raise capital to cover the losses. In effect all BTS holders would provide 'insurance' against the 50% discontinuity event that would blow out a short position. The reason why BTS longs would insure the BTS shorts is because they entire value proposition of BitShares X is derived from the promise of BitUSD remaining pegged. If the BTS holders can increase the value of BTS by providing this insurance against a very rare event, it should in turn increase confidence and thus increase the value of BTS.
This change would shift the losses that BitUSD holders would currently pay to the BTS holders and thus collectively BTS holders are backing all BitUSD and BitUSD holders have something with much lower risks.
Do you mean buying back the surplus BitUSD with newly minted BTS? You'd get my vote on that - even though it might theoretically tear down the 4M BTS limit. Maybe increase transaction fees in the unlikely event that there are more than 4M BTS around?
edit: discussion continues here: https://bitsharestalk.org/index.php?topic=3015.msg37866#msg37866
-
When do i need to make sure i have all my PTS in my wallet in order to receive BTS when it comes out? Is March 1st a good deadline?
That would be exactly 1 day too late. :)
-
ETA on testnet with p2p and TAPOS?
Monday. It is currently working in my local tests, but I want to do a few more tests before launching it for more people.
Are you implementing the share printing now? How soon can you launch another testnet?
-
ETA on testnet with p2p and TAPOS?
Monday. It is currently working in my local tests, but I want to do a few more tests before launching it for more people.
Are you implementing the share printing now? How soon can you launch another testnet?
I am not implementing the share printing right now. I need to implement scanning blockchain for BTC and PTS outputs and then can launch with a genesis block from a real PTS snapshot.
-
Today we had an excellent training session on how to increase our productivity. It will be paying dividends in the weeks ahead.
I also solved a major issue in the design of BitShares X as it relates to how we handle the case where the collateral is insufficient to back the short position and thus the result is unbacked BitUSD in circulation. Considering the value of BitShares X is directly related to the degree to which the holders of BitShares X are willing to guarantee the purchasing power of BitUSD it seems that a decentralized Bank should take the same approach as their centralized counterparts... Sell new shares in the bank to raise capital to cover the losses. In effect all BTS holders would provide 'insurance' against the 50% discontinuity event that would blow out a short position. The reason why BTS longs would insure the BTS shorts is because they entire value proposition of BitShares X is derived from the promise of BitUSD remaining pegged. If the BTS holders can increase the value of BTS by providing this insurance against a very rare event, it should in turn increase confidence and thus increase the value of BTS.
This change would shift the losses that BitUSD holders would currently pay to the BTS holders and thus collectively BTS holders are backing all BitUSD and BitUSD holders have something with much lower risks.
I would love to have that same training session you had.. heard the guy is really good.
-
When do i need to make sure i have all my PTS in my wallet in order to receive BTS when it comes out? Is March 1st a good deadline?
That would be exactly 1 day too late. :)
That would be a catastrophe. You should send out a notice via mail titled "urgent" or something like that, and likewise update the invictus.io site with an "alert" on the frontpage. There are a million people clicking protoshares on coinmarketcap.com now watching the frontpage of invictus.io wondering why the price is rising. This is perhaps your main source of publicity right now.
coinmarketcap.com is rank 2000 in the USA. That's better than coindesk.com
-
That would be a catastrophe. You should send out a notice via mail titled "urgent" or something like that, and likewise update the invictus.io site with an "alert" on the frontpage. There are a million people clicking protoshares on coinmarketcap.com now watching the frontpage of invictus.io wondering why the price is rising. This is perhaps your main source of publicity right now.
coinmarketcap.com is rank 2000 in the USA. That's better than coindesk.com
+5% +5% +5% +5% +5%
-
When do i need to make sure i have all my PTS in my wallet in order to receive BTS when it comes out? Is March 1st a good deadline?
That would be exactly 1 day too late. :)
That would be a catastrophe. You should send out a notice via mail titled "urgent" or something like that, and likewise update the invictus.io site with an "alert" on the frontpage. There are a million people clicking protoshares on coinmarketcap.com now watching the frontpage of invictus.io wondering why the price is rising. This is perhaps your main source of publicity right now.
coinmarketcap.com is rank 2000 in the USA. That's better than coindesk.com
That's how I found out about this whole thing too. When Protoshares appeared on coinmarketcap the first time I thought: "What's that? Something new and right into the top 10? I'd better check it out."
-
Wait until BitUSD is listed on coinmarketcap...
-
Today I made some major progress in the code:
1) I now track price history and enable users to query via API the information necessary to build a candle stick chart.
2) I integrated the import_bitcoin_wallet api to load wallets from Bitcoin Qt
3) I integrated the scanning of the blockchain for outputs claimable with a PTS or BTC address.
Tomorrow I will be testing these features and will prepare to launch the next round of tests complete with instructions on importing your bitcoin-qt and protoshares-qt wallet and a genesis block recently generated. I do want to investigate the attack presented by alt prior to launching this test (as tests are time consuming to launch).
-
Like stock trading system, one day before the opening time to engage in an auction.
Today I made some major progress in the code:
1) I now track price history and enable users to query via API the information necessary to build a candle stick chart.
2) I integrated the import_bitcoin_wallet api to load wallets from Bitcoin Qt
3) I integrated the scanning of the blockchain for outputs claimable with a PTS or BTC address.
Tomorrow I will be testing these features and will prepare to launch the next round of tests complete with instructions on importing your bitcoin-qt and protoshares-qt wallet and a genesis block recently generated. I do want to investigate the attack presented by alt prior to launching this test (as tests are time consuming to launch).
-
Today I fixed many bugs associated with importing bitcoin wallets and added additional RPC calls to import wallets and get price history.
I also filmed my first video blog which will be edited and released soon addressing our future DACs and the upcoming snapshot.
-
Wait until BitUSD is listed on coinmarketcap...
Think it'll make it to the top 10?
-
Actualy bts_server consumes all available memory on my linux machine. So far ~ 8GB and increasing. Is this normal or memory leak?
-
Looks like a leak
Sent from my iPhone using Tapatalk (http://tapatalk.com/m?id=1)
-
Actualy bts_server consumes all available memory on my linux machine. So far ~ 8GB and increasing. Is this normal or memory leak?
not sure, i think it may due to this:
https://github.com/InvictusInnovations/BitShares/issues/52 (https://github.com/InvictusInnovations/BitShares/issues/52)
-
I have spent the past few days thinking about exploits and designing solutions to them. This has required some changes to the code that I am working on to do the following:
1) Increase initial margin to 10x rather than 2x to prevent manipulation by triggering short squeezes. This will reduce leverage in the system and make it very unlikely for a short position to be blown out by a short squeeze.
2) Track market depth and limit trading to a percent of the market depth every block. This will prevent whales from pushing the price around too much.
3) Require minimal market depth before the first trade can occur.
4) Figure out how to test all of this :)
-
I have spent the past few days thinking about exploits and designing solutions to them. This has required some changes to the code that I am working on to do the following:
1) Increase initial margin to 10x rather than 2x to prevent manipulation by triggering short squeezes. This will reduce leverage in the system and make it very unlikely for a short position to be blown out by a short squeeze.
2) Track market depth and limit trading to a percent of the market depth every block. This will prevent whales from pushing the price around too much.
3) Require minimal market depth before the first trade can occur.
4) Figure out how to test all of this :)
I agree you but not 1)
I think 10x is not necessary, 2x is fine.
the key point is give a sell order for bit asset instead of buy directory from market.
-
I have spent the past few days thinking about exploits and designing solutions to them. This has required some changes to the code that I am working on to do the following:
1) Increase initial margin to 10x rather than 2x to prevent manipulation by triggering short squeezes. This will reduce leverage in the system and make it very unlikely for a short position to be blown out by a short squeeze.
2) Track market depth and limit trading to a percent of the market depth every block. This will prevent whales from pushing the price around too much.
3) Require minimal market depth before the first trade can occur.
4) Figure out how to test all of this :)
are these changes that can be tweaked as bitshares evolves, like bitcoin fees are tweaked, or are they more or less permanent to the XT chain?
-
are these changes that can be tweaked as bitshares evolves, like bitcoin fees are tweaked, or are they more or less permanent to the XT chain?
How to make changes, and what changes to allow, THAT is the critically important question. Any DAC that can more intelligently make drastic rapid changes like this will always blow away all dumb hard to change competitors.
The Bitcoin foundation has quite a laborious, slow and involved process to propose, vet, and get these kinds of changes accepted into the network. And even with all that, there is a chance that some miners will not accept any particular updates/changes, possibly resulting in a forked block chain. Obviously, such would be devastating to any community using the coin.
That is why having the ability to build and measure how much consensus you have is so critically important. Getting a network of machines to achieve a consensus on what blocks to accept is one thing, getting all the people rapidly on board and educated (i.e. amplifying the wisdom of the crowd) for dramatic intelligent changes to how the network consensus is achieved, is an entirely different and far more important issue.
Any smart DAC, that can rapidly measure and build consensus amongst the crowd of coin holders and miners, way more effectively and intelligent than the Bitcoin Foundation will always blow away any DAC that is fixed, or very difficult to change/improve, like Bitcoin.
The consensus building system at Canonizer.com is all about exactly that. Amplifying and educating the wisdom of the crowd, building and rigorously measuring for the amount of consensus there or isn't, what is required to get to the level of consensus required, as rapidly as possible, all in a leaderless way bottom up way, and so on. Our goal is to make Canon Coin just such a 'smart' currency, able to change and adapt far more rapidly than any other currency, in a leaderless amplification of the wisdom of the crowd way.
-
The best consensus building mechanism is to just release multiple chains and let people buy what they want
-
I have spent the past few days thinking about exploits and designing solutions to them. This has required some changes to the code that I am working on to do the following:
1) Increase initial margin to 10x rather than 2x to prevent manipulation by triggering short squeezes. This will reduce leverage in the system and make it very unlikely for a short position to be blown out by a short squeeze.
2) Track market depth and limit trading to a percent of the market depth every block. This will prevent whales from pushing the price around too much.
3) Require minimal market depth before the first trade can occur.
4) Figure out how to test all of this :)
are these changes that can be tweaked as bitshares evolves, like bitcoin fees are tweaked, or are they more or less permanent to the XT chain?
These are hard to tweak because they require all nodes to agree / validate the transactions. Voting is not an option and some of these parameters would have very thin prediction markets (subject to manipulation) if we attempted to set them that way.
I suppose there is a way for a trusted party to send a transaction to change a parameter within a preset range. This party would dramatically effect the value of the DAC with every change. Finding a good solution to 'changing the rules after launch' is very hard... doing a snapshot and fork may be the best way to propose changes that gives everyone an opportunity to voluntarily switch to the new chain.
-
I have spent the past few days thinking about exploits and designing solutions to them. This has required some changes to the code that I am working on to do the following:
1) Increase initial margin to 10x rather than 2x to prevent manipulation by triggering short squeezes. This will reduce leverage in the system and make it very unlikely for a short position to be blown out by a short squeeze.
2) Track market depth and limit trading to a percent of the market depth every block. This will prevent whales from pushing the price around too much.
3) Require minimal market depth before the first trade can occur.
4) Figure out how to test all of this :)
are these changes that can be tweaked as bitshares evolves, like bitcoin fees are tweaked, or are they more or less permanent to the XT chain?
... Voting is not an option ...
How about a Proof of Stake based voting mechanism for major changes to blockchain rules?
-
Otherwise known as... proof of stake!
-
How about a prediction market for margin,
I have spent the past few days thinking about exploits and designing solutions to them. This has required some changes to the code that I am working on to do the following:
1) Increase initial margin to 10x rather than 2x to prevent manipulation by triggering short squeezes. This will reduce leverage in the system and make it very unlikely for a short position to be blown out by a short squeeze.
2) Track market depth and limit trading to a percent of the market depth every block. This will prevent whales from pushing the price around too much.
3) Require minimal market depth before the first trade can occur.
4) Figure out how to test all of this :)
are these changes that can be tweaked as bitshares evolves, like bitcoin fees are tweaked, or are they more or less permanent to the XT chain?
These are hard to tweak because they require all nodes to agree / validate the transactions. Voting is not an option and some of these parameters would have very thin prediction markets (subject to manipulation) if we attempted to set them that way.
I suppose there is a way for a trusted party to send a transaction to change a parameter within a preset range. This party would dramatically effect the value of the DAC with every change. Finding a good solution to 'changing the rules after launch' is very hard... doing a snapshot and fork may be the best way to propose changes that gives everyone an opportunity to voluntarily switch to the new chain.
What if you were to set these variables (margin, trading limit and minimum market depth) as you have announced but use prediction markets for each of these variable that would determine that variable's value. The consensus from each prediction market would not override the original values until each market met all of the original requirements before trade. In this way the DAC becomes even more autonomous. I don't know how hard this is to code, but I feel that it is necessary in the evolution of DAC's.
-
How about a prediction market for margin, I have spent the past few days thinking about exploits and designing solutions to them. This has required some changes to the code that I am working on to do the following:
1) Increase initial margin to 10x rather than 2x to prevent manipulation by triggering short squeezes. This will reduce leverage in the system and make it very unlikely for a short position to be blown out by a short squeeze.
2) Track market depth and limit trading to a percent of the market depth every block. This will prevent whales from pushing the price around too much.
3) Require minimal market depth before the first trade can occur.
4) Figure out how to test all of this :)
are these changes that can be tweaked as bitshares evolves, like bitcoin fees are tweaked, or are they more or less permanent to the XT chain?
These are hard to tweak because they require all nodes to agree / validate the transactions. Voting is not an option and some of these parameters would have very thin prediction markets (subject to manipulation) if we attempted to set them that way.
I suppose there is a way for a trusted party to send a transaction to change a parameter within a preset range. This party would dramatically effect the value of the DAC with every change. Finding a good solution to 'changing the rules after launch' is very hard... doing a snapshot and fork may be the best way to propose changes that gives everyone an opportunity to voluntarily switch to the new chain.
What if you were to set these variables (margin, trading limit and minimum market depth) as you have announced but use prediction markets for each of these variable that would determine that variable's value. The consensus from each prediction market would not override the original values until each market met all of the original requirements before trade. In this way the DAC becomes even more autonomous. I don't know how hard this is to code, but I feel that it is necessary in the evolution of DAC's.
discuss it:
https://bitsharestalk.org/index.php?topic=3104.0
-
I have spent the past few days thinking about exploits and designing solutions to them. This has required some changes to the code that I am working on to do the following:
1) Increase initial margin to 10x rather than 2x to prevent manipulation by triggering short squeezes. This will reduce leverage in the system and make it very unlikely for a short position to be blown out by a short squeeze.
2) Track market depth and limit trading to a percent of the market depth every block. This will prevent whales from pushing the price around too much.
3) Require minimal market depth before the first trade can occur.
4) Figure out how to test all of this :)
are these changes that can be tweaked as bitshares evolves, like bitcoin fees are tweaked, or are they more or less permanent to the XT chain?
These are hard to tweak because they require all nodes to agree / validate the transactions. Voting is not an option and some of these parameters would have very thin prediction markets (subject to manipulation) if we attempted to set them that way.
I suppose there is a way for a trusted party to send a transaction to change a parameter within a preset range. This party would dramatically effect the value of the DAC with every change. Finding a good solution to 'changing the rules after launch' is very hard... doing a snapshot and fork may be the best way to propose changes that gives everyone an opportunity to voluntarily switch to the new chain.
Every node has different threshold. Most miners (nodes) agree, then you are agreed. Just like floating transaction fees in the new bitcoin protocol.
-
Maybe we can according to market depth change mortgage rate from 10x to 2x,even from 1x to 0.1x.
-
even from 1x to 0.1x.
=O
-
As depicted in the whitepaper, BitUSD will be destroyed over time due to fees. That means there exists excess XTS backing BitUSD. The theory states that if the backing XTS is more than the original amount, BitUSD will trade with a premium over USD, effectively paying dividend to the BitUSD holder. This also serves as the motivation to hold BitUSD.
Here is the concern. We need a channel to connect the excess XTS to the existing BitUSD, in order for the market to perceive that a BitUSD indeed is more valuable than a USD. In other words, the excess XTS will somehow need to be cashed out. Otherwise, if it stays within the system for ever, then it only provide more security for holding BitUSD against short squeeze. Other than that, it is no more than a notion, and as a results BitUSD price stays with USD, which voids the motivation for holding BitUSD.
-
As depicted in the whitepaper, BitUSD will be destroyed over time due to fees. That means there exists excess XTS backing BitUSD. The theory states that if the backing XTS is more than the original amount, BitUSD will trade with a premium over USD, effectively paying dividend to the BitUSD holder. This also serves as the motivation to hold BitUSD.
Here is the concern. We need a channel to connect the excess XTS to the existing BitUSD, in order for the market to perceive that a BitUSD indeed is more valuable than a USD. In other words, the excess XTS will somehow need to be cashed out. Otherwise, if it stays within the system for ever, then it only provide more security for holding BitUSD against short squeeze. Other than that, it is no more than a notion, and as a results BitUSD price stays with USD, which voids the motivation for holding BitUSD.
Something could be done here, but I am not sure what.
-
As depicted in the whitepaper, BitUSD will be destroyed over time due to fees. That means there exists excess XTS backing BitUSD. The theory states that if the backing XTS is more than the original amount, BitUSD will trade with a premium over USD, effectively paying dividend to the BitUSD holder. This also serves as the motivation to hold BitUSD.
Here is the concern. We need a channel to connect the excess XTS to the existing BitUSD, in order for the market to perceive that a BitUSD indeed is more valuable than a USD. In other words, the excess XTS will somehow need to be cashed out. Otherwise, if it stays within the system for ever, then it only provide more security for holding BitUSD against short squeeze. Other than that, it is no more than a notion, and as a results BitUSD price stays with USD, which voids the motivation for holding BitUSD.
Something could be done here, but I am not sure what.
Is that still true that transaction fees can be payed in BitAssets which then will be destroyed?
I thought, that if an account wants to perform a transaction and does not have enough BTSX to pay for the fee, then an amount of BitAsset will be automatically sold on the market to obtain those BTSX for the fee?
If really BitAssets are destroyed, won't this cause an undesirable overhang of short positions long term?
-
As depicted in the whitepaper, BitUSD will be destroyed over time due to fees. That means there exists excess XTS backing BitUSD. The theory states that if the backing XTS is more than the original amount, BitUSD will trade with a premium over USD, effectively paying dividend to the BitUSD holder. This also serves as the motivation to hold BitUSD.
Here is the concern. We need a channel to connect the excess XTS to the existing BitUSD, in order for the market to perceive that a BitUSD indeed is more valuable than a USD. In other words, the excess XTS will somehow need to be cashed out. Otherwise, if it stays within the system for ever, then it only provide more security for holding BitUSD against short squeeze. Other than that, it is no more than a notion, and as a results BitUSD price stays with USD, which voids the motivation for holding BitUSD.
Something could be done here, but I am not sure what.
Is that still true that transaction fees can be payed in BitAssets which then will be destroyed?
I thought, that if an account wants to perform a transaction and does not have enough BTSX to pay for the fee, then an amount of BitAsset will be automatically sold on the market to obtain those BTSX for the fee?
If really BitAssets are destroyed, won't this cause an undesirable overhang of short positions long term?
I think we need to clear up some terminology here and make a distinction between 'transaction fees' and 'market fees'.
A Transaction Fee is assessed based upon the size of your transaction and is always paid in BTS.
A Market Fee is assessed to anyone who bids higher than the highest bid or lower than the lowest ask. These fees are assessed in their native unit.
BitUSD that is destroyed is no different than someone choosing to hold BitUSD forever at any price. It means that not all short positions can fully unwind and serves to give real backing to BitUSD as shorts must compete for the BitUSD that is actually on the market. In the event that the market wants to completely unwind all short positions, then the holders of BitUSD will profit nicely.
How the market responds to this characteristic would be no different than someone who loses their private key to their BitUSD. It will not matter. It is also a kind of insurance against blowout of margin of short positions by preemtively taking some BitUSD out of circulation, having extreme events do the opposite may balance out.
Either way this is all an experiment and we shall see what happens.
-
Ah, now I get the difference.
So there are overlapping bids and asks (market fees) and lost keys destroying long positions and margin blowouts destroying short positions. And the hope is they will cancel each other out.
In the event that the market wants to completely unwind all short positions, then the holders of BitUSD will profit nicely.
BTW, I don't think this should be called nice. This is the perfect breeding ground for a huge short squeeze. And short squeezes undermine trust, no matter if some people might profit or not.
-
A Transaction Fee is assessed based upon the size of your transaction and is always paid in BTS.
Someone has bitUSD only can't make a transaction?
-
A Transaction Fee is assessed based upon the size of your transaction and is always paid in BTS.
Someone has bitUSD only can't make a transaction?
I guess they must have some XTS to perform transactions.
Sent from my iPad using Tapatalk (http://tapatalk.com/m?id=1)
-
A Transaction Fee is assessed based upon the size of your transaction and is always paid in BTS.
Someone has bitUSD only can't make a transaction?
At the moment, yes. Having a way to charge fees in BitUSD may be an option by having the fees go toward buying BTS to destroy.
-
As depicted in the whitepaper, BitUSD will be destroyed over time due to fees. That means there exists excess XTS backing BitUSD. The theory states that if the backing XTS is more than the original amount, BitUSD will trade with a premium over USD, effectively paying dividend to the BitUSD holder. This also serves as the motivation to hold BitUSD.
Here is the concern. We need a channel to connect the excess XTS to the existing BitUSD, in order for the market to perceive that a BitUSD indeed is more valuable than a USD. In other words, the excess XTS will somehow need to be cashed out. Otherwise, if it stays within the system for ever, then it only provide more security for holding BitUSD against short squeeze. Other than that, it is no more than a notion, and as a results BitUSD price stays with USD, which voids the motivation for holding BitUSD.
Something could be done here, but I am not sure what.
Is that still true that transaction fees can be payed in BitAssets which then will be destroyed?
I thought, that if an account wants to perform a transaction and does not have enough BTSX to pay for the fee, then an amount of BitAsset will be automatically sold on the market to obtain those BTSX for the fee?
If really BitAssets are destroyed, won't this cause an undesirable overhang of short positions long term?
I think we need to clear up some terminology here and make a distinction between 'transaction fees' and 'market fees'.
A Transaction Fee is assessed based upon the size of your transaction and is always paid in BTS.
A Market Fee is assessed to anyone who bids higher than the highest bid or lower than the lowest ask. These fees are assessed in their native unit.
BitUSD that is destroyed is no different than someone choosing to hold BitUSD forever at any price. It means that not all short positions can fully unwind and serves to give real backing to BitUSD as shorts must compete for the BitUSD that is actually on the market. In the event that the market wants to completely unwind all short positions, then the holders of BitUSD will profit nicely.
How the market responds to this characteristic would be no different than someone who loses their private key to their BitUSD. It will not matter. It is also a kind of insurance against blowout of margin of short positions by preemtively taking some BitUSD out of circulation, having extreme events do the opposite may balance out.
Either way this is all an experiment and we shall see what happens.
Ok, I now get why BitUSD price would be higher even without a channel. Then I am concerned that the liabilities on the short side can never be paid off completely, no matter what price, as there does not exist enough long position.
Sent from my iPad using Tapatalk (http://tapatalk.com/m?id=1)
-
Well, so long as someone else is willing to take over the short positions....
I think the way I will solve all of these fee issues is to accumulate BitUSD and simply sell it into the market at the highest bid and take the BTS received and destroy that. Keep things simple and restore balance to the force.
(http://s2.quickmeme.com/img/17/1791bf6b03424e29b03ef6fa63b7397429c417ffff0e38fe914f7a4d5da7360a.jpg)
-
Well, so long as someone else is willing to take over the short positions....
I think the way I will solve all of these fee issues is to accumulate BitUSD and simply sell it into the market at the highest bid and take the BTS received and destroy that. Keep things simple and restore balance to the force.
(http://s2.quickmeme.com/img/17/1791bf6b03424e29b03ef6fa63b7397429c417ffff0e38fe914f7a4d5da7360a.jpg)
you mean from the fees? Or you will be the central bank? O.o
-
Well, so long as someone else is willing to take over the short positions....
I think the way I will solve all of these fee issues is to accumulate BitUSD and simply sell it into the market at the highest bid and take the BTS received and destroy that. Keep things simple and restore balance to the force.
(http://s2.quickmeme.com/img/17/1791bf6b03424e29b03ef6fa63b7397429c417ffff0e38fe914f7a4d5da7360a.jpg)
you mean from the fees? Or you will be the central bank? O.o
From the fees... I am just a poor software developer who wouldn't dream of starting a central bank...
-
Well, so long as someone else is willing to take over the short positions....
I think the way I will solve all of these fee issues is to accumulate BitUSD and simply sell it into the market at the highest bid and take the BTS received and destroy that. Keep things simple and restore balance to the force.
(http://s2.quickmeme.com/img/17/1791bf6b03424e29b03ef6fa63b7397429c417ffff0e38fe914f7a4d5da7360a.jpg)
You should do the same for margin call :D
simply sell backup xfs into the market and take the bit assets received and destroy short possition.
-
Well, so long as someone else is willing to take over the short positions....
I think the way I will solve all of these fee issues is to accumulate BitUSD and simply sell it into the market at the highest bid and take the BTS received and destroy that. Keep things simple and restore balance to the force.
(http://s2.quickmeme.com/img/17/1791bf6b03424e29b03ef6fa63b7397429c417ffff0e38fe914f7a4d5da7360a.jpg)
You should do the same for margin call :D
simply sell backup xfs into the market and take the bit assets received and destroy short possition.
That is what I already do.
-
That is what I already do.
I mean sell all the backup xfs with same price: (amounts of short position)/(amounts of backup xfs)
Then will not generate short position without backup xfs.
From these, the amount of bitusd always equal the amount of short postion.
-
I thought I would update everyone on our GUI development. We have been working with a bright developer named Nathan who has put together a large amount of a basic GUI for the BTS wallet. He still has some work to do, but his progress is still significant.
(http://the-iland.net/static/images/BTSX.png)
It isn't quite the interface I would have designed, but is certainly a step up from the command line and we will enhance it as time progresses.
-
With respect to the GUI... Nathan lacks some domain specific knowledge and so don't cringe too much at some UI elements, he will be able to fix them once he learns what the domain better.
-
I dig it 8)
And it'll only get better from here..
-
Good update +5%
-
I like how its nice and simple :)
Maybe a little bit a blue would be nice
-
I like how its nice and simple :)
+5% the layout reminds me of a clean BTC-E without the trollbox ;)
-
in the GUI USD stand for "BitUSD", right? then why not use word like "BTU" instead to avoid misleading user?
-
Well, so long as someone else is willing to take over the short positions....
I think the way I will solve all of these fee issues is to accumulate BitUSD and simply sell it into the market at the highest bid and take the BTS received and destroy that. Keep things simple and restore balance to the force.
(http://s2.quickmeme.com/img/17/1791bf6b03424e29b03ef6fa63b7397429c417ffff0e38fe914f7a4d5da7360a.jpg)
I would be much more comfortable with this approach.
-
in the GUI USD stand for "BitUSD", right? then why not use word like "BTU" instead to avoid misleading user?
Ripple also displays RippleUSD as USD.
The only problem is, the price of bitUSD floats around the price of 'real' USD.
But Ripple also does not suggest the risk behind RippleUSD vs 'real' USD.
So does btc38.com.
-
Well, so long as someone else is willing to take over the short positions....
I think the way I will solve all of these fee issues is to accumulate BitUSD and simply sell it into the market at the highest bid and take the BTS received and destroy that. Keep things simple and restore balance to the force.
(http://s2.quickmeme.com/img/17/1791bf6b03424e29b03ef6fa63b7397429c417ffff0e38fe914f7a4d5da7360a.jpg)
I tought we did not use force here. :) balance to the source maybe? ;D
-
Great start. I was dreading doing this all via command line.
-
I am *strongly* in favor of only displaying BitUSD as well as prominent warnings that BitUSD is not USD and cannot be used as legal tender like USD can.
-
I am *strongly* in favor of only displaying BitUSD as well as prominent warnings that BitUSD is not USD and cannot be used as legal tender like USD can.
I would have to agree except i think it is important to include cny as well given the community in china.
-
I am *strongly* in favor of only displaying BitUSD as well as prominent warnings that BitUSD is not USD and cannot be used as legal tender like USD can.
I agree, we live in a litigious overregulated society, I would assume all the customer facing content will be vetted by legal eagles (twice).
-
I am *strongly* in favor of only displaying BitUSD as well as prominent warnings that BitUSD is not USD and cannot be used as legal tender like USD can.
I would have to agree except i think it is important to include cny as well given the community in china.
Same for EUR and RUB.
-
I am *strongly* in favor of only displaying BitUSD as well as prominent warnings that BitUSD is not USD and cannot be used as legal tender like USD can.
I would have to agree except i think it is important to include cny as well given the community in china.
Same for EUR and RUB.
I like BitUSD as USD is still the global reserve currency. I would put Gold up before I put any other currency.
CNY would prob be next. EUR & RUB less important. I like Russia but aren't they the country that's been the most hostile to crypto so far?
Oh and cool wallet, good start!
-
Hi,Bytemaster, where can I find the source code of Bitshare X? Pls give me the link, thanks.
-
I am *strongly* in favor of only displaying BitUSD as well as prominent warnings that BitUSD is not USD and cannot be used as legal tender like USD can.
I would have to agree except i think it is important to include cny as well given the community in china.
Same for EUR and RUB.
I like BitUSD as USD is still the global reserve currency. I would put Gold up before I put any other currency.
CNY would prob be next. EUR & RUB less important. I like Russia but aren't they the country that's been the most hostile to crypto so far?
Oh and cool wallet, good start!
Personally, I don't know why gold is relevant. I have never looked to the price of gold to value anything, especially not crypto currencies. The markets will work best when participants are most informed and the underlying asset isn't prone to its own instability. I obviously think that gold should be incorporated later, but as for the test chain the underlying assets should be those that ppl are most comfortable valuing. The ttest chain should also have as few assets as possible. One would suffice but it is very important to include the Chinese community
-
Personally, I don't know why gold is relevant. I have never looked to the price of gold to value anything,
That statement explains everything that is wrong with the fiat generation.
-
I am *strongly* in favor of only displaying BitUSD as well as prominent warnings that BitUSD is not USD and cannot be used as legal tender like USD can.
I would have to agree except i think it is important to include cny as well given the community in china.
Same for EUR and RUB.
I like BitUSD as USD is still the global reserve currency. I would put Gold up before I put any other currency.
CNY would prob be next. EUR & RUB less important. I like Russia but aren't they the country that's been the most hostile to crypto so far?
Oh and cool wallet, good start!
IMHO BitShares X more about assets, if we want to make them popular in China we should have BitCNY, in Russia we should have BitRUB, because in Russian, same as in China peoples don't use USD, and prefere to trade with local currencies.
Russia made same restrictions for Bitcoin as a China and from this point of view governments of China and Russia is equal but it's doesn't mean that Russia and China doesn't have crypto communities anymore.
-
Personally, I don't know why gold is relevant. I have never looked to the price of gold to value anything,
That statement explains everything that is wrong with the fiat generation.
Hahah not really... Gold is as valueless as fiat
-
Personally, I don't know why gold is relevant. I have never looked to the price of gold to value anything,
That statement explains everything that is wrong with the fiat generation.
Hahah not really... Gold is as valueless as fiat
+5% Today you can trade only "Paper Gold" which is more or less same as BitGold
:)
-
Personally, I don't know why gold is relevant. I have never looked to the price of gold to value anything,
That statement explains everything that is wrong with the fiat generation.
Hahah not really... Gold is as valueless as fiat
At any point in the last thousand years, owning a ton gold would make you a wealthy man.
At any point in the last thousand years keeping the equivalent value in fiat would leave you flat broke in less than 50 years without exception.
-
Personally, I don't know why gold is relevant. I have never looked to the price of gold to value anything,
That statement explains everything that is wrong with the fiat generation.
Hahah not really... Gold is as valueless as fiat
+5% Today you can trade only "Paper Gold" which is more or less same as BitGold
:)
No, BitGold is backed by Bitshares, so it's more valuable than paper gold.
The paper gold system obviously allows them to distort the value of gold until there is a run on physical, which is why I love crypto, as each 'bit' is accounted for in a decentralised public ledger so it's harder to pull of that scam.
-
Where does BitBTC stand in importance for inclusion as a bit asset compared to these currencies and gold?
-
Where does BitBTC stand in importance for inclusion as a bit asset compared to these currencies and gold?
It is going to be included because it will facilitate BTC to BTS X trades.
-
Where does BitBTC stand in importance for inclusion as a bit asset compared to these currencies and gold?
It is going to be included because it will facilitate BTC to BTS X trades.
Great, that is what I was hoping to hear.
-
So since it's the 28th... Can we get the BTS X wallet for the test chain? Link? thanks.
-
So since it's the 28th... Can we get the BTS X wallet for the test chain? Link? thanks.
I just checked in some bug fixes and validated that I could do the following:
1) Initialize with a genesis block with data from one of the snapshot services
2) Load my bitcoin wallet to receive AGS and PTS
3) Transfer said balance from AGS and PTS... (believe it or not this was tricky to nail down)
I have a laundry list of items that need to be addressed. There have been a number of requests discussed in this thread and in the attack thread that are causing some delays. Things I need to handle are:
1) Enforce minimal market depth.
2) Increase default collateral requirement to 10x.
3) Fix a bug where wallet loading errors erase wallet contents.
4) Cover a position without requiring additional capital.
-
So since it's the 28th... Can we get the BTS X wallet for the test chain? Link? thanks.
I just checked in some bug fixes and validated that I could do the following:
1) Initialize with a genesis block with data from one of the snapshot services
2) Load my bitcoin wallet to receive AGS and PTS
3) Transfer said balance from AGS and PTS... (believe it or not this was tricky to nail down)
I have a laundry list of items that need to be addressed. There have been a number of requests discussed in this thread and in the attack thread that are causing some delays. Things I need to handle are:
1) Enforce minimal market depth.
2) Increase default collateral requirement to 10x.
3) Fix a bug where wallet loading errors erase wallet contents.
4) Cover a position without requiring additional capital.
If you can cover a position without requiring additional capital, why do you still need to Increase default collateral requirement to 10x?
-
So since it's the 28th... Can we get the BTS X wallet for the test chain? Link? thanks.
I just checked in some bug fixes and validated that I could do the following:
1) Initialize with a genesis block with data from one of the snapshot services
2) Load my bitcoin wallet to receive AGS and PTS
3) Transfer said balance from AGS and PTS... (believe it or not this was tricky to nail down)
I have a laundry list of items that need to be addressed. There have been a number of requests discussed in this thread and in the attack thread that are causing some delays. Things I need to handle are:
1) Enforce minimal market depth.
2) Increase default collateral requirement to 10x.
3) Fix a bug where wallet loading errors erase wallet contents.
4) Cover a position without requiring additional capital.
Only no.4 takes much time, right?
-
Its nice to see a graphic of what it may look like.
Myself, and possibly many other users, would want to use the client for storing and exchanging value like bitUSD and not really use it for trading. A lot of people are also familiar with internet banking but not a trading terminal.
Maybe a tab with a simple display of your account (like in internet banking):
Bitshares: 5
BitUSD: 20
List of recent transactions:
I thought I would update everyone on our GUI development. We have been working with a bright developer named Nathan who has put together a large amount of a basic GUI for the BTS wallet. He still has some work to do, but his progress is still significant.
(http://the-iland.net/static/images/BTSX.png)
It isn't quite the interface I would have designed, but is certainly a step up from the command line and we will enhance it as time progresses.
-
let's think about the metaphor...a 'wallet'
what is in my wallet? cash. a driver's license. a credit card. i can give my wallet to a stranger and without my saying anything they understand what it is and they can spend my money.
the interface looks nice, powerful, etc, but i wouldn't call it a wallet.
-
let's think about the metaphor...a 'wallet'
what is in my wallet? cash. a driver's license. a credit card. i can give my wallet to a stranger and without my saying anything they understand what it is and they can spend my money.
the interface looks nice, powerful, etc, but i wouldn't call it a wallet.
+1
-
Personally, I don't know why gold is relevant. I have never looked to the price of gold to value anything, especially not crypto currencies. The markets will work best when participants are most informed and the underlying asset isn't prone to its own instability. I obviously think that gold should be incorporated later, but as for the test chain the underlying assets should be those that ppl are most comfortable valuing. The ttest chain should also have as few assets as possible. One would suffice but it is very important to include the Chinese community
+5%
Not only is gold a dumb currency, It's immoral. People that hoard it and store it in the ground, instead of letting it contribute to society and life do so much destruction to otherwise possible life. Every time I have to pump my car clutch in the morning, to get it to make a clean electrical connection (because it's too expensive to use gold in the switch) I cures the selfish bastards.
-
Its nice to see a graphic of what it may look like.
Myself, and possibly many other users, would want to use the client for storing and exchanging value like bitUSD and not really use it for trading. A lot of people are also familiar with internet banking but not a trading terminal.
Maybe a tab with a simple display of your account (like in internet banking):
Bitshares: 5
BitUSD: 20
I agree a lot of people will just be looking for a simple way to store value in currencies/gold outside the current systemt not actively trade them. (I'm not sure, but I think this is a good thing because it's means there will be some small profit to be made by people actively providing the market.)
I don't know if you've seen the bullionvault.com interface but it's quite good.
On the main page you see your gold, silver and currency holdings (like a wallet) and you have a simple option to buy or sell at the best price.
If you want to get more involved you can then click through to a different trading screen that gives you more information, like market depth, spreads etc.
Edit: I've addressed your comment Brent.Allsop in another thread rather than derail this one with a gold discussion.
https://bitsharestalk.org/index.php?topic=3285.0
-
Timer ended.........what now?
-
Timer ended.........what now?
at some point I3 generates a bitshares-xt genesis block based on bitshares-pts block 57,787 and the AGS donations. I3 releases bitshares-xt with instructions on how to import pts and btc wallets. This won't happen for a week or two.
-
I just implemented a check for market depth prior to executing any automated order matching.
I need to shut down a potential attack for paring a short/long and creating BitUSD outside the automated order matching.
-
I just implemented a check for market depth prior to executing any automated order matching.
I need to shut down a potential attack for paring a short/long and creating BitUSD outside the automated order matching.
+5%
-
+5% +5%
-
Daniel ,what does your signature mean?
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.
-
Daniel ,what does your signature mean?
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.
Some people have the idea that forum posts are as good as a verbal contract and may attempt to enforce something I post as a contract or something I do as a breach of contract. Basically, if I am going to post freely they must all be non-binding personal opinions and NOT obligations or official statements as CEO of a corporation. I will probably refine the disclaimer over time.
-
We view the forum as a place where we can share our thoughts and get help vetting our ideas in an open and transparent manner. It is here that we experiment with various metaphors and analogies in an attempt to communicate technical content and sometimes hard to grasp ideas. It is where we take time out of development to interact with the community while we are in a hurry to keep up with tens of thousands of postings in a real-time stream of consciousness. We do not own this forum and we speak here only in our capacities as forum members.
-
2) Increase default collateral requirement to 10x.
About 10 times the mortgage:
If I have 400000 xts. I can do: continue to buy bitusd, when I buy a value of 300000 XTS bitusd, the 2700000 XTS is frozen. Next, the seller has no xts. I began to raise the price, the price increased to 1.3 times, let the seller liquidated, sell him my bitusd.
If so, the bitusd deal is not fair. XTS is easy to be short. Perhaps the only fair trade, buyers and sellers of the half, 2 times the mortgage.
关于10倍抵押的思考：
假如我拥有40万xts。我可以这样做：持续买进bitusd，当我购买了价值30万xts的bitusd，卖方就有270万xts被冻结。接下来，卖方已经没有xts了。我开始抬价，把价格提高到1.3倍，让卖方平仓，我的bitusd卖给他。
如果是这样，bitusd的交易是不公平的。xts容易被人做空。可能唯一公平的交易方式，买卖双方各出一半，2倍抵押。
具体抵押细节我还不清楚，只是推测，如果说错了，请谅解。
-
So since it's the 28th... Can we get the BTS X wallet for the test chain? Link? thanks.
I just checked in some bug fixes and validated that I could do the following:
1) Initialize with a genesis block with data from one of the snapshot services
2) Load my bitcoin wallet to receive AGS and PTS
3) Transfer said balance from AGS and PTS... (believe it or not this was tricky to nail down)
I have a laundry list of items that need to be addressed. There have been a number of requests discussed in this thread and in the attack thread that are causing some delays. Things I need to handle are:
1) Enforce minimal market depth.
2) Increase default collateral requirement to 10x.
3) Fix a bug where wallet loading errors erase wallet contents.
4) Cover a position without requiring additional capital.
increase to 10x , it a fix value or can change depende on market depth
why not limit increase/decrease percentage of BTA in the period of 24 hours, if we limit 50% increase/decrease percentage in 24 hours , because 2 times BTS is frozen, so there are two days to operate
-
I have a laundry list of items that need to be addressed. There have been a number of requests discussed in this thread and in the attack thread that are causing some delays. Things I need to handle are:
1) Enforce minimal market depth.
2) Increase default collateral requirement to 10x.
3) Fix a bug where wallet loading errors erase wallet contents.
4) Cover a position without requiring additional capital.
https://bitsharestalk.org/index.php?topic=3315.0
I think it's not enough to avoid the attack.
I prefer a limit for matching price, The price of bitusd can't down more than 10% in one block.
No limit between current block and previous.
-
We view the forum as a place where we can share our thoughts and get help vetting our ideas in an open and transparent manner. It is here that we experiment with various metaphors and analogies in an attempt to communicate technical content and sometimes hard to grasp ideas. It is where we take time out of development to interact with the community while we are in a hurry to keep up with tens of thousands of postings in a real-time stream of consciousness. We do not own this forum and we speak here only in our capacities as forum members.
A use 1BTS create 100 bitusd, B use 1BTS create 200 bitusd, C want to use 1BTS buy 150 bitusd
the exchange is A and B , or B and C
the sell price
A:0.01BTS/bitusd, B: 0.005BTS/bitusd
the buy price
C:0.0067BTS/bitusd
it seem like exchange should beetween B and C
but I think the exchage should been A and B,, because ,
the sell price of BTS
A: 100bitusd/BTS
B:200 bitusd/BTS
the buy price of BTS
C: 150bitsud/BTS
so the exchange should between A and C
-
A is offering to short 100 BitUSD at a price of .01 BTS per USD
B is offering to short 200 BitUSD at a price of .005 BTS per USD
C is offering to buy 150 BitUSD at a price of .0067 BTS per USD
So lets pair the lowest ask with the highest bid... B & C trade and we get the following result:
B gives C 150 BitUSD
C gives B 150 * .0067 BTS = 1 BTS
B is required to put 2 * 1 BTS as collateral which consumes all of B's order.
Result B is short 150 BitUSD backed by 2 BTS and A is long 150 BitUSD.
We can therefore conclude that C got the best possible deal, he went short at a higher price than he requested.
A on the other hand is asking to go short at a price HIGHER than C is willing to buy and thus no trade could ever occur between these two parties.
-
2) Increase default collateral requirement to 10x.
About 10 times the mortgage:
If I have 400000 xts. I can do: continue to buy bitusd, when I buy a value of 300000 XTS bitusd, the 2700000 XTS is frozen. Next, the seller has no xts. I began to raise the price, the price increased to 1.3 times, let the seller liquidated, sell him my bitusd.
If so, the bitusd deal is not fair. XTS is easy to be short. Perhaps the only fair trade, buyers and sellers of the half, 2 times the mortgage.
关于10倍抵押的思考：
假如我拥有40万xts。我可以这样做：持续买进bitusd，当我购买了价值30万xts的bitusd，卖方就有270万xts被冻结。接下来，卖方已经没有xts了。我开始抬价，把价格提高到1.3倍，让卖方平仓，我的bitusd卖给他。
如果是这样，bitusd的交易是不公平的。xts容易被人做空。可能唯一公平的交易方式，买卖双方各出一半，2倍抵押。
具体抵押细节我还不清楚，只是推测，如果说错了，请谅解。
In a deep market there are many buyers and sellers. With a 10x initial margin, the margin call price would be 5x rather than 1.3 and thus it becomes much harder to trigger a short squeeze. With the minimal market depth for trading to occur you also prevent the simplistic 2 user case from ever existing.
-
2) Increase default collateral requirement to 10x.
About 10 times the mortgage:
If I have 400000 xts. I can do: continue to buy bitusd, when I buy a value of 300000 XTS bitusd, the 2700000 XTS is frozen. Next, the seller has no xts. I began to raise the price, the price increased to 1.3 times, let the seller liquidated, sell him my bitusd.
If so, the bitusd deal is not fair. XTS is easy to be short. Perhaps the only fair trade, buyers and sellers of the half, 2 times the mortgage.
关于10倍抵押的思考：
假如我拥有40万xts。我可以这样做：持续买进bitusd，当我购买了价值30万xts的bitusd，卖方就有270万xts被冻结。接下来，卖方已经没有xts了。我开始抬价，把价格提高到1.3倍，让卖方平仓，我的bitusd卖给他。
如果是这样，bitusd的交易是不公平的。xts容易被人做空。可能唯一公平的交易方式，买卖双方各出一半，2倍抵押。
具体抵押细节我还不清楚，只是推测，如果说错了，请谅解。
"when I buy a value of 300000 XTS bitusd, the 2700000 XTS is frozen." is not neccesarily the case. If I buy 1000 bitUSD which is backed with 1000 XTS. Then I sell it at 30000 XTS to you and you can only buy 10 bitUSD which is backed with 10 XTS.
-
We view the forum as a place where we can share our thoughts and get help vetting our ideas in an open and transparent manner. It is here that we experiment with various metaphors and analogies in an attempt to communicate technical content and sometimes hard to grasp ideas. It is where we take time out of development to interact with the community while we are in a hurry to keep up with tens of thousands of postings in a real-time stream of consciousness. We do not own this forum and we speak here only in our capacities as forum members.
A use 1BTS create 100 bitusd, B use 1BTS create 200 bitusd, C want to use 1BTS buy 150 bitusd
the exchange is A and B , or B and C
the sell price
A:0.01BTS/bitusd, B: 0.005BTS/bitusd
the buy price
C:0.0067BTS/bitusd
it seem like exchange should beetween B and C
but I think the exchage should been A and B,, because ,
the sell price of BTS
A: 100bitusd/BTS
B:200 bitusd/BTS
the buy price of BTS
C: 150bitsud/BTS
so the exchange should between A and C
when we are talking sell order and buy order, there is a hidden field we might miss, the target currency we want to sell/buy.
Your example here should be A and B short sell bitusd, C want to buy bitusd, but your understanding is opposite wrong.
Sent from my GT-N7100 using Tapatalk
-
We view the forum as a place where we can share our thoughts and get help vetting our ideas in an open and transparent manner. It is here that we experiment with various metaphors and analogies in an attempt to communicate technical content and sometimes hard to grasp ideas. It is where we take time out of development to interact with the community while we are in a hurry to keep up with tens of thousands of postings in a real-time stream of consciousness. We do not own this forum and we speak here only in our capacities as forum members.
A use 1BTS create 100 bitusd, B use 1BTS create 200 bitusd, C want to use 1BTS buy 150 bitusd
the exchange is A and B , or B and C
the sell price
A:0.01BTS/bitusd, B: 0.005BTS/bitusd
the buy price
C:0.0067BTS/bitusd
it seem like exchange should beetween B and C
but I think the exchage should been A and B,, because ,
the sell price of BTS
A: 100bitusd/BTS
B:200 bitusd/BTS
the buy price of BTS
C: 150bitsud/BTS
so the exchange should between A and C
when we are talking sell order and buy order, there is a hidden field we might miss, the target currency we want to sell/buy.
Your example here should be A and B short sell bitusd, C want to buy bitusd, but your understanding is opposite wrong.
Sent from my GT-N7100 using Tapatalk
becuase my job reason, I usually am concerned with the system is convergen or diverge.
the Bitusds A sell is totally different with the Bitusds B sell
per Bitusd_A include 0.01 BTS , while Bitusd_B include 0.005BTS
So if C exchange with B , C buy 150 Bitusd_B that only include value 150*0.005=0.75BTS
if C exchange with A , C buy 100Bitusd_A that include value 100*0.1=1BTS
C tend to buy the Bitusd that include more value ,therefore C should exchane with A
in other way ,if there is D use 1 BTS create 10000Bitusd
if acc. to your exchange rule , D the sell price only 0.0001BTS/ bitusd ,so C should exchange with D,
but there also is E use 1 BTS create 100000000Bitusd , F ```````` or more
so this system diverge
-
ur... @BTSdac the rule for match buy bitusd orders should using lowest ratio between bitusd and bts , not the value priced in BTS, in your model, why not using value priced in bitusd? it's unfair.
Sent from my GT-N7100 using Tapatalk
-
Today I resolved many annoying bugs and increased the initial margin requirement to 10x.
I also create a tool for viewing your BTS balance from AGS or PTS given a Bitcoin-Qt or Protshares wallet.dat:
https://bitsharestalk.org/index.php?topic=3330.msg41898#msg41898
-
ur... @BTSdac the rule for match buy bitusd orders should using lowest ratio between bitusd and bts , not the value priced in BTS, in your model, why not using value priced in bitusd? it's unfair.
Sent from my GT-N7100 using Tapatalk
everyone use the same ratio to create BTA in on block or in period of time?
-
You can always scale the margin requirements to the amount of capital. So at the low end where people only have 100 BTS, have a 10x margin as they are the ones who will get called the most often. While at the high end you can only require 2X as they likely have more capital that they can deploy without a forced call.
-
A is offering to short 100 BitUSD at a price of .01 BTS per USD
B is offering to short 200 BitUSD at a price of .005 BTS per USD
C is offering to buy 150 BitUSD at a price of .0067 BTS per USD
So lets pair the lowest ask with the highest bid... B & C trade and we get the following result:
B gives C 150 BitUSD
C gives B 150 * .0067 BTS = 1 BTS
B is required to put 2 * 1 BTS as collateral which consumes all of B's order.
Result B is short 150 BitUSD backed by 2 BTS and A is long 150 BitUSD.
We can therefore conclude that C got the best possible deal, he went short at a higher price than he requested.
A on the other hand is asking to go short at a price HIGHER than C is willing to buy and thus no trade could ever occur between these two parties.
you mean if D is offering to short 400 BitUSD at a price of .0025 BTS per USD,
then C should exchange with D?
-
为什么我分到的bts 比例比别人少很多？？？ 一个pts分多少个bts到底？？？还有ags的呢
-
Could Nathan or Bytemaster comment on the below (concerns client UI). I am interested to hear why you guys think. Thanks
Its nice to see a graphic of what it may look like.
Myself, and possibly many other users, would want to use the client for storing and exchanging value like bitUSD and not really use it for trading. A lot of people are also familiar with internet banking but not a trading terminal.
Maybe a tab with a simple display of your account (like in internet banking):
Bitshares: 5
BitUSD: 20
I agree a lot of people will just be looking for a simple way to store value in currencies/gold outside the current systemt not actively trade them. (I'm not sure, but I think this is a good thing because it's means there will be some small profit to be made by people actively providing the market.)
I don't know if you've seen the bullionvault.com interface but it's quite good.
On the main page you see your gold, silver and currency holdings (like a wallet) and you have a simple option to buy or sell at the best price.
If you want to get more involved you can then click through to a different trading screen that gives you more information, like market depth, spreads etc.
Edit: I've addressed your comment Brent.Allsop in another thread rather than derail this one with a gold discussion.
https://bitsharestalk.org/index.php?topic=3285.0
-
I will be traveling for the Texas conference so updates will be sparse for the rest of the week.
-
I will be traveling for the Texas conference so updates will be sparse for the rest of the week.
why not hire more developers ?
-
I will be traveling for the Texas conference so updates will be sparse for the rest of the week.
why not hire more developers ?
bytemaster once responsed that he had been doing programmer hiring job and knew clearly that hiring talented programmers is very hard, harder than most thinks.
But I still don't that understand enough how could it be, to the degree that this hole IFMFS project of such a huge market capacity can't even appeal an extra genius to join in. Incredible.
-
为什么我分到的bts 比例比别人少很多？？？ 一个pts分多少个bts到底？？？还有ags的呢
注意找零地址。
translate: Find in your change address.
-
I will be traveling for the Texas conference so updates will be sparse for the rest of the week.
why not hire more developers ?
bytemaster once responsed that he had been doing programmer hiring job and knew clearly that hiring talented programmers is very hard, harder than most thinks.
But I still don't that understand enough how could it be, to the degree that this hole IFMFS project of such a huge market capacity can't even appeal an extra genius to join in. Incredible.
Very few people in the world know C++ well, know cryptography, know Bitcoin and the community, enough to do the job.
Anyone could do the user interface but the tougher parts aren't so easy and would take a person weeks or months to master. This close to launch I doubt Bytemaster has the time to waste on it.
The same question could be asked of Bitcoin. Why are there only a handful of people who are able to develop Bitcoin?
-
As far as appealing to smart people to join the team.... we have senior engineers from google contacting us for jobs and several people who are working with us or to whom we have extended offers also have offers on the table from google. Unfortunately, in addition to finding people with the proper skills there is also a need to find people interested in taking the risks and who are on the market at this exact moment. We have extended offers to an individual who found the majority of major security bugs in Bitcoin with years of experience.
The problem we have is that anyone with the skills to develop blockchain technology without months of training is already doing so (one of the alt coins) and their own pet projects are more interesting to them than even a highly paid position working for us. Often they have prior commitments (school, job, kids, etc) that mean from the time we convince them to work with us that until they can start work is at least a couple of weeks if not a month or more.
It is not unusual for a company looking for programing talent to take months if not over a year to fill a few positions.
-
As far as appealing to smart people to join the team.... we have senior engineers from google contacting us for jobs and several people who are working with us or to whom we have extended offers also have offers on the table from google. Unfortunately, in addition to finding people with the proper skills there is also a need to find people interested in taking the risks and who are on the market at this exact moment. We have extended offers to an individual who found the majority of major security bugs in Bitcoin with years of experience.
The problem we have is that anyone with the skills to develop blockchain technology without months of training is already doing so (one of the alt coins) and their own pet projects are more interesting to them than even a highly paid position working for us. Often they have prior commitments (school, job, kids, etc) that mean from the time we convince them to work with us that until they can start work is at least a couple of weeks if not a month or more.
It is not unusual for a company looking for programing talent to take months if not over a year to fill a few positions.
I hope you mean dan kaminsky. A nod of approval from a high-profile security researcher such as dan would give a lot of confidence to potential users/investors of bitshare
-
I guess he is talking about Sergio Lerner
-
Counterparty is using two Bitcoin coders for some security audit. Maybe one of them.
-
As far as appealing to smart people to join the team.... we have senior engineers from google contacting us for jobs and several people who are working with us or to whom we have extended offers also have offers on the table from google. Unfortunately, in addition to finding people with the proper skills there is also a need to find people interested in taking the risks and who are on the market at this exact moment. We have extended offers to an individual who found the majority of major security bugs in Bitcoin with years of experience.
The problem we have is that anyone with the skills to develop blockchain technology without months of training is already doing so (one of the alt coins) and their own pet projects are more interesting to them than even a highly paid position working for us. Often they have prior commitments (school, job, kids, etc) that mean from the time we convince them to work with us that until they can start work is at least a couple of weeks if not a month or more.
It is not unusual for a company looking for programing talent to take months if not over a year to fill a few positions.
In a prior life I was a very successful IT head hunter. I'd be happy to recruit (no charge) for you.
Send me high level job descriptions, number of openings, starting pay, full time or part, hourly or salary, perks, telecomute policy, stock options(AGS), etc...
I also noticed there is no jobs//hiring link on the invictus.io site.
-
As far as appealing to smart people to join the team.... we have senior engineers from google contacting us for jobs and several people who are working with us or to whom we have extended offers also have offers on the table from google. Unfortunately, in addition to finding people with the proper skills there is also a need to find people interested in taking the risks and who are on the market at this exact moment. We have extended offers to an individual who found the majority of major security bugs in Bitcoin with years of experience.
The problem we have is that anyone with the skills to develop blockchain technology without months of training is already doing so (one of the alt coins) and their own pet projects are more interesting to them than even a highly paid position working for us. Often they have prior commitments (school, job, kids, etc) that mean from the time we convince them to work with us that until they can start work is at least a couple of weeks if not a month or more.
It is not unusual for a company looking for programing talent to take months if not over a year to fill a few positions.
In a prior life I was a very successful IT head hunter. I'd be happy to recruit (no charge) for you.
Send me high level job descriptions, number of openings, starting pay, full time or part, hourly or salary, perks, telecomute policy, stock options(AGS), etc...
I also noticed there is no jobs//hiring link on the invictus.io site.
That would be great! I'll work on getting you the information you request.
In general, we need about one cord of stacked and seasoned steely-eyed geeks.
(http://www.cordofwood.org/wp-content/uploads/2011/11/cord-of-wood.jpg)
-
Don't know if it makes sense.. but it would help to understand better what other "international" public you might have.. by adding linkedin profile for invictus. Plus it shares over a different environment what invictus is... and it's a great place to promote invictus products.
I have already found several companies composed by the name of invictus.. but.. those are just a couple..
What I mean is.. you could sell the company name at a higher bid... will help over all you effort and will start to take market share into BTS.
-
Don't know if it makes sense.. but it would help to understand better what other "international" public you might have.. by adding linkedin profile for invictus.
Using Linkedin would make a lot more sense than a "Meme collection" (https://bitsharestalk.org/index.php?topic=3458.0) ::)
Ethereum and Mastercoin already have a presence there both as company and as the Group that wider community will want to look to. That then could act as a professional blog with key updates.
-
Dan, I commit a pull request for match_orders().
Please check it, thank you.
-
Any updates?thanks.
-
Dan, I commit a pull request for match_orders().
Please check it, thank you.
I need to review this update more carefully, a quick glance does not appear to be correct.
-
Any updates?thanks.
I have spent the past couple of days refactoring the code and preparing a much more robust testing environment for unit tests.
-
It's promising. Looking forward to XTS's big day ;D
-
Any updates?thanks.
I have spent the past couple of days refactoring the code and preparing a much more robust testing environment for unit tests.
Will it be ready for the Ides of March?
-
@bm, could you kindly enough tell us how long the btx system would be used and the bts could be released？
-
Any updates?thanks.
I have spent the past couple of days refactoring the code and preparing a much more robust testing environment for unit tests.
Will it be ready for the Ides of March?
I am working here side by side with toast in a coding marathon. We are making good progress, but we will not hit our goal :'( :'(. We will have a much more detailed status update / report in the next few days. The recent attack (Monopoly BitUSD attack) has caused be to reconsider 10x.
-
May the God bless you!!!
-
Better have a perfectly working system instead off rushing some arbitrary release date ..
I dont see mastercoin as competitor
-
:)
-
Better have a perfectly working system instead off rushing some arbitrary release date ..
I dont see mastercoin as competitor
[/quote]
+5%
-
Any updates?thanks.
I have spent the past couple of days refactoring the code and preparing a much more robust testing environment for unit tests.
Will it be ready for the Ides of March?
I am working here side by side with toast in a coding marathon. We are making good progress, but we will not hit our goal :'( :'(. We will have a much more detailed status update / report in the next few days.
Thank you for all your hard work. The quality is more important than the timing.
"I've always believed that if you put in the work, the results will come." --Michael Jordan
-
Any updates?thanks.
I have spent the past couple of days refactoring the code and preparing a much more robust testing environment for unit tests.
Will it be ready for the Ides of March?
I am working here side by side with toast in a coding marathon. We are making good progress, but we will not hit our goal :'( :'(. We will have a much more detailed status update / report in the next few days.
Thank you for all your hard work. The quality is more important than the timing.
"I've always believed that if you put in the work, the results will come." --Michael Jordan
That is it. +5%
-
Better have a perfectly working system instead off rushing some arbitrary release date ..
I dont see mastercoin as competitor
+5%
[/quote]
Mastercoin is one dimensional exchange. So Bitshare X is much more multifaceted cryto-equity. So Polishing UI for bitshares is a priority not as who will be the first to release. It should as user-friendly.
-
Any updates?thanks.
I have spent the past couple of days refactoring the code and preparing a much more robust testing environment for unit tests.
Will it be ready for the Ides of March?
I am working here side by side with toast in a coding marathon. We are making good progress, but we will not hit our goal :'( :'(. We will have a much more detailed status update / report in the next few days.
Thank you for all your hard work. The quality is more important than the timing.
"I've always believed that if you put in the work, the results will come." --Michael Jordan
I am thankful as well for their hard work. I would say that both quality and timing are very important and neither more important than the other. Delivering on time with a quality product will only increase confidence and drive greater investment. It will also reduce the expenditure of valuable AGS funds.
-
I want to ask if there are any meanings to get AGS by donating PTS before the BTS x carry out for public ,OR what's even worse ,the bts cant carry out,are there more risks to donate during this time? :-\ :-\
-
Its too late for bitshares . Try other incoming DACs by I3. ;D
-
In tonights update I would like to share some of our latest developments and roll out plans:
I have been putting together an extensive test plan and while preparing for the launch of BitShares XT have concluded that testing everything at once would be like the Wright Brothers attempting to fly an experimental airplane across the Pacific Ocean carrying 2000 passengers while under attack by severe weather.
(http://static.ddmcdn.com/gif/chronicle-of-flight1.jpg)
We have many moving parts that need to be tested and for the sake of everyone involved we are preparing for a phased launch schedule that will add new features as we go. The primary goal is to get the BTS XT shareholders liquid as soon as possible with a block chain that has a near 0 probability of reset. The risk of a reset will significantly harm the market value of BitShares XT.
To achieve this goal we will focus the first test on our networking code and TaPOS without the BitAssets being available. The wallet will implement an API as close to Bitcoin's JSON-RPC API as possible and therefore should be relatively easy for exchanges to integrate with.
Assuming this test is successful, we will use this chain as the snapshot chain for future revisions of BitShares XT that add BitAsset support. Recent discussions in the BTS X attack thread have necessitated some significant thought and changes including among them:
a) Closer evaluation of the Initial Margin requirements. (10x is too much, 2x may be too little)
b) Closer evaluation of the Maintenance Margin requirements. (If it is too high, it increases risks for shorts, too low we risk running out of collateral on short squeezes)
c) More robust algorithm for measuring market depth with a focus on positions near the price point. Initial implementation simply looked at total shares involved without consideration of their price relative to other bids. The exact details on this need to be resolved.
d) Consider implementation of circuit breakers that halt trading if the price changes too quickly. This will help mitigate many attacks and effects caused by short squeezes.
As you can see there are many aspects of this that requires both development and extensive testing and none of these should be rushed. We will likely introduce BitShares ME (new snapshot taken from AGS/PTS) as an incremental step toward testing the Bid/Ask system with custom assets prior to implementing the more sensitive short/long system in BTS XT.
This incremental approach will get tradable value into your hands as quickly as possible while also paving the way for many new DACs to be developed along the way.
As you all know we want to get this out there as quickly as possible. To achieve this goal I have almost completely delegated all non-development tasks to Gregory, Stan, Bo, and Brian who will be taking over business partnerships, marketing, Beyond Bitcoin, etc. They have some exciting things coming for everyone that I am pleased will not take me away from being focused on delivery.
This week I worked with Toast in person to teach him how to extend the BitShares Toolkit to implement BitShares DNS. In three days we managed to get through a basic unit test that started the first auction. Toast will be working on BitShares DNS full time and helping prove that our BitShares Toolkit is properly extendable. We have a video coming out on this shortly.
-
+5%
-
Great update and great work!!
-
Great work ! +5%
but I don`t understand why a new snapshot is needed. the snapshot of 2.28 is enough for test,
As you can see there are many aspects of this that requires both development and extensive testing and none of these should be rushed. We will likely introduce BitShares ME (new snapshot taken from AGS/PTS) as an incremental step toward testing the Bid/Ask system with custom assets prior to implementing the more sensitive short/long system in BTS XT.
-
Great work ! +5%
but I don`t understand why a new snapshot is needed. the snapshot of 2.28 is enough for test,
As you can see there are many aspects of this that requires both development and extensive testing and none of these should be rushed. We will likely introduce BitShares ME (new snapshot taken from AGS/PTS) as an incremental step toward testing the Bid/Ask system with custom assets prior to implementing the more sensitive short/long system in BTS XT.
No, no! Every new BitShares DAC gets born with a snapshot from somewhere! BitShares ME is a new franchise, so it gets spawned from the main grandparents PTS/AGS. It will be a "sibling" franchise to BitShares X on the BitShares family tree. Only Bank and Exchange DACs are spawned with snapshots from the BitShares X proto-family born on Feb 28th.
Franchises allow people to focus their investments into specific sub-sectors of the BitShares industry. PTS/AGS are for general investment in all future franchises.
Many DAC instances can then be derived by third party developers from any family franchise.
-
Cool~ I like the idea of Bitshares ME and look forward to its release. We DO need something to play with in such a quiet market :P
-
what's Bitshares ME, are there any detail content?
-
what's Bitshares ME, are there any detail content?
+5% Can we have some more details of Bitshares Me?
-
You can move to 06:20 in this video to see details about Bitshares Me:
http://vimeo.com/user24356268/review/87448377/66716b27fa
-
hi dan, just wondering if you have any estimated date in mind for releasing BTSXT? form your latest update, I have a feeling that you are going to move bitshare me ahead of BTSXT. correct me if i am wrong ...
Assuming this test is successful, we will use this chain as the snapshot chain for future revisions of BitShares XT that add BitAsset support. Recent discussions in the BTS X attack thread have necessitated some significant thought and changes including among them:
a) Closer evaluation of the Initial Margin requirements. (10x is too much, 2x may be too little)
b) Closer evaluation of the Maintenance Margin requirements. (If it is too high, it increases risks for shorts, too low we risk running out of collateral on short squeezes)
c) More robust algorithm for measuring market depth with a focus on positions near the price point. Initial implementation simply looked at total shares involved without consideration of their price relative to other bids. The exact details on this need to be resolved.
d) Consider implementation of circuit breakers that halt trading if the price changes too quickly. This will help mitigate many attacks and effects caused by short squeezes.
-
Great work ! +5%
but I don`t understand why a new snapshot is needed. the snapshot of 2.28 is enough for test,
As you can see there are many aspects of this that requires both development and extensive testing and none of these should be rushed. We will likely introduce BitShares ME (new snapshot taken from AGS/PTS) as an incremental step toward testing the Bid/Ask system with custom assets prior to implementing the more sensitive short/long system in BTS XT.
No, no! Every new BitShares DAC gets born with a snapshot from somewhere! BitShares ME is a new franchise, so it gets spawned from the main grandparents PTS/AGS. It will be a "sibling" franchise to BitShares X on the BitShares family tree. Only Bank and Exchange DACs are spawned with snapshots from the BitShares X proto-family born on Feb 28th.
Franchises allow people to focus their investments into specific sub-sectors of the BitShares industry. PTS/AGS are for general investment in all future franchises.
Many DAC instances can then be derived by third party developers from any family franchise.
I thought BitSharesX(T) have bid/ask features already.. Did I misunderstand something? What's the difference between ME and X, or say, what's "custom assets"? Sorry I'm not able to check the video.
-
XT was supposed to have all market features but instead will now have just shares on a blockchain to test TAPOS. All of the features are developed but require much more thorough testing. Functionality will be added incrementally. Future X chains still use XT as the snapshot source.
BTS Me has a feature set which is a strict subset of BTS XT, so it makes sense to test just those features and release it first before testing the much more complex market mechanics.
-
Toast, what is Bitshares ME?
-
You can move to 06:20 in this video to see details about Bitshares Me:
http://vimeo.com/user24356268/review/87448377/66716b27fa
Can someone tell me where the video is?
Sent from my iPad using Tapatalk (http://tapatalk.com/m?id=1)
-
Toast, what is Bitshares ME?
It's basically MSC or XCP but on it's own blockchain. Basically you can issue your own shares and do stuff like trade/pay dividends/make bets. Like "ToastGLD, each certificate is 1 oz of gold in my safe" or "ToastHours, each certificate entitles you to 1 hour of my time".
-
As you can see there are many aspects of this that requires both development and extensive testing and none of these should be rushed. We will likely introduce BitShares ME (new snapshot taken from AGS/PTS) as an incremental step toward testing the Bid/Ask system with custom assets prior to implementing the more sensitive short/long system in BTS XT.
Excellent, excellent. I strongly support rolling out features as they become available. BTS XT is such a game-changing kind of product that it should really pay to "get it right" the first time.
This week I worked with Toast in person to teach him how to extend the BitShares Toolkit to implement BitShares DNS. In three days we managed to get through a basic unit test that started the first auction. Toast will be working on BitShares DNS full time and helping prove that our BitShares Toolkit is properly extendable. We have a video coming out on this shortly.
Again, I'm very very glad to hear that you've got some parallel product development going.
The reason I'm excited about multiple products is that the main value proposition for PTS/AGS completely depends on development momentum. The world needs to see that products built on top of PTS/AGS snapshots have an immediate leg up on their competitors. As soon as there is even a single PTS/AGS-derived product that breaks through the $10,000,000 market-cap, developers will be flocking to us.
-
ok, I'm confused and disappointed now >:(
So I stopped AGSing before 2.28, and I expected to have a number of X BTSs when BTS XT comes out. As what you promised before.
And now you will creat a thing called ME, and you need a new snapshot then. And I get fewer BTSs then X!
I see no point of this but you want more people buying AGSs, is that your business model?
-
ok, I'm confused and disappointed now >:(
So I stopped AGSing before 2.28, and I expected to have a number of X BTSs when BTS XT comes out. As what you promised before.
And now you will creat a thing called ME, and you need a new snapshot then. And I get fewer BTSs then X!
I see no point of this but you want more people buying AGSs, is that your business model?
You should be very, very happy! You will be liquid in many unmanned business sectors and own AGS, XTS, and ME (and several more sectors by summer).
Each will be a DAC franchise, an entire family of DACs, and you will own all of their children.
There will be new snapshots from AGS/PTS for each new family as always promised.
No change, no new snapshot for BitShares X. You own that and it cannot be taken away. This family of families will grow and have many children. And you will own them all!
Where else can you buy or mine an entire profitable industry with one coin?
:)
-
ok, I'm confused and disappointed now >:(
So I stopped AGSing before 2.28, and I expected to have a number of X BTSs when BTS XT comes out. As what you promised before.
And now you will creat a thing called ME, and you need a new snapshot then. And I get fewer BTSs then X!
I see no point of this but you want more people buying AGSs, is that your business model?
BTS X still exists and is totally different from BTS Me. You still have your BTS XT. They will still (eventually) do the same thing as before, which is different from what ME does. BTS Me has always been in the pipeline, just the order in which things are released get changed.
-
You can move to 06:20 in this video to see details about Bitshares Me:
http://vimeo.com/user24356268/review/87448377/66716b27fa
Can someone tell me where the video is?
Sent from my iPad using Tapatalk (http://tapatalk.com/m?id=1)
The link you just quoted contains the video at vimeo. Considering vimeo is not accessible in China, logxing has put the video in Youku. It's the same video as that one announcing snapshot of 228. You likely have seen it already.
-
In tonights update I would like to share some of our latest developments and roll out plans:
I have been putting together an extensive test plan and while preparing for the launch of BitShares XT have concluded that testing everything at once would be like the Wright Brothers attempting to fly an experimental airplane across the Pacific Ocean carrying 2000 passengers while under attack by severe weather.
(http://static.ddmcdn.com/gif/chronicle-of-flight1.jpg)
We have many moving parts that need to be tested and for the sake of everyone involved we are preparing for a phased launch schedule that will add new features as we go. The primary goal is to get the BTS XT shareholders liquid as soon as possible with a block chain that has a near 0 probability of reset. The risk of a reset will significantly harm the market value of BitShares XT.
To achieve this goal we will focus the first test on our networking code and TaPOS without the BitAssets being available. The wallet will implement an API as close to Bitcoin's JSON-RPC API as possible and therefore should be relatively easy for exchanges to integrate with.
Assuming this test is successful, we will use this chain as the snapshot chain for future revisions of BitShares XT that add BitAsset support. Recent discussions in the BTS X attack thread have necessitated some significant thought and changes including among them:
a) Closer evaluation of the Initial Margin requirements. (10x is too much, 2x may be too little)
b) Closer evaluation of the Maintenance Margin requirements. (If it is too high, it increases risks for shorts, too low we risk running out of collateral on short squeezes)
c) More robust algorithm for measuring market depth with a focus on positions near the price point. Initial implementation simply looked at total shares involved without consideration of their price relative to other bids. The exact details on this need to be resolved.
d) Consider implementation of circuit breakers that halt trading if the price changes too quickly. This will help mitigate many attacks and effects caused by short squeezes.
As you can see there are many aspects of this that requires both development and extensive testing and none of these should be rushed. We will likely introduce BitShares ME (new snapshot taken from AGS/PTS) as an incremental step toward testing the Bid/Ask system with custom assets prior to implementing the more sensitive short/long system in BTS XT.
This incremental approach will get tradable value into your hands as quickly as possible while also paving the way for many new DACs to be developed along the way.
As you all know we want to get this out there as quickly as possible. To achieve this goal I have almost completely delegated all non-development tasks to Gregory, Stan, Bo, and Brian who will be taking over business partnerships, marketing, Beyond Bitcoin, etc. They have some exciting things coming for everyone that I am pleased will not take me away from being focused on delivery.
This week I worked with Toast in person to teach him how to extend the BitShares Toolkit to implement BitShares DNS. In three days we managed to get through a basic unit test that started the first auction. Toast will be working on BitShares DNS full time and helping prove that our BitShares Toolkit is properly extendable. We have a video coming out on this shortly.
google translate
BitShares x provide a stable price of bitusd and bitcny , but users need to pledge 2-10 times of the BTS to
speculation, which for users is no Attractive , lost speculative leverage , as well as we create bitusd, bitcny,
who need these bitusd, bitcny it?
Demand quantity of bitusd and bitcny , equivalent to the value of BitShares x , we need to create bitusd, bitcny
needs in the world.
We should design a subsystem in BitShares x.
BitShares x provide a stable price of bitusd and bitcny, subsystems push users to use them. bitusd and bitcny
needs mainly of two parts , one is shopping , the other one is speculative , and in a very long time, speculative
demand is Most of the needs.
In summary, there are some suggestions for BitShares x subsystem .
firstly. Design a subsystem , to provide users with speculative leverage , user-friendly speculation.
For example : User A converted 1000 dollars into 1000 bitusds, 1000 bitusds in BitShares x, A can buy a variety of
digital assets such as BTC, LTC, and so on . While A can publish a loaning information , B has 1000 dollars , see
a loaning information, choose to A loans, the system transaction , B has 2000 bitusds to invest.
If the asset of B is approximately equal to (1000 + X) * 1.2, the subsytem will send a notice message to B, when B
's assets is approximately equals to 1000 + X, system will be send B'assets and send 1000 + X bitusds to A.
Thus , the bitusd users will have three chooses .
1.A borrower to others. 2.1000 bitusds to invest.
3.3000 bitusds to invest .
bitusd can gain will make a steady stream of dollars converted into bitusd, thereby creating a more bitusd.
secondly. subsystem painting trend analysis page , user-friendly analysis .
finally. bitusd digital money should be designed with features,such as, a payment confirmation fast , Security ,
and less data exchange and so on, to facilitate for the future needs of the consumer.
-
ok, I'm confused and disappointed now >:(
So I stopped AGSing before 2.28, and I expected to have a number of X BTSs when BTS XT comes out. As what you promised before.
And now you will creat a thing called ME, and you need a new snapshot then. And I get fewer BTSs then X!
I see no point of this but you want more people buying AGSs, is that your business model?
BTS X still exists and is totally different from BTS Me. You still have your BTS XT. They will still (eventually) do the same thing as before, which is different from what ME does. BTS Me has always been in the pipeline, just the order in which things are released get changed.
ok, so when it comes I can just sell all my BTS ME with no impact on my BTS ＸＴ， ｉｓ ｔｈａｔ ｒｉｇｈｔ？
-
Correct, they are totally separate DACs
-
When ABOUT will BTS ME come out?
-
I am a bit lost...A couple of questions:
1. As far as I understand holding AGS / PTS now will give me at least 10% from PTS and at least 10% from AGS on all future DACS including i.e. Bitshares ME and that's why they still have value. Correct? But if that's the case everytime there is a new DAC released their value will drop and drop...Correct? Unless I3 decides to say at some point that a new DAC will honor more than 1:1 the new shares to AGS/PTS Holders which i think would be unlikelly?Or not?
2. The exact % of Bitshares ME honored by holding AGS/PTS will be announced when? A couple of weeks earlier before Bitshares ME is expected to be launched?
3. Holding Bitshares XT will also give me a % percentage of Bitshares ME as well before it is launched? The exact % again to be announced or it is 1:1 allocation? Or depends when it is released? Basically how do we estimate that % everytime there is a new DAC release?
4. When Bitshares i.e Bingo is launced then the new shares will honor at least 10% AGS/PTS, x% of Bitshares X (how do we calculate this), and 1:1 of Bitshares ME? and so on...?
Thank you very much for the replies in advance!!
-
III thinks we are all fool,and easy to get the money from our pocket!
-
ok, I'm confused and disappointed now >:(
So I stopped AGSing before 2.28, and I expected to have a number of X BTSs when BTS XT comes out. As what you promised before.
And now you will creat a thing called ME, and you need a new snapshot then. And I get fewer BTSs then X!
I see no point of this but you want more people buying AGSs, is that your business model?
BTS X still exists and is totally different from BTS Me. You still have your BTS XT. They will still (eventually) do the same thing as before, which is different from what ME does. BTS Me has always been in the pipeline, just the order in which things are released get changed.
ok, so when it comes I can just sell all my BTS ME with no impact on my BTS ＸＴ， ｉｓ ｔｈａｔ ｒｉｇｈｔ？
That is correct. You get all our planned products as soon as they are ready.
They may be sold or bought separately like any other coins. No impact on each other.
DACs are all in a race with different development teams competing to be next to see glory.
Because different teams compete, we cannot predict who will be fastest and which will be next.
Meet some of these teams in our March newsletter, which I am working hard to finish.
-
I am a bit lost...A couple of questions:
1. As far as I understand holding AGS / PTS now will give me at least 10% from PTS and at least 10% from AGS on all future DACS including i.e. Bitshares ME and that's why they still have value. Correct? But if that's the case everytime there is a new DAC released their value will drop and drop...Correct? Unless I3 decides to say at some point that a new DAC will honor more than 1:1 the new shares to AGS/PTS Holders which i think would be unlikelly?Or not?
We make the software for each DAC family freely available to everybody who wants to develop a specialized member of that family. These developers set the % of their DAC that will go to AGS and PTS holders. If they do less than 10% to each, III will not support their DACs. Further, we will support their competitors who give better deals to AGS and PTS holders. If two release versions of a DAC family and one does 10/10 (and keeps 80%) and the other does 40/40 (and keeps 20%), who will this community support the most? Market pressures will favor the most generous developer.
2. The exact % of Bitshares ME honored by holding AGS/PTS will be announced when? A couple of weeks earlier before Bitshares ME is expected to be launched?
DAC families are franchises - free open source toolkits from which other developers can construct and release DACs. Each developer gets to set their own release schedule and DAC parameters. We work to find and encourage developers and remove obstacles from their paths. This model leads to decentralization of the DAC industry and keeps Invictus from being a limit on industry growth. PTS and AGS value will grow as more credible DACs are announced and fall after the value is transferred from PTS/AGS to the DAC at each new snapshot. Think of PTS as a battery that charges up and then discharges each time a new snapshot is taken - like a camera flash charges and discharges.
3. Holding Bitshares XT will also give me a % percentage of Bitshares ME as well before it is launched? The exact % again to be announced or it is 1:1 allocation? Or depends when it is released? Basically how do we estimate that % everytime there is a new DAC release?
BitShares XT is the franchise for Bank and Exchange DACs. It has no effect on BitShares ME or vice versa. We will make the ME chain available to developers as a spinoff using some of our early BitShares XT technology. You will need to evaluate what other developers are offering to develop a ME chain from this toolkit. We know of one who appears to be planning to launch a chain this spring, but it is up to them to convince this community that they should be supported and to defeat any competitors who may emerge for them. Watch for their announcement when they are ready.
4. When Bitshares i.e Bingo is launced then the new shares will honor at least 10% AGS/PTS, x% of Bitshares X (how do we calculate this), and 1:1 of Bitshares ME? and so on...?
We will release a simple toolkit for a lottery franchise from which others can derive any number of new and exciting games. Watch to see who announces an intent to compete using this DAC family toolkit.
Thank you very much for the replies in advance!!
See my replies in bold. All of this is the subject of this month's newsletter to be released early this week.
-
Hi Stan,
I'm worrying about the Bitshares Me itself evolves to Bitshares X, cuz I sold out my PTS partially after March 1st. If the Bitshares Me evolves to Bitshares X one day, instead of Bitshares XT, then your mis-announcement may cause my loss. Just to confirmation, can you characterize clearly that every Bitshares X chain will be snapshoted from Bitshares XT, whose genesis block is snapshoted from 228 of PTS/AGS?
-
Yes, BTS X comes from BTX XT snapshots. BTS Me is a totally unrelated DAC, with a different AGS/PTS snapshot.
The confusion comes from the fact that I3 is saying BTS Me can be used to test aspects of BTS X, since they have some features in common, like both have a market.
-
Yes, BTS X comes from BTX XT snapshots. BTS Me is a totally unrelated DAC, with a different AGS/PTS snapshot.
The confusion comes from the fact that I3 is saying BTS Me can be used to test aspects of BTS X, since they have some features in common, like both have a market.
Toast, go and visit I3 more often. 8) 8)
-
I am a bit lost...A couple of questions:
1. As far as I understand holding AGS / PTS now will give me at least 10% from PTS and at least 10% from AGS on all future DACS including i.e. Bitshares ME and that's why they still have value. Correct? But if that's the case everytime there is a new DAC released their value will drop and drop...Correct? Unless I3 decides to say at some point that a new DAC will honor more than 1:1 the new shares to AGS/PTS Holders which i think would be unlikelly?Or not?
We make the software for each DAC family freely available to everybody who wants to develop a specialized member of that family. These developers set the % of their DAC that will go to AGS and PTS holders. If they do less than 10% to each, III will not support their DACs. Further, we will support their competitors who give better deals to AGS and PTS holders. If two release versions of a DAC family and one does 10/10 (and keeps 80%) and the other does 40/40 (and keeps 20%), who will this community support the most? Market pressures will favor the most generous developer.
Understood thanks
2. The exact % of Bitshares ME honored by holding AGS/PTS will be announced when? A couple of weeks earlier before Bitshares ME is expected to be launched?
DAC families are franchises - free open source toolkits from which other developers can construct and release DACs. Each developer gets to set their own release schedule and DAC parameters. We work to find and encourage developers and remove obstacles from their paths. This model leads to decentralization of the DAC industry and keeps Invictus from being a limit on industry growth. PTS and AGS value will grow as more credible DACs are announced and fall after the value is transferred from PTS/AGS to the DAC at each new snapshot. Think of PTS as a battery that charges up and then discharges each time a new snapshot is taken - like a camera flash charges and discharges.
I understand that. However that does not answer my question. Bitshares ME will be honored by my stake in AGS/PTS, by my stake in Bitshares X or by both (if i understand correctly point 3 below bitshares Me is completely irrelevant from Bitshares X)? and when do we expect the split to be announced? A couple of weeks before Bitshares ME is honored? a couple of months?
3. Holding Bitshares XT will also give me a % percentage of Bitshares ME as well before it is launched? The exact % again to be announced or it is 1:1 allocation? Or depends when it is released? Basically how do we estimate that % everytime there is a new DAC release?
BitShares XT is the franchise for Bank and Exchange DACs. It has no effect on BitShares ME or vice versa. We will make the ME chain available to developers as a spinoff using some of our early BitShares XT technology. You will need to evaluate what other developers are offering to develop a ME chain from this toolkit. We know of one who appears to be planning to launch a chain this spring, but it is up to them to convince this community that they should be supported and to defeat any competitors who may emerge for them. Watch for their announcement when they are ready.
Which developer do you refer to? Where can I find information about this developper? I think I have read something as an alternative to Bitshares XT, but didn't convience me so I just didn't bother to go in more detail there.Are you reffering to that one? Or something else? when can a newbie like me find this kind of informations if these are not posted here? If you can advise it would be nice. If not it is still ok and understandable..
Also I understand that Bitshares X will give me shares from Bitshares XI and then Bitshares XI for Bitshares XV and so on. Do I understand this correctly? Is it fair to assume therefore that once the snapshot for Bitshares XI will be made the price of Bitshares X will decrease (as this happened now with PTS/AGS after the snapshot since their value was transfered to Bitshares X). This is very important point for me to be clear, so please advise.
4. When Bitshares i.e Bingo is launced then the new shares will honor at least 10% AGS/PTS, x% of Bitshares X (how do we calculate this), and 1:1 of Bitshares ME? and so on...?
We will release a simple toolkit for a lottery franchise from which others can derive any number of new and exciting games. Watch to see who announces an intent to compete using this DAC family toolkit.
Again how can I watch who announces an intent to compete using this DAC if it is not announced here?
Please see my questions in red. THANK YOU VERY MUCH FOR YOUR REPLIES!!! I surelly Appreciate a lot that you spend your valuable time replying to my silly questions..The reason many times I ask silly questions is because I am very new to cryptocurrencies, I don't have much IT knowledge and it is very hard to understand all this concept of DACs and how things work.But I am trying to learn...Finally, I want to say that I have read a lot of complaints about how you guys don't communicate well what you are doing, that things don't work as expected, that you need a better marketing and so on...What I have to say is that since I understand much better things than a couple of months ago and since I am still fully supporting PTS and I3 and this community rather than XCP or Mastercoin or Next or Ripple, I think you are doing a very good job marketing wise and getting the information out there. I think you have built a great community here and others can try to beat that but they will fail! The monthly news letters are also amazing so looking forward to receive the March one. Keep up the good work!Thanks again!
-
What is actually very concerning is the fact that bytemaster said:
“ We will likely introduce BitShares ME… prior to implementing … BTS XT”
(here: https://bitsharestalk.org/index.php?topic=1890.msg45173#msg45173)
And what toast said:
“I would guess Lotto and DNS would come before ME.”
(here: https://bitsharestalk.org/index.php?topic=3615.msg45527#msg45527)
???
-
Why is that concerning? bytemaster said Me comes before XT, I said that Lotto/DNS (maybe) come before Me.
Nobody knows the exact order since these are parallel development efforts (dan on XT/Me, me on DNS, arlen on lotto)
-
Thanks toast for your clarifications. The question is: Is this because XT is delayed or the others earlier than expected. It was said that XT will come out (made liquid) this month (probably rather at the end of it). Would this mean it is not unlikely that DNS, ME and Lotto come out also this moth?
Differnt question. You mentioned XCP in the context of BTS ME. Wouldnt the betting feature require more than what I (up to now) understood BTS ME is (basically colored coins/digital IOUs)? Contracts for difference and colored coins are basically two different things. No?
-
Yes, BTS X comes from BTX XT snapshots. BTS Me is a totally unrelated DAC, with a different AGS/PTS snapshot.
The confusion comes from the fact that I3 is saying BTS Me can be used to test aspects of BTS X, since they have some features in common, like both have a market.
Thank you toast.
And I would take this as I3's formal clarification without Dan or Stan's correctness.
But toast, you also said Me is similar to other 2nd gen coins like nxt, xcp, ripple, msc cuz they are all IOU trading systems, didn't you?
Sent from my iPhone using Tapatalk
-
Yes, BTS X comes from BTX XT snapshots. BTS Me is a totally unrelated DAC, with a different AGS/PTS snapshot.
The confusion comes from the fact that I3 is saying BTS Me can be used to test aspects of BTS X, since they have some features in common, like both have a market.
Thank you toast.
And I would take this as I3's formal clarification without Dan or Stan's correctness.
But toast, you also said Me is similar to other 2nd gen coins like nxt, xcp, ripple, msc cuz they are all IOU trading systems, didn't you?
Sent from my iPhone using Tapatalk
哈，你就别担心了。
-
But toast, you also said Me is similar to other 2nd gen coins like nxt, xcp, ripple, msc cuz they are all IOU trading systems, didn't you?
I don't want to say too much because I don't know of Dan's exact plans for Me, but that's my impression based on his brief descriptions.
-
But toast, you also said Me is similar to other 2nd gen coins like nxt, xcp, ripple, msc cuz they are all IOU trading systems, didn't you?
I don't want to say too much because I don't know of Dan's exact plans for Me, but that's my impression based on his brief descriptions.
Thanks toast for your clarifications. The question is: Is this because XT is delayed or the others earlier than expected. It was said that XT will come out (made liquid) this month (probably rather at the end of it). Would this mean it is not unlikely that DNS, ME and Lotto come out also this moth?
Differnt question. You mentioned XCP in the context of BTS ME. Wouldnt the betting feature require more than what I (up to now) understood BTS ME is (basically colored coins/digital IOUs)? Contracts for difference and colored coins are basically two different things. No?
-
Is this because XT is delayed or the others earlier than expected.
Both. XT got delayed, and the process of refactoring XT code into a shell DAC made it really easy to make simpler DACs.
Differnt question. You mentioned XCP in the context of BTS ME. Wouldnt the betting feature require more than what I (up to now) understood BTS ME is (basically colored coins/digital IOUs)? Contracts for difference and colored coins are basically two different things. No?
You are correct. I don't know if betting will be part of BTS Me from the start. Probably CC would be a better comparison to make.
-
Is this because XT is delayed or the others earlier than expected.
Both. XT got delayed, and the process of refactoring XT code into a shell DAC made it really easy to make simpler DACs.
Differnt question. You mentioned XCP in the context of BTS ME. Wouldnt the betting feature require more than what I (up to now) understood BTS ME is (basically colored coins/digital IOUs)? Contracts for difference and colored coins are basically two different things. No?
You are correct. I don't know if betting will be part of BTS Me from the start. Probably CC would be a better comparison to make.
Ok. Thanks.
-
Hi Stan,
I'm worrying about the Bitshares Me itself evolves to Bitshares X, cuz I sold out my PTS partially after March 1st. If the Bitshares Me evolves to Bitshares X one day, instead of Bitshares XT, then your mis-announcement may cause my loss. Just to confirmation, can you characterize clearly that every Bitshares X chain will be snapshoted from Bitshares XT, whose genesis block is snapshoted from 228 of PTS/AGS?
Yes, every Bitshares X chain will have Bitshares X as an ancestor (parent or perhaps grandparent as the industry grows and perhaps segments further). BitShares ME is a sibling family to the X family, not a parent or child.
We are not smart enough, however, to predict what may be invented in the future. It will be up to each developer to determine where their new innovations should plug in to what amounts to an evolving DAC taxonomy or class hierarchy.
Could their be a multiple-inheritance hybrid DAC that is half-exchange and half-insurance? Or a lottery for music? Who knows? Would it be wrong for a developer who invents a domain name insurance DAC to honor 50% from holders of BitShares DNS and 50% from holders of BitShares MAS?
Often it makes sense for a new DAC to honor an incumbent competitor DAC's current owners rather than its original owners. If I were going to compete with an exchange that had been running for a year and had lots of customers, I would want to honor its current customers, not those who sold out and have since moved on. On the other hand, if I wanted to attract users of many types of exchanges, I'd honor BitShares X - the protoDAC parent all exchanges.
As developers try to offers DACs that will attract the largest possible supporter base, it would not surprise me to see them offer a mix like this:
- 30% PTS
- 30% AGS
- 30% XTS
- 10% Developer Support
The purpose of proto-DAC families is to give investors the opportunity to focus their investments on industry sectors that they believe in the most. This makes each DAC family a prediction market for the potential of that market segment.
ProtoDACs grow in value as:
- more credible DACs are announced that will honor them.
- more credible developers prove capable and earn trust.
ProtoDACs naturally and expectedly lose value after each snapshot is taken from them - transferring the value of an anticipated DAC they were holding to the actual instance of that DAC which has now become realized.
-
But toast, you also said Me is similar to other 2nd gen coins like nxt, xcp, ripple, msc cuz they are all IOU trading systems, didn't you?
I don't want to say too much because I don't know of Dan's exact plans for Me, but that's my impression based on his brief descriptions.
Thanks toast for your clarifications. The question is: Is this because XT is delayed or the others earlier than expected. It was said that XT will come out (made liquid) this month (probably rather at the end of it). Would this mean it is not unlikely that DNS, ME and Lotto come out also this moth?
Differnt question. You mentioned XCP in the context of BTS ME. Wouldnt the betting feature require more than what I (up to now) understood BTS ME is (basically colored coins/digital IOUs)? Contracts for difference and colored coins are basically two different things. No?
I'll cover all this in this month's newsletter, but the bottom line is that we have a horse race with different development teams racing to be the next one out. Invictus may make ordering decisions on who gets a little help from Bytemaster next, but otherwise the teams are independent and set their own schedules.
I think it is likely you will see several of them do their snapshots this Spring.
Ask them (when they reveal themselves and start their own threads).
-
Maybe this will help. Here's a sneak-peek from our upcoming March newsletter.
(https://static.squarespace.com/static/51fb043ee4b0608e46483caf/t/5325f056e4b08fd5fbc4a297/1394995287184/?format=1000w)
Each of the DAC franchises shown along the bottom has at least one team forming that could decide to release a DAC in that family this spring. I'll introduce you to some of them in the newsletter. We will hear from others when their deals are finalized and they decide to go public.
Please note that Invictus is staying out of the way. We do the R&D and help developers get started. Do not think that the fact that other developers are beginning to work in parallel means bytemaster has wandered off from BitShares X.
But our first priority is to grow the value for all industry supporters - and that means having many products in the pipeline. We promised to build you a decentralized crypto-equity industry. You will see many of its blossoms this Spring.
-
Is Bitshare Lotto a renamed DAC of Bitshare Bingo? Bingo game is not the same mechanics as Lottery.
-
They are separate dacs, lotto is simpler and will come first
Sent from my SCH-I535 using Tapatalk
-
Forked discussion of BitShares Lotto into it's own topic: https://bitsharestalk.org/index.php?topic=3621.0
-
Is Bitshare Lotto a renamed DAC of Bitshare Bingo? Bingo game is not the same mechanics as Lottery.
We like to start each proto-family franchise with the simplest possible instance to be the protocoin for the rest. Lotto was the simplest we could think of. Who wants to be the developer/promoter/maintainer to launch the first instance of it? There are bound to be different instances for different regions, cultures, and legal jurisdictions. Pick one, announce your social contract proposal to the community and get underway.
Please don't think BitShares is us trying to "own" this DAC - or any DAC. We are trying to stimulate other third parties to "get in the game" by making the first prototype available as an example.
I'm sure third parties will also be all over every other game you can think of. Don't wait for us to give you permission or a roadmap!
-
Please don't think BitShares is us trying to "own" this DAC - or any DAC. We are trying to stimulate other third parties to "get in the game" by making the first prototype available as an example.
I'm sure third parties will also be all over every other game you can think of. Don't wait for us to give you permission or a roadmap!
Yes I would agree to that. Many entrepreneurs are seeing this as another opportunity but they rather wait and see how will I3's DAC impact the market. Its kinda chain reaction you see in our country there is also a lottery-like number game consists of only two numbers. Now if it goes well with DAC implementations , third party developers will surely embrace I3's vision and honor the social contract .
-
We like to start each proto-family franchise with the simplest possible instance to be the protocoin for the rest. Lotto was the simplest we could think of. Who wants to be the developer/promoter/maintainer to launch the first instance of it? There are bound to be different instances for different regions, cultures, and legal jurisdictions. Pick one, announce your social contract proposal to the community and get underway.
Please don't think BitShares is us trying to "own" this DAC - or any DAC. We are trying to stimulate other third parties to "get in the game" by making the first prototype available as an example.
I'm sure third parties will also be all over every other game you can think of. Don't wait for us to give you permission or a roadmap!
Stan, do you mean that I3'll offer the stander proto but instead of launching Bitshares Lotto directly you guys would like to have others finished this part ?
-
Lotto is being worked on by arlen, it will also be the "tutorial dac" for others to look at while using bitshares toolkit
Sent from my SCH-I535 using Tapatalk
-
please keep your own words, tell us more about bts x, not others...
-
please keep your own words, tell us more about bts x, not others...
Everything I am doing is to build BTS X and
-
adistman : if you don't like the plan of dan ,you may sell out all your pts.
-
adistman : if you don't like the plan of dan ,you may sell out all your pts.
I do not want to speak with a crazy dog
-
please keep your own words, tell us more about bts x, not others...
Everything I am doing is to build BTS X and
Thanks for your hard work ,but please give us confidence.
-
Stan has already gave a glimpse on what is in store for AGS/PTS holders. So just relax and eventually Bitshare X will be something to look forward. 8)
-
The fact is that it is already March 17, and there is still no functional Bitshares X. Basically, the developers realized that there are several exploits possible. So, if BTSX would enter the real world in its current condition it will very possibly fail, imho.
If BTSX will be released without BitAssests functionality, we will be stuck with just another altcoin. All the Bitcoin 2.0 features will remain just a theory and will not be implemented in practice, and nobody knows if and when it will be.
All we are left with is just a dream. In the meantime, I3 have another dreams in the pipeline. Why have only one dream? Let's have many! :o
Much +5% for all!
:-[
-
We like to start each proto-family franchise with the simplest possible instance to be the protocoin for the rest. Lotto was the simplest we could think of. Who wants to be the developer/promoter/maintainer to launch the first instance of it? There are bound to be different instances for different regions, cultures, and legal jurisdictions. Pick one, announce your social contract proposal to the community and get underway.
Please don't think BitShares is us trying to "own" this DAC - or any DAC. We are trying to stimulate other third parties to "get in the game" by making the first prototype available as an example.
I'm sure third parties will also be all over every other game you can think of. Don't wait for us to give you permission or a roadmap!
Stan, do you mean that I3'll offer the stander proto but instead of launching Bitshares Lotto directly you guys would like to have others finished this part ?
Ideally, every DAC should have two champions:
- The developer - a steely-eyed geek that builds the block-chain back-end.
- The entrepreneur - a business-savant who figures out a compelling front-end and sells it to the world.
We are looking for both. We tend to sponsor developers until a 3rd party entrepreneur steps forward and says "I'll take that DAC to the moon!" We leave the decision on how to allocate shares (10/10/80?, 40/40/20?, 50/50?) to this pair of individuals based on what they think it will take to develop, promote, and sustain a viable DAC - (and what their competitors might do if they don't get that mix right!)
Ideally, all DACs have such an independent developer/entrepreneur pair to champion them. Once they do, we can let go, and return to the lab and invent something else to grow the industry.
So yes! Arlen is the initial developer behind Lotto, but he could use a partner: an entrepreneur with domain-specific expertise (perhaps having run a traditional lottery business somewhere). He could also use a successor who could eventually take over and allow Arlen to get back to his VP of Software duties.
There are many opportunities - and this revolution will be decentralized!
-
To be clear... Lotto DAC that Arlen will be working on will only be done to the point necessary for him to complete the documentation that will help others launch DACs. Arlen will not be the 'point man' behind Lotto... he is just using it as a learning exercise to make sure we have all of the extension points right in our API.
-
The fact is that it is already March 17, and there is still no functional Bitshares X. Basically, the developers realized that there are several exploits possible. So, if BTSX would enter the real world in its current condition it will very possibly fail, imho.
If BTSX will be released without BitAssests functionality, we will be stuck with just another altcoin. All the Bitcoin 2.0 features will remain just a theory and will not be implemented in practice, and nobody knows if and when it will be.
All we are left with is just a dream. In the meantime, I3 have another dreams in the pipeline. Why have only one dream? Let's have many! :o
Much +5% for all!
:-[
Actually I have one dream... BTS X *is* what I want more than anything... everything between now and then is parallel development or incremental steps toward BTS X.
-
The fact is that it is already March 17, and there is still no functional Bitshares X. Basically, the developers realized that there are several exploits possible. So, if BTSX would enter the real world in its current condition it will very possibly fail, imho.
If BTSX will be released without BitAssests functionality, we will be stuck with just another altcoin. All the Bitcoin 2.0 features will remain just a theory and will not be implemented in practice, and nobody knows if and when it will be.
All we are left with is just a dream. In the meantime, I3 have another dreams in the pipeline. Why have only one dream? Let's have many! :o
Much +5% for all!
:-[
Actually I have one dream... BTS X *is* what I want more than anything... everything between now and then is parallel development or incremental steps toward BTS X.
How confident are you that we'll see a completed, feature-rich XT by the end of Q2?
-
thanks，daniel and stan，things get more interesting now.
one more doubt：will all the lotto dacs use the same snapshot taken at specific time or the individual third party launched lotto dacs use different snapshots taken at different time ？
-
thanks，daniel and stan，things get more interesting now.
one more doubt：will all the lotto dacs use the same snapshot taken at specific time or the individual third party launched lotto dacs use different snapshots taken at different time ？
I thought that snapshot time of third pardty dacs would decided by their creators.
-
thanks，daniel and stan，things get more interesting now.
one more doubt：will all the lotto dacs use the same snapshot taken at specific time or the individual third party launched lotto dacs use different snapshots taken at different time ？
Great question!
Let's think this through together:
Initially there's a snapshot for BitSharesLOTTO and all PTS/AGS holders now have a new kind of coin in their wallets. It works just like PTS, only focused exclusively on interest in future gaming DACs.
Now, somebody who doesn't like the gaming business sector for any number of valid reasons, sells his LTS to someone who sees robotically honest gaming as the investment of a lifetime.
Who should own the shares of the LuckyStrikeCasino DAC when it comes out? Should it be the initial LTS snapshot or a snapshot of the latest block in the LTS chain?
Obviously, it should be the latest block since the whole point of a proto-chain is to trade stakes in future DACs in that business sector.
Now fast forward to a time far in the future, maybe August, when somebody wants to launch a competing EvenMoreLuckyCasino. What is their best strategy?
Do they take a snapshot of the current LTS chain to appeal to all investors in this industry sector?
Or do they take a snapshot of their competitor's chain in an attempt to lure away all of its stakeholders?
Now imagine a short time later when there are hundreds of gaming DACs filling every possible ecological niche. Someone wants to enter the business - where do they take their snapshot?
This is a free market. They could do any combination. I am sure many things will be tried. What will the free market accept?
-
http://www.youtube.com/watch?v=yzCWGGG2gQc
-
Now fast forward to a time far in the future, maybe August, when somebody wants to launch a competing EvenMoreLuckyCasino. What is their best strategy?
Do they take a snapshot of the current LTS chain to appeal to all investors in this industry sector?
Or do they take a snapshot of their competitor's chain in an attempt to lure away all of its stakeholders?
Now imagine a short time later when there are hundreds of gaming DACs filling every possible ecological niche. Someone wants to enter the business - where do they take their snapshot?
This is a free market. They could do any combination. I am sure many things will be tried. What will the free market accept?
Great point! +5%
This makes me even more excited about the success of forks 8)
-
thanks，daniel and stan，things get more interesting now.
one more doubt：will all the lotto dacs use the same snapshot taken at specific time or the individual third party launched lotto dacs use different snapshots taken at different time ？
Great question!
Let's think this through together:
Initially there's a snapshot for BitSharesLOTTO and all PTS/AGS holders now have a new kind of coin in their wallets. It works just like PTS, only focused exclusively on interest in future gaming DACs.
Now, somebody who doesn't like the gaming business sector for any number of valid reasons, sells his LTS to someone who sees robotically honest gaming as the investment of a lifetime.
Who should own the shares of the LuckyStrikeCasino DAC when it comes out? Should it be the initial LTS snapshot or a snapshot of the latest block in the LTS chain?
Obviously, it should be the latest block since the whole point of a proto-chain is to trade stakes in future DACs in that business sector.
Now fast forward to a time far in the future, maybe August, when somebody wants to launch a competing EvenMoreLuckyCasino. What is their best strategy?
Do they take a snapshot of the current LTS chain to appeal to all investors in this industry sector?
Or do they take a snapshot of their competitor's chain in an attempt to lure away all of its stakeholders?
Now imagine a short time later when there are hundreds of gaming DACs filling every possible ecological niche. Someone wants to enter the business - where do they take their snapshot?
This is a free market. They could do any combination. I am sure many things will be tried. What will the free market accept?
i just had a feeling the whole bts project is not as simple as i frist thought. but i do think i should offer my suggestion, which is keep things simple. it's human nature that ppl like things to be simple and straight forward. i really sense a lot complications going on with bts right now.
bts me is good, but is it enough or there are more complications to come?
a example between simple and complication is just like how our memory system works with psycho nerves, prone to remember easy things, resistence to remember complex elemets.
hope stan and bytemaster consider my little thoughts
:)
-
thanks，daniel and stan，things get more interesting now.
one more doubt：will all the lotto dacs use the same snapshot taken at specific time or the individual third party launched lotto dacs use different snapshots taken at different time ？
Great question!
Let's think this through together:
Initially there's a snapshot for BitSharesLOTTO and all PTS/AGS holders now have a new kind of coin in their wallets. It works just like PTS, only focused exclusively on interest in future gaming DACs.
Now, somebody who doesn't like the gaming business sector for any number of valid reasons, sells his LTS to someone who sees robotically honest gaming as the investment of a lifetime.
Who should own the shares of the LuckyStrikeCasino DAC when it comes out? Should it be the initial LTS snapshot or a snapshot of the latest block in the LTS chain?
Obviously, it should be the latest block since the whole point of a proto-chain is to trade stakes in future DACs in that business sector.
Now fast forward to a time far in the future, maybe August, when somebody wants to launch a competing EvenMoreLuckyCasino. What is their best strategy?
Do they take a snapshot of the current LTS chain to appeal to all investors in this industry sector?
Or do they take a snapshot of their competitor's chain in an attempt to lure away all of its stakeholders?
Now imagine a short time later when there are hundreds of gaming DACs filling every possible ecological niche. Someone wants to enter the business - where do they take their snapshot?
This is a free market. They could do any combination. I am sure many things will be tried. What will the free market accept?
i just had a feeling the whole bts project is not as simple as i frist thought. but i do think i should offer my suggestion, which is keep things simple. it's human nature that ppl like things to be simple and straight forward. i really sense a lot complications going on with bts right now.
bts me is good, but is it enough or there are more complications to come?
a example between simple and complication is just like how our memory system works with psycho nerves, prone to remember easy things, resistence to remember complex elemets.
hope stan and bytemaster consider my little thoughts
:)
"Keep it simple" is good advice. How do we keep "reimagining everything" simple?
:)
-
And then we have the future possibilities to combine several of these DACs to form the building blocks of other DACs.
One of my pet projects for over 20 years was trying to create a school/educational center without the inbuilt problems I encountered growing up (inflexibility, coercion, incompetence, preconceived static concepts, lack of oversight, power struggles, corruption etcetera). I've been trying ways for over 20 years to get rid of personal bias, corruption and power struggles in organizations, but was never more than partly successful.
I first thought that principles of opensource en Gnu(Linux) were the way forward, but I was not able to figure out or find practical examples of implementing those same principles with similar success outside of the realm of software. To be more precise I was unable to convince people of the viability of that approach.
To be fair to the opensource bazaar approach, my progress was primarily stopped because I had an accident and the following health and legal problems have shall we say distracted me a bit. Also there have been very interesting ventures in crowdsourcing and crowdfunding, but I still felt there were some essential parts missing. It wasn't until I encountered bitcoin and read about DAC(/O/X) that I finally realized what the missing links were and I really feel we're getting close to improving how we organize ourselves and how we do things. It's been a frustratingly long wait for me, but I've never felt as tantalizingly close to solutions as right now.
Even though bitcoin and initiatives like these from Invictus are only the first small steps for man, I'm finally seeing some light at the end of the tunnel, I now realize that I was getting quite depressed at the lack of progress I was witnessing. Even just seeing projects like this even if they might fail, they have given me back hope for the future and improved my life noticeably already.
So while I can empathize with the impatience wholeheartedly, I also appreciate the fact that Invictus is trying to do things right instead of doing a rush job.
-
So I now have unit tests mining everything, charging fees, and validating. I need to check in with our developers that are implementing the P2P code to make sure that is on track.
Items left to do prior to making XTS liquid:
1) Integrate P2P code
2) Update RPC interface to match bitcoin's as closely as possible while abstracting it so that BitShares DNS / ME / Lotto can simply add a few new methods.
3) Update CLI interface to be extensible so that BitShares DNS / ME / Lotto can use it as well and just add a few new commands
4) Implement a large-scale simulation with 1000 wallets, with random initial balances, each making random transactions to other wallets with simulated mining
- goals: evaluate CPU usage
- validate that the blockchain can run for over a year without 'stalling' for lack of available coindays
- validate that unspent coins are charged proper fee (5%) after 1 year.
5) Integrate P2P code with large-scale simulation and real mining.
- validate network latency doesn't impact simulated behavior
- catch network bugs
- verify performance
Much work to do.. but steady progress is being made.
-
So I now have unit tests mining everything, charging fees, and validating. I need to check in with our developers that are implementing the P2P code to make sure that is on track.
Items left to do prior to making XTS liquid:
1) Integrate P2P code
2) Update RPC interface to match bitcoin's as closely as possible while abstracting it so that BitShares DNS / ME / Lotto can simply add a few new methods.
3) Update CLI interface to be extensible so that BitShares DNS / ME / Lotto can use it as well and just add a few new commands
4) Implement a large-scale simulation with 1000 wallets, with random initial balances, each making random transactions to other wallets with simulated mining
- goals: evaluate CPU usage
- validate that the blockchain can run for over a year without 'stalling' for lack of available coindays
- validate that unspent coins are charged proper fee (5%) after 1 year.
5) Integrate P2P code with large-scale simulation and real mining.
- validate network latency doesn't impact simulated behavior
- catch network bugs
- verify performance
Much work to do.. but steady progress is being made.
+5%
-
So I now have unit tests mining everything, charging fees, and validating. I need to check in with our developers that are implementing the P2P code to make sure that is on track.
Items left to do prior to making XTS liquid:
1) Integrate P2P code
2) Update RPC interface to match bitcoin's as closely as possible while abstracting it so that BitShares DNS / ME / Lotto can simply add a few new methods.
3) Update CLI interface to be extensible so that BitShares DNS / ME / Lotto can use it as well and just add a few new commands
4) Implement a large-scale simulation with 1000 wallets, with random initial balances, each making random transactions to other wallets with simulated mining
- goals: evaluate CPU usage
- validate that the blockchain can run for over a year without 'stalling' for lack of available coindays
- validate that unspent coins are charged proper fee (5%) after 1 year.
5) Integrate P2P code with large-scale simulation and real mining.
- validate network latency doesn't impact simulated behavior
- catch network bugs
- verify performance
Much work to do.. but steady progress is being made.
+5%
So what's the next, XT or Me?
-
:o thats helluva coding job +5%
-
Can you update the OP with status updates rather than just adding to the 500+ comments? Or just start a new thread, pin it and un-pin the old ones. The message gets convoluted in-between the on and off-topic replies.
As a matter of fact, you shouldn't even allow us to reply to your updates. Just let everyone start their own thread with their concerns or questions.
-
Can you update the OP with status updates rather than just adding to the 500+ comments? Or just start a new thread, pin it and un-pin the old ones. The message gets convoluted in-between the on and off-topic replies.
As a matter of fact, you shouldn't even allow us to reply to your updates. Just let everyone start their own thread with their concerns or questions.
+5%
-
Or you could change your setting to view last post first
-
So I now have unit tests mining everything, charging fees, and validating. I need to check in with our developers that are implementing the P2P code to make sure that is on track.
Items left to do prior to making XTS liquid:
1) Integrate P2P code
2) Update RPC interface to match bitcoin's as closely as possible while abstracting it so that BitShares DNS / ME / Lotto can simply add a few new methods.
3) Update CLI interface to be extensible so that BitShares DNS / ME / Lotto can use it as well and just add a few new commands
4) Implement a large-scale simulation with 1000 wallets, with random initial balances, each making random transactions to other wallets with simulated mining
- goals: evaluate CPU usage
- validate that the blockchain can run for over a year without 'stalling' for lack of available coindays
- validate that unspent coins are charged proper fee (5%) after 1 year.
5) Integrate P2P code with large-scale simulation and real mining.
- validate network latency doesn't impact simulated behavior
- catch network bugs
- verify performance
Much work to do.. but steady progress is being made.
+5%
So what's the next, XT or Me?
If you read recent posts, it sounds like Me may come first, since it provides a way to test one or two of the dimensions that will be offered in the more complex XT. But let's just let them do their job and not ask for daily updates. They need to focus their time and efforts creating this. The lower maintenance we are in the next few weeks, the more progress we will see from the developers.
-
Hm .. maybe I missed that but don't you necessarily need to launch keyhotee before bts-x as you wanted to distribute some btsx to the keyhotee founders?
-
Hm .. maybe I missed that but don't you necessarily need to launch keyhotee before bts-x as you wanted to distribute some btsx to the keyhotee founders?
They just need to finish founder registration
-
Can you update the OP with status updates rather than just adding to the 500+ comments? Or just start a new thread, pin it and un-pin the old ones. The message gets convoluted in-between the on and off-topic replies.
As a matter of fact, you shouldn't even allow us to reply to your updates. Just let everyone start their own thread with their concerns or questions.
+1
At least update the original/first post, so everyone doesn't have to dig through all this every week to find out what is going on.
Come on, put some effort into making this easier on supporters.
-
Can you update the OP with status updates rather than just adding to the 500+ comments? Or just start a new thread, pin it and un-pin the old ones. The message gets convoluted in-between the on and off-topic replies.
As a matter of fact, you shouldn't even allow us to reply to your updates. Just let everyone start their own thread with their concerns or questions.
+1
At least update the original/first post, so everyone doesn't have to dig through all this every week to find out what is going on.
Come on, put some effort into making this easier on supporters.
Really? Entitled much?
We get daily progress updates from the lead dev on the project. Let's be thankful for the wealth of information we already get and not complain about the updates' formatting...
Sent from my SCH-S720C using Tapatalk 2
-
Can you update the OP with status updates rather than just adding to the 500+ comments? Or just start a new thread, pin it and un-pin the old ones. The message gets convoluted in-between the on and off-topic replies.
As a matter of fact, you shouldn't even allow us to reply to your updates. Just let everyone start their own thread with their concerns or questions.
+1
At least update the original/first post, so everyone doesn't have to dig through all this every week to find out what is going on.
Come on, put some effort into making this easier on supporters.
Really? Entitled much?
We get daily progress updates from the lead dev on the project. Let's be thankful for the wealth of information we already get and not complain about the updates' formatting...
Sent from my SCH-S720C using Tapatalk 2
Agree. Being able to comment on each and give feedback is valueable. And the first post would get looooooooong..
-
So I now have unit tests mining everything, charging fees, and validating. I need to check in with our developers that are implementing the P2P code to make sure that is on track.
Items left to do prior to making XTS liquid:
1) Integrate P2P code
2) Update RPC interface to match bitcoin's as closely as possible while abstracting it so that BitShares DNS / ME / Lotto can simply add a few new methods.
3) Update CLI interface to be extensible so that BitShares DNS / ME / Lotto can use it as well and just add a few new commands
4) Implement a large-scale simulation with 1000 wallets, with random initial balances, each making random transactions to other wallets with simulated mining
- goals: evaluate CPU usage
- validate that the blockchain can run for over a year without 'stalling' for lack of available coindays
- validate that unspent coins are charged proper fee (5%) after 1 year.
5) Integrate P2P code with large-scale simulation and real mining.
- validate network latency doesn't impact simulated behavior
- catch network bugs
- verify performance
Much work to do.. but steady progress is being made.
+5%
So what's the next, XT or Me?
If you read recent posts, it sounds like Me may come first, since it provides a way to test one or two of the dimensions that will be offered in the more complex XT. But let's just let them do their job and not ask for daily updates. They need to focus their time and efforts creating this. The lower maintenance we are in the next few weeks, the more progress we will see from the developers.
As a developer for, well, longer than I want to admit, I concur that interruptions are the killer of progress. It's amazing that these guys update everyone as often as I see in the short time I've been lurking here.
-
Can you update the OP with status updates rather than just adding to the 500+ comments? Or just start a new thread, pin it and un-pin the old ones. The message gets convoluted in-between the on and off-topic replies.
As a matter of fact, you shouldn't even allow us to reply to your updates. Just let everyone start their own thread with their concerns or questions.
+1
At least update the original/first post, so everyone doesn't have to dig through all this every week to find out what is going on.
Come on, put some effort into making this easier on supporters.
Really? Entitled much?
We get daily progress updates from the lead dev on the project. Let's be thankful for the wealth of information we already get and not complain about the updates' formatting...
Sent from my SCH-S720C using Tapatalk 2
Asking for organization of updates so investors and newbies can easily see what's happening is asking too much? How dare I?
Can you update the OP with status updates rather than just adding to the 500+ comments? Or just start a new thread, pin it and un-pin the old ones. The message gets convoluted in-between the on and off-topic replies.
As a matter of fact, you shouldn't even allow us to reply to your updates. Just let everyone start their own thread with their concerns or questions.
+1
At least update the original/first post, so everyone doesn't have to dig through all this every week to find out what is going on.
Come on, put some effort into making this easier on supporters.
Really? Entitled much?
We get daily progress updates from the lead dev on the project. Let's be thankful for the wealth of information we already get and not complain about the updates' formatting...
Sent from my SCH-S720C using Tapatalk 2
Agree. Being able to comment on each and give feedback is valueable. And the first post would get looooooooong..
Would it get 500 posts looooooooooong?
I think this back and forth proves one of my points. Convoluted. Now everyone else has to sift through these last few posts hoping bytemaster didn't leave an Easter egg within. It's more professional to be upfront and visible with the updates that usually contain vital investor information. I found out that BTS-XT is delayed and may be released following the release of ME and DNS in another boards thread. I come here and there is now official update. Is this even true? That is pretty vital information that should be upfront for all to see in an "Update Thread". Originally 2015 was the targeted release, then mid to late March 2014, now we would be lucky to have it by end of June. Are these just W.A.G's? Is that where we are?
All I'm saying is, an official update is in order if the plan has been altered or changed.
-
It would be nice to have a separate subforum for project updates, a separate thread in said subforum for each update, and a locked sticky containing current information ONLY.
-
Or you could change your setting to view last post first
+5% +5% +5%. Bless you Sir
-
Or you could change your setting to view last post first
+5% +5% +5%. Bless you Sir
That worked well as it took me to your blessed post. Let's try to think things through before we post.
I want an official update. I don't want to read about your blessings, or my concerns over updates, or clout's thoughts, or anyone else's questions in the "update thread". All of that should be in other threads started for their own reason, not in the "update thread". I continue to post here because it proves my point. Others and you will have to sift through this BS to find the updates.
-
Can you update the OP with status updates rather than just adding to the 500+ comments? Or just start a new thread, pin it and un-pin the old ones. The message gets convoluted in-between the on and off-topic replies.
As a matter of fact, you shouldn't even allow us to reply to your updates. Just let everyone start their own thread with their concerns or questions.
+1
At least update the original/first post, so everyone doesn't have to dig through all this every week to find out what is going on.
Come on, put some effort into making this easier on supporters.
Really? Entitled much?
We get daily progress updates from the lead dev on the project. Let's be thankful for the wealth of information we already get and not complain about the updates' formatting...
Sent from my SCH-S720C using Tapatalk 2
Asking for organization of updates so investors and newbies can easily see what's happening is asking too much? How dare I?
Can you update the OP with status updates rather than just adding to the 500+ comments? Or just start a new thread, pin it and un-pin the old ones. The message gets convoluted in-between the on and off-topic replies.
As a matter of fact, you shouldn't even allow us to reply to your updates. Just let everyone start their own thread with their concerns or questions.
+1
At least update the original/first post, so everyone doesn't have to dig through all this every week to find out what is going on.
Come on, put some effort into making this easier on supporters.
Really? Entitled much?
We get daily progress updates from the lead dev on the project. Let's be thankful for the wealth of information we already get and not complain about the updates' formatting...
Sent from my SCH-S720C using Tapatalk 2
Agree. Being able to comment on each and give feedback is valueable. And the first post would get looooooooong..
Would it get 500 posts looooooooooong?
I think this back and forth proves one of my points. Convoluted. Now everyone else has to sift through these last few posts hoping bytemaster didn't leave an Easter egg within. It's more professional to be upfront and visible with the updates that usually contain vital investor information. I found out that BTS-XT is delayed and may be released following the release of ME and DNS in another boards thread. I come here and there is now official update. Is this even true? That is pretty vital information that should be upfront for all to see in an "Update Thread". Originally 2015 was the targeted release, then mid to late March 2014, now we would be lucky to have it by end of June. Are these just W.A.G's? Is that where we are?
All I'm saying is, an official update is in order if the plan has been altered or changed.
what if bts-me releasing is delayed after the snapshot just like bts-x. what happens than.
-
Can you update the OP with status updates rather than just adding to the 500+ comments? Or just start a new thread, pin it and un-pin the old ones. The message gets convoluted in-between the on and off-topic replies.
As a matter of fact, you shouldn't even allow us to reply to your updates. Just let everyone start their own thread with their concerns or questions.
+1
At least update the original/first post, so everyone doesn't have to dig through all this every week to find out what is going on.
Come on, put some effort into making this easier on supporters.
Really? Entitled much?
We get daily progress updates from the lead dev on the project. Let's be thankful for the wealth of information we already get and not complain about the updates' formatting...
Sent from my SCH-S720C using Tapatalk 2
Asking for organization of updates so investors and newbies can easily see what's happening is asking too much? How dare I?
Can you update the OP with status updates rather than just adding to the 500+ comments? Or just start a new thread, pin it and un-pin the old ones. The message gets convoluted in-between the on and off-topic replies.
As a matter of fact, you shouldn't even allow us to reply to your updates. Just let everyone start their own thread with their concerns or questions.
+1
At least update the original/first post, so everyone doesn't have to dig through all this every week to find out what is going on.
Come on, put some effort into making this easier on supporters.
Really? Entitled much?
We get daily progress updates from the lead dev on the project. Let's be thankful for the wealth of information we already get and not complain about the updates' formatting...
Sent from my SCH-S720C using Tapatalk 2
Agree. Being able to comment on each and give feedback is valueable. And the first post would get looooooooong..
Would it get 500 posts looooooooooong?
I think this back and forth proves one of my points. Convoluted. Now everyone else has to sift through these last few posts hoping bytemaster didn't leave an Easter egg within. It's more professional to be upfront and visible with the updates that usually contain vital investor information. I found out that BTS-XT is delayed and may be released following the release of ME and DNS in another boards thread. I come here and there is now official update. Is this even true? That is pretty vital information that should be upfront for all to see in an "Update Thread". Originally 2015 was the targeted release, then mid to late March 2014, now we would be lucky to have it by end of June. Are these just W.A.G's? Is that where we are?
All I'm saying is, an official update is in order if the plan has been altered or changed.
what if bts-me releasing is delayed after the snapshot just like bts-x. what happens than.
We will not announce the snapshot until the software is already ready. Not going to make that mistake again.
-
When BTS release is expected ? 'cause we just have almost worthless PTS at the moment....
-
Worthless? Buddy, PM me and I'll buy all the PTS you've got. Have a little patience with this development team; they're working their asses off. Your PTS are going to be worth a mint, but not by next week.
-
Worthless? Buddy, PM me and I'll buy all the PTS you've got. Have a little patience with this development team; they're working their asses off. Your PTS are going to be worth a mint, but not by next week.
+1
Simple minds want speed at any price. Greater minds prefer things being done right, and have patience.
-
Worthless? Buddy, PM me and I'll buy all the PTS you've got. Have a little patience with this development team; they're working their asses off. Your PTS are going to be worth a mint, but not by next week.
if it is worthless, he should give you away for free
^ ^
-
Worthless? Buddy, PM me and I'll buy all the PTS you've got. Have a little patience with this development team; they're working their asses off. Your PTS are going to be worth a mint, but not by next week.
+1
Simple minds want speed at any price. Greater minds prefer things being done right, and have patience.
5%
-
Worthless? Buddy, PM me and I'll buy all the PTS you've got. Have a little patience with this development team; they're working their asses off. Your PTS are going to be worth a mint, but not by next week.
:D
+5%
-
Worthless? Buddy, PM me and I'll buy all the PTS you've got. Have a little patience with this development team; they're working their asses off. Your PTS are going to be worth a mint, but not by next week.
if it is worthless, he should give you away for free
^ ^
Unfortunately, he hasn't given them to me yet. I had to go on Cryptsy and buy some more PTS myself.
-
cause we just have almost worthless PTS at the moment....
:o. Seriously ? Or:
A. "fresh troll droppings", an oxymoron
B. "Bear meat", always a welcome treat
C. "Noob Turrets", harmless acute and curable condition
-
Worthless? Buddy, PM me and I'll buy all the PTS you've got. Have a little patience with this development team; they're working their asses off. Your PTS are going to be worth a mint, but not by next week.
I have 1000, how about .012 BTC each?
-
Worthless? Buddy, PM me and I'll buy all the PTS you've got. Have a little patience with this development team; they're working their asses off. Your PTS are going to be worth a mint, but not by next week.
+1
Simple minds want speed at any price. Greater minds prefer things being done right, and have patience.
Speed is important as well. That being said what we need is speed and quality NOT one at the expense of the other. I mean if the release of something is going to be delayed for weeks or months like Keyhotee than you might as well extend the founding period as well. Perhaps the snapshot date shouldn't have been on the 28th of February.
It also makes you look good if you say you'll have something done by a certain deadline and you follow through, plus it shows leadership.
-
Worthless? Buddy, PM me and I'll buy all the PTS you've got. Have a little patience with this development team; they're working their asses off. Your PTS are going to be worth a mint, but not by next week.
I have 1000, how about .012 BTC each?
Thanks for the offer. I'll send you a private message.
-
Worthless? Buddy, PM me and I'll buy all the PTS you've got. Have a little patience with this development team; they're working their asses off. Your PTS are going to be worth a mint, but not by next week.
+1
Simple minds want speed at any price. Greater minds prefer things being done right, and have patience.
Speed is important as well. That being said what we need is speed and quality NOT one at the expense of the other. I mean if the release of something is going to be delayed for weeks or months like Keyhotee than you might as well extend the founding period as well. Perhaps the snapshot date shouldn't have been on the 28th of February.
It also makes you look good if you say you'll have something done by a certain deadline and you follow through, plus it shows leadership.
Alas, we promised 2-weeks notice, so that means the snapshot had to happen 2 weeks before the earliest possible date.
The alternative we plan to use in the future is to wait until latest possible date (when testing is totally complete), and then wait two more weeks before we can launch.
This is also why we no longer release estimates or target dates. We'd like to share our hopes and goals, but that has proven to be counterproductive.
Keeping everybody equally unhappy is always an interesting compromise. :)
-
Alas, we promised 2-weeks notice, so that means the snapshot had to happen 2 weeks before the earliest possible date.
The alternative we plan to use in the future is to wait until latest possible date (when testing is totally complete), and then wait two more weeks before we can launch.
This is also why we no longer release estimates or target dates. We'd like to share our hopes and goals, but that has proven to be counterproductive.
Keeping everybody equally unhappy is always an interesting compromise. :)
Stan,
It's not difficult to understand the community takes you guys' words as official decisions ignoring your signatures especially when it comes to the dates.
Like what you said on Mar 16th as shown below. People may think, "What's wrong with I3, it's weekend now, where is the newsletter, delay again?"
Words are words, promises and promises, but what I really care about is what you deliver.
See my replies in bold. All of this is the subject of this month's newsletter to be released early this week.
-
Please see toast's DNS Update thread on how an update thread is supposed to work.
https://bitsharestalk.org/index.php?topic=3655.0
Unpin this thread, start a new pinned update thread and lock it from comments. It's simple, organized, and makes your progress and intentions visible.
-
Please see toast's DNS Update thread on how an update thread is supposed to work.
https://bitsharestalk.org/index.php?topic=3655.0
Unpin this thread, start a new pinned update thread and lock it from comments. It's simple, organized, and makes your progress and intentions visible.
(http://s2.quickmeme.com/img/3e/3eb1f00ad3753bddd99401088d19ad22bf5469a961ff0fc20e4ec469263eb994.jpg)
https://bitsharestalk.org/index.php?topic=3812.msg47872#msg47872
-
(http://s2.quickmeme.com/img/3e/3eb1f00ad3753bddd99401088d19ad22bf5469a961ff0fc20e4ec469263eb994.jpg)
https://bitsharestalk.org/index.php?topic=3812.msg47872#msg47872
Lol, hopefully devs won't encounter any suprise Rodents Of Unusual Size, it could cause another delay.
-
Please see toast's DNS Update thread on how an update thread is supposed to work.
https://bitsharestalk.org/index.php?topic=3655.0
Unpin this thread, start a new pinned update thread and lock it from comments. It's simple, organized, and makes your progress and intentions visible.
(http://s2.quickmeme.com/img/3e/3eb1f00ad3753bddd99401088d19ad22bf5469a961ff0fc20e4ec469263eb994.jpg)
https://bitsharestalk.org/index.php?topic=3812.msg47872#msg47872
+5%
You rock.
-
Hi Dan,
Thank you very much for the new BTS X update you have posed here: https://bitsharestalk.org/index.php?topic=3812.0
As being monitor the thread for several weeks, I saw many features of the new BTS X, they are very interesting. I was wondering that you can have some latest screenshots of the app for us. That would be great to fulfill our expectations :P
-
Hi Dan,
Thank you very much for the new BTS X update you have posed here: https://bitsharestalk.org/index.php?topic=3812.0
As being monitor the thread for several weeks, I saw many features of the new BTS X, they are very interesting. I was wondering that you can have some latest screenshots of the app for us. That would be great to fulfill our expectations :P
+5% +5% full of curiosity :D
-
How much will be launched within the next month?
-
Patience everyone 8) it will be worth the wait.
-
Patience everyone 8) it will be worth the wait.
+5% big things will come :)
-
Worthless? Buddy, PM me and I'll buy all the PTS you've got. Have a little patience with this development team; they're working their asses off. Your PTS are going to be worth a mint, but not by next week.
+1
Simple minds want speed at any price. Greater minds prefer things being done right, and have patience.
Speed is important as well. That being said what we need is speed and quality NOT one at the expense of the other. I mean if the release of something is going to be delayed for weeks or months like Keyhotee than you might as well extend the founding period as well. Perhaps the snapshot date shouldn't have been on the 28th of February.
It also makes you look good if you say you'll have something done by a certain deadline and you follow through, plus it shows leadership.
Alas, we promised 2-weeks notice, so that means the snapshot had to happen 2 weeks before the earliest possible date.
The alternative we plan to use in the future is to wait until latest possible date (when testing is totally complete), and then wait two more weeks before we can launch.
This is also why we no longer release estimates or target dates. We'd like to share our hopes and goals, but that has proven to be counterproductive.
Keeping everybody equally unhappy is always an interesting compromise. :)
+5%
I was just reading an article about Counterparty being upset over how the core Bitcoin developers slashed OP_RETURN 80 bytes down to 40 bytes of extra data on the Bitcoin blockchain. It just goes to show that Bitshares really has no competitor in this space. I remember BM talking about how the MSC approach of doing things on top of the Bitcoin blockchain was flawed because of blockchain bloat and here we are and that is probably what is happening.
So despite the fact that we(I) may get a bit impatient you guys are ahead of the pack. You're on to something big here and we(I) will continue to invest into the AGS fund.
-
Amen. I was thinking the same thing when I read that.
-
Amen. I was thinking the same thing when I read that.
Can I get a link?
-
It just goes to show that Bitshares really has no competitor in this space.
*cough* NXT *cough*
(Don't have any NXT; missed out on the initial IPO and it was always a risk to buy later with massive holders out there who can cash out anytime with massive profits.)
-
Amen. I was thinking the same thing when I read that.
Can I get a link?
This is the link
http://www.coindesk.com/developers-battle-bitcoin-block-chain/
-
Amen. I was thinking the same thing when I read that.
Can I get a link?
This is the link
http://www.coindesk.com/developers-battle-bitcoin-block-chain/
I think that article was only written as an opportunity to bash Bitcoin and plug Ethereum. I don't see how it would make sense otherwise to even mention a completely irrelevant "solution", particularly if the quoted persons say the same thing. (Their Disqus-moderator also didn't take to kindly to me pointing that out, which makes me doubt their objectiveness even more.)
I've read parts of the discussion on the forums and it seems the issue is one that could affect everyone in this space. They did not communicate or involve the developers of bitcoin in their plans and then act a bit like spoiled divas. I think this might be because of a cultural problem of being unfamiliar with how open-source projects and development works.
Open-source might be open and free, but that doesn't mean you don't have to make your own sandwich. Counterparty (don't know if mastercoin was the same) are complaining they are not being catered to and project themselves as the end all be all of Bitcoin and all bitcoiners should carry the burden of their plans, no questions asked. As far as I could tell, the bitcoin devs were not unwilling to develop a more elegant solution instead of the current exploit-hack and even proposed a few temporary workarounds until such a solution was found, but judging from the reactions I doubt we'll see a BIP anytime soon from the Counterparty and Mastercoin teams.
In short I think we should be prepared for similar cultural/perspective problems over here as well.
-
but bitshares doesn't use the bitcoin blockchain.
-
but bitshares doesn't use the bitcoin blockchain.
Don't know if you were commenting on my post, but for the moment I assume you did.
The argument arose, because people were trying to build stuff on top of bitcoin, but did not actually inform or involve the bitcoin-devs in their projects, neither did they propose solutions or improvements via BIPs. Something similar could happen to bitshares as well, where people just build on to of bitshares in isolation and suddenly throw a fit when a bugfix seems to have fixed an exploit they were relying on for their project.
Spinning this as bitcoin-devs being "against" them is a little far fetched in my opinion, but that does not mean that the same false arguments could not be directed at bitshares-devs for similarly strange reasons (because of unfamiliarity with the open-source way of doing things).
-
Don't know if you were commenting on my post, but for the moment I assume you did.
The argument arose, because people were trying to build stuff on top of bitcoin, but did not actually inform or involve the bitcoin-devs in their projects, neither did they propose solutions or improvements via BIPs. Something similar could happen to bitshares as well, where people just build on to of bitshares in isolation and suddenly throw a fit when a bugfix seems to have fixed an exploit they were relying on for their project.
Ah, thanks for the clarification.
-
but bitshares doesn't use the bitcoin blockchain.
Don't know if you were commenting on my post, but for the moment I assume you did.
The argument arose, because people were trying to build stuff on top of bitcoin, but did not actually inform or involve the bitcoin-devs in their projects, neither did they propose solutions or improvements via BIPs. Something similar could happen to bitshares as well, where people just build on to of bitshares in isolation and suddenly throw a fit when a bugfix seems to have fixed an exploit they were relying on for their project.
Spinning this as bitcoin-devs being "against" them is a little far fetched in my opinion, but that does not mean that the same false arguments could not be directed at bitshares-devs for similarly strange reasons (because of unfamiliarity with the open-source way of doing things).
The critical difference is that XCP depends on the bitcoin blockchain and cannot "ignore" an update. Each DAC developer should of course be careful to make sure they don't pull in breaking changes...
-
The critical difference is that XCP depends on the bitcoin blockchain and cannot "ignore" an update. Each DAC developer should of course be careful to make sure they don't pull in breaking changes...
Still should any of the bitshare-projects achieve even partly the current popularity of bitcoin, then similar problems might occur when updating the software and 3-rd party software that's running on top gets broken.
Might be a ways off in the future, but the more free-market voting, concensus style of working might come as a shock to people new to the Bazaar way (http://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar) of doing things.
-
BitShares has no room for 3rd parties to piggy back on our chain because we don't use scripts that can contain arbitrary data. You would have to embed the data in the addresses in the blockchain. We also charge transaction fees on a per-byte basis so this would become very expensive to require at least 256 bytes of data for 20 bytes of payload, especially when there is a minimum output amount.
-
Piggy-backing is not the only way for 3rd parties to interface with the protocol though, while at the same time not communicating or cooperating with "core-devs". Similar problems could arise if those 3rd parties build on the use of bitsharesX, not that unfathomable should it become popular enough.
Demanding that everyone who wants to write software to work with the bitsharesX-protocol to be open-source as well, might not be possible. However I don't think that it would hurt to mention that that does not exclude them from the open-source process or at least warn people of the potential hazards that custom closed source solutions might have, like for example mtGox.
It might be perfectly obvious for everyone here that open-source is the only secure and transparent way to go and that nobody here would even consider using blackbox closed-source software for anything valuable. That however does not change the fact that the majority of desktop/tablet/phone-users still have no idea what open-source even means or why it's important and that includes a significant amount of software-developers.
-
So now that NYC is over, when BTSX will be make liquid?
-
So now that NYC is over, when BTSX will be make liquid?
As soon as possible.
We are taking the long train home tonight.
-
So now that NYC is over, when BTSX will be make liquid?
As soon as possible.
We are taking the long train home tonight.
Get home safely ;)
-
Is dan still working on BitsharesX? His last commit was almost 2 weeks ago...
-
Prep for conference plus travel plus website has taken a lot of my time. I was coding on the train. Also a lot of time was spent designing dpos.
Sent from my iPhone using Tapatalk (http://tapatalk.com/m?id=1)
-
Is dan still working on BitsharesX? His last commit was almost 2 weeks ago...
There is a new sticky post to track the development status:
https://bitsharestalk.org/index.php?topic=3812.0
-
Is dan still working on BitsharesX? His last commit was almost 2 weeks ago...
There is a new sticky post to track the development status:
https://bitsharestalk.org/index.php?topic=3812.0
yeah. I know. And from that post and the commits on github it looks like he is just delegating work for it for now.. Maybe it is too much for him at the moment. With all these DAC's and conferences. I just wish he would finish this DAC first. It almost looks like he lost confidence in the success of bitsharesX. I hope this is not the case..
-
No lost confidence. Just had to solve pos first.
Sent from my iPhone using Tapatalk (http://tapatalk.com/m?id=1)
-
No lost confidence. Just had to solve pos first.
Has this been solved now wrt coding?
-
No lost confidence. Just had to solve pos first.
Has this been solved now wrt coding?
Yes, I released a white paper on DPOS last week and have implemented a large part of it and will be testing it in the days ahead. Resolving the security model in a way that one can thoroughly understand and prove is secure was a major challenge. You can follow discussions on this forum where about a half dozen variations / iterations where vetted and found wanting... Let me list the evolution:
1) Mining with Momentum... tossed due to centralization and non profitability
2) Transactions as Proof of Stake white paper (Nov 28th, 2013) adjusted mining difficulty by stake. Suffered from weakness on deciding who should produce the next block.
3) Ripple Consensus + TaPOS was the concept in January at the Miami event through Feb, but after attempted implementation we realized it had several deal breakers:
a) the unique node list was an invite-only group and a point of trust
b) the UNL was not compensated in any way
c) the bandwidth requirements / scalability were an issue
4) Fall back on a simple mining + TaPOS and various variations on equations for option 2. All of these variations suffered from many potential attacks and would require many confirmations. It became too complex to analyze. (Feb through March)
5) Single trustee which could be fired... the process was too manual but otherwise sound.
6) Delegated POS this solution has been reviewed, found to be decentralized, fast, and secure without ambiguity. We have finally resolved the issue.
In that time we also identified problems and found solutions to several market manipulation attacks. These need to be implemented, but then we should be good to go.
As you can see R&D is not predictable when you are at the bleeding edge of innovation and solving problems as they are discovered.
-
No lost confidence. Just had to solve pos first.
Has this been solved now wrt coding?
Yes, I released a white paper on DPOS last week and have implemented a large part of it and will be testing it in the days ahead. Resolving the security model in a way that one can thoroughly understand and prove is secure was a major challenge.
Actually that was the answer to my question (I had read up the DPOS whitepaper as soon as you posted it). Nice summary of the evolution, though. Can you do a similar one for market manipulation attacks?
-
“We are plain quiet folk and have no use for innovations.
Nasty disturbing uncomfortable things! Make you late for dinner!”
-- Bilbo, the Hobbit
(http://2.bp.blogspot.com/-z2_XigD9I0U/UNpe57TlDjI/AAAAAAAAAo0/OoVEkLJGUfI/s320/The-Hobbit-1024x1024.jpg)
-
No lost confidence. Just had to solve pos first.
Has this been solved now wrt coding?
Yes, I released a white paper on DPOS last week and have implemented a large part of it and will be testing it in the days ahead. Resolving the security model in a way that one can thoroughly understand and prove is secure was a major challenge. You can follow discussions on this forum where about a half dozen variations / iterations where vetted and found wanting... Let me list the evolution:
1) Mining with Momentum... tossed due to centralization and non profitability
2) Transactions as Proof of Stake white paper (Nov 28th, 2013) adjusted mining difficulty by stake. Suffered from weakness on deciding who should produce the next block.
3) Ripple Consensus + TaPOS was the concept in January at the Miami event through Feb, but after attempted implementation we realized it had several deal breakers:
a) the unique node list was an invite-only group and a point of trust
b) the UNL was not compensated in any way
c) the bandwidth requirements / scalability were an issue
4) Fall back on a simple mining + TaPOS and various variations on equations for option 2. All of these variations suffered from many potential attacks and would require many confirmations. It became too complex to analyze. (Feb through March)
5) Single trustee which could be fired... the process was too manual but otherwise sound.
6) Delegated POS this solution has been reviewed, found to be decentralized, fast, and secure without ambiguity. We have finally resolved the issue.
In that time we also identified problems and found solutions to several market manipulation attacks. These need to be implemented, but then we should be good to go.
As you can see R&D is not predictable when you are at the bleeding edge of innovation and solving problems as they are discovered.
I am so proud of you! <3
You make everything better :)
-
No lost confidence. Just had to solve pos first.
Has this been solved now wrt coding?
Yes, I released a white paper on DPOS last week and have implemented a large part of it and will be testing it in the days ahead. Resolving the security model in a way that one can thoroughly understand and prove is secure was a major challenge. You can follow discussions on this forum where about a half dozen variations / iterations where vetted and found wanting... Let me list the evolution:
1) Mining with Momentum... tossed due to centralization and non profitability
2) Transactions as Proof of Stake white paper (Nov 28th, 2013) adjusted mining difficulty by stake. Suffered from weakness on deciding who should produce the next block.
3) Ripple Consensus + TaPOS was the concept in January at the Miami event through Feb, but after attempted implementation we realized it had several deal breakers:
a) the unique node list was an invite-only group and a point of trust
b) the UNL was not compensated in any way
c) the bandwidth requirements / scalability were an issue
4) Fall back on a simple mining + TaPOS and various variations on equations for option 2. All of these variations suffered from many potential attacks and would require many confirmations. It became too complex to analyze. (Feb through March)
5) Single trustee which could be fired... the process was too manual but otherwise sound.
6) Delegated POS this solution has been reviewed, found to be decentralized, fast, and secure without ambiguity. We have finally resolved the issue.
In that time we also identified problems and found solutions to several market manipulation attacks. These need to be implemented, but then we should be good to go.
As you can see R&D is not predictable when you are at the bleeding edge of innovation and solving problems as they are discovered.
I am so proud of you! <3
You make everything better :)
hahaha
Summary posts such as the one above (list the evolution) are important for providing the community with information on all that has been done. It functions as a good pacifier :)
-
No lost confidence. Just had to solve pos first.
Has this been solved now wrt coding?
Yes, I released a white paper on DPOS last week and have implemented a large part of it and will be testing it in the days ahead. Resolving the security model in a way that one can thoroughly understand and prove is secure was a major challenge. You can follow discussions on this forum where about a half dozen variations / iterations where vetted and found wanting... Let me list the evolution:
1) Mining with Momentum... tossed due to centralization and non profitability
2) Transactions as Proof of Stake white paper (Nov 28th, 2013) adjusted mining difficulty by stake. Suffered from weakness on deciding who should produce the next block.
3) Ripple Consensus + TaPOS was the concept in January at the Miami event through Feb, but after attempted implementation we realized it had several deal breakers:
a) the unique node list was an invite-only group and a point of trust
b) the UNL was not compensated in any way
c) the bandwidth requirements / scalability were an issue
4) Fall back on a simple mining + TaPOS and various variations on equations for option 2. All of these variations suffered from many potential attacks and would require many confirmations. It became too complex to analyze. (Feb through March)
5) Single trustee which could be fired... the process was too manual but otherwise sound.
6) Delegated POS this solution has been reviewed, found to be decentralized, fast, and secure without ambiguity. We have finally resolved the issue.
In that time we also identified problems and found solutions to several market manipulation attacks. These need to be implemented, but then we should be good to go.
As you can see R&D is not predictable when you are at the bleeding edge of innovation and solving problems as they are discovered.
this is cool
if nothing new should be added, can you guys finish the dpos blockchain and p2p network coding before you go to china next month?
-
No lost confidence. Just had to solve pos first.
Has this been solved now wrt coding?
Yes, I released a white paper on DPOS last week and have implemented a large part of it and will be testing it in the days ahead. Resolving the security model in a way that one can thoroughly understand and prove is secure was a major challenge. You can follow discussions on this forum where about a half dozen variations / iterations where vetted and found wanting... Let me list the evolution:
1) Mining with Momentum... tossed due to centralization and non profitability
2) Transactions as Proof of Stake white paper (Nov 28th, 2013) adjusted mining difficulty by stake. Suffered from weakness on deciding who should produce the next block.
3) Ripple Consensus + TaPOS was the concept in January at the Miami event through Feb, but after attempted implementation we realized it had several deal breakers:
a) the unique node list was an invite-only group and a point of trust
b) the UNL was not compensated in any way
c) the bandwidth requirements / scalability were an issue
4) Fall back on a simple mining + TaPOS and various variations on equations for option 2. All of these variations suffered from many potential attacks and would require many confirmations. It became too complex to analyze. (Feb through March)
5) Single trustee which could be fired... the process was too manual but otherwise sound.
6) Delegated POS this solution has been reviewed, found to be decentralized, fast, and secure without ambiguity. We have finally resolved the issue.
In that time we also identified problems and found solutions to several market manipulation attacks. These need to be implemented, but then we should be good to go.
As you can see R&D is not predictable when you are at the bleeding edge of innovation and solving problems as they are discovered.
Very nice paper (http://107.170.30.182/security/delegated-proof-of-stake.php)...
Although I must admit that still needs some visual explanation for broader public understanding. It also would help consolidate by commenting it (visual drawings).
Things like this necessarily have to change/adapt with time essence... we face edge developing ideas that get reactions... when implemented. So documenting them is a MUST. Consolidating their stable audience.. also. Otherwise developing something that only we understand about.. and where the focus is for everyone to adopt.. will be worth nothing.. I understand that time races against your availability, but felt right to me in pointing out this.
This is just my way of extrapolating the effect of knowledge specialization. That we do require as a source for developing new core ideas.. but that with time if canalized to the right direction can potentially create a positive diversion.. for mass adoption.
-
So, what's next and when ? :-\
-
Bytemaster, just a polite request, at the time of wallet release please add carefully thought through instructions for enabling/activating POS within the wallet environment, if this is needed. I've seen this implemented quite variably with lots of alt coins. No reason to doubt you won't do this, but please offer a bounty though if appropriate if time is of the essence.
I am guessing you have maybe made POS automatic?
-
Pos is automatic.
Sent from my iPhone using Tapatalk (http://tapatalk.com/m?id=1)
-
So, what's next and when ? :-\
+1
-
I have been putting together more detailed algorithm documentation here:
http://bitshares.org/documentation/group__dpos.html
If you see anything that needs correction or clarification let me know... the webpage is generated from the following doxygen file:
https://github.com/BitShares/bitshares_toolkit/blob/master/libraries/blockchain/dpos.dox
As far as when...
(http://burneylawfirm.com/goodtime.png)
Eric & I are working closely to get the P2P code integrated with the blockchain and DPOS. We have been making great progress and the links above show the design / algorithm documentation. This serves as our checklist and points that we must test.
-
(http://static.emedco.com/media/catalog/product/Workplace-Posters-HRP32-LAM-ba.gif)
-
What about the GUI ?
-
Are there anybody coding the GUI, or maybe i can do it.
-
Are there anybody coding the GUI, or maybe i can do it.
Yes, someone has already been working on it.
https://bitsharestalk.org/index.php?topic=1890.msg40688#msg40688
-
2 months, any progress on GUI?
-
Nathan is in school and has been unable to work on GUI much. :(.
Sent from my iPhone using Tapatalk (http://tapatalk.com/m?id=1)
-
Nathan is in school and has been unable to work on GUI much. :(.
Sent from my iPhone using Tapatalk (http://tapatalk.com/m?id=1)
I will see what i can do.
-
Nathan is in school and has been unable to work on GUI much. :(.
Sent from my iPhone using Tapatalk (http://tapatalk.com/m?id=1)
I will see what i can do.
If i can assist, maybe i can help, let me know! Can provide graphical stuff if needed
-
When can we expect the test-test-... wallet...?????
WE WAIT FOR A LONG LONG TIME.
-
Nathan is in school and has been unable to work on GUI much. :(.
Sent from my iPhone using Tapatalk (http://tapatalk.com/m?id=1)
I will see what i can do.
If i can assist, maybe i can help, let me know! Can provide graphical stuff if needed
you have my vote!
the gui thing is quite important，why let a part-part time in school guy to finish that?no offense to nathan but it really was like 我裤子都脱了你就给我看这个？
-
you have my vote!
the gui thing is quite important，why let a part-part time in school guy to finish that?no offense to nathan but it really was like 我裤子都脱了你就给我看这个？
[/quote]
这才是神吐槽！ +5%
-
i also don't understand why let a part time student work on such crucial task, we invested a lot of money,but the progress is quite disappointed so far.
-
i also don't understand why let a part time student work on such crucial task, we invested a lot of money,but the progress is quite disappointed so far.
+5% +5% +5% +5% +5% +5% +5% +5% +5% +5% +5% +5% +5% +5% +5% +5% +5% +5% +5% +5% +5% +5% +5% +5%
-
4700+btc，300,000+pts……
student，part-time……
-
I3 gathered tons of money from investors,then what?I CAN'T SEE ANY SOLID PRODUCT RIGHT NOW.
DELAY AND DELAY AND DELAY AND DELAY.
infinite DELAY.. >:( >:( >:( >:( >:(
-
I3 gathered tons of money from investors,then what?I CAN'T SEE ANY SOLID PRODUCT RIGHT NOW.
DELAY AND DELAY AND DELAY AND DELAY.
infinite DELAY.. >:( >:( >:( >:( >:(
TIL that 1 month=Infinite.
Sent from my SCH-S720C using Tapatalk 2
-
We hope 3I consider the method of organize the project.
Module the project, employ programmers, and focus on the project rather than trivial things.
-
We hope 3I consider the method of organize the project.
Module the project, employ programmers, and focus on the project rather than trivial things.
+5%
-
Warning suwoder, 表达已经可以，再爆粗口就封号了。
-
I thought I would update everyone on our GUI development. We have been working with a bright developer named Nathan who has put together a large amount of a basic GUI for the BTS wallet. He still has some work to do, but his progress is still significant.
(http://the-iland.net/static/images/BTSX.png)
It isn't quite the interface I would have designed, but is certainly a step up from the command line and we will enhance it as time progresses.
this UI is invalid、canceled？
-
Warning suwoder, 表达已经可以，再爆粗口就封号了。
>:(
-
I3 gathered tons of money from investors,then what?I CAN'T SEE ANY SOLID PRODUCT RIGHT NOW.
DELAY AND DELAY AND DELAY AND DELAY.
infinite DELAY.. >:( >:( >:( >:( >:(
TIL that 1 month=Infinite.
Sent from my SCH-S720C using Tapatalk 2
Interesting fact: when a product/project is delayed, the probability of further delays increases. The more time past without a release since the initial deadline, the more the probability of an actual release decrease.
Source: Taleb in Black Swan.
-
I create a git to coding GUI.
https://github.com/cgafeng/BTX (https://github.com/cgafeng/BTX)
need somebody help edit the CMakeLists.txt.
-
Steve Jobs was fired for delaying projects. Microsoft stole his idea and did it quicker. We all know the conclusion.
All in good time is fine until somebody else does it faster.
-
If people lost real money every time MSDOS or Windows crashed, how successful do you think Microsoft would have been?
Sent from my SCH-I535 using Tapatalk
-
Apparently they'd own the most successful computer software company in the world.
-
Steve Jobs was fired for delaying projects. Microsoft stole his idea and did it quicker. We all know the conclusion.
All in good time is fine until somebody else does it faster.
If only you have spent some time checking out their github repo: https://github.com/InvictusInnovations/BitShares/commits/master/bts_wallet . It's just unbelievable that they could raise 4000 BTC & 300,000 PTS with this piece of code. I guess they don't want to miss the deadline time after time, either. They're just incompetent. That's all.
-
Steve Jobs was fired for delaying projects. Microsoft stole his idea and did it quicker. We all know the conclusion.
All in good time is fine until somebody else does it faster.
If you have someone who can do this faster then please bring him to my attention. I want this done as quickly as possible.
-
Steve Jobs was fired for delaying projects. Microsoft stole his idea and did it quicker. We all know the conclusion.
All in good time is fine until somebody else does it faster.
If only you have spent some time checking out their github repo: https://github.com/InvictusInnovations/BitShares/commits/master/bts_wallet . It's just unbelievable that they could raise 4000 BTC & 300,000 PTS with this piece of code. I guess they don't want to miss the deadline time after time, either. They're just incompetent. That's all.
We migrated from that code base a while back... all recent work is being done here:
https://github.com/BitShares/bitshares_toolkit
-
*lost real money
Yeah, it totally sucked how I lost BTC and bitUSD everyone Windows crashed...but no sweat, just reboot and write it off as a silly mistake...
Sent from my SCH-I535 using Tapatalk
-
I'm not worried as this was kind of my "throw it in and see what happens" bet. If it should fail then fine. If not then great. I was just simply stating that we are passed the "in good time" phase.
-
I thought I would update everyone on our GUI development. We have been working with a bright developer named Nathan who has put together a large amount of a basic GUI for the BTS wallet. He still has some work to do, but his progress is still significant.
(http://the-iland.net/static/images/BTSX.png)
It isn't quite the interface I would have designed, but is certainly a step up from the command line and we will enhance it as time progresses.
this UI is invalid、canceled？
No that UI is still valid for the BTS X trading work. Nathan graduates in a month and will be working full time on it. He is one of the most talented developers I have met and producing that GUI was a challenge I didn't expect him to be able to complete given the time we gave him. He pulled it off and so I am very excited to have him come on board. Obviously the GUI has some work to do.
I would have liked to have him work more on it the past month or so, but unfortunately that is beyond my power. We have been interviewing lots of people trying to find the skills we need and so far Nathan has proven himself where as others have not shown the same potential.
-
Nathan graduates in a month and will be working full time on it.
So he will graduate let's say May 15th, and from then he start full time working on GUI... >:( when will xts liquid??
Fine, I just hope this guy really exist.
-
I3 gathered tons of money from investors,then what?I CAN'T SEE ANY SOLID PRODUCT RIGHT NOW.
DELAY AND DELAY AND DELAY AND DELAY.
infinite DELAY.. >:( >:( >:( >:( >:(
Think of it this way: We have set out on a journey of unknown length. We can see the goal on a distant mountain top but we know the road before us snakes through many valleys and dark forests where there await lions and tigers and bears.
Those who have been watching closely note that every obstacle is overcome quickly and we become stronger and stronger after every battle. ("Was mich nicht umbringt, macht mich stärker.") They see victory after victory after victory after victory while others only see the delays associated with those victories.
Our little band of intrepid hobbits have put everything on the line. Others have invested much. We have invested all. If it were possible to take a shorter, straighter road with fewer obstacles along the way, we certainly would!
(http://images.travelpod.com/tw_slides/ta00/ce3/2a6/long-windy-road-to-cave-zhangjiajie.jpg)
-
I create a git to coding GUI.
https://github.com/cgafeng/BTX (https://github.com/cgafeng/BTX)
need somebody help edit the CMakeLists.txt.
great！
-
I3 gathered tons of money from investors,then what?I CAN'T SEE ANY SOLID PRODUCT RIGHT NOW.
DELAY AND DELAY AND DELAY AND DELAY.
infinite DELAY.. >:( >:( >:( >:( >:(
Think of it this way: We have set out on a journey of unknown length. We can see the goal on a distant mountain top but we know the road before us snakes through many valleys and dark forests where there await lions and tigers and bears.
Those who have been watching closely note that every obstacle is overcome quickly and we become stronger and stronger after every battle. ("Was mich nicht umbringt, macht mich stärker.") They see victory after victory after victory after victory while others only see the delays associated with those victories.
Our little band of intrepid hobbits have put everything on the line. Others have invested much. We have invested all. If it were possible to take a shorter, straighter road with fewer obstacles along the way, we certainly would!
(http://images.travelpod.com/tw_slides/ta00/ce3/2a6/long-windy-road-to-cave-zhangjiajie.jpg)
+5% +5% +5% +5% +5% +5% +5% +5% +5% +5% +5% +5% +5% +5% +5% +5%
-
Nathan is in school and has been unable to work on GUI much. :(.
Sent from my iPhone using Tapatalk (http://tapatalk.com/m?id=1)
Is this a joke？Tell me it's joke please
-
Nathan is in school and has been unable to work on GUI much. :(.
Sent from my iPhone using Tapatalk (http://tapatalk.com/m?id=1)
Is this a joke？A student, a part time job，and he‘s been too busy too work on it，Tell me it's a joke please
-
What is the reasoning to not honor AGS that came into existence after 2/28?
It is a weak argument that you promised that. When you said that you also promised a product in about 2 weeks. With the delay now in the significant category, I think it is time to reconsider that. With every passing day it seems more and more like you are not honoring significant part of the AGS (at least 50% as of today +2 weeks) and arguing with the above argument seems more and more as a way to go around your ‘social consensus’ promise…
More than that (in my opinion) it is unreasonable to not give stake for those who continue their support even with and during the delay.
My 2 bips...
-
Nathan is in school and has been unable to work on GUI much. :(.
Sent from my iPhone using Tapatalk (http://tapatalk.com/m?id=1)
Is this a joke？A student, a part time job，and he‘s been too busy too work on it，Tell me it's a joke please
Nathan will be joining us full time in May. He has wowed us with his capabilities in March but got slammed in April. So, now if we find someone to work this task in the next few weeks and get them spun up they will probably reach the same place Nathan is already about the time Nathan comes on board. The question is, will they be as good as Nathan has proven to be?
In the meantime, if someone thinks they can cross the finish line on this task faster than Nathan, let us know! That would certainly position you for a job with us!
And this product is also an ideal candidate for a third-party entrepreneur to grab a central place in the ecosystem.
Unless one of these two possibilities emerges, we are already on the shortest path to success we have found.
-
What is the reasoning to not honor AGS that came into existence after 2/28?
It is a weak argument that you promised that. When you said that you also promised a product in about 2 weeks. With the delay now in the significant category, I think it is time to reconsider that. With every passing day it seems more and more like you are not honoring significant part of the AGS (at least 50% as of today +2 weeks) and arguing with the above argument seems more and more as a way to go around your ‘social consensus’ promise…
More than that (in my opinion) it is unreasonable to not give stake for those who continue their support even with and during the delay.
My 2 bips...
It all boils down to the bump in this chart leading up to February 28th:
(https://static.squarespace.com/static/51fb043ee4b0608e46483caf/t/534a8a1de4b0e2dbda74cdce/1397393950071/?format=1500w)
People skipped lunch and sold some of their offspring to donate at this time based on the understanding that after the 28th donations would have one less DAC to honor them.
As for why we picked this date, we promised two weeks notice and the 28th was the earliest we thought we could be ready - until we discovered more R&D was needed in the security model. In the future, we will wait till everything is known to be ready, then give our two weeks notice. This will make the snapshot occur two weeks later than necessary but will avoid it happening many weeks too early.
Obviously it would have been advantageous for the community to have had the donations toward BTS continue during this time, if we knew then what we know today.
-
No that UI is still valid for the BTS X trading work. Nathan graduates in a month and will be working full time on it. He is one of the most talented developers I have met and producing that GUI was a challenge I didn't expect him to be able to complete given the time we gave him. He pulled it off and so I am very excited to have him come on board. Obviously the GUI has some work to do.
I would have liked to have him work more on it the past month or so, but unfortunately that is beyond my power. We have been interviewing lots of people trying to find the skills we need and so far Nathan has proven himself where as others have not shown the same potential.
Nathan will be joining us full time in May. He has wowed us with his capabilities in March but got slammed in April. So, now if we find someone to work this task in the next few weeks and get them spun up they will probably reach the same place Nathan is already about the time Nathan comes on board. The question is, will they be as good as Nathan has proven to be?
In the meantime, if someone thinks they can cross the finish line on this task faster than Nathan, let us know! That would certainly position you for a job with us!
And this product is also an ideal candidate for a third-party entrepreneur to grab a central place in the ecosystem.
Unless one of these two possibilities emerges, we are already on the shortest path to success we have found.
I have hard time to believe that you cannot find people to do a GUI job. The original launch date was a month ago and you are asking to wait one more for something as simple yet crucial as GUI. It all sounds very suspicious an sad :'(
-
Are you serious? I will pay you $1,000 of my own personal money if you find us a qualified Qt GUI developer who can start work full time before this Nathan guy can start.
-
No that UI is still valid for the BTS X trading work. Nathan graduates in a month and will be working full time on it. He is one of the most talented developers I have met and producing that GUI was a challenge I didn't expect him to be able to complete given the time we gave him. He pulled it off and so I am very excited to have him come on board. Obviously the GUI has some work to do.
I would have liked to have him work more on it the past month or so, but unfortunately that is beyond my power. We have been interviewing lots of people trying to find the skills we need and so far Nathan has proven himself where as others have not shown the same potential.
Nathan will be joining us full time in May. He has wowed us with his capabilities in March but got slammed in April. So, now if we find someone to work this task in the next few weeks and get them spun up they will probably reach the same place Nathan is already about the time Nathan comes on board. The question is, will they be as good as Nathan has proven to be?
In the meantime, if someone thinks they can cross the finish line on this task faster than Nathan, let us know! That would certainly position you for a job with us!
And this product is also an ideal candidate for a third-party entrepreneur to grab a central place in the ecosystem.
Unless one of these two possibilities emerges, we are already on the shortest path to success we have found.
I have hard time to believe that you cannot find people to do a GUI job. The original launch date was a month ago and you are asking to wait one more for something as simple yet crucial as GUI. It all sounds very suspicious an sad :'(
Try giving someone the following offer: "We need you to quit your current project and work for us full time for a month until someone we have already committed to is available to take over."
Top quality developers are almost never available to begin working immediately on such a short time horizon.
(And if there is such a qualified unemployed hero, I have already said we would put them to work immediately.)
-
Hahaha since when did this become a troll box? (Chinese) Ppl stop freaking out. Does the gui delay the test chain? I personally care less about the aesthetics and more about whats under the hood.
-
GUI does not delay anything and is a parallel effort.
Sent from my iPhone using Tapatalk (http://tapatalk.com/m?id=1)
-
What is the reasoning to not honor AGS that came into existence after 2/28?
It is a weak argument that you promised that. When you said that you also promised a product in about 2 weeks. With the delay now in the significant category, I think it is time to reconsider that. With every passing day it seems more and more like you are not honoring significant part of the AGS (at least 50% as of today +2 weeks) and arguing with the above argument seems more and more as a way to go around your ‘social consensus’ promise…
More than that (in my opinion) it is unreasonable to not give stake for those who continue their support even with and during the delay.
My 2 bips...
It all boils down to the bump in this chart leading up to February 28th:
(https://static.squarespace.com/static/51fb043ee4b0608e46483caf/t/534a8a1de4b0e2dbda74cdce/1397393950071/?format=1500w)
People skipped lunch and sold some of their offspring to donate at this time based on the understanding that after the 28th donations would have one less DAC to honor them.
As for why we picked this date, we promised two weeks notice and the 28th was the earliest we thought we could be ready - until we discovered more R&D was needed in the security model. In the future, we will wait till everything is known to be ready, then give our two weeks notice. This will make the snapshot occur two weeks later than necessary but will avoid it happening many weeks too early.
Obviously it would have been advantageous for the community to have had the donations toward BTS continue during this time, if we knew then what we know today.
I get it – Slight dilution of early AGS adopters is not OK, but not honoring over 50% of AGS holders is perfectly fine…
OK let’s wait and see what % of the AGS holders you will end up not honoring…
Unfortunately your stance on the above issue makes more believable the following scenario: Setting artificially early day for the snapshot because such date provided 3 benefits for 3I:
1. Serious inflow of funds to the AGS account.
2. At the same time – the total position of 3I, in PTS and AGS (as a percentage), allowed for maximizing the company’s share of the BTS.
3. At the same time, i.e. while achieving 2. above, giving AGS and PTS holders 50% each i.e. all of the shares- far above the promised minimum of 10%. And looking good for doing so.
-
What is the reasoning to not honor AGS that came into existence after 2/28?
It is a weak argument that you promised that. When you said that you also promised a product in about 2 weeks. With the delay now in the significant category, I think it is time to reconsider that. With every passing day it seems more and more like you are not honoring significant part of the AGS (at least 50% as of today +2 weeks) and arguing with the above argument seems more and more as a way to go around your ‘social consensus’ promise…
More than that (in my opinion) it is unreasonable to not give stake for those who continue their support even with and during the delay.
My 2 bips...
It all boils down to the bump in this chart leading up to February 28th:
(https://static.squarespace.com/static/51fb043ee4b0608e46483caf/t/534a8a1de4b0e2dbda74cdce/1397393950071/?format=1500w)
People skipped lunch and sold some of their offspring to donate at this time based on the understanding that after the 28th donations would have one less DAC to honor them.
As for why we picked this date, we promised two weeks notice and the 28th was the earliest we thought we could be ready - until we discovered more R&D was needed in the security model. In the future, we will wait till everything is known to be ready, then give our two weeks notice. This will make the snapshot occur two weeks later than necessary but will avoid it happening many weeks too early.
Obviously it would have been advantageous for the community to have had the donations toward BTS continue during this time, if we knew then what we know today.
I get it – Slight dilution of early AGS adopters is not OK, but not honoring over 50% of AGS holders is perfectly fine…
OK let’s wait and see what % of the AGS holders you will end up not honoring…
People donating for AGS the two weeks before the snapshot paid around 10X more for those AGS - so they can get in on the BTS - than what is being paid now for AGS, so it is more than "slight".
-
you've missed the point of ags. ags is not just for bitshares x it is for all bitshares dacs. the snapshot has been taken for bitshares x already. current ags donations are being honored in future dacs, such as bitshares me and dns and lotto. all ags gets honored, but you have to make your donations before the snapshot of each specific dac type. i still donate to ags because my stake in the entire dac industry gets diluted as more ags are issued. however my stake in bts x is not getting diluted because that snapshot has already been taken. in order to make the best of your investment, buy now while it is cheap and few ppl understand the value of it.
-
Clout, I would have agreed with you if the delay was not as long as it is now, which in turn leads to conspiracy theories in my head. (see above)
-
Unfortunately your stance on the above issue makes more believable the following scenario: Setting artificially early day for the snapshot because such date provided 3 benefits for 3I:
1. Serious inflow of funds to the AGS account.
This isn't a bad thing. The point of ags is funding. It would be one thing if they created a snapshot, got ags funding and ran. However they didn't do that they are still coding away and developing the bitshares brand. Clearly they are focused on the big picture. If anything the early snapshot lost funding opportunity for I3, since people are less optimistic about the other DACs and simply want to profit from early investment in bitshares x. So now the price of ags is significantly lower/there are less donations because people understand that they have less to gain from donating at this point. I dont think funding is an issue at this point. It is my perception that they can accomplish the development their dacs without additional funds. Its more of an investment opportunity for the community.
2. At the same time – the total position of 3I, in PTS and AGS (as a percentage), allowed for maximizing the company’s share of the BTS.
Once again this is not a bad thing. Firstly they should receive a large stake in what they are developing, because they are the ones that are putting everything on the line to develop and market it. Secondly, their ability to accumulate stake in pts and ags is due to their understanding of how valuable the concept of a dac is, while most people do not understand the implications of this technology
3. At the same time, i.e. while achieving 2. above, giving AGS and PTS holders 50% each i.e. all of the shares- far above the promised minimum of 10%. And looking good for doing so.
This is the point where I can't even entertain your logic. So they have accumulated a large stake in ags and pts by doing exactly what any investor in the community can do on their own - buy pts, mine pts, donate pts to ags fund, donate btc to ags fund. You have to see that there are no barriers to access in the investment vehicle they have provided. The only barrier is ignorance. Second instead of only donating 20% to ags/pts and keeping the rest for themselves they have allocated all bts to ags and pts holders thereby leveling the playing field once more. It is not mathematically possible that they can have a larger stake in bts by doing this. All i know is that whereas my stake in bts would have been 0.0026% under the initial agreement, my stake is now 0.013% under the current agreement
-
1.Good by itself – if not achieved by artificially early delivery date. And btw it would have been even better if the active investment period had continued for twice or 3 times as long, getting 2-3 times more money, involving more and more people (instead of thinking today about airdrops)
2.The fair way to achieve 2 is to just say: Here is the distribution 40/40/20 AGS/PTS/Developers, and not by pretending to be 50/50 and achieving 40/40/20 with artificially early date.(BTW I personally am more than fine with 10 to 20% share for the developers)
3.Great! If not looking for workarounds to get better position and only taking the benefit as if you have done the best you can.
-
GUI does not delay anything and is a parallel effort.
Sent from my iPhone using Tapatalk (http://tapatalk.com/m?id=1)
-
You're clearly just looking to complain about things for the sake of complaining. If they split it 40/40/20 you would be worse off and they would be better off. It doesn't make any sense why you have a problem with the allocation.
-
Though this project is delayed for several reasons that are sometimes arguable in the views of some investors, I think once the bts is ready , secured and efficiently designed, domino-effect would occur to every I3 DACs on the horizon. After the launch of Bitshare X , investors may see how fast their ROI can be as DACs would spring up like mushrooms . Patience is the key. The ideas are already in place. Implementation really takes time. But time is really important than anything else. Losing investments due to time constraints have great impacts on all businesses. This is the main reason why blockchain is being considered as alternative business model. It is FAST, efficient and most importantly DECENTRALIZED.
-
Everyone knows people that buy AGS now will not get bitshares X. If you want bitshares X, do not buy AGS now. I don't see why it is unfair that people do not get what they did not pay for?
I think I3 shot themselves in the foot with the early snapshot (hurting the ability to fundraise for longer), but what they are doing now is being fair and honouring their agreement. Look how much donations have dropped since Feb 28. Even including the run-up, I3 would have been better to not do the snapshot that early (more money for development).
Since the evidence shows that I3 was acting in good faith (since they hurt themselves more than AGS holders by doing an early snapshot), and people should not get what they did not pay for, everything appears to be fine... I really can't see what the problem is in their strategy...
EDIT: I'm even more confused, tonyk is contradicting himself. At one point he says the early snap shot was disingenuous since it provided I3 the benefit of "Serious inflow of funds to the AGS account." but then counters the rebutal to that point by saying, " it would have been even better if the active investment period had continued for twice or 3 times as long, getting 2-3 times more money, involving more and more people." He basically destroyed his own argument. The logic at the other points doesn't make sense either, and is circular.
-
Unfortunately your stance on the above issue makes more believable the following scenario: Setting artificially early day for the snapshot because such date provided 3 benefits for 3I:
1. Serious inflow of funds to the AGS account.
This isn't a bad thing. The point of ags is funding. It would be one thing if they created a snapshot, got ags funding and ran. However they didn't do that they are still coding away and developing the bitshares brand. Clearly they are focused on the big picture. If anything the early snapshot lost funding opportunity for I3, since people are less optimistic about the other DACs and simply want to profit from early investment in bitshares x. So now the price of ags is significantly lower/there are less donations because people understand that they have less to gain from donating at this point. I dont think funding is an issue at this point. It is my perception that they can accomplish the development their dacs without additional funds. Its more of an investment opportunity for the community.
2. At the same time – the total position of 3I, in PTS and AGS (as a percentage), allowed for maximizing the company’s share of the BTS.
Once again this is not a bad thing. Firstly they should receive a large stake in what they are developing, because they are the ones that are putting everything on the line to develop and market it. Secondly, their ability to accumulate stake in pts and ags is due to their understanding of how valuable the concept of a dac is, while most people do not understand the implications of this technology
3. At the same time, i.e. while achieving 2. above, giving AGS and PTS holders 50% each i.e. all of the shares- far above the promised minimum of 10%. And looking good for doing so.
This is the point where I can't even entertain your logic. So they have accumulated a large stake in ags and pts by doing exactly what any investor in the community can do on their own - buy pts, mine pts, donate pts to ags fund, donate btc to ags fund. You have to see that there are no barriers to access in the investment vehicle they have provided. The only barrier is ignorance. Second instead of only donating 20% to ags/pts and keeping the rest for themselves they have allocated all bts to ags and pts holders thereby leveling the playing field once more. It is not mathematically possible that they can have a larger stake in bts by doing this. All i know is that whereas my stake in bts would have been 0.0026% under the initial agreement, my stake is now 0.013% under the current agreement
Lets make some things clear:
1) We could have raised more money by not announcing the snapshot and missing an artificial deadline
2) Knowing a longer time horizon would have given us the wisdom to spread out our own investments and thus maximize the AGS per PTS / BTC
3) Early estimates (made in January) were based upon the following assumptions
a) release with a single trustee and eventually turn into Consensus + TaPOS
b) that there were no unexpected market manipulation attacks.
c) that the MVP would not be extensible for many alternative DACs.
4) Since then we have found problems with Consensus and also market manipulation attacks
a) we have opted to avoid the single trustee and go straight to DPOS.
b) we have opted for a phased approach to minimize risk
c) we have refactored into an extensible toolkit and thus accelerated the timeline of many other DACs.
So rather than looking at this as merely missing a release date or some kind of conspiracy we need to view this from the perspective that we have increased the features to be tested in the MVP and accelerated follow on DACs. This decision was made to maximize the value of testing in the MVP from the perspective of all DACs. So taken as a whole the schedule hasn't slipped as we will be delivering more in the MVP than we had originally planned.
-
Lets just skip caring about deadlines and continue building a superior crypto community
I fully support you BM!!
-
Lets just skip caring about deadlines and continue building a superior crypto community
I fully support you BM!!
+5%
Agree. BM and the team is not delaying anything on purpose. Why should they? Our advantage is theirs and vice versa. It is in the nature of complex ventures that they never go as planed. Even though that could have been communicated better by III. But that is a non crucial issue... Honour their work by paying applying constructive criticsm.
-
Also does this https://bitsharestalk.org/index.php?topic=1709.0 still apply in some way?
-
I thought I would update everyone on our GUI development. We have been working with a bright developer named Nathan who has put together a large amount of a basic GUI for the BTS wallet. He still has some work to do, but his progress is still significant.
(http://the-iland.net/static/images/BTSX.png)
It isn't quite the interface I would have designed, but is certainly a step up from the command line and we will enhance it as time progresses.
this UI is invalid、canceled？
No that UI is still valid for the BTS X trading work. Nathan graduates in a month and will be working full time on it. He is one of the most talented developers I have met and producing that GUI was a challenge I didn't expect him to be able to complete given the time we gave him. He pulled it off and so I am very excited to have him come on board. Obviously the GUI has some work to do.
I would have liked to have him work more on it the past month or so, but unfortunately that is beyond my power. We have been interviewing lots of people trying to find the skills we need and so far Nathan has proven himself where as others have not shown the same potential.
wow really nie update! Really great work so far Nathan ... if i could help providing graphic related stuff pls don't hesitate to contact my anytime
-
Lets just skip caring about deadlines and continue building a superior crypto community
I fully support you BM!!
I think that's a dangerous attitude. deadlines are important even if they do slip from time to time.
However, this particular instance of going over the stated deadline is much less egregious when considering the reasons given by BM for the delays and I support the path I3 is taking by taking some extra time to flesh out the security model and build out a toolkit that will hopefully speed up future DAC development.
-
Lets just skip caring about deadlines and continue building a superior crypto community
I fully support you BM!!
I think that's a dangerous attitude. deadlines are important even if they do slip from time to time.
However, this particular instance of going over the stated deadline is much less egregious when considering the reasons given by BM for the delays and I support the path I3 is taking by taking some extra time to flesh out the security model and build out a toolkit that will hopefully speed up future DAC development.
I have spoken thus far with a number of other Devs with regard to potentially using Beyond Bitcoin as a helpful platform to have their presence known and have specifically brought up the concept of DPOS...and all of them thus far are loving it. Thought you guys might want to hear this...
-
Lets just skip caring about deadlines and continue building a superior crypto community
I fully support you BM!!
I think that's a dangerous attitude. deadlines are important even if they do slip from time to time.
However, this particular instance of going over the stated deadline is much less egregious when considering the reasons given by BM for the delays and I support the path I3 is taking by taking some extra time to flesh out the security model and build out a toolkit that will hopefully speed up future DAC development.
I have spoken thus far with a number of other Devs with regard to potentially using Beyond Bitcoin as a helpful platform to have their presence known and have specifically brought up the concept of DPOS...and all of them thus far are loving it. Thought you guys might want to hear this...
Thanks for the good news!
-
Lets just skip caring about deadlines and continue building a superior crypto community
I fully support you BM!!
I think that's a dangerous attitude. deadlines are important even if they do slip from time to time.
However, this particular instance of going over the stated deadline is much less egregious when considering the reasons given by BM for the delays and I support the path I3 is taking by taking some extra time to flesh out the security model and build out a toolkit that will hopefully speed up future DAC development.
I have spoken thus far with a number of other Devs with regard to potentially using Beyond Bitcoin as a helpful platform to have their presence known and have specifically brought up the concept of DPOS...and all of them thus far are loving it. Thought you guys might want to hear this...
Thanks for the good news!
+5%
-
May I ask after the GUI delay,What's the ETA of the wallet release?thanks
-
May I ask after the GUI delay,What's the ETA of the wallet release?thanks
same question here. BM said after the NY conference , what now?
-
Regardless,
When this is up and running, there should be a big marketing push for it. I think that is why BM was trying to gauge interest for an airdrop--to get people using it immediately.
The more I look into it, the more I think that the blackcoin multipool model would be the best kind of air drop.
-
The biggest problem right now is the 28 Feb snapshot. As we get farther away from the date, it keeps looking worse (and is generating a lot of heartache amongst investors) and creating more pressure on Dan and co.
The logical order of releases would have been Test DPOS -> Real DPOS Coin -> BTS Me -> BTS X. I have a suggestion (will probably be hated by most) which might get around this.
For starters, PTS mining and AGS donation has to be stopped and all these along with the Feb 28th snapshot merged in a single coin of 4m supply (lets call it Tokens) and the social consensus would state that at least 20% of any DAC should honour these Tokens (instead of 10% each for PTS and AGS). Also, the Feb 28 snapshot will NOT be used for BTS X.
So, the distribution will be
1> Some 1.8m for PTS will become 1.8m Tokens
2> Roughly 1.1m AGS will become 1.1m Tokens
3> The remaining 1.1m can be distributed amongst Feb 28 snapshot and/or award Tokens directly to I3 which will be used only as payments/bounties (and can't be sold directly by I3).
The ratios can be adjusted accordingly to try and even out the playing field amongst the various types of investors. In this scheme, I think all the sets are being accommodated.
1> PTS holders will still get the same portion.
2> Ditto for AGS but as an added bonus they are liquid (BM is trying to get some form of BTS XT out quickly so that those AGSers can have some form of liquid asset).
3> PTS and AGSers before Feb 28th, who got in at a higher price due to the promise of BTS X will be partly compensated by getting awarded extra tokens. If you think that is not enough, that snapshot may also be used to award BTS Me, which is expected to be the first DAC with some features.
In doing so, initially BM releases a test version to try out DPOS. If it works well, the conversion into Tokens happen, which will mean it will be tested on a real coin listed on exchanges and having a good market cap. At this point, a mining pool which awards Tokens can also be set up. Remember, Tokens at this point will be the first DPOS coin, and with the rage about PoS these days, having a supposedly superior (we have to see how it works in practice), we should get a lot of buzz.
Then, BTS Me with some functionality (and maybe honouring Feb 28th snapshot) gets released, and after that every DAC honours Tokens directly - no more having families of DACs with with its own ProtoDACs to provide distribution and all. This simplifies matters to a large extent as you know how may of these Tokens you have and so what percentage you will get - no more trying to calculate separately for PTS, AGS or even BTS XT (for future BTS Xs). Of course, future DAC creators may award differently, like 20% for Tokens and, say, 10% for Bitshares Me, but that is his own choice.
Even if you guys think I am not bonkers, still there is room to adjust the numbers/ratios to even it out amongst the various investors. I just like the idea of having a simple, elegant system to award me the DACs (instead of the complicated mess we have now). The biggest benefit, IMO, is that the infamous Feb 28 snapshot monkey is off the back.
*goes back to smoking that weird plant thingy*
-
Also, the Feb 28 snapshot will NOT be used for BTS X.
This is absurd. by doing this 3i and the whole project will be a totally joke that no one would give it any tiny trust any more.
god, stan and BM please don't even think of this.
-
changing the social contract is suicide and the devs know that very well and stated several times in this board that it will not happen!
-
Pardon my candor,
Management by committee sucks and by forum outright lunacy.
I would assume each project team has a project plan and I3 has a strategy for orchestrating the various projects. We can cheer, hoot and holler all day here on the forum, at best we provide ideas, sentiment and information. But, we do not are should we drive the plan, that is best left to the planners and system architects.
As an investor, I put my faith in the organization and to a lessor degree the community. Communities can raise a barn in a weekend, not build complex financial systems. We in the community can best support the organization by:
Starting complementary projects of our own that honor the AGS/PTS contract
Continuing to invest in AGS/PTS
Fill openings in existing projects when available
Educate the greater community
Be good community citizens by helping selflessly
And yes, open source projects can build very complex systems organically over long periods of time. But, this is a different animal, part open source and part commercial enterprise. Don't try to apply old school familiar rules. This is a, classic Black Swan (oxymoron, btw).
-
Also, the Feb 28 snapshot will NOT be used for BTS X.
This is absurd. by doing this 3i and the whole project will be a totally joke that no one would give it any tiny trust any more.
god, stan and BM please don't even think of this.
That's not a real quote is it
Sent from my iPhone using Tapatalk
-
Yes please don't make bolded claims when they are not true. Using a different snapshot is insanity.
Sent from my SCH-I535 using Tapatalk
-
The February 28th snapshot is cast in concrete.
-
The February 28th snapshot is cast in concrete.
+5% +5% +5% +5% +5%
-
The biggest problem right now is the 28 Feb snapshot. As we get farther away from the date, it keeps looking worse (and is generating a lot of heartache amongst investors) and creating more pressure on Dan and co.
The logical order of releases would have been Test DPOS -> Real DPOS Coin -> BTS Me -> BTS X. I have a suggestion (will probably be hated by most) which might get around this.
For starters, PTS mining and AGS donation has to be stopped and all these along with the Feb 28th snapshot merged in a single coin of 4m supply (lets call it Tokens) and the social consensus would state that at least 20% of any DAC should honour these Tokens (instead of 10% each for PTS and AGS). Also, the Feb 28 snapshot will NOT be used for BTS X.
So, the distribution will be
1> Some 1.8m for PTS will become 1.8m Tokens
2> Roughly 1.1m AGS will become 1.1m Tokens
3> The remaining 1.1m can be distributed amongst Feb 28 snapshot and/or award Tokens directly to I3 which will be used only as payments/bounties (and can't be sold directly by I3).
The ratios can be adjusted accordingly to try and even out the playing field amongst the various types of investors. In this scheme, I think all the sets are being accommodated.
1> PTS holders will still get the same portion.
2> Ditto for AGS but as an added bonus they are liquid (BM is trying to get some form of BTS XT out quickly so that those AGSers can have some form of liquid asset).
3> PTS and AGSers before Feb 28th, who got in at a higher price due to the promise of BTS X will be partly compensated by getting awarded extra tokens. If you think that is not enough, that snapshot may also be used to award BTS Me, which is expected to be the first DAC with some features.
In doing so, initially BM releases a test version to try out DPOS. If it works well, the conversion into Tokens happen, which will mean it will be tested on a real coin listed on exchanges and having a good market cap. At this point, a mining pool which awards Tokens can also be set up. Remember, Tokens at this point will be the first DPOS coin, and with the rage about PoS these days, having a supposedly superior (we have to see how it works in practice), we should get a lot of buzz.
Then, BTS Me with some functionality (and maybe honouring Feb 28th snapshot) gets released, and after that every DAC honours Tokens directly - no more having families of DACs with with its own ProtoDACs to provide distribution and all. This simplifies matters to a large extent as you know how may of these Tokens you have and so what percentage you will get - no more trying to calculate separately for PTS, AGS or even BTS XT (for future BTS Xs). Of course, future DAC creators may award differently, like 20% for Tokens and, say, 10% for Bitshares Me, but that is his own choice.
Even if you guys think I am not bonkers, still there is room to adjust the numbers/ratios to even it out amongst the various investors. I just like the idea of having a simple, elegant system to award me the DACs (instead of the complicated mess we have now). The biggest benefit, IMO, is that the infamous Feb 28 snapshot monkey is off the back.
*goes back to smoking that weird plant thingy*
‘still there is room to adjust the numbers/ratios to even it out amongst the various investors. I just like the idea of having a simple, elegant system’
Try suggesting honoring the pre 28th AGS with at least 3:1 ratio, or better, to the other AGS in future DAC’s.
Reasons?
– some of the early investors paid 10X compared to investors now (see currencydebt post above)
–others of them did not have the benefit of ‘... a longer time horizon that would have given them the wisdom to spread out their own investments and thus maximize the AGS per PTS / BTC...’, even though this spreading would have resulted in smaller share for them(*1) (see bytemasters post above)
–the after Feb 28th AGS are late coming diluters of the founding AGSers share; those late comers are also more stupid ones - as they supported someone after this person promised them something and while being very late, instead of trying to deliver on his promises, went to preach his other ideas, improving the concept of his non-existing product and god knows what else. But do not think he moved the delivery day ahead of the possible/reasonable date… no,no ..it is a coincidence that he bunched the donations in a short period and having those funds secured (and not depending on his behavior afterwards), went on doing what he really wanted to do in the first place.
(*1) If you what to check that this is the case - compare what percentage of BTS one with say 100,000 PTS would have if he spread its donation equally from Jan1 to Feb 28 and compare this to what percentage he will get if he spreads same 100K PTS from Jan1 to Today – the difference is about 50% more in the first scenario (and this is without including the reasonable expectation that the donations would have been higher after 28th if such donations gave a chance to participate in the snapshot)
‘…AGS donation has to be stopped…’ here, there is no need donations to be stopped. Just make clear to them donors they can continue donating, but they will not be honored in any future DAC’s with anything more than 1%... as this is the social consensus…
Now I expect to have a good time in the following weeks in a better place with no internet connection …I just hope when I check back this project to be something more than ‘improved’ product existing mainly in somebody’s head…
-
–the after Feb 28th AGS are late coming diluters of the founding AGSers share; those late comers are also more stupid ones - as they supported someone after this person promised them something and while being very late, instead of trying to deliver on his promises, went to preach his other ideas, improving the concept of his non-existing product
[/i] here, there is no need donations to be stopped. Just make clear to them donors they can continue donating, but they will not be honored in any future DAC’s with anything more than 1%... as this is the social consensus…
Social contract says 10%. Folks donating to AGS after the Fe. 28 snapshot also see the potential of other DACs. The person who promised us something is on track to deliver more than promised over the next few months. I, for one, will continue donating as I want shares in those new DACs, too. Call me stupid, but Bitshares Me, Music, DNS, Insurance, Lotto, etc. look freakin awesome.
-
The February 28th snapshot is cast in concrete.
This concerns me as I've broken concrete with my bare hands. :)
-
The February 28th snapshot is cast in concrete.
This concerns me as I've broken concrete with my bare hands. :)
This is fiber-reinforced concrete coated with stainless steel and wrapped in titanium.
-
The February 28th snapshot is cast in concrete.
This concerns me as I've broken concrete with my bare hands. :)
You haven't seen the titanium rebar with 800ksi Nycon-PVA-RF-4000 High Performance Macro Fiber reinforcement we added to the mix:
(http://nycon.com.previewdns.com/wp-content/uploads/2013/11/Improved_Flexural_Strength.jpg)
-
The February 28th snapshot is cast in concrete.
This concerns me as I've broken concrete with my bare hands. :)
This is fiber-reinforced concrete coated with stainless steel and wrapped in titanium.
…and its studded with kryptonite
-
The biggest problem right now is the 28 Feb snapshot. As we get farther away from the date, it keeps looking worse (and is generating a lot of heartache amongst investors) and creating more pressure on Dan and co.
Yep, it really annoys me.
Having value trap in a black hole during an undetermined period of time was not part of the deal. Having value stuck is reeeeally annoying, especially in the cryptospace where things move very fast. If I didn't mind having my value be illiquid I would have buy more AGS, my portfolio was skewed toward PTS for a reason.
-
–the after Feb 28th AGS are late coming diluters of the founding AGSers share; those late comers are also more stupid ones - as they supported someone after this person promised them something and while being very late, instead of trying to deliver on his promises, went to preach his other ideas, improving the concept of his non-existing product
[/i] here, there is no need donations to be stopped. Just make clear to them donors they can continue donating, but they will not be honored in any future DAC’s with anything more than 1%... as this is the social consensus…
Social contract says 10%. Folks donating to AGS after the Fe. 28 snapshot also see the potential of other DACs. The person who promised us something is on track to deliver more than promised over the next few months. I, for one, will continue donating as I want shares in those new DACs, too. Call me stupid, but Bitshares Me, Music, DNS, Insurance, Lotto, etc. look freakin awesome.
+5%
-
The February 28th snapshot is cast in concrete.
This concerns me as I've broken concrete with my bare hands. :)
This is fiber-reinforced concrete coated with stainless steel and wrapped in titanium.
+5%
fully secured crypto-equity. 8)
-
Social contract says 10%. Folks donating to AGS after the Fe. 28 snapshot also see the potential of other DACs. The person who promised us something is on track to deliver more than promised over the next few months. I, for one, will continue donating as I want shares in those new DACs, too. Call me stupid, but Bitshares Me, Music, DNS, Insurance, Lotto, etc. look freakin awesome.
Sorry I was under the impression that Bitshares Me, Music, DNS, Insurance, Lotto will all honor AGS/PTS 50/50. And after these ones the social contract says at least 10%. Isn't that the case?
-
No, only X is definitely 50/50. DNS will drop on namecoin for example
Sent from my SCH-I535 using Tapatalk
-
Social contract says 10%. Folks donating to AGS after the Fe. 28 snapshot also see the potential of other DACs. The person who promised us something is on track to deliver more than promised over the next few months. I, for one, will continue donating as I want shares in those new DACs, too. Call me stupid, but Bitshares Me, Music, DNS, Insurance, Lotto, etc. look freakin awesome.
Sorry I was under the impression that Bitshares Me, Music, DNS, Insurance, Lotto will all honor AGS/PTS 50/50. And after these ones the social contract says at least 10%. Isn't that the case?
It is up to each developer to determine how their shares are distributed. They are compliant with the Social Consensus if they honor both PTS and AGS with 10%. After that, it depends on their business and marketing models. In general the strategy is to maximize the viability of their DAC by attracting supporters, customers, donations, and investment through wise decisions about how best to distribute their shares.
Most of the strategies discussed in this forum amount to "targeted air-drops" to specific constituency groups a developer wants to attract. In rare cases, air dropped shares are distributed to the General Population. This usually results is most people quickly selling their shares - depressing the price - and hence has been found to be not in the developer's best interest. PTS and AGS seek to represent groups that developers benefit from attracting. The remaining 80% is free to be used by developers to attract still more specialized groups or to increase the intensity of support they get from the most loyal and informed DAC support group in the world: PTS and AGS holders.
-
The biggest problem right now is the 28 Feb snapshot. As we get farther away from the date, it keeps looking worse (and is generating a lot of heartache amongst investors) and creating more pressure on Dan and co.
Yep, it really annoys me.
Having value trap in a black hole during an undetermined period of time was not part of the deal. Having value stuck is reeeeally annoying, especially in the cryptospace where things move very fast. If I didn't mind having my value be illiquid I would have buy more AGS, my portfolio was skewed toward PTS for a reason.
Is having your AGS being illiquid for 2-3 months really the end of the world? You know your returns are going to be huge once the product is released. The only thing Im annoyed about is that I didnt donate more.
-
The biggest problem right now is the 28 Feb snapshot. As we get farther away from the date, it keeps looking worse (and is generating a lot of heartache amongst investors) and creating more pressure on Dan and co.
Yep, it really annoys me.
Having value trap in a black hole during an undetermined period of time was not part of the deal. Having value stuck is reeeeally annoying, especially in the cryptospace where things move very fast. If I didn't mind having my value be illiquid I would have buy more AGS, my portfolio was skewed toward PTS for a reason.
Is having your AGS being illiquid for 2-3 months really the end of the world? You know your returns are going to be huge once the product is released. The only thing Im annoyed about is that I didnt donate more.
What really annoys me is that we don't have 100 DACs deployed already occupying the top 100 slots at coinmarketcap.com.
It also annoys me that we don't have our own electric car and space launch companies and our own decentralized sovereign nation somewhere in international waters, perhaps conveniently located on the floor of the Pacific Ocean.
Having all that value trapped in bytemaster's head and only a tiny low-bandwidth output port: The BitShares Industry.
Then there's that whole "change the world" agenda.
Like I used to ask my parents from the back of the car... "Are we there yet?"
-
The biggest problem right now is the 28 Feb snapshot. As we get farther away from the date, it keeps looking worse (and is generating a lot of heartache amongst investors) and creating more pressure on Dan and co.
Yep, it really annoys me.
Having value trap in a black hole during an undetermined period of time was not part of the deal. Having value stuck is reeeeally annoying, especially in the cryptospace where things move very fast. If I didn't mind having my value be illiquid I would have buy more AGS, my portfolio was skewed toward PTS for a reason.
Is having your AGS being illiquid for 2-3 months really the end of the world? You know your returns are going to be huge once the product is released. The only thing Im annoyed about is that I didnt donate more.
What really annoys me is that we don't have 100 DACs deployed already occupying the top 100 slots at coinmarketcap.com.
It also annoys me that we don't have our own electric car and space launch companies and our own decentralized sovereign nation somewhere in international waters, perhaps conveniently located on the floor of the Pacific Ocean.
Having all that value trapped in bytemaster's head and only a tiny low-bandwidth output port: The BitShares Industry.
Then there's that whole "change the world" agenda.
Like I used to ask my parents from the back of the car... "Are we there yet?"
I'm with you Stan! I'm truly excited for when this technology begins consuming the industries of physical goods & transportation - transposing them to a state of what they should be.
-
The biggest problem right now is the 28 Feb snapshot. As we get farther away from the date, it keeps looking worse (and is generating a lot of heartache amongst investors) and creating more pressure on Dan and co.
Yep, it really annoys me.
Having value trap in a black hole during an undetermined period of time was not part of the deal. Having value stuck is reeeeally annoying, especially in the cryptospace where things move very fast. If I didn't mind having my value be illiquid I would have buy more AGS, my portfolio was skewed toward PTS for a reason.
Is having your AGS being illiquid for 2-3 months really the end of the world? You know your returns are going to be huge once the product is released. The only thing Im annoyed about is that I didnt donate more.
No, I don't know my returns are gonna be huge, especially calculated in BTC. There are a ton of reasons why this can end up not be the case, the world is a very complex place, it's not because some smart people tell you they are gonna change the world and make you rich that that will actually happen.
Like I said if I don't mind having value illiquid I would have buy AGS instead of PTS. But I bought PTS, and my value is illiquid. That's really annoying.
Stan your parents probably responded to you "yeah soon" even when that wasn't true, but your investors are not person that you should feel comfortable treating like child.
Beside that, it raises the question: how have you end up underestimate so much the time you needed? Did you really think you could do in 15 days (February 28th => Ides of March) something you actually cannot do in maybe 45+ days? Should we always mentally triple the time when you speak about something in the future?
-
The biggest problem right now is the 28 Feb snapshot. As we get farther away from the date, it keeps looking worse (and is generating a lot of heartache amongst investors) and creating more pressure on Dan and co.
Yep, it really annoys me.
Having value trap in a black hole during an undetermined period of time was not part of the deal. Having value stuck is reeeeally annoying, especially in the cryptospace where things move very fast. If I didn't mind having my value be illiquid I would have buy more AGS, my portfolio was skewed toward PTS for a reason.
Is having your AGS being illiquid for 2-3 months really the end of the world? You know your returns are going to be huge once the product is released. The only thing Im annoyed about is that I didnt donate more.
No, I don't know my returns are gonna be huge, especially calculated in BTC. There are a ton of reasons why this can end up not be the case, the world is a very complex place, it's not because some smart people tell you they are gonna change the world and make you rich that that will actually happen.
Like I said if I don't mind having value illiquid I would have buy AGS instead of PTS. But I bought PTS, and my value is illiquid. That's really annoying.
Stan your parents probably responded to you "yeah soon" even when that wasn't true, but your investors are not person that you should feel comfortable treating like child.
Beside that, it raises the question: how have you end up underestimate so much the time you needed? Did you really think you could do in 15 days (February 28th => Ides of March) something you actually cannot do in maybe 45+ days? Should we always mentally triple the time when you speak about something in the future?
+5% +5%
-
The biggest problem right now is the 28 Feb snapshot. As we get farther away from the date, it keeps looking worse (and is generating a lot of heartache amongst investors) and creating more pressure on Dan and co.
Yep, it really annoys me.
Having value trap in a black hole during an undetermined period of time was not part of the deal. Having value stuck is reeeeally annoying, especially in the cryptospace where things move very fast. If I didn't mind having my value be illiquid I would have buy more AGS, my portfolio was skewed toward PTS for a reason.
Is having your AGS being illiquid for 2-3 months really the end of the world? You know your returns are going to be huge once the product is released. The only thing Im annoyed about is that I didnt donate more.
No, I don't know my returns are gonna be huge, especially calculated in BTC. There are a ton of reasons why this can end up not be the case, the world is a very complex place, it's not because some smart people tell you they are gonna change the world and make you rich that that will actually happen.
Like I said if I don't mind having value illiquid I would have buy AGS instead of PTS. But I bought PTS, and my value is illiquid. That's really annoying.
Stan your parents probably responded to you "yeah soon" even when that wasn't true, but your investors are not person that you should feel comfortable treating like child.
Beside that, it raises the question: how have you end up underestimate so much the time you needed? Did you really think you could do in 15 days (February 28th => Ides of March) something you actually cannot do in maybe 45+ days? Should we always mentally triple the time when you speak about something in the future?
+5% +5%
That's why we stopped giving estimates. We don't know what we don't know. When our conventional mining solution for PTS pointed out that mining was centralizing and unprofitable, a new invention was necessary. Our supporters have watched (and helped) us make that invention in real time - with access to every chin-scratching twist and turn of our thinking. Is that not being treated like adults?
Here's the list of R&D progress we've made pursuing that invention, as summarized by bytemaster a week or so ago. None of it could be anticipated until we did the work, thought the thoughts, listened to input from this forum, scratched our chins and engineered the required breakthroughs:
Yes, I released a white paper on DPOS last week and have implemented a large part of it and will be testing it in the days ahead. Resolving the security model in a way that one can thoroughly understand and prove is secure was a major challenge. You can follow discussions on this forum where about a half dozen variations / iterations where vetted and found wanting... Let me list the evolution:
1) Mining with Momentum... tossed due to centralization and non profitability
2) Transactions as Proof of Stake white paper (Nov 28th, 2013) adjusted mining difficulty by stake. Suffered from weakness on deciding who should produce the next block.
3) Ripple Consensus + TaPOS was the concept in January at the Miami event through Feb, but after attempted implementation we realized it had several deal breakers:
a) the unique node list was an invite-only group and a point of trust
b) the UNL was not compensated in any way
c) the bandwidth requirements / scalability were an issue
4) Fall back on a simple mining + TaPOS and various variations on equations for option 2. All of these variations suffered from many potential attacks and would require many confirmations. It became too complex to analyze. (Feb through March)
5) Single trustee which could be fired... the process was too manual but otherwise sound.
6) Delegated POS this solution has been reviewed, found to be decentralized, fast, and secure without ambiguity. We have finally resolved the issue.
In that time we also identified problems and found solutions to several market manipulation attacks. These need to be implemented, but then we should be good to go.
As you can see R&D is not predictable when you are at the bleeding edge of innovation and solving problems as they are discovered.
We are now much, much stronger than we were then and the total industry value proposition is bigger than ever.
-
The biggest problem right now is the 28 Feb snapshot. As we get farther away from the date, it keeps looking worse (and is generating a lot of heartache amongst investors) and creating more pressure on Dan and co.
Yep, it really annoys me.
Having value trap in a black hole during an undetermined period of time was not part of the deal. Having value stuck is reeeeally annoying, especially in the cryptospace where things move very fast. If I didn't mind having my value be illiquid I would have buy more AGS, my portfolio was skewed toward PTS for a reason.
Is having your AGS being illiquid for 2-3 months really the end of the world? You know your returns are going to be huge once the product is released. The only thing Im annoyed about is that I didnt donate more.
No, I don't know my returns are gonna be huge, especially calculated in BTC. There are a ton of reasons why this can end up not be the case, the world is a very complex place, it's not because some smart people tell you they are gonna change the world and make you rich that that will actually happen.
Like I said if I don't mind having value illiquid I would have buy AGS instead of PTS. But I bought PTS, and my value is illiquid. That's really annoying.
Stan your parents probably responded to you "yeah soon" even when that wasn't true, but your investors are not person that you should feel comfortable treating like child.
Beside that, it raises the question: how have you end up underestimate so much the time you needed? Did you really think you could do in 15 days (February 28th => Ides of March) something you actually cannot do in maybe 45+ days? Should we always mentally triple the time when you speak about something in the future?
+5% +5%
That's why we stopped giving estimates. We don't know what we don't know. When our conventional mining solution for PTS pointed out that mining was centralizing and unprofitable, a new invention was necessary. Our supporters have watched (and helped) us make that invention in real time - with access to every chin-scratching twist and turn of our thinking. Is that not being treated like adults?
Here's the list of R&D progress we've made pursuing that invention, as summarized by bytemaster a week or so ago. None of it could be anticipated until we did the work, thought the thoughts, listened to input from this forum, scratched our chins and engineered the required breakthroughs:
Yes, I released a white paper on DPOS last week and have implemented a large part of it and will be testing it in the days ahead. Resolving the security model in a way that one can thoroughly understand and prove is secure was a major challenge. You can follow discussions on this forum where about a half dozen variations / iterations where vetted and found wanting... Let me list the evolution:
1) Mining with Momentum... tossed due to centralization and non profitability
2) Transactions as Proof of Stake white paper (Nov 28th, 2013) adjusted mining difficulty by stake. Suffered from weakness on deciding who should produce the next block.
3) Ripple Consensus + TaPOS was the concept in January at the Miami event through Feb, but after attempted implementation we realized it had several deal breakers:
a) the unique node list was an invite-only group and a point of trust
b) the UNL was not compensated in any way
c) the bandwidth requirements / scalability were an issue
4) Fall back on a simple mining + TaPOS and various variations on equations for option 2. All of these variations suffered from many potential attacks and would require many confirmations. It became too complex to analyze. (Feb through March)
5) Single trustee which could be fired... the process was too manual but otherwise sound.
6) Delegated POS this solution has been reviewed, found to be decentralized, fast, and secure without ambiguity. We have finally resolved the issue.
In that time we also identified problems and found solutions to several market manipulation attacks. These need to be implemented, but then we should be good to go.
As you can see R&D is not predictable when you are at the bleeding edge of innovation and solving problems as they are discovered.
We are now much, much stronger than we were then and the total industry value proposition is bigger than ever.
We know that you team make great efforts underground before the seed of Bitsahres sprouting, we as investor just want something visible to stronger our confidence and stop the useless urge.
-
That's why we stopped giving estimates. We don't know what we don't know. When our conventional mining solution for PTS pointed out that mining was centralizing and unprofitable, a new invention was necessary. Our supporters have watched (and helped) us make that invention in real time - with access to every chin-scratching twist and turn of our thinking. Is that not being treated like adults?
Here's the list of R&D progress we've made pursuing that invention, as summarized by bytemaster a week or so ago. None of it could be anticipated until we did the work, thought the thoughts, listened to input from this forum, scratched our chins and engineered the required breakthroughs:
Yes, I released a white paper on DPOS last week and have implemented a large part of it and will be testing it in the days ahead. Resolving the security model in a way that one can thoroughly understand and prove is secure was a major challenge. You can follow discussions on this forum where about a half dozen variations / iterations where vetted and found wanting... Let me list the evolution:
1) Mining with Momentum... tossed due to centralization and non profitability
2) Transactions as Proof of Stake white paper (Nov 28th, 2013) adjusted mining difficulty by stake. Suffered from weakness on deciding who should produce the next block.
3) Ripple Consensus + TaPOS was the concept in January at the Miami event through Feb, but after attempted implementation we realized it had several deal breakers:
a) the unique node list was an invite-only group and a point of trust
b) the UNL was not compensated in any way
c) the bandwidth requirements / scalability were an issue
4) Fall back on a simple mining + TaPOS and various variations on equations for option 2. All of these variations suffered from many potential attacks and would require many confirmations. It became too complex to analyze. (Feb through March)
5) Single trustee which could be fired... the process was too manual but otherwise sound.
6) Delegated POS this solution has been reviewed, found to be decentralized, fast, and secure without ambiguity. We have finally resolved the issue.
In that time we also identified problems and found solutions to several market manipulation attacks. These need to be implemented, but then we should be good to go.
As you can see R&D is not predictable when you are at the bleeding edge of innovation and solving problems as they are discovered.
We are now much, much stronger than we were then and the total industry value proposition is bigger than ever.
I have been lurking through the forums; this statement just made me register on the forum. If I am reading it correctly, your solution to incorrect estimates (not only BTSX but keyhotee too) is not to provide an estimate any more. So basically, what you are saying is "we will never try to make a correct estimate, so yeah lets leave it?" I am just dumbfounded by this way of thinking. :-X
While I also appreciate the amount of work BM has put in compiling the list. The question really is - why weren't they tried before the snapshot or March dates? Is it going to be I3's policy to make a commitment, generate an interest from the public and then say this doesn't work so trust us for some more time? I guess you might think there is a whole new value proposition here so, I3 can get away with its tardiness.
I also work in the IT industry. Whenever I am asked for an estimate, my efforts are always padded with 30% of rework, rethink and general avoidance of being rushed. So if I need 10, I say 13.
In worst case, if I do cross 13 and there is 14/15th day, I am answerable to my end users. I certainly don't take a stance saying "well, as my estimates have proven wrong, so no estimate from here on."
That said, I understand there must be a lot of stress on BM. So if you can't give a day-wise estimate, how about a week/month estimate. Say we are looking at end of June or Q2 end or Q3 , that allays some nerves and certainly better than "we don't know when we will be ready (will it ever be?)"
-
Here is how to make it fair - if I am not mistaken the feb 28 snapshot would only convert to 50% of BTSX (if that is not the case then this idea needs fine tuning)
Could we find a fair way to allow post feb 28 to also convert to BTSX but at a proper rate? I.e perhaps at 1:10 ratio since some people put in 150BTC on some days close to Feb 28. Perhaps post Feb 28 would yield only 1/10th. And do this until they release it that way they have incentive to do it sooner.
Sent from my iPhone using Tapatalk
The Feb 28 snapshot was announced with something like a months notice, and people like me donated before then based on that announcement. It would hardly be fair on us if Invictus reneged on that date would it? Im tired of hearing people suggesting changing the snapshot - its a non starter.
If you want to get BTS-X cheap then there will be another opportunity once its made liquid but before the BitAsset trading is enabled.
-
Nooo my point was what was announced before stays. It just distributes some to the post Feb 28 at a smaller rate as well. Or is 100% of BTS allocated with the feb 28 snapshot?
Sent from my iPhone using Tapatalk
-
Yes 100% of BTS-X was allocated from the 28th Feb snapshot of AGS donations and PTS holdings.
-
Nooo my point was what was announced before stays. It just distributes some to the post Feb 28 at a smaller rate as well. Or is 100% of BTS allocated with the feb 28 snapshot?
Sent from my iPhone using Tapatalk
It is 100% allocated with Feb 28 snapshot. It is done can't be change now. I think Stan and Bytemaster pretty much cover why we have the delay. And for the estimates here is Stan answer :
Alas, we promised 2-weeks notice, so that means the snapshot had to happen 2 weeks before the earliest possible date.
The alternative we plan to use in the future is to wait until latest possible date (when testing is totally complete), and then wait two more weeks before we can launch.
This is also why we no longer release estimates or target dates. We'd like to share our hopes and goals, but that has proven to be counterproductive.
.
So to me it is pretty clear, From now on no more estimates they will announce the lunch when they are 100% sure.
-
That's why we stopped giving estimates. We don't know what we don't know. When our conventional mining solution for PTS pointed out that mining was centralizing and unprofitable, a new invention was necessary. Our supporters have watched (and helped) us make that invention in real time - with access to every chin-scratching twist and turn of our thinking. Is that not being treated like adults?
Here's the list of R&D progress we've made pursuing that invention, as summarized by bytemaster a week or so ago. None of it could be anticipated until we did the work, thought the thoughts, listened to input from this forum, scratched our chins and engineered the required breakthroughs:
Yes, I released a white paper on DPOS last week and have implemented a large part of it and will be testing it in the days ahead. Resolving the security model in a way that one can thoroughly understand and prove is secure was a major challenge. You can follow discussions on this forum where about a half dozen variations / iterations where vetted and found wanting... Let me list the evolution:
1) Mining with Momentum... tossed due to centralization and non profitability
2) Transactions as Proof of Stake white paper (Nov 28th, 2013) adjusted mining difficulty by stake. Suffered from weakness on deciding who should produce the next block.
3) Ripple Consensus + TaPOS was the concept in January at the Miami event through Feb, but after attempted implementation we realized it had several deal breakers:
a) the unique node list was an invite-only group and a point of trust
b) the UNL was not compensated in any way
c) the bandwidth requirements / scalability were an issue
4) Fall back on a simple mining + TaPOS and various variations on equations for option 2. All of these variations suffered from many potential attacks and would require many confirmations. It became too complex to analyze. (Feb through March)
5) Single trustee which could be fired... the process was too manual but otherwise sound.
6) Delegated POS this solution has been reviewed, found to be decentralized, fast, and secure without ambiguity. We have finally resolved the issue.
In that time we also identified problems and found solutions to several market manipulation attacks. These need to be implemented, but then we should be good to go.
As you can see R&D is not predictable when you are at the bleeding edge of innovation and solving problems as they are discovered.
We are now much, much stronger than we were then and the total industry value proposition is bigger than ever.
I have been lurking through the forums; this statement just made me register on the forum. If I am reading it correctly, your solution to incorrect estimates (not only BTSX but keyhotee too) is not to provide an estimate any more. So basically, what you are saying is "we will never try to make a correct estimate, so yeah lets leave it?" I am just dumbfounded by this way of thinking. :-X
While I also appreciate the amount of work BM has put in compiling the list. The question really is - why weren't they tried before the snapshot or March dates? Is it going to be I3's policy to make a commitment, generate an interest from the public and then say this doesn't work so trust us for some more time? I guess you might think there is a whole new value proposition here so, I3 can get away with its tardiness.
I also work in the IT industry. Whenever I am asked for an estimate, my efforts are always padded with 30% of rework, rethink and general avoidance of being rushed. So if I need 10, I say 13.
In worst case, if I do cross 13 and there is 14/15th day, I am answerable to my end users. I certainly don't take a stance saying "well, as my estimates have proven wrong, so no estimate from here on."
That said, I understand there must be a lot of stress on BM. So if you can't give a day-wise estimate, how about a week/month estimate. Say we are looking at end of June or Q2 end or Q3 , that allays some nerves and certainly better than "we don't know when we will be ready (will it ever be?)"
3i suck!
-
3i suck!
As much as I want to agree with you but I really can't. It's true that bts has been delayed over and over which is the source of your 3i disappointment. But let me tell you this , a wise investor has enormous amount of patience and will make his/her at exactly the way he or she wants to move. Now instead of grudging on 3i, invest on other crypto. Balance your portfolio . Indeed it is the best ever remedy to wait and see situation. wanna tip? take a look at pawncoin. They wlll be releasing their own exchange and witness the skyrocket phenomenon that is happening now.
-
3i suck!
As much as I want to agree with you but I really can't. It's true that bts has been delayed over and over which is the source of your 3i disappointment. But let me tell you this , a wise investor has enormous amount of patience and will make his/her at exactly the way he or she wants to move. Now instead of grudging on 3i, invest on other crypto. Balance your portfolio . Indeed it is the best ever remedy to wait and see situation. wanna tip? take a look at pawncoin. They wlll be releasing their own exchange and witness the skyrocket phenomenon that is happening now.
pawncoin is not a very good investment. slow block time, mining, and no community does not translate to a good investment. diversification is not the best investment strategy. the best investment strategy is knowing what you are investing in. if you are not comfortable waiting for the development of this platform you clearly do not understand what you are investing in. take the time to understand the situation better. take the time to understand the concepts that bitshares brings to the table and you might find that your concerns are not fully warranted.
-
3i suck!
As much as I want to agree with you but I really can't. It's true that bts has been delayed over and over which is the source of your 3i disappointment. But let me tell you this , a wise investor has enormous amount of patience and will make his/her at exactly the way he or she wants to move. Now instead of grudging on 3i, invest on other crypto. Balance your portfolio . Indeed it is the best ever remedy to wait and see situation. wanna tip? take a look at pawncoin. They wlll be releasing their own exchange and witness the skyrocket phenomenon that is happening now.
pawncoin is not a very good investment. slow block time, mining, and no community does not translate to a good investment. diversification is not the best investment strategy. the best investment strategy is knowing what you are investing in. if you are not comfortable waiting for the development of this platform you clearly do not understand what you are investing in. take the time to understand the situation better. take the time to understand the concepts that bitshares brings to the table and you might find that your concerns are not fully warranted.
If you are referring to my comments above, I would clearly stay with bitshare as I believe in its principles. But time is more important than anything else. I was soothing the pain of somebody's agony of waiting . Let someone earn a quick buck or two so that the anguish lessens. Eventhough what you have said about pawncoin is true , look at their project timeline. It is almost in sync. That is why short term investors are having hands on this opportunity. But when the smoke is clear as to say, people might dump it . At least they have earned from their investment in such small period of time.
-
Thats so amateur! Yes go ahead and
buy so I can sell to u for a quick buck. Whos going to buy when everyone is thinking the same thing? Only way is if there is a service implemented to offer utility then that iis what its worth... but usually devs will price it in before announcement so really its not a wise move unless you wanna get caught holding bags.
-
I have been lurking through the forums; this statement just made me register on the forum. If I am reading it correctly, your solution to incorrect estimates (not only BTSX but keyhotee too) is not to provide an estimate any more. So basically, what you are saying is "we will never try to make a correct estimate, so yeah lets leave it?" I am just dumbfounded by this way of thinking. :-X
While I also appreciate the amount of work BM has put in compiling the list. The question really is - why weren't they tried before the snapshot or March dates? Is it going to be I3's policy to make a commitment, generate an interest from the public and then say this doesn't work so trust us for some more time? I guess you might think there is a whole new value proposition here so, I3 can get away with its tardiness.
I also work in the IT industry. Whenever I am asked for an estimate, my efforts are always padded with 30% of rework, rethink and general avoidance of being rushed. So if I need 10, I say 13.
In worst case, if I do cross 13 and there is 14/15th day, I am answerable to my end users. I certainly don't take a stance saying "well, as my estimates have proven wrong, so no estimate from here on."
That said, I understand there must be a lot of stress on BM. So if you can't give a day-wise estimate, how about a week/month estimate. Say we are looking at end of June or Q2 end or Q3 , that allays some nerves and certainly better than "we don't know when we will be ready (will it ever be?)"
3i suck!
No they don't suck. They are just tardy, thats all.
Until they release a working product - for which they have failed twice - keyhotee and now this, there is no way to judge their work.
-
3i suck!
As much as I want to agree with you but I really can't. It's true that bts has been delayed over and over which is the source of your 3i disappointment. But let me tell you this , a wise investor has enormous amount of patience and will make his/her at exactly the way he or she wants to move. Now instead of grudging on 3i, invest on other crypto. Balance your portfolio . Indeed it is the best ever remedy to wait and see situation. wanna tip? take a look at pawncoin. They wlll be releasing their own exchange and witness the skyrocket phenomenon that is happening now.
pawncoin is not a very good investment. slow block time, mining, and no community does not translate to a good investment. diversification is not the best investment strategy. the best investment strategy is knowing what you are investing in. if you are not comfortable waiting for the development of this platform you clearly do not understand what you are investing in. take the time to understand the situation better. take the time to understand the concepts that bitshares brings to the table and you might find that your concerns are not fully warranted.
If you are referring to my comments above, I would clearly stay with bitshare as I believe in its principles. But time is more important than anything else. I was soothing the pain of somebody's agony of waiting . Let someone earn a quick buck or two so that the anguish lessens. Eventhough what you have said about pawncoin is true , look at their project timeline. It is almost in sync. That is why short term investors are having hands on this opportunity. But when the smoke is clear as to say, people might dump it . At least they have earned from their investment in such small period of time.
Thats the issue isnt? If anyone raises a concern about the tardiness of 3I for them its all about the money. It certainly can't be about people's expectation, can it?
Given the onslaught of coins we had, the reason I chose PTS was because I really liked the idea. Make no mistake most start-up funding (which was PTS' purpose, wasn't it?) happens because people like the idea. Now liking an idea and believing in it are two separate things. Belief comes later when the person asking for funding can actually prove himself.
- So I was eagerly waiting for Keyhotee release in Dec. I could judge their work and then chose to believe in them -- it dint happen.
- I reset my expectations to BTS-X in March, dint happen.
I was ready to reset it to May-Jun too but then I hear - we don't know when will we be ready..and thats certainly not the kind of belief I am looking at.
-
We are testing now and have working transfers. Working toward your goal of being liquid ASAP.
Sent from my iPhone using Tapatalk (http://tapatalk.com/m?id=1)
-
The biggest problem right now is the 28 Feb snapshot. As we get farther away from the date, it keeps looking worse (and is generating a lot of heartache amongst investors) and creating more pressure on Dan and co.
The logical order of releases would have been Test DPOS -> Real DPOS Coin -> BTS Me -> BTS X. I have a suggestion (will probably be hated by most) which might get around this.
For starters, PTS mining and AGS donation has to be stopped and all these along with the Feb 28th snapshot merged in a single coin of 4m supply (lets call it Tokens) and the social consensus would state that at least 20% of any DAC should honour these Tokens (instead of 10% each for PTS and AGS). Also, the Feb 28 snapshot will NOT be used for BTS X.
So, the distribution will be
1> Some 1.8m for PTS will become 1.8m Tokens
2> Roughly 1.1m AGS will become 1.1m Tokens
3> The remaining 1.1m can be distributed amongst Feb 28 snapshot and/or award Tokens directly to I3 which will be used only as payments/bounties (and can't be sold directly by I3).
The ratios can be adjusted accordingly to try and even out the playing field amongst the various types of investors. In this scheme, I think all the sets are being accommodated.
1> PTS holders will still get the same portion.
2> Ditto for AGS but as an added bonus they are liquid (BM is trying to get some form of BTS XT out quickly so that those AGSers can have some form of liquid asset).
3> PTS and AGSers before Feb 28th, who got in at a higher price due to the promise of BTS X will be partly compensated by getting awarded extra tokens. If you think that is not enough, that snapshot may also be used to award BTS Me, which is expected to be the first DAC with some features.
In doing so, initially BM releases a test version to try out DPOS. If it works well, the conversion into Tokens happen, which will mean it will be tested on a real coin listed on exchanges and having a good market cap. At this point, a mining pool which awards Tokens can also be set up. Remember, Tokens at this point will be the first DPOS coin, and with the rage about PoS these days, having a supposedly superior (we have to see how it works in practice), we should get a lot of buzz.
Then, BTS Me with some functionality (and maybe honouring Feb 28th snapshot) gets released, and after that every DAC honours Tokens directly - no more having families of DACs with with its own ProtoDACs to provide distribution and all. This simplifies matters to a large extent as you know how may of these Tokens you have and so what percentage you will get - no more trying to calculate separately for PTS, AGS or even BTS XT (for future BTS Xs). Of course, future DAC creators may award differently, like 20% for Tokens and, say, 10% for Bitshares Me, but that is his own choice.
Even if you guys think I am not bonkers, still there is room to adjust the numbers/ratios to even it out amongst the various investors. I just like the idea of having a simple, elegant system to award me the DACs (instead of the complicated mess we have now). The biggest benefit, IMO, is that the infamous Feb 28 snapshot monkey is off the back.
*goes back to smoking that weird plant thingy*
‘still there is room to adjust the numbers/ratios to even it out amongst the various investors. I just like the idea of having a simple, elegant system’
Try suggesting honoring the pre 28th AGS with at least 3:1 ratio, or better, to the other AGS in future DAC’s.
Reasons?
– some of the early investors paid 10X compared to investors now (see currencydebt post above)
–others of them did not have the benefit of ‘... a longer time horizon that would have given them the wisdom to spread out their own investments and thus maximize the AGS per PTS / BTC...’, even though this spreading would have resulted in smaller share for them(*1) (see bytemasters post above)
–the after Feb 28th AGS are late coming diluters of the founding AGSers share; those late comers are also more stupid ones - as they supported someone after this person promised them something and while being very late, instead of trying to deliver on his promises, went to preach his other ideas, improving the concept of his non-existing product and god knows what else. But do not think he moved the delivery day ahead of the possible/reasonable date… no,no ..it is a coincidence that he bunched the donations in a short period and having those funds secured (and not depending on his behavior afterwards), went on doing what he really wanted to do in the first place.
(*1) If you what to check that this is the case - compare what percentage of BTS one with say 100,000 PTS would have if he spread its donation equally from Jan1 to Feb 28 and compare this to what percentage he will get if he spreads same 100K PTS from Jan1 to Today – the difference is about 50% more in the first scenario (and this is without including the reasonable expectation that the donations would have been higher after 28th if such donations gave a chance to participate in the snapshot)
‘…AGS donation has to be stopped…’ here, there is no need donations to be stopped. Just make clear to them donors they can continue donating, but they will not be honored in any future DAC’s with anything more than 1%... as this is the social consensus…
Now I expect to have a good time in the following weeks in a better place with no internet connection …I just hope when I check back this project to be something more than ‘improved’ product existing mainly in somebody’s head…
The point was since in my scheme, before 28 Feb'ers are getting screwed on BTS XT (they will be getting less than 50% of the original amount), can we find a way to compensate them? (that would include me too, btw).
My compensation package was
1> Share in all future DACs - insurance, music, lotto etc (since that snapshot is now part of the unified 'tokens').
2> BTS Me will get awarded with the Feb 28 snapshot. If that still doesn't sound enough then maybe the first BTS X chain, or the first 2, or the first 3, or DNS.
For all those who bought/donated after snapshot date, their stake in future DACs is reduced, but they also get a share in BTS X.
Why take the trouble? My main reasons were
1> Simplify the process. We will have a fixed number of the 'tokens' and we will know exactly how much % of each DAC we are getting (instead of the complicated calculations we were doing before the Feb 28 snapshot).
2> Have a working product - a stand alone DPoS coin which can be tested in real world, and which will show an unique I3 product.
3> Allow Bytemaster the time to release a working BTS X when it is ready. Right now, he is trying to rush out a DPoS coin named as BTS XT so as to make AGS investors liquid (see the post above).
-
The point was since in my scheme, before 28 Feb'ers are getting screwed on BTS XT (they will be getting less than 50% of the original amount), can we find a way to compensate them? (that would include me too, btw).
This isn't happening. Don't use active tense or it could case FUD.
-
They should have made this liquid even if it is on a some centralized website in the short term. Or they could have made it piggy back on another currency for the POW. (Make each block of BTS be proof of work using hash of another crypto blocks hash so in effect it can not be gamed) do this so people can exchange BTSX until the right algorithm is ready. If it's a week or two more that's fine but the lack of contingency plan is really hurting their reputation. Plus they wouldn't have to rush the solution if they had a contingency plan.
Sent from my iPhone using Tapatalk
This is the inherent problem with many in the crypto space. So many ppl are speculating rather than investing. If you invest in a product and fully believe in its potential you understand that development and growth do not happen over night. It may not even happen in a year. One of the reason why I gravitated to I3 is because it is a company not a simply a crypto project like nxt. If you are fortunate to acquire stake in company during its early stages traditionally your equity will not really be liquid until the ipo. Crypto-equity changes this, but it is important to understand that we are in a transitional period in which the traditional paradigm has not fully changed. If you wanted to speculate and keep your stake liquid you could have done that with pts, but if you wanted to be a value investor you would certainly put your money in the ags. The whole point of pts/ags and the social consensus was to attract a community of loyal investors who rather than dumping the crypto-equity when the product was released would hold on to it in order to realize potentially higher returns in the long run. You can't really complain about how I3 has conducted themselves because they have been entirely transparent through out the whole process and have provided you with an investment vehicle that only serves to afford you the greatest return on your investment.
Lastly ppl keep talking about a contingency plan. Is that a euphemism for a sub par product? I didn't invest my money for that purpose. Please get out of this mentality of quick profits and understand that you stand to gain a lot more by investing for the long term. If you realized the potential of bitcoin when it first came out and sold during the early $30 bubble I imagine you would be kicking yourself in the head right now.
-
The point was since in my scheme, before 28 Feb'ers are getting screwed on BTS XT (they will be getting less than 50% of the original amount), can we find a way to compensate them? (that would include me too, btw).
This isn't happening. Don't use active tense or it could case FUD.
I mentioned 'my scheme', and clearly I am not an I3 employee or even a big investor.
-
I would have sold "some" at $30 and would have not kicked myself :)
Sent from my iPhone using Tapatalk
-
They should have made this liquid even if it is on a some centralized website in the short term. Or they could have made it piggy back on another currency for the POW. (Make each block of BTS be proof of work using hash of another crypto blocks hash so in effect it can not be gamed) do this so people can exchange BTSX until the right algorithm is ready.
It would have been a bad decision to release something crappy just for the purpose of making it liquid. It just would have wasted a bunch of time and delayed the ultimate goals of what they are doing. No one would have bought XT shares that were hosted on an I3 server...
-
We are testing now and have working transfers. Working toward your goal of being liquid ASAP.
Great! :)
-
We are testing now and have working transfers. Working toward your goal of being liquid ASAP.
Great! :)
+5% +5%
-
We are testing now and have working transfers. Working toward your goal of being liquid ASAP.
Sent from my iPhone using Tapatalk (http://tapatalk.com/m?id=1)
+5%
Happy to hear that.
Only slightly concerned, it was our goal but somehow not yours.
-
We are testing now and have working transfers. Working toward your goal of being liquid ASAP.
Sent from my iPhone using Tapatalk (http://tapatalk.com/m?id=1)
+5%
Happy to hear that.
Only slightly concerned, it was our goal but somehow not yours.
Well, it has been our goal as well.
-
Big update here...
https://bitsharestalk.org/index.php?topic=3812.msg53938#msg53938
-
This is a monumental step towards making BTS liquid. Blockchain will be tested in real-time scenario. Cross our fingers and let it be bug-free. 8)
-
https://bitsharestalk.org/index.php?topic=3812.msg53938#msg53938
'We should have P2P fully integrated and tested this week under the trustee model. At this point we will launch the chain with an intention of doing a hard-fork to activate DPOS once enough delegates have been elected and the system is sound. '
+5%
GREAT!
Now we are talking!
My recent aggressive, and in more than one occasion crossing the line of offensive, posts are paying dividends. :)))
Clearly all progress is the result of your posts. :P
http://xkcd.com/552/
-
We should have P2P fully integrated and tested this week under the trustee model. At this point we will launch the chain with an intention of doing a hard-fork to activate DPOS once enough delegates have been elected and the system is sound.
Whoops, that's an estimate!
Place your bets now everyone!
-
wow a Betting DAC :o
-
We should have P2P fully integrated and tested this week under the trustee model. At this point we will launch the chain with an intention of doing a hard-fork to activate DPOS once enough delegates have been elected and the system is sound.
Whoops, that's an estimate!
Place your bets now everyone!
Dang! I can't let him out of my sight for one minute!
-
https://bitsharestalk.org/index.php?topic=3812.msg53938#msg53938
'We should have P2P fully integrated and tested this week under the trustee model. At this point we will launch the chain with an intention of doing a hard-fork to activate DPOS once enough delegates have been elected and the system is sound. '
+5%
GREAT!
Now we are talking!
My recent aggressive, and in more than one occasion crossing the line of offensive, posts are paying dividends. :)))
Clearly all progress is the result of your posts. :P
http://xkcd.com/552/
Sure I have whiskers, so the ‘logic’ is that I am a cat!
+
You do not let one be happy Troglodactyl ....
-
Great job Bytemaster and team!!!!
BM please make sure you eat a great diet, get plenty of rest and PLEASE PLEASE get some exercise so that your mind can be at ease and your stress levels lower. Lower stress levels means you have a higher capacity for creative thought.
Pretty excited for what's to come.
-
(http://www.my-favorite-coloring.net/Images/Large/Famous-characters-Troll-face-OMG-Rage-Face-139671.png) ;)
-
(http://transparentwithmyself.files.wordpress.com/2012/03/child-very-excited1.jpg)
-
I tried out building, running and also the manual test yesterday. Unless I completely missed something, the only functions available in the client are for importing private keys, generating new receiving addresses and sending bitshares to an address.
Is there any way to test trustee block generation? I tried looking at log.txt, but I could only see votes being cast.
What is the server's role in the setup?
Did both clients use the server at the same time?
What does the server know about the clients? For example, does the server know if one client is a trustee?
I'm not sure what I should've been expecting from an update dubbed "a big update", it felt like I was using a very crippled bitcoin wallet. There wasn't an asset generation option anywhere to be found, but it does make bitshares liquid, which is good for everyone.
I tried building today's pull from the bitshares_toolkit repo, but it's failing with :
/bitshares_toolkit/libraries/rpc/rpc_client.cpp: In member function ?bts::blockchain::transaction_id_type bts::rpc::detail::rpc_client_impl::sendtoaddress(const bts::blockchain::address&, const bts::blockchain::asset&, const string&, const string&)?: /home/esh/software/coins/bitshares_toolkit/libraries/rpc/rpc_client.cpp:78:193: error: no matching function for call to ?fc::rpc::json_connection::call(const char [14], fc::variant, fc::variant, fc::variant, fc::variant)? return _json_connection->call("sendtoaddress", fc::variant((std::string)address), fc::variant(amount), fc::variant(comment), fc::variant(comment_to));
Also, the ' Launch the Clients ' section of the manual test lists the command to run the clients with a Bitshares-PTS address rather than a true Bitshares address, and that fails without an error message so it should be fixed too.
Thanks for keeping us posted.
-
I create a git to coding GUI.
https://github.com/cgafeng/BTX (https://github.com/cgafeng/BTX)
need somebody help edit the CMakeLists.txt.
+5% +5%
-
I create a git to coding GUI.
https://github.com/cgafeng/BTX (https://github.com/cgafeng/BTX)
need somebody help edit the CMakeLists.txt.
+5% +5%
I move the code to https://github.com/cgafeng/bitshares_toolkit (https://github.com/cgafeng/bitshares_toolkit), in Branch name Branch_bts_xt_ui.
The ui code is in bitshares_toolkit/programs/bts_xt_ui/.
until now, there are something work well:
1. RPC connecting to bts_xt is work.
2.have a launch window.
3.have a create wallet window.
4.can compile on windows and mac.
-
I have made some major updates to the RPC interface:
1) it now supports HTTP + Basic Auth and is thus much closer to being compatible with Bitcoin
2) I have integrated a basic webserver into the client which means that we can use jquery + RPC requests to build a web interface for the wallet in very short order.
Tonight I will be documenting the RPC interface and providing a proof-of-concept web-based wallet interface. This will make using the CLI unnecessary and give a much better experience out of the gate.
More updates to follow.
-
I have made some major updates to the RPC interface:
1) it now supports HTTP + Basic Auth and is thus much closer to being compatible with Bitcoin
2) I have integrated a basic webserver into the client which means that we can use jquery + RPC requests to build a web interface for the wallet in very short order.
Tonight I will be documenting the RPC interface and providing a proof-of-concept web-based wallet interface. This will make using the CLI unnecessary and give a much better experience out of the gate.
More updates to follow.
+5%
-
Tonight I will be documenting the RPC interface and providing a proof-of-concept web-based wallet interface. This will make using the CLI unnecessary and give a much better experience out of the gate.
These are such big development . A web-based wallet is something I am hoping for. It can be vulnerable but pretty much handy.
-
Tonight I will be documenting the RPC interface and providing a proof-of-concept web-based wallet interface. This will make using the CLI unnecessary and give a much better experience out of the gate.
These are such big development . A web-based wallet is something I am hoping for. It can be vulnerable but pretty much handy.
Note: this will be local host and not a web service... though if done right a lot of the code could be reused for a web service.
-
Sounds great!! Thanks for the update!
Sent from my iPhone using Tapatalk
-
Bytemaster, do you have a solution yet for how transaction fees are paid for direct BitUSD -> BitGold swaps?
I guess the problem of destroying some of the BitAssets as tx fees is that it could theoretically make it impossible for shorts to cover their positions, because there arent enough BitAssets to go around as they were destroyed in tx fees.
Thats why Im wondering if youve got a solution for this.
-
Bytemaster, do you have a solution yet for how transaction fees are paid for direct BitUSD -> BitGold swaps?
I guess the problem of destroying some of the BitAssets as tx fees is that it could theoretically make it impossible for shorts to cover their positions, because there arent enough BitAssets to go around as they were destroyed in tx fees.
Thats why Im wondering if youve got a solution for this.
Yes, I have a solution to this problem. You will be able to pay trx fees in BitUSD or BitGold at 2x the going rate of paying them in the native shares. The fees will the be used to purchase BTS on the market and the purchased BTS will be destroyed.
-
Bytemaster, do you have a solution yet for how transaction fees are paid for direct BitUSD -> BitGold swaps?
I guess the problem of destroying some of the BitAssets as tx fees is that it could theoretically make it impossible for shorts to cover their positions, because there arent enough BitAssets to go around as they were destroyed in tx fees.
Thats why Im wondering if youve got a solution for this.
Yes, I have a solution to this problem. You will be able to pay trx fees in BitUSD or BitGold at 2x the going rate of paying them in the native shares. The fees will the be used to purchase BTS on the market and the purchased BTS will be destroyed.
A very elegant solution +5%
-
Bytemaster, do you have a solution yet for how transaction fees are paid for direct BitUSD -> BitGold swaps?
I guess the problem of destroying some of the BitAssets as tx fees is that it could theoretically make it impossible for shorts to cover their positions, because there arent enough BitAssets to go around as they were destroyed in tx fees.
Thats why Im wondering if youve got a solution for this.
Yes, I have a solution to this problem. You will be able to pay trx fees in BitUSD or BitGold at 2x the going rate of paying them in the native shares. The fees will the be used to purchase BTS on the market and the purchased BTS will be destroyed.
A very elegant solution +5%
Neat +5%
-
What happens with the extra bitAssets paid as fee?
All is converted to BTS or as much as needed.
-
What happens with the extra bitAssets paid as fee?
All is converted to BTS or as much as needed.
All is converted to BTS and destroyed.
-
This week will launch the test blockchain,is it true?is that means my xts will be liquid?
-
What happens with the extra bitAssets paid as fee?
All is converted to BTS or as much as needed.
All is converted to BTS and destroyed.
+5% +5%
bts x is the core
-
1. Does 5% inactivity fee apply to bitAssets like bitUSD?
2. I remember that the interest of collateral (XTS) will go to holders of bitAsset. I believe this can support the price of bitAsset and prevent its price goes to 0. As the interest is got from transaction fees, will this calculation be based on block by block? If yes, I wonder what is the simplest way to implement it in wallet code as for each block you need to calculate that and adjust the balance of bitAsset holder.
-
1) yes 2) there is no interest for the first chain and the bitasset's price is supported by a market peg, not interest. When there is a chain with interest it comes out of short position's collateral and not tx fees.
Sent from my SCH-I535 using Tapatalk
-
1. Does 5% inactivity fee apply to bitAssets like bitUSD?
2. I remember that the interest of collateral (XTS) will go to holders of bitAsset. I believe this can support the price of bitAsset and prevent its price goes to 0. As the interest is got from transaction fees, will this calculation be based on block by block? If yes, I wonder what is the simplest way to implement it in wallet code as for each block you need to calculate that and adjust the balance of bitAsset holder.
1) Yes the inactivity fee applies to all balances. The BitUSD collected by this fee is sold for BTS and the BTS is destroyed to pay dividends to shareholders.
2) A long time a go when I was implementing dividends via direct accounting this applied. Once I switched to implicit dividends (via fee destruction) it was no longer viable to pay this way.
Instead what the dividends on collateral does is increase the backing on the BitUSD over time.
-
1) Yes the inactivity fee applies to all balances. The BitUSD collected by this fee is sold for BTS and the BTS is destroyed to pay dividends to shareholders.
2) A long time a go when I was implementing dividends via direct accounting this applied. Once I switched to implicit dividends (via fee destruction) it was no longer viable to pay this way.
Instead what the dividends on collateral does is increase the backing on the BitUSD over time.
To have something which price linked with fiat is so important that it's very important to make bitUSD and bitCNY work.
I think it was a good idea to support bitUSD value with interest of collateral. Actually the burning of bitUSD transaction fee has the similar effect but you've decided to buy and burn BTS instead.
Now with implicit dividends I think we can still get the similar approach by returning same amount of BIP instead of BTS when shorters cover the short. The dividends (new collateral BIP - old collateral BIP) can still go to all the holders of bitUSD. It's more complex in implementation but I think it's really important to have some thing supporting the bitAsset to prevent price going to 0 instead of just a name link between bitUSD and USD. I hope we can find an easier way to dispatch dividends.
-
Shouldn't we will have the xts this week as BM said?Miss the deadline again?good job I3.good job BM.Any excuses?lol
-
What deadline? They already are testing things.
-
Shouldn't we will have the xts this week as BM said?Miss the deadline again?good job I3.good job BM.Any excuses?lol
PLEASE DO NOT PUSH THEM SO HARD.
哥们，之前铺天盖地的抱怨贴已经让他们很清楚地知道大家的不满了，再催真的会适得其反的。
我希望出来的产品是没有明显漏洞能经得起考验的。如果他们有信心发布，我相信是不会藏着掖着的。都等了这么久，再给他们一些时间吧。更何况他并没有说这周发布吧?
-
Do not let people complains affect the perfection of the product. I want Bitshares X to be released only when it works perfectly!
People are complaining because they are short term speculators who have locked their investment for more than anticipated originally. Let them complain... I am investing in the long run and I do not wish the first I3 product not to work as it supposed to work. A couple of months more is nothing compared to the eternity ;)...
Short term speculation really pisses me off. This is the disaster of modern capitalism. You have to learn to invest for the long run and not for short term profits. Do not rush your investments.
-
Do not let people complains affect the perfection of the product. I want Bitshares X to be released only when it works perfectly!
People are complaining because they are short term speculators who have locked their investment for more than anticipated originally. Let them complain... I am investing in the long run and I do not wish the first I3 product not to work as it supposed to work. A couple of months more is nothing compared to the eternity ;)...
Short term speculation really pisses me off. This is the disaster of modern capitalism. You have to learn to invest for the long run and not for short term profits. Do not rush your investments.
You gotta be realistic here too. People have bills to pay, it's almost summer, and Invictus promised to release months ago.
What do you expect? Of course everyone is impatient after waiting for months. Also we are witnessing the rise of pure PoS when Bitshares probably is what initiated that in the first place. So other coins will get media attention and market cap while the Bitshares community gets to jealously watch.
It's an "are we there yet?". It's not an "I need my money, gimme!".
-
I can say that progress is picking up speed and our development is improving. Our designs are stabilizing and our initial product will be more than the MVP we would have launched earlier.
-
I don't understand why can't the people proclaiming to be long term holders get through their thick heads. No one, not even the "short term speculators", benefits from a sub-par product. If it is crap, the PTS held wont be even worth $4 or the BTS wont crawl even $1 mark. So the short or long term, both want the same thing - a working product.
Anyone in the IT side of things will tell you -- most code doesn't work perfectly on the first go. So all this nonsense about perfect code should stop. Just get us a working product, test it, improve and iterate it. If things were so perfect, bitcoins wouldn't require so many iterations.
-
I think the metric we are going for is stability of API and blockchain vs being bug free. The magnitude of changes that we are introducing is decreased significantly so we are getting closer.
-
Here https://bitsharestalk.org/index.php?topic=3812.msg55376#msg55376
BM said: “Today I implemented support for multi-sig, cross-chain-trading”
Can you tell us more about that? (comprehendible for the age group of 4 to 7 year old would be best!)
-
How about we let him develop it rather than asking more questions?
-
Here https://bitsharestalk.org/index.php?topic=3812.msg55376#msg55376
BM said: “Today I implemented support for multi-sig, cross-chain-trading”
Can you tell us more about that? (comprehendible for the age group of 4 to 7 year old would be best!)
I added the transaction validation to support the following algorithm:
https://en.bitcoin.it/wiki/Atomic_cross-chain_trading
-
How about we let him develop it rather than asking more questions?
Djeezus, sorry for asking but this could be extremely important, somewhat important or not important at all…. but give me a break, I am not asking him to implement:
- a blockchain that captures/integrates the world's energy (*1),
- an assisted suicide block chain (*2),
- or do something about Maidsafe, which apparently is coming up with the app of all apps (that does nothing… sorry for misspeaking… is so great we will be all forced to buy it, no matter if it is in our best interest to do so or not) (*3)
(*1) https://bitsharestalk.org/index.php?topic=4398.msg55387#msg55387
(*2) https://bitsharestalk.org/index.php?topic=4399.msg55406#msg55406
(*3) https://bitsharestalk.org/index.php?topic=4090.msg55368#msg55368
-
hahah tonyk, my man. keeping it real when others won't.
-
is the atomic cross-chain trading based on sergio's implementation here:
https://bitcointalk.org/index.php?topic=91843.0
-
bytemaster，are you going to have sergio reviewed your bitshares toolkit code ?
-
is the atomic cross-chain trading based on sergio's implementation here:
https://bitcointalk.org/index.php?topic=91843.0
I think it is more like gmax's protocol with timeouts:
https://bitcointalk.org/index.php?topic=91843.msg1011956#msg1011956
-
bytemaster，are you going to have sergio reviewed your bitshares toolkit code ?
YEs
-
holy moly .. wohooo
-
bytemaster，are you going to have sergio reviewed your bitshares toolkit code ?
YEs
+5%
-
+5% +5% +5%
-
+5% +5% +5%any status update?thanks.
-
Can i ask where all the latest BTSX code is?
The blockchain & p2p code that is reusable for all DACs is here:
https://github.com/BitShares/bitshares_toolkit
Its had lots of recent changes by Bytemaster.
However the BTSX specific code hasnt had any updates from Bytemaster for 2 months:
https://github.com/InvictusInnovations/BitShares
Are you just keeping the BTSX specific stuff local for the time being, or is it somewhere else?
Even though youre focusing on making BTSX liquid first without BitAsset trading, I would have thought there would still be many recent changes to BTSX.
-
Each time I see a network connectivity graph, I can't help wonder what it would take to have it stall or fork. It's not obvious to me how nodes find and prefer others, though perhaps that has become standard from P2P. Especially with slow churn PoS networks, where there might also be large holders, I can only wonder at what the effect of those might be. NXT has me wondering about how distributed the forgers really are but I guess there might be a risk to all kinds of network. Where nodes are inclined to look to the first they see rather than jumping as far as they can or having some dynamic in the length of each connection, perhaps there is a risk of two sides of the network fighting. In my ignorance I also don't understand what happens to a transaction that is accepted to a block that fails but I guess the original node keeps broadcasting until it hears the transaction has been accepted on the tree it knows. The other thought seeing these graphs is that dataisbeautiful.
-
Can i ask where all the latest BTSX code is?
The blockchain & p2p code that is reusable for all DACs is here:
https://github.com/BitShares/bitshares_toolkit
Its had lots of recent changes by Bytemaster.
However the BTSX specific code hasnt had any updates from Bytemaster for 2 months:
https://github.com/InvictusInnovations/BitShares
Are you just keeping the BTSX specific stuff local for the time being, or is it somewhere else?
Even though youre focusing on making BTSX liquid first without BitAsset trading, I would have thought there would still be many recent changes to BTSX.
Core code that is shared in common for BTS X is where I have been focusing my efforts...
-
Core code that is shared in common for BTS X is where I have been focusing my efforts...
Should we expect from this that its quite likely there will be many unforeseen problems getting BitAsset trading going? Or do you expect that will be relatively simple compared to getting the DPOS networking solid & robust?
-
The exchange transaction code was tested in the past I thought. Market manipulations were discovered after forum was already playing with working btsx on one machine.
-
Here is a status update from the PTS thread a few days ago. For those of yes not involved in the testing. I found this to be insightful.
No work on the exchange has taken place since DPOS since we want to have a solid foundation... I will provide more updates with respect to the exchange in a week or so. Our primary focus is a solid chain foundation with DPOS. So far we are relying on trustee model because the ability to handle natural chain forks automatically is challenging to say the least. We are making the wallet/RPC api as close to compatible with bitcoin as possible which should make the DPOS update to PTS as easy as possible for the exchanges.
-
Here is a status update from the PTS thread a few days ago. For those of yes not involved in the testing. I found this to be insightful.
No work on the exchange has taken place since DPOS since we want to have a solid foundation... I will provide more updates with respect to the exchange in a week or so. Our primary focus is a solid chain foundation with DPOS. So far we are relying on trustee model because the ability to handle natural chain forks automatically is challenging to say the least. We are making the wallet/RPC api as close to compatible with bitcoin as possible which should make the DPOS update to PTS as easy as possible for the exchanges.
I have been working around the clock to get the chain fork handling in order. We have solved a lot of issues in the past week and I hope to have a full up DPOS system with fork handling through basic unit tests in the next couple of days. We are making MAJOR strides here and our team coordination and efficiency has never been higher.
Like everyone I want this thing done as quickly as possible and there is no harder slave driver than myself. Being an imperfect man, I do my best with my weaknesses and unfortunately for us all I am the best we have at this point in time. So I will continue to plow ahead as quickly as possible and appreciate your understanding from one person to another.
In our last public test the trustee failed (crash) and served to remind me that launching with even a well-tested trustee model could have some major issues and liability. I want things out as soon as possible, but the reality is whether we launch sooner or later the problems that we must overcome are the same. Launching sooner just means we are asking the community to do more beta-testing and take greater risks.
-
Here is a status update from the PTS thread a few days ago. For those of yes not involved in the testing. I found this to be insightful.
No work on the exchange has taken place since DPOS since we want to have a solid foundation... I will provide more updates with respect to the exchange in a week or so. Our primary focus is a solid chain foundation with DPOS. So far we are relying on trustee model because the ability to handle natural chain forks automatically is challenging to say the least. We are making the wallet/RPC api as close to compatible with bitcoin as possible which should make the DPOS update to PTS as easy as possible for the exchanges.
I have been working around the clock to get the chain fork handling in order. We have solved a lot of issues in the past week and I hope to have a full up DPOS system with fork handling through basic unit tests in the next couple of days. We are making MAJOR strides here and our team coordination and efficiency has never been higher.
Like everyone I want this thing done as quickly as possible and there is no harder slave driver than myself. Being an imperfect man, I do my best with my weaknesses and unfortunately for us all I am the best we have at this point in time. So I will continue to plow ahead as quickly as possible and appreciate your understanding from one person to another.
In our last public test the trustee failed (crash) and served to remind me that launching with even a well-tested trustee model could have some major issues and liability. I want things out as soon as possible, but the reality is whether we launch sooner or later the problems that we must overcome are the same. Launching sooner just means we are asking the community to do more beta-testing and take greater risks.
I don't know how the others think on the community. But from me you have 100% support. I am not a programmer so I can not help this way, but I will invest time and even more PTS/AGS, and will wait as long as it needs to witness bitshares succes... After all what really matters in the end is the journey to Ithaca...
as a real gift to bytemaster I want to dedicate him from my heart the poem "Ithaca" (C. P. Cavafy)
Ithaca
"As you set out on the way to Ithaca
hope that the road is a long one,
filled with adventures, filled with understanding.
The Laestrygonians and the Cyclopes,
Poseidon in his anger: do not fear them,
you’ll never come across them on your way
as long as your mind stays aloft, and a choice
emotion touches your spirit and your body.
The Laestrygonians and the Cyclopes,
savage Poseidon; you’ll not encounter them
unless you carry them within your soul,
unless your soul sets them up before you.
Hope that the road is a long one.
Many may the summer mornings be
when—with what pleasure, with what joy—
you first put in to harbors new to your eyes;
may you stop at Phoenician trading posts
and there acquire fine goods:
mother-of-pearl and coral, amber and ebony,
and heady perfumes of every kind:
as many heady perfumes as you can.
To many Egyptian cities may you go
so you may learn, and go on learning, from their sages.
Always keep Ithaca in your mind;
to reach her is your destiny.
But do not rush your journey in the least.
Better that it last for many years;
that you drop anchor at the island an old man,
rich with all you’ve gotten on the way,
not expecting Ithaca to make you rich.
Ithaca gave to you the beautiful journey;
without her you’d not have set upon the road.
But she has nothing left to give you any more.
And if you find her poor, Ithaca did not deceive you.
As wise as you’ll have become, with so much experience,
you’ll have understood, by then, what these Ithacas mean."
Translated by Daniel Mendelsohn
(Poems by C. P. Cavafy.)
PS Maybe other translations will like you better, you can find them here:
Source: http://www.cavafy.com/poems/content.asp?id=259&cat=1
-
I don't know how the others think on the community. But from me you have 100% support.
+5% support from my side :)
-
‘Being an imperfect man, I do my best with my weaknesses and unfortunately for us all I am the best we have at this point in time.’
BM you are a man of many talents. So many, it seems an enormous task to just choosing how to best spend your time at any point…
What I am getting is – you must work hard on delegating. You do not need to put your hand on every little detail, man! You can have somebody doing the more tedious details… but you do not trust anybody handling those details, you think that because you can do them better you are the one that must do them.
What I am trying to say is, because” [you are] the best we have at this point in time.” does not mean you have to do a particular task.
Spend some percentage of you time to find talent and delegate… I know… I know it is too late for BTS X to do this, but do this ASAP after you have working/somewhat working BTS X product….
Here is good place to start looking for great talent and great minds - topcoder. com
-
‘Being an imperfect man, I do my best with my weaknesses and unfortunately for us all I am the best we have at this point in time.’
BM you are a man of many talents. So many, it seems an enormous task to just choosing how to best spend your time at any point…
What I am getting is – you must work hard on delegating. You do not need to put your hand on every little detail, man! You can have somebody doing the more tedious details… but you do not trust anybody handling those details, you think that because you can do them better you are the one that must do them.
What I am trying to say is, because” [you are] the best we have at this point in time.” does not mean you have to do a particular task.
Spend some percentage of you time to find talent and delegate… I know… I know it is too late for BTS X to do this, but do this ASAP after you have working/somewhat working BTS X product….
Here is good place to start looking for great talent and great minds - topcoder. com
+5%