Can't you make 2 coinbase transaction, one for mining the other for donation ?

  struct block_header
  {
    uint8_t major_version;
    uint8_t minor_version;
    uint64_t timestamp;
    crypto::hash  prev_id;
    crypto::hash  mm;
    uint32_t nonce;

    BEGIN_SERIALIZE()
      VARINT_FIELD(major_version)
      if(major_version > CURRENT_BLOCK_MAJOR_VERSION) return false;
      VARINT_FIELD(minor_version)
      VARINT_FIELD(timestamp)
      FIELD(prev_id)
      FIELD(mm)
      FIELD(nonce)
    END_SERIALIZE()
  };

  struct block: public block_header
  {
    transaction miner_tx; // <------------------------------- coinbase
    std::vector<crypto::hash> tx_hashes;

    BEGIN_SERIALIZE_OBJECT()
      FIELDS(*static_cast<block_header *>(this))
      FIELD(miner_tx)
      FIELD(tx_hashes)
    END_SERIALIZE()
  };

If you really want the donation to be fair and effective as a business model, you need to allow the miners to choose not only how much they donate, but also to whom they donate. If the original develoeper(s) do a bad job, the miners need to be able to fire them (by vote) and have all the donations go to someone else. (The Invictus coins implement something like this.)

Otherwise this is just a scheme for you to collect donations from lazy or ignorant miners (who do not know how to or do not bother to disable donations) forever regardless of whether you actually continue do useful work.

For that matter this is part of the essence of crowdfunding. I should be able to donate, but only if you convince a sufficient number of the other miners to donate as well. If too few are convinced, then you shouldn't get anything, including my donation or those from lazy or ignorant miners who donate by default. In practice a vote-to-fire system is largely the same and easier to implement.

Failing all that, provide an easy mechanism for miners to donate but leave it off by default. If you add value miners will turn it on.
I will support this coin if you get rid of the donations-by-default scam.

EDIT: And also address the GPU minability issue below.

Changing the name would help too. You mentioned in one of your earlier posts that you are not a native English speaker and that your language is quite different. You should realize that in English HoneyPenny is an atrocious name for a cryptocurrency. I mean this in the most constructive way possible. Rename is a priority if you want this to succeed.

1% seems to be the bare reasonable maximum.
The problem is also that it's tied to you "at vitam eternam".

May be you should make a system that will allows others to be candidates for the donation.
Of course it could not be any address, otherwise miner would donate to themselves.
You could implement a voting system like memorycoin (shareolder voting  : memorycoin.org) but witch will only allow an address to be eligible for the donation, for example with 33% (this number could be higher in the beginning to avoid early cheat), then the miner decide who he chose.
... ok, I'm realising that because of the technologies involved (anonymous balance) it could be a little bit harder to implement the voting system.

A must have for this kind of donation, is that the coin are un-spendable for at least several months.
This will avoid the early dump, and restore confidence. You are here for the long run anyway.

Can we have a time for the release date please?

apply a random number of rounds 1 through 10 that go to developers.

in reality, you do not need crowd funding. this will relegate you to secondary currency. you knowledge and early participation will assure your profits. while a fair launch without taxes will attract miners which will improve you success.

Thank you for reporting problem, will fix it asap.

refresh command does not work in simplewallet: "Error: refresh failed: no connection to daemon. Please, make sure daemon is running. Blocks received: 0"


(yes, I deleted blockchain.bin)

also, link fails for several programs because -lpthread is not used
I added -lpthread into src/CMakeLists.txt (lines with target_link_libraries) but there is probably a better way

A better name maybe ?

I see a problem here :
Even if all the miners decided to give 0% donation, you will still be able to mine with a 10% more block reward than any other miners.
And I guess if you make a pool miner you will set this to 10% and possibly you could attract all the miners in your pool by giving them 1% or more bonus from your donation.

This cry-out centralisation to me !!!

Got it.
I have it up and running and "start_mining 4" shows that 4 threads started. Only issue I have is that "show_hr" doesn't display anything.

Maybe this is a stupid question but ...will coins mined on the test network be valid, or will the slate be wiped clean at launch?

what is hpd

I think it's an interesting way to implement a way to keep you involved, and you should absolutely not be ashamed. I just hope that you will be willing and ready, when it comes time, to suggest a recommended percentage. It's no small responsibility, asking for taxes. It requires you to be honest with yourself and everyone . . or at least convince them you are.

What I'm saying is that by making the % changeable based on the miner's choice (this is the approach I'm assuming you're taking -- correct me if i'm wrong), you will need to provide them with definitions of what every percentage that isn't 0 or 10% according to what it means to you. I could only see this working if you're capable of asking for 3.56% tax, or 7.692% tax based on definitions we all come to agree on. No taxation without representation is what's coming to mind -- are you capable of defending your right to demand that which we have every right to refuse?

I've seen a similar approach in MemoryCoin 2. Are you familiar with that? The fact that freetrade manipulated votes and pretty much dropped the coin, in addition to it losing a lot of momentum, when he got voted out is what I'm worried about. What types of parallels/differences do you expect with your coin? I'm just curious is all.

It's tough to track down differences in the original code with the way you brought into your github. As far as I can tell immediately all that was removed was one character, a "-". I see there's more, but it will take time to find the changes.

Sorry, I must have read that wrong the first time. I did not understand before, but it seems to make more sense now. It's still a little unclear, but I can understand better the source when you're ready.

Thanks for the responses, it's nice to see a pre-ann discussion full of more than "looks nice" or "can't wait for this one".

Correct me if i'm wrong but on summary these are the biggest changes
1. The use of another hashing algorythm based on the blockchain, it should fix the slow bc syncing we experience in BCN & BMR.

2. 10% of total coins going through emission to the developers so they can do their job when drinking cocktails on the Bahama's. (in other words, 10% of each block goes into the devs pockets)

3. Mixing level of coins will always be greater then 0

4. Smaller blockchain because of dust removal

5. p2p broadcasting like used in Litecoin for sending messages through the blockchain
6. Mapping of addresses to short names for easy access

For the dev. Are you changing the way the blockchain is stored? Like write it directly to a db and not a full mem load?

Ummm…. don't mind me. I'm just wondering if this is mineable with an ATI graphics card. You guys can go back to drawing balloons and troops strategy after that