I also have a list of addresses of which I would like to spend the balance... Maintaining your own secrets is your business. blockchain.info cannot recover forgotten wallets or lost credentials, that is why you must back up your wallet data. This also solves the problem of people trying to social engineer their way into other's accounts. https://blockchain.info/wallet/backupsSecurity Our security policy is to hold as little data as possible that in the event of a security breach could affect our users. Using our My Wallet service we do not hold or intercept any passwords or personally identifying information; wallet data is only stored in encrypted form. |
|
|
|
You are missing the part with the double-spending. What you describe will remove a transaction from Bitcoin. This removes the "already spent" status of particular unspent txouts (individual bitcoin payments you've received from someone else and change inputs from previous transactions, called "inputs" when you look at block explorer sites) and returns them to your balance sheet. However, this alone neither prevents the transaction from later being included in the blockchain or guarantees that the previous transaction will be invalidated with a new spend from your wallet. Picture this scenario: -My wallet has a 1BTC and a 2BTC payment I've received and no other transactions. -I send seller 1BTC with no fee (this transaction uses the wallet's unspent 1btc txout) -which doesn't confirm in a timely manner. Then: -I follow this procedure to remove the transaction from my Bitcoin client and return the balance to Bitcoins I can spend. Now: -I resend 1BTC to the merchant with a 0.01 voluntary fee -The wallet picks the most sensible txouts to construct the transaction of 1.01BTC, which is to use the 2BTC payment instead. 1.01BTC is sent to the sender and the wallet gets 0.99BTC change back. Result: -Merchant quickly gets new 1BTC payment -Original transaction is not invalidated by any of it's txouts being double-spent -But... surprise, some miner includes the original transaction in a block, now you have paid twice. You must document the actual txouts spent by a payment before removing it, and use a coin-control type wallet to re-spend some of the same txouts with appropriate fee; only when some of the same txouts are confirmed in the blockchain could the original payment be considered invalid. There was a previous discussion about adding a re-send type feature to double-spend with more fee, with code for miners to recognize the new transaction as legitimate as it did not alter the original payment: I thought I have seen Gavin somewhere talking about adding fees to already existing transactions... am I mistaken ?
I'm working on a patch that will create the basic infrastructure to add fees to transactions that have been sent but not yet included in a block. It will only let you add additional inputs and outputs, but never make any output have a lower value than it did before. Nor will it let you modify a transaction that has already been spent. I've been considering what criteria nodes should have to allow discarding a pending in-memory transaction and replace it with an increased-fee transaction. Your conclusion is logical. Since the output of a transaction that is change can't be identified by miners or nodes, to validate what constitutes a legitimate non-double-spend transaction, it appears that a retransmitted transaction must not alter any inputs or outputs in the original transaction. If one of the outputs were allowed to be reduced to increase the fee, this could mean a 0 confirmation payment to someone could be changed from the expected value, which is the definition of a malevolent double-spend. If any output could be modified in the original, this means that 0 confirm payments could not be trustable, because output values could be moved from one recipient to another or reduced. Instead, fee must solely be added by adding a new input, and a separate change payment must be sent. In the example below, I show where we add another complete input and change (where fee = input - change).  OutputX, another payment to another recipient (or a third change payment to enhance anonymity even more), could be optional and shouldn't be a "blocker" if it exists. Change from adding a fee demands some new outputs. However, being able to add such "mini-transaction" chunks with new inputs and outputs and retransmit them, could mean that a service that issues many regular payments could just keep adding to an existing 0 confirmation transaction and retransmitting, instead of creating a new transaction. I don't know if this would be a novel feature or undesirable. Another strange situation is if the original tx has spent all the available inputs, the user can't increase the fee. Explaining why the wallet can't add more fee even though it shows a balance will be one for the UI designers. |
|
|
|
|
Dear John, you are hereby granted the moral authority to ban the "+1" sock posters.
|
|
|
|
It was announced today that CoinTerra now accept Credit card and Paypal Payment via mailing list.
Can we now trust CoinTerra?
I don't see how that's going to work out well for them... You have to take payment somehow if you have a business, but:
Prohibited Activities
You may not use the PayPal service for activities that:
...
relate to transactions that (a) show the personal information of third parties in violation of applicable law, (b) support pyramid or ponzi schemes, matrix programs, other "get rich quick" schemes or certain multi-level marketing programs, (c) are associated with purchases of annuities or lottery contracts, lay-away systems, off-shore banking or transactions to finance or refinance debts funded by a credit card, (d) are for the sale of certain items before the seller has control or possession of the item, (e) are by payment processors to collect payments on behalf of merchants, (f), are associated with the sale of traveler's checks or money orders, (h) involve currency exchanges or check cashing businesses, or (i) involve certain credit repair, debt settlement services, credit transactions or insurance activities.
|
|
|
|
|
It seems like if you put a valuable Internet Bitcoin property up, it will get DDoSed. First pools, then exchanges, the forum and wiki/.org, now gambling sites. The previous attacks would rotate where they point their bandwidth every few hours or days, likely to frustrate many sites with partial downtimes instead of just taking out a single site.
The first step would be to identify several of the IP addresses, contact the ISP's abuse departments to see if they will facilitate owner identification for anti-malware research, and implement full promiscuous monitoring with the owner's permission to determine command and control or obtain an image or copy of the malware. You probably wouldn't want to identify your attack mitigation efforts as representative of the interests of Internet gambling sites unless legal in your jurisdiction and the bot attacker's.
Then what do you do when c&c is from its-only-cyber-crime-if-you-are-a-civilian.army.mil...
|
|
|
|
After a brief exchange, it appears that setting the DNS to 4.2.2.4 instead of 8.8.8.8 (in step 8 of my 9 step plan) fixed the problem here. Another mystery... but maybe that will help you if you still can't connect.
Name: google-public-dns-a.google.com
Address: 8.8.8.8
Name: a.resolvers.level3.net
Address: 4.2.2.1If you don't want a record of every time you type just-dice.com into the URL bar stored on Google's servers and easily correlated to your identity, in addition to making your youtube and netflix not use a geographically close server, maybe just add just-dice.com 108.162.207.227to your hosts file (likely C:\Windows\System32\drivers\etc\hosts) |
|
|
|
I just checked email, got one yesterday saying my ozcoin wallet address had changed (?!?!?). Just went into ozcoin website and it shows withdrawal made of all my remaining coins to this other (Unknown) address. I haven't logged into the ozcoin website in months. Not sure who/how my address could have been changed and then all coins withdrawn in a 24hr timespan.
I use a > 15 digit alphanumeric pwd that is not repeated at any other site, and I don't have any other indications I might have been compromised. Am I missing something obvious? I haven't been on the forums or paying alot of attention lately, so this is possible, but I'm still somewhat troubled. Given the current exchange rate of Bitcoin this represents a nontrivial amount of currency.
Thanks I've posted here and personal message, with reasonable tone and volume. Are there other support options? Not to raise a stink but someone stole my coins from your website, I'd appreciate at least a token response. I'd rather not have to change either tone or volume.  Thanks in advance. It is good for you to report here, but it is probable that nothing is wrong with the site - your credentials for the pool website were likely obtained by a cracker, by your computer, email accounts, or network connection being Pwned. With Bitcoin, you are responsible for your own security; there is no bank to call that can give you your money back when you got scammed. There is also no way to prove it wasn't you that withdrew the money. You can report the theft to Police who will be glad to chuckle; with someone willing enough to file a police report because a theft actually happened, a site admin may be able to turn over what forensic evidence there is, likely just a Tor exit node IP address or an IP address of one of over 9000 rooted machines under a hacker's control (if there even is any logging - many users might prefer no logging of their pool connections if given the choice...) |
|
|
|
|
I have re-downloaded and sanitized my blockchain of that cruft several times. What you are asking, to clarify, is someone that still has a Bitcoin client around, with the original blockchain as-downloaded, that was also running continuously (not running continuously = inaccurate record of blocks seen on network). Also remember that duplicate block numbers seen after the first are ignored, not stored, only people that originally believed an orphan would have a chance of still having it.
|
|
|
|
Many of you seem to be lost in translation.
SHA-256 HAS BACKDOORS.
LIKE WINDOWS OS HAS BACKDOORS. That means NSA works with Windows to plant backdoors to access any system. NSA purposely weakens software and plants backdoors in it, SHA-256 is no exception.
It's worse than you think. All they need is 8 BITS of a SHA-256 message digest and they can backdoor their way to reconstructing your arbitrary length message. Incidentally this is the same tech they use to store a full year of global telecoms traffic on a thumb drive. Now you've gone full retard. How about I give you the first 32 bits of every Bitcoin block hash and you reconstruct the message (hint: they are all 0x00000000h). If I have a SHA256 hash, it will likely correspond to collision with two 257 bit messages, four 258 bit messages, etc. The "arbitrary length message" of Bitcoin is a never-before-seen merkle tree of 256 bit hashes; the information in the hash cannot possibly be used to derive the ~250KB of data per block. |
|
|
|
|
Original Bitcoin code is decently commented compared with many commits these days. What is missing is a script and protocol overview and design document.
|
|
|
|
Satoshi's brain when he looked at a white paper.   |
|
|
|
Hamlet (1996) - 242 minutes There are many pages and lists elsewhere devoted to this discussion; this is too off-topic for "off-topic".
|
|
|
|
So, again, my question is, can someone who knows about the client code confirm that it's ultimately using /dev/urandom?
The ultimate source of random data for keys is OpenSSL's rand_lib.c. This is where the build options will cause the answer to diverge; when you build Bitcoin, the answer is ultimately dependent upon build config options such as OPENSSL_FIPS (use the FIPS140 engine) and platform. One would need to investigate the gitian-reproducible Bitcoin builds to give an answer about the official binaries; I've read enough OpenSSL code for this answer that I'm not gonna do this... |
|
|
|
Address: 1GRaviTaB5kizyHpt1SUSmwjTJkude8FfE Privkey: 5JvVieeJr7aq1E7B1sy2y7sZE6m91w62ACvU6UpuUmockSb8MQs Looks like 51 digits to me. You would get a useful response if you said what you are attempting to do and what non-bitcoin-qt software you are using to create a "wallet". If that's too much for you, the (less secure) mini-private-key format used on Casascius coins could be adapted to LTC. https://forum.litecoin.net/index.php?topic=2968.0 |
|
|
|
Payout threshold reduced to 0.01BTC to help smaller miners.
Please be aware lowering payout threshold below 0.1BTC will likely incur higher fees when you go to spend your coins.
Thanks, I'm still the same GPU miner, but difficulty is now 100M instead of 1.5M of two years ago (this adjustment doesn't even keep up with difficulty)... Just this year:  10 Block Erupters would take nearly a week before earning the old 0.1BTC. Now BTC0.01 = $1.38 USD = $1.49 AUD = €1.05 = 1 week of $40 ASIC Block Erupter = 1 week of $150 GPU. |
|
|
|
I previously published a method using the block hash as a pseudo-random number generator for raffle ticket picking. The block hash is quite random: the only way of manipulating future block hashes is to be a significant miner and discard winning block hashes if they don't meet a criteria, which gives you even less chance of influence than your hashrate would indicate in addition to discarding 50 25 BTCs: http://we.lovebitco.in/raffle.htmlHey guys, okay, first of all I'm new to this crypto stuff and I know the issue of "Provably Fair" has been discussed over and over again. Yet I haven't quiet found any definite answer to my approach. What I want to do is make the RNG more transparent by taking the information of the next/current block found (txconf=1). My approach so far looks like this: hmac_sha512($blockhash, $nonce) Using a 512 bit hash gives the illusion that there is more entropy than there is. The block hash can be considered as a random number generator, with an even distribution of results between 0 and the current difficulty target, currently 0000000000000031679C00000000000000000000000000000000000000000000. That's currently less than 198 bits of entropy. It would be more appropriate to re-hash the block hash with a secure 160 bit algorithm such as RIPEMD-160 just to be clear in algorithms that that is the depth of the randomness. A block hash not the best secret for a gambling site, as it not a secret, and your salting method may be discoverable. It is good when a future random number pick will determine a winner and the picking method needs to be verifiable by all. |
|
|
|
|
One night I dreamed I was walking along the beach with the Lord.
Many scenes from my life flashed across the sky.
In each scene I noticed footprints in the sand.
Sometimes there were two sets of footprints,
other times there were one set of footprints.
This bothered me because I noticed
that during the low periods of my life,
when I was suffering from
anguish, sorrow or defeat,
I could see only one set of footprints.
So I said to the Lord,
"You promised me Lord,
that if I followed you,
you would walk with me always.
But I have noticed that during
the most trying periods of my life
there have only been one
set of footprints in the sand.
Why, when I needed you most,
you have not been there for me?"
The Lord replied,
"The times when you have
seen only one set of footprints,
is when I wasn't getting your money."
|
|
|
|
|
Show Posts
