Bitcoin Forum
April 25, 2014, 07:02:36 AM *
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: Forks (and other flatware) on: March 13, 2013, 09:53:44 AM
It just doesn't sit right with me that there was such intense concern over the (minor and short-lived) fork on Monday.  Especially if governments could effectively force a network fork within their region.

What you are predicting is like the desert island scenario.  The answer to that was:

But overall, bitcoin is an online digital currency and doesn't work for desert islands without at least sporadic (e.g., hourly) occurrances of connectivity.  

All this "desert island" would need is a single node with outside connectivity.  The bandwidth requirements are as small as what a dial-up modem provides, with intermittent / period connectivity during each day.  Then that node would then communicate with the local peers on the island.  New blocks would arrive to this node and new transactions would be broadcast out from it.

Of course, the requirement for there to be block confirmations before payments are recognized would be a necessary variation (e.g., no 0/unconfirmed for the anonymous tourists to the desert island).
1442  Economy / Gambling / Re: bitZino - Provably Fair Bitcoin Casino - Blackjack, Roulette, Craps, Video Poker on: March 13, 2013, 06:29:19 AM
rather than just having the reels spin indefinitely.

Ok, I do notice it hasn't happened when I've not been logged in.  But then when I am logged in, even if I'm playing Play Money while logged in it will happen.  It also happened on Firefox 16.0.2 (Ubuntu) as well as on my Android Nexus 7 tablet (Chrome for mobile).  

So multiple browsers, multiple devices.  The only thing consistent is using my same login.  Maybe it is my account?  

Have you run into similar issues with Roulette as well? It's possible that the same bug is present on both of these games.

I don't normally play roulette.  But to test I just tried on the same browsers and devices and no problem with roulette.  Went back to slots on each and got the indefinite spin right away.  It isn't consistent 100% but I don't have to do more than a spin or three and it will go with the indefinite spin for at least one wheel.
1443  Bitcoin / Bitcoin Discussion / Re: Understanding why the call to rollback to v0.7 was made. on: March 13, 2013, 05:34:02 AM
I am unclear about the compatibility of older versions earlier than 0.7.

The BDB database lock limit issue discovered March 12th exists with every version of the reference client (Bitcoin-Qt, and prior to that WxBitcoin GUI, and bitcoind) prior to v0.8.

I assume that means all previous versions? At what point are older versions no longer usable?

That's the definition of a hard fork.  Old software rejects new blocks which include the incompatible change.

So the moment the fork starts is when any clients not supporting the new rules are no longer supported.

When that does happen how would a user know they should upgrade?

Chances are when the hard fork happens most everyone already would have upgraded.

What that means is that the client released would support both the existing rules and the new rules, with the new rules not taking effect until some future point in time (based on block number).   So essentially if block_number > N then follow the new rules else follow the old rules.

And it would be released well in advance of block N occurring.  [Edit: i.e., two years, according to one core dev:

A hard fork like this would require the intentional support of a majority of merchants.
Short of an emergency, that means everyone will be given at least 2 years to upgrade.
1444  Bitcoin / Development & Technical Discussion / Re: How exactly do Transactions work in Bitcoin Network? on: March 13, 2013, 04:21:23 AM
Q #1. "A Bitcoin address is only a hash, so the sender can't provide a full public key in scriptPubKey."

Here, the sender is Bruce? Which "full public key" are we talking about here? The public key corresponding to the private key of Bruce? or the public key corresponding to Linda's private key?

Linda's pub key.

Bruce's client does not know Linda's public key.  Bruce knows Linda's Bitcoin address.

In the wiki article it reads "<pubKeyHash>".  I believe that can be used interchangeably with Bitcoin Address.    But it is not Public Key.
1445  Economy / Gambling / Re: bitZino - Provably Fair Bitcoin Casino - Blackjack, Roulette, Craps, Video Poker on: March 13, 2013, 04:09:58 AM
Our servers seem to be operating smoothly - our response times are withing the 100-200ms range, which is the

My first spin never ended (all three wheels). I waited maybe 60 seconds then hit reload, and it showed a loss.    Single line.

Then the next half dozen spins went fine.

Then I went three lines hit spin,   Left wheel stops, the right two wheels keep spinning.  More than 60 seconds.

I am on wi-fi with intermittent connectivity but not sure if that's the cause.   Chromium on Ubuntu Linux.
1446  Bitcoin / Project Development / Re: ICBIT Derivatives Market (USD/BTC futures trading) - LIVE on: March 13, 2013, 03:48:59 AM
Yeah, this maybe problematic. As the exchange grows (it's still very very small compared to e.g. MtGox), this problem would not be so important because of bigger quantity of bids/asks.

I just read about 1Broker closing its BTC/USD market:

A user successfully demonstrated the possibility to win constantly on our platform by moving the underlying market. This problem was known but thought to be not profitable because of position limits, market fees, and spreads.

ICBIT stands without much competition for selling Bitcoin short.
1447  Other / Beginners & Help / Re: importing private key from a blockchain wallet on: March 13, 2013, 02:44:02 AM
Already send him a pm 3 days ago and did send a support request too. still waiting for an answer.

Is this resolved?

Here's possibly what was happening:

1448  Other / Beginners & Help / Re: Campbx problem transferring bitcoin on: March 13, 2013, 02:30:12 AM
HAs anyone else dealt with this or do they have any advice?

Firstly, I would advise never associating coins from a service where it is commonly known that illegal trade occurs with an exchange that uses the banking system.   That's pretty much just asking for trouble.

I have no idea if that's why you are unable to access your "wallet" but that's just a suggestion.

campbx wallet is no longer there!

Are you saying that you now cannot log into your exchange account at Camp BX?

They are a hosted (shared) EWallet provider, so you as a customer don't have a wallet there.   You only are given a Bitcoin address in Camp BX's wallet.  When you send a payment to that address, Camp BX will increase your exchange account balance when that payment confirms.

If that is not happening, try to determine from them what the problem is.  If you don't even know what Bitcoin address you might ask them to let you know what deposit address(es) are for your account.

This is the problem with using hosted (shared) Ewallets.  You don't have control over your own coins.    You have to beg their support department for information to figure out what happened.

Incidentally,you might want to look into the new "shared" address method for receiving bitcoins to a wallet at -- which you can accessed via Tor even.
1449  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.
1450  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:

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:
1451  Economy / Service Discussion / Re: 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.

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.
1452  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.]
1453  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.

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.
1454  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.
1455  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.
1456  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:


Understanding why the call to rollback to v0.7 was made.
1457  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).
1458  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.

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


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.
1459  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.


From another thread:

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.


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:

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.
1460  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 and then you can see your current balance (and transact) from there.

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!