Bitcoin Forum
April 25, 2014, 07:37:06 AM *
News: Due to the OpenSSL heartbleed bug, changing your forum password is recommended.
 
  Home Help Search Donate Login Register  
  Show Posts
Pages: 1 ... 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 [68] 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 ... 450
1341  Other / Beginners & Help / Re: Three months old un-confirmed transaction on: March 18, 2013, 02:55:21 AM
How is that possible?

You are probably describing how in your Bitcoin-Qt client is a spend transaction that still shows 0/unconfirmed.

If so, then what most likely is the situation is that the transaction uses funds that you had received and spent.   The stock Bitcoin-Qt/bitcoind client doesn't let you spend any funds until they have at least one confirmation.   So what can happen is that payment you received showed a confirmation, you spent it, and then it reverted back to having no confirmations.

Looking at it now then, your client has an invalid transaction -- it wants to spend funds that you never really had and don't have today.  You have a transaction that is no longer valid.  Worse, if your transaction also attempted to spend any other funds which were valid, it will reserve those for this transaction which will never confirm.

The Bitcoin-Qt/bitcoind client doesn't handle these outgoing double spends nicely.    In fact, unless you are technical they become quite a pain.

The easiest resolution for some is to import their wallet into another client that can handle this scenario better, or to export your private keys from your Bitcon-Qt, create a new, empty wallet and import the private keys so that you end up with exactly what you just had, less the offending transaction.

The easiest way for some is to import the wallet.dat to a new blockchain.info/wallet and spend the funds from there.
 - https://blockchain.info/wallet/import-wallet

Otherwise, the Bitcoin-Qt client has a Debug console in which you can export your private keys.  The:
  listaddressgroupings
command will give you all the addresses in your wallet, and from there you can do a:
 dumpprivkey [BitcoinAddress]
on  each address. 

Then if you are creating a new wallet, then to import the keys:
 importprivkey [PrivateKey]

For more info on importing:
 - http://en.bitcoin.it/wiki/How_to_import_private_keys
1342  Economy / Service Announcements / Re: MtGox generation of USD redeemable codes will stop at 10 Apr 2013 on: March 17, 2013, 10:20:34 PM
Quote
<MagicalTux> as US customer, it will not be possible to have a balance in anything else than BTC/USD/CAD

That's interesting. So how do they know who's a US customer? ID scans for all an sundry? IP geolocation? Simply trusting their customers to be honest?

 - Received Dwolla?  Ding.  U.S.
 - Submitted ID and it says U.S?   Ding.  U.S.  (or submitted Canadian,  CAN)
 - Access via U.S. or Canadian IP address?    Ding.  U.S. or Canada.

It's 80% of Mt. Gox's customer base (not sure if that is by number or by value of accounts).

1343  Bitcoin / Electrum / Re: Electrum why backup wallet? on: March 17, 2013, 09:31:31 PM
I don't need to restore my wallet from a backup, right?

If you ever import private keys, those won't be able to be recreated from the seeds.
1344  Bitcoin / Mining speculation / Re: Hashrate jump, Who can it be ? +60% to 53 Ths on: March 17, 2013, 09:03:11 PM
3 day average say we've gained 11TH+ in the last 3 days

Fast forward 12 months:  Do you remember when we thought a 11 Thash/s spike was something notable?
1345  Bitcoin / Project Development / Re: ICBIT Derivatives Market (USD/BTC futures trading) - LIVE on: March 17, 2013, 06:02:23 PM
Clearly you can't determine the settlement price when there are 4 hours left in the settlement day.

A (24 hour) volume weighted adjusted price is just that -- the VWAP for the trailing (24-hour) period.  It can be any 24 hour period of time.  The contract doesn't say 00:00 to 23:59 UTC of settlement day, it says the "volume weighted average price", and the settlement occurs at 20:00 UTC.   So the 24 hour WAP goes from 20:00 on the day prior settlement day through 19:59 of settlement day.   [Update: Since the contract doesn't actually say "24 hour", it could be ambiguous as to which VWAP was intended ...  24 hour, monthly, or what?  Previous BTC/USD contracts were using the 24 hour VWAP.]

Now I suppose a script can be run to check the numbers, but settlement happens in real-time.  There's no ability to go pull the raw trade data to come up with the WAP in real-time.   If that computation is done later and comes up with a different number, then it needs to be analyzed why that is.

I can see the potential for a problem though.  If Mt. Gox exchange were to misreport the weighted average, possibly from a staff member trying to manipulate the ICBIT settlement price, then it would be hard to prove what value was showing.   I can see the need to have a separate computation performed later against the raw trade data for verification purposes.
1346  Bitcoin / Project Development / Re: ICBIT Derivatives Market (USD/BTC futures trading) - LIVE on: March 17, 2013, 05:46:39 PM
I find the use of 8pm surprising as the contract says it's the average for the settlement day.

The contract was settled at 20:01 UTC, just like the contract says.

PM means after 12:00.  08:00 hours + 12:00 hours = 20:00 hours.  

The forum post time is 08:39 pm UTC, which is the same as 20:39 pm UTC.    He posted the forum post 39 minutes after settlement occurred.
1347  Economy / Service Discussion / Re: [LIST] btc to silver/gold exchange sites on: March 17, 2013, 04:49:05 PM
If there is already a list like this, let me know : P

 - http://en.bitcoin.it/wiki/Trade#Precious_.26_Base_Metals.2FCoins
1348  Local / India / Re: Forum Moderator on: March 17, 2013, 04:17:24 PM
He has requested me to post this and request India forum members for their opinion if everyone is alright with me as the moderator.

Several interactions with Benson.  Pleasant experience on all.

1349  Other / Beginners & Help / Re: How can I prove that a bitcoin transfer was made? on: March 17, 2013, 03:57:01 PM
Can I prove that I made a bitcoin transfer to a particular address? Say, for example in case of a legal dispute. I am asking for something more substantial than a screenshot of my wallet. I understand that all transactions somehow ar stored on the network?

Then the question is, how can you prove to the person you paid that the address was one that they gave you to pay?

And the answer to that:

We need a payment protocol with non-repudiation built in.

See https://gist.github.com/2217885 for a multisig version (the singlesig version is simpler, but the merchant <-> customer communication will be the same).


And a variation of which is being developed now.  The Development mailing list has a thread on the topic.
1350  Bitcoin / Bitcoin Discussion / Re: Bitcoin & download speeds on: March 17, 2013, 03:52:08 PM
How does Bitcoin ever expect to be useful in the mainstream if every time people with slow internet open their wallet, it takes hours and hours to update.

If you are using v0.8, the initial download is about a day or less -- and much less if you have decent hardware and bandwidth.

If you are using v0.7, stop (or stop, if you don't have decent hardware, bandwidth and patience.)

If you are using really old hardware, consider MultiBit, which is an SPV client -- it only downloads block headers and unspent transactions for addresses in the wallet.
1351  Bitcoin / Technical Support / Re: blockchain WTF please please help me understand this on: March 17, 2013, 03:44:50 PM
Even though the total btc in top right hand corner says 3.85 btc it still says everytime (insufficient funds, available balance 0.022774 or there abouts as if the 3.6 btc

Yup, Blockchain.info was reporting wrong values.

Here's more info:

Quote
Balances bug fixed. All calls to /unspent /multiaddr /address should now be much faster, means faster transaction creation and API calls.
- https://twitter.com/blockchain/status/313269863365877760

Give it another try and report back.
1352  Other / Beginners & Help / Re: Bitcoin In Israel on: March 17, 2013, 03:09:25 PM
Take a look at localbitcoins.com to see if you can find anything,

The URL for that:
 - https://localbitcoins.com/country/IL

There's Meni's:
 - http://bitcoil.co.il/

There's also:
 - http://bitcoinisrael.co.il  <---   Fairly new, perform due diligence, use and escrow maybe?


You can also pay cash to buy either a CashU card or a UKash card, and use that instrument to buy bitcoins through Bitcoin Nordic (either), VirWoX (UKash) or mercabit.eu (UKash).

For larger amounts, of course, an International bank transfer to an exchange works.

The more comprehensive list of exchanges:
 - http://en.bitcoin.it/wiki/Buying_bitcoins
1353  Other / Beginners & Help / Re: Bitinstant BTC-E on: March 17, 2013, 02:33:25 PM
Does any1 know what happend to bitinstant? There is no more possibility to fund BTC-E

The BitInstant support thread is here:

Official BitInstant Support Thread (Active Customer Support)
 - http://bitcointalk.org/index.php?topic=128314.0

That question has been raised, but not answered as far as I can tell:

why cant we deposit to btc-e anymore
1354  Bitcoin / Technical Support / Re: Did wallet.dat files change over time? on: March 17, 2013, 02:28:25 PM
Could it be that the wallet.dat file change over time so that the current client is unable to read it?

The newer clients (v0.7 and higher) are less ignorant of bad data in the wallet.dat.     Are you getting a message unable to open wallet.dat?

You could try joric's pywallet and see if it can get more out of it than Bitcoin-Qt can.
1355  Other / Beginners & Help / Re: Unconfirmed Transaction | Installed Python/Pywallet... need help on: March 17, 2013, 02:23:03 PM
Please elaborate...

How to export keys from the Debug console?

Or how to get to the debug console?    The Debug Console option is in the pull-down menu, like Help -> Debug Console maybe?  (I'm not using a machine with Bitcoin-Qt installed at the moment and I can't remember exactly which pull-down.)

The command to get a list of all addresses in your wallet:
  listaddressgroupings

Then to get the private key for each:
  dumpprivkey [address]

Then to import the private key for each:
  importprivkey [private key]

You can copy and paste from the Debug Console into an editor, and then create the commands to somewhat automate it.

Here's more on importing:
 - http://en.bitcoin.it/wiki/How_to_import_private_keys
1356  Other / Alternate cryptocurrencies / Re: Cryptocurrency Strategy on: March 17, 2013, 02:14:13 PM
Actually, I was having a conversation with a friend and the idea that banks might create their own crypto currency.

Sure.   Call it e-gold.   Sell the snot out of it!   Great idea!   Someone should do it!

[/snark]
1357  Bitcoin / Development & Technical Discussion / Re: Is the 21 million bitcoin limit unchangeable? on: March 17, 2013, 01:57:20 PM
If the subsidy would be abolished the purchasing power of my 100 BTC would gain 2.5% every year and the interest rate drops to 2.5%.

Well nobody knows what the change to purchasing power is if this hypothetical "economic majority forces an immediate end to the block reward subsidy" and thus that 2.5% of currency inflation that was expected in year 2024 goes away.

That's why the buyer should require that lending contracts include some language that addresses changes in the protocol that would affect the currency inflation rate.   

But it is really a moot point, I believe.  The lending from the economic majority also includes loans to miners, and miners made an investment in their capacity counting on the subsidy -- it was part of the deal.  The miners would default on their loans causing once again for the economic majority a wash between the two options.   And that's a relatively minor issue compared to the bad image it would give.  If there were any alternatives a black eye like that would be a great catalyst to move to another one which is even more resistant to that type of corruption.

1358  Economy / Speculation / Re: The Weekend Dip Myth on: March 17, 2013, 01:04:38 PM
So it seems this time weekend dippers turned out to be weekend hikers and will have to buy for more then they have sold for.

Well, the weekend isn't over but it looks to be about a break even to buy back right now, then less fees for a sub 1% loss.    At the time of the post (late Wednesday (West), mid-day Thursday (East)) the exchange rate was something like $47.80.  The last trade at this very moment was $47.52.

There was a dip, down to $46.05 and many opportunities to buy back at a small profit when it was under $47 and was looking quite apparent that this weekend was not going to see a big selloff.  The thing the weekend dip strategy couldn't have seen in advance was the IMF going batshit crazy like they did.  Now I gotta figure out how to reverse some other positions where I'm on the wrong side before Europeans rush the exits and discover bitcoin as a new home for their money.
1359  Other / Beginners & Help / Re: DB Bug Example of 51% Network Takeover? on: March 17, 2013, 12:26:59 PM
Quote
  Reverse other people's transactions
    Send coins that never belonged to him
I don't agree with this. As far as i know, yes he can!

You might be confusing the term "reverse transaction" with "reverse confirmations".    An attacker with 51% can release a blockchain that started a number of blocks back and invalidates a number of blocks.  For any transactions that the attacker does not include in the new longest chain, those transactions will simply sit as 0/unconfirmed.   That's technically not "reversing" the transactions.

And for part two of that, "Send coins that never belonged to him", I'm not sure why you would think that an attacker with 51% could do that.

I know of some people in the banking sector that would do it just for laughs if it became mainstream

They'ld throw twenty million+ dollars away?  I doubt their shareholders would think it wise.

Anyways, two years ago when bitcoin had just hit parity with the dollar, (giving a total dollar valuation of about $7 million USD) and the cost to do a 51% attack was probably less than $1 million of hardware this same argument came up then.   "If bitcoin becomes mainstream, $1 million would be nothing for a government or big bank".   Which probably is true, but nothing happened.    Now the cost is 20X that, ... no longer something that would be done "just for laughs".    A few more months, that might be $40 million.    They better hurry, because this thing is starting to look like it could go mainstream.
1360  Bitcoin / Bitcoin Discussion / Re: Alert: chain fork caused by pre-0.8 clients dealing badly with large blocks on: March 17, 2013, 10:00:05 AM
This would force all the transactions that "used to be good" but no longer are to get re-broadcast to get into the new chain.

Nope.  Those v0.8 clients simply added those transactions from the orphaned block back into the memory pool.  It does not re-broadcast them.  I don't even think the node that sent the transaction will re-broadcast the transaction immediately upon the block being orphaned -- it probably gets treated like normal, at some random point (e.g., over the next half hour) it will re-broadcast it because it has no confirmations.  [Edit: the sending node was a v0.7 node so it had no concept of orphaned v0.8 blocks, so it should've just simply re-broadcast periodically until confirmed.]

There's another question:  Wouldn't most of them be in both chains already?

Take the 211.9093 BTC (~ $10K) transaction to OKPay (12814b8ad57ce5654ba69eb26a52ddae1bff42093ca20cef3ad96fe7fd85d195).  It had been broadcast and then included in the v0.8 side in block 225,446 (00000000000000757de9173ee2f01c9f957c8aa3b4f71b901b0fa19683ab1fa1) but did not confirm on the v0.7 side, presumably because the transaction had inputs that hadn't even confirmed yet on the v0.7 side.  So on the v0.7 after the transaction had been broadcast and relayed you had new v0.7 mining nodes starting up.   But they don't pull transactions from peers, they only listen for broadcasts.

So that's a normal situation where these new v0.7 mining nodes are ignorant of a double-spending race attack potentially being attempted.  Only BTC Guild knows if and when that node had received (12814b8ad57ce5654ba69eb26a52ddae1bff42093ca20cef3ad96fe7fd85d195) and if it had then why their node (running v0.7 by then) no longer knew of it when it mined the double spend (762443f6373b7c8b3833d4ad23578fc3099cc29b86d1359d0c0565e3c8614f91) more than six and a half hours later.  It could be that the node was just spun up and the memory pool just hadn't received that transaction yet.  I might suspect that the memory pool for that node was filling and as a result was housekeeping by flushing older and lower priority transactions out.  This was an intentional double spend (even if the losses to the merchant were repaid voluntarily by the "attacker" at a later time) and was carried out by running a script to broadcast the double spend continuously every ten seconds.   The initial transaction was submitted through Blockchain.info (though I'm not sure if that was as a raw transaction through their pushtx or if it was through their API (or normal web interface maybe even).  It is possible that it was a fire and forget action, where the transaction wasn't re-broadcasted ever again.

What might have been useful is if there was some hard fork recovery approach in which the memory pool was initialized using the list of transactions from a set of blocks (the ones that would be orphaned on the v0.8 side).  If any blocks arriving had transactions that included a double spend of the recovery transactions those blocks would be ignored.  This mode would continue until all transactions from that initial set were either included in blocks or rejected for being invalid.  Then the client would switch back to normal and bring in the transactions that had queued up while the node was in the recovery mode.  As long as enough hashing capacity followed this "deferential recovery" mode the recovery might have been nearly as quick and no merchants would have had confirmed transactions on the v0.8 side that ended up not confirming on the v0.7 side when the transaction was valid on both.  That's not a violation of the protocol but instead is just a manual override mode that would help protect Bitcoin's prime directive #3 -- transactions having six confirmations or more on the longest chain are never reversed.

Pages: 1 ... 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 [68] 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 ... 450
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!