Bitcoin Forum
January 22, 2019, 06:01:41 PM *
News: Latest Bitcoin Core release: 0.17.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 [3]  All
  Print  
Author Topic: [News]WHY AGAINST SEGWIT AND CORE? Mining investor gives his answer  (Read 2375 times)
jbreher
Legendary
*
Offline Offline

Activity: 2268
Merit: 1171


lose: unfind ... loose: untight


View Profile
November 25, 2016, 07:22:16 AM
 #41

Okay, so the BU crowd wants to scale via a hard fork. But why this specific proposal?

It was decided in your absence solely because you left the conversation. You self-selected not to participate. Suck it up, buttercup.


Anyone with a campaign ad in their signature -- for an organization with which they are not otherwise affiliated -- is automatically deducted credibility points.

I've been convicted of heresy. Convicted by a mere known extortionist. Read my Trust for details.
1548180101
Hero Member
*
Offline Offline

Posts: 1548180101

View Profile Personal Message (Offline)

Ignore
1548180101
Reply with quote  #2

1548180101
Report to moderator
1548180101
Hero Member
*
Offline Offline

Posts: 1548180101

View Profile Personal Message (Offline)

Ignore
1548180101
Reply with quote  #2

1548180101
Report to moderator
1548180101
Hero Member
*
Offline Offline

Posts: 1548180101

View Profile Personal Message (Offline)

Ignore
1548180101
Reply with quote  #2

1548180101
Report to moderator
There are several different types of Bitcoin clients. The most secure are full nodes like Bitcoin Core, but full nodes are more resource-heavy, and they must do a lengthy initial syncing process. As a result, lightweight clients with somewhat less security are commonly used.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
jbreher
Legendary
*
Offline Offline

Activity: 2268
Merit: 1171


lose: unfind ... loose: untight


View Profile
November 25, 2016, 07:26:05 AM
 #42

...  Hearn and Andresen ... whereas the reality is that this whole blocksize debate was began so that they could get their hands on the keys to Bitcoin's source code.

That's not only condescending, but just plain stupid. In the history of Bitcoin, there have been exactly two people who have given up the keys to the castle. One was Satoshi. What was the other one's name...?

Anyone with a campaign ad in their signature -- for an organization with which they are not otherwise affiliated -- is automatically deducted credibility points.

I've been convicted of heresy. Convicted by a mere known extortionist. Read my Trust for details.
Killerpotleaf
Sr. Member
****
Offline Offline

Activity: 728
Merit: 250



View Profile
November 25, 2016, 07:28:09 AM
 #43

main community wants segwit!

who are you referring to?

the poeple from the censored forms?
node count?
hashing power?

how can you claim to know what the majority want?



     ▄██    ▐███████▄▄▄       ▄▄█████▄▄      ▄██▄      ▐██▄    ▒▓▓▄      ▄▓▓▒
     ███    ▐██▌▀▀▀▀▀███▄    ███▀▀▀▀▀███▄    ████▄     ▐██▌  ▐▓▄ ▀▓▓▄  ▄▓▓▀ ▄▓▌
     ███    ▐██▌      ███   ███▌      ███▌   ██████    ▐██▌   ▀▓▓▄ ▀▓▓▓▓▀ ▄▓▓▀
     ███    ▐██▌    ▄████  ▐███▌      ▐██▌   ███ ███▄  ▐██▌     ▀▓▓▄ ▀▀ ▄▓▓▀
     ███    ▐█████████▀▀   ▐███▌      ▐██▌   ███  ▀███ ▐██▌      ▓▓▓    ▓▓▓
     ███    ▐██▌   ▀███     ███▌      ███▌   ███    ██████▌   ▄▓▓▀ ▄▓▓▓▓▄ ▓▓▓▄
     ███    ▐██▌     ███    ▀███▄▄▄▄▄████    ███     ▀████▌  ▐▓▀ ▄▓▓▀  ▀▓▓▄ ▀▓▌
     ███    ▐██▌      ███     ▀▀██████▀▀     ███       ███▌    ▄▓▓▀      ▀▓▓▄
                  ▄▄▄█████▄▄▄▄
             ▄▄█▓▓▓▓▓█▀▀▀▀█▓▓▓▓▓█▄
           ▄▓▓▓█▀▀            ▀▀█▓▓█▄
         ▓▓▓█▀                    ▀▓▓█▄
       ▄▓▓▓▀                        ▀▓▓█
      ▄▓▓█                            █▓▓
      ▓▓▓                    ▄██▄     ▐▓▓█
     ▓▓▓                   ▄█▓▓▀       ▐▓▓▌
     ▓▓▓                 ▄█▓▓▀          ▓▓▓
     ▓▓▓       ▓▓▓▄    ▓▓▓▓▀            ▓▓▓
     ▓▓▓        ▀▓▓▓▄█▓▓▓▀             ▐▓▓▌
     ▀▓▓▓         ▀█▓▓█▀               █▓▓
      ▓▓▓▄                            ▓▓▓▌
       ▓▓▓█                         ▄█▓▓▀
        ▀▓▓█▄                     ▄▓▓▓█▀
          ▀▓▓▓█▄               ▄▄█▓▓█▀
            ▀▀█▓▓▓█▄▄▄▄▄▄▄▄▄▄█▓▓▓█▀
                ▀▀██▓▓▓▓▓▓▓███▀▀
franky1
Legendary
*
Offline Offline

Activity: 2296
Merit: 1355



View Profile
November 25, 2016, 10:01:41 AM
 #44

how can you claim to know what the majority want?

even people that love core want dynamic blocksize. the only argument they can come up with though is that they would only TRUST gmaxwell to write the code for it. they are even screaming to tell the community that core never said no to a increase of the base blocksize, they just waiting for gmaxwell who proposed a dynamic blocksize LAST YEAR!

afterall the altcoin dooms day myth has been busted. all that will happen is an elevation of possible orphan rate due to how small or large the minority is (hense 95%+ acceptability to implement). making under 5% (under 250 of 5000 nodes) not sync and need to upgrade.

afterall the bloat doomsday myth has been busted. 4mb bloat is acceptable

so the solution/compromise is obvious. core tweak their segwit code to 2mb base 4mb weight.. call it 0.13.1b release it alongside 0.13.1 and let the community choose to download either 0.13.1 or 0.13.1b

atleast if everyone happily downloads 0.13.1b segwit also gets activated by default too.
if there is no desire of a jump in base block.. then no one will download 0.13.1b and it wont activate. meaning no harm either fanboys just download 0.13.1 instead

but simply preventing even letting the community have the release to even have a choice under their 'trusted' brand they wont run away from. is no longer the right course of action

then. when activated and we have more REAL capacity because the buffer has increased. that gives alot more time to code new features instead of these stupid delays

I DO NOT TRADE OR ACT AS ESCROW ON THIS FORUM EVER.
Please do your own research & respect what is written here as both opinion & information gleaned from experience. many people replying with insults but no on-topic content substance, automatically are 'facepalmed' and yawned at
DaRude
Legendary
*
Offline Offline

Activity: 1614
Merit: 1015


In order to dump coins one must have coins


View Profile
November 25, 2016, 07:07:59 PM
 #45

main community wants segwit!

who are you referring to?

the poeple from the censored forms?
node count?
hashing power?

how can you claim to know what the majority want?

Are you asking me or franky1? Let me highlight the important parts that you cut out from my quote to make it seem out of context

Only problem is that big blockers realizes that even 20MB blocks cannot accommodate the transaction volume they speak of, nor does it solve 10min confirmation time. So other layers must be implemented which cannot (efficiently) be done without segwit. So they're just trying to hold segwit hostage.

holding it hostage??
um... like core not coding something so holding the other bip hostage by not even having a release available. which is far more hostile then having code released but people choose not to use it.

also are you presume bitcoin is going to jump in utility by a factor of 20, in days, weeks, months, years..?
seems your opinion is that its going to jump in days-months and so your upset that bitcoin cant cope.. yet RATIONALLY bitcoin utility will grow over YEARS and in those YEARS larger blocks would be happily relayable.

the main community is not saying jump to 20mb in weeks-months. its instead asking for a rational growth over rational time without having to beg devs "can i have some more" every couple years. by allowing the growth to be dynamic and not controlled by a team of people paid by banks.

its also worth looking at the bait and switch proposals and who actually proposed them, to then realise that it was done to scare people into loving core



If a space on a distributed blockchain costs only $0.01 i might use it as a notepad to store my reminders. e.g. if it's free (or almost free) to spam i can't imagine mempool being empty again, regardless of the size of a block.

Quote
by allowing the growth to be dynamic
Yes sure why don't we introduce this HUGE attack vector into BTC? Sounds like a good plan. No one in their right mind would allow this. How big should a block be to handle Visa volumes?

I like your assumptions of the desires of "main community". I can do that too, main community wants segwit! There is a group that proposed Classic/XT/BU which was/is rejected by the main community. Now there is a proposal for segwit, yet there is a group that is blocking it. So what are the options? Main community must agree with BU minority or otherwise no one gets segwit?

"Feeeeed me Roger!"  -Bcash
DaRude
Legendary
*
Offline Offline

Activity: 1614
Merit: 1015


In order to dump coins one must have coins


View Profile
November 25, 2016, 07:18:09 PM
 #46

how can you claim to know what the majority want?

even people that love core want dynamic blocksize. the only argument they can come up with though is that they would only TRUST gmaxwell to write the code for it. they are even screaming to tell the community that core never said no to a increase of the base blocksize, they just waiting for gmaxwell who proposed a dynamic blocksize LAST YEAR!

afterall the altcoin dooms day myth has been busted. all that will happen is an elevation of possible orphan rate due to how small or large the minority is (hense 95%+ acceptability to implement). making under 5% (under 250 of 5000 nodes) not sync and need to upgrade.

afterall the bloat doomsday myth has been busted. 4mb bloat is acceptable

so the solution/compromise is obvious. core tweak their segwit code to 2mb base 4mb weight.. call it 0.13.1b release it alongside 0.13.1 and let the community choose to download either 0.13.1 or 0.13.1b

atleast if everyone happily downloads 0.13.1b segwit also gets activated by default too.
if there is no desire of a jump in base block.. then no one will download 0.13.1b and it wont activate. meaning no harm either fanboys just download 0.13.1 instead

but simply preventing even letting the community have the release to even have a choice under their 'trusted' brand they wont run away from. is no longer the right course of action

then. when activated and we have more REAL capacity because the buffer has increased. that gives alot more time to code new features instead of these stupid delays

Personally I'd like to see some research on what effect 4mb weight blocks would have on further centralization, but that's what i foresee most likely to happen. If 0.13.1 won't get enabled, bump up blocks to 2MB+segwit and let people vote on that.

"Feeeeed me Roger!"  -Bcash
AgentofCoin
Legendary
*
Offline Offline

Activity: 1092
Merit: 1000



View Profile
November 25, 2016, 09:21:39 PM
Last edit: November 25, 2016, 09:37:42 PM by AgentofCoin
 #47


Personally I'd like to see some research on what effect 4mb weight blocks would have on further centralization, but that's what i foresee most likely to happen. ...

I don't think it is possible to do actual research on it, it is always a guess (as to node loss).
So besides research on node utilization costs/attacks and block propagation costs/attacks,
the major problem is: no one really can do research on what a post-hardforked blocksize
node count will be. It could be 4500 or it could be 5. There is no way to study it legitimately,
so its outright just a blind risk. I don't like the idea of jumping off a cliff blind and not knowing
if the cliff is deadly or just a simple street curb.

I was thinking today, if the BU and other developers figured out a mechanism to "incentivize nodes"
in the same manner that Miners are incentivized to verify Bitcoin txs/blocks, then not only would they
provide one of the greatest services to the Bitcoin community, but also allow a more secured future for
forked upgrades, since the node system can grow and not diminish.

If I had the know how, that some of the members of this forum have, that is what I would be working on.
Miners don't work for nothing, but node maintainers do. If this puzzle could be legitimately resolved, it would
be a great success for Bitcoin, even more so than a 2 to 8mb blocksize increase.

I support a decentralized & unregulatable ledger first, with safe scaling over time.
Request a signed message if you are associating with anyone claiming to be me.
franky1
Legendary
*
Offline Offline

Activity: 2296
Merit: 1355



View Profile
November 25, 2016, 10:51:52 PM
 #48

if the BU and other developers figured out a mechanism to "incentivize nodes"
in the same manner that Miners are incentivized to verify Bitcoin txs/blocks, then not only would they
provide one of the greatest services to the Bitcoin community, but also allow a more secured future for
forked upgrades, since the node system can grow and not diminish.

incentivising them is not easy or even advantageous..

all that will happen is 1-2 corporations running 20,000 nodes all running on AWS each, to grab the incentive.. then the 5000 oldtimers who are left with nothing, will feel that they are not being paid and (unknowingly) think the network is secure with 20,000 nodes.. so they would switch off.

leaving the network in the hands of 1-2 entities and the copies of the blockchain in a centralized single location (amazon service).

the problem with incentives is. rich guys pool their resources to get a leader advantage and claim a majority of incentives.
just take a look at the future industries that 'invested' in trump and now going to become the leaders of their industry with nice large government grants heading their way.

incentives do not mean better security.

I DO NOT TRADE OR ACT AS ESCROW ON THIS FORUM EVER.
Please do your own research & respect what is written here as both opinion & information gleaned from experience. many people replying with insults but no on-topic content substance, automatically are 'facepalmed' and yawned at
AgentofCoin
Legendary
*
Offline Offline

Activity: 1092
Merit: 1000



View Profile
November 26, 2016, 07:52:50 PM
Last edit: November 26, 2016, 08:10:53 PM by AgentofCoin
 #49

if the BU and other developers figured out a mechanism to "incentivize nodes"
in the same manner that Miners are incentivized to verify Bitcoin txs/blocks, then not only would they
provide one of the greatest services to the Bitcoin community, but also allow a more secured future for
forked upgrades, since the node system can grow and not diminish.

incentivising them is not easy or even advantageous..

all that will happen is 1-2 corporations running 20,000 nodes all running on AWS each, to grab the incentive.. then the 5000 oldtimers who are left with nothing, will feel that they are not being paid and (unknowingly) think the network is secure with 20,000 nodes.. so they would switch off.

leaving the network in the hands of 1-2 entities and the copies of the blockchain in a centralized single location (amazon service).

the problem with incentives is. rich guys pool their resources to get a leader advantage and claim a majority of incentives.
just take a look at the future industries that 'invested' in trump and now going to become the leaders of their industry with nice large government grants heading their way.

incentives do not mean better security.

No, what I meant is figuring out how to create an "incentive node" network that can't be gamed.
This is very hard to do and thus why I said it was a puzzle. But if solved, would be a monumental feat.
If the 5000 oldtimers don't want to join, they don't have to, they can continue as is because they love it.
My reasoning is getting new people into the game because they would be paid to do so.

Bitcoin's blockchain only works because Satoshi knew it needed an incentive to mine.
Mining, as you know, is both verification of transactions and PoW and a systematic dispersal system for the token.
The whole system only works because the miners are "forced" to verify/do work to get the "award/fee".

The proposed incentive for this node network would be very small and not compensate the full cost of a node,
but would allow average people to get bitcoins the same way members of this forum get some bitcoin from
signature campaigns. It may even be possible that the incentive could cover the costs, I haven't done the math.
As the number of "incentive nodes" increase in this proposed network, the incentive shared decreases.
The point is not profit, but to "incentive" people to want to run a node.

When you see how many people sig spam on this forum for their 0.0010 btc or whatever per week or two
(I seriously have no idea how often they are paid and what the average amount is), imagine if all those
people were running this incentive node platform that can't be gamed. It would usher in a new era for Bitcoin.
An era where the Users can be more than just Users, they participate in a way Satoshi originally intended.
Though he understood that over time it would become centralized, I believe he meant around 2050 to 2080
when the system would be institutionalized and not within the first decade of its whitepaper release.

This proposed incentive network would obviously be designed to prevent the exploitation that Franky has
stated as well as others that could occur. Its possible we could make centralized server companies such as
amazon or other cloud storage restricted within this proposed "incentive node" network.
If an attacker wanted to spin up many nodes in a single location, they would need pay the costs of
personally housing those devices and etc, and when the incentive is not substantial, would be a major
financial loss to do. The point is we can design this system if we really wanted to.

Solve the puzzle. Your prize is ensuring a strong future for Bitcoin.

I support a decentralized & unregulatable ledger first, with safe scaling over time.
Request a signed message if you are associating with anyone claiming to be me.
Carlton Banks
Legendary
*
Offline Offline

Activity: 2254
Merit: 1482



View Profile
November 26, 2016, 08:33:16 PM
 #50

Personally I'd like to see some research on what effect 4mb weight blocks would have on further centralization, but that's what i foresee most likely to happen.

I'm not too sure that much research is necessary.



All "4MB weight" means is that in addition to the standard 1 MB blocks we have now, an extra 3 MB can be used but for signatures only. Today's transactions dedicate slightly less than half of their size in bytes to the signature, on average.

And that's why the increase gets quoted as only being between 1.75 MB and 2MB, because it's not possible to fill up all 3 MB of extra block space using transactions that are 1:1 data:signature. The reason there's 3x times more space than we can use is that Lightning transactions will change that average ratio closer to the 1:3 data:signature due to it's use of multi-sig (multi-sig transactions must have larger signatures, as more than one signature is required to sign them correctly).

All this would have to change if the signature technology got changed, which is a likely future upgrade. Bitcoin uses ECDSA signatures right now, but more space-efficient signature schemes exist that could replace it, that would mean the 1:3 data:signature ratio would need changing to reflect that.


So, I hope you can see from this that neither node or mining centralisation is affected by the weighting, it's just a ratio used to target efficient use of block space.

Vires in numeris
franky1
Legendary
*
Offline Offline

Activity: 2296
Merit: 1355



View Profile
November 26, 2016, 11:22:49 PM
Last edit: November 27, 2016, 12:00:46 AM by franky1
 #51

Personally I'd like to see some research on what effect 4mb weight blocks would have on further centralization, but that's what i foresee most likely to happen.

the 4mb bloat has been evaluated.
the main cries over the last few years why anything above 1mb was bad was things like
"not everyone has fast internet"
"chinese firewall"
etc

yet all that has been debunked and tests were done that 8mb is acceptable.. but 4mb was deemed the very safe amount to handle for now as acceptable bloat.
"chinese firewall"
yes thats right. while the west was crying that it cant go above 1mb due to chinese firewall.. the east (inside the firewall) all laughed and said what a stupid doomsday. nothing about the chinese firewall has issues with it and data can be so much more than 4mb


"not everyone has fast internet"
tell that to the millions of people in africa doing skype videocalls. then millions of people uploading to youtube. millions doing livestreaming, whilst online gaming...

so devs now backtracked doomsday and happily said upto 4mb bloat was acceptable.


yet still keeping tx baseblock data at 1mb..

i cant wait until they backtrack the 1mb baseblock dooms day when they finally see its just a orphan risk scenario.. hense the need for super high majority consensus to mitigate orphan risk.

the 'it causes altcoin' doomsday is FUD. because oppositions need EXTRA added code to intentionally IP/USERAGENT BAN connecting to certain nodes.. just like ethereum intentionally split '--oppose-dao-fork'
without adding an intentional ban list of IP/useragents. the connected nodes just have an orphan battle on a single chain, they dont keep 2 chains alive for eternity they orphan the minority
high majority consensus means low risk of orphans. and leaves the minority never syncing.. thus again no second chain. just minority left unsynced


as for the "linear/quadratic" doomsday.
easy.

if sigops is causing issues... limit sigops.
there is no rational reason for one person to need to do 500-20000 sigops. so limit the number of sigops a tx can have.
aswell as ensuring validation times are not used as a DDoS, the extra benefit is we will not see a block with just 1tx sized at 1mb with hefty amount of sigops to churn through..

I DO NOT TRADE OR ACT AS ESCROW ON THIS FORUM EVER.
Please do your own research & respect what is written here as both opinion & information gleaned from experience. many people replying with insults but no on-topic content substance, automatically are 'facepalmed' and yawned at
Pages: « 1 2 [3]  All
  Print  
 
Jump to:  

Bitcointalk.org is not available or authorized for sale. Do not believe any fake listings.
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!