Bitcoin Forum
May 26, 2024, 02:08:48 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 2 3 [4]
61  Bitcoin / Development & Technical Discussion / Re: Can you handle 8MB blocks? on: August 20, 2015, 04:37:59 PM
CPUs are used to relay the blocks that are found and to control the ASICs. In addition, Bitcoin Core uses 0.1% CPU max on my computer, even with my node running, my CPU is throttled to it's lowest voltage/speed on my laptop. I also cannot assume that if blocks were 10MB each, that it would take my computer 1%.

I have an intel 3610qm ( intel i7 2.3Ghz up to 3.3Ghz) but i always wonder how if we have 1000 transactions a second one day how large the tx cache will be
62  Bitcoin / Project Development / Is this possible with bitcoin right now? on: August 20, 2015, 04:21:30 PM
Say I have a Bitcoin based marketplace through bitcoind php and json
and in an effort to keep the blockchain clear of dust and relatively "small" transactions, could a user "commit" a certain balance that would be deducted once the balance value (say for example $50) is reached within the marketplace via a multi-sig transaction/contract.

The user could do 5 $10 dollar transactions with 5 different sellers etc

Or is this what Lightning network is?

thanks

Was
63  Bitcoin / Development & Technical Discussion / Re: Can you handle 8MB blocks? on: August 20, 2015, 04:10:17 PM
Just put it this way, a lot more processing power that could ever be used to relay transactions and verify them on full nodes is already being used to mine because of the financial incentive.
64  Bitcoin / Development & Technical Discussion / Re: Can you handle 8MB blocks? on: August 20, 2015, 02:58:41 PM
The question is not can you handle 8MB blocks every 10 minutes, the question is can you handle 8MB blocks all 10 minutes in 2016 and a doubling every 2 years!

So you should ask the question can you handle 8GB (Gigabyte!) blocks every 10 minutes in 2036!


well, we're talking 20 years from now, of course. We can cross that bridge when we come to it. My guess would be, yes, according to Moore's law.

Was
65  Bitcoin / Development & Technical Discussion / Re: Can you handle 8MB blocks? on: August 20, 2015, 03:35:21 AM
Here's a link to my result on Speedtest. http://www.speedtest.net/my-result/4596020657

30 people have seen this and not one has provided whether or not they'd be compatible with BIP101 in the long term?

Im just looking for input on whether this is a feasible proposal for full node operators in the short and long term.

was
66  Bitcoin / Development & Technical Discussion / Can you handle 8MB blocks? on: August 20, 2015, 01:59:15 AM
Hello all!

Hope you all have been well since I last posted.

I've been dealing with anxiety regarding the notion that if we aren't able to deal with an issue as simple and laid out as the Block-size, and cannot collaborate as a community in an organized manner, perhaps our financial system is destined to be ruled by central authorities forever.

This kind of thing taking place within the community, which in some cases, vaguely resembles one at all (/r/bitcoin) really troubles me because I feel like decentralized financial technologies can end the status quo of impoverished countries that are so due to fiat currencies....along with all the other mind-blowing implications.

I guess being taken advantage of is the compromise of being arrogant and in some cases, apathetic.

I was checking out my download/upload speed today on  speedtest.net 
Turns out I can download at around 23megabits per second. Which equates to around 2.5MB a second.

At 2.5MB/sec, you can download 8MB in 3.2 seconds, which means I should be able to run a full node in the event that blocks consistently were full in the next two years post-XT. If my bandwidth stays the same, I should also be able to relay 16MB blocks within 6.4seconds.
I was looking for some input from the community on what your download speeds were, and what region you run your node (if you run one)...

It looks like the majority of nodes are in the US, and the majority of nodes in the US are on the east coast, which is also where I am...

P.S My ISP is Verizon Fios

Thanks for reading

Was
67  Bitcoin / Development & Technical Discussion / Re: Block size limit proposal: bounded hash power mediated block size limit on: August 19, 2015, 02:14:09 AM
What does this look like in code?
68  Bitcoin / Development & Technical Discussion / Re: Block-size Solution Proposal on: August 15, 2015, 05:48:26 PM
You are still dodging my question. Why is 1.618 per day reasonable? I'm just heading unrelated crap about 'patterns in nature' that have nothing to do with computational resources or txn volume.

What is wrong with waiting a week or month for growth? Your current rate is excessive. I'm not buying the claim that we even have a chance of needing terabyte blocks within only one or a few months. I favor something more reasonable such as 1.5 factor per week at most.

I never solidified a 1.618x increase day over day, just threw it up in the air, however, I don't see why if the network demanded it we couldn't implement it.

 If Bitcoin use doubled within a week because of some event similar to Greece, we need to ensure that Bitcoin remains dynamic enough to handle such genuine influx. Or risk giving a bad impression on new-adopters.

I don't see the point in getting caught up in all of this, really. We can always implement an equation on top in order to prevent transaction volumes from out-pacing Moore's law, and introduce as a result, a fee market, but in the end : Such a market would further incentivize people to develop capable hardware of handling the excess transactions that the network would otherwise be incapable of handling.

If there's money to be made, it will be made. Just look at computers, there was a ton of money to be made, so we now carry the decade ago equivilent of super computers in our pockets... casually.

And on the other hand, there isn't much money to be made in developing alternatives to the current banking system (short term), or Gasoline.... or Cures instead of life-long treatments. So it doesn't happen.

Guys, please try to move away from the argument-like vibe of this topic, we're all trying to achieve similar things, so we should be collaborating and discussing, not bashing other people's ideas or notions. If someone is factually wrong, feel free to correct them, but stay out of your feelings please.
69  Bitcoin / Development & Technical Discussion / Re: Block-size Solution Proposal on: August 14, 2015, 09:46:13 PM
This is the most silly proposal I have ever heard.
Fibonachi blocks will skyrocket within a few years.
If it matches some nature models it doesn't mean we'll implement.
It's useless...
Incredibly silly...



They will skyrocket because bitcoin use will skyrocket. Paypal alone handles around 115 transactions per second. Bitcoin will eventually have to sustain over 100,000 tx/s, so why not set a cap in small, then large increments (fibonacci sequence) in proportion to the need of the network, but prevent it from outpacing Moore's law with a time-based equation?  At such point free market takes over and provides further incentive to develop nodes and miners and bandwidth that would support larger transaction volumes and therefore, a greater amounts of tx fees.
70  Bitcoin / Development & Technical Discussion / Re: Block-size Solution Proposal on: August 14, 2015, 04:11:35 PM
It's not an argument worth having because this (whether to increase blocksize based on a deterministic formula or whether to increase it as a function of usage, or any such combination) doesn't appear to even be the issue at hand. It seems that certain people are against ANY block increase in short term, no matter how sensible or perfect. 

I see your point, so why can't this issue be handled before it becomes an issue and a threat to the network. Lets pass a BIP that allows Bitcoin Core to know when the network needs the additional headroom in order to make space for legitimate transactions.


a very sensible idea and i agree, so it's baffling why they don't.

"They"?
71  Bitcoin / Development & Technical Discussion / Re: Block-size Solution Proposal on: August 14, 2015, 04:28:48 AM
It's not an argument worth having because this (whether to increase blocksize based on a deterministic formula or whether to increase it as a function of usage, or any such combination) doesn't appear to even be the issue at hand. It seems that certain people are against ANY block increase in short term, no matter how sensible or perfect. 

I see your point, so why can't this issue be handled before it becomes an issue and a threat to the network. Lets pass a BIP that allows Bitcoin Core to know when the network needs the additional headroom in order to make space for legitimate transactions.

Nothing has to change immediately, we can still keep the 1MB block in the short term, but when we begin to exceed 7tx/s on a daily basis, our clients and the miners will accept a 2MB block, until that threshold is reached, and so on and so forth as it gets exponentially more impossible for the network to be manipulated by dusting, and even if it was, it would be unsustainable.

If we can't reach consensus with a damn block-size increase when all it takes is math to understand the need for raising the ceiling, how will the community ever be able to deal with anything that pops up? Something that we didn't know was going to happen? I think we need a way for the community to vote on the blockchain for BIPs, and then maybe we'll be better able to deal with things like this...

Was
72  Bitcoin / Development & Technical Discussion / Re: Block-size Solution Proposal on: August 14, 2015, 03:01:26 AM
Seriously, do I need to ask this again, since you failed to answer it in the previous discussion we had? Why fibonacci? What benefit does it have for Bitcoin itself? Sure, the constant phi (1.618) is cool and mathematically elegant and applicable to nature, but bandwidth and storage capacity do NOT grow as a geometric sequence with ratio phi.

Also, if I spammed for 15 days, I'd get the block size up to a gigabyte every 10 minutes. This is obviously unsustainable. You can't grow the block size after only a day of fullness. It invites too much abuse.

Hello! thanks for taking the time to reply.
I replied to your post on the other forum shortly after I wrapped up this post, but Im sorry if I didn't completely address your concerns.

I would ask you to re-read what I said, as I simply threw the 1 day correction period up in the air, for us to discuss.

What other mathematical equation do you suggest that allows initial gradual growth of the block-size limit??  It is my understanding that current proposals suggest a doubling 8MB block size limit every 2 years? How is this more desirable than a dynamic block-size of any formula?

"Also, if I spammed for 15 days, I'd get the block size up to a gigabyte every 10 minutes"

This sentence hardly even makes sense, but it begs the general question: How would you plan to do this? I believe that in order to "dust" the blockchain with sufficient # of txs to raise the limit, it would take an increasing large amount of coin and, once you run out, you would be purchasing at an exponentially increasing rate and would just drive the USD/BTC price to the moon, further driving your ability to "abuse" my proposition into the ground.

I believe that we could benefit from a 2MB, then 3MB, then 5MB blocksize limit before we need to jump immediately to 8MB block caps.  Because, you know "bandwidth and storage capcity do NOT grow as a geometric sequence with ratio phi", but they don't grow in an exponential sequence either.

Nor would they need to, blocksize only needs to be dynamic in order to accommodate an ever increasing transaction volume driven by humans.

The reason the fibonacci sequence is so desirable for this issue and bitcoin as a whole is because it allows gradual growth of the blocksize limit while Bitcoin is in it's infancy, and then an accelerating growth in order to accommodate a transaction volume similar to Visa's and Mastercard's combined, while not disturbing the network

At the end of the day, I think its one of the best options, and if everyone is so against an infallible method of growth being applied to the bitcoin blocksize limit, go ahead and implement a static increase of 1.5x each time. You can keep your 1.5MB blocks.

Was

73  Bitcoin / Development & Technical Discussion / Re: Would this be a reasonable compromise between Core and XT? on: August 13, 2015, 05:48:54 PM
It will bring us to 2MB, then 3MB, then 5MB, THEN 8MB... You think it's excessive, but you don't seem to realize exactly how many transactions bitcoin may one day handle.

Gradually, and only when it's necessary. Rather than on irrelevant time intervals.
Check my post.
74  Bitcoin / Development & Technical Discussion / Block-size Solution Proposal on: August 13, 2015, 05:43:27 PM
Hello All,

Let me start off by saying how fortunate I feel to be apart of this forum and the bitcoin community as a whole. This really is an exciting time to be alive. Between Bitcoin and the internet, the implications of technologies (can be) endless.

However, It is my feeling that too many somewhat lack the sense of responsibility when it comes to ensuring that this payment network becomes what it inevitably was meant to be. We have been granted the opportunity to be present at the beginning of bitcoin. Therefore, the future of our world's financial system (and the world as a whole) lies in each one of our hands.

 I have an imperative proposal that I would like you all to consider with an open mind. I believe this proposal could reach consensus by the end of this year. (or as soon as people realize it's implementation is absolutely necessary, ie., huge backlog of txs.)

I believe that this proposal is very bipartisan, as it does not change anything immediately, until such time that it's improvements to the protocol are reflected by our blockchain.

I believe that we currently do not need larger blocks, because the average block is not even over 75% full. "If its not broken don't fix it"

However, I know that it is inevitable, as bitcoin continues to add users and liquidity, that we will need a larger block-size cap due to increased tx volume.

Therefore, my proposal is as follows:
 
Increase the block-size cap following a Fibonacci Sequence (1,2,3,5,8,13,21) dynamically according to the average full-ness (95-99%) of the last X amount of blocks. ( I am looking for input on the best compromise between quick resolution and required resolution)... ?

The Fibonacci Sequence is nature's mathematical equation for growth and it has proved infallible for all of life's existence. (It's actually really interesting, I suggest looking into it and keeping an eye out for it in nature)



Other proposals suggesting the "doubling" of the block size (Bitcoin XT) after set time periods show complete disregard for both the complexity of bitcoin itself and the ability of nodes to remain capable of relaying blocks of larger size.

This idea appeals to me because it allows gradual, then geometric growth of the network instead of exponential growth, which will not remain feasible in the long run.

This BIP will allow the block-size cap to remain at 1MB until such time that it is necessary for the block-size to be increased due to a long duration of essentially full blocks in order to prevent the build-up of backlogged tx's on the blockchain. This will begin to happen when we see more than 7tx/s. Which, at the latest, will happen Q2 2016.

I hope that this gave you all some food for thought, and I look forward to reviewing questions, comments and ideas from the community.

Peace and love

Was
75  Bitcoin / Development & Technical Discussion / Re: Would this be a reasonable compromise between Core and XT? on: August 13, 2015, 05:05:39 PM
 And the Fact is, the vast majority of blocks that we see are under 600kb, and until earlier this year, were artificially capped at 750kb by miners in order to further incentivize Tx fees. (make miners more $)

However, as bitcoin continues to grow, 7tx/s will not be sufficient.

I proposed a blocksize increase that followed a Fibonacci geometric sequence. So the next max block size would be 2MB, and the next after that, 3MB, and the next, 5MB, and then 8MB and so on.

I think the best way for us to handle this issue is to implement this geometric block-size sequence into our clients and allow the block size to remain at 1MB until the last 144 Blocks are over 900kb. At least then our software will be prepared, and nothing changes until it needs to.
Pages: « 1 2 3 [4]
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!