Latest posts of: CIYAM

Quote from: BkkCoins on September 22, 2012, 03:35:34 AM

But it would be fairly easy for me to create a C++ function you integrate at your end to add the keys. The code is readable in the vanitygen keyconv utility and was what I based my own JS client code on. At the C++ end it would require linking to the openssl library and only a few lines to add the keys. openssl provides the BigNum functions for addition. I'd have to look into.

Great - I am already using OpenSSL so that should be easy (am not using boost though so hopefully the code won't need it also).

Quote from: BkkCoins on September 22, 2012, 03:06:20 AM

I haven't added an end user api yet but the client JS does already access an Ajax JSON interface. It would require at your end a fairly small function to do the final key addition. I'd have to create a few samples in php, python etc.

Unlike most other web systems my back end is 100% C++ so I would be hoping for something simpler (such as just using "curl" to get back CSV).

Do you have a link to an explanation about how the third-party partial key implementation of vanitygen is working?

Provided I am satisfied with the safety of the system I think I would be interested to use this (although an API approach might be preferable to a standard website).

Quote from: John Smith on September 21, 2012, 11:49:33 AM

What options are you using? For example, are you using RPC at all?

These are the options I have set:

Code:

noirc=1
nolisten=1
server=1
rpcallowip=127.0.0.1
rpcpassword=***password***

Quote from: FreeMoney on September 21, 2012, 09:08:14 PM

Stupid to think "Only hoarding" is going to happen. If there was "only hoarding" how would a 51% attack even do anything? Try to set up an attack that doesn't require trade to have happened.

If no coins were being traded at all then IMO Bitcoin would have already died.

If very few tx's were taking place but blocks were still being mined for a very small coinbase amounts and very few people were bothering to mine then a >50% to prevent any tx from ever being processed could easily take place thus killing Bitcoin as you could never make a tx again.

BTW it was Gavin's blog that was musing about "only hoarding" (not my idea at all).

Quote from: wcoenen on September 21, 2012, 08:37:01 AM

Perhaps this is the post being referred to: http://gavinthink.blogspot.be/2012/07/is-store-of-value-enough.html

Thanks for that - an interesting read.

From my debug.log:

Code:

************************
EXCEPTION: N5boost16exception_detail10clone_implINS0_19error_info_injectorINS_6system12system_errorEEEEE       
close: Either the application has not called WSAStartup, or WSAStartup failed       
C:\Program Files\Bitcoin\bitcoin-qt.exe in ThreadRPCServer()

This is occurring every time I exit. Sad

The work on "pruning" the blockchain will pretty much achieve this affect (by only retaining "unspent" coins) although for the sake of completeness of the ledger I would think that miners and perhaps others will elect to keep the entire blockchain.

I am surprised that Gavin posted that (do you have a link to the blog entry?) - personally I think if bitcoins are only hoarded it will be the death of it (as achieving a >50% attack would become easy if mining has all but died).

Although it has been a little annoying as the blockchain bloats I think having more and more transactions is the most important thing to ensure the success of Bitcoin (at least while it remains a "proof of work" system).

You seem to have missed some rather major points here:

1) Are you going to pay the fees to return the "tainted" bitcoins?

2) How are you going to change the software to make sure the next tx doesn't try to send the same "tainted" coins again?

That's great - be sure not to copy any new files to it before using file recovery software.

You could try this software: http://www.nchsoftware.com/data-recovery/index.html?gclid=CM3ktL3Ww7ICFS5U4godHhkA4w

(I haven't used it myself though so can't personally recommend it)

This type of recovery is possible with deterministic wallets but AFAIA the Satoshi client doesn't support this.

Sorry to give you such bad news (and would be happily corrected if I've got anything wrong).

One thing that probably should be added to the Satoshi client is a message to tell you to backup your wallet as soon as you have encrypted it.

Quote from: Revalin on September 20, 2012, 06:36:11 AM

Ouch, I wasn't aware of that - why would it throw away the pool?

Ironically (for the OP) this is done just in case someone managed to get a copy of the unencrypted wallet.

Quote from: sethsethseth on September 20, 2012, 06:31:43 AM

edited OP to state that I made tx after I encrypted the wallet

In that case unfortunately you really have a problem as the unused addresses in the original backed up key pool were discarded when the wallet was encrypted (and re-encrypting the backup with the same password won't help as am pretty sure the addresses will be random).

Any change addresses that had been used prior to the encryption will still be present (otherwise the encrypted wallet would not be able to find those funds) it is only those addresses in the key pool that were unused (as far as the client could tell at that time) will have been discarded so as per Revalin's advice do a rescan and all should be good.

Quote from: Dabs on September 20, 2012, 05:23:34 AM

3. someone generated the same private key as yours, usually cracking a brainwallet or something similar, or a vanity address.
4. someone has the same private key because yours is so predictable.

No need for point 4 (as it is actually point 3) and there is no issue of cracking a private key due to using a vanity address (if you generate multiple vanity addresses with the same prefix they will always be different addresses).

Proof in point - check out my vanity address and you'll find there are quite a few bitcoins there - welcome to steal them if you can.

If your wallet is unencrypted then anyone or any software that has access to your computer could potentially copy your wallet and with this copy steal all your bitcoins.

If your wallet is encrypted (using the standard client) then your private keys are much safer as a copy of the wallet cannot be used to steal the coins without knowing the pass phrase.

Of course your pass phrase could be determined by a key logger (not sure how much of a problem this is on Mac but certainly a real threat under Windows) then you are back at square one.

It is also true that during the time the wallet keys are unencrypted (after you type in your password) they could be located in physical memory (but this threat is very unlikely).

Two factor authentication is one solution and the other is to use a computer that has never been connected to the internet to create private keys (there are a few threads on this around).

The real problem technically is to do with coin control and although the latest release has low level RPC commands to construct a tx manually for 99.99% of Bitcoin users this would simply be not practical (little own Gavin's grandma).

So in actuality the software cannot do what you are wanting to be done and although you are welcome to create a patch to achieve this I think you will have little to no interest from the core development team and most users.

I think the time and energy is better spent on securing ones coins (with multi-sig) than trying to chase "tainted" coins.

Unless everyone agrees to use a single list then you are most likely going to end up with a situation that you cannot send a tx to someone because your lists differ in their opinions about what is tainted. No one is going to want to use Bitcoin if every time they try and make a payment small portions get sent back and they are told to make another payment (which in all likelihood their client will actually just try and send the same rejected inputs again).

Taking this problem further forward then eventually (after all mining has finished) every single "coin" will end up with some input that was "stolen" as some time in the past (especially if it is decided that coins stolen from previous heists should also be included) so unless you are limiting the transaction history and only ever using the one list then this will simply make Bitcoin unusable.

Not quite sure exactly what you are asking about (free trials of what?) but the very nature of Bitcoin means that unlike credit cards (which are a pull system) the wallet owner has to make each an every payment themselves (which is a push system).

So until the standard (or some other) client comes with a "periodic payment" sub-system you could really only send a payment reminder to your customers.

You might be interested to take a look at Open Transactions though as I think it could be suitable for creating contracts with recurring payments.