Doesn't it poll the github account directly controlled by the dev also? not sure what all github allows them to see, but just those 2 sites is disappointing here.
Still glad we got the altcoin bump on this one, hope more investors jump in to pick up the slack.
Too bad that second exchange didn't open up. . .
all these changes to the burn fees for transactions makes the DEX hopeless for endusers and paying a central source for trading this altcoin brings us back to square one.
Great ideas though! A dev will surely figure out usable code to do altcoin DEXing eventually.
Kudos to the dev's for thinking this up, so simple of an idea, yet so requiring of coding skills to actually implement. . .
https://forums.counterparty.co/index.php/topic,71.0.html
Still glad we got the altcoin bump on this one, hope more investors jump in to pick up the slack.
Too bad that second exchange didn't open up. . .
all these changes to the burn fees for transactions makes the DEX hopeless for endusers and paying a central source for trading this altcoin brings us back to square one.
Great ideas though! A dev will surely figure out usable code to do altcoin DEXing eventually.
Kudos to the dev's for thinking this up, so simple of an idea, yet so requiring of coding skills to actually implement. . .
https://forums.counterparty.co/index.php/topic,71.0.html
Blockchain.info queries
Regarding the blockchain.info site hits, those were necessary for retrieving an arbitrary account balances as well as unspent outputs (UTXOs) for an arbitrary address. This was only required when we needed to get this information on an address that was not in the local wallet (e.g. for counterwallet itself, as we do not keep web wallet users' addresses in the server's bitcoind wallet). As of our commits to develop this weekend, these blockchain.info calls are no longer necessary, due to us now using Bitpay's Insight daemon, which is a free, open source product that provides an API with similar services and is installed on the local machine, parsing through the blockchain files stored by bitcoind. More info: https://github.com/xnova/counterpartyd_build/blob/develop/docs/SettingUpInsight.rst)
However, regarding this, note that counterpartyd has a new "insight-enable" config setting. By default, on mainnet, this is set to 0 (off), due to the overhead with setting up insight (e.g. it's similar complexity to setting up bitcoind, and takes about 30GB on disk once the mainnet data is indexed -- we didn't want to force doing this on people that just wanted to use counterwalletd to run the GUI on mainnet, for instance). If this setting is off, blockchain will still be used to get the required data (and note this is not a persistent connection, it's just a simple HTTP query as we need to get the data). Moreover, Insight is required to be used on testnet, since blockchain.info's APIs do not support testnet.
I'm glad that we could remove this dependency on blockchain.info. We feel the same way about consulting 3rd party sites in the code of a "decentralized" system like Counterparty. It was a hack at first due to the limitations of bitcoind, and we've been able to move past it this weekend, employing a more proper solution that preserves decentralization (i.e. using insight, which is free, open source, installed locally and works off of the local blockchain data).
Version check (github.com query)
This is a simple (i.e. non-persistent) query to a single .json file on github, to make sure the client is up to date with the most recent major modifications. This was done to avoid forks (i.e. situations where someone starts up old code, and ends up sending out an invalid txn, which is seen as valid by those running counterpartyd on the same old code, but not by people on the newer code, for instance). These are serious situations, and due to the rapid pace of counterpartyd development, this was seen as the most acceptable option, as the file it hits is a) public and b) under version control, in the same location as the code, and c) published/updated in the same manner as the code is (signed push by the devs).
Also, even with this check, note that if the client is NOT up to date, counterpartyd will simply complain and not start. It will NOT automatically update any code, or make any changes.
Moreover, Phantom has just today enhanced the --force flag to avoid this version check, so if you REALLY want to run without this functionality (not recommended!), you can just use --force. Again, we do not want to make people have to have their client check an external 3rd party site. It's just in this case, it's a Really Good Idea that we default to. This check will remain, at least until development has slowed down. We think it's a good idea beyond that though, to avoid forks as much as possible.
Hopefully that clears up some of these concerns. Thanks guys for working with us and being patient as things continue to take form.
