Bitcoin Forum
May 25, 2024, 04:07:03 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 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 »
681  Bitcoin / Bitcoin Discussion / Re: [FORBES] The Bitcoin Crash - New Article, Forbes Claim is Doom on: August 08, 2011, 01:57:45 PM
Quote
The puzzling thing about Bitcoin, which I pointed out back in April, is that the currency doesn’t seem to have any fundamental value at all.
This statement is nonsense.  A bitcoin itself might not have any intrinsic value, but the bitcoin platform has plenty of fundamental value.  The author is dead wrong on this point.  The issues will get resolved in time, effective defenses against theft will be crafted, and bitcoin will survive.
682  Bitcoin / Development & Technical Discussion / Re: Multiple bitcoind on one machine on: August 07, 2011, 12:51:11 PM
The overhead can be stupendous though.

You mean as in ram usage or are you talking about something else?

i was able to get 2 running successfully for a while on a test server.

I wonder what the record is for the most amount of bitcoind instances running together successfully... anyone running 3 or more?


I've run as many as 6 on a machine...two that are on a private local testnet...one that is on a prive testnet between several machines, one on the public test net and another couple on the real net.  Works fine, albeit the machine can get a little sluggish.  I do typically run 2 to 4 (2 on a private local testnet, one no a shared private testnet, and one on the real net).
683  Bitcoin / Bitcoin Discussion / Re: Why is BTC in the toilet right now? on: August 07, 2011, 12:45:22 PM
This talk of parity is silly.  It's meaningless.  We could all agree tomorrow to shift the decimal place 1 position and the price of bitcoin would be back below $1.  The kind of parity I'm interested in is when the value of all bitcoin in existence matches or exceeds the total value of some other currency in existence.  Bitcoin has a long way to go.
684  Bitcoin / Development & Technical Discussion / Re: BitCoin Deanonymization on: August 07, 2011, 12:33:12 PM
It would be a good idea for the client to enter safe mode when it sees a deep reorg, but it still must switch chains. Otherwise the network can become permanently segmented, and an attacker that gets control for some time can keep control much more easily. Keep in mind that it is not impossibly expensive to take control of the network for several weeks.
I don't understand this argument...if an attacker successfully generated a few blocks in succession, one of their blocks would indeed become old enough that it is permanently embedded...but so what?  Even if the attacker had 70 or 80% of the processing power, they could only force reorgs say 6 blocks deep...or ~1 hour into the past...and blocks from other miners would still beat out the attacker on occasion (rendering ineffective an attack where legitimate transactions were being ignored).  If this was pervasively happening for some period of time, people could simply start waiting a full 6 (assuming 6 is the point where reorgs are only allowed manually) transactions when dealing with untrusted people (but you could still safely accept transactions immediately when dealing with a counterparty that is trusted).
685  Bitcoin / Development & Technical Discussion / Re: BitCoin Deanonymization on: August 07, 2011, 05:24:38 AM
The longest reorg I'm aware of was 25 blocks. Someone correct me if I missed one.
The one after the overflow bug was 54 blocks. If all old clients had ignored the longer chain because the split was too far back, then lots of damage could have been done by the attacker.

I'm not sure that is a good argument here.

While the current reorg logic was certainly a boon in that situation, and future situations like it are easy to imagine, we should recognize that we are overloading that operation to do something that it wasn't intended to do.

Maybe we should think of a proper mechanism to deal with nodes that are known to have critical bugs, and allow the block chain logic to concentrate on protecting the chain.
I'm not familiar with what happened with that bug...but in such a circumstance, couldn't you issue an update to the client that fixed the bug as well as fixated on the known good chain?  You then have to convince everyone to start running that new version of the client (and other clients would need updating as well).  But in the case of a serious bug, that has to happen anyway.  To me, there doesn't seem to be any legitimate reason to allow deep reorgs to happen.  About the only thing I could think of is when a large section of the network is cutoff for an extended period of time, but how likely is that to happen?  And if it did, isn't some manual intervention a good idea anyway (you could have features in the client that let you see when there are other chains that would cause a deep reorg and let the user choose to take it or not)?
686  Bitcoin / Development & Technical Discussion / Re: BitCoin Deanonymization on: August 07, 2011, 01:53:16 AM
The 50% mark is not really a tipping point, as you can still get left behind in many potential attacks.  Percentage of network power just means are you ever-more-likely to be able to double-spend while waiting with a chain of length X in the background.  The attack is still very, very difficult and reliant upon probability even at 60%, 70%, etc.
Yeah, but what makes me nervous is that someone with that kind of power could lay in wait for an indefinite period of time...spending whatever it takes to remain substantially ahead of the network...waiting for the most opportune time to reveal themselves and completely undermine bitcoin.
That is one of the reasons why the Satoshi Client includes hardcoded block chain checkpoints.
That is a simple, practical solution that effectively accomplishes the same result.  What about doing something less manual and less sporadic though?  I've often wondered whether it would make sense to simply not allow reorgs beyond a certain depth at all (which is practically speaking what the exponentially more difficult reorg proposal does).  If you happen to get stuck on a dead branch, you would need to take manual steps to force your client to recognize the chain that the rest of the network recognizes.  Most normal splits/reorgs occur when a couple blocks are generated at nearly the same time.  If the network is well maintained and clients have a handful of well connected nodes they can reliably connect with (and those are well connected to each other), it should be an extremely remote situation where a reorg goes more than a couple blocks deep.  I wonder if you could even be as aggressive as not allowing any reorg of more than 6 blocks deep.
687  Bitcoin / Bitcoin Discussion / Re: Why is BTC in the toilet right now? on: August 06, 2011, 05:56:16 PM
Look at the bright side...maybe we won't need to shift the decimal place as soon as we thought.  And if it collapses, we can always burn our worthless bitcoin to heat our homes in the winter (oh wait, nm...I guess fiat currency does have some intrinsic value after all).

Grin
688  Bitcoin / Development & Technical Discussion / Re: BitCoin Deanonymization on: August 06, 2011, 01:10:35 AM
The 50% mark is not really a tipping point, as you can still get left behind in many potential attacks.  Percentage of network power just means are you ever-more-likely to be able to double-spend while waiting with a chain of length X in the background.  The attack is still very, very difficult and reliant upon probability even at 60%, 70%, etc.
Yeah, but what makes me nervous is that someone with that kind of power could lay in wait for an indefinite period of time...spending whatever it takes to remain substantially ahead of the network...waiting for the most opportune time to reveal themselves and completely undermine bitcoin.
689  Bitcoin / Bitcoin Discussion / Re: Is the rapid drop in bitcoin value because there are more miners than buyers? on: August 05, 2011, 08:07:50 PM
Keep in mind, the annualized inflation rate of bitcoin is ~37.6% at the moment.  If the price holds steady it means that there is enough new demand to keep up with this pace of inflation.  To me, it seems quite natural that the variance in demand relative to the rate of inflation in such a small market is bound to create substantial volatility in both directions.  People should be more surprised that the price stuck at around $14 or $15 for so long.  

The absolute number of miners has nothing to do with it...the question is simply to what degree the net demand is increasing in relation to the supply.  A miner that sells all of their generated bitcoins are reducing net demand (just like anyone else selling bitcoins) while a miner that holds all of their generated bitcoins and increasing net demand (just like anyone else buying bitcoins).

The breaches, the hacks, and the fading media attention are probably all contributing to a lull in demand at the moment.
690  Bitcoin / Development & Technical Discussion / Re: BitCoin Deanonymization on: August 05, 2011, 06:01:38 PM
And yes, resolving a permanent split would require human intervention.  Essentially, the minority network would be forced to discard all blocks since the split if they wanted to rejoin the global network.  Personally, I think the potential cost to individual miners and nodes is a small price to pay to protect the network as a whole.
Agreed.
691  Bitcoin / Development & Technical Discussion / Re: Dan Kaminskys thoughts on scalability on: August 05, 2011, 05:52:37 PM
I agree with the OP's analysis.  I would further add that should a scalability limitation prove practically insurmountable (or practically insurmountable in relatively short time frame) you always have the possibility of off block chain transactions backed by bitcoin.  And these off block chain transactions don't have to utilize database account entries (which we know are all too vulnerable).  They could instead use privately issued block chains.  These would introduce new coins when real bitcoins are deposited and destroy coins when they are redeemed.  A central authority would be issuing the blocks for such chains (and wouldn't require the distributed proof of work...instead you rely on the central authority to ensure the chain is secure).  Such chains would be inherently less trustworthy than the bitcoin chain, but would also be less costly to administer and address both scaling and transaction cost issues.  For day to day purchases and micro transactions, I think such private chains would work quite well and no one would have to trust them with very much money for very long periods of time (they could settle on the public bitcoin block chain once a day or even hourly).
692  Bitcoin / Development & Technical Discussion / Re: BitCoin Deanonymization on: August 05, 2011, 05:37:32 PM
The other attack is the offline attack, where the attacker does not publish his blocks until his chain is at least X blocks longer than the public chain.  In this attack, 51% is indeed a tipping point, because once he reaches 51% he is assured that if he waits long enough, he will eventually have enough blocks saved up to perform the chain reversion.
But this attack is so easy to detect that it makes no sense to try it.

You mean like everyone would notice if 7 blocks get swapped all at once?  Yeah, we would notice, but they would be the correct chain then, so what would we do about it?

Sell their bitcoins!!!

Quote from: kjj
This attack can be countered by changing the calculation for deciding which chain is valid.  An exponential function would solve the problem.
Interesting idea.  IIUC, this makes it such that the deeper the reorg, the higher the barrier for it to be accepted.  Which means that you effectively force the >51% attacker out into the open (they have to publish their blocks or their private chain will quickly become virtually impossible to get accepted) and basically force them to periodically build off of other's blocks...and you effectively require miners (and all nodes really) to take steps to ensure blocks get widely distributed.  However, if there is a temporary split in the network, doesn't this run the risk of a temporary split becoming permanent?  I suppose you could come up with a non technical means of resolving such a split should it ever occur...it might be an acceptable trade off considering that this proposal might have a huge benefit (in the sense that it would severely inhibit the damage that could be done by a miner with >50% could do).
693  Bitcoin / Bitcoin Discussion / Re: Three New Merchants are now up-and-running with Bit-Pay on: August 04, 2011, 01:02:48 PM
Great. I like the new logo Smiley

Thanks...forum member evoorhees designed it for us and is great to work with.  If you need any logo or copy writing work done, check with him (and at least for us, he accepted payment in bitcoin).
694  Bitcoin / Bitcoin Discussion / Re: [UABCI] September 27, 2011 U.S. Department of the Treasury to regulate BitCoin on: August 03, 2011, 02:22:12 PM
According to this new ruling, companies, organizations as well as individuals must register in order to legally transact with any parties, providing quite privacy invasive contact information on each individual transacted with as well as keep those records for 5 years.

What do you think would be a good way to insure that this ruling does not apply to Bitcoin?

The use of bitcoin is an exercise of free speech and as such is protected by the 1st amendment to the US constitution.  Any law that would interfere with the use of bitcoin is in direct contradiction to this amendment.
695  Bitcoin / Bitcoin Discussion / Re: Trust issues. on: August 03, 2011, 02:17:06 PM
Good post Vladimir.  I only recommend the official client to be used for storing substantial quantities of bitcoin (Instawallet or others are good if you need a little spending money for a few days and you need to use a cell phone, but no more than a few bitcoins).  If you are not technical enough to use the official client properly, then either you shouldn't be saving substantial amounts of bitcoins (you need to wait until the clients are more robust), or you should find someone you personally trust to use or help you use the official bitcoin client (and you need to not only trust that person's character, you also need to trust their skills).
696  Bitcoin / Project Development / [WANTED] OpenCart & PHP Developer on: August 01, 2011, 07:38:02 PM
I am seeking someone to implement an OpenCart plugin to interface with Bit-Pay.com.  If you know OpenCart and PHP (which is the language OpenCart is written in) and are interested helping us with this, please send me a private message.
697  Bitcoin / Bitcoin Discussion / Re: How I would EMBRACE Bitcoin if I was a goverment on: August 01, 2011, 01:48:24 PM
I think bitcoin offers numerous benefits to governments (as well as banks and other companies).  As a result, I do forsee a day when some governments and established companies actually begin running mining farms for the express purpose of securing the network.
698  Economy / Economics / Re: Silver undervalued or gold overvalued? on: August 01, 2011, 01:02:47 AM
I'm surprised that no one has mentioned that silver has been in backwardation for months.  That suggests physical silver is in tight supply.
699  Bitcoin / Bitcoin Discussion / Re: What's a better investment currently. Bitcoins or Mining Equipment? on: July 31, 2011, 08:15:06 PM
How many people here would put thousands of dollars into mining equipment vs bitcoins?

If you think bitcoins will rise in value, both are good investments, but I would like to hear the debate between the 2 separate camps.

It's not really a good question.  The choice comes down to what you think the price of bitcoins is likely to do and what your risk tolerance is (one question is pure speculation and the other very individual).  Mining is lower risk because your capital equipment has resale value, but the profitability of mining (particularly right now) is pretty low.  Buying bitcoin outright carries a far higher risk.  If you think the price of bitcoin is going to rise quickly in the near term and you can tolerate the risk, you're better off just buying bitcoins.  If you think the price is going to hold steady or rise moderately for a long while, you may be better off mining.  If you think the price is going to steadily decline, don't buy or mine (unless you can buy some mining hardware on the cheap due to other selling out).  If you think the price is about to collapse, sell all your bitcoins and mining equipment fast!

When you do the calculations for mining, make sure you're doing your accounting as if you sell every last bitcoin mined as it is mined (even if you intend to keep some or all of your mined bitcons).  The reason is that when you hold them, you are now investing directly in bitcoin and speculating on the future value.  You don't need mining equipment for that, you could more easily just buy the bitcoins you would have mined.
700  Bitcoin / Bitcoin Discussion / Re: Feature Request for Exchanges on: July 31, 2011, 08:01:17 PM
I don't think they can as the quote could be invalid as soon as you see it.

Example: Buy $100 worth of bitcoins at $13 ...if the trade fee is 1%, then the amount of bitcoins for the order would be $99/$13 or 7.6153 bitcoins (truncated to 4 decimal places).  If the current low ask is $14, the then order is placed as "buy 7.6153 bitcoins @$13" ...if the current low ask is $12 and can cover my entire order, then it will execute a trade immediately, buying $100 worth of bitcoins (or $99/$12 = 8.2500 bitcoins).

This is by far the most common trade I do.  I rarely sell bitcoins on the exchanges (instead, I like to spend or save them to spend later).  And when I buy, it's usually for the entire amount that I have on deposit with the exchange (because I have no desire to keep a balance of anything (BTC or USD) in the exchanges).
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 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 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!