[BBR] Boolberry: Privacy and Security - Guaranteed Since 2014 - page 293.

eddywise

sr. member

Activity: 253

Merit: 250

Let's Boolberry

I cant believe BBR value only 1219BTC on the coinmarketcap

jl777

legendary

Activity: 1176

Merit: 1134

Quote from: superplus on September 11, 2014, 05:39:36 PM

Quote from: jl777 on September 11, 2014, 05:19:24 PM

Quote from: S3MKi on September 11, 2014, 04:36:15 PM

when will be add to bter?

I can push for it, but last I heard people wanted this to be delayed for a while

bter people? i think it wouldn't harm to have some more exchanges
push it Wink

see, not many want this and I dont want to keep asking for favors if there is no strong feeling for it

superplus

sr. member

Activity: 475

Merit: 500

Quote from: jl777 on September 11, 2014, 05:19:24 PM

Quote from: S3MKi on September 11, 2014, 04:36:15 PM

when will be add to bter?

I can push for it, but last I heard people wanted this to be delayed for a while

bter people? i think it wouldn't harm to have some more exchanges
push it Wink

jl777

legendary

Activity: 1176

Merit: 1134

Quote from: S3MKi on September 11, 2014, 04:36:15 PM

when will be add to bter?

I can push for it, but last I heard people wanted this to be delayed for a while

clintar

full member

Activity: 212

Merit: 100

Quote from: mitache365 on September 11, 2014, 04:38:29 PM

not sure how to change intensity. thanks.

It's just -i 18 on his gpu miner.

mitache365

hero member

Activity: 732

Merit: 500

Quote from: mbk on September 10, 2014, 06:39:30 PM

MBK's Boolberry Mining Pool

I've spend a lot of time optimizing OpenCL miner so later I looked at how pools work too. Clintar fixed the problems so pools work much better now if updated. Anyway I have some ideas how to tune the pool to get more blocks on the same hardware. I tested it for a week with my GPU farm, rented a decent server and now you can give my pool a try.

http://bbr.mbkpool.info

Usage with my OpenCL miner:
Windows

Code:

minerd.exe -a wildkeccak_ocl -o stratum+tcp://bbr.mbkpool.info:7777 -u YOUR_WALLET_ADDRESS -p x -k http://bbr.mbkpool.info/scratchpad.bin -l scratchpad.bin

Linux

Code:

minerd -a wildkeccak_ocl -o stratum+tcp://bbr.mbkpool.info:7777 -u YOUR_WALLET_ADDRESS -p x -k http://bbr.mbkpool.info/scratchpad.bin -l ~/scratchpad.bin

Changes:

100ms boolbd daemon polling interval - to get new blocks as soon as possible (later I could make it even less)
1 minute difficulty targeting - it's better to make shares rarer and more valuable in current miner implementation (starting diff is 150 millions on port 9999 for multi-GPUs)

Options to try:
-i x (intensity) - default value is 18, try lower values if it doesn't lower your hashrate as it will improve efficiency (we cannot exit GPU calculation cycle so the shorter cycle means less time we lose when new block arrives)

I'm not talking about large improvement but the miners should be close to 100% efficiency. You can try it and make decision yourself. Look at miner's output and compare. In the real example below the miner calculates 1112 kh/s and every hash works to make a share on the pool.

Code:

[2014-09-10 21:56:40.175] eff: 100% @ 1112 kh/s, accepted: 1251/1251 (100.00%), 1101 kh/s at diff 76695845 (yay!!!)

not sure how to change intensity. thanks.

S3MKi

legendary

Activity: 1540

Merit: 1016

when will be add to bter?

crypto_zoidberg

hero member

Activity: 976

Merit: 646

Quote from: clintar on September 11, 2014, 03:07:45 PM

Quote from: crypto_zoidberg on September 11, 2014, 02:56:44 PM

Clintar, thank you for understanding, atm i moved your pool to last position in pool's list. Let's see how it's going. Another move that we can do - is to exclude you from list for few days to spread hashrate around other pools, only in case if you don't mind.

Nope, I don't mind. How do you like my proposal for the round robin dns idea? Downside is it having to be maintained by you. I guess pools could host their own with their own server as priority, too, in case someone wants to mine at a certain pool and have failover.

I like it much(exept thing that i have to maintain it

), good idea, and it definitely some new approach. Since you seems to be trusted person for me and for community, i would be happy to see you as maintainer of this, what you think ? I really have a lot of stuff last days, even have not enough time to code.

btw: i wrote you in irc, did you saw it ?

clintar

full member

Activity: 212

Merit: 100

Quote from: crypto_zoidberg on September 11, 2014, 02:56:44 PM

Clintar, thank you for understanding, atm i moved your pool to last position in pool's list. Let's see how it's going. Another move that we can do - is to exclude you from list for few days to spread hashrate around other pools, only in case if you don't mind.

Nope, I don't mind. How do you like my proposal for the round robin dns idea? Downside is it having to be maintained by you. I guess pools could host their own with their own server as priority, too, in case someone wants to mine at a certain pool and have failover.

crypto_zoidberg

hero member

Activity: 976

Merit: 646

Quote from: clintar on September 11, 2014, 09:54:40 AM

Quote from: Hotmetal on September 11, 2014, 03:51:25 AM

Quote from: clintar on September 10, 2014, 10:34:32 PM

Nice, looks good. Sounds like I should change some diffs, then, too .

http://cncoin.farm/

Network
Hash Rate: 7.29 GH/sec
Block Found: 2 minutes ago

Our Pool
Hash Rate: 3.51 GH/sec
Block Found: 2 minutes ago

Right now BBR is getting itself into a bad situation for multiple reasons.. Besides the 51% attack, a DDOS attack @ http://cncoin.farm/ and mining BBR becomes *extremely* profitable for an attacker.

I was wondering what I can do about that. Probably need miners to fail-over at least. If pools had standard ports, I was wondering if a round-robin dns with all of them listed would work out ok. Otherwise I guess I can set a really high fee to get people to switch when it's so high, but I'd sure look greedy doing that with so much of the network.

Clintar, thank you for understanding, atm i moved your pool to last position in pool's list. Let's see how it's going. Another move that we can do - is to exclude you from list for few days to spread hashrate around other pools, only in case if you don't mind.

crypto_zoidberg

hero member

Activity: 976

Merit: 646

Quote from: mbk on September 10, 2014, 06:39:30 PM

MBK's Boolberry Mining Pool

I've spend a lot of time optimizing OpenCL miner so later I looked at how pools work too. Clintar fixed the problems so pools work much better now if updated. Anyway I have some ideas how to tune the pool to get more blocks on the same hardware. I tested it for a week with my GPU farm, rented a decent server and now you can give my pool a try.

http://bbr.mbkpool.info

Usage with my OpenCL miner:
Windows

Code:

minerd.exe -a wildkeccak_ocl -o stratum+tcp://bbr.mbkpool.info:7777 -u YOUR_WALLET_ADDRESS -p x -k http://bbr.mbkpool.info/scratchpad.bin -l scratchpad.bin

Linux

Code:

minerd -a wildkeccak_ocl -o stratum+tcp://bbr.mbkpool.info:7777 -u YOUR_WALLET_ADDRESS -p x -k http://bbr.mbkpool.info/scratchpad.bin -l ~/scratchpad.bin

Changes:

100ms boolbd daemon polling interval - to get new blocks as soon as possible (later I could make it even less)
1 minute difficulty targeting - it's better to make shares rarer and more valuable in current miner implementation (starting diff is 150 millions on port 9999 for multi-GPUs)

Options to try:
-i x (intensity) - default value is 18, try lower values if it doesn't lower your hashrate as it will improve efficiency (we cannot exit GPU calculation cycle so the shorter cycle means less time we lose when new block arrives)

I'm not talking about large improvement but the miners should be close to 100% efficiency. You can try it and make decision yourself. Look at miner's output and compare. In the real example below the miner calculates 1112 kh/s and every hash works to make a share on the pool.

Code:

[2014-09-10 21:56:40.175] eff: 100% @ 1112 kh/s, accepted: 1251/1251 (100.00%), 1101 kh/s at diff 76695845 (yay!!!)

Added! Thank you!

crypto_zoidberg

hero member

Activity: 976

Merit: 646

Quote from: Pyrrhic on September 10, 2014, 12:39:19 PM

Quote from: smooth on September 10, 2014, 11:18:24 AM

The spending of the multisig output is the point at which the funds become spent by the group and respendable by the new owner.

how to determine that someone has spent a transaction? apart from a transaction itself being spend, is it possible to determine if a transaction was spent by a specific address viewing only the blockchain? or can it only be understood that the tx has not been respent yet, which can require the forced mixin?

aside, can the chain be parsed in order to determine only that a transaction has been spent, when another transaction attempting to mixin with it is completed. if someone mixed with a previous multisig tx, is it possible to determine that that multisig tx was spent, ie: invalid for mixing?

.....

I'm not sure if i understand your post corret, i only want to point that you can't see addresses in blockchain, and you can't say on which address was sent transaction (except in the case when you have tracking key of recipient address), since CN blockchain don't have addresses in it.

Hotmetal

sr. member

Activity: 378

Merit: 250

Quote from: clintar on September 11, 2014, 11:34:36 AM

We could have a site that queries all in the list for your address on the api port.

Edit: I've set up a SRV record as an example. _bb._tcp.us.cncoin.farm that has all the pools listed on the first page that have dns names for connecting. That is one issue with this approach. All pools would have to have a name and not an IP for a SRV record to work. You can see what it returns with

Code:

dig SRV _bb._tcp.us.cncoin.farm

in linux, or

Code:

nslookup -type=all _bb._tcp.us.cncoin.farm

in windows.
example output:

Code:

;; ANSWER SECTION:
_bb._tcp.us.cncoin.farm. 7199 IN SRV 10 0 11007 bbr.poolto.be.
_bb._tcp.us.cncoin.farm. 7199 IN SRV 0 0 7777 bbr.cncoin.farm.
_bb._tcp.us.cncoin.farm. 7199 IN SRV 0 0 1111 mine.bbr.unipool.pro.
_bb._tcp.us.cncoin.farm. 7199 IN SRV 0 0 7777 boolberry.extremepool.org.

Notice it gives a port. It has a priority that I have set the non-us pool to a higher number to give it less priority. Could do the opposite with a _bb._tcp.non-us or _bb._tcp.eu or whatever, even separate lists for cpu/gpu ports. Obviously, it should be managed by core boolberry team or at least not a pool operator, and then miner would have to use something like libsrv (first google hit I saw) to query this record. We could even have a complimentary SRV record to determine API port of these servers I guess. What do you think?

Reference I used for SRV records here: http://www.zytrax.com/books/dns/ch8/srv.html

Quite an elegant solution actually. No other coin offers this type of integration either. Allowing a core boolberry team member to operate it means complaints about scams, faulty pooling payouts etc can easily be addressed and failure to fix a problem or comply will mean the majority of every day people will not be served automagically from the boolberry master pool.

clintar

full member

Activity: 212

Merit: 100

Quote from: Hotmetal on September 11, 2014, 10:11:06 AM

Quote from: clintar on September 11, 2014, 09:54:40 AM

Quote from: Hotmetal on September 11, 2014, 03:51:25 AM

Quote from: clintar on September 10, 2014, 10:34:32 PM

Nice, looks good. Sounds like I should change some diffs, then, too .

http://cncoin.farm/

Network
Hash Rate: 7.29 GH/sec
Block Found: 2 minutes ago

Our Pool
Hash Rate: 3.51 GH/sec
Block Found: 2 minutes ago

Right now BBR is getting itself into a bad situation for multiple reasons.. Besides the 51% attack, a DDOS attack @ http://cncoin.farm/ and mining BBR becomes *extremely* profitable for an attacker.

I was wondering what I can do about that. Probably need miners to fail-over at least. If pools had standard ports, I was wondering if a round-robin dns with all of them listed would work out ok. Otherwise I guess I can set a really high fee to get people to switch when it's so high, but I'd sure look greedy doing that with so much of the network.

Some type of round robin would actually work out really well. Then all pool owners can apply to be apart of the pool. There are a lot of reasons this is a good way of doing it.
The down side to doing it would be how would a miner see his hashrate?

We could have a site that queries all in the list for your address on the api port.

Edit: I've set up a SRV record as an example. _bb._tcp.us.cncoin.farm that has all the pools listed on the first page that have dns names for connecting. That is one issue with this approach. All pools would have to have a name and not an IP for a SRV record to work. You can see what it returns with

Code:

dig SRV _bb._tcp.us.cncoin.farm

in linux, or

Code:

nslookup -type=all _bb._tcp.us.cncoin.farm

in windows.
example output:

Code:

;; ANSWER SECTION:
_bb._tcp.us.cncoin.farm. 7199 IN SRV 10 0 11007 bbr.poolto.be.
_bb._tcp.us.cncoin.farm. 7199 IN SRV 0 0 7777 bbr.cncoin.farm.
_bb._tcp.us.cncoin.farm. 7199 IN SRV 0 0 1111 mine.bbr.unipool.pro.
_bb._tcp.us.cncoin.farm. 7199 IN SRV 0 0 7777 boolberry.extremepool.org.

Notice it gives a port. It has a priority that I have set the non-us pool to a higher number to give it less priority. Could do the opposite with a _bb._tcp.non-us or _bb._tcp.eu or whatever, even separate lists for cpu/gpu ports. Obviously, it should be managed by core boolberry team or at least not a pool operator, and then miner would have to use something like libsrv (first google hit I saw) to query this record. We could even have a complimentary SRV record to determine API port of these servers I guess. What do you think?

Reference I used for SRV records here: http://www.zytrax.com/books/dns/ch8/srv.html

Hotmetal

sr. member

Activity: 378

Merit: 250

Quote from: clintar on September 11, 2014, 09:54:40 AM

Quote from: Hotmetal on September 11, 2014, 03:51:25 AM

Quote from: clintar on September 10, 2014, 10:34:32 PM

Nice, looks good. Sounds like I should change some diffs, then, too .

http://cncoin.farm/

Network
Hash Rate: 7.29 GH/sec
Block Found: 2 minutes ago

Our Pool
Hash Rate: 3.51 GH/sec
Block Found: 2 minutes ago

Right now BBR is getting itself into a bad situation for multiple reasons.. Besides the 51% attack, a DDOS attack @ http://cncoin.farm/ and mining BBR becomes *extremely* profitable for an attacker.

I was wondering what I can do about that. Probably need miners to fail-over at least. If pools had standard ports, I was wondering if a round-robin dns with all of them listed would work out ok. Otherwise I guess I can set a really high fee to get people to switch when it's so high, but I'd sure look greedy doing that with so much of the network.

Some type of round robin would actually work out really well. Then all pool owners can apply to be apart of the pool. There are a lot of reasons this is a good way of doing it.
The down side to doing it would be how would a miner see his hashrate?

clintar

full member

Activity: 212

Merit: 100

Quote from: Hotmetal on September 11, 2014, 03:51:25 AM

Quote from: clintar on September 10, 2014, 10:34:32 PM

Nice, looks good. Sounds like I should change some diffs, then, too .

http://cncoin.farm/

Network
Hash Rate: 7.29 GH/sec
Block Found: 2 minutes ago

Our Pool
Hash Rate: 3.51 GH/sec
Block Found: 2 minutes ago

Right now BBR is getting itself into a bad situation for multiple reasons.. Besides the 51% attack, a DDOS attack @ http://cncoin.farm/ and mining BBR becomes *extremely* profitable for an attacker.

I was wondering what I can do about that. Probably need miners to fail-over at least. If pools had standard ports, I was wondering if a round-robin dns with all of them listed would work out ok. Otherwise I guess I can set a really high fee to get people to switch when it's so high, but I'd sure look greedy doing that with so much of the network.

mbk

member

Activity: 106

Merit: 10