16
Technical Support / Re: [BitShares2-light] Javascript errors when clicking on Membership tab
« on: November 20, 2015, 05:15:32 pm »
Confirmed fixed in https://github.com/bitshares/bitshares-2/releases/tag/v2.0.151119.
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.
17
Technical Support / [BitShares2-light] Javascript errors when clicking on Membership tab
« on: November 03, 2015, 11:56:25 am »
Running BitShares2-light client v2.0.151101 on Mac OS 10.11.1.
1. Launch BitShares.
2. Select an account.
3. Click on the Membership tab in the left nav menu.
4. Several Javascript errors occur (only detectable by Toggling DevTools):
- Uncaught Error: argument is not an object id: undefined (app.js:50)
- Uncaught TypeError: Cannot read property '_currentElement' of null (repeated many times) (vendors.js:17)
1. Launch BitShares.
2. Select an account.
3. Click on the Membership tab in the left nav menu.
4. Several Javascript errors occur (only detectable by Toggling DevTools):
- Uncaught Error: argument is not an object id: undefined (app.js:50)
- Uncaught TypeError: Cannot read property '_currentElement' of null (repeated many times) (vendors.js:17)
18
General Discussion / Re: IOTA + Bitshares
« on: October 31, 2015, 05:48:02 am »
Thanks @mthcl and @Come-from-Beyond for the extra context! I've (myself) never seen a system like Tangle before; very interested to see where this goes.
19
General Discussion / Re: IOTA + Bitshares
« on: October 30, 2015, 12:44:23 am »
Reading through the whitepaper now.
Could you help me wrap my brain around the concepts? Here's what I think I understand so far:
--
1. When a new transaction is broadcast to become a tip, it must approve two existing transactions. What does it mean to approve an existing transaction? Is it similar in concept to generating a block hash in Bitcoin?
2. Section 2 indicates that a node may invest a variable amount of work into creating the transaction (ultimately resulting in an own weight value that is equal to a power of 3). What is the nature of the work? Again using Bitcoin concepts, would this be similar to voluntarily using a higher/lower difficulty when computing the block hash?
3. Each transaction has 2 different weights and a height:
a. Its own weight, which is determined by the amount of work that was invested into creating it (see question 2 above).
b. Its cumulative weight, which is determined by summing the own weights of all of the transactions that approve it, plus the own weight of the transaction itself. Conceptually, you could think of this like tracing all of the paths from that transaction to the tips and adding up all of the own weights of the transactions that you encounter along the way.
c. Its height, which is determined by summing up the own weights of all the transactions that it approves, plus the own weight of the transaction itself. Conceptually, you could think of this like tracing all of the paths from that transaction all the way to the genesis block and adding up the own weights of the transactions that you encounter along the way.
4. A new tip is allowed to approve any two existing transactions at any height(s), but it is more valuable to the network if incoming transactions approve other tips with the highest possible height, in order to ensure that new transactions get confirmed, correct? Is that the problem being addressed in section 3?
5. Unlike, say, Bitcoin, you don't try to entice the network to include your transaction by including a transaction fee; instead you try to ensure that your transaction's height is within the top xx% of all tips in the network, so that it is more likely that other nodes will prefer to approve your transaction.
6. If your transaction's height isn't enough, you could try to increase it by generating empty transaction(s) that approve it.
a. The new transaction(s) have a larger height than the original one, and if they also approve another tip with a large height (recall that each transaction must approve exactly 2 others), then that could be enough to bump the new transaction into the coveted "top xx%" subset.
b. If more work is invested into the empty transaction(s), this also increases their height values (because the transaction's own weight is included in its height).
7. A double spend could theoretically be carried out against the network in one of two ways:
a. An attacker spams the network with a massive number of new transactions approving the double-spend transaction and not the legitimate transaction (even indirectly).
b. An attacker submits a new transaction with a huge own weight (by investing lots of work into it) that approves the double-spend transaction and not the legitimate transaction.
If either attack succeeds, the network builds on the transactions from the double-spend, orphaning the the part of the DAG where the legitimate transaction resides.
It is not clear to me, though, what that actually looks like. Does the DAG get pruned? Do transactions have inputs and outputs similar to Bitcoin, and in the event that two transactions reference the same inputs, the one with the larger cumulative weight wins?
Could you help me wrap my brain around the concepts? Here's what I think I understand so far:
--
1. When a new transaction is broadcast to become a tip, it must approve two existing transactions. What does it mean to approve an existing transaction? Is it similar in concept to generating a block hash in Bitcoin?
2. Section 2 indicates that a node may invest a variable amount of work into creating the transaction (ultimately resulting in an own weight value that is equal to a power of 3). What is the nature of the work? Again using Bitcoin concepts, would this be similar to voluntarily using a higher/lower difficulty when computing the block hash?
3. Each transaction has 2 different weights and a height:
a. Its own weight, which is determined by the amount of work that was invested into creating it (see question 2 above).
b. Its cumulative weight, which is determined by summing the own weights of all of the transactions that approve it, plus the own weight of the transaction itself. Conceptually, you could think of this like tracing all of the paths from that transaction to the tips and adding up all of the own weights of the transactions that you encounter along the way.
c. Its height, which is determined by summing up the own weights of all the transactions that it approves, plus the own weight of the transaction itself. Conceptually, you could think of this like tracing all of the paths from that transaction all the way to the genesis block and adding up the own weights of the transactions that you encounter along the way.
4. A new tip is allowed to approve any two existing transactions at any height(s), but it is more valuable to the network if incoming transactions approve other tips with the highest possible height, in order to ensure that new transactions get confirmed, correct? Is that the problem being addressed in section 3?
5. Unlike, say, Bitcoin, you don't try to entice the network to include your transaction by including a transaction fee; instead you try to ensure that your transaction's height is within the top xx% of all tips in the network, so that it is more likely that other nodes will prefer to approve your transaction.
6. If your transaction's height isn't enough, you could try to increase it by generating empty transaction(s) that approve it.
a. The new transaction(s) have a larger height than the original one, and if they also approve another tip with a large height (recall that each transaction must approve exactly 2 others), then that could be enough to bump the new transaction into the coveted "top xx%" subset.
b. If more work is invested into the empty transaction(s), this also increases their height values (because the transaction's own weight is included in its height).
7. A double spend could theoretically be carried out against the network in one of two ways:
a. An attacker spams the network with a massive number of new transactions approving the double-spend transaction and not the legitimate transaction (even indirectly).
b. An attacker submits a new transaction with a huge own weight (by investing lots of work into it) that approves the double-spend transaction and not the legitimate transaction.
If either attack succeeds, the network builds on the transactions from the double-spend, orphaning the the part of the DAG where the legitimate transaction resides.
It is not clear to me, though, what that actually looks like. Does the DAG get pruned? Do transactions have inputs and outputs similar to Bitcoin, and in the event that two transactions reference the same inputs, the one with the larger cumulative weight wins?
20
General Discussion / Re: List your PGP public key and experiment with me.
« on: February 26, 2015, 03:46:11 pm »What can be done with a fingerprint? It can't be used to verify an encrypted message can it? I'm genuinely curious.A fingerprint can be uses to identify and verify a public key .. its like a short version of the pubkey .. though you cannot derive the pubkey from it
In terms of crypto currencies .. the fingerprint would be an address to a public key
The fingerprint is a good way to verify that a public key that was transmitted via an unsecured medium hasn't been tampered with in transit.
For example, suppose you and I want to communicate securely, so you download my public key from the keyserver, or you ask me to email it to you. In those cases, you shouldn't trust the public key you receive, since someone else could have replaced my public key with their own by the time you receive it.
So, you contact me via a more trusted/secure channel, such as a PM on bitsharestalk or call me on my phone, etc., and I send/tell you the key fingerprint, which you can then compare against the fingerprint of the public key you received.
This way, in order to fool you into using their public key to encrypt messages intended for me, an attacker would not only have to get you to use the wrong public key, but they would also have to impersonate me on the second channel to communicate the key fingerprint.
21
Stakeholder Proposals / Re: MineBitShares.com - A virtual mining multi-pool for BitShares
« on: January 31, 2015, 07:22:25 pm »
I would like to try this out with a Mac. How do I get started?
22
Stakeholder Proposals / Re: You know what would be a neat addition to BTSX?
« on: January 08, 2015, 12:48:22 am »
VoR0220, is this what you mean?
Customer sends BitAssets to address xxx => vendor automatically creates and fulfills an order containing that item? Each item has a different BTS address.
Maybe similar to Amazon 1-Click ordering?
I saw a similar concept to that in an image a couple of years ago that I can't find anymore. It was a menu at a restaurant, and each item on the menu had its own BTC address / QR code. To order something, you would send the correct amount to the address listed next to it.
Customer sends BitAssets to address xxx => vendor automatically creates and fulfills an order containing that item? Each item has a different BTS address.
Maybe similar to Amazon 1-Click ordering?
I saw a similar concept to that in an image a couple of years ago that I can't find anymore. It was a menu at a restaurant, and each item on the menu had its own BTC address / QR code. To order something, you would send the correct amount to the address listed next to it.
23
Technical Support / [Mac] "Bitshares" can't be opened because it is from an unidentified developer
« on: December 31, 2014, 07:00:26 pm »
Each time I update Bitshares.app, Mac OS X's Gatekeeper feature prevents me from launching the app. It can be bypassed each time, but it's a pain and you have to know where to look.
From http://support.apple.com/HT202491:
Relevant snippet from that URL for developers:
From http://support.apple.com/HT202491:
Quote
- Gatekeeper options set to "Mac App Store and identified developers"
- "App name" can't be opened because it is from an unidentified developer
- Your security preferences allow installation of only apps from the Mac App Store and Identified developers.
- Safari downloaded this file Date from URL.
Relevant snippet from that URL for developers:
Quote
For apps that are downloaded from places other than the Mac App Store, developers can get a unique Developer ID from Apple and use it to digitally sign their apps. The Developer ID allows Gatekeeper to block apps created by malware developers and verify that apps haven't been tampered with since they were signed. If an app was developed by an unknown developer—one with no Developer ID—or tampered with, Gatekeeper can block the app from being installed.
Note: If you have an app that has not been signed with a Developer ID to support Gatekeeper, contact the developer of the app to determine if they offer an update which supports Gatekeeper.
24
General Discussion / Re: [ANN] Bitshares SMF login plugin
« on: December 24, 2014, 09:00:45 pm »- Went to http://bitsharesnation.org/.
- Clicked on "Login with BitShares":
- BitShares app open and unlocked: clicking the login button switched focus to the BitShares app, but nothing else happened.
- BitShares app open and locked: clicking the login button switched focus to the BitShares app, but nothing else happened.
- BitShares app not open: clicking the login button caused the BitShares app to launch. I entered my password to unlock my wallet, but nothing else happened.
Browser: Firefox 34.0
OS: Mac OS 10.10.1
BTS: 0.4.27.2
25
General Discussion / Re: [ANN] Bitshares SMF login plugin
« on: December 22, 2014, 12:58:28 am »
I'd like to test this out. http://bitsharesnation.org/ does not load for me:
PM me if you need any details to help troubleshoot the connection issue.
Once that's resolved, let me know if there's anything specific that you'd like me to test, and I'll be all over it.
Code: [Select]
[497][~] curl -IL 'http://bitsharesnation.org/'
curl: (7) Failed to connect to bitsharesnation.org port 80: Connection refusedPM me if you need any details to help troubleshoot the connection issue.
Once that's resolved, let me know if there's anything specific that you'd like me to test, and I'll be all over it.
26
General Discussion / Re: Can BTS be used for website authentication?
« on: December 22, 2014, 12:51:22 am »Here the example: https://bitsharestalk.org/index.php?topic=12119.0
Oh, sweet! Thanks for the link!
27
General Discussion / Can BTS be used for website authentication?
« on: December 21, 2014, 07:04:11 pm »28
General Discussion / Re: Making Proof of Work as Predictable as DPOS
« on: December 04, 2014, 12:46:14 pm »
If the miners are producing hashes independently of blocks, what are they producing hashes of?
Could signing blocks (and receiving the block reward) be payment for doing something not directly related to the blockchain (but still useful) with their processing power?
Could signing blocks (and receiving the block reward) be payment for doing something not directly related to the blockchain (but still useful) with their processing power?
29
General Discussion / Re: Where do you go for crypto 2.0 news?
« on: November 16, 2014, 03:19:33 pm »
After about a month of aggressively adding new feeds to my RSS reader, here's the collection I have now (in no particular order):
There are a number of other projects I'd like to keep an eye on, but they don't have RSS feeds, which makes it harder for me to get updates.
- http://nullstreet.com/
- http://beyondbitcoinx.net/
- http://bitcoinist.net/category/news/
- http://www.futuretechfarm.com/blog/
- http://www.coindesk.com/
- https://www.darkcoin.io/news/
- https://blog.ethereum.org/
- https://merchantcoin.net/company-news/
- http://omnibazaar.com/
- http://blog.viacoin.org/
- http://www.wildbunny.co.uk/blog/
There are a number of other projects I'd like to keep an eye on, but they don't have RSS feeds, which makes it harder for me to get updates.
30
General Discussion / Re: OmniBazaar: social-consensus-rejecting BTS fork
« on: November 11, 2014, 02:36:29 am »
I think there's an opportunity here. Let's be supportive and provide honest and constructive feedback about the product and the ecosystem they are trying to create (or just ignore them if you want; that probably works, too).
If the project is successful, then it's a vital "reality check" for those of us who didn't think that a copycat DAC could get off the ground without honoring the social consensus. And hey, the guy did say he's going to add some new features to the code; maybe he ends up producing something that can be applied to BTS. At least he won't have any grounds to complain if/when his enhancements get copied over to the BTS codebase (:
But if OmniBazaar fails, then what better evidence of the virtues of the social consensus could you ask for than a project that was doomed from the start – despite all of the encouragement (or at least professional courtesy) from the BTS community – simply because the developers didn't honor the social consensus? That all other things being equal, not honoring the social consensus is an Achilles Heel?
If the project is successful, then it's a vital "reality check" for those of us who didn't think that a copycat DAC could get off the ground without honoring the social consensus. And hey, the guy did say he's going to add some new features to the code; maybe he ends up producing something that can be applied to BTS. At least he won't have any grounds to complain if/when his enhancements get copied over to the BTS codebase (:
But if OmniBazaar fails, then what better evidence of the virtues of the social consensus could you ask for than a project that was doomed from the start – despite all of the encouragement (or at least professional courtesy) from the BTS community – simply because the developers didn't honor the social consensus? That all other things being equal, not honoring the social consensus is an Achilles Heel?
