here we go CIYAM calling everyone stupid all day again.
The vote was called stupid and I agree with CIYAM. There will be nothing learned from the results because we cant know whether a single person voted 10 times. the votes are not cryptographically verified? O_o! |
|
|
|
a fee of 5¢/transaction isn't so burdensome, is it?
5¢ makes things like mixing coins expensive and suddenly anything less then 5$ TX is not as fun to do also its not so much the cost that bothers me its the fact that it make newbies lives harder. we never use to have " My TX is taking forever to confrim " threads before, and i wish they would go away. lets not forget that ~90% of TX on the network today are low value... i would assume the 5¢ fee is already prohibiting all kinds of legit TX that would otherwise take place on the blockchain. |
|
|
|
I assume hardware is always getting better because HELLO! and libsecp256k1 offers 5x validation speeds.
Ah, I shall research these but they both sound like software to me. Hmm, unless "HELLO!" isn't software and you were just indicating that faster hardware is just so obvious. Certainly faster hardware is coming at us; but a quadratic growth problem will *always* out scale even the greatest conceivable hardware. A linear improvement in the software is always appreciated but again it is *only* linear (even if it is a massive 5x) as compared to quadratic growth, i.e. n². For example, suppose it takes t amount of time to process one sigop. Then a transaction with n sigops will take approximately n²*t amount time. Now we unleash the mighty libsecp256k1 5x improvement. So, we have n²*(t/5). When n is small this is great news. For example, 1²*t vs. 1²*(t/5) or 1t vs. t/5 gets us the full 5x advantage but 10²*t vs. 10²*(t/5) or 100t vs. 20t is still taking 20t and not 10t let alone 2t to do those 10 sigops. Moreover, 100 sigops works out to 10,000t vs. 2,000t; and who wants to compute 2,000t for just 100 sigops? Honestly/sincerely I am utterly delighted at the 5x offered by libsecp256k1 but against quadratic growth it pales. 1)how insane would a TX have to be to make it so validation time is hindered? 2)can we simply ignore TX that are that crazy? 3) is it conceivable that a legit TX would be that crazy? i have no clue my guess is 1) extremely insane 2) yes 3) no but guessing is not cool, would be nice if some math could back up me up. |
|
|
|
Breaking out ?
Tzupy called it. |
|
|
|
|
we need to get Gavin and Vladimir in the same room and ask them these questions.
I think you'll see that the reason they disagree isn't because they disagree about technical limitations but rather different visions.
One believes bitcoin full nodes need to run on a Raspberry pie the other doesn't think thats necessary.
|
|
|
|
To scale we must either;
1) have fast enough hardware
2) improve the algorithm, i.e. verify without pairing
3) verify in the background (although the verification has to happen sometime)
4) constrain the sum of sigops/transaction in a block
Can someone please provide an example of transaction that requires two or more sigops?
this is a none issue #1 #2 is has already been done it's not like these crazy computational intensive TX are legit, you only get into trouble if you try to allow this crazy spam like TX with thousands of inputs. miners are allowed to orphen a block for ANY reason. I think it's perfectly valid to not allow spam TX designed to slow down validation time of the block. 1) Oh? What speed hardware can handle what number of sigops? With quadratic growth eventually some number of sigops will exceed the capacity of any conceivable hardware. 2) Please help me understand; I am not aware of this development yet. So, each input comes with a sigop; I see, actually that makes perfect sense. Hmm, would it make any sense to create a number of smaller transactions that consolidate the many inputs? Perhaps it would be possible/better to avoid creating addresses with small amounts in the first place. Just trying my best to understand. I appreciate your patience and efforts. i dont know the details... I assume hardware is always getting better because HELLO! and libsecp256k1 offers 5x validation speeds. |
|
|
|
the lighting network will require bigger blocks too....
According to the wallpaper it will be able to accommodate 30 million users at a 1 MB block size limit. with the 1MB blocks currently all full, i seriously doubt thats true. what happens when a payment channel with 10,000TX needs to be settled on the blockchain? |
|
|
|
|
summary : " poeple are so dumb you can hand them piece of paper call it money and it works! why would we need bitcoin ? "
|
|
|
|
|
everything you hear about why we shouldn't increase blocksize is a bullshit excuse to delay the inevitable. the lighting network will require bigger blocks too....
we simply have to do this, the only thing to discuss now is when, thats all.
core says 1 year because they want the fee market to grow, and get poeple to come to there second layer solution sooner rather than later.
they would have us keep bitcoin first layer always 1 step behind, so that the second layer solution is attractive from day 1.
if you can't see this reality then you haven't done enough digging.
|
|
|
|
A transaction will have one or more sigops (signature operations). Let's denote these as S1, S2, ..., Sn. Apparently verifying these involves considering pairs, e.g. (S1, S2), (S1, S3), ..., (S1, Sn), (S2, S3), (S2, S4), ..., (S2, Sn), ..., (Sn-1, Sn). This leads to quadratic growth of the compute time. To avoid running behind the live stream of blocks, transactions are limited in size; they cannot span multiple blocks. Furthermore, the block size is limited; currently to 1MB.
The least compute intensive block is composed of a single transaction with only one sigop. The most computational intensive block is also composed of a single transaction but with as many sigops as will fit. A block with two or more transactions will be less computational intense. A block full of many transactions, each with just a single sigop, is minimal in terms of compute power required to verify it.
Let's denote transactions, Tk, where k is the number of sigops. A block is composed of a set of transactions, (Tk1, Tk2, ..., Tkn). The verification time is then approximated by K12+K22+...+Kn2.
To scale we must either;
1) have fast enough hardware
2) improve the algorithm, i.e. verify without pairing
3) verify in the background (although the verification has to happen sometime)
4) constrain the sum of sigops/transaction in a block
Can someone please provide an example of transaction that requires two or more sigops?
this is a none issue #1 #2 is has already been done it's not like these crazy computational intensive TX are legit, you only get into trouble if you try to allow this crazy spam like TX with thousands of inputs. miners are allowed to orphen a block for ANY reason. I think it's perfectly valid to not allow spam TX designed to slow down validation time of the block. |
|
|
|
|
here we go CIYAM calling everyone stupid all day again.
|
|
|
|
when segwit is delayed, miners will bypass Core and push 2MB blocklimit on us early. everyone will cheer! "We have the power!" we will all feel much better, knowing bitcoin's destiny isn't in the hands of a handful of devs employed by blockstream, and then ... well then ... hahaha  |
|
|
|
just thought i'd share this with you altcoin folk ( wrote it myself )  ehehehhehhe |
|
|
|
|
I hope these stupid meme didnt offend anyone, i can't stop LMAO. life's too short to be serious all the time, if you can't laugh at yourself, call me i'll do it for you.
|
|
|
|
|
these meme are for lolz and do not reflect the opinions of adamsgbit.
|
|
|
|
|
Show Posts
