◈◈Bitcredit ◈◈ Migrating to UniQredit◈◈

[thelonecrouton]

Does anyone have problems with the BN payments schedule?

Code:

int64_t GetBanknodePayment(int nHeight, int64_t blockValue)
{
    int64_t ret = blockValue/5; //20%

  
    if(nHeight > 85000)               ret += blockValue / 20; //  25.0% 
    if(nHeight > 85000+((1440*30)* 1)) ret += blockValue / 20; //  30.0% 
    if(nHeight > 85000+((1440*30)* 2)) ret += blockValue / 20; //  35.0% 
    if(nHeight > 85000+((1440*30)* 3)) ret += blockValue / 40; //  37.5% 
    if(nHeight > 85000+((1440*30)* 4)) ret += blockValue / 40; //  40.0% 
    if(nHeight > 85000+((1440*30)* 5)) ret += blockValue / 40; //  42.5% 
    if(nHeight > 85000+((1440*30)* 6)) ret += blockValue / 40; //  45.0% 
    if(nHeight > 85000+((1440*30)* 7)) ret += blockValue / 40; //  47.5% 
    if(nHeight > 85000+((1440*30)* 8)) ret += blockValue / 40; //  50.0% 
    if(nHeight > 85000+((1440*30)* 9)) ret += blockValue / 40; //  52.5% 
    if(nHeight > 85000+((1440*30)*10)) ret += blockValue / 40; //  55.0% 
    if(nHeight > 85000+((1440*30)*11)) ret += blockValue / 40; //  57.5% 
    if(nHeight > 85000+((1440*30)*12)) ret += blockValue / 40; //  60.0% 
    
    
    return ret;
}

Nope, looks fine, if anything I would ramp it forward - lower the 1440 to 800 to better reflect the avg. blocks per day and keep it more or less monthly, and keep the increments at 5%.

I never understood why Evan/DRK wanted to stretch the process out for 18 months - MNs and BNs are the core of both currencies, the value added by having them far outweighs any 'loss' to the miners.

edit: just read your google spreadsheet, yeah BN reward should increase over time, not decrease! I had been working off just the code above, hadn't taken into account the block reduction... kind of drastically changes the picture for a BN investor...

More money held in BNs means greater price stability too.

[1714787824]

1714787824

[1714787824]

1714787824

[1714787824]

1714787824

[1714787824]

1714787824

[thelonecrouton]

bitcreditscc, any ideas why block 107254 has so far taken 1hr42mins? I tried to setgenerate true to hurry it on a bit but got a core dump. 

The pools have like 4-5 kh/s. at diff 3k, that should be solved in like 30 seconds ...i think its not on a high diff block so something else is up, as time proceeds i am sure it will illuminate itself.  Also, it seems that the new wallet has fixed the syncing issue of yesterday so that's one down.

can you post your getblocktemplate?

Unfortunately, I still can not send! Any ideas?

07:52:55

getblocktemplate


07:52:55

CreateNewBlock() : TestBlockValidity failed (code -1)

Have you unchecked the Darksend box in the Send screen?

[siameze]

Anyone here that has experience building this on Debian 7/8 ? I have tried at random times over the past few weeks to build and still run into dependency issues, despite building against the latest boost. I am obviously missing something but this is my first go at building this type of wallet with added features, etc.


EDIT: This is a 64 bit system, which carries it's own headaches. Configure fails at this point:

checking whether the linker accepts -Wl,--exclude-libs,ALL... yes
configure: error: No working boost sleep implementation found.


I am sure with Wheezy, it is still reading the system boost headers. If I build latest boost and define the path during configure, it will still fail on the same note.

[dragos_bdi]

Anyone here that has experience building this on Debian 7/8 ? I have tried at random times over the past few weeks to build and still run into dependency issues, despite building against the latest boost. I am obviously missing something but this is my first go at building this type of wallet with added features, etc.


EDIT: This is a 64 bit system, which carries it's own headaches. Configure fails at this point:

checking whether the linker accepts -Wl,--exclude-libs,ALL... yes
configure: error: No working boost sleep implementation found.


I am sure with Wheezy, it is still reading the system boost headers. If I build latest boost and define the path during configure, it will still fail on the same note.

what boost version ?
did you compiled from source ?
are you sure you've compiled all libraries ?

[siameze]

Anyone here that has experience building this on Debian 7/8 ? I have tried at random times over the past few weeks to build and still run into dependency issues, despite building against the latest boost. I am obviously missing something but this is my first go at building this type of wallet with added features, etc.


EDIT: This is a 64 bit system, which carries it's own headaches. Configure fails at this point:

checking whether the linker accepts -Wl,--exclude-libs,ALL... yes
configure: error: No working boost sleep implementation found.


I am sure with Wheezy, it is still reading the system boost headers. If I build latest boost and define the path during configure, it will still fail on the same note.

what boost version ?
did you compiled from source ?
are you sure you've compiled all libraries ?

Boost is 1.58.0 all libs compiled from source. I have also attempted build using qmake (for simplicity sake) and get the error:

/root/crypto/bicreditsnew/bitcredit-qt.pro:540: Parse Error ('src/qt/res/themes/qdarkstyle/style.qrc')
Error processing project file: /root/crypto/bicreditsnew/bitcredit-qt.pro

[Mario241077]

bitcreditscc, any ideas why block 107254 has so far taken 1hr42mins? I tried to setgenerate true to hurry it on a bit but got a core dump.  

The pools have like 4-5 kh/s. at diff 3k, that should be solved in like 30 seconds ...i think its not on a high diff block so something else is up, as time proceeds i am sure it will illuminate itself.  Also, it seems that the new wallet has fixed the syncing issue of yesterday so that's one down.

can you post your getblocktemplate?

Unfortunately, I still can not send! Any ideas?

07:52:55

getblocktemplate


07:52:55

CreateNewBlock() : TestBlockValidity failed (code -1)

Have you unchecked the Darksend box in the Send screen?

yes, unchecked

Status: conflicted, has not been successfully broadcast yet
Date: 07.05.2015 07:37
To: 6ELnLCQbGTw1E3oxqm36CKU3E1o2EcVivR
Debit: -100.00000000 BCR
Net amount: -49.20700906 BCR
Transaction ID: 1862ecf5e44e0c7e25ba7e4a07082c03d003dc0ab6f49a5d9dbece1dd195da9a-000

[dragos_bdi]

Anyone here that has experience building this on Debian 7/8 ? I have tried at random times over the past few weeks to build and still run into dependency issues, despite building against the latest boost. I am obviously missing something but this is my first go at building this type of wallet with added features, etc.


EDIT: This is a 64 bit system, which carries it's own headaches. Configure fails at this point:

checking whether the linker accepts -Wl,--exclude-libs,ALL... yes
configure: error: No working boost sleep implementation found.


I am sure with Wheezy, it is still reading the system boost headers. If I build latest boost and define the path during configure, it will still fail on the same note.

what boost version ?
did you compiled from source ?
are you sure you've compiled all libraries ?

Boost is 1.58.0 all libs compiled from source. I have also attempted build using qmake (for simplicity sake) and get the error:

/root/crypto/bicreditsnew/bitcredit-qt.pro:540: Parse Error ('src/qt/res/themes/qdarkstyle/style.qrc')
Error processing project file: /root/crypto/bicreditsnew/bitcredit-qt.pro

I don't tryed to compile using the qmake, so I can't tell you nothing.
Could you tell me the "./b2" line used ?

[bitcreditscc]

bitcreditscc, any ideas why block 107254 has so far taken 1hr42mins? I tried to setgenerate true to hurry it on a bit but got a core dump.  

The pools have like 4-5 kh/s. at diff 3k, that should be solved in like 30 seconds ...i think its not on a high diff block so something else is up, as time proceeds i am sure it will illuminate itself.  Also, it seems that the new wallet has fixed the syncing issue of yesterday so that's one down.

can you post your getblocktemplate?

Unfortunately, I still can not send! Any ideas?

07:52:55

getblocktemplate


07:52:55

CreateNewBlock() : TestBlockValidity failed (code -1)

Have you unchecked the Darksend box in the Send screen?

yes, unchecked

Status: conflicted, has not been successfully broadcast yet
Date: 07.05.2015 07:37
To: 6ELnLCQbGTw1E3oxqm36CKU3E1o2EcVivR
Debit: -100.00000000 BCR
Net amount: -49.20700906 BCR
Transaction ID: 1862ecf5e44e0c7e25ba7e4a07082c03d003dc0ab6f49a5d9dbece1dd195da9a-000

Activation of darksend has brought it's own problems, i am looking into this. As far as i am concerned , i would completely deactivate it. Darksend in my opinion is a gimmick.Enough anonymity is already assured by not using the same address for anything other than Bank Tx. And even then i have figure a way that allows users to use different addresses while still maintaining trust rating.

I only made it active after soe users indicated they wanted it. but even on DRK chain, it is barely used.

[bitcreditscc]

Code:

Program received signal SIGSEGV, Segmentation fault.
WalletModel::getOptionsModel (this=0x0) at qt/walletmodel.cpp:413
413	    return optionsModel;

this headache

[thelonecrouton]

As far as i am concerned , i would completely deactivate it. Darksend in my opinion is a gimmick.Enough anonymity is already assured by not using the same address for anything other than Bank Tx. And even then i have figure a way that allows users to use different addresses while still maintaining trust rating.

I only made it active after soe users indicated they wanted it. but even on DRK chain, it is barely used.

I would also vote to shelve Darksend, at least for the time being.

Use of DS by itself does not remotely guard your privacy from TPTB or any competent sleuth, there are just too may other weak links in the chain, although I suppose it might let you slip a purchase for your mistress past your wife.

Even then, I have been asking for over a year now, to no avail, for DRK to implement optional password protection before the wallet will display your balance or transaction history. Sending funds 'anonymously' to your supplier is useless if anyone can come along, glance at your wallet and read "$xxxx.xx to chocolate-covered-nuns.com, 21 Jan 2015"

[bitcreditscc]

As far as i am concerned , i would completely deactivate it. Darksend in my opinion is a gimmick.Enough anonymity is already assured by not using the same address for anything other than Bank Tx. And even then i have figure a way that allows users to use different addresses while still maintaining trust rating.

I only made it active after soe users indicated they wanted it. but even on DRK chain, it is barely used.

I would also vote to shelve Darksend, at least for the time being.

Use of DS by itself does not remotely guard your privacy from TPTB or any competent sleuth, there are just too may other weak links in the chain, although I suppose it might let you slip a purchase for your mistress past your wife.

Even then, I have been asking for over a year now, to no avail, for DRK to implement optional password protection before the wallet will display your balance or transaction history. Sending funds 'anonymously' to your supplier is useless if anyone can come along, glance at your wallet and read "$xxxx.xx to chocolate-covered-nuns.com, 21 Jan 2015"

 

weird tastes much? Actually gonna google that

I agree with your points though. I think we should call a vote on all current issues and have the community decide.

For the next 24 hours, let us hear arguments and vote on

1) BN payments increase (perhaps a static % for the entire lifetime?, i'd say 40% but don't mind me, i'm a multiple BN owner)

2) Darksend ( i think we should keep InstantX)

[dbt1033]

Any thoughts?  Happens with new wallet within a minute of launching.

[bitcreditscc]

To speed up the error resolving, i will offer 50 BCR per pull request that has a valid fix for any area of the code. I your pull request is large and has multiple fixes, just put the fix count in the Pr title and sign with your wallet address.  

[bitcreditscc]

Any thoughts?  Happens with new wallet within a minute of launching.

->

Code:

Program received signal SIGSEGV, Segmentation fault.
WalletModel::getOptionsModel (this=0x0) at qt/walletmodel.cpp:413
413	    return optionsModel;

this headache

[dbt1033]

Any thoughts?  Happens with new wallet within a minute of launching.

->

Code:

Program received signal SIGSEGV, Segmentation fault.
WalletModel::getOptionsModel (this=0x0) at qt/walletmodel.cpp:413
413	    return optionsModel;

this headache

LOL... ok man just wondering.

Good luck!

[siameze]

Anyone here that has experience building this on Debian 7/8 ? I have tried at random times over the past few weeks to build and still run into dependency issues, despite building against the latest boost. I am obviously missing something but this is my first go at building this type of wallet with added features, etc.


EDIT: This is a 64 bit system, which carries it's own headaches. Configure fails at this point:

checking whether the linker accepts -Wl,--exclude-libs,ALL... yes
configure: error: No working boost sleep implementation found.


I am sure with Wheezy, it is still reading the system boost headers. If I build latest boost and define the path during configure, it will still fail on the same note.

what boost version ?
did you compiled from source ?
are you sure you've compiled all libraries ?

Boost is 1.58.0 all libs compiled from source. I have also attempted build using qmake (for simplicity sake) and get the error:

/root/crypto/bicreditsnew/bitcredit-qt.pro:540: Parse Error ('src/qt/res/themes/qdarkstyle/style.qrc')
Error processing project file: /root/crypto/bicreditsnew/bitcredit-qt.pro

I don't tryed to compile using the qmake, so I can't tell you nothing.
Could you tell me the "./b2" line used ?

I used the same ./b2 install I always use. Always these little things that get me during a build

Thanks to all here for the help.

[thelonecrouton]

For the next 24 hours, let us hear arguments and vote on

1) BN payments increase (perhaps a static % for the entire lifetime?, i'd say 40% but don't mind me, i'm a multiple BN owner)

2) Darksend ( i think we should keep InstantX)

1) 40% I can live with. Maybe a voted review every 6 months or something.
2) DS is at best a false sense of security for the few that use it. IX is useful for everyone, all the time.

[dbt1033]

For the next 24 hours, let us hear arguments and vote on

1) BN payments increase (perhaps a static % for the entire lifetime?, i'd say 40% but don't mind me, i'm a multiple BN owner)

2) Darksend ( i think we should keep InstantX)

1) 40% I can live with. Maybe a voted review every 6 months or something.
2) DS is at best a false sense of security for the few that use it. IX is useful for everyone, all the time.

Thumbs up from me... On both thoughts.

[starblocks]

As far as i am concerned , i would completely deactivate it. Darksend in my opinion is a gimmick.Enough anonymity is already assured by not using the same address for anything other than Bank Tx. And even then i have figure a way that allows users to use different addresses while still maintaining trust rating.

I only made it active after soe users indicated they wanted it. but even on DRK chain, it is barely used.

I would also vote to shelve Darksend, at least for the time being.

Use of DS by itself does not remotely guard your privacy from TPTB or any competent sleuth, there are just too may other weak links in the chain, although I suppose it might let you slip a purchase for your mistress past your wife.

Even then, I have been asking for over a year now, to no avail, for DRK to implement optional password protection before the wallet will display your balance or transaction history. Sending funds 'anonymously' to your supplier is useless if anyone can come along, glance at your wallet and read "$xxxx.xx to chocolate-covered-nuns.com, 21 Jan 2015"

 

weird tastes much? Actually gonna google that

I agree with your points though. I think we should call a vote on all current issues and have the community decide.

For the next 24 hours, let us hear arguments and vote on

1) BN payments increase (perhaps a static % for the entire lifetime?, i'd say 40% but don't mind me, i'm a multiple BN owner)

2) Darksend ( i think we should keep InstantX)

I'm not so sold on darksend or mixing but I'd like to know how many people actually use it? Like even with Dash do many people actually use it for much? (it's not even real anon anyway no such thing yet as far as I know) - I'd still be curious as to statistics of how many people use this feature...

InstantX is very handy

Edit: Perhaps just put the darksend thingo on the roadmap as a feature that can be re-added later if enough people request it

[bitcreditscc]

Yeah, if it really is useful we can always have it later. For now i'd rather focus on finishing up the internal messaging and stats engine.

If we can agree, i will institute the changes in the next update. Currently seeking the BN issue where they aren't being registered by some peers.