Bitcoin Forum
December 05, 2016, 12:43:35 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Poll
Question: Will you support Gavin's new block size limit hard fork of 8MB by January 1, 2016 then doubling every 2 years?
1.  yes
2.  no

Pages: « 1 ... 1142 1143 1144 1145 1146 1147 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189 1190 1191 [1192] 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 ... 1560 »
  Print  
Author Topic: Gold collapsing. Bitcoin UP.  (Read 1804605 times)
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
May 10, 2015, 03:37:18 PM
 #23821

I understand the probability equations, but am trying to understand the logic in how they are being used and how an attacker with less than 50% could have an almost 100% chance of forcing a new longer chain. I would expect that no matter what the probability of being successful would be less than 50%.

The reason is the attacker just keeps going with his attack until (with a tiny bit of luck) his chain is longer. At that point everyone else will join his chain and his need to "attack" is over, he just mines his chain along with everyone else.

Intuitively, realize that the success probability is 100% at >50%, because he can always be assured of outrunning the other fork. It doesn't just jump right from near-zero to 100% as soon as you get 50%, it rises gradually with significant shares <50%.





but for every "bit of luck" the 49% attacker gets (by that i'm assuming you mean a "spurt" of luck with several blocks in a row) the 51% honest chain has the same chances of that "bit of luck" of a block spurt.  not only does the 51% honest chain have the advantage of slowly pulling further ahead via percentages alone while the 49% attacker is withholding blocks, he has the advantage of the same block spurt of luck.  both of these factors as the 51% chain pulls further and further ahead will eventually force the 49% attacker to abandon his attack, start over, while suffering losses from the blocks he could have claimed by publishing them instead of holding them back.  in effect, you can neutralize the spurt of blocks from the analysis and just say that the 51% chain will always outrun the 49% chain on average.

The math says otherwise. The 51% chain doesn't need to do anything at all. The 49% chain just needs to get lucky to pull ahead briefly, and it eventually will, usually. That 2% lead isn't much. Occasionally the 51% chain will pull too far ahead and you will need to abandon your attack, that's what accounts for the 4% (or whatever number) chance of failure. But usually this doesn't happen.

If Satoshi's brief explanation or Peter R's use of the math isn't clear enough for you, there is more of a step-by-step explanation here, along with some pictures (Figure 3 in particular): https://bitcoil.co.il/Doublespend.pdf



that's interesting.  not that it matters.

did you know Meni Rosenfeld was a huge proponent of POS for several years?  smart guy but he was way off on that one.
1480941815
Hero Member
*
Offline Offline

Posts: 1480941815

View Profile Personal Message (Offline)

Ignore
1480941815
Reply with quote  #2

1480941815
Report to moderator
1480941815
Hero Member
*
Offline Offline

Posts: 1480941815

View Profile Personal Message (Offline)

Ignore
1480941815
Reply with quote  #2

1480941815
Report to moderator
1480941815
Hero Member
*
Offline Offline

Posts: 1480941815

View Profile Personal Message (Offline)

Ignore
1480941815
Reply with quote  #2

1480941815
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480941815
Hero Member
*
Offline Offline

Posts: 1480941815

View Profile Personal Message (Offline)

Ignore
1480941815
Reply with quote  #2

1480941815
Report to moderator
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
May 10, 2015, 04:04:19 PM
 #23822

I agree. I am in support of Bitcoin. I think it is possibly its own trojan horse. And I think the masses are going to adopt Bitcoin no matter what we do. I posit our only hope is to establish an alternative (often anonymous) economy with sufficient usage that it will remain viable and useful. I have no delusions about entirely disrupting fiat nor Bitcoin, because the masses don't want to end their socialism (they depend on Big Brother for food, housing, education, healthcare, anti-terrorism shadows, etc).

However, my point against altcoins (and note I have not intensively evaluated for example Nxt's ecosystem, so there might be exceptions I am unaware of) is they have limited network effects because afaics network effects are mostly driven by the use as a medium-of-exchange. And it appears to me to be a chicken-or-egg dilemma in that without network effects then it can't be a viable investment because medium-of-exchange requires reasonable ubiquity (currency must be convenient and increase efficiency of trade). In short, there is no value in just buying digits that we trade as an investment. There has to be some use value to impart value to the digits.

Thus I posit there does come a point where we may not be able to get the economy-of-scale to offer a viable option to Bitcoin any more. The inertia could become too great to overcome and we might even already be there or approach that point on the next runup in price with Circle, Coinbase, and Paypal all ready to vest the masses in Bitcoin. I assert that the masses are complacent and they simply won't switch, no matter if all our ideological reasons for supporting Bitcoin disappear. We could try to leave into our own coin, but we will find that not enough of us can leave en masse at once in order to use the coin for anything. Thus most of us will thus throw in the towel and realize it is futile and we waited too long.

So I argue we can't just take it as a given and must be proactive and expedient on any altcoin experiments we want to do.


while digging thru all your other bullshit, i stumbled upon this.  i can't disagree much with anything you say here and am glad to see you say supporting things about Bitcoin.

Bitcoin does have the network effect and that is why i say don't waste time on altcoins.  we should spend more time strengthening Bitcoin to make it stronger and more resilient to attack.  specifically to your Sybil attack theory, there is the parallel meshnetworks that ppl are trying to bootstrap for Bitcoin.  that seems like a worthwhile project while at the same time continuing to build on Bitcoin. 

it's my strong sense that the general opinion out there is that Bitcoin is it of all the cryptocurrencies.  you can see it in the charts.  all the altcoins, incl Monero, have been more decimated by this latest bear market.  you can say it's just more volatile swings and to be expected but my reading of the news states that most investors are turning to the safest of all coin options, that being Bitcoin.

how about this?  let's say you're right about TPTB trying to get the entire world onto Bitcoin.  well, that's going to take several years and significant price pumping to do so, so why not ride the wave?  make lotsa money on the way up; profit.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
May 10, 2015, 04:24:47 PM
 #23823



^ Here's a chart that shows the historical blocksize growth along with the limits, the "block fullness," and some commentary on how the limits have changed in the past and may change in the future.

Credit to Solex for the 1MBCON Advisory System Status and DeathAndTaxes for digging up the GitHub commits that introduced the blocksize limits.

Peter, can you extend the chart out to the right so we can see what year the 20MB size would be hit?
Zangelbert Bingledack
Legendary
*
Offline Offline

Activity: 1022


View Profile
May 10, 2015, 04:54:15 PM
 #23824

By an eyeballing it's about 6 years from now (tenfolding about every four years), but I kind of doubt extrapolation can hold up very well as the transactional currency aspect doesn't really start to come to the fore until later when the network effects reach critical mass. Perhaps the exponential growth is enough to account for that, but I suspect something faster unless a lot of the transaction volume moves off chain.

Assuming 20MB means about 100 TPS, ten years from now we'd be at 200MB blocks and 1000 TPS, then by around 2030 we'd be into the 2GB and 10000+ TPS range, which looks like pretty solid global adoption (roughly 4000x current TPS). I suppose that's not unreasonable.

I should note that some say the 1MB limit is already pushing down the increase, which would be another reason to doubt the extrapolation.

While I'm extrapolating, if we consider price at that level to be something in the very general ballpark of $1M per BTC, which is about 4000x the current price, it all fits together somewhat cleanly. Though that means the price will only tenfold roughly every 4 years as well. Though who knows, target price could be $10M or even $100M for all I know - in which case the price would tenfold about every 3 years or 2.5 years, respectively, on average for the next ~15 years. Of course if we get an S-curve for the price growth, most of those gains will be front loaded over the next several years.

/speculation Grin
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
May 10, 2015, 04:57:13 PM
 #23825

By an eyeballing it's about 6 years from now (tenfolding about every four years), but I kind of doubt extrapolation can hold up very well as the transactional currency aspect doesn't really start to come to the fore until later when the network effects reach critical mass. Perhaps the exponential growth is enough to account for that, but I suspect something faster unless a lot of the transaction volume moves off chain.

Assuming 20MB means about 100 TPS, ten years from now we'd be at 200MB blocks and 1000 TPS, then by around 2030 we'd be into the 2GB and 10000+ TPS range, which looks like pretty solid global adoption (roughly 4000x current TPS). I suppose that's not unreasonable.

By the way, if we consider price at that level to be something in the very general ballpark of $1M per BTC, which is about 4000x the current price, it all fits together somewhat cleanly. Though that means the price will only tenfold roughly every 4 years as well. Though who knows, target price could be $10M or even $100M for all I know - in which case the price would tenfold about every 3 years or 2.5 years, respectively, on average for the next ~15 years. Of course if we get an S-curve for the price growth, most of those gains will be front loaded over the next several years.

/speculation Grin

Then, as you've said before, we need to get going!
Zangelbert Bingledack
Legendary
*
Offline Offline

Activity: 1022


View Profile
May 10, 2015, 05:27:07 PM
 #23826

Then, as you've said before, we need to get going!

I do detect a trace of inevitability in the air recently.

Even this blocksize debate, with all the hypothetical perils it highlights going forward, has left me with one remarkable sensation I haven't experienced in all my years of online discussion. Although it may look like there is a lot of squabbling and trolling and facile arguments, when compared to the baseline Internet noise level I've never seen so many people come together in debate in such a serious way with the mental discipline that comes from having so much truly on the line, both financially and personally (or ideologically), united in basic vision even if disagreeing on the details for how to get there.

It hints at the formidable power of the world's first purely economic community, and the all-permeating effect of Bitcoin's allure - it's potency in aligning people with its agenda regardless of their organizational affiliations.
Peter R
Legendary
*
Offline Offline

Activity: 938



View Profile
May 10, 2015, 05:58:07 PM
 #23827

Peter, can you extend the chart out to the right so we can see what year the 20MB size would be hit?


Run Bitcoin Unlimited (www.bitcoinunlimited.info)
tvbcof
Legendary
*
Offline Offline

Activity: 1974


View Profile
May 10, 2015, 06:53:24 PM
 #23828

Peter, can you extend the chart out to the right so we can see what year the 20MB size would be hit?



Thx for that.  It shows quite clearly that attempts to outgrow most of the scaling problems that vex Bitcoin by doing simplistic scaling are pretty futile which is a point of view that I held since before I bought my first BTC (on e-bay IIRC.)

I'm using the same computer now that I put together around the time Bitcoin was invented.  It's obsolete, but not horribly so.  i5 chipset (Nehalem), 4G, a few TB of mirrored encrypted storage, etc.  Sure, I could build a much better computer now (although not all that much better), but the ONLY reason I would have any need to do so would be to try to run a simple transfer node.  My network capacity has decreased by orders of magnitude since I moved out of the silicon valley so even at 7 TPS I probably would not try and if I did I would only activate it at hours when my data was not metered.

Upshot: I could still play a constructive support role in infrastructure support if I had good reason to.  One of the main reasons I do not is that if my contribution made much of a difference in a stressed situation where it would be of value is that my efforts could be nixed at a flip of the switch by simple injunctive measures (network censorship.)  Because Bitcoin dev has not focused on (or even acknowledged) this potential failure mode I feel little incentive to waste my time and money trying to support the robustness of the solution.

The chart shows that in roughly the short time I've been involved (mid 2011) we will be right back to where we are again with 20 MB (forgetting for a moment the little issue that is supposed to be forgotten that many people's 20MB has an exponential growth factor beyond that.)  There was a huge amount of low hanging fruit codebase-wise to harvest getting 1MB to work to the extent that it does.  That luxury will not be present moving into the 20 MB limit by the nature of how computer science is done.

I made several mis-calculations about Bitcoin at the time I put some actual fund into the blockchain:

1) That things would naturally centralize around such entities as blockchain.info, coinbase, etc, and thus alleviate the need to grow the transaction rate.  (A positive mis-calculation.)

2) That it would be so blatantly obvious that Bitcoin's only realistic trajectory would be as a backing store for similar solutions by the time we stressed the transaction rate limits that nobody could argue otherwise.  (A negative mis-calculation.)

edit: slight.  Also:

I would again note that the issue charted is UTXO which is not particularly related to transaction rate.  An attack I thought of years ago would be to formulate UTXO's systematically to chain blocks together in such a way that 1) their count would stress the working database (currently implemented in RAM most often) and 2) verifying them would touch as many blocks as possible making rendering of much of the actual blockchain itself require for many transactions.  I'm sure there is a name for such an attack.  If not, call it the 'tvbcof attack' I suppose.  I've not 'done the math', but it seems somewhat intuitive to me that such an 'attack' would happen organically upon reasonable use rates (which we have yet to even approach in the real-world to this point if Bitcoin remains a 'one-size-fits-all' exchange currency solution.)


Zangelbert Bingledack
Legendary
*
Offline Offline

Activity: 1022


View Profile
May 10, 2015, 07:17:41 PM
 #23829

An attack I thought of years ago would be to formulate UTXO's systematically to chain blocks together in such a way that 1) their count would stress the working database (currently implemented in RAM most often) and 2) verifying them would touch as many blocks as possible making rendering of much of the actual blockchain itself require for many transactions.  I'm sure there is a name for such an attack.  If not, call it the 'tvbcof attack' I suppose.

Something like this was brought up on reddit. Why not have higher fees for these kind of "tvbcof transactions"? (Higher fees in proportion to how much they scatter the UTXOs. And perhaps lower or zero fees for transactions that consolidate UTXOs.)
tvbcof
Legendary
*
Offline Offline

Activity: 1974


View Profile
May 10, 2015, 07:31:58 PM
 #23830

An attack I thought of years ago would be to formulate UTXO's systematically to chain blocks together in such a way that 1) their count would stress the working database (currently implemented in RAM most often) and 2) verifying them would touch as many blocks as possible making rendering of much of the actual blockchain itself require for many transactions.  I'm sure there is a name for such an attack.  If not, call it the 'tvbcof attack' I suppose.

Something like this was brought up on reddit. Why not have higher fees for these kind of "tvbcof transactions"? (Higher fees in proportion to how much they scatter the UTXOs. And perhaps lower or zero fees for transactions that consolidate UTXOs.)

That would be one solution.  Another would be to periodically do what I would call a 're-base'.  Neither could be achieved without either

 - a major-ish re-design (and more and more changes qualify as 'major-ish' as Bitcoin ages), OR

 - with some increased control over the solution which could probably only come with processing centralization.  When one can mandate a 'tvbcof transaction tax' through this mechanism we will be well beyond the point where it will have been possible to implement the 'Qaddafi block' which Hearn hypothesized back around the time I took an active(-ish self) interest in Bitcoin.


Chainsaw
Hero Member
*****
Offline Offline

Activity: 525


x


View Profile
May 10, 2015, 07:34:17 PM
 #23831

Peter, can you extend the chart out to the right so we can see what year the 20MB size would be hit?



Thx for that.  It shows quite clearly that attempts to outgrow most of the scaling problems that vex Bitcoin by doing simplistic scaling are pretty futile which is a point of view that I held since before I bought my first BTC (on e-bay IIRC.)

I'm using the same computer now that I put together around the time Bitcoin was invented.  It's obsolete, but not horribly so.  i5 chipset (Nehalem), 4G, a few TB of mirrored encrypted storage, etc.  Sure, I could build a much better computer now (although not all that much better), but the ONLY reason I would have any need to do so would be to try to run a simple transfer node.  My network capacity has decreased by orders of magnitude since I moved out of the silicon valley so even at 7 TPS I probably would not try and if I did I would only activate it at hours when my data was not metered.

Upshot: I could still play a constructive support role in infrastructure support if I had good reason to.  One of the main reasons I do not is that if my contribution made much of a difference in a stressed situation where it would be of value is that my efforts could be nixed at a flip of the switch by simple injunctive measures (network censorship.)  Because Bitcoin dev has not focused on (or even acknowledged) this potential failure mode I feel little incentive to waste my time and money trying to support the robustness of the solution.

The chart shows that in roughly the short time I've been involved (mid 2011) we will be right back to where we are again with 20 MB (forgetting for a moment the little issue that is supposed to be forgotten that many people's 20MB has an exponential growth factor beyond that.)  There was a huge amount of low hanging fruit codebase-wise to harvest getting 1MB to work to the extent that it does.  That luxury will not be present moving into the 20 MB limit by the nature of how computer science is done.

I made several mis-calculations about Bitcoin at the time I put some actual fund into the blockchain:

1) That things would naturally centralize around such entities as blockchain.info, coinbase, etc, and thus alleviate the need to grow the transaction rate.  (A positive mis-calculation.)

2) That it would be so blatantly obvious that Bitcoin's only realistic trajectory would be as a backing store for similar solutions by the time we stressed the transaction rate limits that nobody could argue otherwise.  (A negative mis-calculation.)

edit: slight.  Also:

I would again note that the issue charted is UTXO which is not particularly related to transaction rate.  An attack I thought of years ago would be to formulate UTXO's systematically to chain blocks together in such a way that 1) their count would stress the working database (currently implemented in RAM most often) and 2) verifying them would touch as many blocks as possible making rendering of much of the actual blockchain itself require for many transactions.  I'm sure there is a name for such an attack.  If not, call it the 'tvbcof attack' I suppose.  I've not 'done the math', but it seems somewhat intuitive to me that such an 'attack' would happen organically upon reasonable use rates (which we have yet to even approach in the real-world to this point if Bitcoin remains a 'one-size-fits-all' exchange currency solution.)



This could be a high visibility chart.
We are extrapolating a line. I want to point out a risk.

The drawn line extrapolates based on an assumption of linear growth from some point midway along the function into the future.
If we drew a linear line from the start of the dataset through the current time, we would hit 20MB at a different, earlier date.
If we drew the line of best fit as a polynomial function (which is currently above the line and returning to it), we would hit 20 MB at a different, still earlier date.
If we drew a sigmoid function where we are approaching a ceiling, it is possible that limit would never hit 20MB.

If it is within anyone's capacity, I think it would be worth throwing these data points into some statistical software and determining line(s) of best fit, with correlations and such.
It would turn something that is subjectively interpretible into something objective.
I think that's important in this debate, for many of the reasons Zangelbert mentioned above.

cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
May 10, 2015, 09:56:48 PM
 #23832

Peter, can you extend the chart out to the right so we can see what year the 20MB size would be hit?



Thx for that.  It shows quite clearly that attempts to outgrow most of the scaling problems that vex Bitcoin by doing simplistic scaling are pretty futile which is a point of view that I held since before I bought my first BTC (on e-bay IIRC.)

I'm using the same computer now that I put together around the time Bitcoin was invented.  It's obsolete, but not horribly so.  i5 chipset (Nehalem), 4G, a few TB of mirrored encrypted storage, etc.  Sure, I could build a much better computer now (although not all that much better), but the ONLY reason I would have any need to do so would be to try to run a simple transfer node.  My network capacity has decreased by orders of magnitude since I moved out of the silicon valley so even at 7 TPS I probably would not try and if I did I would only activate it at hours when my data was not metered.

Upshot: I could still play a constructive support role in infrastructure support if I had good reason to.  One of the main reasons I do not is that if my contribution made much of a difference in a stressed situation where it would be of value is that my efforts could be nixed at a flip of the switch by simple injunctive measures (network censorship.)  Because Bitcoin dev has not focused on (or even acknowledged) this potential failure mode I feel little incentive to waste my time and money trying to support the robustness of the solution.

The chart shows that in roughly the short time I've been involved (mid 2011) we will be right back to where we are again with 20 MB (forgetting for a moment the little issue that is supposed to be forgotten that many people's 20MB has an exponential growth factor beyond that.)  There was a huge amount of low hanging fruit codebase-wise to harvest getting 1MB to work to the extent that it does.  That luxury will not be present moving into the 20 MB limit by the nature of how computer science is done.

I made several mis-calculations about Bitcoin at the time I put some actual fund into the blockchain:

1) That things would naturally centralize around such entities as blockchain.info, coinbase, etc, and thus alleviate the need to grow the transaction rate.  (A positive mis-calculation.)

2) That it would be so blatantly obvious that Bitcoin's only realistic trajectory would be as a backing store for similar solutions by the time we stressed the transaction rate limits that nobody could argue otherwise.  (A negative mis-calculation.)

edit: slight.  Also:

I would again note that the issue charted is UTXO which is not particularly related to transaction rate.  An attack I thought of years ago would be to formulate UTXO's systematically to chain blocks together in such a way that 1) their count would stress the working database (currently implemented in RAM most often) and 2) verifying them would touch as many blocks as possible making rendering of much of the actual blockchain itself require for many transactions.  I'm sure there is a name for such an attack.  If not, call it the 'tvbcof attack' I suppose.  I've not 'done the math', but it seems somewhat intuitive to me that such an 'attack' would happen organically upon reasonable use rates (which we have yet to even approach in the real-world to this point if Bitcoin remains a 'one-size-fits-all' exchange currency solution.)



This could be a high visibility chart.
We are extrapolating a line. I want to point out a risk.

The drawn line extrapolates based on an assumption of linear growth from some point midway along the function into the future.
If we drew a linear line from the start of the dataset through the current time, we would hit 20MB at a different, earlier date.
If we drew the line of best fit as a polynomial function (which is currently above the line and returning to it), we would hit 20 MB at a different, still earlier date.
If we drew a sigmoid function where we are approaching a ceiling, it is possible that limit would never hit 20MB.

If it is within anyone's capacity, I think it would be worth throwing these data points into some statistical software and determining line(s) of best fit, with correlations and such.
It would turn something that is subjectively interpretible into something objective.
I think that's important in this debate, for many of the reasons Zangelbert mentioned above.

yeah, i agree.  the rate of tx growth could be highly variable.  almost as volatile or even dependent on the price.
shmadz
Legendary
*
Offline Offline

Activity: 1428


@theshmadz


View Profile
May 10, 2015, 10:34:30 PM
 #23833

Regarding transaction growth and the limits of bandwidth, has anyone thought of the possibility of parallel chains?

Split the Blockchain into several chunks and distribute.

Is there any discussion of this at all? Or is it just a stupid idea?

* Edit: never mind, I guess that's essentially sidechains, isn't it?

"You have no moral right to rule us, nor do you possess any methods of enforcement that we have reason to fear." - John Perry Barlow, 1996
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
May 10, 2015, 11:18:57 PM
 #23834

Regarding transaction growth and the limits of bandwidth, has anyone thought of the possibility of parallel chains?

Split the Blockchain into several chunks and distribute.

Is there any discussion of this at all? Or is it just a stupid idea?

* Edit: never mind, I guess that's essentially sidechains, isn't it?

Yeah, the problem with those ideas is that you want to try and keep all TX's on the mainchain as possible to pay miners fees, imo, so as to minimize cannibalizing or even killing off Bitcoin. Any of those offchain alternatives are  likely to create friction as well.
shmadz
Legendary
*
Offline Offline

Activity: 1428


@theshmadz


View Profile
May 10, 2015, 11:46:08 PM
 #23835

Regarding transaction growth and the limits of bandwidth, has anyone thought of the possibility of parallel chains?

Split the Blockchain into several chunks and distribute.

Is there any discussion of this at all? Or is it just a stupid idea?

* Edit: never mind, I guess that's essentially sidechains, isn't it?

Yeah, the problem with those ideas is that you want to try and keep all TX's on the mainchain as possible to pay miners fees, imo, so as to minimize cannibalizing or even killing off Bitcoin. Any of those offchain alternatives are  likely to create friction as well.

So... what if you fragment the chain? Like a distributed computing project, so each node only had to do a fraction of the work. But then maybe you'd have problems with forks... but if there was a protocol that was very small, very fast that could help speed up consensus... Gavin talked about something like this once, invertable bloom filters, I think?


"You have no moral right to rule us, nor do you possess any methods of enforcement that we have reason to fear." - John Perry Barlow, 1996
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
May 11, 2015, 12:16:05 AM
 #23836

Regarding transaction growth and the limits of bandwidth, has anyone thought of the possibility of parallel chains?

Split the Blockchain into several chunks and distribute.

Is there any discussion of this at all? Or is it just a stupid idea?

* Edit: never mind, I guess that's essentially sidechains, isn't it?

Yeah, the problem with those ideas is that you want to try and keep all TX's on the mainchain as possible to pay miners fees, imo, so as to minimize cannibalizing or even killing off Bitcoin. Any of those offchain alternatives are  likely to create friction as well.

So... what if you fragment the chain? Like a distributed computing project, so each node only had to do a fraction of the work. But then maybe you'd have problems with forks... but if there was a protocol that was very small, very fast that could help speed up consensus... Gavin talked about something like this once, invertable bloom filters, I think?



he's never talked about that, afaik.  IBLT is a totally different thing.  that is a set reconciiation strategy dependent on the fact that most full nodes are carrying a set of unconfirmed tx's in their RAM that are already pretty close to identical to each others across the network.  the smaller the differences, the smaller the IBLT has to be to reconcile those differences.  the strategy is apparently only about 4 yo invented after Bitcoin. 

Gavin has proposed using IBLT's by miners who solve a block who then, instead of retransmitting the block with all it's tx's across the network which involves considerable latency, only then have to transmit the IBLT with the header to other nodes who then can reconstruct their unconfirmed tx set using the IBLT to match that of the proposed block to then see if the POW was in fact valid.

that was pretty tortured language so i hope you understand.
shmadz
Legendary
*
Offline Offline

Activity: 1428


@theshmadz


View Profile
May 11, 2015, 12:37:02 AM
 #23837

Regarding transaction growth and the limits of bandwidth, has anyone thought of the possibility of parallel chains?

Split the Blockchain into several chunks and distribute.

Is there any discussion of this at all? Or is it just a stupid idea?

* Edit: never mind, I guess that's essentially sidechains, isn't it?

Yeah, the problem with those ideas is that you want to try and keep all TX's on the mainchain as possible to pay miners fees, imo, so as to minimize cannibalizing or even killing off Bitcoin. Any of those offchain alternatives are  likely to create friction as well.

So... what if you fragment the chain? Like a distributed computing project, so each node only had to do a fraction of the work. But then maybe you'd have problems with forks... but if there was a protocol that was very small, very fast that could help speed up consensus... Gavin talked about something like this once, invertable bloom filters, I think?



he's never talked about that, afaik.  IBLT is a totally different thing.  that is a set reconciiation strategy dependent on the fact that most full nodes are carrying a set of unconfirmed tx's in their RAM that are already pretty close to identical to each others across the network.  the smaller the differences, the smaller the IBLT has to be to reconcile those differences.  the strategy is apparently only about 4 yo invented after Bitcoin. 

Gavin has proposed using IBLT's by miners who solve a block who then, instead of retransmitting the block with all it's tx's across the network which involves considerable latency, only then have to transmit the IBLT with the header to other nodes who then can reconstruct their unconfirmed tx set using the IBLT to match that of the proposed block to then see if the POW was in fact valid.

that was pretty tortured language so i hope you understand.

Yes, I was imagining using IBLT to maybe provide a mechanism to allow for some kind of parallelization of the nodes, so that each node only needs to contain a small chunk of the UTXO data.

I guess what I'm envisioning is a node structure where it might be possible to split up the work of maintaining the blockchain similar to how storj is fragmenting and distributing files.

Any proposed solutions I've seen so far to the scaling issue have been incremental at best, so I want to start spitballing some more "outside the box" crazy proposals, but I'm not a programmer so I only have a rudimentary idea of what's feasible.

Sorry if it's all just a waste of time.

"You have no moral right to rule us, nor do you possess any methods of enforcement that we have reason to fear." - John Perry Barlow, 1996
thezerg
Legendary
*
Offline Offline

Activity: 1246


View Profile
May 11, 2015, 12:57:43 AM
 #23838

I believe I know how to solve that.  There are 3 innovations that form the core of a microtxn coin -- a problem I've been keen to solve because like I said years ago i think there are room 4 3 coins:
BTC: first mover for holding and large txns.
AnonCoin: maybe MRO
MicroCoin: undefined.

The 3 innovations are:
1. UTXO oriented protocol and storage.  (Merkle UTXO trees that I discussed previously)
2. UTXO size consolidation.  There are various approaches.  The previously mentioned idea for addtl fees if outputs > inputs is not quite there.  Better is addtl fee for every not-previously seen address and UTXO merkle is changed to be address-with-balance merkle tree.  Other ideas are to make address creation expensive (like vanity addresses) and address consolidation txn gets fee rebate.
3. Transformation of blockchain to scale.


And I think 2 more innovation might as well be thrown in.
4. A distributed trustless way to communicate price of coin against USD. (Solved)
5. A way to inject oracle data into the blockchain so scripting has value (easy)

Anyway hoping to lay out my microcoin in a doc soon but I can't wrap my head around how to play nice with bitcoin... sidechain altcoin etc... what would you guys do?
TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420


View Profile
May 11, 2015, 01:02:50 AM
 #23839

Surely the vitamin D3 is working because of the intense volcano energy I feel right now if one of those detractors would join me in the boxing ring right now.

But I have numb legs today from the knee down and a mild gut pain. But other than that, I am strong enough today. This is a significant improvement over March, where I couldn't even think or keep my body up out of bed most of the time.

Totally OT at this point, but upping your Vitamin D3 intake means you also need to keep your electrolytes in balance. If you start feeling sore muscles or inexplicable fatigue, that's your cue to load up on minerals. After I upped my D3 intake to 5000 IU per day, I also started supplementing 250mg magnesium oxide, 1000mg potassium chloride, and 2000mg sodium chloride.

I can't even afford the time (and expense) of travel to a first world country to get a proper MRI and have my blood work and panels properly monitored and interpreted. As I said, "my back is against the wall". I need to be very careful about minerals because I am dosing 50,000+ IU per day, thus I am at risk of kidney stones and permanent renal damage due to concentration of minerals in the kidneys. So I am drinking 2 - 3L of water a day to flush them out continuously. I am craving foods, so clearly my body wants to replenish. I am in a tropical country and eating natural whole foods too, so hopefully I'll be okay. I feel I've turned the corner. Today I am feeling very strong and want to get to the gym. I am feeling a slight lethargy today in my head, yet I also feel an energy reservoir that is ready to explode at the gym. For me, these are signs of my original self, so I am encouraged. Thanks again for the sentiments. We can stop this OT discussion now.

TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420


View Profile
May 11, 2015, 01:10:21 AM
 #23840

So that is one argument that can be made against the pool's having control. Note it doesn't impact my other upthread (and very on topic) point that larger blocks favor centralization because higher orphan rates do.

larger bloat blocks have a higher chance of being orphaned

I reiterate my upthread point that higher orphan rate favors larger pools because they will be better connected (don't forget the NSA has direct taps on major trunk lines and the high-speed traders on Wall Street have this superior connectivity too) and thus mine on orphaned chains less, thus have high profits for their miners, thus driving more miners to them and making the smaller pools go bankrupt. This is a variant of the selfish mining effect.

Thus I will repeat again that larger blocks = centralization.

I hope that is clear now, since apparently you didn't get it the first time and apparently ignored or didn't understand me?

(if you did ignore before, covering your ears won't help you)

My radical re-design totally eliminates the issue of orphans and the critical advantages of connectivity latency. It is a radical paradigm shift that solves the problem that Bitcoin was designed to be centralized and there is nothing you can do within Bitcoin's current design to stop that! (I will elaborate soon)

Add: and the key point of distinction is that in Bitcoin in order to get a transaction to have a confirmation then it must be put into a block. In my novel new design, transactions don't have to be put in blocks in order to be confirmed. That is a very strong head scratching hint for you!

well that'll be a trick b/c the blockchain is Satoshi's fundamental contribution to tx security that was missing for all these decades of digital money formation.  each block cements the tx's into the chain via POW.  

you need to elaborate on your purported innovation to have any meaningful discussion.

Wink its a puzzle and you took the expected path into the maze and that is why you did not solve it. Epiphanies are like that. Yes I will have to elaborate but I am not going to give away such a valuable insight for free. I'd rather implement and profit. Wouldn't you?

You'd be crazy not to invest.

Yes it is a trick. The key insight is into how to make things orthogonal with a clever twist. I must admit, the more I think about it, the less obvious it is. I do have the antithetic weakness of the Dunning-Kruger syndrome, "Conversely, highly skilled individuals tend to underestimate their relative competence, erroneously assuming that tasks which are easy for them are also easy for others.".

For $10,000 investment and promise of secrecy, you can find out now.

Note my Bitmessage is not functioning on my new ISP, so anyone that wants to talk with me should PM me then we will go into encrypted webchat (very easy just load a webpage and chat).

Pages: « 1 ... 1142 1143 1144 1145 1146 1147 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189 1190 1191 [1192] 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 ... 1560 »
  Print  
 
Jump to:  

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!