|
oh and that "replace by fee" bullshit
ya sorry todd
go fuck yourself.
|
|
|
|
idk wtf you guys have been saying. frankly i dont give a fuck. we know what we want! we know these FUCKING devs are just pounds in OUR game we WILL HAVE bigger blocks WE will have some form of Sedgwick and all the good things that come with it. NO WE WILL NO SETTLE FOR ANY COMPROMISE we know this is possible!  |
|
|
|
|
We need bigger blocks... lets all just run le BU
|
|
|
|
|
this is the "we are going nowhere, i'm out" bear trap. likely to be unimpressive...
|
|
|
|
i should have sold at 1240  |
|
|
|
i dont believe the idea that bitcoin will become an immutable protocol i dont buy the bullshit iamnotback is saying about the "whales" and you know what i dont even care what the whales think, let them dump on the chain i believe to be valid, and let see how that works out for them.  I WANT TO FORK YOUR MOTHER!!!!!!!!!! |
|
|
|
iamnotback is WRONG!  also you too xhiggy... economic majority is EVERYTHING! the white paper simply assumes that hashing power would always at least Represent the will of the economic majority, short of being economic majority. the longest chain is meaningless if its not valid and the definition of "valid" can and will change. imagine 85% of the hashing power started to produce empty blocks, all day long forever. this will severely cripple bitcoins ability to TX, 1 or 2 new rules will be required, somthing like blocks cannot be empty, and blocks must be mostly filled with TX that are in most nodes mempools, or somthing. in that case a UASF is easily achievable. and we could very well get in a case where we fork off with minority hashing power and minority node count ( because under sybil attack ) and STILL WIN! @iamnotback no i do not give a SHIT if the economic minority throws a hissy fit and manages to bring us cheap coins!!!!! For a short while... welcome to the blockchain lets FORK! |
|
|
|
|
i would open a church and preach things like:
" thou shall mine! "
" let he who has never bought an altcoin sell the first bits"
" Let there be consensus and be happy "
|
|
|
|
I offer 0.9BTC for your BTC ill pay the TX fee  |
|
|
|
do you even know what core is?
core is 2 things. 1) master of bitcoin 2) slave of blockstream  |
|
|
|
You are comparing apples with pears. The two solutions don't have to be mutually exclusive, and could be used complimentary. What is the best technical method of implementing these solutions?
No. I'm comparing healthy apples to rotten ones. You need a soft fork + hard fork or a hard fork that incorporates both at the same time. This is the project that you're looking for: https://bitcoinec.info/Do you not think segwit could be a better implementation as a hard fork? Perhaps it could even learn some lessons from classic's flextrans features. And BU's implementation of EC could be considered over complicated, and a better KISS solution could be used. https://bitcointalk.org/index.php?topic=1864477.msg18541674#msg18541674poeple think EC is complicated, because the crazy scenarios in which EC could be leveraged to attack the network, are complicated as hell. EC is itself is quite simple... |
|
|
|
soft fork + hard fork or a hard fork that incorporates both at the same time. This is the project that you're looking for: https://bitcoinec.info/this is almost perfect. almost... its needs to revert all of segwit's "blockweight" aspects, and let EC determine the blocksize exclusively. however their reasoning for letting segwit in AS IS, is a pretty Fing good reason... I like this project. |
|
|
|
The idea behind UASF is to persuade/influence/ miners to fork, but
the problem is that anything except hash power is relatively inexpensive
to spoof. So, this goes against the philosophy of Bitcoin PoW.
right, but get mostly everyone, bitfinex, stamps, bitpay etc. all supporting USAF, and its not ambiguous and the idea of "spoofing" is a non issue. its not inconceivable that with a minority hashing power and a minority node count, a UASF is successful and carries with it the BTC brand. |
|
|
|
with HF segwit, it should be possible to not add this ugly prefix. ( i wonder if its just us die-hard-bitcoiners that would notice the prefix changed)
I think you still need to change the format because of the old Bitcoin addresses. Good thing about the new format is it's all lower case. Plus has a bunch of error correcting stuff, so if you type in a couple letters wrong it can correct it for you. poeple actually type out these addresses?!?! ( i might do that once in a full moon to get into a paper wallet ) i think, BU proposes similar kind of change along side hf-segwit https://bitco.in/forum/threads/buip045-unified-addresses-format-for-buip037.1725/I commented first with reasons why i dont like it. i think these are legitimate reasons... of course devs are like " oh thats a silly argument " |
|
|
|
can someone explain what is meant by "native key"
you mean people who choose to stick with the current/old TX format, in the context of SF only? right?
Yeah, old Bitcoin addresses. Segwit addresses look like this: bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4 Don't complain! atleast luke-jr didn't push for "tonal addresses" oh no, prefixed with bc1  no no no this doesn't look right anymore. i guess its unavoidable to add a new prefix to addresses in the context of a soft fork, since users nodes need to know if they are sending to segwit address VS native address with HF segwit, it should be possible to not add this ugly prefix. ( i wonder if its just us die-hard-bitcoiners that would notice the prefix changed) |
|
|
|
|
can someone explain what is meant by "native key"
you mean people who choose to stick with the current/old TX format, in the context of SF only? right?
|
|
|
|
but its not..
only those people who use segwit keys are disarmed from quadratic spamming . but native key users are not.
thus spammers can just stick to native kys and spam the base block ..
thats why keeping a tight grip on txsigop limits is still needed as a ultimate solution FOR EVERYONE native or segwit key users
Native keys can spam away at their 1MB block all they want. Segwit keys can take advantage of the extension blocks. Or you could do what the one BU dev proposed and go full out hardfork segwit and block native keys and switch everyone over to segwit keys and increase the base block as much as you want, but blocking native keys is a real dirty solution. dirty isn't the right word. code wize, HF is cleaner by definition, its just very shitty that it forces the upgrade. I wonder if a sorta Soft & Hard fork would be possible, in that it would initially be soft, but once 98% of nodes are upgraded ( like ~1-2years out?? ) the softness is dropped and it become hardforked in, at which point its no biggy. best of both worlds? |
|
|
|
Flextrans (which is bundled with Bitcoin Classic btw) solves mallaebility and quadratic hashing ,
arguably better than segwit.
right, Flextrans is an interesting proposal that come up few months back. i'm on the fence between Flextrans or HF-segwit for the wanted malleability and quadratic hashing fixes for BU. altho I have not completely given up on the idea of a simpler SF for segwit, but there Appears to be some drawback with doing it soft as OP mentioned... form what i see BU community is unwilling to let these disadvantages slip though simply for the sake of SF'ing |
|
|
|
|
In a perfect world we'd get EC for blocksize + Core's segwit for mall&quad fix and everyone would be equally discontent.
|
|
|
|
|
seriously, do you trust what they tell you?
|
|
|
|
|
Show Posts
