Bitcoin Forum
July 04, 2015, 06:58:40 AM *
News: Latest stable version of Bitcoin Core: 0.10.2 [Torrent]
 
  Home Help Search Donate Login Register  
  Show Posts
Pages: « 1 ... 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 119 120 121 122 123 124 125 ... 455 »
1481  Other / Beginners & Help / Re: Alipay to Bitcoin? on: March 15, 2013, 01:15:26 PM
I don't know why you cannot do the same thing.

The wiki is open to all to edit.  I volunteer many hours of my time every month to do what I can to keep it current.

I don't know why you cannot do event a fraction of the same thing.
1482  Other / Beginners & Help / Re: Continuity of support on: March 15, 2013, 01:02:17 PM
specifically but rather the database of Bitcoins, right?  Does the coin database (is this the block chain?) grow without limit or is there some sort of truncation eventually?

Transactions have inputs (which spend previously unspent transaction outputs) and outputs.  The exception is the first transaction in the block which is for generated coin and fees.  
 - http://en.bitcoin.it/wiki/Transactions#Generation

Here's the coinbase transaction for the first block of that March 11th blockchain fork.
 - https://blockchain.info/tx/9bfae0ea23bc15db2b0cfba42926e32a396103ca080baa73349936f38c6ab7b0
The amount was 26.70259792, which consists of 25 BTC for the generated coin and 1.70259792 which is the total of the fees of transactions in the block.

The miner can't spend this coinbase (neither the generated coin nor the fees received) until it has 120 confirmations.

They will "mine" not for new coins anymore but instead just for the, um, confirmation/validation/encryption of the new blocks of transactions.

For the fees.  Right now the fees are a small fraction of the block reward subsidy.  That's why the subsidy is so high, to help get a sufficient level of protection (hashing capacity).

Hmm, two miners (unintentionally or deliberately) creating divergent block chains force entities to make a choice; the majority win.

Nope.  Longest chain for the agreed upon protocol wins.

What happened this past week was there was a change to the protocol in v0.8 that nobody realized happened.   Then there had to be a decision -- which side should win, and are there sufficient resources behind the decision that it would succeed.

In the earlier moments of a hard fork (who's job is it to be watchful and broadcast the alert?),

Well, BitPay was watchful and noticed it, halted their daemon and started investigating.  At least one pool's monitoring detected it however it apparently wasn't acted upon in a timely manner.  I suspect one or more exchanges were watchful and noticed it,.     The v0.7 client automatically detected that it was behind and displayed a warning to its users.   In this case, unfortunately, it was the v0.8 clients that needed to be warned, but since that was the longest chain, they shouldn't have cared as the assumption is that longest chain six or more blocks ahead is final, never to be surpassed.

It might not be clear at all which side will become the winning side.  Entities (at least those in the know) would be wise to wait (for how long?  what if a paid service is life critical?) for the situation to settle down.  Hmm.  It feels like waiting is not acting with authority.

When the VISA/MC/AMEX payment card systems go down, merchants can't get authorization, but they still fall back to the imprint method (pencil + POS receipt, and scratch the pencil across the receipt on top of the card, makes an imprint of the card on the receipt.)   There's no guarantee the retailer would win in a dispute, so this only works if the customer can be trusted.      

During the time of the accidental hard-fork this past week, there was no reason for a merchant to stop accepting payments from a trusted counterparty.  Those transactions all (or nearly all) got processed in blocks on both chains and no problems occurred for those.   Neither outcome of the decision to go with one side or the other mattered for those transactions.  As far as how long the wait was, the first reports of a problem trickled in at March 11, 2013 at 23:10-ish, and it was only less than an hour later, March 12, 2013 at 00:02 that dev's realized they might be facing a crisis, at 00:06 that they confirmed it, and 3 minutes later Mt. Gox and poolops were alerted.  At 00:30, while devs were still deciding (though nearly all in agreement towards the v0.7 side) the largest pool unilaterally began preparations for switching over to v0.7.  And within a half hour from there that became the decision that was communicated out.

This scenario is a little different from other potential crisis situations but there definitely were some lessons to be learned.   The contingencies list (from the Wiki) didn't cover this specific type of incident but the steps it did have were followed and helped.

In theory there might not be a central authority per se but in practice continuity of support can potentially provide quicker and higher quality results reducing the risks to the Bitcoin community.

I do see how if there ad been one or two of the core developers who were unreachable or unable to help how the outcome could have been worse. (e.g., if Sipa hadn't been able to crank out a band-aid fix for v0.8 so that Slush's v0.8 would work on the chain on the v0.7 side.)  

But remember, there's no "Bitcoin, Inc."   These core developers are volunteers (except for Gavin).   It will probably be the major participants who each build a crisis response strategy suited for their own needs and collaborate where appropriate.

1483  Bitcoin / Technical Support / Re: yet another unconfirmed transaction on: March 15, 2013, 08:35:20 AM
The transaction size is 1160 bytes. The price per 1000 bytes is 0.0005 BTC. Shouldn't you have paid 0.001 BTC fee for this transaction?

Correct me if I'm wrong.

You are correct on the price per KB.  What I'm not sure of is if a 1160 byte transaction is considered 2 X 1000 bytes, or just 1 X 1000 (where remainders are not considered for the fee assessment).

Quote
A transaction will be sent without fees if these conditions are met:
It is smaller than 10 thousand bytes.
All outputs are 0.01 BTC or larger.
Its priority is large enough (see the Technical Info section below)
  - http://en.bitcoin.it/wiki/Transaction_fees

So this transaction had an output below 0.01 BTC thus there did need to be fees paid at the rate of 0.0005 BTC per KB.

Incidentally, this transaction has since confirmed.
1484  Economy / Currency exchange / Re: Question: BTC with Credit Card on: March 15, 2013, 05:44:38 AM
What reliable website can I use to buy btc with credit card?

About the only options are VirWoX and BTCQuick.

For VirWox, you actually buy Second Life Lindens (SLLs) and pay with credit card.  Then you convert those SLLs to BTCs and withdraw.
 - http://www.VirWoX.com

For BTCQuick, it depends on catching them when they have stock:
 - https://www.btcquick.com/buy/index.php?route=product/category&path=60_63

Otherwise, you pretty much are stuck.

I did see that Transferwise now accepts Debit card (EUR and GBP).  So you could then add funds from TransferWise and transfer those to your exchange account (e.g., if GBP, then convert to EUR and use SEPA withdrawal to BITSTAMP).

But cash is really the easier way to buy coins in most areas (U.S., Canada, Australia, New Zealand, Russia, Brazil, E.U., and more).   

In the U.S., cash deposit at BItMe (using Chase bank), BitFloor (using Bank of America), Ziggap (Using Western Union or Moneygram), BitInstant (Moneygram) and more.   The other options can be found from this list:

 - http://en.bitcoin.it/wiki/Buying_bitcoins
1485  Other / Beginners & Help / Re: buying coins via PayPal on: March 15, 2013, 05:37:33 AM
How can I build trust with someone so that they will accept payment via PayPal?

Here's someone else, couldn't even get anyone to do a $2 trade with PayPal.  Even after posting a pic of a sad looking puppy.   

But that same person could find a lender for same, just by offering a usurious interest rate.   It's a bizarro world.

And I thought posting a pic of puppy would do the trick...

Well here's my loan at BTCjam https://btcjam.com/listings/2487 Paypal and phone number verified, ID verification is pending approval.

Now go and invest your coins with 100% profit  Tongue
1486  Bitcoin / Mining support / Re: UK ISP problems with mining on: March 15, 2013, 04:04:43 AM
my isp keeps on throttling my internet connection since it is counted as p2p.

Does this help?

 - http://en.bitcoin.it/wiki/Tor#Pooled_Mining
1487  Other / Beginners & Help / Re: bitfloor BTC prices on: March 15, 2013, 03:59:27 AM
relatively quickly?

That really is what determines what price you pay.

If you simply sit above the current highest bid, eventually someone will hit you because someone will sell at market rate eventually (and that's your bid).  What could happen is the exchange rate rises though and you have to stay above the highest bid and you could end up paying more than if you hit the lowest ask right off the bat.

So it all depends what you mean by "relatively quickly".  Since you don't when a sell order at market will come in that could be hours or more.  Or it could be ten minutes.

1488  Alternate cryptocurrencies / Altcoin Discussion / Re: Cryptocurrency Strategy on: March 15, 2013, 03:51:30 AM
Brand-wise they are very, very vanilla.

Decentralized (proof-of-work based) digital currencies are vulnerable to a 51% attack.  Thus to be protected they need a sufficiently high level hurdle to reach 51%.  

When Bitcoin was small, its hurdle to being 51% attacked was that nobody knew it was anything more than an experiment.  There was relatively little value crossing the wires.     Today Bitcoin is protected from a 51% attack by the fact that to do so might cost tens of millions of dollars (if attempting just to procure the equipment to do a brute-force 51% attack.)

This is not something "very, very vanilla" between Bitcoin and the alternatives.
1489  Bitcoin / Technical Support / Re: repost for advice (non tech user) on: March 15, 2013, 03:04:09 AM
so I opened the folder "bitcoin" and typed it in? when I restarted the client another folder was created called bitcoin.-recan

I've no idea what you did but there should not be a directory called "bitcoin.-recan" or any new directory.  

Your wallet.dat contains the private keys necessary to spend.  As long as you still have that, you should still have access to spend those funds (once you get a client in sync).

At this point you are first simply trying to ascertain that the funds are still there.

In the bitcoin client click on Receive.  Do your addresses show?  If not, you are running the client against an empty wallet.dat.

You can stop the client and swap out wallet.dat files (e.g., rename the current one and restore from backup another one) to see if that shows any different.   With 4K blocks to go, that means if you did ANY spending with your wallet since January you shouldn't trust the balance that shows until it has sync.   Newer versions of the client don't show bogus results when not in sync, so if you had done any spending from your wallet then this is a problem that you see only because you are still on an older client.
1490  Economy / Speculation / Re: Physical security of MtGox on: March 15, 2013, 02:52:10 AM
I'm sure wallets and such are backed up. The website itself is hosted remotely. Still, the damage would be immense.

Discussed here:

- Does [MtGox] use cold storage (an offline wallet that cannot be accessed should the exchange's service become compromised)

Yes.

 - Is there a target as to how much of customer's funds are kept in cold storage?  (e.g., percent of total, or perhaps relative to recent withdrawal requirements)?

On average 98% of customer bitcoins are held in cold storage, with possible variations on large bitcoin moves (large deposits or customers asking for large withdrawals).

 - Do new deposits go to cold storage?  (if the hot wallet is compromised, new deposits made (e.g., automated payouts by mining pools) would still be secure)

No, this wouldn't be practical in terms of number of bitcoin addresses to keep in cold storage. This could change thanks to BIP 0032 which we are working on implementing. It should be noted however that we are using a hardware security module for the hot wallet

 - Does the offline wallet where the cold storage resides remain protected due to an "air gap" (no access to it electronically, not connected to the network)?

Offline wallets are generated from an offline system and kept in paper format in three separate locations, using a technology based on raid. It will likely be changed to use Shamir's Secret-Sharing method in the future, and all existing offline wallets will be converted to this.

When the funds for Mt. Gox's current U.S. and Canadian customers are "transitioned" and then handled by Coinlab, that's discussed here:

Quote
CoinLab's Tiered Security Options:

Medium Security (Hot Wallet) amounts are kept minimal and layered behind clients and firewalls
High Security (Cool Wallet Storage) is kept in a physically secure location
Ultra High Security (Cold Wallet Storage) is split using Shamir's Secret Sharing Algorithm and distributed physically

 - http://coinlab.com/storage
1491  Other / Beginners & Help / Re: I need the current opinion on mining on: March 15, 2013, 02:36:40 AM
But again, with the increased difficulty, should I not even attempt at mining?

Put simply, look at the following image.  

For you, up just a little is something bad.  Up like this is redonkulously bad.


 - http://bitcoin.sipa.be/speed-small-lin-ever.png

And that is with not all Avalons that have been paid for being shipped yet, nonetheless how BFL hasn't even started shipping.  Either of those happens and there won't be a single remaining GPU miner who can smile (unless, of course, there is a corresponding BTC/USD increase that tracks the difficulty increase).
1492  Bitcoin / Development & Technical Discussion / Re: How to force a rule change by bloating the UTXO set on: March 15, 2013, 02:06:54 AM
you can stick with your old client, and it will reject the "Bitcoin 2.0" blocks, but you can't spend your money without miners, and you can't be a miner without the UTXO set.

Sure you can.  It just takes one or more miners to mine before transactions are included in a block and eventually confirm.  Just like after the hard fork occurred and v0.8 was ten blocks ahead, anyone could still mine on the v0.7 side even though it had just a fraction of the hashing capacity and the v0.8 side had the longest chain.

It isn't the miners who decide.   It is the economic majority who will buy the miner's coins that decides.  

If this happened today and the very next block were to be a fork as you describe as 80% of the hashing power ganged up and switched over to a client that followed your protocol change, the decision facing users, merchants and exchanges would be .... do we follow, or do we boycott?

Probably what would happen is that payment processing for much of the bitcoin economy would be immediately halted (i.e., there would be no recognition of confirmations on either side of the fork) until some discussions occur.  But if those who buy coins (the economic majority) were to boycott the protocol change, it would only be a matter of time (minutes to hours) before individual miners would leave the pools that pulled that stunt and the chain for the original protocol would gain and extend beyond the height for the chain with the changed protocol.

[Update: And the difference between your scenario and this weeks' hard-fork was that users, merchants and exchagne were already using software that unknowingly accepted the rule change (no more 10K BDB locks, and reverting to v0.7 was compatible with both v0.7 and v0.8 clients.  i.e., it didn't require everyone to have to change their software to something that understood a change to the protocol rules.]
1493  Bitcoin / Bitcoin Discussion / Re: Social Network "Zurker" now accepting Bitcoin (through Coinbase) on: March 15, 2013, 01:05:36 AM

Is this pretty much BTCJam except with more social network stuff?
1494  Other / Beginners & Help / Re: declaring coins to the IRS? on: March 15, 2013, 12:36:56 AM
How do you do this?

Related:
 - http://en.bitcoin.it/wiki/Tax_compliance
1495  Bitcoin / Technical Support / Re: Fastest way to withdraw using private key on: March 14, 2013, 11:56:23 PM
What's the fastest way to import a private key and spend the inputs for that address?

Manually?
 - http://brainwallet.org/#tx  <--- Be very careful to spend every bit of the funds (except the fee), otherwise the unspent balance goes ... to fees.

Also, EasyWallet from a mobile has one-touch scan and redeem (to an EasyWallet).   But I believe it is N confirmations (3 ?) before the funds appear in the wallet.
 - http://www.EasyWallet.org
1496  Bitcoin / Project Development / Re: ICBIT Derivatives Market (USD/BTC futures trading) - LIVE on: March 14, 2013, 11:39:34 PM
The field for Quantity is assuming the input is Octal numbers when there is a leading 0.  e.g., if I enter quantity 011 that gets understood as 9.   If I enter 09 that gets an "invalid quantity" (because in octal, anything above 7 doesn't exist.)
1497  Economy / Speculation / Re: At no point was there a double spend in the longest chain on: March 14, 2013, 10:10:02 PM
It seems the only possible scenario is if the attacker connected directly to a restarted miner and submitted the double-spend to the miner first. This is statistically unlikely.

The original transaction (to OKPay) had fees of 0.0005 BTC:
 - http://blockchain.info/tx/12814b8ad57ce5654ba69eb26a52ddae1bff42093ca20cef3ad96fe7fd85d195

The double spend transaction had fees 0.00139906 BTC and was mined by BTC Guild.
 - http://blockchain.info/tx/762443f6373b7c8b3833d4ad23578fc3099cc29b86d1359d0c0565e3c8614f91

The double spend transaction wasn't seen by Blockchain.info until 2013-03-12 08:07:30, which was hours after the chains converged.  It got included in the next block.  But BTC Guild had already mined a dozen blocks on the v0.7 side by then.

I'm wondering if BTC Guild included the double spend transaction because of the higher fees versus following the protocol of rejecting it as invalid (for having an input that was already spent in a previously received transaction).
1498  Bitcoin / Bitcoin Discussion / Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. on: March 14, 2013, 09:24:25 PM
I later manually corrected the issue with another transaction, thus double spend.

For post-mortem analysis, would you mind sharing how that raw transaction was broadcast?  Through bitcoin-Qt/bitcoind I presume?   But was this just connecting to peers or had you actually explicitly connected to a mining pool or well connected node?

The question is that most peers would have rejected it because they should already have known of the original transaction (12814b8ad57ce5654ba69eb26a52ddae1bff42093ca20cef3ad96fe7fd85d195) and not relayed your double spend (762443f6373b7c8b3833d4ad23578fc3099cc29b86d1359d0c0565e3c8614f91).  

With all the nodes reverting to 0.7 and/or starting up with an empty memory pool it is not impossible for your node to have reached one of them with no knowledge of the original transaction and then because your double spend transaction was perfectly valid for that node to relay your transaction got relayed to other new nodes as well.  Eventually then there would be a path that would reach the miner who eventually mined 225466 (the block with the double spend) -- BTC Guild [Edit: Yes, confirmed BTC Guild, per the coinbase].
1499  Other / Beginners & Help / Re: icbit - weird fees and weird fills/logs. on: March 14, 2013, 03:12:32 PM
this is unacceptable, and unheard of. are there any details on how and when this happened?

Here's the thread:

We had to close a few profitable positions due to non-paying customers

I'm confused.  If it was a profitable position it would add variation margin and thus no payment would be required.   About the only thing that would explain a profitable position seeing forced margin selling would be if the margin requirements changed, which if true would be news to me.

One person shorted too much, and did not add money in the account to upkeep the position, so account reached negative state. And there are no asks in the order book to cover the short position. So it falls into the "worst case": the system chooses counter parties (longs in the same futures contract in our case) with biggest unrealized profit by itself, and makes a forced trade (buy to cover) between these parties.

As a result, the person who was in debt ends up with 0 BTC in account (there were a few emails sent, and waiting time was a few days), and profitable traders positions were reduced (as if they sold them to realize the profit).
1500  Other / Beginners & Help / Re: Month old transactions now unconfirmed upon upgrading from 0.6x to 0.8 on: March 14, 2013, 02:31:09 PM
Yet In the overview tab I see   "unconfirmed:     0.00142 BTC"

Chances are you've been playing Satoshi DICE (even if that was a month ago). 

Does the transaction show up in the blockchain (e.g., on Blockchain.info ?)

If not, let your client run for a half hour to an hour to ensure there is an attempt to re-broadcast it.    Then check blockchain.info again.
Pages: « 1 ... 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 119 120 121 122 123 124 125 ... 455 »
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!