1
Openledger / Where is OPEN.EOS?
« on: July 21, 2017, 04:40:53 am »
EOS is trading on a number of other exchanges, but not OpenLedger yet. Why not? Is this on the queue to be added, or have you decided to avoid it for some reason?
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Pages: [1] 2
2
Technical Support / Unlinkable block error when syncing
« on: January 30, 2016, 08:24:30 pm »
I've attempted to resync a number of times today and keep stalling out with this:
Any ideas?
Code: [Select]
1270591ms th_a application.cpp:525 handle_block ] Error when pushing block:
3080000 unlinkable_block_exception: unlinkable block
block does not link to known chain
{}
th_a fork_database.cpp:81 _push_block
{"new_block":{"previous":"002ed047b2c977366e45ec5164ae95d2ae84bb97","timestamp":"2016-01-29T01:37:33","witness":"1.6.17","transaction_merkle_root":"0000000000000000000000000000000000000000","extensions":[],"witness_signature":"204303bc91c8cb28cdcc38575ec9547f0dc4970170b831683c75f1f0abbf92d48136505af995804ab9bea416a5f90afe96b7db762fc2dfc033f36083416b9f4d47","transactions":[]}}
th_a db_block.cpp:201 _push_block
1270591ms th_a fork_database.cpp:60 push_block ] Pushing block to fork database that failed to link: 002ed049662d95b06d7e8164b27e204b113511ba, 3067977
1270591ms th_a fork_database.cpp:61 push_block ] Head: 3067959, 002ed0373fd510a23b375e022c62154499b35bbe
1270591ms th_a application.cpp:525 handle_block ] Error when pushing block:
3080000 unlinkable_block_exception: unlinkable block
block does not link to known chain
{}
th_a fork_database.cpp:81 _push_block
{"new_block":{"previous":"002ed0480aea3c92bd537999d865cc7cb3c0a54e","timestamp":"2016-01-29T01:37:42","witness":"1.6.35","transaction_merkle_root":"0000000000000000000000000000000000000000","extensions":[],"witness_signature":"1f5d8a0a03d97498a1d501e39510cec4e92d3db093d5e24cba4b3ab5b09b5661a764686113e417c2753377c6bb7f77d0a39af0231f67ed7fda285477f52145697f","transactions":[]}}
th_a db_block.cpp:201 _push_block
1270591ms th_a fork_database.cpp:60 push_block ] Pushing block to fork database that failed to link: 002ed04a061430c5daec0f233e6b2147e05d0768, 3067978
1270591ms th_a fork_database.cpp:61 push_block ] Head: 3067959, 002ed0373fd510a23b375e022c62154499b35bbe
1270591ms th_a application.cpp:525 handle_block ] Error when pushing block:
3080000 unlinkable_block_exception: unlinkable block
block does not link to known chain
{}
th_a fork_database.cpp:81 _push_block
{"new_block":{"previous":"002ed049662d95b06d7e8164b27e204b113511ba","timestamp":"2016-01-29T01:37:45","witness":"1.6.49","transaction_merkle_root":"0000000000000000000000000000000000000000","extensions":[],"witness_signature":"1f71078310ac9dcff2b706d275e3b365d4a6637d00da692d1b5c9be87ca708200307fe0e61ccf1a82dc92472442377ad6be2d8d4e163fd5b66ee5042c369828912","transactions":[]}}
th_a db_block.cpp:201 _push_block
1270592ms th_a fork_database.cpp:60 push_block ] Pushing block to fork database that failed to link: 002ed04bb1ee8f9843fed2aa9054f76bf75425a1, 3067979
1270592ms th_a fork_database.cpp:61 push_block ] Head: 3067959, 002ed0373fd510a23b375e022c62154499b35bbe
Any ideas?
4
General Discussion / Added balance as portion of total supply
« on: October 22, 2015, 03:47:27 am »
I saw people talking about this, so I added it to play with the ui code a bit. It displays in your account overview as a new updating "PPM" (Parts Per Million) column for each balance. So the new column is just (balance/current_supply*1,000,000). Showing it as a straight percentage would just be depressing for anyone who isn't a whale.
https://github.com/Troglodactyl/graphene-ui
Not sure I want to pull request it since 4 columns may be a bit messy there, but it's there for anyone who wants it.
EDIT: https://imgur.com/jyyHF8j
https://github.com/Troglodactyl/graphene-ui
Not sure I want to pull request it since 4 columns may be a bit messy there, but it's there for anyone who wants it.
EDIT: https://imgur.com/jyyHF8j
5
Technical Support / Chain backup 10/5/2015
« on: October 07, 2015, 01:11:44 am »
Here's a backup of the synced chain from yesterday. Hope it helps someone...
https://mega.nz/#!CVUzxZpL!4m8Ee8c1rD6fOluqqq7HROMmOG2ERmidykBQRO2GlU8
https://mega.nz/#!CVUzxZpL!4m8Ee8c1rD6fOluqqq7HROMmOG2ERmidykBQRO2GlU8
6
Technical Support / NodeJS update and ui build issues
« on: October 03, 2015, 03:40:31 pm »
https://github.com/brianmcd/contextify/issues/180
Running into this when building graphene-ui with the latest NodeJS versions, and it looks like react-foundation-apps doesn't like some of the older versions.
Can someone with an unbroken build configuration post what version they're using?
Running into this when building graphene-ui with the latest NodeJS versions, and it looks like react-foundation-apps doesn't like some of the older versions.
Can someone with an unbroken build configuration post what version they're using?
7
General Discussion / Community Transition - The Future of BitShares
« on: July 17, 2015, 04:17:49 am »
In its infancy, this network and the community surrounding it has been highly dependent on a few key actors for leadership, growth, and survival. This is normal and healthy for a developing network, but it would be terribly unhealthy to stagnate in this stage. I am quite grateful for the dedication, innovation, and vision that has been poured into BitShares by its founders and other early leaders. I hope they will remain active members and contributors to this community, but with the impending transition to graphene, the time has come to mature our social structure into a more fault tolerant mesh that reflects the elegant design of our network.
To achieve this, I propose the following prioritization strategy:
1. Complete BitShares 2.0 migration
2. Create user friendly Follow My Vote tools to enable stake voting on later proposals
?. Privacy features
?. Bond market
?. Decentralized BitShares ID based communication and social platform to replace centralized forums
?...
As soon as step one is complete, the community can commence a massively parallel marketing campaign using the referral system. As soon as step two is complete, all remaining development goals can be proposed and sequenced through stakeholder voting. Developers ideally should maintain multiple links to the community for fault tolerance, rather than relying so much on bytemaster to speak for them. We need to outgrow dependence on any single individual as a decision making bottleneck. In the future, good ideas should propagate through our social mesh virally, snowballing stake support as they go. Where they originate is irrelevant.
This is the last major strategy and vision decision that needs to be pushed through with the current leadership structure. This will enable them to work themselves out of a job and become just a few more highly respected community members and stakeholders. With BitShares 2.0 + an FMV stake voting system, I believe this network can begin to grow even beyond the intentions of its founders.
Please state if you agree that using 2.0 and FMV to end BitShares remaining reliance on centralized leadership should be our top priority. If you disagree, please state your reasoning. The goal is in sight, but we need all need to be together on this, especially the dev team.
To achieve this, I propose the following prioritization strategy:
1. Complete BitShares 2.0 migration
2. Create user friendly Follow My Vote tools to enable stake voting on later proposals
?. Privacy features
?. Bond market
?. Decentralized BitShares ID based communication and social platform to replace centralized forums
?...
As soon as step one is complete, the community can commence a massively parallel marketing campaign using the referral system. As soon as step two is complete, all remaining development goals can be proposed and sequenced through stakeholder voting. Developers ideally should maintain multiple links to the community for fault tolerance, rather than relying so much on bytemaster to speak for them. We need to outgrow dependence on any single individual as a decision making bottleneck. In the future, good ideas should propagate through our social mesh virally, snowballing stake support as they go. Where they originate is irrelevant.
This is the last major strategy and vision decision that needs to be pushed through with the current leadership structure. This will enable them to work themselves out of a job and become just a few more highly respected community members and stakeholders. With BitShares 2.0 + an FMV stake voting system, I believe this network can begin to grow even beyond the intentions of its founders.
Please state if you agree that using 2.0 and FMV to end BitShares remaining reliance on centralized leadership should be our top priority. If you disagree, please state your reasoning. The goal is in sight, but we need all need to be together on this, especially the dev team.
8
Technical Support / Membership levels and sub-accounts
« on: June 24, 2015, 02:26:07 am »
I'd like to suggest that membership status should always apply to the base level account and be inherited by sub accounts, rather than applying to each account separately. Given that the base account can replace the keys of sub accounts, each tree of accounts represents a single entity from a trust perspective, and it would be terribly inconvenient to have different fees and rewards for different accounts created for organizational purposes.
The other question is whether rewards should always be pooled to the base account, or if they should be scattered across the tree according to where they were generated.
Thoughts?
The other question is whether rewards should always be pooled to the base account, or if they should be scattered across the tree according to where they were generated.
Thoughts?
9
General Discussion / Bad data at coinmarketcap and bitsharesblocks
« on: March 25, 2015, 06:17:59 am »
Both cmc and bitsharesblocks seem to have badly distorted data for bitUSD currently. If you go to the actual exchanges and markets directly, you'll see that the peg is holding fine, despite these sites reporting it as currently 15% off.
10
Stakeholder Proposals / Persistent interest rate competition in shorting
« on: February 17, 2015, 03:54:58 am »
As much as I love being able to short to myself at near 0 interest and harvest yield, I think it would be better if shorts competed to offer higher interest persistently, rather than only initially.
My idea is to allow shorts to be bought out and taken over part way through the term by someone offering higher interest. Such a purchase would effectively force the original shorter to exit at the current feed, and would only be possible if such an exit was profitable, or at least break even. The original shorter would receive his original collateral, plus the difference between the current value of the bitAssets and the initial value at creation, minus accumulated interest. The purchaser would pay for all of this in order to assume ownership of the short position. The expiration date would remain the same, only the interest rate would increase.
With this change, interest rate competition is no longer a separate competition run in each block, but persistent ongoing rate competition, so it can no longer be gamed by opening shorts in low competition blocks when no one else is watching. Also, holding both sides of a short to harvest yield risks exposure to the asset as it should, because the short position may be taken over by a genuine bull willing to pay higher interest for increased BTS exposure, leaving the harvester with the asset unhedged.
Let me know if any of this is unclear and I'll try to expand on it.
My idea is to allow shorts to be bought out and taken over part way through the term by someone offering higher interest. Such a purchase would effectively force the original shorter to exit at the current feed, and would only be possible if such an exit was profitable, or at least break even. The original shorter would receive his original collateral, plus the difference between the current value of the bitAssets and the initial value at creation, minus accumulated interest. The purchaser would pay for all of this in order to assume ownership of the short position. The expiration date would remain the same, only the interest rate would increase.
With this change, interest rate competition is no longer a separate competition run in each block, but persistent ongoing rate competition, so it can no longer be gamed by opening shorts in low competition blocks when no one else is watching. Also, holding both sides of a short to harvest yield risks exposure to the asset as it should, because the short position may be taken over by a genuine bull willing to pay higher interest for increased BTS exposure, leaving the harvester with the asset unhedged.
Let me know if any of this is unclear and I'll try to expand on it.
12
General Discussion / New Decentralized Forum
« on: January 27, 2015, 04:37:25 am »
We have an alternate decentralized forum available, all it needs is people:
retroshare://forum?name=BitSharestalk&id=c01bf375bbdf33c44b257457004d5363
It's hosted through RetroShare, see the sign-up thread here: https://bitsharestalk.org/index.php?topic=13419.0
retroshare://forum?name=BitSharestalk&id=c01bf375bbdf33c44b257457004d5363
It's hosted through RetroShare, see the sign-up thread here: https://bitsharestalk.org/index.php?topic=13419.0
13
General Discussion / Secure communication with BitShares and RetroShare (Reviving the Keyhotee Dream)
« on: January 18, 2015, 05:58:45 am »
Although BitShares development is progressing beautifully, the advanced communication features envisioned for Keyhotee have faded out of focus. I would like to encourage renewed efforts to in that area, starting with BitShares community user acceptance testing of the RetroShare project. RetroShare already supports decentralized and encrypted IM, mail, forums, VOIP, and file sharing. If these features function at scale to the satisfaction of this community, or show sufficient promise, I recommend that we reach out to the RetroShare development team as a community to cooperate with them, and consider offering funding for their development and integration with BitShares.
If you'd like to participate in testing, the software is here: http://retroshare.sourceforge.net/index.html
Please post your RetroShare public key below, and add mine and those of any other participants. The process for adding contacts in RetroShare is unfortunate, but if we integrate this should eventually be solved by TITAN.
Adding a secure communication network to BitShares' robust financial system could be a massive step.
EDIT: Renamed topic for those who weren't here for the original Keyhotee dream...
If you'd like to participate in testing, the software is here: http://retroshare.sourceforge.net/index.html
Please post your RetroShare public key below, and add mine and those of any other participants. The process for adding contacts in RetroShare is unfortunate, but if we integrate this should eventually be solved by TITAN.
Code: [Select]
Af8AAAJdxsBNBFS6wbsBCADU82X/Da1r1qD63B0iUznc1t4B8cHkkxqMWORaYlBD
Rv0GnHMLGdI6abL63JV56gG9xLVJwxiSfae7PXBHAjFAeVh64rtd8n9QD/uPhu6T
f0Km05t8mzJBOO5MhFFLPa7hvEeSWqhFh1abTuRVDd+z3QGv7sqCmCJnDZFk0aQG
IEC1Rf4yc6gJ4ygm9+TpDQRWR1CyJhdaX4WICJWgRNtjpjyg1p2fmhH1/NvEui+j
po1ird/PJYSxGQMadWau9CapP3bnSiEHd9OFQuLJs/vqc9JFxMm/JVfUb+9iP0dp
dLmQWLAjwsqDLiSEk9fTjXtsiFY3O5t8njzQzM0tsWXdABEBAAHNKVRyb2dsb2Rh
Y3R5bCAoR2VuZXJhdGVkIGJ5IFJldHJvU2hhcmUpIDw+wsBfBBMBAgATBQJUusG7
CRC3+qLGsDytMQIZAQAA6xMH/1i/h+m7F9D9Xi63AIBO4OhEj5nnfWZnnCBZbeu1
S0BvhoTmQuPRKI9ft4HhjK9h11EIKeTxpLbsZLtF/OCkddJV2DvHp4aOnb2bTMdd
KyvonBzy9co3Fzr0dibbBDHxjmEisubG+QVqX6YIynJgSK448621QbuL3pf5LYp+
Xj2gkDkvPlIOsxExEtKPmX6p2GVvUJHMx1H/yoLeSQqaVVrqleUycq/Io3OKM/Il
nrOjGhW9UAPrM4fs6EMg/y1wT0Ir/auCmSwx9NYnaJ/9mdzm2qCNeIZp1bmagh+i
8L3XZ4hL0aXYoh2D7PjHZ8iVXzoSFyqgkNCPHa28h7u9mfcCBkZyj2wNtQMGwKgC
ZQ21BAAGBEhvbWUFEEnDvggwBogANgRztucOtcs=Adding a secure communication network to BitShares' robust financial system could be a massive step.
EDIT: Renamed topic for those who weren't here for the original Keyhotee dream...
14
General Discussion / Forking Features
« on: October 12, 2014, 01:03:11 am »
What features besides multi sig and payments from shorts to longs are on the list that require a fork? To minimize forking updates, I think we should get them all listed here and try to bundle them as much as possible.
Is it plausible that multi sig could be ready in time to roll out with short interest payments?
Is it plausible that multi sig could be ready in time to roll out with short interest payments?
15
General Discussion / Decoupling transaction fees from delegate pay...
« on: September 11, 2014, 01:31:44 pm »
I still think it's a mistake to give asset transaction fees as interest instead of allocating them through the delegates. The sooner we have solid rules that are obviously sustainable, the sooner people will be comfortable building business on the network. It's possible that BTSX transactions will have high enough volume to compensate for asset transactions, but if the goal is Visa level volumes in bitUSD, and shorts only pay one time BTSX fees to create bitUSD, it's plausible that relatively stable asset markets with high transaction volume could become millstones around the delegate's necks, and that creates uncertainty and deters serious commitment. This also runs the risk of inflating BTSX fees to the point where only high volume transactions are cost effective, stratifying a class system for investors. Even if these concerns are unrealized, subsidizing asset holders from BTSX holders adds unnecessary economic complication and uncertainty, and hard codes a marketing agenda that I think would be better left at the fluid discretion of delegates and investors.
Conceptually, I think the ideal is that transaction fees should pay for the real costs of transactions, and shorts should pay longs a variable amount depending on the current demand to short. Is there any disagreement on this?
I'm trying to figure out ways to implement these concepts more cleanly, but wanted to see how much consensus there is that they should be pursued.
Conceptually, I think the ideal is that transaction fees should pay for the real costs of transactions, and shorts should pay longs a variable amount depending on the current demand to short. Is there any disagreement on this?
I'm trying to figure out ways to implement these concepts more cleanly, but wanted to see how much consensus there is that they should be pursued.
Pages: [1] 2
