adam440 (OP)
Jr. Member
Offline
Activity: 44
Merit: 1
|
|
March 03, 2017, 08:36:04 PM |
|
Hello, I have only a little knowledge about these scaling solutions so I want to ask if it's possible to somewhat combine these two solutions. Like, change the transaction protocol according to SegWit to allow off-chain solutions (Lighting Network) while letting the miners choose a size of the block. Is this possible?
|
|
|
|
Foxpup
Legendary
Offline
Activity: 4368
Merit: 3061
Vile Vixen and Miss Bitcointalk 2021-2023
|
|
March 04, 2017, 02:19:20 AM |
|
Lightning does not require SegWit, and SegWit already is a compromise on block size by increasing it to 4MB.
|
Will pretend to do unspeakable things (while actually eating a taco) for bitcoins: 1K6d1EviQKX3SVKjPYmJGyWBb1avbmCFM4I am not on the scammers' paradise known as Telegram! Do not believe anyone claiming to be me off-forum without a signed message from the above address! Accept no excuses and make no exceptions!
|
|
|
achow101
Moderator
Legendary
Offline
Activity: 3402
Merit: 6659
Just writing some code
|
|
March 04, 2017, 02:32:46 AM |
|
Because those who know segwit well enough to implement it and change it do not like BU and thus do not know BU well enough to implement both Segwit and BU in a client. Nor do those people want to because they think that BU is a stupid idea.
Those who know BU well enough to implement it and change it do not like Segwit and thus do not know Segwit well enough to implement both BU and Segwit in a client. Nor do those people want to because they think that Segwit is a stupid idea.
|
|
|
|
HCP
Legendary
Offline
Activity: 2086
Merit: 4316
<insert witty quote here>
|
|
March 06, 2017, 09:33:49 AM |
|
Sadly, it has got to the point where personal pride and stubbornness appears to be getting in the way of what is best for the network and it's users... Neither side wants to admit "defeat" and both think they have "The Best Solution"™ to the issues currently facing the network. In my opinion, SegWit isn't really trying to compete with BU directly... is it an attempt to fix some other issues (transaction malleability etc) and the increase in blocksize is more of a side effect than the main goal. BU seems to be solely focused on increasing the blocksize. Meanwhile, the mempool has been well over 30K transactions for almost a week... and everyone is "suffering"... hopefully, one side or the other will prevail soon so at least we'll find out if one of the solutions works (if not, we can always just try the other I guess )
|
|
|
|
JackH
|
|
March 06, 2017, 10:33:31 AM |
|
There is no need to compromise with BU. It is a broken implementation that gives miners power to decide block sizes and is nothing but a political tool invented by those that want to see Bitcoin become centralized. Why would anyone compromise when the solution that is ready is superior in every way and also increases block size?
|
<helo> funny that this proposal grows the maximum block size to 8GB, and is seen as a compromise <helo> oh, you don't like a 20x increase? well how about 8192x increase? <JackH> lmao
|
|
|
DannyHamilton
Legendary
Offline
Activity: 3402
Merit: 4656
|
|
March 09, 2017, 02:00:29 PM |
|
- snip - I want to ask if it's possible to somewhat combine these two solutions. - snip - Is this possible?
You are dealing with a very political problem, not a technical one. You can see this in that 5 people all responded to your thread already and NONE of them answered your question. Instead, they ALL gave you answers about why they think it shouldn't be done, or why they think nobody will do it. The simple answer to your question is: YES. It is technically possible. There is nothing about SegWit that makes it technically impossible to also implement Unlimited, and there is nothing about Unlimited that makes it technically impossible to also implement SegWit.If anyone eventually choose to do so, we will probably just fragment the system even more. You'll some some users that hate SegWit and will ONLY run Unlimited, some users that hate Unlimited and will ONLY run SegWit, some users that hate BOTH and will refuse to upgrade beyond Core version 0.12, and some users that don't care and are willing to run your "compromise". This isn't a problem that is going to be fixed by introducing more options to fight about. Bitcoin is quite possibly destined to tear itself in half. Either there will eventually be a fork with two chains each trying to call themselves the REAL bitcoin, or a very charismatic person will show up that convinces an overwhelming majority to agree on something. All the trolls and zealots in all the discussion forums only make the fork with two chains each trying to call themselves the REAL bitcoin more likely. They'll all blame "the other side" if it all falls apart, it's always easier to be angry at what someone else did than feel responsible for one's own actions.
|
|
|
|
Carlton Banks
Legendary
Offline
Activity: 3430
Merit: 3074
|
|
March 09, 2017, 02:28:56 PM |
|
You are dealing with a very political problem, not a technical one.
The simple answer to your question is:
YES. It is technically possible. There is nothing about SegWit that makes it technically impossible to also implement Unlimited, and there is nothing about Unlimited that makes it technically impossible to also implement SegWit.
Then why not say that, then shut your mouth? Every other part of your post is simply subtle politicking, as if you're somehow the voice of reason if you say "I'm the only one who says this is political", when in fact at least 2 other posters have made the same essential point already (demonstrating you're manipulating the narrative to make yourself appear trustworthy, pah) Danny's post is covertly political, he publicly states that BU is actually an attempt at a genuinely intended dynamic block sizing concept, but really it's just a dressed up way of allowing miners to entirely control the blocksize, and to cut the honest hardworking professional software developers out of Bitcoin development. Danny never addresses any of this, he simply says "I don't do politics" when invited to discuss the technical "merits" of BU If Danny was really interested in the technical argument, he would be mentioning the serious technical attack vector that BU represents. But of course, because no real Bitcoin users are actually interested in having any aspect of what should be a system with limits becoming unlimited, Danny has no choice but to continue the social engineering attack on Bitcoin instead (currently the only effective attack against it)
|
Vires in numeris
|
|
|
LabaDaba
Member
Offline
Activity: 97
Merit: 10
|
|
March 09, 2017, 04:34:51 PM |
|
Exactly chinese miners and miner mafuf. trying to take over BTC. Main traitor Bitmain.
|
|
|
|
mwizard
|
|
March 10, 2017, 05:45:30 AM |
|
Lightning does not require SegWit, and SegWit already is a compromise on block size by increasing it to 4MB.
Couple of comments. SegWit does not change the actual block size. It stays at 1 MB. That is why SegWit is a soft fork. Nodes running older versions will still accept it. SegWit moves some data out of the block so that more transactions can fit into a 1 MB block. The various versions of Lightning need SegWit to fix transaction malleability. It will be very difficult to introduce a version of Lightning if this is not fixed.
|
|
|
|
|
cellard
Legendary
Offline
Activity: 1372
Merit: 1252
|
|
March 10, 2017, 03:13:50 PM |
|
After reading a lot about BU and segwit, the problem with your proposition is the fact that BU just doesn't work. There is not a single "flexible blocksize" approach that properly works without opening nasty cans of worms. Therefore, the conservative approach is still the preferred one.
|
|
|
|
andron8383
|
|
March 12, 2017, 08:42:29 PM |
|
After reading a lot about BU and segwit, the problem with your proposition is the fact that BU just doesn't work. There is not a single "flexible blocksize" approach that properly works without opening nasty cans of worms. Therefore, the conservative approach is still the preferred one.
Better would be hard limit increase. But now we have to deal with block size. solution like: -we group blocks into superblocks like 5000 packages every node have to keep last 3 superblocks -every time when we create superblock we create balance sheet for all adresses -superblocks have to have conections between each other that you could use all from day 0 and be sure that you use good one superblock - in such sytuaction blocksize doesn't matter so much and we can grow in size and transaction time. 2nd solution would be 3rd party layers to blockchain
|
|
|
|
seradj0
|
|
March 14, 2017, 06:28:52 PM |
|
So we are facing a HF I guess no !?
|
Geek,
|
|
|
by rallier
Legendary
Offline
Activity: 1848
Merit: 1334
just in case
|
|
March 15, 2017, 02:25:42 PM Last edit: March 15, 2017, 03:06:23 PM by by rallier |
|
If Chinese miners don't want to accept SegWit because of possible network issues, still we dont need to Bitcoin Unlimited. Bitcoin Developers can develop new adaption like bitcoin block timing reduce to 2 minute (now 10 minute) and bitcoin block bounty can be reduced %50^5 percent. Doesn't change on ecosystem edit: I opened a thread discuss to my suggestion : https://bitcointalk.org/index.php?topic=1827943
|
signature not found.
|
|
|
Carlton Banks
Legendary
Offline
Activity: 3430
Merit: 3074
|
|
March 15, 2017, 03:21:30 PM |
|
You're late to your own discussion by several months, this is not an original suggestion. The block interval target is 10 minutes for important reasons: orphan rate, inherent latency of TCP/IP networks etc. It's also a hard fork change, and so much more could be done with any hard fork that relegates the importance of reducing the block interval target. It's not the worst idea, but you're not really contributing anything useful by bringing this up for the Nth time.
|
Vires in numeris
|
|
|
BitUsher
Legendary
Offline
Activity: 994
Merit: 1034
|
|
March 15, 2017, 03:51:29 PM |
|
Hello, I have only a little knowledge about these scaling solutions so I want to ask if it's possible to somewhat combine these two solutions. Like, change the transaction protocol according to SegWit to allow off-chain solutions (Lighting Network) while letting the miners choose a size of the block. Is this possible?
Miners can and already and do set the size of the block with soft limits , users set the upper end of the hard limit though . Giving miners control of the blocksize would centralize mining , set a bad precedent that the miners control validation rules and not economic users, and not account for externalities like the cost of nodes on processing the blocks leading to node drop off and centralization. Essentially creating paypal 2.0 with a mining cartel , where everyone eventually is forced to trust third parties instead of validating their own txs. So , no thank you.
|
|
|
|
hv_
Legendary
Offline
Activity: 2520
Merit: 1055
Clean Code and Scale
|
|
March 16, 2017, 07:10:22 AM |
|
Hello, I have only a little knowledge about these scaling solutions so I want to ask if it's possible to somewhat combine these two solutions. Like, change the transaction protocol according to SegWit to allow off-chain solutions (Lighting Network) while letting the miners choose a size of the block. Is this possible?
Miners can and already and do set the size of the block with soft limits , users set the upper end of the hard limit though . Giving miners control of the blocksize would centralize mining , set a bad precedent that the miners control validation rules and not economic users, and not account for externalities like the cost of nodes on processing the blocks leading to node drop off and centralization. Essentially creating paypal 2.0 with a mining cartel , where everyone eventually is forced to trust third parties instead of validating their own txs. So , no thank you. What is your very balanced counter offer ? SW + 2nd layer where 2nd layer will turn out to be the very same you not want?
|
Carpe diem - understand the White Paper and mine honest. Fix real world issues: Check out b-vote.com The simple way is the genius way - Satoshi's Rules: humana veris _
|
|
|
Balthazar
Legendary
Offline
Activity: 3108
Merit: 1358
|
|
March 16, 2017, 07:57:49 AM |
|
It's a natural resistance against Chinese coup d'état. No compromise should be made in such situation, no sane person would make a deal with terrorists.
|
|
|
|
hv_
Legendary
Offline
Activity: 2520
Merit: 1055
Clean Code and Scale
|
|
March 16, 2017, 09:13:13 AM |
|
It's a natural resistance against Chinese coup d'état. No compromise should be made in such situation, no sane person would make a deal with terrorists.
It's a natural resistance from (Chinese) miners against blockstream terrorists. Just two ways of view. (Hard for many here to see both, since most just are simple users and don't care about miners investments) BTW: Miners do safe the blockchain and your bitcoins. They play it well as we see.
|
Carpe diem - understand the White Paper and mine honest. Fix real world issues: Check out b-vote.com The simple way is the genius way - Satoshi's Rules: humana veris _
|
|
|
mezzomix
Legendary
Offline
Activity: 2618
Merit: 1253
|
|
March 16, 2017, 09:55:49 AM |
|
Miners Pools ... play it well as we see.
SPV Mining is the opposite of playing well!
|
|
|
|
|