BoolBerry seems to compile fine with libboost 1.54
But does it work ?
I'm asking since other cryptonight don't seem to like 1.54.
DON'T USE libboost 1.54 Thank you to point this, i've updated readme and cmakelists. Ok, anyway it seems the bug is only for windows so you could put this restriction on windows only... |
|
|
|
|
BoolBerry seems to compile fine with libboost 1.54
But does it work ?
I'm asking since other cryptonight don't seem to like 1.54.
|
|
|
|
already have trollcoin
Added
Cinnicoin
Communitycoin
Monero
Sharecoin
Thanks, can't seems to see the Monero thought ! |
|
|
|
FeeShare earn 30% stake by itself (These are stake generated from the ShareCoin you used to buy FeeShare) plus the revenues generated from ShareXcoin.com
ShareCoin will earn 30% stake by itself and 30% more from the FeeShare sale.
How can FeeShare generate 30% from the corresponding ShareCoin since there is 10 time more (relative to value) FeeShare than ShareCoin ? This smell bad. The interest is not going on forever the interest is only a way to re-distribute ShareCoin to the community. The more FeeShare sold, the faster ShareCoins are redistributed. Interest will stop when all 50,000 FeeShare are released. At this point, ShareCoin and FeeShare won't gain any interest. Only 50% revenues of the exchange are paid to FeeShare holders by Bitcoin. @lzr1900: I suggest you going through this first before spreading FUD like that: https://sharexcoin.com/fee_shares/aboutOK, that isn't written in the about. Another question : Will you stop market trading for FeeShare when you go for the next round of FeeShare sell ? And if not, will you credit immediately the FeeShare bought with (20,000) ShareCoins to the buyer account ? |
|
|
|
FeeShare earn 30% stake by itself (These are stake generated from the ShareCoin you used to buy FeeShare) plus the revenues generated from ShareXcoin.com
ShareCoin will earn 30% stake by itself and 30% more from the FeeShare sale.
How can FeeShare generate 30% from the corresponding ShareCoin since there is 10 time more (relative to value) FeeShare than ShareCoin ? This smell bad. |
|
|
|
|
For the next round of feeshare sale, will the feeshare be distributed immediately on purchase ?
Will the market be closed during that time ?
|
|
|
|
|
Well actually, there is a bounty system that could work !
The problem with your other proposal was that you wanted to peg the donation with a parameter that could be cheated.
So I suggest you add a bounty option to your pool !
|
|
|
|
Can you explain how someone could corrupt the block chain ?
If I'm synced with the network, then the checkpoint won't affect me since they are in the past.
And I won't accept changing old blocks.
So you should explain us how the checkpoint corrupted the blockchain, and how to check for a good or bad one.
Is'nt there a command to recheck the entire blockchain, without having to download it ?
If not, it is needed.
If you had a full chain, it very likely was never corrupted. (Of course there could always be bugs but we don't know of any that would do this.) If you had tried to sync after the checkpoint was added, the code could have accepted some earlier blocks (before the checkpoint) without fully validating them. If you downloaded a valid blockchain file (which would have included all of the blocks up to the checkpoint) and used the code version with the checkpoint, you were in all likelyhood not affected, other than some invalid blocks being accepted by your node (but offchain), bloating your memory and disk usage. This could have eventually become a denial-of-service issue, if the number of invalid blocks continued to grow. There were probably very few people directly affected. But when it comes to the integrity of the blockchain it does not pay to take chances. So the checkpoint has been temporarily removed forcing all blocks to be fully validated and will likely soon be added back in a safer way. A command to validate the existing block chain is a good idea. We will look at that, possibly in connection with the improved checkpoint feature. Thank you for the clarification. How come an offchain block is stored on disk ? |
|
|
|
For each tx donation value is defined as:
donation(tx) = (if (donation_flag_set) fee; else 0);
For each block average donations value is:
avr_donations(block) = sum_of_all_tx_donatons/tx_count
For example:
block1 have following transactions in txs[]:
txs[0]: fee=100, donation flag=0;
txs[1]: fee=200, donation flag=0;
txs[2]: fee=100, donation flag=1;
txs[3]: fee=150, donation flag=0;
txs[4]: fee=100, donation flag=1;
txs[5]: fee=100, donation flag=0;
avr_donations(block1) = (0 + 0 + 100 + 0 + 100 + 0)/6 = 33
Finally, once a day(each 720th block) donation value to transfer to devs calculated as a median(avr_donations(block0), avr_donations(block1)....avr_donations(block719)) * 720
Does it make sense ?
UPDATE:
donations(block1) = (0 + 0 + 100 + 0 + 100 + 0) = 200
Ok you have removed the averaging in the block, and now are adding the transaction fee. This mean that my previous attack will be always successful whatever the foreign transaction are. Let's just say you forgot to add my /2 requirement and think with it included. I will use fee=1 for easiness. Now if only 40% block tx voted for a donation, you will just have to add 10% tx to get the donation. So you will pay 72 to win 720/2=360, net result : 360-72=288. So basically you just need one vote so that your cheating will be worth it : you pay 359 you win 360, net result : 1 By the way did you chose a 2 min block time ? |
|
|
|
|
Can you explain how someone could corrupt the block chain ?
If I'm synced with the network, then the checkpoint won't affect me since they are in the past.
And I won't accept changing old blocks.
So you should explain us how the checkpoint corrupted the blockchain, and how to check for a good or bad one.
Is'nt there a command to recheck the entire blockchain, without having to download it ?
If not, it is needed.
|
|
|
|
|
What about the low hashrate of minerc, how does it relate to HR in daemon ?
|
|
|
|
bitmonero wallet v0.8.6.295()
password: *************
Opened wallet: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Starting refresh...
Error: refresh failed: daemon is busy. Please try later. Blocks received: 0
Can't refresh (tried multiple time), bitmonero compiled from source and the daemon is fully synced. This is not working since few days, I updated source but still not working. The daemon can mine however. Any idea ? Edit : using libboost 1.53 Try typing "save" in the daemon window It worked thanks ! But that's strange since I did multiple exit and relaunch witch would have saved the blockchain. Any way ... good to know. |
|
|
|
bitmonero wallet v0.8.6.295()
password: *************
Opened wallet: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Starting refresh...
Error: refresh failed: daemon is busy. Please try later. Blocks received: 0
Can't refresh (tried multiple time), bitmonero compiled from source and the daemon is fully synced. This is not working since few days, I updated source but still not working. The daemon can mine however. Any idea ? Edit : using libboost 1.53 |
|
|
|
For each tx donation value is defined as:
donation(tx) = (if (donation_flag_set) fee; else 0);
For each block average donations value is:
avr_donations(block) = sum_of_all_tx_donatons/tx_count
For example:
block1 have following transactions in txs[]:
txs[0]: fee=100, donation flag=0;
txs[1]: fee=200, donation flag=0;
txs[2]: fee=100, donation flag=1;
txs[3]: fee=150, donation flag=0;
txs[4]: fee=100, donation flag=1;
txs[5]: fee=100, donation flag=0;
avr_donations(block1) = (0 + 0 + 100 + 0 + 100 + 0)/6 = 33
Finally, once a day(each 720th block) donation value to transfer to devs calculated as a median(avr_donations(block0), avr_donations(block1)....avr_donations(block719)) * 720
Does it make sense ?
Yes, it seems fair, however still could be cheated : Dev send 361 transactions in 361 blocks with donation fee=1,OOO he then gets 720,000 as donation, net benefice = 359,000. This will work straight if half+1 block don't have transaction (361 block containing only the dev transaction). This will also work if there is only one foreign transaction in B-1 block, one with 0 tx and all other with one or more transaction. Dev will only send a 2OOO fee tx for each B block ( with B<360 ). Let's say A="number of blocks with 0 foreign tx", B="numbers of blocks with 1 foreign tx" and A+B =361 then dev will win 720,000 - B*2000 -A*1000 . So I guess you should divide by 2 the donation to avoid that.How about block without transaction value ? I guess it will be 0. As Johnny Mnemonic said dev got incentive to pump fee up. By the way how fee are fixed ? |
|
|
|
HornyPennis ?  |
|
|
|
This might work but not in the beginning an not with 10 blocks.
I would suggest waiting 15 days after launch before making donation, and calculating the median on 1440 blocks (1 day) or more.
How would you account for the transaction without donation flag in your calculation ?
Why do you thing without? Can you give us the formula and an example calculation ? |
|
|
|
Creating donation in proportion to transaction fee is a good idea.
However it can still be cheated in it's actual proposed form :
Dev will mine a block and include inside it a transaction to themselves with a huge fee.
As they mined the block they get the fee back, and as they are the Dev, they get the same amount of fee created as donation.
Basically they can double their money each time they mine a block.
Think we have a solution of the problem that you pointed, please take a look in updated topic. What do you think? I suppose you are talking about (it's better to post the modification you are making) : We've tried to move focus from miners to common users of network, whith actually use it currency.
Each transaction is vote for donation of size equals to a fee of this transaction.
For each block, we calculate the average value of donations (based on transaction's fee and donations flag).
Every 10th block we take the median of the average values of prev 10 blocks, and use this as a size of donation to transfer the developers.
This might work but not in the beginning an not with 10 blocks. I would suggest waiting 15 days after launch before making donation, and calculating the median on 1440 blocks (1 day) or more. How would you account for the transaction without donation flag in your calculation ? |
|
|
|
An alternative, without money creation, could be that the people making a transaction can chose the % of the fee that should go to miner or Dev.
It the same as if they just have an option to send part of their own money to dev. Won't work. Not if the fee is mandatory for anti-spam purpose. But there is still a problem of centralisation if people can't chose any other developer than the creator of coin.
I feel what you mean, but can't even imagine practical process of project management with such approach. It is decentralized by nature since you can publish and promote your own sources for this net, and if most of people trust you than they will use your stuff. I've already explained a possible process with bounty distribution, if you are willing to implement it, I will elaborate more. ( https://bitcointalk.org/index.php?topic=577267.msg6440772#msg6440772) Basically in crypto I see 3 ways of voting : - Miner vote (each time a miner mint a block he have a vote) - Shareholder vote (you have one vote for each coin you own) - Transaction vote (you vote when you make a transaction (but you have to pay a fee to avoid spam)) By choosing one or making a combination of those vote, you can designate people to have certain function in the coin community. Those function could be of all sort, but you should always try to divide the power amongst lots of people, even to the point that a certain person can just do a tiny thing in a whole process. This will allow you to do things that a machine can't do (ie : check for the work to be done, evaluate market, decide something...) There is a 4th solution, but that involve web of trust, and it's very hard to make it work in a greedy world ! |
|
|
|
the key is to really subtract the dev fee from the transaction, not just create it out of thin air
Yes that is what I was proposing, but I didn't think that's what the OP was about ! |
|
|
|
|
Show Posts
