Topic: [ANN][KMD][dPoW] Komodo - An Open, Composable Smart Chain Platform, Secured by B - page 590. (Read 1192347 times)
February 11, 2017, 05:45:24 PM
Komodo on Bittrex! Status: Normal !
February 11, 2017, 04:17:58 PM
People here need to learn to have patience.
You invest a few $ and expect a 500% return the day it launches.
If you arent prepared to wait a reasonable amount of time for a return then dont invest.
Exactly.If you don't have patience,you will lose all.For this reason I don't trade.Only buy cheap and the rest will arrive don't worryYou invest a few $ and expect a 500% return the day it launches.
If you arent prepared to wait a reasonable amount of time for a return then dont invest.
Supernet is the first who wants to add value
Exactly, Even bitcoin took a few years before it reaches current price.
February 11, 2017, 02:40:36 PM
It´s a good time to buy at these prices. February 11, 2017, 02:30:27 PM
People here need to learn to have patience.
You invest a few $ and expect a 500% return the day it launches.
If you arent prepared to wait a reasonable amount of time for a return then dont invest.
Exactly.If you don't have patience,you will lose all.For this reason I don't trade.Only buy cheap and the rest will arrive don't worryYou invest a few $ and expect a 500% return the day it launches.
If you arent prepared to wait a reasonable amount of time for a return then dont invest.
Supernet is the first who wants to add value
February 11, 2017, 02:25:46 PM
People here need to learn to have patience.
You invest a few $ and expect a 500% return the day it launches.
If you arent prepared to wait a reasonable amount of time for a return then dont invest.
You invest a few $ and expect a 500% return the day it launches.
If you arent prepared to wait a reasonable amount of time for a return then dont invest.
February 11, 2017, 02:06:44 PM
Kmd constantly taking a knee
February 11, 2017, 01:30:04 PM
soon in bittrex
Nice info buddy, prepare your self. I hope the price of KMD will be better than yesterday
February 11, 2017, 01:22:37 PM
soon in bittrex
February 11, 2017, 01:16:10 PM
This shit komodo will never be on Bittrex or Poloniex, I'm sure of it
You could not get get any? That's why you are saying Komodo is shit? Even better, Komodo will have it's own exchange built-in in the future.
If you ask how long you have to wait? I have been holding BTCD since the mining days which is few years ago and recently converted them into KMD. Will hold long term. Even without exchange, KMD is giving 5% interest which is much better than small CPU or GPU mining.
February 11, 2017, 01:05:16 PM
How to solo mininig in win ?
You currently can not solo mine in windows unless you have linux run wallet on your network.
February 11, 2017, 12:59:44 PM
How to solo mininig in win ?
You currently can not solo mine in windows unless you have linux run wallet on your network.
February 11, 2017, 12:56:47 PM
This shit komodo will never be on Bittrex or Poloniex, I'm sure of it
Do you wanna bet for Bittrex ? ^^
February 11, 2017, 12:53:51 PM
Please answer me my question? 
February 11, 2017, 12:52:21 PM
This shit komodo will never be on Bittrex or Poloniex, I'm sure of it
February 11, 2017, 08:07:59 AM
How to solo mininig in win ?
February 11, 2017, 05:35:08 AM
As I wrote in https://bitcointalksearch.org/topic/m.17800081
there is no bitcoin built in way to find out if a txid/vout has been spent or not. To do that you need to index the entire blockchain and mark the txids that have been spent, the ones not marked are still unspent. Of course bitcoin does this for addresses in the wallet, but it doesnt do it for addresses that are not in the wallet. Including watchonly addresses.
So over the last couple of days I wrote a full blockchain indexer that can be used to index any blockchain with standard RPC. for now it is only enabled for KMD via dexexplorer API:
curl --url "http://127.0.0.1:7778" --data "{\"agent\":\"dex\",\"method\":\"explorer\",\"symbol\":\"KMD\"}"
it will take a while to scan the blockchain the first time, but after that it will initialize in under a minute when iguana is launched.
The following are the API bindings that are now available:
TWO_STRINGS(dex,listunspent2,symbol,address);
TWO_STRINGS_AND_TWO_DOUBLES(dex,listtransactions2,symbol,address,count,skip);
HASH_AND_STRING_AND_INT(dex,gettxin,txid,symbol,vout);
TWO_STRINGS(dex,listspent,symbol,address);
TWO_STRINGS(dex,getbalance,symbol,address);
I made listunspent2 and listtransactions2 so we can get them validated before using them in the main bitcoinrpc path. The above API bindings simply shows the JSON field names needed in the curl request, there are plenty of examples in SuperNET/iguana/tests
With dex explorer initialized, this means that (theoretically) the current balance of any address, the set of utxo, the list of spends, the spent status of any utxo, can all be queried. And it is all RAM based, so should be quite fast. I added a special handling in dex/getbalance for the address of '*', which will return the coin supply. This it does by bruteforce iterating through all the addresses and doing a getbalance on it. Not very efficient, but still it is completing in about 30 seconds.
To my knowledge this is the smallest code size for any explorer, coming in at 600 lines. And you can see the power of SuperNET as when the notary nodes run this, then all basilisk nodes will be able to access all these explorer functions remotely, without needing any blockchain locally.
The timeline is that this needs to be validated, probably will just do a bruteforce compare against a known good reference. Then it is deployed for the notary nodes. Once there, the GUI can rely on basilisk support of this and so the GUI can use this data for transaction listing. Then it needs to be packaged into the installers.
I am also not handling blockchain reorgs yet, it just has a setback of 3 blocks, which should cover the vast majority of small reorgs. For now, if we detect a larger reorg, it might be that we have to recreate the DB/TRANSACTIONS/KMD file
Quite a bit of work to do in order to get the GUI's transaction history sorted, but we do what we must. A nice side effect of this is now there is a publicly available gettxin and listspent support for the coins the notaries are running this for. Maybe someday, gettxin will become a standard RPC in bitcoin?
there is no bitcoin built in way to find out if a txid/vout has been spent or not. To do that you need to index the entire blockchain and mark the txids that have been spent, the ones not marked are still unspent. Of course bitcoin does this for addresses in the wallet, but it doesnt do it for addresses that are not in the wallet. Including watchonly addresses.
So over the last couple of days I wrote a full blockchain indexer that can be used to index any blockchain with standard RPC. for now it is only enabled for KMD via dexexplorer API:
curl --url "http://127.0.0.1:7778" --data "{\"agent\":\"dex\",\"method\":\"explorer\",\"symbol\":\"KMD\"}"
it will take a while to scan the blockchain the first time, but after that it will initialize in under a minute when iguana is launched.
The following are the API bindings that are now available:
TWO_STRINGS(dex,listunspent2,symbol,address);
TWO_STRINGS_AND_TWO_DOUBLES(dex,listtransactions2,symbol,address,count,skip);
HASH_AND_STRING_AND_INT(dex,gettxin,txid,symbol,vout);
TWO_STRINGS(dex,listspent,symbol,address);
TWO_STRINGS(dex,getbalance,symbol,address);
I made listunspent2 and listtransactions2 so we can get them validated before using them in the main bitcoinrpc path. The above API bindings simply shows the JSON field names needed in the curl request, there are plenty of examples in SuperNET/iguana/tests
With dex explorer initialized, this means that (theoretically) the current balance of any address, the set of utxo, the list of spends, the spent status of any utxo, can all be queried. And it is all RAM based, so should be quite fast. I added a special handling in dex/getbalance for the address of '*', which will return the coin supply. This it does by bruteforce iterating through all the addresses and doing a getbalance on it. Not very efficient, but still it is completing in about 30 seconds.
To my knowledge this is the smallest code size for any explorer, coming in at 600 lines. And you can see the power of SuperNET as when the notary nodes run this, then all basilisk nodes will be able to access all these explorer functions remotely, without needing any blockchain locally.
The timeline is that this needs to be validated, probably will just do a bruteforce compare against a known good reference. Then it is deployed for the notary nodes. Once there, the GUI can rely on basilisk support of this and so the GUI can use this data for transaction listing. Then it needs to be packaged into the installers.
I am also not handling blockchain reorgs yet, it just has a setback of 3 blocks, which should cover the vast majority of small reorgs. For now, if we detect a larger reorg, it might be that we have to recreate the DB/TRANSACTIONS/KMD file
Quite a bit of work to do in order to get the GUI's transaction history sorted, but we do what we must. A nice side effect of this is now there is a publicly available gettxin and listspent support for the coins the notaries are running this for. Maybe someday, gettxin will become a standard RPC in bitcoin?
Great work James!
February 11, 2017, 05:07:29 AM
As I wrote in https://bitcointalksearch.org/topic/m.17800081
there is no bitcoin built in way to find out if a txid/vout has been spent or not. To do that you need to index the entire blockchain and mark the txids that have been spent, the ones not marked are still unspent. Of course bitcoin does this for addresses in the wallet, but it doesnt do it for addresses that are not in the wallet. Including watchonly addresses.
So over the last couple of days I wrote a full blockchain indexer that can be used to index any blockchain with standard RPC. for now it is only enabled for KMD via dexexplorer API:
curl --url "http://127.0.0.1:7778" --data "{\"agent\":\"dex\",\"method\":\"explorer\",\"symbol\":\"KMD\"}"
it will take a while to scan the blockchain the first time, but after that it will initialize in under a minute when iguana is launched.
The following are the API bindings that are now available:
TWO_STRINGS(dex,listunspent2,symbol,address);
TWO_STRINGS_AND_TWO_DOUBLES(dex,listtransactions2,symbol,address,count,skip);
HASH_AND_STRING_AND_INT(dex,gettxin,txid,symbol,vout);
TWO_STRINGS(dex,listspent,symbol,address);
TWO_STRINGS(dex,getbalance,symbol,address);
I made listunspent2 and listtransactions2 so we can get them validated before using them in the main bitcoinrpc path. The above API bindings simply shows the JSON field names needed in the curl request, there are plenty of examples in SuperNET/iguana/tests
With dex explorer initialized, this means that (theoretically) the current balance of any address, the set of utxo, the list of spends, the spent status of any utxo, can all be queried. And it is all RAM based, so should be quite fast. I added a special handling in dex/getbalance for the address of '*', which will return the coin supply. This it does by bruteforce iterating through all the addresses and doing a getbalance on it. Not very efficient, but still it is completing in about 30 seconds.
To my knowledge this is the smallest code size for any explorer, coming in at 600 lines. And you can see the power of SuperNET as when the notary nodes run this, then all basilisk nodes will be able to access all these explorer functions remotely, without needing any blockchain locally.
The timeline is that this needs to be validated, probably will just do a bruteforce compare against a known good reference. Then it is deployed for the notary nodes. Once there, the GUI can rely on basilisk support of this and so the GUI can use this data for transaction listing. Then it needs to be packaged into the installers.
I am also not handling blockchain reorgs yet, it just has a setback of 3 blocks, which should cover the vast majority of small reorgs. For now, if we detect a larger reorg, it might be that we have to recreate the DB/TRANSACTIONS/KMD file
Quite a bit of work to do in order to get the GUI's transaction history sorted, but we do what we must. A nice side effect of this is now there is a publicly available gettxin and listspent support for the coins the notaries are running this for. Maybe someday, gettxin will become a standard RPC in bitcoin?
there is no bitcoin built in way to find out if a txid/vout has been spent or not. To do that you need to index the entire blockchain and mark the txids that have been spent, the ones not marked are still unspent. Of course bitcoin does this for addresses in the wallet, but it doesnt do it for addresses that are not in the wallet. Including watchonly addresses.
So over the last couple of days I wrote a full blockchain indexer that can be used to index any blockchain with standard RPC. for now it is only enabled for KMD via dexexplorer API:
curl --url "http://127.0.0.1:7778" --data "{\"agent\":\"dex\",\"method\":\"explorer\",\"symbol\":\"KMD\"}"
it will take a while to scan the blockchain the first time, but after that it will initialize in under a minute when iguana is launched.
The following are the API bindings that are now available:
TWO_STRINGS(dex,listunspent2,symbol,address);
TWO_STRINGS_AND_TWO_DOUBLES(dex,listtransactions2,symbol,address,count,skip);
HASH_AND_STRING_AND_INT(dex,gettxin,txid,symbol,vout);
TWO_STRINGS(dex,listspent,symbol,address);
TWO_STRINGS(dex,getbalance,symbol,address);
I made listunspent2 and listtransactions2 so we can get them validated before using them in the main bitcoinrpc path. The above API bindings simply shows the JSON field names needed in the curl request, there are plenty of examples in SuperNET/iguana/tests
With dex explorer initialized, this means that (theoretically) the current balance of any address, the set of utxo, the list of spends, the spent status of any utxo, can all be queried. And it is all RAM based, so should be quite fast. I added a special handling in dex/getbalance for the address of '*', which will return the coin supply. This it does by bruteforce iterating through all the addresses and doing a getbalance on it. Not very efficient, but still it is completing in about 30 seconds.
To my knowledge this is the smallest code size for any explorer, coming in at 600 lines. And you can see the power of SuperNET as when the notary nodes run this, then all basilisk nodes will be able to access all these explorer functions remotely, without needing any blockchain locally.
The timeline is that this needs to be validated, probably will just do a bruteforce compare against a known good reference. Then it is deployed for the notary nodes. Once there, the GUI can rely on basilisk support of this and so the GUI can use this data for transaction listing. Then it needs to be packaged into the installers.
I am also not handling blockchain reorgs yet, it just has a setback of 3 blocks, which should cover the vast majority of small reorgs. For now, if we detect a larger reorg, it might be that we have to recreate the DB/TRANSACTIONS/KMD file
Quite a bit of work to do in order to get the GUI's transaction history sorted, but we do what we must. A nice side effect of this is now there is a publicly available gettxin and listspent support for the coins the notaries are running this for. Maybe someday, gettxin will become a standard RPC in bitcoin?
February 11, 2017, 04:53:49 AM
I voted for KMD in mercatox exchange , https://mercatox.com/coins/list&page=2 , everybody should vote as well.
Good luck!
Good luck!
The fact that now there is a vote on the coin is added to the stock exchange mercatox, there is nothing wrong, but I think it would be better if the devs have agreed with bittrex or polo on what would KMD traded them? I think it would be better than what the small stock exchanges to carry out the vote, etc.
Sure, but likely devs think differently
February 11, 2017, 04:42:56 AM
I voted for KMD in mercatox exchange , https://mercatox.com/coins/list&page=2 , everybody should vote as well.
Good luck!
Good luck!
The fact that now there is a vote on the coin is added to the stock exchange mercatox, there is nothing wrong, but I think it would be better if the devs have agreed with bittrex or polo on what would KMD traded them? I think it would be better than what the small stock exchanges to carry out the vote, etc.
February 11, 2017, 03:12:50 AM
I voted for KMD in mercatox exchange , https://mercatox.com/coins/list&page=2 , everybody should vote as well.
Good luck!
Good luck!
Jump to: