|
A big problem with tracking 'taint' is that it quickly gets everywhere. MtGox mixes most of the coins they receive into a few large value addresses, so once they've accepted tainted coins you're getting tainted coins pretty much every time you withdraw from them.
|
|
|
|
is it possible to receive payments to mtgox or armory watching wallet
and then automatically assign numbers to users accounts ?
while actual coins sit safe and are sent manually on request
If the coins are sent to MtGox, they're only as safe as MtGox's security allows them to be. They've been hacked before. If the coins are sent to an offline armory wallet then they're pretty much safe. So to answer your question, "yes". |
|
|
|
taking advantage of every last day of interest, as BTC, itself, generates NONE.
I heard that there are ways of generating lots of interest on BTC investments. |
|
|
|
Anyone heard from Patrick Strateman since this happened? Anyone know him personally? It would be interesting to hear his take on how it went down.
Funny you should ask. I added him on Skype maybe a month ago to tell him about a bug in the Intersango code. The interaction was brief and to the point, and that was that. Then a couple of days ago he messaged me out of the blue on Skype to ask me what I was wearing. Very odd. |
|
|
|
I just realized though... in order to make it work, one would have to "pre-send" a whole bunch of 0.01 BTC amounts to different addresses. That way, the coinage not sent remains old. If I were to just send 0.01 out of 1 BTC, then suddenly, the other 0.99 BTC is brand new again, and cannot be sent fee-less for a while afterward.
That's right. You would have to wait another 1.01 or so days before you could use the change 0.99 BTC without incurring a fee. But remember, if you pre-send 0.01 to yourself 100 times (you can use the same address for each - they'll remain as separate inputs as far as the network is concerned) you'll have to wait 100 days before spending any of them. You might decide it's better to pre-send 0.10 to yourself 10 times, and then only have to wait 10 days to be able to spend them. Or maybe send a range of different sizes to yourself, which will then 'mature' at different times. Unfortunately the satoshi client doesn't make an effort to try to pick inputs that will avoid transaction fees (other than to prefer inputs with 6 or more confirmations over those with less), so you'll likely end up incurring fees unless you patch the client to allow you to manually select which inputs to spend. There's a pending pull request ('coin control') which allows you to select which addresses to send from, but it doesn't allow control over individual inputs if you have multiple inputs at a single address. |
|
|
|
How many customers need to be paid out Chris? If it's substantially more than the number who've contacted you through this thread, then maybe there needs to be a thread on reddit or some other places so customers who don't frequent here have some idea of what's going on.
85 accounts have more than 0.1 BTC or 0.5 AUD 65 accounts have more than 1 BTC or 5 AUD. 50 accounts have more than 10 BTC or 50 AUD. 13 accounts have more than 100 BTC or 500 AUD. I've not counted the participants in this thread, but would guess it's around 15 or 20 at most. It's a shame that Andre has somehow lost control of his website. That would be the perfect place to announce what's going on. |
|
|
|
UNfortunately true. If Andre is not stepping up I only see the possibility to set a deadline until where people have to hand in claims. If no claims were handed in we would have to assume tehre is nothing else.
The problem with this is that it's quite possible there are customers who don't know about this thread. I have no way of communicating with them. I don't have contact details for most WBX customers. I thought about this one, as well. There is no easy way for me to proove this. I see two possibilities: 1) I can forward you the complete mail correspondence with Andre incl. headers
2) I can prove on my account that the money never arrived. I'm not sure whether the Database stored to which account a payment should have been gone. if it's the case, it is easy to prove. If not, I can only show, that all payments went always to the same account, except for those mentioned above.
I do have all the withdrawal request details, so that could work. |
|
|
|
Is it possible to send someone a bitcent without a fee? How old would the coins have to be in order to do so?
To avoid fees, the coins you spend should be at least 1 "bitcoin day" old. A 3 BTC input that is 4 days old is 12 "bitcoin days" old. Like "man hours" - 3 men working for 4 hours each is 12 man hours. So to send 1/100th of a bitcoin for free, it needs to be 100 days old. To send 24 bitcoins for free, they need to be 1 hour old. Etc. If any of your outputs are less than 0.01 BTC (including any change output), then you will always need to include a fee. This is to avoid the recommended fee, of course. If you edit the source you can send any amount you like without a fee, but miners may then decide not to include your transaction in a block. Edit: if you have a 1 BTC coin that is 1 day old, you will be able to send 0.01 BTC (with 0.99 BTC change) without paying a fee. It's the size and age of the inputs that matters, not the outputs. Though the outputs have to be a bit cent or more to avoid fees. Edit2: and it's not really the age that matters, but the number of confirmations. If we get 1 block every 10 minutes then the above is true. |
|
|
|
I got rid of this "few moments" delay by commenting out two lines in the source code that perform this lengthy rescan - I did this so I could batch-import lots of keys and not have any per-key delay. The flip side is I must -rescan when I'm done.
Me too: diff --git a/src/rpcdump.cpp b/src/rpcdump.cpp
index 5bb4789..1fa6694 100644
--- a/src/rpcdump.cpp
+++ b/src/rpcdump.cpp
@@ -69,8 +69,8 @@ Value importprivkey(const Array& params, bool fHelp)
if (!pwalletMain->AddKey(key))
throw JSONRPCError(-4,"Error adding key to wallet");
- pwalletMain->ScanForWalletTransactions(pindexGenesisBlock, true);
- pwalletMain->ReacceptWalletTransactions();
+ // pwalletMain->ScanForWalletTransactions(pindexGenesisBlock, true);
+ // pwalletMain->ReacceptWalletTransactions();
}
MainFrameRepaint();
I don't need to -rescan at all if I'm importing addresses I just made in vanitygen, since I know there aren't yet any transactions mentioning the imported keys. |
|
|
|
1) You generate a random 256-bit integer less than the SECP256k1 generator. You keep this secret. (Effectively, an ECDSA private key.)
Why would it need to be less than the generator? 3) The person working out the vanity address for you tries various 256-bit integers also less than the SECP256k1 generator.
Again, why the constraint? It shouldn't be necessary. 4) You add the 256-bit integer they found to the 256-bit integer you generated in step 1 and reduce it modulo the SECP256k1 generator.
You mean modulo the order of the underlying field I think. Other than that, neat scheme! |
|
|
|
That was mine, yes. Actually it is additional ~1900 AUD that Andre still owes me. Please find below the original mail from him. I can also forward the e-mail to dooglus (for the header or whatsoever) please give me a shout and I will do so, potentially also witht he complete discussion with Andre.
Couple of comments: 1) If he owes you an extra 1900 AUD alone, who knows how much extra he owes to all his other customers. I was naively thinking that if the database showed a payment had been made, then the payment had been made. Sounds like that's not the case. 2) Unless Andre steps up with a full list of liabilities, what's to stop anyone from claiming they are owed a similar amount? I'm not at all saying your claims aren't honest, but the next guy's might not be. Andre really needs to make the total level of liabilities be known, else there's no way to fairly distribute the remaining BTC. |
|
|
|
The 'wallet details' tab says: Public Key (compressed, 65 characters [0-9A-F]):
021057EDD23AE4D3E51C150AF43C9477530FA268EC80FC03046F0AD7957597E9E6 but that's 66 characters, not 65. maybe they ignore the leading zero on the left. I think it's just a typo in the bitaddress code. Compare with the uncompressed version which also has a leading zero, but has the correct length: Public Key (130 characters [0-9A-F]):
048FDCB5A9E446EC3363CD04ABB7FEA271265A2942D5347F0D9488C0926AF87FD
ECF2345C49CA5A6C5677936C4BFAA3062DC1BFF7A5F93A94FEAF271DEECCC3CAF
Public Key (compressed, 65 characters [0-9A-F]):
038FDCB5A9E446EC3363CD04ABB7FEA271265A2942D5347F0D9488C0926AF87FDE The uncompressed key is 1+32+32 bytes, the compressed key is 1+32 bytes. Both need doubling to get the length in hex digits. |
|
|
|
The 'wallet details' tab says: Public Key (compressed, 65 characters [0-9A-F]):
021057EDD23AE4D3E51C150AF43C9477530FA268EC80FC03046F0AD7957597E9E6 but that's 66 characters, not 65. |
|
|
|
And there is a ICP on the BTCchina.com.
他妈的磁铁，他们如何工作？ |
|
|
|
However, put options, with emphasis on USD sale price, may become under covered as exchange rates change. This is unavoidable because our escrow service only accepts bitcoins, and default risk can be factored into pricing put options.
Can't you just insist that the creator of the put option has sufficient USD in their account to cover the contact, and hold it in reserve for the duration of the contract. In effect, acting as your own escrow service, at least until you find an escrow service that meets your requirements. |
|
|
|
This paragraph of the FAQ:  says "in this forum thread". Is that meant to be a link? |
|
|
|
I find it hard to distinguish between regular text and links on the FAQ page:  "this short description" is a link, but looks very much like the "You can read" text. Is the colour slightly different? |
|
|
|
We take security seriously. [...] - We use secure password management. Passwords are never emailed, and are handled with the highest level of security. Users don't choose their own passwords, which can be weak or unlock their other accounts. Instead strong passwords are assigned, then salted and hashed.
The password you gave me when I signed up was only 9 characters long. I tried to change it to something much longer, but it won't let me. Instead it just makes up new short passwords. The most recent one it gave me was only 8 characters long. I heard a rumour that some people in the Bitcoin community have serious hardware capable of brute forcing hashes remarkably quickly, and so would like to be able to generate my own secure password. |
|
|
|
From memory, when you sign in with OpenID (even if you do it through Google or another service) it asks you whether you want to share your email and your username for that service with the site you're signing into. It's possible that at least some users elected to do this and so they might be contactable in a roundabout way if that information can be retrieved.
I looked into that at the time. It turned out that I had the option in the code of either: * only accepting users who check the "let them see my email address" box, or * never getting email information from any user I couldn't find a way of allowing users to decide whether to send their email or not, and still having them be able to register even if they decided not to share their email address. So it ended up just not asking for the email address. I think you'll find that if a site that uses OpenID ever has the "share email?" option and you don't check it, then your sign-up attempt will fail. There's no field in the WBX database for email addresses either. |
|
|
|
|
Show Posts
