[ANN][XCN] Cryptonite - NEW Thread | 1st mini-blockchain coin | Bounties!

[pallas]

What do you think about the idea of creating a bot telegrams as frontend mining pool? So that this bot could create accounts, keep statistics and give out tasks and take shares from miners. I'm thinking about creating a pool but I'm afraid that my server is bogged down by DDoS attacks, so came up with this idea (to cover a pool node of servers Telegram)

I don't know about telegram bots, but I guess it will have a lot of overhead compared to a standard, C based stratum implementation. Will it be able to verify and record tens of share submissions a second?

[1714891591]

1714891591

[1714891591]

1714891591

[info_infoman1]

What do you think about the idea of creating a bot telegrams as frontend mining pool? So that this bot could create accounts, keep statistics and give out tasks and take shares from miners. I'm thinking about creating a pool but I'm afraid that my server is bogged down by DDoS attacks, so came up with this idea (to cover a pool node of servers Telegram)

I don't know about telegram bots, but I guess it will have a lot of overhead compared to a standard, C based stratum implementation. Will it be able to verify and record tens of share submissions a second?

https://core.telegram.org/mtproto
Here it is said that a multithreaded connection is used between the client and the telegram server

The application bot can be written and there are examples in c ++, for each unit mining you can have a separate dedicated connection to telegrams

And how much does the average miner generate shares\sec in cryptonite?

[pallas]

What do you think about the idea of creating a bot telegrams as frontend mining pool? So that this bot could create accounts, keep statistics and give out tasks and take shares from miners. I'm thinking about creating a pool but I'm afraid that my server is bogged down by DDoS attacks, so came up with this idea (to cover a pool node of servers Telegram)

I don't know about telegram bots, but I guess it will have a lot of overhead compared to a standard, C based stratum implementation. Will it be able to verify and record tens of share submissions a second?

https://core.telegram.org/mtproto
Here it is said that a multithreaded connection is used between the client and the telegram server

The application bot can be written and there are examples in c ++, for each unit mining you can have a separate dedicated connection to telegrams

And how much does the average miner generate shares\sec in cryptonite?

Depends on the stratum difficulty, which is set by the pool.

[mak013]

can we sometimes make infopost, may be with snapshot?

as example:

25.10.17
Exchanges listed:
coin-exchange
Exchanges asked to be listed:
Yobit(till 02.10.17, waiting answer (last - 15.10.17))
Cryptopia(till 05.10.17, asks 9BTC for listing)
Poloniex(till 10.10.17, waiting answer)
Scrypt/Wallet problems:
15.10.17 fixed Wallet(new wallet in 1st post)


etc

[info_infoman1]

What do you think about the idea of creating a bot telegrams as frontend mining pool? So that this bot could create accounts, keep statistics and give out tasks and take shares from miners. I'm thinking about creating a pool but I'm afraid that my server is bogged down by DDoS attacks, so came up with this idea (to cover a pool node of servers Telegram)

i think bot may be interesting but later. pools is a good idea, there is now normally working pools.

[kensaii]

What do you think about the idea of creating a bot telegrams as frontend mining pool? So that this bot could create accounts, keep statistics and give out tasks and take shares from miners. I'm thinking about creating a pool but I'm afraid that my server is bogged down by DDoS attacks, so came up with this idea (to cover a pool node of servers Telegram)

i think bot may be interesting but later. pools is a good idea, there is now normally working pools.

An information with graph and statics about network and pool would be better.

[info_infoman1]

What do you think about the idea of creating a bot telegrams as frontend mining pool? So that this bot could create accounts, keep statistics and give out tasks and take shares from miners. I'm thinking about creating a pool but I'm afraid that my server is bogged down by DDoS attacks, so came up with this idea (to cover a pool node of servers Telegram)

i think bot may be interesting but later. pools is a good idea, there is now normally working pools.

An information with graph and statics about network and pool would be better.

Telegram bots support html5, there are no problems here

[megainarmy]

can we sometimes make infopost, may be with snapshot?

as example:

25.10.17
Exchanges listed:
coin-exchange
Exchanges asked to be listed:
Yobit(till 02.10.17, waiting answer (last - 15.10.17))
Cryptopia(till 05.10.17, asks 9BTC for listing)
Poloniex(till 10.10.17, waiting answer)
Scrypt/Wallet problems:
15.10.17 fixed Wallet(new wallet in 1st post)


etc

It would be nice, man!!! 

[pallas]

I wanted to share a discussion we had on slack recently.
It all started from the difficulty we are having of being listed on exchanges.
From an exchange integration point of view, Cryptonite is just like any other coin, except for the "extended precision" amounts.
Since they never tell us why xcn is not listed yet, we can't be sure that this is the problem, but it surely is something they must customize to support our coin.
What to do? Removing EP amounts and using standard 8 decimal numbers would make it downward incompatible, possibly breaking the services we already have, like nova exchange or the block explorer.
One possibility is adding a configuration option to disable extended precision amounts, so the exchanges can use the classic format, if they like.
It shouldn't be much work to do (developing such an option), BUT we must be sure that this doesn't bring any side effect.
Please share your opinions on the matter.

[info_infoman1]

I wanted to share a discussion we had on slack recently.
It all started from the difficulty we are having of being listed on exchanges.
From an exchange integration point of view, Cryptonite is just like any other coin, except for the "extended precision" amounts.
Since they never tell us why xcn is not listed yet, we can't be sure that this is the problem, but it surely is something they must customize to support our coin.
What to do? Removing EP amounts and using standard 8 decimal numbers would make it downward incompatible, possibly breaking the services we already have, like nova exchange or the block explorer.
One possibility is adding a configuration option to disable extended precision amounts, so the exchanges can use the classic format, if they like.
It shouldn't be much work to do (developing such an option), BUT we must be sure that this doesn't bring any side effect.
Please share your opinions on the matter.

Give extended information about EP, at the moment during my experiments directly in the code I use uint64, and EP touches me only in the RPC or QT interfaces

[mak013]

I wanted to share a discussion we had on slack recently.
It all started from the difficulty we are having of being listed on exchanges.
From an exchange integration point of view, Cryptonite is just like any other coin, except for the "extended precision" amounts.
Since they never tell us why xcn is not listed yet, we can't be sure that this is the problem, but it surely is something they must customize to support our coin.
What to do? Removing EP amounts and using standard 8 decimal numbers would make it downward incompatible, possibly breaking the services we already have, like nova exchange or the block explorer.
One possibility is adding a configuration option to disable extended precision amounts, so the exchanges can use the classic format, if they like.
It shouldn't be much work to do (developing such an option), BUT we must be sure that this doesn't bring any side effect.
Please share your opinions on the matter.

can u may snapshot/backup? to have opportunity to come back if smth will be wrong? ok,we`ll lost mined for 3-5-7 days, but if it can help with exchanges - it is ok, i think

[pallas]

I wanted to share a discussion we had on slack recently.
It all started from the difficulty we are having of being listed on exchanges.
From an exchange integration point of view, Cryptonite is just like any other coin, except for the "extended precision" amounts.
Since they never tell us why xcn is not listed yet, we can't be sure that this is the problem, but it surely is something they must customize to support our coin.
What to do? Removing EP amounts and using standard 8 decimal numbers would make it downward incompatible, possibly breaking the services we already have, like nova exchange or the block explorer.
One possibility is adding a configuration option to disable extended precision amounts, so the exchanges can use the classic format, if they like.
It shouldn't be much work to do (developing such an option), BUT we must be sure that this doesn't bring any side effect.
Please share your opinions on the matter.

Give extended information about EP, at the moment during my experiments directly in the code I use uint64, and EP touches me only in the RPC or QT interfaces

http://cryptonite.info/wiki/index.php?title=Coinbase_account

http://cryptonite.info/wiki/index.php?title=Cryptonite_API

[info_infoman1]

I wanted to share a discussion we had on slack recently.
It all started from the difficulty we are having of being listed on exchanges.
From an exchange integration point of view, Cryptonite is just like any other coin, except for the "extended precision" amounts.
Since they never tell us why xcn is not listed yet, we can't be sure that this is the problem, but it surely is something they must customize to support our coin.
What to do? Removing EP amounts and using standard 8 decimal numbers would make it downward incompatible, possibly breaking the services we already have, like nova exchange or the block explorer.
One possibility is adding a configuration option to disable extended precision amounts, so the exchanges can use the classic format, if they like.
It shouldn't be much work to do (developing such an option), BUT we must be sure that this doesn't bring any side effect.
Please share your opinions on the matter.

Give extended information about EP, at the moment during my experiments directly in the code I use uint64, and EP touches me only in the RPC or QT interfaces

http://cryptonite.info/wiki/index.php?title=Coinbase_account

http://cryptonite.info/wiki/index.php?title=Cryptonite_API

oooh swill here guys overdo it, implanted in the client that it was not worth it to implant ....   I think it was necessary at the outset to make 64to53.CLI expansion especially for exchanges and pools...

ps can we clean the code for today from the EP and to create a simple extension of the 64to53.CLI?

[pallas]

I wanted to share a discussion we had on slack recently.
It all started from the difficulty we are having of being listed on exchanges.
From an exchange integration point of view, Cryptonite is just like any other coin, except for the "extended precision" amounts.
Since they never tell us why xcn is not listed yet, we can't be sure that this is the problem, but it surely is something they must customize to support our coin.
What to do? Removing EP amounts and using standard 8 decimal numbers would make it downward incompatible, possibly breaking the services we already have, like nova exchange or the block explorer.
One possibility is adding a configuration option to disable extended precision amounts, so the exchanges can use the classic format, if they like.
It shouldn't be much work to do (developing such an option), BUT we must be sure that this doesn't bring any side effect.
Please share your opinions on the matter.

Give extended information about EP, at the moment during my experiments directly in the code I use uint64, and EP touches me only in the RPC or QT interfaces

http://cryptonite.info/wiki/index.php?title=Coinbase_account

http://cryptonite.info/wiki/index.php?title=Cryptonite_API

oooh swill here guys overdo it, implanted in the client that it was not worth it to implant ....   I think it was necessary at the outset to make 64to53.CLI expansion especially for exchanges and pools...

ps can we clean the code for today from the EP and to create a simple extension of the 64to53.CLI?

Another idea could be to return both the EP and non-EP amounts; for the RPC requests, we could add support for both types. This way they won't need to change the config file, just look at the rpc response.

[info_infoman1]

I wanted to share a discussion we had on slack recently.
It all started from the difficulty we are having of being listed on exchanges.
From an exchange integration point of view, Cryptonite is just like any other coin, except for the "extended precision" amounts.
Since they never tell us why xcn is not listed yet, we can't be sure that this is the problem, but it surely is something they must customize to support our coin.
What to do? Removing EP amounts and using standard 8 decimal numbers would make it downward incompatible, possibly breaking the services we already have, like nova exchange or the block explorer.
One possibility is adding a configuration option to disable extended precision amounts, so the exchanges can use the classic format, if they like.
It shouldn't be much work to do (developing such an option), BUT we must be sure that this doesn't bring any side effect.
Please share your opinions on the matter.

Give extended information about EP, at the moment during my experiments directly in the code I use uint64, and EP touches me only in the RPC or QT interfaces

http://cryptonite.info/wiki/index.php?title=Coinbase_account

http://cryptonite.info/wiki/index.php?title=Cryptonite_API

oooh swill here guys overdo it, implanted in the client that it was not worth it to implant ....   I think it was necessary at the outset to make 64to53.CLI expansion especially for exchanges and pools...

ps can we clean the code for today from the EP and to create a simple extension of the 64to53.CLI?

Another idea could be to return both the EP and non-EP amounts; for the RPC requests, we could add support for both types. This way they won't need to change the config file, just look at the rpc response.

and, we can add the -nonEP option

I think so, even better would be, it is always easier to add a small parameter in the configuration file and have the desired result

if we return the amounts in two versions, they will have to build a separate parser

-nonEP = 0 return EP
-nonEP = 1 return 53
-nonEP = 2 return 64

[info_infoman1]

pallas,
I think this option does not hurt, but you need to discuss with each exchange separately, because they may have already set up the parser EP

[pallas]

pallas,
I think this option does not hurt, but you need to discuss with each exchange separately, because they may have already set up the parser EP

that's why I said it must be backward-compatible.

say an rpc call returns "balance":

"balance" : "10.1234567800ep"

we can simply add:

"balance_dp" : "10.12345678"

the old exchange will continue using "balance", the new one (not wanting to support EP) will just use "balance_dp".

on the RPC request parameters, we can detect the missing final "ep" and translate it to EP, so the rest of the wallet works as before.

[gnasirator]

that's why I said it must be backward-compatible.

say an rpc call returns "balance":

"balance" : "10.1234567800ep"

we can simply add:

"balance_dp" : "10.12345678"

the old exchange will continue using "balance", the new one (not wanting to support EP) will just use "balance_dp".

on the RPC request parameters, we can detect the missing final "ep" and translate it to EP, so the rest of the wallet works as before.

I like that and absolutely agree that this feature needs backwards-compatibility.
Any new feature usually does until the old way to do things becomes obsolete because everybody has moved on.

[info_infoman1]

pallas,
I think this option does not hurt, but you need to discuss with each exchange separately, because they may have already set up the parser EP

that's why I said it must be backward-compatible.

say an rpc call returns "balance":

"balance" : "10.1234567800ep"

we can simply add:

"balance_dp" : "10.12345678"

the old exchange will continue using "balance", the new one (not wanting to support EP) will just use "balance_dp".

on the RPC request parameters, we can detect the missing final "ep" and translate it to EP, so the rest of the wallet works as before.

situation number 1  your Exchange is new and never before add Cryptonite-
in your Exchange standard should call returns "balance": "10.12345678"
but Cryptonite return "balance" : "10.1234567800ep"
well your Exchange must convert this answer "balance": to "10.12345678" or to take "balance_dp" : "10.12345678"
for this (to take "balance_dp") the exchange will have to edit the exchange's code
 ::)I think the exchange will not agree to this

situation number 2  your Exchange is not new and have add Cryptonite before change
well your Exchange can converting this answer "balance": from "10.1234567800ep" to "10.12345678"
and Exchange will not have problems

situation number 3  your Exchange is not new and have add Cryptonite before change
but they still have problem witch converting "10.1234567800ep" to "10.12345678"
and they are not agree to change exchange's code especially for this coin....
well Exchange still have problems

if we are
add the -nonEP option
-nonEP = 0 return EP(default)
-nonEP = 1 return 53
-nonEP = 2 return 64
for situation number 1 your Exchange only need to change the daemon startup parameters(-nonEP = 1 return 53) and not to change exchange's code especially for this coin
for situation number 2 your Exchange have backwards-compatibility(-nonEP = 0 return EP(default) - return "balance" : "10.1234567800ep")
for situation number 3 your Exchange only need to change the daemon startup parameters(-nonEP = 1 return 53) and restart daemon and not to change exchange's code especially for this coin

future:

situation number 4  your Exchange is new and never before add Cryptonite and can work with full 2^64-
Exchange only need to change the daemon startup parameters(-nonEP = 2 return full 64) and not to change exchange's code especially for this coin

[pallas]

it's true that the commandline option (or, better, conf option, or both) is less work for the exchange.
let's hear some more opinions then I'll start coding ;-)