Bitcoin Forum
June 21, 2024, 08:42:15 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 [256] 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 ... 384 »
5101  Bitcoin / Development & Technical Discussion / Re: How a floating blocksize limit inevitably leads towards centralization on: February 19, 2013, 10:15:52 PM
Okay then, lets for the sake of argument imagine you are correct that 10,000 nodes is sufficient decentralisation.

1,000,000 bytes divided by 10,000 nodes is 100 bytes per block per node.

Multiply by 144 blocks per day and you get 14400 bytes per node per day.

If transactions were one byte each that would be enough for each node to send one settlement to each of the other nodes per day and still have 4,399 bytes to spare. Unfortunately transactions are what, some 400 or so bytes each on average? But, settling up only requires one of the nodes of each pair of nodes to send coins: the one that owes some to the other.

If all the nodes needed to settle every day, it seems from this very sketchy back of an envelope approximation that they would need about 200 times the block size we currently have. 200+ megabytes per block

Maybe if we can get 10,000 full bitcoin nodes to also run Ripple we can start to see how often they actually do tend to need to settle up with each other. It actually, surprisingly, seems quite a surprise to realise that the core backbone of full nodes obviously is not actually settling up pairwise between all of them every day already. Are my numbers way way off? As it seems from this guestimation that only about one in a hundred of the combinatorial pairs of full nodes is settling up on any given day even if we assume no transaction other than such settlements hit the blockchain. Since we also hear that Satoshi Dice is maybe the biggest user of the blockchain apparently it must be quite a bit less than one day in a hundred that a full node actually settles up with another full node at this time. So maybe we can figure typical full nodes settle up about once per quarter of a year?

The more traffic Ripple can cause to not require immediate settlement on the blockchain the longer 10,000 full nodes should be able to continue to settle up at the same rate they currently are, and if Satoshi Dice also moved off the blockchain, settling with each gambler's full node of choice quarterly too, we'd continue to have plenty of space on the blockchain unless/until far more full nodes sprang up, each wanting to settle with all other full nodes at the same rate full nodes settle up currently.

Yeah I know that is not realistic. But it seems to give some insight into the numbers, at least to me. Full nodes seemingly are not settling up even as often as quarterly right now, why is that? Is it that actually there are only about 10,000 individual users actively transacting currently at any one time / on any given hour or during any given day or something like that?

-MarkM-
5102  Bitcoin / Development & Technical Discussion / Re: artificial 250kB limit? on: February 19, 2013, 09:11:15 PM
So the current one megabyte hard limit is already double the limit Satoshi originally put in place?

-MarkM-
5103  Bitcoin / Bitcoin Discussion / Re: The fork on: February 19, 2013, 09:07:33 PM
I can understand how needing greater bandwidth can cut off a minority of miners.. but how can it concentrate it into the hands off just the few? If you look at bandwidth usage statistics aren't a majority of the people that mine bitcoin currently considered high bandwidth already? Therefore this "centralization" simply means into the hands of what already is a majority which should theoretically get even more dispersed the more high bandwidth connections are available right? Or is some extremely powerful bandwidth connection able to eliminate "normal" high bandwidth users?  
So your biggest fear is that alternative solutions to the block size limit won't be made? In other words what the other guy mentioned bitcoin clearing houses? How does that help decentralization?

Read up on "high frequency trading".

What you are thinking of as "high bandwidth" is godawfully slow compared to, say, a composite cable less than half a mile long of parallel optic fibres, or whatever the currently state of the art fastests fattest most-direct short-hop direct link is. Basically it could become infeasible to mine anywhere else than in the mining district of the mining colony in the arctic or in antarctica, with the final showdown being between those two (or actual best, since they might not have cheap power to go along with cheap cooling, so maybe Iceland as the "artic" one), with only one pole being able to win since the other is too far away to compete with it. Maybe a see-saw between them as each increases hashing-power to try to make its hemisphere the world's mining capital instead of the other hemisphere...

-MarkM-
5104  Bitcoin / Bitcoin Discussion / Re: The fork on: February 19, 2013, 08:50:43 PM
In before someone says p2p means peer to peer not person to person:

I suspect grassroots peer to peer networks' concept of a peer is more akin to peers as in "a jury of your peers" than to "peers as in members of the House of Lords". Pick any twelve people on the internet at random, and try to ensure the vast majority of any such picks will result in almost all of them being qualified as in having easily enough computer and network at home to run the thing.

-MarkM-
5105  Bitcoin / Development & Technical Discussion / Re: How a floating blocksize limit inevitably leads towards centralization on: February 19, 2013, 08:42:28 PM
Ripple is out of closed beta too, maybe it can take a lot of the load off the blockchain. A lot of users use online wallets too, those have internal transfers too.

-MarkM-


you bring up a really good point. With ripple we can do off blockchain transactions with out the negative effects of centralization.

We can also maybe refer to Ripple as a Business to Business network from the outset rather than as a Person to Person network, since it seems designed and intended from the outset to be B2B oriented rather than P2P oriented.

-MarkM-
5106  Bitcoin / Bitcoin Discussion / Re: The fork on: February 19, 2013, 08:30:11 PM
Otherwise the basic plan seem to be to pull a bait-and-switch, selling people on a purportedly person to person grassroots currency then pulling the rug out from under them by migrating it to business-to-business then to megacorp-to-megacorp...

Well put.  Bank of America, Wells Fargo, et al. already provide me with an expensive and restrictive form of money transfer.  Their services come with perks too, like insurance and customer service.

Yes, but, the alternative might have to be an expensive but not restricted (by KYC, privacy invasion, AML, what you are allowed to buy, who you are allowed to buy it from, which nationalities, races or creeds you can or cannot do business with etc etc etc) form of value transfer (bitcoin with block limits that keep it reasonable to run a full node at home), and/or a whole bunch of such forms so that each individual form fits easily on home computers and maybe even some home computers can merged-mine many of the forms at once like I still do right now.

(
Imagine: Pay with: BTC (highest fee), NMC (lower fee, popular with domain speculators), IXC (lower fee, lower security)...
or
Imagine: Pay with <greyed out>BTC: not applicable (cart's total is too low for high-value network), NMC (highest fee network handling such low value transactions), IXC (lower fee, lower security)..
etc
Or even  BTC: pay whole coin, change tendered in NMC or IXC, etc...
)

-MarkM-
5107  Bitcoin / Development & Technical Discussion / Re: How a floating blocksize limit inevitably leads towards centralization on: February 19, 2013, 08:18:45 PM
I suspect we could double the block size without massive disruption, but once you start where does it end?

Doubling the liimit might well just prove it is going to give way at every push or shove, leading it it being pushed and shoved way up beyond any reasonable person-to-person network's personal computer's ability to actually operate as a node on a personal internet connection.

It will become a business to business or even backbone to backbone network, making the whole p2p premise just a bait-and-switch trick used to con people into doing the initial investment and work to get the elite's new elite billionaire-to-billionaire-network up and running initially and suck people in to the early adoption phase of it.

-MarkM-
5108  Bitcoin / Bitcoin Discussion / Re: The fork on: February 19, 2013, 07:58:29 PM
I expect that to a lot of people bitcoin being a "person to person" (p2p) currency is a major part of the "contract" they feel they entered into when choosing it rather than, say, Paypal or Visa or whatever alternative type of system for transferring value online.

So maybe we need to move to a DIstributed Hash Table (DHT) based system or something of that kind, that lets these ordinary people running nodes of a p2p financial network connecting them directly with various friends and family and other participants in the network do it without needing the whole blockchain?

Maybe we could even move the work into buckets grouping transactions into hash-bucket groups to form one block per hash-bucket or something if one cannot actually divvy up all the blockchain DHT style or RAID style effectively?

Otherwise the basic plan seem to be to pull a bait-and-switch, selling people on a purportedly person to person grassroots currency then pulling the rug out from under them by migrating it to business-to-business then to megacorp-to-megacorp...

For it to be a p2p network, I think we need to do something like look at the median, mode or mean home computer on the median, mode or mean home internet connection and ensure our limits keep it reasonable for folks to run full nodes on such systems without sacrificing their ability to run their accounting software and their word processor and their browser at the same time...

(Notice I do not say also stream a movie or even also listen to internet radio; I am content that they use their television and/or radio for that stuff. Heck let them use a telephone for voice chat too.)

-MarkM-
5109  Bitcoin / Development & Technical Discussion / Re: How a floating blocksize limit inevitably leads towards centralization on: February 19, 2013, 07:39:07 PM
Ripple is out of closed beta too, maybe it can take a lot of the load off the blockchain. A lot of users use online wallets too, those have internal transfers too.

-MarkM-
5110  Bitcoin / Bitcoin Discussion / Re: The fork on: February 19, 2013, 07:27:08 PM
Basically it seems to me that no cap on block size simply creates a new avenue of attack, akin to the 51% hash-power attack.

It is a "X% bandwidth" attack maybe, which does not even require 51% hashing power to pull it off.

A few actors on the scale of Google, Microsoft, the NSA, CIA etc could bypass all our vaunted largest hashing power in the world defenses with just a fraction of the hashing power we have simply by pumping out maximum sized blocks themselves whenever they do happen to find a block, so if there is no max size that would mean unlimited size, which in turn might mean whatever size such actors can manage to transmit to each other inside of ten minutes, or heck maybe within five minutes since doubling their cartel-member to cartel-member direct transfer rate is probably easy for them. Look at how high frequency traders sped up their communications with stock exchanges for example. Move all your mining to the mining capital of the world, pump out multi-terrabyte blocks and anyone who cannot verify them inside of ten minutes cannot even tell whether they are valid so are irrelevant to "consensus" as they aren't even able to make an informed judgement of validity.

I see two extremes possible at least: one is a high value high fee currency for the elite, implemented at a grass roots level so the non-elite can earn by running the elite's network just as it can earn by mowing their lawns, washing their dishes and so on, or a low value aka micropayments system only the elite can afford to run, providing them with micropayment ability so they can nickel and dime every last nickel and dime from the masses by selling them stuff so worthless that it isn't even worth sending by UPS or FedEx, stuff which therefore is so darn cheap it could probably be paid for by displaying ads instead of charging the consumers anything for it at all. (Stuff cheap enough to use as "loss leaders" to get to show people stuff worth real money as in enough money to maybe be worth recording the sale in the blockchain.)

Those two extremes amount to "everyone can easily run a full node but fees are too high to allow trivial transactions" and "only massive players can run a full node but every peasant's every cup of chicken-feed can be recorded in the global public ledger".

-MarkM-
5111  Bitcoin / Development & Technical Discussion / Re: How a floating blocksize limit inevitably leads towards centralization on: February 19, 2013, 07:05:01 PM
Once ASIC production gets down pat, churning out chips whose research and setup costs have long been covered, and so many are in use that they are only borderline profitable and even then maybe only in places where electricity is dirt cheap and/or the heat produced is needed or recycled back into more electricity what level of difficulty will be be looking at?

A megabyte per decimal-digit of difficulty would already be seven megabytes right now, since difficulty hit 1,000,000. I am not sure offhand how many leading zeroes that is in the binary version that is actually used by the code.

But fundamentally we just cannot really know what the future needs will look like, which is why I still favour going through this whole should we shouldn't we and the whole is everyone on board for this hard-fork process each time it starts to seem to some as if the limit does need to be raised.

How long is that process likely to take? We seem to have oodles of spare space currently, if we take our time about maybe adding a whole 'nother megabyte we still might find we have more than enough space by the time it even comes into effect.

I have even read here and there claims it is mostly Satoshi Dice that has made block sizes climb enough to notice much, if that is so I'd say we should correct the failure to discourage such frivolous waste first before considering increasing the block size.

Since I last wrote, bitcoin price has risen significantly again, so it is clearer by the hour that the block size limit is not discouraging use / driving away adoption enough to hit us in the pocketbooks, if at all. Maybe the people inventing in the dram of $10,000 per bitcoin actually like the idea that transaction fees will be high enough to ensure each and every one of their coins is safer than houses.


-MarkM-
5112  Bitcoin / Bitcoin Discussion / Re: The fork on: February 19, 2013, 05:49:17 PM
Doing a "hard fork" is hard, but maybe better than putting in some automatic adjustment that someone could end up "gaming".

If each time the limit is to be raised another megabyte, or each time it is to be doubled, the whole "hard fork" thing has to be gone through again that might provide some security at least until the developers get the hard fork techniques down to a point where it becomes pretty much just a "rubber stamp" that goes along with whatever change they decide to make next.

Clearly blocks are plenty big enough currently, maybe even too big, since we are clearly not losing per bitcoin price/value due to high transaction fees nor are we even managing to discourage "frivolous" transactions (like "sorry, you lost, please try again" type messages which probably belong in IM or some other kind of chat system not in the world's permanent global ledger of the world's most important, most highly secured value storage system).

If the fees are not high enough to discourage every penny-ante gambler from yelling to the world about each and every few-penny bet they lose then the fees are probably too low.

-MarkM-
5113  Bitcoin / Development & Technical Discussion / Re: How a floating blocksize limit inevitably leads towards centralization on: February 19, 2013, 04:27:11 PM
Maybe we could start off with a really conservative schedule of increases, like every time the mining rate halves the maximum block size must at least double?

That would give as an already-overdue doubling from last year's halving of minting, and provide that we will double the size again in less than four years if it isn't at least 4 megabytes by then.

That would give us an as soon as we can reasonably get it done doubling along with a few years in which to argue about whether we can survive until the next halving of the minting or will have to do an emergeny increase before then?

Meanwhile we can also start propagandising more the idea that bitcoins ought rightfully be worth thousands of dollars each, that it is kind of frivolous to use it for transactions of less value than that, and there are plenty of merged mined chains to choose from to start stabilising some other coin's value at some lower value per coin for smaller transactions...

-MarkM-
5114  Bitcoin / Development & Technical Discussion / Re: How a floating blocksize limit inevitably leads towards centralization on: February 19, 2013, 03:25:34 PM
Here's an idea: Reject blocks larger than 1 megabyte that do not include a total reward (subsidy+fees) of at least 50 BTC per megabyte.

"But miners can just include a never broadcast, fee-only transactions to jack up the fees in the block!"

Yes... but if their block gets orphaned then they'll lose those "fake fees" to another miner. I would guess that the incentive to try to push low-bandwidth/CPU miners out of the network would be overwhelmed by the disincentive of losing lots of BTC if you got orphaned.

That might work, but it is probably worth while not to un-cap the size limit, just raise it to something that wouldn't cause problems if someone *did* choose to blow a few hundred or thousand bitcoins on blowing up the network. Someone who hacked half a million coins some years back could easily be out there who'd love to blow up the whole shebang for just a few tens of thousands of coins...

-MarkM-

EDIT: As to eight decimals, it provides price granularity, so your transactions of at least one whole bitcoin have plenty of granularty for representing many different fractions of prime or almost-prime larger numbers. It need not mean transactions of less than a whole coin are to be encouraged.
5115  Bitcoin / Development & Technical Discussion / Re: How a floating blocksize limit inevitably leads towards centralization on: February 19, 2013, 03:16:59 PM
They are going to refuse to "relay" things that got into the highest difficulty blockchain?

I thought relaying only meant passing around the stuff that is not yet in the blockchain?

Miners mining blocks can pass them directly to all major pools probably without any "relaying".

-MarkM-


5116  Bitcoin / Development & Technical Discussion / Re: How a floating blocksize limit inevitably leads towards centralization on: February 19, 2013, 03:02:49 PM
I thought one of the main points being brought up is that on the contrary it allows Joe Superminer to progressively drive more and more competitors off the net until he and he along controls all the mining. (Presumably pretending to be more than one mining operation, of course, to keep people from noticing he has become the sole arbiter of the network.)
Did you read the proposal? The decision about how large blocks can be rests with the nodes which relay blocks, not the miners.

If Joe Superminer controls enough of the hashing power and the p2p network to force a change through he could ruin the network today, with or without any change to the protocol.

I thought I had read it. We are here dissing or discussing the fact the clients would float the limit, aren't we?

If the limit can float, who controls the things it takes into account in determining whether to float and how much to float? What is it looking at to make the decision, that is not controlled by miners?

-MarkM-
5117  Bitcoin / Development & Technical Discussion / Re: How a floating blocksize limit inevitably leads towards centralization on: February 19, 2013, 02:53:04 PM
What exactly is wrong with this proposal, that justifies all this drama?

https://bitcointalk.org/index.php?topic=140233.msg1503099#msg1503099

That proposal does not force miners to increase the size of their blocks, or include any transactions they don't want to include.

It does not force any node to relay or store blocks they don't want to.

It allows the maximum block size to be determined by distributed consensus instead of centrally managed by fiat. That's the exact opposite of what people are complaining about, and the solution of leaving the limit in place is the problem they claim to want to avoid.

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

I thought one of the main points being brought up is that on the contrary it allows Joe Superminer to progressively drive more and more competitors off the net until he and he alone controls all the mining. (Presumably pretending to be more than one mining operation, of course, to keep people from noticing he has become the sole arbiter of the network.)

-MarkM-
5118  Bitcoin / Development & Technical Discussion / Re: How a floating blocksize limit inevitably leads towards centralization on: February 19, 2013, 02:45:06 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?

This is maybe the real reason for making the Bitcoin Foundation: to trademark the name, so whatever popsicle-coin of the day they come up with gets the "network effect" associated with the "brand"...

-MarkM-
5119  Bitcoin / Development & Technical Discussion / Re: How a floating blocksize limit inevitably leads towards centralization on: February 19, 2013, 02:42:51 PM
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.

Why not?  All he'd have to do is code the change, offer it as the new version of the "reference client" and see how many people accepted it.  What percentage would have to accept the hard fork for it to become viable? 50%? 20%? 5%?


Lowering the difficulty of the real, as in original, bitcoin, so the rest of us can go on mining the original, high value per coin, international settlements bitcoins while he goes on to make a payment network for people to buy popsibles with. Sounds interesting... Especially with everyone having their coins from the past still exist on both chains, the original and the new popsicle-coin chain.

-MarkM-
5120  Alternate cryptocurrencies / Altcoin Discussion / Re: Any coder wants to make a cryptocurrency? on: February 19, 2013, 02:35:23 PM
Sounds interesting but a logged medium seems best to minimise the editing/redacting needed to present the ideas to the masses when making copy telling them what it is what it does how it works etc.

So I suggest you first make docs explaning it all, not much point going to PM just to come back and post "yeah as expected the guy seems to have no idea WTF he is talking about".

Its not like you are already known for your excellent "revolutionary new currency applications" or anything like that.

Convince us your ideas have merit. Months and many long threads involving many types of experts took place on the idea of proof of stake for example before any coder considered the idea well enough discussed to be worth having a try at implementing it (and its maybe even now still controversial whether they chose the best version of it to implement...)

-MarkM-
Pages: « 1 ... 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 [256] 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 ... 384 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!