The private keys are encrypted (by AES) in your wallet so they are about as safe as they can be.

Understand that the rest of the wallet is *not* encrypted so if you are worried about people seeing your balances or your transaction history then you might want to consider encrypting the entire file.

Well - best of luck with that.

No-one posted code that included the OP code so your "blindly following" comment makes little sense.

If you are keen to contribute then how about just focus on the solution?

And as I already pointed out your comment about the "code quality" was completely unnecessary as the OP had already admitted his code was bad and needed re-doing.

Exactly why he asked for it to be "re-written" (not "built upon" as all the other replies already said).

It is probably just an age thing but if you want to get a reward I would recommend more code and less negative comments (you should note that you are not being criticized about your code).

Did you not read his OP and the immediate follow up to my post?

He stated his code was badly written - so your rubbish about "code quality" is completely OT as he had already admitted the code needed re-writing.

You were "insulted" probably because either you didn't pay any attention to the OP and the following 2 posts or your ego (will let you choose which).

Hmm... I think if you posted the code first rather than the insults you might have had a better chance.

Surely people who bought the coins would have transferred the BTC value to a different address by now wouldn't they?

(so the idea that he could *now* go and steal huge amounts of BTC seems a bit unrealistic to me)

Your link isn't much help as it's thousands of lines of code (why don't you just paste your relevant function rather than the whole of the bitaddress.org webpage that presumably includes your code "somewhere" inside) - but basically you will want to use a timer function for your looping.

Here is a simple timer example:

There are a couple of main problems with bounty systems which is why CIYAM Open was designed the way it was.

Firstly it's kind of pointless to have a "race to code" as you are going to end up with the worst quality software possible as each coder only cares about delivering first not how good the software is. Secondly, how do you confirm delivery and acceptance?

For the first part I use the approach of "dibs" which is where several devs provide a promised delivery date but only *one* is selected to work on the task (if unable to complete it on time then the task is re-opened for further "dibs").

For the second part "git" is your friend - a "git pull request" is proof that you have submitted code and if that request is "merged" then you have proof that the code was accepted. Even if rejected because the "pull request" remains in the repository its changes can be compared against later changes made to the project to show evidence of "stealing rejected code".

I would have to agree that Luke-Jr seems to be a bit confused about what a "bug" is.

Perhaps he is just getting a bit overzealous about his dislike of this "feature". 

Move the wallet.dat file to somewhere safe (maybe rename it to wallet.dat.old so you don't confuse it with your new wallet) then start bitcoin-qt - it should automatically create a new empty wallet for you.

You would be advised to keep some copies of the old wallet also (and the new wallet after you have given it a passphrase).

For a start I don't use Electrum and quite likely most of your potential "buyers" don't either and for a second you need to really read up on what UTXO's are to fully understand that there is no "from address".

The only way you could make a tx "appear" to have a "from" address would be to use only one UTXO or multiple UTXOs that were all outputs to the *same* address (something no user should ever do in the first place if they care about their own privacy).

Your idea is now looking like a "nightmare" for your potential customers - not only do they have to use a certain client but also apparently they have to get rid of any chance of anonymity in order to use your service.

I think it's pretty clear that you aren't going to find any customers with this approach - maybe time to rethink what you are hoping to achieve.

I am struggling to work out how you are going to know who has paid for your product/service (unless it is just a gambling website similar to SD in which case just say so).

The point here being that if you can't work out who has paid for what then how could you possibly deliver it to them?

How is that going to help when the customer themselves have no idea what addresses their own UTXO's came from?

(i.e. your customer would then have exactly the same problem as you are stating as they can't control their "from" address either)


You just advertise without a payment address (do most people advertise a bank account # currently?). Payment is normally at least a "click here to purchase" link.


Don't look at SD for an example of "best practice" (and especially the blockchain spamming "signal" payments). Also understand SD doesn't *have* a product or a service that is is selling - it's just a gambling website (or is that what you are setting up also?).


I am not sure what is the problem with creating a new pay-to address for each tx - surely you can store them in a DB to know what each is for?

Perhaps just think about this from your own side - how do you know who has paid if all payments are made to the same address?

Indeed - I didn't read the OP carefully enough - you really should be generating a separate address for every payment being made.

The version of "coin control" you'd want to be using is by "cozz" and you can find a link to binaries and source in the OP here: https://bitcointalk.org/index.php?topic=144331.0 (it is not part of the official bitcoin-qt client *yet*).

Accounts are not addresses - so you simply cannot think of address X *belonging* to account A (the accounts in bitcoin are confusing to many).

If you want to control the UTXO's being used (the "froms" and note they will often be many) then you are either going to have to use the "Coin Control" version (and not the "coderr" one as it's obsolete) or start coding "raw transactions".

The XRP has collapsed in value from a high of around 8,000 per BTC to now around 80,000 per BTC so that aspect has clearly failed (and deservedly so).

Unfortunately it also seems that WeExchange is in big troubles (take a look at the various topics about Ukyo to follow this).

Its worse problem is that it isn't decentralised (very much limited to a small number of servers) although its best feature is very fast txs (assuming that there is no flaw in the "consensus" model it is using).

I think that the "tricky" nature of its launch has led to its unpopularity, however, I do think that the consensus mechanism is an important technical achievement and could be exactly what is needed to help something like Bitcoin that is struggling to cope with large numbers of transactions (and to have transactions "confirm" much quicker).