Author

Topic: /r/btc / BUg propaganda spread by VIP user (Read 1113 times)

full member
Activity: 224
Merit: 100
March 31, 2017, 10:25:13 AM
#17
I stopped reading here: 1) BUg requires +21 million coins (total supply will not be a fixed 21 million anymore) for emergent consensus to even hope to work

If you start off with miss information no one is going to take you seriously.
legendary
Activity: 1512
Merit: 1012
The post linked in the OP doesn't seem to break or bypass any forum rules. As far as the content of the post goes, this is the Meta section, discussions about it should be made elsewhere...
copper member
Activity: 2996
Merit: 2374
BU is still under development and segwit has not activated, furthermore LN is still in development. We are discussing future scalability plans to the Bitcoin network. One issue with block sizes that always increase is that a fee market will not develop. Mining rewards half every 4 years. Part of the original Satoshi plan to fund mining was that transaction fees would make up for the decreased mining revenue caused by halvings. Lack of a functioning fee market leads to various incentive problems for miners. Miners may decide to mine empty blocks because they feel running a full node and validating transactions isn't worth the fees. Currently, BU's lead developer has stated that inflation is one option to get a functioning fee market with increasing block sizes and is the only solution proposed thus far.
The miners will not work for free, and each incremental transaction included in a block will incrementally increase the chance that said block will get orphaned, depriving the miner of all of the fee revenue (and block subsidy if applicable) in that block. If a transaction does not have a sufficient tx fee to account for the incremental risk of the block getting orphaned, then a miner will not include said transaction in it's block if it is acting rationally -- miners are also under no obligation to mine on top of any specific block, especially any specific most recent block, so if a block is very large or is otherwise difficult to validate, the other miners can choose to SPV mine on top of that block, or to ignore it for a period of time. In addition, it would be a possibility to use a series of softforks to set a minimum tx fee rate (transactions containing a tx fee rate below this rate would be invalid) in order to prevent a miner from operating at a loss in order to gain market share over the long run. I think a minimum tx fee rate would be a less harmful regulation than what is needed for a fee market to operate.

Personally I am unsure whether or not there is a better solution for BU, however I feel he did raise some valid points and inflation may be necessary.
Deflation is very bad for all parts of an economy. The exception to this is for lenders (at it's face), however lenders should expect a higher default rate on loans, possibly (likely) resulting in greater losses than what small amounts of inflation would cause (especially after factoring in interest payments). Deflation will often lead to a greater economic slowdown than the rate of deflation, while inflation will generally lead to greater increases of economic activity than the rate of inflation.

Also, see above in order to avoid having to resort to perpetual inflation with no fee market in Bitcoin.

In order to create or receive (validate) segwit transactions, you will need to upgrade to segwit. If you wish to continue using old Bitcoin without segwit, you are under no obligation to update, however you will only be able to send and receive old style Bitcoin transactions, you will not be able to send or receive segwit txs.
I am not aware of anything that prevents a SegWit input being sent to a non-SW output.

Also, as I previously mentioned, even if you only receive old style Bitcoin transactions, you will not be able to validate that the transaction has actually confirmed once a single SW transaction is included in a block, because you can no longer validate if blocks are valid.

However I will concede a little here in that segwit is different to previous softforks in this regard as it modifies the network topology. Segwit nodes are programmed to prefer other segwit nodes. If segwit nodes become the majority of the Bitcoin network, then non-segwit nodes may experience connectivity issues. If they are experiencing connectivity issues, they will either need to hardcode IP addresses of other non-segwit nodes into their configuration or upgrade to segwit to resolve the issue. Because such an issue will only arise when the vast majority of nodes upgrade to segwit and there is some kind of work around, I feel that a segwit softfork is the right approach and a contentious segwit hardfork to be dangerous.
If non-SW nodes are connecting to other non-SW nodes, then they would effectively become split from the network.

Also, if you are explicitly connecting to several specific nodes, then you will need to somewhat trust that collection of nodes, as I understand that which nodes a specific node will connect to is somewhat random.
legendary
Activity: 1372
Merit: 1252
@OP - the reason why that guy is able to post in the Important Announcements section is because he donated 50BTC to become a VIP some number of years ago. VIPs are able to post in that section once per week unless there is an important security related announcement in which case they can post more frequently.




1. dynamic implementations including BU. are not touching the 21mill cap..

Peter Rizun (head BU dev):
"To have a fee market with no block size limit you need Bitcoin's inflation rate to be nonzero"
http://np.reddit.com/r/btc/comments/61a4uk/to_have_a_fee_market_with_no_block_size_limite/
"I don't believe a fixed supply is a central property of Bitcoin."
https://i.supload.com/r1pdI_mDg.jpg
BU, like Bitcoin core is open software (I anticipate that BU will remain open source over the long run), and users are free to modify the code as they wish. If the community as a whole (and the economy) wishes to use a Bitcoin that has in excess of 21 million coins, then there is no reason why they should not be able to do this. One person's desire to use a coin with a specific consensus rule does not force others into adhering to these same rules.

Further, the position of one prominent BU developer does not necessarily reflect the position of BU as a whole, nor all BU supporters. This is similar to how just because Greg Maxwell aka nullc aka Gmaxwell, the CTO of blockstream, and a prominent figure within "Core", vandalized Wikipedia does not mean that other Core supporters support this kind of behavior, nor that all other Core supporters actively vandalize Wikipedia as Gmaxwell did.

2. dynamics does not give control to miners. remember its segwit that bypassed node consensus going soft.

Softforks are optional. Nobody are forced to use them. Does not require concensus, but in any case, segwit won't activate without 95% miner support (BU is 75%), or UASF.
Softforks are not optional if you wish to be able to validate incoming transactions and/or validate blocks. Further, a user who has not "upgraded" after a soft fork may result in a user trying to send a transaction they believe to be valid that will never confirm for seemingly no reason. Unless a user agrees to run the most recent version of software written by a third party they may or may not trust and/or agree with, a user will have difficulty being made aware of a soft fork. With soft forks, users are forced to abide by the new rules, regardless of if they agree with them, or even if they are aware of them.

A hardfork on the other hand, will make it very obvious to a user that a change has been made because he is no longer receiving valid blocks, alerting him that he needs to investigate the changes the hard fork made, and if he agrees, to upgrade. It will be very expensive to attempt to trick someone who has not upgraded into accepting a transaction that gets confirmed on an old chain because finding a block will cost roughly that of a block reward (~14 BTC currently) and both the fact that there is a significant drop-off in transaction volume, and a block being found >2 hours after the prior block should both setoff red flags (if a block is found more than a 1/2 day after the prior block, a red flag bright enough should be setoff that he should consider the block invalid, especially if he does not receive subsequent blocks).

For the above reasons, I believe soft forks to be more dangerous than hard forks.

3. having diverse nodes like bitcoinj, classic, xt, bitcoinruby, btcd and a dozen others means that if one codebase has a bug. the network continues as proven by when bu was hit the other diverse codebases continued.

bitcoinj isn't a full node.
A full node is generally considered to be something that has validated all blocks from the first block to present, validates all transactions as it receives them, and validates all future blocks as it receives them.

I would be surprised if most major businesses do not use their own custom full node software with special security settings to protect themselves from various attacks, including sybil attacks.

There is no reason why Wladimir J. van der Laan should have the authority to solely determine exactly what goes into full node software.


4. segwit have not got consensus.

70% economic support:
https://coin.dance/poli
That link actually says that 35% of companies polled support SegWit, and an additional 35% of companies are ready for it. Further, companies are listed on that website regardless of economic transaction volume, or if a company is actually a Bitcoin related company. There are several blockchain "consulting" companies, and other companies that likely do less than $2,000 in monthly business that are given equal weight to companies that do tens/hundreds of millions worth of dollars of business every day. For example, this Canadian "exchange" listed on coin.dance that supports SW and opposes Bu, has a ~9% spread, which is greater than what would be expected on LBC, I think this actually might just be one person who trades bitcoin locally in Canada -- this guy has the same weight as Coinbase.

I would not give very much weight to these kinds of polls.

edit: it actually looks like this poll is giving extra weight to some very small players, for example -ck who authored CGminer (I am not even sure if this is even used anymore), and ckpool which has ~1% of the network hadhrate running on it.

As soon as people that is deluded enough to support BU find out that eventually the supply will need to be more than 21 million coins they will stop supporting it. No amount of twisting of the facts like franky1 does will persuade people into supporting a coin that is a total mess in its very design. Literally no one wants more than 21 million coins, BU is done for for that reason alone (and theres a million reasons why Core is better than BU)
full member
Activity: 196
Merit: 101
BU, like Bitcoin core is open software (I anticipate that BU will remain open source over the long run), and users are free to modify the code as they wish. If the community as a whole (and the economy) wishes to use a Bitcoin that has in excess of 21 million coins, then there is no reason why they should not be able to do this. One person's desire to use a coin with a specific consensus rule does not force others into adhering to these same rules.

Further, the position of one prominent BU developer does not necessarily reflect the position of BU as a whole, nor all BU supporters. This is similar to how just because Greg Maxwell aka nullc aka Gmaxwell, the CTO of blockstream, and a prominent figure within "Core", vandalized Wikipedia does not mean that other Core supporters support this kind of behavior, nor that all other Core supporters actively vandalize Wikipedia as Gmaxwell did.

BU is still under development and segwit has not activated, furthermore LN is still in development. We are discussing future scalability plans to the Bitcoin network. One issue with block sizes that always increase is that a fee market will not develop. Mining rewards half every 4 years. Part of the original Satoshi plan to fund mining was that transaction fees would make up for the decreased mining revenue caused by halvings. Lack of a functioning fee market leads to various incentive problems for miners. Miners may decide to mine empty blocks because they feel running a full node and validating transactions isn't worth the fees. Currently, BU's lead developer has stated that inflation is one option to get a functioning fee market with increasing block sizes and is the only solution proposed thus far.

Personally I am unsure whether or not there is a better solution for BU, however I feel he did raise some valid points and inflation may be necessary.

Personally I think that halving the block reward every 4 years was a poor design choice on Satoshi's part. However, this is the currency that people bought into, and I feel changing this to be too controversial at this point and even though I agree with not having "halvings", removing it at this stage would certainly hurt the value of Bitcoin due to each coin being less scarce. Also interesting to note is thanks to Satoshi's masterful c++ coding skills, Bitcoin has a bug that means there is no 21 million coin cap, it is infinite.

Softforks are not optional if you wish to be able to validate incoming transactions and/or validate blocks. Further, a user who has not "upgraded" after a soft fork may result in a user trying to send a transaction they believe to be valid that will never confirm for seemingly no reason. Unless a user agrees to run the most recent version of software written by a third party they may or may not trust and/or agree with, a user will have difficulty being made aware of a soft fork. With soft forks, users are forced to abide by the new rules, regardless of if they agree with them, or even if they are aware of them.

A hardfork on the other hand, will make it very obvious to a user that a change has been made because he is no longer receiving valid blocks, alerting him that he needs to investigate the changes the hard fork made, and if he agrees, to upgrade. It will be very expensive to attempt to trick someone who has not upgraded into accepting a transaction that gets confirmed on an old chain because finding a block will cost roughly that of a block reward (~14 BTC currently) and both the fact that there is a significant drop-off in transaction volume, and a block being found >2 hours after the prior block should both setoff red flags (if a block is found more than a 1/2 day after the prior block, a red flag bright enough should be setoff that he should consider the block invalid, especially if he does not receive subsequent blocks).

For the above reasons, I believe soft forks to be more dangerous than hard forks.

In order to create or receive (validate) segwit transactions, you will need to upgrade to segwit. If you wish to continue using old Bitcoin without segwit, you are under no obligation to update, however you will only be able to send and receive old style Bitcoin transactions, you will not be able to send or receive segwit txs.

However I will concede a little here in that segwit is different to previous softforks in this regard as it modifies the network topology. Segwit nodes are programmed to prefer other segwit nodes. If segwit nodes become the majority of the Bitcoin network, then non-segwit nodes may experience connectivity issues. If they are experiencing connectivity issues, they will either need to hardcode IP addresses of other non-segwit nodes into their configuration or upgrade to segwit to resolve the issue. Because such an issue will only arise when the vast majority of nodes upgrade to segwit and there is some kind of work around, I feel that a segwit softfork is the right approach and a contentious segwit hardfork to be dangerous.

(I don't have time right now to respond to the rest of your points, but I may later).
copper member
Activity: 2996
Merit: 2374
@OP - the reason why that guy is able to post in the Important Announcements section is because he donated 50BTC to become a VIP some number of years ago. VIPs are able to post in that section once per week unless there is an important security related announcement in which case they can post more frequently.




1. dynamic implementations including BU. are not touching the 21mill cap..

Peter Rizun (head BU dev):
"To have a fee market with no block size limit you need Bitcoin's inflation rate to be nonzero"
http://np.reddit.com/r/btc/comments/61a4uk/to_have_a_fee_market_with_no_block_size_limite/
"I don't believe a fixed supply is a central property of Bitcoin."
https://i.supload.com/r1pdI_mDg.jpg
BU, like Bitcoin core is open software (I anticipate that BU will remain open source over the long run), and users are free to modify the code as they wish. If the community as a whole (and the economy) wishes to use a Bitcoin that has in excess of 21 million coins, then there is no reason why they should not be able to do this. One person's desire to use a coin with a specific consensus rule does not force others into adhering to these same rules.

Further, the position of one prominent BU developer does not necessarily reflect the position of BU as a whole, nor all BU supporters. This is similar to how just because Greg Maxwell aka nullc aka Gmaxwell, the CTO of blockstream, and a prominent figure within "Core", vandalized Wikipedia does not mean that other Core supporters support this kind of behavior, nor that all other Core supporters actively vandalize Wikipedia as Gmaxwell did.

2. dynamics does not give control to miners. remember its segwit that bypassed node consensus going soft.

Softforks are optional. Nobody are forced to use them. Does not require concensus, but in any case, segwit won't activate without 95% miner support (BU is 75%), or UASF.
Softforks are not optional if you wish to be able to validate incoming transactions and/or validate blocks. Further, a user who has not "upgraded" after a soft fork may result in a user trying to send a transaction they believe to be valid that will never confirm for seemingly no reason. Unless a user agrees to run the most recent version of software written by a third party they may or may not trust and/or agree with, a user will have difficulty being made aware of a soft fork. With soft forks, users are forced to abide by the new rules, regardless of if they agree with them, or even if they are aware of them.

A hardfork on the other hand, will make it very obvious to a user that a change has been made because he is no longer receiving valid blocks, alerting him that he needs to investigate the changes the hard fork made, and if he agrees, to upgrade. It will be very expensive to attempt to trick someone who has not upgraded into accepting a transaction that gets confirmed on an old chain because finding a block will cost roughly that of a block reward (~14 BTC currently) and both the fact that there is a significant drop-off in transaction volume, and a block being found >2 hours after the prior block should both setoff red flags (if a block is found more than a 1/2 day after the prior block, a red flag bright enough should be setoff that he should consider the block invalid, especially if he does not receive subsequent blocks).

For the above reasons, I believe soft forks to be more dangerous than hard forks.

3. having diverse nodes like bitcoinj, classic, xt, bitcoinruby, btcd and a dozen others means that if one codebase has a bug. the network continues as proven by when bu was hit the other diverse codebases continued.

bitcoinj isn't a full node.
A full node is generally considered to be something that has validated all blocks from the first block to present, validates all transactions as it receives them, and validates all future blocks as it receives them.

I would be surprised if most major businesses do not use their own custom full node software with special security settings to protect themselves from various attacks, including sybil attacks.

There is no reason why Wladimir J. van der Laan should have the authority to solely determine exactly what goes into full node software.


4. segwit have not got consensus.

70% economic support:
https://coin.dance/poli
That link actually says that 35% of companies polled support SegWit, and an additional 35% of companies are ready for it. Further, companies are listed on that website regardless of economic transaction volume, or if a company is actually a Bitcoin related company. There are several blockchain "consulting" companies, and other companies that likely do less than $2,000 in monthly business that are given equal weight to companies that do tens/hundreds of millions worth of dollars of business every day. For example, this Canadian "exchange" listed on coin.dance that supports SW and opposes Bu, has a ~9% spread, which is greater than what would be expected on LBC, I think this actually might just be one person who trades bitcoin locally in Canada -- this guy has the same weight as Coinbase.

I would not give very much weight to these kinds of polls.

edit: it actually looks like this poll is giving extra weight to some very small players, for example -ck who authored CGminer (I am not even sure if this is even used anymore), and ckpool which has ~1% of the network hadhrate running on it.
legendary
Activity: 3542
Merit: 1965
Leading Crypto Sports Betting & Casino Platform
Quote
BUg gives total control to miners (miners = a couple of guys with state-sponsored ASICs in china)
Total control to miners? More like a total control in stealing people's money.

Quote
Peter R and others support attack on minority chain when network support is against BU

We have no way of telling if it's really them who did it or maybe it's just some core supporters.

The mining Pools are in a way monopolizing decisions from a centralized perspective, because they are throwing their weight around as a group to shift development decisions in their favor. So yes, in a way the do have total control. Today it is Block sizes and tomorrow it might be something worst. < like the 21 Mil coin cap >

Whomever has the minority chain, will be targeted by a 51% attack, that is just the nature of people and even animals in nature. < The weak will not survive >
sr. member
Activity: 243
Merit: 250
So should propaganda and FUD be the exclusive reserve of blockstream/core fanatics? How dare this user shill another implementation!
Show me posts of core fanatics with FUD where they constantly write that bitcoin is dead, failed experiment, etc?
full member
Activity: 196
Merit: 101
We have no way of telling if it's really them who did it or maybe it's just some core supporters.

BU devs refuse to implement replay protection. They stated their main purpose for doing this is to attack the old chain once BU activates, in order to force people off the old chain onto the new one. Their whole plan is to create a new chain and force everyone who won't voluntarily switch over to it, onto it, by attacking the old chain.
sr. member
Activity: 1400
Merit: 269
Quote
BUg gives total control to miners (miners = a couple of guys with state-sponsored ASICs in china)
Total control to miners? More like a total control in stealing people's money.

Quote
Peter R and others support attack on minority chain when network support is against BU

We have no way of telling if it's really them who did it or maybe it's just some core supporters.
full member
Activity: 196
Merit: 101
that was about BLOCK SPACE that needs to inflate..

That is some very creative twisting of words right there.

quote from 0:14 seconds: "Number 1 we need for Bitcoin's inflation rate to be non-zero" - Peter Rizun (head BU dev)

So you think inflation rate of a currency means block size inflating in size?
If so, what did he mean by non-zero?

Could he possibly mean that Bitcoin is a deflationary currency (IE zero inflation), and that he needs to change it into an inflationary currency for a fee market to work with block sizes that always increase?
sr. member
Activity: 476
Merit: 501
So should propaganda and FUD be the exclusive reserve of blockstream/core fanatics? How dare this user shill another implementation!
sr. member
Activity: 243
Merit: 250
https://bitcointalk.org/index.php?topic=1836611.new;boardseen#new

Why does this guy get to stick his obvious pro-BUg thread in the forum?

If he is a vip it doesn't mean anything, he simply donates to this forum, it doesnt' make him expert or more reliable. But the fact that he shills for China coin BTU instantly kills his good standing
legendary
Activity: 4424
Merit: 4794
1. dynamic implementations including BU. are not touching the 21mill cap..

Peter Rizun (head BU dev):
"To have a fee market with no block size limit you need Bitcoin's inflation rate to be nonzero"
http://np.reddit.com/r/btc/comments/61a4uk/to_have_a_fee_market_with_no_block_size_limite/
"I don't believe a fixed supply is a central property of Bitcoin."
https://i.supload.com/r1pdI_mDg.jpg


that was about BLOCK SPACE that needs to inflate.. nothing to do with the coin cap.
do your research better. did you even watch the first 60 seconds of the video.
yep 0seconds->60 seconds listen for the words BLOCK SPACE
full member
Activity: 196
Merit: 101
1. dynamic implementations including BU. are not touching the 21mill cap..

Peter Rizun (head BU dev):
"To have a fee market with no block size limit you need Bitcoin's inflation rate to be nonzero"
http://np.reddit.com/r/btc/comments/61a4uk/to_have_a_fee_market_with_no_block_size_limite/
"I don't believe a fixed supply is a central property of Bitcoin."
https://i.supload.com/r1pdI_mDg.jpg

2. dynamics does not give control to miners. remember its segwit that bypassed node consensus going soft.

Softforks are optional. Nobody are forced to use them. Does not require concensus, but in any case, segwit won't activate without 95% miner support (BU is 75%), or UASF.

3. having diverse nodes like bitcoinj, classic, xt, bitcoinruby, btcd and a dozen others means that if one codebase has a bug. the network continues as proven by when bu was hit the other diverse codebases continued.

bitcoinj isn't a full node. And to quote Satoshi:

I don't believe a second, compatible implementation of Bitcoin will ever be a good idea.  So much of the design depends on all nodes getting exactly identical results in lockstep that a second implementation would be a menace to the network.  The MIT license is compatible with all other licenses and commercial uses, so there is no need to rewrite it from a licensing standpoint.

A second version would be a massive development and maintenance hassle for me.  It's hard enough maintaining backward compatibility while upgrading the network without a second version locking things in.  If the second version screwed up, the user experience would reflect badly on both, although it would at least reinforce to users the importance of staying with the official version.  If someone was getting ready to fork a second version, I would have to air a lot of disclaimers about the risks of using a minority version.  This is a design where the majority version wins if there's any disagreement, and that can be pretty ugly for the minority version and I'd rather not go into it, and I don't have to as long as there's only one version.

I know, most developers don't like their software forked, but I have real technical reasons in this case.


Also, read up on how multiple implementations killed other decentralized networks, such as gnutella.

4. segwit have not got consensus.

70% economic support:
https://coin.dance/poli


legendary
Activity: 4424
Merit: 4794
lol
you have no clue
seems you are scripted by billybobzorton and pereira4

1. dynamic implementations including BU. are not touching the 21mill cap.. secondly its segwit that need people to move funds to segwit keys after activation to achieve anything.

2. dynamics does not give control to miners. remember its segwit that bypassed node consensus going soft. its the blockstreamists that are shouting that nodes dont matter.. while the other dynamic groups know nodes do matter.
as proven by the 1.000250mb block that got rejected in 3 seconds without any technical drama(because NODES disagreed with a block pools made.. literally saying not yet no consensus reached)

3. having diverse nodes like bitcoinj, classic, xt, bitcoinruby, btcd and a dozen others means that if one codebase has a bug. the network continues as proven by when bu was hit the other diverse codebases continued. however if everyone was to centralise to blockstream(core). then big nasty events like the 2013 core leveldb event will happen again. which cant be mitigated or toned down due to the fact that everyone would be ALL using the same codebase
.. this is why decentralised diverse nodes are important

4. segwit have not got consensus. and its segwit with all the intolerance of decentralism code. treating anything not segwit as second tier.. they have high ban scores, bip9 uasf and Pow changes.. all to FORCE segwit into activation. blockstream dont care about consensus. going soft then going bilateral split but always skipping real consnsus in the middle.. very bad tactics.
full member
Activity: 168
Merit: 100
https://bitcointalk.org/index.php?topic=1836611.new;boardseen#new

Why does this guy get to stick his obvious pro-BUg thread in the forum?

BUg is not bitcoin:

1) BUg requires +21 million coins (total supply will not be a fixed 21 million anymore) for emergent consensus to even hope to work
2) BUg gives total control to miners (miners = a couple of guys with state-sponsored ASICs in china)
3) BUg has incompetent dev team that makes crashing software, even resorting to closed source patches
4) Peter R and others support attack on minority chain when network support is against BU

A second version would be a massive development and maintenance hassle for me.  It's hard enough maintaining backward compatibility while upgrading the network without a second version locking things in.  If the second version screwed up, the user experience would reflect badly on both, although it would at least reinforce to users the importance of staying with the official version.


Quote from: whitepaper
The network timestamps transactions by hashing them into an ongoing chain of hash-based proof-of-work, forming a record that cannot be changed without redoing the proof-of-work. The longest chain not only serves as proof of the sequence of events witnessed, but proof that it came from the largest pool of CPU power. As long as a majority of CPU power is controlled by nodes that are not cooperating to attack the network, they'll generate the longest chain and outpace attackers.





Miners are now split from nodes and (some) planning on attacking 92% of the network. I must remind you that miners = a couple of centralized actors.

In BUg miners would have total control of blocksize and so on.

Nodes would have no weight anymore. Bitmain would end up with both mining and node datacenter monopoly.

Such a coin is garbage, you cant call that decentralized with a straight face anymore.

And remember: all of this mess because roger ver wants to buy coffee onchain. This is nuts.

Jump to: