Bitcoin Forum
June 21, 2018, 10:44:40 AM *
News: Latest stable version of Bitcoin Core: 0.16.1  [Torrent]. (New!)
  Home Help Search Donate Login Register  
  Show Posts
Pages: « 1 ... 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 126 127 128 129 130 131 132 133 134 135 136 137 ... 464 »
1721  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.
1722  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.
1723  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:

1724  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.
1725  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.
1726  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:
1727  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.
1728  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.]
1729  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.
1730  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.
1731  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.
1732  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.
1733  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).
1734  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.
1735  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.
1736  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.

1737  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 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.
1738  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).
1739  Other / Beginners & Help / Re: Continuity of support on: March 12, 2013, 09:38:21 PM
Just like there is a 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 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:

1740  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?
Pages: « 1 ... 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 126 127 128 129 130 131 132 133 134 135 136 137 ... 464 »
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!