Bitcoin Forum
June 23, 2024, 09:49:13 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 [685] 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 ... 1472 »
13681  Bitcoin / Bitcoin Discussion / Re: How does block size harm decentralization? on: February 10, 2019, 05:42:07 AM
causing a transaction backlog and fee pressure NOW kills off the desire and utility of bitcoin.

How do you know? Any evidence or just more empty conjecture?

evidence... hmmm
how about people frustrated with bitcoin to such a point they are actively promoting LN....
how they are frustrated with waiting for bitcoin innovation that they are willing to losen their morals and principles and understanding of bitcoin to actively want to have a different network where funds are locked into counterparty management(banking).

every person that WANTS LN are people secretly pee'd off with bitcoin fee's and limited transaction ability... if they were not peed off, and happy with bitcoin. they would not be so hard nose about promoting LN as LN would not be something they would want/need
in essense. if there wasnt a problem then LN would not be a solution.. so those promoting LN are actually announcing and screaming there is a bitcoin problem.

but the 'problem' is not technology.. but political decision of devs' to not innovate bitcoin and instead stifle bitcoin to make LN a thing people desire

as for segwits stuff that core pretend are fixed
maleability.. has not been fixed. people can still malleate on the bitcoin network by using legacy
infact new opcodes for segwit allow segwit to be malleated too... yep core want/are reintroducing malleation into segwit.. (i know i laughed hard when that became public knowledge)
as for the legacy transaction s in regards to the "quadratic" verification.. that can be solved real easy... dont let a single transaction be allowed to have 16,000 sigops. this then solves 2 things
a. if a transaction is only allowed say 500sigops. then their wont be any issue with sighash validating.
b. blocks wont be filled by just 5tx's of such bloated crap.

funnily enough.. core when keeping the baseblock but then shifting to weight. didnt DECREASE sigop limit to eleviate the problem.. instead they increased the sigop limit
it was 20k blocksigop limit with a /5 for tx sigop limit... to then be a 80000k blocksigop limit with a /5 for tx sigoplimit
(4k to 16k sigops per tx).. which was an unbelievable foolish move.

at worse they could have done 80000 /20 to atleast stick to the old 4ktx limit.. or improved the situation by doing a 80k /100 to get transactions to only be allowed 800 (though i personally think 800 is still too much for a 'peer-to-peer' decentralsied currency)
13682  Bitcoin / Bitcoin Discussion / Re: Is it possible to restart the blockchain? on: February 10, 2019, 05:21:25 AM
in relation to restarting the entire network back to genesis block, while also keeping the current network alive as a separate chain.. this is just creating a non-premined altcoin

many have done this many times, where the rules are pretty much the same. only they change the name of the coin to make it obvious that its not the same chain as the current bitcoin network.

forked chains (that begin at XXXXXX block instead of block zero again) are called forked premined chains.

as for not re-starting a network at zero(genesis) but just deleting some blocks where the funds of an old block is spent was one original vision of 'prunning' but then prunning every block upto current height minus a few hundred blocks became the main vision of prunning where nodes (not the entire network) .. but just some nodes dont archive the whole chain.

.....
knowing that core are ok with prunning.. thus relying on just some UTXO set and knowing that the main irritation of newbies syncing for the first time is not so much about the delay itself but the fact they cant see a final balance untill synced to know if they imported the right wallet.. you might aswell just let nodes grab a UTXO set to atleast give users an upfront 'unverified' balance so people can get on and do things. which then makes sitting around twiddling thumbs a non-issue. thus the initial sync then becomes just a background second afterthought.
much like gaming these days that do small install of a light demo level that people can play with while the main game is in the background downloading. thus people get a initial glimpse/ useful experience upfront and are more happy to let a decade of data download in the background. win win basically.
(i dont mean have this as default/forced feature. but an option box like prunned that can be chosen for those people who nag about having to wait days/weeks before they can do anything with a full node)
13683  Bitcoin / Bitcoin Discussion / Re: Decentralisation is harder than you think on: February 09, 2019, 10:56:30 PM
at what point would there ever be 100% agreement on a change? how would you ever be able to measure that? you're trying to confuse things with loaded and political terms. please try and stick to discussing what nodes are actually doing.

let's take segwit as an example.

by running my legacy node in 2017, i opted into to the consensus---i agreed to the current set of consensus rules. when segwit happened, my legacy node retained consensus with all segwit nodes. there was no chain split. therefore, segwit never violated the consensus that i agreed to. that consensus still exists today and i am still opted into it.

with a hard fork, that consensus would be broken by definition. hard forked nodes would be ignored by my legacy node because the two disagree about what the consensus rules are.

as for the whole 'backward compatibility' where older nodes get a stripped out data thats not fit for the full relay layer, and thus forms an underclass of downstream/filtered nodes. yes thats a soft fork as no one is dictatorially thrown off the network. but activating a new ruleset by excluding a certain class from a vote before the ruleset is even activated is not consensus. its a controversial softfork

your position on "downstream/filtered nodes" obviously disagrees with the design as satoshi wrote it:

The solution was script, which generalizes the problem so transacting parties can describe their transaction as a predicate that the node network evaluates.  The nodes only need to understand the transaction to the extent of evaluating whether the sender's conditions are met.

The script is actually a predicate.  It's just an equation that evaluates to true or false.  Predicate is a long and unfamiliar word so I called it script.

The receiver of a payment does a template match on the script.  Currently, receivers only accept two templates: direct payment and bitcoin address.  Future versions can add templates for more transaction types and nodes running that version or higher will be able to receive them.  All versions of nodes in the network can verify and process any new transactions into blocks, even though they may not know how to read them.

1. yes never 100%. but i was addressing your comment about 100%.. just to correct you that if in YOUR scenario of 100% that there would be no fork. but instead just an united upgrade.
i then went on, passed your limited scope.. and i digressed to show the other parameters of majority(under 100%) and then controversial(less than majority).. it was not me that was highlighting just a 100% agreement. that was you.. like i said i went and explained the multiple levels of what happens when less and less agree and i also described how things play are when nodes are thrown out before consensus(to fake a vote)
...
but in short segwit only got 35% in spring 2017 and so instead of going back to the drawing board with a new option of a varient feature. they doubled down and really pushed for their segwit1x controversially

2. what you dont realise is that downstream/filtered nodes are not just skipping transaction full verification and just saying they pass a minimal test.. these nodes are actually being handed stripped data. which if they were part of the relay layer, the main relay layer nodes would reject the blocks. so its not true compatibility. its just fake compatibility t keep an underclass online but without voting rights (you might want to look into it.. ) the block data 'compatible' nodes get is not the same data full nodes get.
presuming 'compatible nodes' are true full relay nodes and have same vote rights is a flaw in your understanding of the relay network.

3. also before the segwit new ruleset even activated there was a controversial biased fork. some devs called it a bilateral split, amungst many names, but the devs do not deny that a controversial non consensus hardfork occured to push opposition off the network to then get a faked approval vote to get segwit1x activated.
there was no "honest consensus" / "honest node" event around how segwit1x got activated.

some people really need to do some research.. or atleast before trying to deny events happen. atleast speak to devs and realise devs do not need to be defended by lying and saying events didnt happen if said devs are happy to admit their own actions/involvement.
i see no reason for you to pretend things didnt happen. as it defends no one. and also blockdata which is immutible can prove you wrong, let alone quotes from devs themselves. so i wonder what are your motives for continuing the echo chamber of mythical nonsense that a certain group of of people want to continue pushing...

... as the only motive for such i can see is that certain echo chamber group. do NOT care for bitcoin. but only care for keeping bitcoin stifled to then promote another network(LN) where the echo chamber can only hope to become factory/watchtower nodes to be greedy income earnrs.. which if you play out scenario's of LN the echo chamber would soon learn they they wont get to be the hubs of get rich quick. as it will end up being the custodial services of the DCG portfolio that will be the big income earners.. all at the expense of making peer-to-peer self control a thing of the past, while the aim is to push the community into counterparty controlled, banking system which is not community/blockchain confirmed/validated. but instead co-custodian managed and manipulatable. thus killing off the whole point of bitcoin by making bitcoin too expensive and also too small utility to be useful
13684  Bitcoin / Bitcoin Discussion / Re: Decentralisation is harder than you think on: February 09, 2019, 09:25:52 PM
I do know what is a consensus. But consensus doesn't work. Yes, it does if we are only 10 people, not difficult, but it can't work with everybody included. And it can also work if people are ready for some compromise.
Imagine a consensus in politic, do you really think it's possible? Hell no.

the idea of getting consensus to change a protocol like bitcoin is insane. there's millions of users. there's no way 100% of users would ever agree to a hard fork, except maybe in the narrow case where the protocol is under existential threat from a bug (like if ECDSA were broken).

that's one of the strengths of soft forks. if backed by majority hashpower, they are compatible with the prior consensus. if consensus is never broken, you don't need 100% of users to agree to a fork. everyone can co-exist with backward compatible software.
you been sniffing too much of the echo chamber mantra.

if there was 100% agreement. there would be no soft/hardfork. as everyone would be in agreement. thus they all follow the new rule, thus no fork.. just an upgrade

in a majority consensus(majority but not 100%) the minority wont be hard forked to a different network. they would just be stalled out. same network just not receiving new blocks/data(soft fork).
the minority then decide if they rejoin. or make their own network

in a controversial hardfork where nodes are banned off the network before activation and not due to activation. well thats dictatorship at play.
in a controversial hardfork where code is activated AND THEN nodes are banned/thrown off the network due to rule incompatibility. well if pools were in that group thrown off.. then a new network would occur(hard fork)

as for the whole 'backward compatibility' where older nodes get a stripped out data thats not fit for the full relay layer, and thus forms an underclass of downstream/filtered nodes. yes thats a soft fork as no one is dictatorially thrown off the network. but activating a new ruleset by excluding a certain class from a vote before the ruleset is even activated is not consensus. its a controversial softfork

core pulled of many tricks to get sgwit1x active.. they didnt and make a more community acceptable compromise when they seen they only had 35%. thy decided to get controversial and fake consensus
13685  Bitcoin / Bitcoin Discussion / Re: Decentralisation is harder than you think on: February 09, 2019, 08:59:30 PM
I do know what is a consensus. But consensus doesn't work. Yes, it does if we are only 10 people, not difficult, but it can't work with everybody included. And it can also work if people are ready for some compromise.
Imagine a consensus in politic, do you really think it's possible? Hell no.

hell yes.
politics with consensus = democracy
politics without consensus = dictatorship

the only reason politics dictatorship is limited to one vote per 4-5 years is the fact that it takes people having to walk to a polling station per vote, which is lengthy to organise. yet things like america's got talent can achieve voting using technology more often than politics hense why americas got talent does voting every year.

with bitcoin where nodes are always online voting can happen even more rapidly. it just requires devs to not biased throw out certain classes from a vote and instead accept a vote didnt go their way(35%) and instead have them compromise and re try a new proposition, rather than dig deeper with thir proposals and get buddies to social drama other fake options to pander out the opposition and sway/threaten others to accept the dug deeper proposition.

but yea.. consensus can work, but has been bypassed so now consensus(byzantine generals problem) has been sidelined so absurdly that it has now made consensus 'broke' and core show no sign of wanting to go back to a consensus system of satoshis invention as they now control and dictate the rules.
Luke JR is super happy that he gets to do that as and when he likes without opposition now
13686  Bitcoin / Bitcoin Discussion / Re: Can bitcoin sustain itself on fees alone? on: February 09, 2019, 05:11:48 AM

people DO NOT need to pay high fee's to make bitcoin mining functional. here is why

1. having an increased transaction count per block can offset this.
    EG 2000 tx of 25cents doesn't mean 2000 tx of 50cents after a halving. instead 4000 tx of 25cents offers the same solution
    this is not a point where the usual snake charmers shout out "gigabytes by midnight" or "blockchains cant scale".
    reality is they can scale. and it doesnt need to be jumping extra large real fast. but progressively over time


Are you finally admitting that the block size increase in Segwit was the right decision at the right time? Cool

no, he is still saying the same thing as ever. to increase the block size itself with a hard fork but instead of jumping to a ridiculous number like 32 byte, go at it with a slower pace like increase to 2 MB first then maybe a couple of years later to 3 or something like that.
although I still don't understand why he is denying SegWit's scaling that happened already!

firstly it is you segwit/LN lovrs that have been the ones spouting out gigabytes by midnight.. no one else
secondly segwit did not/does not offer any bettr scaling for the bitcoin network. sgwit actually if you count the bytes per transaction, segwit is WORSE than legacy.. however segwit hides the real bytes with the wishy washy witness scale factor, stripped data and vbyte crap

my stance for years has never been jump to gigabytes ASAP but instead do what happened before 2015.. which was scaling.
2009-2011 0.25mb
2011-2013 0.5mb
2013-2014 0.75mb
2014-2015 1mb

segwits 4mb is not actually 4mb.. its a tx data base area of 1mb and a tailend area for signatures. the issue is by bloating up bytes per average transaction via new features. and the cut out the signature in the bas area still keeps the max tx count roughly the same.
EG
1mb legacy had a 600k a day tx count implied offering which is a number known back in 2010
but due to bloated features and new use-case features. blocks surpass 1mb of data.. yet we have not had a single day that has surpassed a 600k transaction count for a day.  

secondly my stance of fee's is that making veryone pay an average. and that average being hit due to how much demand there is, is not useful for anyone. as all it does is promote stalling/stagnating bitcoin scaling purely to try keeping a fee average up.

however RE-introducing a fee priority mechanism that is more based on age of funds. EG spammers that have funds only 1 confirm age pay more than a user that have funds that are over 144 confirms pay less.
this means people still pay fee's even if blocks are full or not as fees are not linked to a stifled blocksize.
it also penalises spammers, and to flip the argument incentivise those spammers that multispend a day to see the benefit of LN.
whilst those that only spend once a day/week/month dont get penalised to the same average.. they also because they dont spend often wont see benefit of LN anyway so shouldnt be burdened with paying the same price as spammers
13687  Bitcoin / Bitcoin Discussion / Re: Joe Rogan and twitter CEO Jack Dorsey in trouble for bitcoin fraud? on: February 09, 2019, 01:42:49 AM
I mean it's nasty that they didn't disclose sponsorships

didnt disclose?
...
its public information.
its not a secret

the actual issue is that some people didnt like that some dude got to talk about a subject he prefered rather than a subject some viewers wanted to see...

its like interviewing daniel radcliffe about a new movie but some viewers get very anally butt hurt that harry potter was not brought up in the conversation

its like interviewing arnold schwarzenegger about politics a few years back but some viewers get very anally butt hurt that terminator was not brought up in the conversation
13688  Bitcoin / Bitcoin Discussion / Re: How does block size harm decentralization? on: February 08, 2019, 10:10:42 PM
imagine getting to see a 'unverified' balance within seconds of opening your node for the first time. via SPV methods(grab a rlatively fresh UTXO set from peers). and thus using a fresh UTXO set, then able to know you have imported the correct wallet by seeing aatleast a unverified balance and also then able to make transactions.. then the whole blockchain syncing becomes a background issue rather than a stare at the screen waiting issue

its like online gaming/phone apps these days. get to play with a small single level demo of a game whilst the whole game downloads in the background. people can the be instantly entertained and not be as concerned about waiting for the game to download, as that main download is treated as a background issue
Why not just use a lightweight client then? If you just want to send transactions and see your balance then you can just import that wallet in an SPV client. The assurance you get from verifying all TX's via your full node isn't meant to be an annoyance, we shouldn't be taking a full node and downgrading it to some kind of hybrid; there's a reason SPV exists.

its not about turning a full node into a SPV.. although. funnily enough core's prunned chain feature and stripped block featurs actually allow a core node to not be a full node.
its not about turning a full node into a SPV.. its about allowing users to still be full nodes. but also get some unverified upfront information to help them out straight away rather than waiting


the way i see it is that not everyone NEEDS to be a full node. so yea people can use lite wallets.
the way i see it if you only have balance to only b spending occassionally (once a week) you dont need to monitor every transaction there is all day every day, all you really care about is that your transaction exists. so being a full node is not an essential need.

where as businesses that NEED to monitor hundreds/thousands of transactions they are personally involved in have personal reasons to NEED to be a full node.

also those few people that have slow internet because they are home users actually bottleneck the propogation. and thus they are not helping the network. so just being a full node for the sake of thinking they are helping, is actually doing the opposite.

if people really want to be full nodes then they need to expect some sort of effort is needed by them by actually having hom broadband instead of borrowing starbucks wifi occassionally.

its like online gaming. wanting to play the latest game but not having the latest console to play it. if you really want to play the latest games then buy the latest console. rather than say that online gaming should be regulated down to only being sega megadrive(genesis)/n64 graphics purely to be universal

imagine it. the gaming community first saying online gaming should be regulated down to sega/nintendo specs.. and then saying that online gaming should then charge 20cents per 10 minute game round.. thus ruling out utility for the same group that only want sega/nintendo standards by way of fee's..

and then going further. having a special screen that offers HD standards but you need to sign a contract that locks your funds up with a custodian that then server streams you HD content to screen, purely so you can play hd games for sub-pennies without the need of a console.

there is just so much hypocrisy of flip flop arguements that it becomes amusing.
LN's design is for the fast microtransactions niche:
do you really think LN users will take their desktop computers running as masternodes to validate all the mainchains that are LN compatible into starbucks to LN purchase a coffee.. or just use a phone app linked to a LN factory/watchtower server..
as the answer will tell you that LN will be more centralised than people think

too many people think that the answer to bitcoin is just 2 debates
low utility high fee.. or gigabytes by midnight low fee
big server farms.. or everyone NEEDS to be fullnode
13689  Bitcoin / Bitcoin Discussion / Re: How does block size harm decentralization? on: February 08, 2019, 08:53:14 PM
I'm surprised people don't mention about Compact block when we're talking about block propagation, block size and scaling. But it's not applied for nodes that just went online though

1. Block propagation is very fast as compact block have very small size (AFAIK about 10-30KB for 1MB block size)
2. Block verification time is fast as all transaction inside block already confirmed when it's broadcasted
3. AFAIK both block propagation and verification time should take less than 20 second (based on a presentation/conference video i've seen few years ago)

Regardless, few things such as Initial sync is serious concern as it took few days to few weeks (depending on internet speed, storage speed, etc.)

the main irritation about the initial block sync is not actually "cost".. but the time.
and when actually poking deeper at the irritations the main rebuttal i hear again is not cost. but the fact that people cannot see their 'final balance' until the syncing is complete. which means they cant really easily see if imported their wallet correctly or even make a transaction until the syncing is complete.

this can easily be remedied.
imagine getting to see a 'unverified' balance within seconds of opening your node for the first time. via SPV methods(grab a rlatively fresh UTXO set from peers). and thus using a fresh UTXO set, then able to know you have imported the correct wallet by seeing aatleast a unverified balance and also then able to make transactions.. then the whole blockchain syncing becomes a background issue rather than a stare at the screen waiting issue

its like online gaming/phone apps these days. get to play with a small single level demo of a game whilst the whole game downloads in the background. people can the be instantly entertained and not be as concerned about waiting for the game to download, as that main download is treated as a background issue.

lastly the fee being more than a few hours of minimum wage labour for MILLIONS of people in third world countries deters more people than the cost of a hard drive or internet access
13690  Bitcoin / Bitcoin Technical Support / Re: pff priority transfers have zero confirmations after 5 hours on: February 08, 2019, 08:37:16 PM
Ow boy had to make 2 urgent transfers this afternoon. So at 1pm CET (5 hours ago) I made 2 transfers from my blockchain wallet. I set fee to priority to be confirmed within 60 minutes. Now after 5 hours both transactions even do not have a single confirmation.... Undecided

core removed a fee priority mechanism where the network would follow years ago

now everyone ends up paying the same 'estimate' for transactions they want accepted. and thats the foolish part. if everyone pays the same estimate, then no one gets priority.

EG 2000 seat train. fee's to get on th next train are a premium of 10cents.. 4000 people pay the extra 10cents.. not everyone gets on the next train... in 10 minutes another 4000 pay the 10cents extra.. the spare 2000 from first allotment are in no bettr position than those in second allotment. so out of 6000 waiting for second train. its again random selection out of the 6000.. not 2000 get priority due to first allotment
13691  Economy / Speculation / Re: new bullish run on: February 08, 2019, 07:36:11 PM
not a bull run...
its just a calve(baby bull) playing with cubs(baby bears) on the same field

bull runs are not hours old..

there is a mining cost:market price dynamic at play and hashrate hit the 50exahash again for the first time in months.
this can explain the SPECULATIVE rise(hours/days). but it takes time for a sustained 50exahash to play out as a bottomline SUSTAINABLE value dynamic on the market(weeks/months).

so its too early to scream bull. as the hashrate part of the dynamic may just be a temporary blip
13692  Bitcoin / Bitcoin Discussion / Re: How does block size harm decentralization? on: February 08, 2019, 06:42:01 PM
Larger blocks cause propagation delays. This increases orphaning rates, which disproportionately hurts smaller miners

propagation is currently SECONDS.. so SCALING block sizes to atleast get passed the implied 600k transactions a day limit is not going to cause issues.

secondly nodes dont even need to receive the full block data in one lump. they can get blockheaders. and thn attach the transactions in their own nodes mempools to fill in the blanks and only request the few missing transactions that didnt get relayed to them. so again if nodes are only receiving block headers. the propagation is still low as the transactions element of a full block is not being sent with it.
a blockheader(~80bytes) of 2000tx includes TXIDs of 6bytes(compact/shortIDs) per tx =12kb
so instead of sending 1mb of a full block data blockheaders can be a little over 12kb
meaning a block of 4000tx =24kb (compared to 2mb)
meaning a block of 8000tx =48kb (compared to 4mb)

thirdly. "miners" dont care about blocksizes. get a screw driver and look inside an ASIC.. you will find no hard drive. asics do not store blockdata. they are just given a small piece of data and their job is to send back a hash. that is all

fourthly
bitcoin core has already dropped compatibility for xp/vista and so should drop minimum hardware specs of such outdated levels. we are not in the 1990's and should not be trying to keep bitcoin relevant to PC specs of a decade+ ago
average joe upgrades their PC's every 2-6 years.
imagine online gaming industry.. how innovative would they be if they had to keep specs down below millenium/decade old tech/spec..
the whole need to keep bitcoin functional for a raspi spec is just empty excuses.. because even on a raspi bitcoin is capable of more than 600k transactions a day processing

fifthly
scaling is not just about pure blocksize increases.. it is most definetly not about jumping to "gigabytes by midnight"
scaling can be done by
actually avoiding adding features that cause a byte per tx bloat.(sgwit actually uses more bytes per tx, but then hides the real bytes with its pseudo math of vbytes and witness scale factor and other wishy washy code)
core also STUPIDLY allow a block to be treated as filled by having just 5 transactions, with lots of sigops.. so reduce the sigops means more transactions, and less concern over any legacy linear sigop processing delays(yep core instigated the linear sigop delay drama by even allowing a transaction to have thousands of sigops.. all so they can sway people into accepting the LN gateway tx format called segwit)

in a peer-to-peer cash  system. a peer does not need transactions of 16k sigops. in most cases they only need 2-5
thus going to that kind of transaction format of low sigops would actually speed up transaction validation where by more than 2000tx under low sigop counts can validate FASTER than 200tx under the current ratio

sixthly
fee's do not need to be pressured by a fe war over a limited space. it can be done be RE-introducing a fee priority mechanism.
a mechanism such as if a users funds are only 1confirm aged. they have to pay 144 times more than someone that only spends once a day(144confirm age). that way it actually means the whole community do not get pressured to pay the same high amount due to just a couple of spammers filling blocks.. but instead the spammers pay the price of spamming and its the spammers who want to spend every 10 minutes that would then see the incentive of using commercialised service networks like LN. while more modest ethical users get to remain happily using the bitcoin network still paying a more acceptable fee amount where because they dont spend often they wouldnt have benefitted from LN anyways.
simply trying to push EVERYONE, including the modest spenders into LN with the whole fe war pressure helps no one
13693  Bitcoin / Bitcoin Discussion / Re: How does block size harm decentralization? on: February 08, 2019, 06:08:17 PM
If we keep increasing block size, "more transactions" doesn't imply a requisite increase in fees. That all depends on how limited block space is. If we increase block size beyond demand because technology advancement allows it (Like Bitcoin Cash), fees will drop towards zero. We need full blocks and a constant transaction backlog, otherwise there is no fee pressure.

Now, what evidence do you have that "higher fees will kill Bitcoin?"

pools dont need fee's for decades
so drop that mindset of them needing fees now

causing a transaction backlog and fee pressure NOW kills off the desire and utility of bitcoin.
people dont and wont want a system which costs them more than other networks and still get delays (yes im using LN's promotion).
the very point that people love and want LN is the very point that proves that people are already angry and disliking bitcoin.
so why is bitcoin hated and detested. because fee's are too high and mempool backlogs cause bitcoin to be too slow.

if fee's were low and no backlog, people would love bitcoin and not care for LN... LN would then be seen as just the commercial service for business hubs to make money from by offering a banking system(counterparty authorised tranasactions)
13694  Bitcoin / Bitcoin Discussion / Re: How does block size harm decentralization? on: February 08, 2019, 05:49:30 AM
No franky1, I know you are 100% against the LN and I respect that, but you should also be able to see that Block size scaling is not the way to go, if we want Bitcoin to go mainstream. If the LN can only handle most of the micro payments, then we have already made significant progress. <Let's give it some time to mature and to show it's advantages over Block size scaling. >

Yes, every method has it's advantages and disadvantages, but stagnating on one method <because it was Satoshi's original idea> is not very innovative or creative at all. We have talented developers with lots of new ideas that might improve on Satoshi's original implementation.  Wink

3 years after we hit the implied tx count limit and bitcoins network has not improved.. instead "use this other network and stop using bitcoin".... (facepalm) thats a 200 year old business model which we all know how it ended

gold is limited utility, lock it up and use these promissory notes, oh and by the way it will be expensive if you want your gold back so here have some silver and nickel if you dont wanna play with promissory notes
13695  Bitcoin / Bitcoin Discussion / Re: How does block size harm decentralization? on: February 08, 2019, 05:31:32 AM
A gradual increase in the Block size was a old method to scale, since then new innovations like second layer applications <Lightning Network> was introduced to reduce the burden on the Blockchain to prevent a scenario where the Blockchain grows too fast for people to be able to affordably run nodes with big enough storage space. <It is also significantly faster than the Blockchain>
LN is NOT a bitcoin network. it is a thunderdome network for multiple coins.
for those that dont get the movie reference.. its a fortknox custodial banking system of not 100% control

which once you enter it. you wont want to leave and obtain BTC on exit. because it will become too impractical/expensive(fees) to close out and withdraw bitcoin from the locks

people will end up just atomic swapping to altcoin ious(12 decimal unconfirmed LN payments) within LN and exit using LTC or other coins that have been modified to have gateways to LN but have more transaction counts and cheaper fee's

oh by the way. those wanting to be full nodes for LN will end up actually harbouring multiple chains to allow channels to atomic swap. so if bitcoin for instance is too much to handle. imagine full node running multiple chains at once..
stick that scenario in your play book and run with it.. itll shock you in a hard way

LN's design is to take utility AWAY from bitcoin

People like Roger Ver and supporters of Block size scaling will learn the hard way, that it is not a good strategy for the long-term and definitely not if it goes mainstream. <Currently BCash has huge Block sizes and only a small percentage of blocks are used to capacity>

^ blah blah blah social drama distraction.

im guessing your the kind of person that only has one plate, one knife and fork and one shelf in your kitchn because you only plan on minimal reserves.

smart people have extra wardrobe space in their bedroom. a full plate and cuttlery set in the kitchen so that they can cope with change and growth/expansion rather then race around at the last minut when theings happen

EG when you buy a computer do you buy a computer with the minimalist of features or do you try to buy a computer that has more than you need so that yor covered for future changes?
13696  Bitcoin / Bitcoin Discussion / Re: How does block size harm decentralization? on: February 08, 2019, 05:11:38 AM
block size does not harm decentralization, how block size is increased can do that. for example if you increase it suddenly to a much bigger number now it will end up centralizing bitcoin but if it is increased slowly with the advancement of hardware and internet speed then it can't do much harm.

There's still a larger problem here that most people don't discuss. Even if hardware advancement allows us to significantly increase block sizes over time, that doesn't address whether doing so is compatible with Bitcoin's hard cap on supply.

Without inflation, the system needs fee revenue to continue incentivizing miners. The block size limit is the only means we have to enforce scarcity of block space, which guarantees fee revenue. Otherwise, Bitcoin's Byzantine fault tolerance may be threatened as block rewards decline in value. You can't have a network worth many billions or trillions of USD where miners have no incentive to secure the network.

what your not realising is that you cant have a network that is core demandd to stick with under 600k transactions a day as that then just makes the network only useful to under 600k people wanting to use/monitor/care about bitcoin daily.

people end up using other networks that are cheaper and able to process more than 600k transactions a day and bitcoin is left stranded as the coin no one wants to return to because the costs become too high..

LN thunderdome: btc and LTC iou's may enter, only LTC iou's may leave

secondly the REAL incentive to pools is not for the next few decade requiring fee's. the block reward is sufficient enough
(in short dont even bother bringing 'fee's for pools' into a scaling debate unless its a few decades in the future)

thirdly fee COST USERS funds, not incentivise users.
arguing that things need to be done for user benefit, then push that argument aside to then say fe's need to rise to benefit pools. is just playing games and empty excuses as to why scaling should be stalled/stagnant

again forcing utility to remain at 600k a day transactions helps no one, incentivises no one and actually makes peopl want to care less about bitcoin if they cant use it as and when they like.

so if it costs something just to monitor 600k peoples transactions as a user.. and then costs a user $1+ just to use it themselves. then its the fee's that will push people away far sooner.

the real goal would be to
allow more transactions
allow the combined (lower fees) to accumulate to be more as a total.

thus making bitcoins blockchain USEFUL for users. and also cheap to use for users.thus users continue to be full nodes

which after years of progressive growth would then become enough to cover costs for pools eventually(when pools actually need it)
13697  Bitcoin / Bitcoin Discussion / Re: A conspiracy against Bitcoin? on: February 08, 2019, 01:35:07 AM
It wasn't until we saw consensus in action that it became more apparent just how strongly people feel about it.
and under HONEST consensus.. core only got 35%

Those people who are supporting this network without reimbursement by running a non-mining node have already paid a cost, so understandably they will enforce rules on the network which prevent increasing that cost against their will.  More people now seem to respect this logic.
yet core implemented an activation that was done via controversial means.....

seems you really need to get out of your echo chamber of myths.
again the devs themselves will happily admit their actions.. so i wonder why are you still defending them as innocent when they plead guilty to their actions

so mr flip flop who in one post admits that disconnecting nodes PRE activation occured..
where is the "network that prevents x against their will" where is the "respect"
(pre-empt echo:
mandated controversial bilateral split
inflight upgrade
controversial forks
compatible sheep nodes of abstaining counted as approval)

you can flip and flop in and out for many more  months..(i dont see why you prefer to continue that, as its no longer funny, but making me yawn at you now)

 or just sit back do some research, update your echo chamber and then comeback with a single narative.. or you can skip your flip flop narative and just get to the point that you want bitcoin to remain low utility so that commercial networks become popular in the hopes that you can get paid for running a commercial hub on such commercial networks..

but. to help you out and pr-empt future echo's about your desires of geting paid as a full node.. you will run into the infographic windfury provided that will show who will actually get to be the commercial hubs making income from running full nodes.

meaning your not gonna get rich supporting cores roadmap. so atleast wake up to your motives and how they wont manifest into you getting rich by sticking with the myth echos of supporting core centralists
13698  Bitcoin / Bitcoin Discussion / Re: A conspiracy against Bitcoin? on: February 08, 2019, 01:23:15 AM
https://bitcoin.org/bitcoin.pdf

Quote
The proof-of-work also solves the problem of determining representation in majority decision
making.  If the majority were based on one-IP-address-one-vote, it could be subverted by anyone
able   to   allocate   many   IPs.     Proof-of-work   is   essentially   one-CPU-one-vote.     The   majority
decision is represented by the longest chain, which has the greatest proof-of-work effort invested
in it.

Thank you for proving my point.  The longest chain told incompatible clients to gtfo and they did.  It's almost as though it does exactly what it says on the tin.

thats talking about if nodes ACTIVATED differing rules.. (dishonest nodes) that dont wait for consensus
try to do some research

Quote
Any needed rules and incentives can be enforced with this consensus mechanism

Yes.  A rule was enforced with the consensus mechanism to disconnect nodes flagging bit 6 and bit 8.  It literally says right there in the whitepaper that new rules can be enforced and that's precisely what happened.  Now that you've literally just explained it to yourself, does it make sense now? 

I swear if Inigo Montoya were here, he'd tell you that he doesn't think those words mean what you think they mean.  And he'd be right.   Cheesy

thats talking consensus.. YOUR talking about enforcing rules by bypassing consensus by controversially disconnecting nodes before HONEST MAJORITY


now...
show me in the white paper where it says the network should be run by one team of devs code where everyone has to be sheep to that one trusted party

First you'd have to convince me that's what we currently have.  I can't use written documents to confirm or deny things that only exist in your imagination.  You should try speaking to a therapist.

your own flip flop statements and showing how you love core and saying how core has majority
node count websites

and by the way. the minority of diverse nodes are not part of the main relay network. they are ringfensed as 'downstream' 'filtered' nodes as a layer below the main relay network.. should you want to do some research devs will tell you this. they even made those buzzwords and even pretty pictures to show its true and they also went as far as making a guide to say that those not upgrading to cores new rules will be set as a lower tier than the fullnode relay network.

try to do some research. its been months but your still stuck at the same echo excuses and fud of previous myths which even the devs were happy to admit were myths.
13699  Bitcoin / Bitcoin Discussion / Re: How does block size harm decentralization? on: February 08, 2019, 12:53:53 AM
I think the idea is that advances in networking technologies will mean we can transfer more data in the same amount of time as. As long as networking capacities grow quicker than the blockchain then we will be able to avoid the problem you have described.
I don't think the network is the problem, sure initial download of the blockchain would take a really really long time (especially if you verify every tx signature,  but that can be skipped anyway), but day to day broadcast of blocks and transactions would be fine.

My understanding is that it's just a disk storage issue.
even though if you do the math of sending a full block to another user 1block of 1mb legacy transactions every ~10 minutes is1.66kb/s (even dialup can handle that)

so yea those against BITCOIN adoption/scaling are not really true 'bitcoiners' as they prefer to be stuck shouting out that bitcoin cant scale beyond 1999's technology
Again I don't think it's a network issue. If the block size was 8mb like in BIP-101 then it would be 13.33kb/s. I'm certain modern day CPUs can handle the tx verification even if we increased the # of txs a lot, and there really doesn't seem to be a network issue unless I'm totally missing something; so it must be storage.

its not even about storage
1mb base block =52gb a year(4mb=~200gb)
i can get a 256gb microsd card(size of a fingernail)
i can get a couple terrabyte hard drive for less than a week of groceries cost

funny thing is those worried about 1mb+=bad, before 2017 suddenly shut up when it became convenient to allow 4mb to allow the gateway to another network..

yet millions-billions do facetime/stream HDTV,they play online games and upload the gaming while narrating while streaming HD content all the same time.
and happily would take up hundreds of gigabytes of data. just so they can run around a map shooting people

but yet strangely the rhetoric of same data, same speeds becomes suddenly impossible in regards to bitcoin
13700  Bitcoin / Bitcoin Discussion / Re: How does block size harm decentralization? on: February 07, 2019, 11:46:59 PM
the debate is that those that want people to be pushed off bitcoin and into other networks will say bitcoin cant scale and blockchains ar broke because they want people to use commercialised networks/services.

the myth presented about bitcoin is the whole "gigabytes by midnight" fud that is being pushed by those commercial lovers, to make is sound like bitcoin has to remain at 1mb base block or jump to gigabytes.

the funny part is that progressive SCALING (step by step growth) like what WAS allowed 2009-2015 (0.25mb, 0.5mb, 0.75mb,1mb) pretty much went stagnant at 2015

even the supposed 'segwit' has not achieved a scaling solution ONCHAIN and we are still stuck at the implied limit of 600k transactions a day, while segwits true purpose is to be used as the gate way tx format for an alternative network

even though if you do the math of sending a full block to another user 1block of 1mb legacy transactions every ~10 minutes is1.66kb/s (even dialup can handle that)

so yea those against BITCOIN adoption/scaling are not really true 'bitcoiners' as they prefer to be stuck shouting out that bitcoin cant scale beyond 1999's technology

the only reason to keep to the implied 600k tx a day, is purely to incentivise commercial services to advertise their alternative networks/services while also pushing the fee's of bitcoin up to keep users from wanting to utilise the bitcoin network
Pages: « 1 ... 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 [685] 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 ... 1472 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!