Topic: [CLOSED] $20,000 Mini-Blockchain Implementation - page 4. (Read 10068 times)

This is exactly the case.  I'm implementing an altcoin myself, and the major requirements of this bounty (length limited blockchain, recovery of lost coins, reasonably trustable zero-confirm transactions)  closely resemble some of the novel features I had already intended to do anyway.   So I was already planning to write some very similar code.  If someone else is willing to pay a bounty for this particular set of requirements, and afterwards I still have rights to open-source, modify, and use the code produced, then doing this gets me about 80% of the way to the versions of these features I want to implement for my own system. 

It's earlier in my dev plan than I had intended to do it, but the set of requirements here apply to a transaction model much simpler than mine (I'm going to be using pay-to-script-hash and several different families of addresses with different properties) so it can exist independently of the complications I'll need to integrate it with.  Implementing this version will be easier and cleaner than what's going to eventually wind up in my code, but it'll still be a very good starting point for me.

FWIW, I think having the miner detect double spends is far too late for zero-confirm transactions.   It ought to be possible to repudiate a doubly-spent transaction within ten seconds, or the capability becomes one that won't be practical to use (in situations like checkout lines with people waiting behind you, or vending machines where you're just grabbing something on your way somewhere and don't have extra minutes, etc).  It doesn't matter if the double spend is "punished" or not; the merchant is still left holding the bag and that's _not_ okay!  I say ten seconds because that's roughly the amount of time it takes for a transaction to propagate across the Bitcoin network to 90% or more of the nodes and it'll only take a couple of seconds for an online merchant to check with ten or so clients at least a few of which are likely to have heard of the other transaction.

I would highly recommend that you try to team up with Cryddit. There will be less wasted effort and things will get done quicker if you guys team up instead of working independently. 'Probably' does have a point about that.

I'm going to try to as well. But will use it for my altcoin.

Developers are typically not hard to find, but when you require developers skilled enough to work on cutting edge crypto-currency technology which has never been built before, it is very hard to find developers. In the many months I've been advertising this bounty, Cryddit is actually the only person who has told me directly that he is going to try to implement this concept in order to claim the bounty.

EDIT: and if developers don't want to waste their time attempting to claim this bounty, then they should try to team up with other developers in this thread who have already said they are working in it.

In that case your coins would get re-mined under the assumption they were lost. You would have to transfer a portion or all of your coins to another address to prove that you still have control of the coins.

Probably, I think there is a difference between hiring developers (where whatever they produce belongs to you) and this open source bounty system. Nothing prevents someone from following the requirements here, creating own altcoin, and after the release claim the bounty. Thus it is lower than market development rates. Plz correct me if I'm wrong, bitfreak.

I didn't write that part of the wiki, but I think you're correct, we should only need to reference an account by the address.

Yes exactly, you are right about this as well. If it was done the other way then anyone could send coins to an address to ensure that the coins are never considered to be lost, which would defeat the purpose of the re-mining system.

The best way of doing this is dropping this "bounty" system and just hiring developers?

Is it really that mysterious?


Never mind that it seems grossly inefficient and a waste of resources to have "competition jobs" where people are developing in parallel, racing for the bounty prize.


Also, you might want to discuss this with developers to find out the timeframe and compensation for developing what you're talking about.


I get it that you have a budget, we all do, but realize that your budget dictates the quality, speed and interest you'll find in developing these products. In my estimate what you're looking for versus how much you're willing to pay for it is wildly off base. For reference, I've been a part of small HTML websites that were more expensive than what you're offering.

Someone stated "Devs are hard to find" in the thread. This is absurd. Devs that are willing to work under customer dictated terms that attempt to bypass the marketplace norms, maybe. I don't know too many development houses that would think these terms are fair.

Feel free to seek it out, of course, but all of this nonsense regarding how to find devs and how to make them feel like they'll get the bounty are easily solvable via contracts and directly hiring firms that develop software. The institution I work for never has a shortage of vendors who are willing to accept our money in return for software.

Then casascuis won't make coins for blockchains that mine lost coins.

Not a problem for Bitcoin.  This is for altcoins.

@Bitfreak!

Another requirements question.  When you say you'd like "recovery of lost coins" do you mean "recovery of coins sent to addresses/keys whose corresponding private keys have not been used in X time"?  Or do you mean "recovery of coins in addresses/keys that have not been used in *ANY* transaction (ie, neither the private key nor the public key has been used) in X time"?

I ask because it's possible that Alice lost the private key to one of her addresses many years ago, but Bob just sent coins to that address using the public key just last week.  Are the  coins Bob sent to be considered "lost" because the only key that could possibly spend them hasn't been used for many years, or are those coins (and all other coins in Alice's old account) to be considered "live" because the public key to that account was used only last week?

If we go with the first option, then once Alice's old account has been "recovered", as long as she doesn't reactivate it by using the private key that we assumed was lost, any coins sent to that address may be recovered immediately, even in the very same block as the tx that sends them.  

The first option seems more sensible to me, because the only idea that causes "recovery" to make any sense is the presumption that the private key to the address has been lost. Coins recently sent to that address do not indicate that it has been found.  

But the second option is more sensible in terms of orderly data structures.  If it's the private key only then we need to keep track of the last time each account was decremented, but we may never completely delete an account from our account lookup because if the account is "dead" it remains "dead" until the private key is used, and any amounts sent to it may be recovered immediately.  If it's both private *and* public key, then we must remember the last time the balance changed in either direction, but we can delete accounts completely when they reach zero, because the effect is the same if a new spend "creates a new account" as if a new spend is directed to an account that has been "recovered".

"Re-Mining of Lost Coins" Why stop there? While we're at it why don't we just increase the number of coins from 21 million to 42 million?

@Bitfreak!

I'm going to take a run at this, but I want to be sure I've got the requirements right first.

When you say on the wiki page describing the Account Tree that it should be easy to reference an account by "offset and address" I'm guessing that by "address" you mean the key needed to spend to that account, but what do you mean by "offset?"

It wouldn't be hard at all to make it easy to reference an account by address alone.  That would make it equally simple to just ignore some extra data called an "offset" as being something I don't really need to find the account -- unless you mean that you also want to be able to look it up by offset alone, without needing the address for this other kind of search?

False, you can have m of n transactions so 2 out of 3 have to agree or whatever ration you set. https://github.com/spesmilo/sx is your friend there (look for Multisig)

reserved

Sounds like a plan, we can discuss the details further when I return, for now I need to get some shut eye. I'll be back to check on this thread later.

Okay - I get that - so if I hold any funds I will GPG sign an agreement about the release of them to make sure that all is above board.

Trust is a hard thing to come by on this forum - and I very much value the trust that I have established so far.

I was thinking about that too, but multisig transactions require all parties to agree before the funds can be released, and I really don't want any more than 2 parties involved, so I'm not really sure there's a point. If we both hold a portion of the funds then the winner of the bounty can at least be fairly certain they will receive a partial reward from one of us.

Perhaps a multi-sig solution might be even better (so the trust is spread).

BTW I don't think that many members would have a trust problem with you as I know you have been around longer than I have been.

Ok after some thinking I am willing put some of the project funds under the control CIYAM Open (I'm thinking 10 BTC), but I will maintain control of the rest of the funds. I know I don't have any trust feedback but I have been a part of this forum since early 2011 and have been offering bitcoin related tools and information on my website for many years, so I think I have earned some trust in any case.