So who the hell is still supporting BU?

[Lauda]

Well at least they have solved the communication issue with a voting system (to filter out trolls and shills), and the final consensus thing is similar to that of bitcoin.

They solved nothing. If anything, they've made their system even more centralized and favorable to large capitalists.

416 contributors, but only 24 working in the last month.

Considering that this is the critical moment for Bitcoin scaling, yet people are not very eager to work on it.

Why would they work on that specifically when they have provided a near-future 'solution'? This is also ironic because it shows your lack of knowledge. Bitcoin Core has entered feature freeze in January. In this phase, no new features will be merged as the release of 0.14.0 is being prepared.

But looking at the current situation, we have 5 million sheeps who expect answers from 24 people. That is a very centralized system.

You mean working on Rootstock, Lightning, Mimblewimble, Joinmarket et. al = not working on Bitcoin? If you think that, you don't even understand decentralization.

Bitcoin starts to look very ugly.

The only thing I see in this thread (ignoring the trolling and pseudo-science) here is your lack of knowledge and perspective.

[1714775459]

1714775459

[1714775459]

1714775459

[1714775459]

1714775459

[1714775459]

1714775459

[aarturka]

Seems unlimited steadily dying, only 4,7%  267 nodes have left https://bitnodes.21.co/nodes/.

[franky1]

i have even asked hm to learn some basic concepts that dont need code skills such as consensus vs bilateral.
-snip-

Fun fact:
Standard orphans are not the same as the invalid block which was mined by a BU pool the other day. Yet you keep pushing this pseudo-explanation of the situation.

more buzzword nonsense.

firstly an orphan does not need to have a parent rejected for the child to be an orphan.
EG a parent can exist and still live.. but decided to give up the child.. for the child to be an orphan.. so even rejects can in real world life, be an orphan.

yep rejects are orphans too. (once you get away from cores buzzword nonsense and think about things in real life laymans english)

Bu's block was thrown aside in 3 seconds.. end of drama.. just like other rejects
the problem was not the block.. but CORES excessive banscore. which over reacted and banned nodes for handing it to other nodes.
the simple thing is without the banning of nodes.. the reject would still have been a reject and nothing different would have come of it.
(gone in 3 seconds)

2017-01-29 06:59:12 Requesting block 000000000000000000cf208f521de0424677f7a87f2f278a1042f38d159565f5
2017-01-29 06:59:15 ERROR: AcceptBlock: bad-blk-length, size limits failed (code 16)

it was a non-event, until it was over dramatised due to excessive banscore utility by core nodes which is cores failure where CORE would have been the cause of a bilateral split by CORE banning nodes when CORE didnt need to ban nodes.

[franky1]

Why would they work on that specifically when they have provided a near-future 'solution' temporary gesture?

fixed that for you

You mean working on Rootstock, Lightning, Mimblewimble, Joinmarket et. al = not working on Bitcoin? If you think that, you don't even understand decentralization.

you do realise what LN does... its a contract AKA permissioned funds locked in. and even after settlement confirmation there is a few hour-days maturity lock (like banks 3-5 day balance unavailable(CLTV maturity)) and changes of the counter party revoking funds while immature(like banks chargeback(CSV revokes))

please learn these things.

mimblewimble wants to have something similar to CSV revokes, to take random peoples outputs, spend them (in a mixing service) even without the peoples consent. and then people have HOPE the mimble wimble manager puts the exact same amount back into peoples addresses. thus making the old block empty of unspents (oops i mean UTXO's) so that the old block can be pruned while offering a mixing service aswell.
yes it seem god the glossy pamphlets says pruning and mixing in one.. but you have to understand your allowing a mimble manager access to move your funds without you.. to achieve this.

also mimble wants to add confidential payment codes (oops confidential Pedersen commitments) which would make a standard say 450byte tx be well over 1kb.. even if the number of inputs/outputs dont change. = BLOATED TRANSACTIONS

this is why even after segwit is activated, which lauda knows only BEST expectations of this one time gesture offering 2.1mb (if 100% utility) the other 1.9mb of weight. is not to further allow more transactions.. but to allow the BLOAT of CPC (oops confidential Pedersen commitments)

yep best expectation if 100% of people swap ovr to use p2wpkh or p2wsh keys is
~4500tx for 2.1mb
later
~4500tx for 4mb but with CPC

but i do not expect to see ~4500tx when looking at the real stats of how fast people move funds or how fast people change over to new types of keys

p.s. i now expect a explosion of personal attack trolls trying to get people not to read the context of my posts. rather than rational replies rebuttling the context by showing real knowledge of concepts and code (eg 'your wrong because troll')

[RealBitcoin]

They solved nothing. If anything, they've made their system even more centralized and favorable to large capitalists.

Well I would disagree here, and maybe this is the borderline between left and right in Bitcoin.

I would have no problem with a POS system that lets node vote based on their capital %, running a cryptocurrency like a decentralized corporation.

Without board members or CEO, just shareholders voting based on their % share, versus a node system where everyone can setup a node, and poor people could outvote rich people.

Its only a question of time until leftists take over BTC.

Why would they work on that specifically when they have provided a near-future 'solution'? This is also ironic because it shows your lack of knowledge. Bitcoin Core has entered feature freeze in January. In this phase, no new features will be merged as the release of 0.14.0 is being prepared.

Then they should work on the other clients to have a decentralized software marketplace.

If people claim that BU sucks, then why arent more devs working on it to improve it?

You mean working on Rootstock, Lightning, Mimblewimble, Joinmarket et. al = not working on Bitcoin? If you think that, you don't even understand decentralization.

They are good projects I dont believe they address the biggest problem that the system has.

I would like to see some onchain scaling at some point in time.

The only thing I see in this thread (ignoring the trolling and pseudo-science) here is your lack of knowledge and perspective.

My perspective would be decentralization, but I dont see that, I only see more and more centralization.

Whether by exchanges (big ones  eating up small ones due to regulation compliance requirements), centralized wallet providers, centralized development, etc....

This is not the same vision that satoshi had in 2009.

[cellard]

Here is a good and simple comparation chart on Bitcoin unlimited and Segwit and why Bitcoin unlimited is a shitty option compared to going the Segwit route:



It's pretty obvious that Bitcoin unlimited is an stupid and unnecessary risk that would ruin the project.

[franky1]

Here is a good and simple comparation chart on Bitcoin unlimited and Segwit and why Bitcoin unlimited is a shitty option compared to going the Segwit route:



It's pretty obvious that Bitcoin unlimited is an stupid and unnecessary risk that would ruin the project.

LOL wow show a pretty picture.

please learn consensus.
nodes should have the power, not miners not devs.

its CORE that has avoided true consensus. but luckily thats why 60% of pools (not funded by same group as blockstream(DCG)) are waiting for nodes to have decided even if core think nodes shouldnt decide.

pools wont push for something that nodes wont fully validate and accept. (yes they can accept but right now 50% cant validate segwit)
but core think validation is not important hence why they are stroking the sheeps wool to say its ok for the sheep not to upgrade nodes.

which ends up leaving (right now 50%) of nodes unable to fully validate the new feature. which pools know is an issue.
it should have been a node consensus first, pool consensus second.

core dont care because they have FIBRE that make core the gatekeepers of the network (oops i mean upstream filters) where other nodes are less important and basically there just to relay and store data (in cores eyes)


but by doing a hard(node then pool) full consensus event.. would have meant while getting nodes to upgrade, those node users would have asked for core to have dynamic block code included(2 birds one stone event). which ofcourse core would refuse.

but by going soft, (pool only) half consensus event.. core are left waiting for the undecided pools to be confident about the node count of full VALIDATION, before pools will even flag to make blocks that include segwit.

cores motive.. if things go wrong in CORES strategy. blame the pools. if it goes right. core take the glory. (nice bait and switch)

[C0RE]

nodes should have the power, not miners not devs.

I agree but more nodes supports segwit and only few unlimited. and unlimited is more favorable for greedy miners, that's why we must push segwit. For the sake of decentralisation and consensus

[franky1]

I agree but more nodes supports segwit and only few unlimited. and unlimited is more favorable for greedy miners, that's why we must push segwit. For the sake of decentralisation and consensus

1. pools cant push for higher size blocks unless nodes can cope. meaning its not centralizing nodes because its the nodes that decide what the network can cope with and reject what they cant. stop reading the r/bitcoin doomsday scripts of 'datacentres by midnight' or 'gigabyte blocks by midnight'.. those doomsdays are fake and illogical, used mainly to scare sheep to run into the wolfs den

2. even funnier part of the dooms day is this stupid tactic "fear non-core implementations, they want to create an alt.." .. "other implementations want consensus which we wont give them. lets instead tell them to fork off to an alt"
i hope you see the hypocracy in those 2 statements.
EG "fear your neighbour, he has a gun.. oops he doesnt, so lets shout at him to get a gun and hope he shoots someone."


3. segwit offers pruned and other features, which dilutes the number of full sync SEEDERS
   segwit also with the sidestepping of allowing nodes to consent/ be ready, dilutes the FULL VALIDATION status
   sgwit also allows nodes to not have to store signatures(-nowitness), which dilutes the FULL VALIDATION and FULL SYNC SEEDING
   segwit is the primer for LN, which if people are locked into LN they wont see need to run a full node 24/7, but run a LN node instead. diluting node count

core dont care. because they have changed the topology of the network with FIBRE being the gatekeepers (upstream filter) of the network. meaning CORE FIBRE nodes do the validating, which in their mind the other nodes are not required (which is centralizing the data to their 'brand'). yep they are even saying after segwit activation and they finally release a full segwit implementation (including P2WPKH/p2WSH wallet) that fibre/segwit nodes can 'whitelist' other implementations that are downstream but those downstream are not required to be gatekeepers/ the security guards of the network..
which again is about pushing core nodes to be at the centre of the network and other implementation left on the outer edges if they get lucky to be whitelisted.

try reading the documentation and code whilst wearing a critical /logical thinking cap. and not a fanboy cap.
dont thing about the limited benefits, promotional sales pitches.. look for the fine print limitations and realities.
EG
https://bitcoincore.org/en/2016/10/27/segwit-upgrade-guide/

In this configuration, you set your current Bitcoin Core node (which we’ll call the “older node”) to connect exclusively to a node running Bitcoin Core 0.13.1 or later (which we’ll call the “newer node”). The newer node is connected to the Bitcoin P2P network as usual. Because the newer node knows about the segwit changes to the consensus rules, it won’t relay invalid blocks or transactions to the older node—but it will relay everything else.

When using this configuration, please note that the older node, if it uses Bitcoin Core defaults, will not see transactions using segwit features until those transactions are included in a block.

Configuration:

For the newer node, start it normally and let it sync the blockchain. At present, you cannot use a pruned node for this purpose because pruned nodes will not act as relay nodes. You may optionally start the newer node with either or both of the following command line parameters so that it treats the older node as special (these options may also be placed in Bitcoin Core’s configuration file):

  -whitebind=<addr>
       Bind to given address and whitelist peers connecting to it. Use
       [host]:port notation for IPv6

  -whitelist=<netmask>
       Whitelist peers connecting from the given netmask or IP address. Can be
       specified multiple times. Whitelisted peers cannot be DoS banned
       and their transactions are always relayed, even if they are
       already in the mempool, useful e.g. for a gateway

For the older node, first wait for the newer node to finish syncing the blockchain and then restart the older node with the following command line parameter (this may also be placed in the Bitcoin Core configuration file):

-connect=<IP_address_or_DNS_name_of_newer_node>

[mezzomix]

nodes should have the power, not miners not devs.

Users should have the power, not miners not devs. This is why a change of the mining algorithm has the first priority with the next hard fork. A mining algorithm that requires the complete UTXO set plus all block entries within every round will prevent pool mining and simple number crunchers.

[Lauda]

Why would they work on that specifically when they have provided a near-future 'solution' temporary gesture?

fixed that for you

No, stop trolling.

you do realise what LN does... its a contract AKA permissioned funds locked in.

No, unless you want to severely twist the word 'permissioned'.

I would have no problem with a POS system that lets node vote based on their capital %, running a cryptocurrency like a decentralized corporation.

That is not a decentralized model. A model primarily run by capital has no decentralization.

Then they should work on the other clients to have a decentralized software marketplace.

No, they most certainly should not waste their time on those.

If people claim that BU sucks, then why arent more devs working on it to improve it?

Due to their absurd ideas that almost nobody supports.

They are good projects I dont believe they address the biggest problem that the system has.

Your belief, with your pseudo-knowledge (you've admitted it yourself; I'm not attacking you), has very little importance. If you want something "fixed" or changed, then go learn how to code and do it yourself.

My perspective would be decentralization, but I dont see that, I only see more and more centralization.

The exact opposite has happened. Are you really this uninformed, or are you cranking up your post count? Look back into 2013: 1) The mining pools; 2) The exchanges. They were much more heavily concentrated than they are now.

[franky1]

Why would they work on that specifically when they have provided a near-future 'solution' temporary gesture?

fixed that for you

No, stop trolling.

you do realise what LN does... its a contract AKA permissioned funds locked in.

No, unless you want to severely twist the word 'permissioned'.

if you dont understand the tech, please learn it before replying. and i do not mean you have read their sales pitch glossy version. but done the critical small print understanding of what is being promoted

for instance if you dont understand multisigs where you are no longer just signing your own tx and sending your own tx, but requiring a counter party to sign off on your transaction. that is needing their permission..
without them you have nothing.
it has some advantages but also disadvantages. atleast understand and be honest about both sides.
also please understand CLTV and CSV and understand the REAL WORLD end user experience of these and how they compare to paypal/banks 'issues' of the same end user experience.


its you trying to undersell/ sweep under the carpet.
atleast try to think about bing helpful to the real community by informing them of exactly what they are going to be getting involved it. honest critical thought means more to people than stroking their sheep fur, telling them its ok to go to sleep

[RealBitcoin]

That is not a decentralized model. A model primarily run by capital has no decentralization.

It's not run by capital, it's weighted by capital. Not the same thing.

The entry cost is still 0, so anybody can join, but only those that have a stake have their votes weighted by their stake.

The exact opposite has happened. Are you really this uninformed, or are you cranking up your post count? Look back into 2013: 1) The mining pools; 2) The exchanges. They were much more heavily concentrated than they are now.

Yes but look back before 2013 when everyone was their own pool, when people used to mine with CPU or GPU.

I could not find a chart of nodes before 2014, but it looks like the active nodes in a period has shrunk from 90,000 (2014) to 30,000 (2017)
https://bitinfocharts.com/comparison/nodes-btc.html

Plus countless people are now using centralized wallet providers like blockchain.info, or coinbase to store their coins, instead of a a desktop wallet where they control the keys.

This is what I am talking about, I am not uninformed.

[classicsucks]

I see a false dichotomy in this thread - Unlimited versus Core. There have been plenty of attempts to fork the Bitcoin blockchain and code, but as of yet, only Core's chain forks have been successful, and their (pre-0.13) source tree remains the de facto Bitcoin implementation. However, their latest attempt at a blockchain fork (Segwit) is failing. Unlimited has been around for awhile and isn't necessarily an optimal solution. However, it is currently blocking Segwit. Therefore it is well-placed to send the message to Core that people don't want Segwit. It's not about Unlimited versus Core, it's about "will Core listen to the requests of the miners and users"?

At any time, Core can request consesnsus on a hard fork (AS THEY HAVE DONE SUCCESSFULLY BEFORE ON AN EMERGENCY BASIS) to increase the blocksize, release a simple 0.12 version with blocksize increase, and this whole drama would be over in less than a week,  Core will be very stubborn for quite some time, of course - how often do open source projects roll back to a previous version and withdraw an entire feature?  Furthermore, their funding source depends on the Blockstream corporation that is heavily invested in LN, for which Segwit paves the way.

“It is difficult to get a man to understand something, when his salary depends on his not understanding it.”


If Core refuses to roll back, eventually technically competent devs other than core (or a splinter faction at Core who arent drinking the LN/Segwit Koolaid) will fork Bitcoin and people may adopt that fork. We can only wait for the Soviet Politburo so long...

[-ck]

Yes but look back before 2013 when everyone was their own pool, when people used to mine with CPU or GPU.

You're mistaken here. I've been writing mining software and mining since June 2011 and virtually everyone was mining on a pool back then. If you want to use that argument you need to go back to 2010 or earlier... basically before bitcoin became popular at all.

[franky1]

..

non-core implementations will only use CONSENSUS (try being specific, rather then using the 'fork' empty umbrella term) they do not intent to split they do not want to split they do not require a split they are not proposing a split. they want to use bitcoins consensus.

yep core have forked the chain. yep even Sipa caused a bug in 2013 which led to needing to roll back some blocks to fix his boo boo.

core have failed the community by not doing a node first pool second double consensus (hard consensus) because just doing a pool consensus single consensus (soft consensus) means the pools get to decide.
but even so, the smart pools/ethical pools will wait until nodes are happy even if nodes dont get a vote. purely because of the orphan risks if a bug pops up.

core want people to think its a core vs bu, king against king battle. when its not. its a COMMUNITY decision
there should be no king.. only nodes... who adjust based on the settings of the nodes. and the pools react to what the nodes will allow.

75% of the community are saying undecided or saying no (~60% undecided/ not keeping uptodate)
25% pool agreement
25% node have full latest running implementation

the rest are not uptodate or not decided either way (yes another 25% of nodes are 'compatible'. and 50% are 'acceptable'. but only 25% nodes are uptodate)

funny thing is even if nodes/pools did gather 95% pool votes, when it activates they still end up having to wait for another core release just to actually use p2wpkh/p2sh keys. meaning this whole give pools the power to vote first has issues. and even then its not an effective vote because nodes then have to re-upgrade to use the keys to see the benefit of the one time boost temporary gesture.

yep even with 0.13.2 people can still malleate transactions. even after activation at 95% people using 0.13.2 can still malleate transactions.
yep even with 0.13.2 you wont see any different to the transaction count after activation.

it requires another release and only those using the new 0.1x.x(whatever the number will be) after activation who move funds over to p2wpkh and p2wsh keys who are the ones that cant malleate. but if you use legacy p2pkh /p2sh keys you can still malleate. meaning that malicious people can still be malicious.

and seing that nodes take so long to remain fully uptodate with the latest version. getting it activated is not the end of the drama of low tx count or malleation.. its still going to take a while if ever to get the 'promises' core suggest.

yes every node and every transaction needs to be p2wpkh or p2wsh capable and used to give the tx count boost and malleation impossibility. anything less than 100% means not 100% fixed

[iMaster]

Lucifer and Crawly king of hell lol. Are you sure we would've ended up like ETC/ETH? like everyone could profit 10% on their stashed bitcoins instantly?
I think not. good thing about open source always majority wins but if you put it that way then the majority is the central authority only with the exception that everyone is free and capable to join or become part of the majority.

[hv_]

Lucifer and Crawly king of hell lol. Are you sure we would've ended up like ETC/ETH? like everyone could profit 10% on their stashed bitcoins instantly?
I think not. good thing about open source always majority wins but if you put it that way then the majority is the central authority only with the exception that everyone is free and capable to join or become part of the majority.

Core is in the driver seat. Their task is to deliver consensus features. I still hope for their insight that we need both in one go: SW And BU = swabu

[franky1]

Core is in the sheep hearding seat. Their task is to bypass consensus features. I still hope for a change of motive because we should do both in one go: fix issues and allow nodes to choose scale = swabu

fixed that for you

[hv_]

Core is in the sheep hearding seat. Their task is to bypass consensus features. I still hope for a change of motive because we should do both in one go: fix issues and allow nodes to choose scale = swabu

fixed that for you

I m happy for any such quick fixes esp in these times.