Bitcoin Forum
August 09, 2024, 12:48:26 AM *
News: Latest Bitcoin Core release: 27.1 [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 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 ... 160 »
501  Bitcoin / Bitcoin Discussion / Re: Bitcoin-Qt / bitcoind version 0.8.0 released on: February 19, 2013, 06:56:26 PM
Excellent!

A major thank you to all the devs for your continued hard work.
502  Economy / Economics / Re: Inflation and Deflation of Price and Money Supply on: February 19, 2013, 05:39:28 PM
when you think about how much they've stolen, yes ... pretty d@mn genius

LOL yeah looking at it that way, you're actually right  Cheesy Which is sad..  Angry
503  Economy / Economics / Re: Inflation and Deflation of Price and Money Supply on: February 19, 2013, 05:02:08 PM
While I despise them, I see the genius of the Federal Reserve system.

There's genius in stealing?  Roll Eyes
504  Bitcoin / Bitcoin Discussion / Re: The fork on: February 19, 2013, 05:01:11 PM
I'm fairly certain that Gavin and his supporters would not go ahead with the fork unless major services such as Gox, Blockchain.info, Coinbase, major pools etc were actually behind him. After that it really doesn't matter jack shit what the niche of resistance does. That other fork would be a super minority and dead fairly quickly.

I could easily see Bitcoin Foundation starting a major lobby campaign for support of the changes in the fork. They would most likely win a large majority behind them. Personally I'm in the latter camp as well, I want Bitcoin to be cheap and usable for $1 transactions. Having to pay a $20 fee to include a transaction to the blockchain is ridiculous.

Yeah and while we're at it we can change the block reward to 25 forever and get rid of fees entirely, then shorten the avg blocks per hour to 60, so no more long waiting times for confirmations...  Roll Eyes If you don't like Bitcoin, fork the source code and start your own cryptocurrency.
505  Economy / Speculation / Re: Wall Observer - MtGoxUSD wall movement tracker on: February 19, 2013, 04:38:54 PM

Thanks!
506  Economy / Speculation / Re: Wall Observer - MtGoxUSD wall movement tracker on: February 19, 2013, 04:32:43 PM
Another record in bid size.



This is crazy if u ask me.

What site is this char from?
507  Bitcoin / Bitcoin Discussion / Re: Should casual users avoid the Satoshi client? on: February 19, 2013, 04:28:30 PM
(because a hacked blockchain.info could feed you evil Javascript,...


Their browser addon eliminates that risk, no?
508  Bitcoin / Development & Technical Discussion / Re: How a floating blocksize limit inevitably leads towards centralization on: February 19, 2013, 04:27:18 PM
If you think that the block size should stay at 1 megabyte forever, then you're saying the network will never support more than 7 transactions per second, and each transaction will need to be for a fairly large number of bitcoins (otherwise transaction fees will eat up the value of the transaction).

If transactions are all pretty big, why the heck do we have 8 decimal places for the transaction amount?

Why not? They're 64-bit numbers, might as well give plenty of room for whatever the price turns out to be.

More to the point, if I'm correct and in the future we're paying miners billions of dollars a year, that implies Bitcoin is probably transfering trillions of dollars a year in value, on and off chain. In that scenario the market cap is probably tens of trillions of dollars worth, so 1BTC could easily be worth something like $10,000USD. Thus the $20 fee is 0.002BTC. That's pretty close to fees currently in terms of BTC - you might as well ask why do we have 8 decimal places now?

Not to mention off chain transaction service providers will need the accuracy of 8 decimal places or even more when they eventually have to push a sum of off chain transaction onto the chain.
509  Bitcoin / Bitcoin Discussion / Re: The fork on: February 19, 2013, 04:19:15 PM
What happens to Bitcoin if there is a hard fork and half go along while the other half refuse?

Actually, what happens to someone who holds bitcoins if there's a hard fork? Are they still valid on either one of the chains? On which one? Does the user get to decide?

All coins that ever existed prior to the fork can be spent on both forks. It's an economic disaster and would take a while before one or both forks recovered if at all.
510  Bitcoin / Development & Technical Discussion / Re: How a floating blocksize limit inevitably leads towards centralization on: February 19, 2013, 02:56:46 PM
I don't see how a hard fork is somehow not Bitcoin. It's simply an upgrade.

There are no backwards incompatible upgrades in Bitcoin, otherwise I wouldn't be here or have use for it.

As far as the hard fork goes didn't we have a couple of those last year anyway, such as multisig transactions?

Nope, all soft forks and backwards compatible - inherently different from a hard fork.
511  Bitcoin / Development & Technical Discussion / Re: How a floating blocksize limit inevitably leads towards centralization on: February 19, 2013, 02:42:45 PM
- snip -
I agree. I even think if ever a hard fork in Bitcoin should happen the new version should have a completely new name so that users who stay on the old version know they still use their Bitcoin and the users of the new version know that what they're using isn't Bitcoin anymore.

Who gets to decide which fork gets to claim to be "Bitcoin"?  If users of both forks decide they are the true "Bitcoin", how is the naming issue resolved?

Bitcoin will be what Bitcoin is right now. I didn't say the name of the new version will change or users of the new version will want it to change, they may well want it to stay Bitcoin, doesn't make it Bitcoin though and I don't think it should be called Bitcoin. But that is my opinion and it depends how much that matters.
512  Bitcoin / Development & Technical Discussion / Re: How a floating blocksize limit inevitably leads towards centralization on: February 19, 2013, 02:35:36 PM
So...  I start from "more transactions == more success"

I strongly feel that we shouldn't aim for Bitcoin topping out as a "high power money" system that can process only 7 transactions per second.

I agree with Stephen Pair-- THAT would be a highly centralized system.

Oh, sure, mining might be decentralized.  But who cares if you either have to be a gazillionaire to participate directly on the network as an ordinary transaction-creating customer, or have to have your transactions processed via some centralized, trusted, off-the-chain transaction processing service?

So, as I've said before:  we're running up against the artificial 250K block size limit now, I would like to see what happens. There are lots of moving pieces here, so I don't think ANYBODY really knows what will happen (maybe miners will collectively decide to keep the block size low, so they get more fees.  Maybe they will max it out to force out miners on slow networks.  Maybe they will keep it small so their blocks relay through slow connections faster (maybe there will be a significant fraction of mining power listening for new blocks behind tor, but blasting out new blocks not via tor)).


I think we should put users first. What do users want? They want low transaction fees and fast confirmations. Lets design for that case, because THE USERS are who ultimately give Bitcoin value.


you could never get away with a hard fork on this point so the best you could do is create an alternative cryptocurrency which you would then become the developer of instead of bitcoin. In this respect i say more power to you! lets get some healthy competition in the cryptocurrency market! (litecoin doesnt count as competition)

I agree. I even think if ever a hard fork in Bitcoin should happen the new version should have a completely new name so that users who stay on the old version know they still use their Bitcoin and the users of the new version know that what they're using isn't Bitcoin anymore.
513  Bitcoin / Bitcoin Discussion / Re: The fork on: February 19, 2013, 12:15:25 PM
As I understand it, Satoshi DID intend to increase the block size, and he intended to do it without a fork.

I think its worth remembering that Satoshi's view ought to get a certain amount of respect just because, he is Satoshi.

Fallacy: Appeal to authority.


It's completely irrelevant what Satoshi or anyone else thought how Bitcoin ought to work if it isn't based in a sound argument.
514  Bitcoin / Bitcoin Discussion / Re: The fork on: February 19, 2013, 12:10:30 PM
Does it matter what your point was? You spread manipulative framing, don't do it.

That's just silly. Of course it matters what the point was.

Notig was using Gavin's words to imply that Gavin had a certain intent.  The only way to point out that Gavin had a different intent was to point out what that different intent was.

Yes. Of course.

But instead of saying Gavin was responding to an argument that blocksize has to remain small forever for the sake of inefficient miners (as he framed it) you could have accurately said that he was responding to an argument that blocksize has to remain small forever for the sake of security and decentralization.

See the difference? It's subtle, but that's how manipulation usually is.
515  Bitcoin / Bitcoin Discussion / Re: The fork on: February 19, 2013, 11:45:06 AM
It's an argument over what ramifications for the security and the decentralization of Bitcoin removing the block size limit would have. Please don't spread Gavin's manipulative reframing. No one in that thread cares if less efficient miners can't "hack it", they all care what that would mean for Bitcoin. And if less efficient miners are part of what makes Bitcoin secure and decentralized then absolutely they need to be thought off when considering a hard fork type change of the protocol.
The point wasn't to spread manipulative framing.

Does it matter what your point was? You spread manipulative framing, don't do it.
516  Bitcoin / Bitcoin Discussion / Re: The fork on: February 19, 2013, 10:56:58 AM
The quotes you posted appear to be used as an argument against a particular reasoning that blocksize has to remain small forever for the sake of inefficient miners.

It's an argument over what ramifications for the security and the decentralization of Bitcoin removing the block size limit would have. Please don't spread Gavin's manipulative reframing. No one in that thread cares if less efficient miners can't "hack it", they all care what that would mean for Bitcoin. And if less efficient miners are part of what makes Bitcoin secure and decentralized then absolutely they need to be thought off when considering a hard fork type change of the protocol.
517  Economy / Economics / Re: Representational Monetary Identity on: February 19, 2013, 01:43:31 AM
If the bank loans out your money, even though they owe you that money, you thinking you have access to that money is an illusion, no matter how you slice it, period.

I went to my bank yesterday and made a withdrawal of almost all my balance. Was that an illusion, period?

I explained it to you that if every demand deposit account holder went and did the same the bank couldn't repay all of their IOUs and would go bust unless bailed out.

If you can't face facts I'm simply going to stop wasting my time explaining them to you.

Now you treat this IOU as if it's actual money because in the current system it behaves just like actual money, but it's not. It's debt and an illusion that in a market regulated strictly by consumption i.e. in a free market would not survive.

It is not my choice to treat this IOU as money: it is the only money around. If I don't treat it as money, then I will have no money to pay for things (at least while Bitcoin does not go mainstream).

False. You can use cash + a savings account.

What you are failing to understand is that even if I am eventually unable to withdraw my money, I am still entitled to do so

Says who? Certainly not your contract with the bank. Have you read the fine print?
518  Economy / Economics / Re: Representational Monetary Identity on: February 19, 2013, 12:22:28 AM
My U$ 1.000,00 can rather belong to the bank's excess reserves. Or, I can succeed in withdrawing them if I am quicker than you and benefit from the bank's 10% reserves. And even if there are no excess reserves and I am not quicker enough so the bank cannot give me my money, my U$ 1.000,00 still belong to me since it was the bank that loaned them, not me: I am not responsible for what my bank does, am I? The point is that the money created by loans must be money just as much as the money originally deposited (and in practice indistinguishable from it), otherwise the system cannot work. If you say deposit money is an illusion, then you are saying that loaned money is an illusion, and conversely.

Are you high?

If the bank loans out your money, even though they owe you that money, you thinking you have access to that money is an illusion, no matter how you slice it, period. The $1000 you deposited are not with the bank anymore and have moved into someone else's pocket (the borrower). What you actually have with the bank is an IOU for $1000 that you hold and the bank is a counterparty to.

Now you treat this IOU as if it's actual money because in the current system it behaves just like actual money, but it's not. It's debt and an illusion that in a market regulated strictly by consumption i.e. in a free market would not survive.


And these are the facts, no matter what you think depositing $1000 into a demand deposit account entitles you to.

Quote
I am not responsible for what my bank does, am I?

Under the current system with the FDIC and FED you have the illusion of no responsibility because you are protected by them and can count on always getting your IOU repaid which is the huge problem banking has today. But that doesn't mean you aren't actually holding an IOU when depositing into a demand deposit account and that you aren't personally responsible to pick a bank that will prudently loan out your money and keep a prudent reserve ratio. You are, read your contract with the bank, it tells you are when they tell you that under certain circumstances you wont get your money on demand.
519  Bitcoin / Development & Technical Discussion / Re: How a floating blocksize limit inevitably leads towards centralization on: February 18, 2013, 11:38:38 PM
I feel these debates have been going on for years. We just have wildly different ideas of what is affordable or not.

I don't think the most fundamental debate is about how high the limit should be. I made some estimates about how high it would have to be for worldwide usage, which is quite a wild guess, and I suppose any estimation about what is achievable with either today's or tomorrow's technology is also a wild guess. We can only hope that what is needed and what is possible will somehow continue to match.

But the most fundamental debate is about whether it is dangerous to (effectively) disable the limit. These are some ways to effectively disable the limit:
  • actually disabling it
  • making it "auto-adjusting" (so it can increase indefinitely)
  • making it so high that it won't ever be reached

I think the current limit will have to be increased at some point in time, requiring a "fork". I can imagine you don't want to set the new value too low, because that would make you have to do another fork in the future. Since it's hard to know what's the right value, I can imagine you want to develop an "auto-adjusting" system, similar to how the difficulty is "auto-adjusting". However, if you don't do this extremely carefully, you could end up effectively disabling the limit, with all the potential dangers discussed here.

You have to carefully choose the goal you want to achieve with the "auto-adjusting", and you have to carefully choose the way you measure your "goal variable", so that your system can control it towards the desired value (similar to how difficulty adjustments steers towards 10minutes/block).

One "goal variable" would be the number of independent miners (a measure of decentralization). How to measure it? Maybe you can offer miners a reward for being "non-independent"? If they accept that reward, they prove non-independence of their different mining activities (e.g. different blocks mined by them); the reward should be larger than the profits they could get from further centralizing Bitcoin. This is just a vague idea; naturally it should be thought out extremely carefully before even thinking of implementing this.


Of all the posts this one makes the most sense to me - a layman. This I'm aware means practically nothing aside from me not being willing to download a new version of Bitcoin-Qt if I wont like the hard fork rules. A carefully chosen auto-adjusting block size limit that makes the space scarce and encourages fees keeping mining reasonable open to competition while solving the scalability issue seems like a good compromise.

But how many of all transactions should on average fit into a block? 90%? 80%? 50%? Can anyone come up with some predictions and estimates how various auto-adjusting rules could potentially play out?
520  Bitcoin / Development & Technical Discussion / Re: How a floating blocksize limit inevitably leads towards centralization on: February 18, 2013, 11:17:32 PM
Network assurance contracts are far from a sure thing. It's basically an attempt to solve the tragedy of the commons, and the success rate society has had there is pitiful, even with strong central authorities. Assuming they will work is a big risk.

Sure, there is some risk, but Kickstarter is showing that the general concept can indeed fund public goods.

Off topic:
It's interesting you say that, I'm guessing you don't think there was a need for a Bitcoin Foundation then do you?
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 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 ... 160 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!