Bitcoin Forum
April 20, 2014, 04:26:08 PM *
News: Due to the OpenSSL heartbleed bug, changing your forum password is recommended.
 
  Home Help Search Donate Login Register  
  Show Posts
Pages: 1 ... 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 119 120 121 122 123 ... 450
1441  Other / Beginners & Help / Re: Continuity of support on: March 13, 2013, 01:47:22 AM
how do we detect if a lead decision maker is under duress?

There's a documented release process.  Trying to ram something through without going through the process would raise suspicions.

If it is a patch, that is likely delivered not as a binary but as source code.

Yesterday nobody was pressured to switch over to running new code.  They were pressured to abandon new code which was found to be broken in a way nobody previously had been aware of.

How does decision making reliably transition?

The problem is with situational awareness.  

When on March 12 about 03:00 am UTC when OKPay credited a customer for a deposit worth about $10K USD, the alert had already been broadcast.  There already was a blockchain fork reaching over a dozen blocks.   Either OKPay didn't know about the current situation or got bad information.   They are the ones who have money on the line.  

Once a fork was detected using customized monitoring solutions a "safe mode" switch which was thrown which protected some pools, exchanges and processing services (e.g., BitPay) from accepting transactions or confirmations once the fork occurred.   They and their customers are the ones who make the decisions, and they had the information to halt processing of new transactions and confirmations (or even shut down completely until resolution, like many merchants and exchanges did.)

Let's say the decision from the developers instead had said to stick with v0.8, and all miners, merchants and users on v0.7 and prior would have to upgrade.  

That decision isn't theirs to make.  They can suggest, but they can't make that decision for miners, merchants and users.

If that decision was more harmful than the alternatives, those who acquire new coins would have resisted it.    Miners follow the rules of whomever is taking their coins.  If Mt. Gox had said they were switching to the v0.7 and got word to the v0.8 miners that "your blocks are no good at our exchange", those miners would have switched to v0.7 regardless of the direction recommendations from the developers.  It is an economic certainty.  Choose -- follow the devs recommendations or get paid.   Guess which wins?

So what the process you are describing for protecting continuity of central authority doesn't work -- there is no central authority.
1442  Bitcoin / Project Development / Re: Phisical coin on: March 13, 2013, 01:02:06 AM
How can i make a physical coin? I would like to do this, to show bitcoin to other people.
Im from Brazil.

A coin that securely holds a bitcoin private key and reveals the Bitcoin Address?

Casascius has created those, but the process was very expensive to do.  He had to have a token company make a brass token with a Bitcoin logo on it.  Then he had to get a hologram made that was would be harder to counterfeit.  Then he had to securely get the private key onto the coin (via paper), without any mistakes (i.e., where a coin goes out without having correct amount of bitcoins on it).

He is now trying to come up with some "low security" coin manufactured using a laser engraver:
 - http://bitcointalk.org/index.php?topic=41892.msg1588721#msg1588721

Now with a paper wallet you have the exact same ability to show off how bitcoin works (private key / Redeem,  Bitcoin Address / Load).  And it costs nothing more than your time and the cost to print a sheet of paper:
 - http://www.BitAddress.org
1443  Economy / Service Discussion / Re: Blockchain.info error when creating wallet on: March 13, 2013, 12:52:11 AM
A friend and I are both getting this error when trying to create a new wallet. The same errors occur across browsers, with alias or without, etc.

Code:
Decoded Key address does not match generated address

Does anybody know what might be causing this error?

When you say "create a new wallet", what specifically do you mean?   Simply just "New Address", or are you referring to something else?

This could be related:

importing private key from a blockchain wallet   <--- Ignore the title, that's not really what he was wanting to do.
 - http://bitcointalk.org/index.php?topic=148455.0   
1444  Bitcoin / Bitcoin Discussion / Re: Understanding why the call to rollback to v0.7 was made. on: March 13, 2013, 12:27:26 AM
What exactly do you mean by roll back? I can't get the chain on 0.7 to update...

By rollback I think he meant have miners downgrade to v0.7 (i.e., roll back the version of software they are using to a prior relese).

If you are having an issue getting your client to sync with v0.7, that probably has nothing to do with the fork.  You probably should open a thread on the Tech Support forum board for that (if the typical suggestions of check your connections, delete the blockchain data files and re-download, etc. don't work for you.)  [Edit: Or move on over to v0.8 which doesn't use BDB for the blockchain.]
1445  Bitcoin / Bitcoin Discussion / Re: Understanding why the call to rollback to v0.7 was made. on: March 13, 2013, 12:24:03 AM
what are locks?

With databases, locks are generally referring to something that must be done in a series.  With multiple CPUs, there can be the situation where two pieces of code want to change the same variable at the same time.  Think of an increment operation.   If you have a value of four and that gets incremented by both at the same time, the result would be five, not six like it is supposed to be.     So a lock basically gives one instance of the code the ability to make the change, and then after that lock is released the next instance of the code can do what it needs to do.  So that value goes from four to five, and then five to six.

So in the context of the "bug" in v0.7 and prior versions, the setting used for maximum locks for BDB was below that necessary for a transaction that first made it into a block on a v0.8 node. v0.8 doesn't use BDB and therefore doesn't have that same restriction.  There was a rule in the bitcoin protocol, due to a specific BDB configuration, that wasn't expressly known previously.

[Edit: And here is the info specifically on the BDB locks configuration:

Here's the Berkeley DB tutorial for anyone who might want to do some reading on sizing your database correctly and lock limits.

http://www.stanford.edu/class/cs276a/projects/docs/berkeleydb/ref/lock/max.html

Quote
The maximum number of locks required by an application cannot be easily estimated. It is possible to calculate a maximum number of locks by multiplying the maximum number of lockers, times the maximum number of lock objects, times two (two for the two possible lock modes for each object, read and write). However, this is a pessimal value, and real applications are unlikely to actually need that many locks. Reviewing the Lock subsystem statistics is the best way to determine this value.
1446  Bitcoin / Bitcoin Discussion / Re: Understanding why the call to rollback to v0.7 was made. on: March 13, 2013, 12:12:41 AM
Not sure if you're really trying to place any blame on the merchant.... errr

No, I'm not.

It might be common sense / generally accepted protocol that when an alert is received by the bitcoin client to basically halt all payment processing until the problem is understood.

In the case of the March 12th fork, the alert didn't go out until after there had already been six or more confirmations on transactions.  There's nothing an OKPay or other merchant could have done if this transaction had occurred a few blocks earlier (after the fork started but before the alert was released).   The merchant can't know at five o'clock that at six o'clock miners will abandon your chain and instead help a fork become the longest chain.
1447  Other / Beginners & Help / Re: Utility Bills for Exchanges... on: March 12, 2013, 11:59:29 PM
Providing utility bills as proof of address is standard practice around the world in any businesses that are required to Know Your Customer.

Just as flinging a stick with a strip of leather at a horse was standard practice for transportation at one point in time (i.e., a buggy whip)..

In this day when so many people are sharing residences to reduce spending, very few people as a percent of the population have their name show up on a utility bill.    It might even be seen as one of the vestiges of a patriarchal social system.  If a person has no credit and never has his or her name on a utility bill as a poor substitute for credit, that person has less power to participate in the economy.   Statistically this affects more women than it does men.  

So essentially it could be argued that this litmus test of having a utility bill in your name before you can engage in commerce is a form of discrimination (intentional or not) against women.
1448  Bitcoin / Bitcoin Discussion / Re: So what happened? on: March 12, 2013, 11:42:55 PM
I'm reading all these things about a glitch etcetera, but no topic really tells me what happened. I guess there is some topic about it but I must be overlooking it.. could someone point me in the right direction?

Executive Overview:
 - http://bitcoin.org/chainfork.html

then:

Understanding why the call to rollback to v0.7 was made.
 - https://bitcointalk.org/index.php?topic=152282.0
1449  Bitcoin / Bitcoin Discussion / Re: Understanding why the call to rollback to v0.7 was made. on: March 12, 2013, 11:29:44 PM
This was an undocumented issue with v0.7 ("bug").

And the term v0.7 is being misused here.  It really is a pre v0.8 bug, right?  i.e., it has existed since day one ... a configuration setting for BDB that has been that way since v0.3 at least, if I read correctly.

Since when was this bug in software? So how long did the testnet have time to discover it?

See above.  It was a scenario (a transaction requiring 10,000 locks, or about 5,000 inputs) that hadn't been tested (again, from what conversations I've seen on it).
1450  Bitcoin / Bitcoin Discussion / Re: Understanding why the call to rollback to v0.7 was made. on: March 12, 2013, 11:20:43 PM
There shouldn't be such transactions, there can be fault at merchant end accepting double-spend transaction during fork time.

When the fork was first being looked into, at March 12 2013 and at 00:03 AM the main net at the time (mined by v0.8 clients) was at block 225439, yet other clients were stuck on the fork at the time (mined by v0.7 and prior clients) was at 225431.

Quote
00:00   sipa   ;;bc,blocks
00:00   gribble   225431

00:01   sipa   but it seems blockexplorer is stuck too...
00:01   sipa   as i'm on 225439

 - http://bitcoinstats.com/irc/bitcoin-dev/logs/2013/03/12

So even before anyone knew for sure that a fork was underway, there could have been transactions with six confirmations on the v0.8 side.  If for whatever reason those transactions didn't also already get included in blocks on the v0.7 side, there was the opportunity to perform a race attack to double spend the transaction that had already been included on the v0.8 side.

We now know that exact scenario is what happened with the transfer to OKPay that is being claimed to have been successfully double spent.  Though in that instance, it was after the alert went out that OKPay still processed the deposit as being valid.  So that specific incident could have been prevented had they halted processing once the alert went out, but there still was a window between when confirmations would occur since the fork started and when the alert eventually went out.
1451  Economy / Trading Discussion / Re: Should Exchanges keep Trading hours? on: March 12, 2013, 10:52:47 PM
The exchange could close outside of business hours and we would be forced to trade in different timezones. It would diversify the exchange economy, and each exchange would have a chance to address issues in peace, without panic spreading like wildfire from a few minutes of downtime.

Camp BX closed trading during the fork.   I was not able to use the best information available at the time and trade on it because Camp BX made the decision to "protect" their customers from market influence (or ??) apparently and close all trading.

I PREFER TO MAKE MY OWN DECISIONS

From another thread:

Quote
An efficient capital market is a market that reflects all available news and information. An efficient market is also quick to absorb new information and adjust stock prices relative to that information. This is known as an informationally efficient market. Generally, efficient markets are expected to reflect all available information. If that is not the case, investors with the information may benefit leading to abnormal returns.

 - http://www.investopedia.com/exam-guide/cfa-level-1/securities-markets/emh-efficient-market-hypothesis.asp
 - http://en.wikipedia.org/wiki/Efficient-market_hypothesis

There aren't many (or any ?) methods for a retail investor to do forex trading over the weekend.   There was one, OANDA, but they claimed the low volume was too challenging for them where they would be taking on too much risk having to take the other side of the trades:
 - http://www.forexcrunch.com/oanda-closes-weekend-trading

Of course, there is a lot of forex trading over the weekend -- just not by you or I.  Central banks, corporate and institutional (government) bankers, multinational corporations and more are all trading 24x7.

So the market is efficient for them.  The rest of us stuck with a losing forex position thanks to news that occurs over the weekend are stuck with that increasingly deteriorating position until the markets open on Monday (or Tuesday, when Monday is a banking holiday like what happened this 3-day weekend.)  

That's not the definition of an efficient market.  Market-changing information occurs over the weekend as well (with announcements oftentimes timed specifically for release over the weekend.)  Bitcoin markets don't have this restriction.    That still doesn't mean bitcoin exchanges can be considered "efficient" though.  For instance, there was a pattern called the "weekend dip" in which buyers interested in buying had insufficient cash at the ready at the exchanges in order to buy and as a result there was little buying to counter a weekend selloff until new cash arrived at the exchanges when funds sent through the banking system were credited.   Lately, however, the weekend dip opportunity seems to have abated.

At some point a financial company will start using Bitcoin as the method for moving value in and out of other assets, including offering the ability for that to continue throughout the weekend as the way to differentiate that investment offering from the competition.
1452  Bitcoin / Development & Technical Discussion / Re: quick advice please on: March 12, 2013, 10:16:09 PM
although nearly complete (less than 10000 blks to go nothing shows?

Until your client is caught up, nothing else matters.

What might work for you is to import your wallet.dat into a Blockchain.info/wallet and then you can see your current balance (and transact) from there.

 - https://blockchain.info/wallet/import-wallet
1453  Economy / Service Discussion / Re: Review unspent transactions for a particular address on: March 12, 2013, 10:10:36 PM
I am just curious if there is a blockchain.info view or another website or software that would show only inputs to a particular address that have not yet been spent?  I'd like to see how many small inputs I have just waiting and unspent.  Wink

You can import the address into a Bitcoin-Qt wallet and go through all the unspent transactions (provided by listunspent RPC call) and open each one up (decoderawtransaction) to filter for just the one address your are interested in.
1454  Bitcoin / Legal / Re: Block chain fork: Can now FinCEN legally go against Bitcoin core devs? on: March 12, 2013, 09:57:50 PM
I just want to analyze

Let's say I am a distributor in the wholesale flower business.  Some of my business comes from selling flowers to street vendors.  Street vending requires a license in my town, let's say, but I suspect none of the street vendors I sell to are licensed.  So a particular vendor normally sells on the corner of Main Street but I know the city will be closing that street for construction.   So I advise the street vendor to sell on a different street.

My advice was used and flowers were sold.  Without my advice those flowers might not have been sold.  Am I in trouble for selling flowers without having a vending license?  I don't think so.  I didn't sell on the street and I didn't receive the revenue or profits from the sale (at least not directly).
1455  Other / Beginners & Help / Re: Continuity of support on: March 12, 2013, 09:38:21 PM
Just like there is a Continuity of government http://en.wikipedia.org/wiki/Continuity_of_government, it seems to me there ought to be a Continuity of support (or whatever it should be called) for the Bitcoin capabilities.

Well, what services are needed for the Bitcoin network to continue?

Yesterday, the services offered included management advice: (obtaining consensus among a small group of trusted individuals (core developers on #Bitcoin-dev) to decide on a plan and then to persuade the parties affected (mining pools, large solo miners, etc) to participate.), communications (the notice on the Bitcoin.org website, the Bitcoin client network alert broadcast, forum post by Sipa, twitter post @GavinAndresen).

If it had involved a software patch, release of that would have been another service the group provided.

If there was just a fraction of the team members available, or they couldn't use IRC and had to communicate via e-mail or something like that I don't know what the outcome would have been.

So there definitely was reliance on a set or people and a method.

The contingency plans touch on some of this:

 - http://en.bitcoin.it/wiki/Contingency_plans
1456  Other / Off-topic / Re: Client 0.8 has taken forever on: March 12, 2013, 09:25:51 PM
before fork, client did start and shutdown much faster than the previous versions...

why rollback when everyone shouldve moved forward

There was some misinformation in the first minutes.  v0.7 and prior had the bug, but a purposely configured v0.8 allowed it to be exposed and cause the fork. 

v0.8 works fine for a user and merchant.  Until there is a v0.8.1 then if you are a mining pool (including p2pool) or large miner (i.e., mining solo) then you want to use v0.7 as blocks mined using v0.8 could still produce blocks that v0.7 (now used for the longest chain) won't accept.


As far as your v0.8 client not syncing, that should be resolved by now.  Has it?
1457  Bitcoin / Development & Technical Discussion / Re: Apollo 13 film vs the handling of block chain fork, which is better thriller? on: March 12, 2013, 09:19:57 PM
I suggest everybody willing to read a thriller take a look at the chat log in Bitcoin-dev while the chain fork was taking please and a miners and developers tried hard to agree on what to do. Every line is chilling...

Read it at http://bitcoinstats.com/irc/bitcoin-dev/logs/2013/03/12

Have fun! Best regards, Sergio.

What time was the network alert broadcast?

I see a few questions like "anyone know how to contact [specific top 10 exchange]", "how to contact [specific top 10 pool]".  

A significant blockchain fork was an eventuality but it was alarming to see how non-automated communications were such a crucial component to getting a resolution, and how those communications are so inefficient due to timezones (middle of the night in Europe), language differences, differences in market impact (the top exchanges and merchants got contacted, the smaller ones didn't), etc.

There is a lot that needs to be learned from this incident.
1458  Bitcoin / Bitcoin Discussion / Re: Reversed transactions due to fork on: March 12, 2013, 08:13:49 PM
Within seconds, Armory told me it was no longer synced to my Bitcoin client, and within a few minutes after that, Armory crashed.

What you are describing is not a "reversed transaction" but simply a transaction that apparently never got broadcast.

The Bitcoin-Qt/bitcoind client does not send out a spend transaction until it has reached sync.  So it could have been perfectly bad timing where just before when your transaction was communicated to bitcoind (which is what Armory uses underneath I believe), that client discovered a block at a greater height and did not send the transaction. 

Now when the client is restarted it does not automatically re-broadcast a transaction.  The bitcoind needs to remain running, sometimes a half hour or (or longer maybe) for any transactions to get re-broadcast.

So, at this point -- make sure you've left everything running for a long enough period to make sure no spend transaction is just waiting to get re-broadcast.

If that doesn't change anything then I'm pretty much out of suggestions.  If the Bitcoin network doesn't know of your transaction (e.g., blockchain.info doesn't have any knowledge of it) and your client isn't re-broadcasting it then either the transaction was invalid and no peers will relay it or it somehow never got saved. 

The bitcoind wallet uses BDB so I suppose if that got taken down with a crash and the database wasn't closed that a rollback in the local BDB wallet.dat database could have occurred to the point it was at prior to you sending the payment.

If this is to an address in your own wallet, there's nothing really to worry about if the transaction were somehow later be re-broadcast.  If it was to some other party, one way of ensuring that the lost transaction becomes moot is to spend those coins with a new transaction.  So if your wallet has 1.123456 BTC, send a payment to an address you control with all 1.123456  (less transaction fee) so that even if that missing transaction were somehow to resurface at some later time it would not be a valid transaction (as you've since re-spent those funds).
1459  Other / Beginners & Help / Re: Unable to transfer wallet to new computer...or access it on my old! on: March 12, 2013, 11:58:33 AM
If I install one from, say, 10.2012 will it fail to show my transactions since then? what other problems will it cause? 

The wallet contains keys in a key pool.  So a backup taken today will already include the keys for my next 100 transactions where a new address is generated for change (or where an address is generated because I clicked New).

So any recent backup probably has all the keys you've used ... unless you do a lot of SatoshiDICE wagers or that kind of activity.

Wallets can be restored, then another one restored without any impact.

You will want to launch the client with -rescan though the first time after each restored wallet.dat.
1460  Bitcoin / Bitcoin Discussion / Re: Miners: Demand more in fees from the userbase by blocking spam transactions on: March 12, 2013, 11:56:50 AM
isn't 0.01 btc closer to 50c?
5 cents actually.

Redo your math.  It is 1/100th of BTC/USD, so about $0.44 at current rate.

Except that is not the mandatory fee assessed low priority transactions.   If you have low priority transactions, you will be assessed 0.0005 BTC per 10KB.   If you have a high priority transaction, there is no mandatory fee.

This has been this way since version 0.4 or something like that. 

If you are being asked to pay a 0.01 BTC fee it is because you have a low priority transaction that is huge.   How does one avoid this?   Stop using bitcoin as a micropayments network.  If someone is sending you bitcoin dust (like SatoshiDICE does for losing payouts), then stop patronizing that service.
Pages: 1 ... 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 119 120 121 122 123 ... 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!