Bitcoin Forum
September 22, 2019, 04:39:53 AM *
News: If you like a topic and you see an orange "bump" link, click it. More info.
 
   Home   Help Search Login Register More  
Pages: « 1 [2] 3 »  All
  Print  
Author Topic: Are non-Segwit nodes, full nodes?  (Read 457 times)
franky1
Legendary
*
Online Online

Activity: 2520
Merit: 1464



View Profile
November 13, 2018, 06:39:52 PM
Last edit: November 13, 2018, 08:10:48 PM by franky1
Merited by vapourminer (1)
 #21

(facepalm)
not fully verifying..
dont directly participate

full nodes doesnt mean just verify transactions aimed at you. it means fully validate all data to ensure NETWORK security.
come on. imagine if all nodes didnt fully verify.
the whole point of full nodes is that the whole block should be verified.

The point of running a full node is to validate payments received. That's what "being your own bank" means -- validating payments you receive against the protocol instead of trusting a centralized authority.

If a legacy node forwards valid transactions it doesn't fully understand, how does that jeopardize network security? Can you explain how Segwit jeopardizes network security and why we haven't seen the "ANYONECANSPEND attack" come to fruition?

short answer to that debate was that full nodes should validate everything. not just its own personal needs but validate the networks data.

Why? Explain how legacy nodes are endangered, and why the network is now insecure.

to those that do want to learn about full nodes. research
NODE_NETWORK, NODE_BLOOM, NODE_WITNESS, NODE_NETWORK_LIMITED (1037)

1. litenodes are more intended to just validate that your own personal transactions are verified in a block(there are many variants that can give you variant levels of data that are as simple as just blockdata related to your own list of addresses(bloom).. just the latest 288 blocks(nodenetwork limited) all the way up to full blocks of data(nodenetwork)).. but a full nodes purpose is to have full data and have that full data fully verified(all of the above).

2. "instead of trusting a centralized authority" yep. exactly.. so legacy nodes are trusting the segwit node validated ALL  transactions... (ofcourse its not your transaction,, but a full node is about network. not just personal)
(emphasis "full node" does not mean "personal only my transaction node" it means "full node")

3. full nodes are to validate the FULL DATA for network security. and to have full data to allow the other network participants to have a source to get data from.

4. and no. dont try to dilute the meaning of full for 'personal use' as thats just weakening the amount of nodes available to properly sync to.. imagine it. nodes pruning out transactions that are not important to that person.. means the next peer cant get them

imagine if some nodes had a stripped block of legacy only.
imagine if some nodes had a pruned block of only data that was still UTXO
and only 1 node was actually fully archival.

now imagine a fresh user wanted to run a actual full node. guess where they will get thier data from.
it wont be from the stripped nodes.  it wont be from the pruned nodes.

thats why its important to identify whats actually a full archival node.
same goes for validation
no one wants to be messed around with receiving invalid data, even if their actual full node is going to full validate anyway. but atleast knowing theres many true sources of believed full valid data. saves time and hassle of not having to drop connection and wait for data

in short. imagine if out of 10,000 nodes.. not all are actually full archival, fully validing nodes.
but a mish mash.
thats not supporting the network with a 10,000 strong network of full 100% 10k copies of the blockchain. the reality is far less than 10k.

as for the anyonecan spend stuff.. thats where many argued from 2016+ and the end result was dont release the wallet for making a segwit tx until weeks after nodes activated.
(the arguement prior to activation was that its fine, all compatible and people could make segwit transactions inflight without consensus)

but end result was consensus was needed. hense the november 2016 consensus
consensus was not reached. hense the mandatory
then after the mandatory. the wallet facility to actually make transactions was allowed weeks later.

..
now if there was a bug and segwit was deactivated the transactions revert back to anyonecanspend. and because pools are the ones collating the transactions. guess whos gonna pick up those funds

..
as for the if legacy dont forward transactions it dont understand how does that jeopodise the network.
(funny)
if the network doesnt actually have 10k full nodes that do forward.. but only a few... imagine that,

trying to say there are 10k nodes that do a to z. when in fact theres one a few thousand that do a-z shows how people dont understand that the numbers are fudged

...
ok imagine it this way
you go into a shop. wanting a buy a few things. you prechecked online and seen 10 in stock.. you go to the store and told actually theres only 3 in stock as 7 are either older models, asian 'replica's missing vital things or they are ex display

would you treat them all the same or question the quality of the 7
you probably would likely ask why were they not advertised as ex demo or exrepair or replica models to save your journey and so that your fully informed before getting involved in a decision process.

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
1569127193
Hero Member
*
Offline Offline

Posts: 1569127193

View Profile Personal Message (Offline)

Ignore
1569127193
Reply with quote  #2

1569127193
Report to moderator
1569127193
Hero Member
*
Offline Offline

Posts: 1569127193

View Profile Personal Message (Offline)

Ignore
1569127193
Reply with quote  #2

1569127193
Report to moderator
1569127193
Hero Member
*
Offline Offline

Posts: 1569127193

View Profile Personal Message (Offline)

Ignore
1569127193
Reply with quote  #2

1569127193
Report to moderator
"With e-currency based on cryptographic proof, without the need to trust a third party middleman, money can be secure and transactions effortless." -- Satoshi
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1569127193
Hero Member
*
Offline Offline

Posts: 1569127193

View Profile Personal Message (Offline)

Ignore
1569127193
Reply with quote  #2

1569127193
Report to moderator
1569127193
Hero Member
*
Offline Offline

Posts: 1569127193

View Profile Personal Message (Offline)

Ignore
1569127193
Reply with quote  #2

1569127193
Report to moderator
1569127193
Hero Member
*
Offline Offline

Posts: 1569127193

View Profile Personal Message (Offline)

Ignore
1569127193
Reply with quote  #2

1569127193
Report to moderator
Zin-Zang
Member
**
Offline Offline

Activity: 364
Merit: 11

Killing Lightning Network with a 51% Ignore attack


View Profile
November 14, 2018, 04:22:12 AM
Last edit: November 14, 2018, 04:35:24 AM by Zin-Zang
 #22

if you start to define some nodes as a secondary underclass, you're only playing into the hands of those who seek to create tensions and divisions in the community.  


Prune / Lite / non-segwit Nodes are All INFERIOR compared to a True Full Node capabilities in maintaining the btc/segwit network.
That is not a argument to create tension in your false btc religion beliefs , that is an undeniable Fact.

Only True Full Nodes can keep and maintain the btc network,
all of the others are there for people unable or unwilling to maintain the expense of a full node
so they take a shortcut that in no way helps the network only their personal needs.
And their is nothing wrong with that. That is their personal choice.

The only thing that is Wrong is the Lie perpetrated by you and others , that those INFERIOR Nodes are Full Nodes ,
when by the very fact that none of the inferior nodes (pruned/lite/non-segwit) can maintain the btc network alone without losing current capabilities,
should be enough proof for anyone that they are not Full Nodes.



I was Red Tagged because Lauda Blows Theymos to get back on DT
The rest are just lauda's personal butt monkeys=> Hhampuz , Vod, TMAN , achow101
Wind_FURY
Hero Member
*****
Offline Offline

Activity: 1218
Merit: 812


Crypto-Games.net: Multiple coins, multiple games


View Profile
November 14, 2018, 05:12:23 AM
 #23

In such an outcome, which one of the split would the community follow, the Core developers support, and the market value?

but if segwit itself had a bug. then depending on the bug and its impact. it could go as
downgrade, patch, then upgrade
or
patch then upgrade..  


But node operators can always downgrade their nodes to the version before Segwit, while the software after Segwit is being patched, right? Wouldn't that be an argument supporting that "Segwit as a soft fork" is better?

We are off-topic. This should be discussed in a new thread. Haha.


▄▄▄████████▄▄▄
▄██████████████████▄
▄██████████████████████▄
██████████████████████████
████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
████████████████████████████
██████████████████████████
▀██████████████████████▀
▀██████████████████▀
▀▀▀████████▀▀▀
   ███████
██████████
██████████
██████████
██████████
██████████
██████████
██████████
██████████
██████████
██████████
██████████
███████
BTC  ◉PLAY  ◉XMR  ◉DOGE  ◉BCH  ◉STRAT  ◉ETH  ◉GAS  ◉LTC  ◉DASH  ◉PPC
     ▄▄██████████████▄▄
  ▄██████████████████████▄        █████
▄██████████████████████████▄      █████
████ ▄▄▄▄▄ ▄▄▄▄▄▄ ▄▄▄▄▄ ████     ▄██▀
████ █████ ██████ █████ ████    ▄██▀
████ █████ ██████ █████ ████    ██▀
████ █████ ██████ █████ ████    ██
████ ▀▀▀▀▀ ▀▀▀▀▀▀ ▀▀▀▀▀ ████ ▄██████▄
████████████████████████████ ████████
███████▀            ▀███████ ▀██████▀
█████▀                ▀█████
▀██████████████████████████▀
  ▀▀████████████████████▀▀ 
✔️DICE           
✔️BLACKJACK
✔️PLINKO
✔️VIDEO POKER
✔️ROULETTE     
✔️LOTTO
Zin-Zang
Member
**
Offline Offline

Activity: 364
Merit: 11

Killing Lightning Network with a 51% Ignore attack


View Profile
November 14, 2018, 09:12:43 AM
 #24

In such an outcome, which one of the split would the community follow, the Core developers support, and the market value?

but if segwit itself had a bug. then depending on the bug and its impact. it could go as
downgrade, patch, then upgrade
or
patch then upgrade..  


But node operators can always downgrade their nodes to the version before Segwit, while the software after Segwit is being patched, right? Wouldn't that be an argument supporting that "Segwit as a soft fork" is better?

We are off-topic. This should be discussed in a new thread. Haha.

Soft Fork is not better than a Hard fork.

Hard Fork takes only 51% to agree and a code update, and then it is safe to use.

Soft Fork takes near 90% to agree and can be reversed at any time if 51% decide to discard it.

Hard Fork is safer after the code update is complete ,
a Soft Fork is never really safe as the miners can all switch to the legacy nodes anytime.
Groestlcoin was the only coin to actually hard fork and activate segwit.

*Segwit only activated because the miners preferring larger onchain blocks moved to the bch network , allowing segwit to then reach the needed % to activate.
If the bch miners had stay on btc, they could have blocked segwit permanently. *

If any code problems occur on any network, it can hard fork one day, release a downgrade hard fork the next , and a week later hard fork to a permanent fix.
Hard Forks don't require months to years of begging the communities to switch, they execute on the program date and people join them or they don't.
Hard Fork can be fast and decisive , Soft Forks are slow and indecisive , because you can still change your mind later.

Right after the hard fork it is safe, with a soft fork you are never really safe.

I was Red Tagged because Lauda Blows Theymos to get back on DT
The rest are just lauda's personal butt monkeys=> Hhampuz , Vod, TMAN , achow101
franky1
Legendary
*
Online Online

Activity: 2520
Merit: 1464



View Profile
November 14, 2018, 03:06:45 PM
 #25

In such an outcome, which one of the split would the community follow, the Core developers support, and the market value?

but if segwit itself had a bug. then depending on the bug and its impact. it could go as
downgrade, patch, then upgrade
or
patch then upgrade..  


But node operators can always downgrade their nodes to the version before Segwit, while the software after Segwit is being patched, right? Wouldn't that be an argument supporting that "Segwit as a soft fork" is better?

We are off-topic. This should be discussed in a new thread. Haha.

if segwit itself was broke then there could be a case where all unspent segwit utxo's need to be removed. thus literally orphaning off 15 months of blockchain data AND reverting nodes to version 0.12 for instance
it could be that it just needs to revert to version0.12
it could be that just a quick patch and release of new 0.14.b -0.17.b
again it could cause many issues or many different scenarios, requiring many different responses.
soft or hard could be a blessing or a curse.
but
just letting in any random change "inflight" puts the network more at risk of bugs occuring
just having one source of full node code, does not defend against trojan code. and puts the network at more risk of bugs occuring

its not just a case of diversity of levels of validity levels of upgrade. its also about what code language diversity there is, what database store of blocks. and many other things.

what a few people foolishly believe is that the entire chain should be secured by one codebase. and if there was a bug they think that its better that the entire chain should fail(facepalm) rather than a bunch of nodes from brand A continue while another brand is stalled..

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
Zin-Zang
Member
**
Offline Offline

Activity: 364
Merit: 11

Killing Lightning Network with a 51% Ignore attack


View Profile
November 14, 2018, 06:07:58 PM
 #26

what a few people foolishly believe is that the entire chain should be secured by one codebase. and if there was a bug they think that its better that the entire chain should fail(facepalm) rather than a bunch of nodes from brand A continue while another brand is stalled..

FYI:
Bitcoin last big snafu , was caused by the fact some people upgraded and some did not.
https://bitcoinmagazine.com/articles/bitcoin-network-shaken-by-blockchain-fork-1363144448/

While in theory I agree that multiple code bases should add diversity and increased protection like in a biological system.
Where Diversity is a protection from biological attacks.

The Problem arrives in the fact, that unlike a biological system the ones that fail die, and the strong/adaptable continue without them.

Bitcoin has proven that the miners will decide themselves which fork they want to allow , and choose based on their colluded ideology ,
not allowing a true evolution of the strong or most adaptable to survive.
Since that is the case , there is no real point to multiple code bases if and I repeat if the coin's specs are essentially identical.

Clarifications, I mainly speak of a single chain,
if one were talking about multiple coins/chains, it makes perfect sense each have a different code base,
just not different code bases for a single chain as nothing is really gained except increased chances for disruptions between the two,
requiring one be picked over the other in event of disagreement.


I was Red Tagged because Lauda Blows Theymos to get back on DT
The rest are just lauda's personal butt monkeys=> Hhampuz , Vod, TMAN , achow101
Wind_FURY
Hero Member
*****
Offline Offline

Activity: 1218
Merit: 812


Crypto-Games.net: Multiple coins, multiple games


View Profile
November 15, 2018, 05:11:50 AM
 #27

In such an outcome, which one of the split would the community follow, the Core developers support, and the market value?

but if segwit itself had a bug. then depending on the bug and its impact. it could go as
downgrade, patch, then upgrade
or
patch then upgrade..  


But node operators can always downgrade their nodes to the version before Segwit, while the software after Segwit is being patched, right? Wouldn't that be an argument supporting that "Segwit as a soft fork" is better?

We are off-topic. This should be discussed in a new thread. Haha.

Soft Fork is not better than a Hard fork.

Hard Fork takes only 51% to agree and a code update, and then it is safe to use.


Wouldn't that be a contentious hard fork?

In such an outcome, which one of the split would the community follow, the Core developers support, and the market value?

but if segwit itself had a bug. then depending on the bug and its impact. it could go as
downgrade, patch, then upgrade
or
patch then upgrade..  


But node operators can always downgrade their nodes to the version before Segwit, while the software after Segwit is being patched, right? Wouldn't that be an argument supporting that "Segwit as a soft fork" is better?

We are off-topic. This should be discussed in a new thread. Haha.

if segwit itself was broke then there could be a case where all unspent segwit utxo's need to be removed. thus literally orphaning off 15 months of blockchain data AND reverting nodes to version 0.12 for instance
it could be that it just needs to revert to version0.12
it could be that just a quick patch and release of new 0.14.b -0.17.b
again it could cause many issues or many different scenarios, requiring many different responses.
soft or hard could be a blessing or a curse.
but
just letting in any random change "inflight" puts the network more at risk of bugs occuring
just having one source of full node code, does not defend against trojan code. and puts the network at more risk of bugs occuring

its not just a case of diversity of levels of validity levels of upgrade. its also about what code language diversity there is, what database store of blocks. and many other things.

I would only agree  to your debate, if the Segwit "bug" was VERY serious that it would be the "death of Bitcoin", and that a hard fork to fix the issue would gain consensus.

But let us avoid the conversation in going to the gaslighting zone. Haha.

Quote
what a few people foolishly believe is that the entire chain should be secured by one codebase. and if there was a bug they think that its better that the entire chain should fail(facepalm) rather than a bunch of nodes from brand A continue while another brand is stalled..

Yes, you can run Bitcoin Knots by your favorite developer. Cool


▄▄▄████████▄▄▄
▄██████████████████▄
▄██████████████████████▄
██████████████████████████
████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
████████████████████████████
██████████████████████████
▀██████████████████████▀
▀██████████████████▀
▀▀▀████████▀▀▀
   ███████
██████████
██████████
██████████
██████████
██████████
██████████
██████████
██████████
██████████
██████████
██████████
███████
BTC  ◉PLAY  ◉XMR  ◉DOGE  ◉BCH  ◉STRAT  ◉ETH  ◉GAS  ◉LTC  ◉DASH  ◉PPC
     ▄▄██████████████▄▄
  ▄██████████████████████▄        █████
▄██████████████████████████▄      █████
████ ▄▄▄▄▄ ▄▄▄▄▄▄ ▄▄▄▄▄ ████     ▄██▀
████ █████ ██████ █████ ████    ▄██▀
████ █████ ██████ █████ ████    ██▀
████ █████ ██████ █████ ████    ██
████ ▀▀▀▀▀ ▀▀▀▀▀▀ ▀▀▀▀▀ ████ ▄██████▄
████████████████████████████ ████████
███████▀            ▀███████ ▀██████▀
█████▀                ▀█████
▀██████████████████████████▀
  ▀▀████████████████████▀▀ 
✔️DICE           
✔️BLACKJACK
✔️PLINKO
✔️VIDEO POKER
✔️ROULETTE     
✔️LOTTO
Zin-Zang
Member
**
Offline Offline

Activity: 364
Merit: 11

Killing Lightning Network with a 51% Ignore attack


View Profile
November 15, 2018, 05:28:24 AM
 #28

In such an outcome, which one of the split would the community follow, the Core developers support, and the market value?

but if segwit itself had a bug. then depending on the bug and its impact. it could go as
downgrade, patch, then upgrade
or
patch then upgrade..  


But node operators can always downgrade their nodes to the version before Segwit, while the software after Segwit is being patched, right? Wouldn't that be an argument supporting that "Segwit as a soft fork" is better?

We are off-topic. This should be discussed in a new thread. Haha.

Soft Fork is not better than a Hard fork.

Hard Fork takes only 51% to agree and a code update, and then it is safe to use.


Wouldn't that be a contentious hard fork?


Not necessary, only 51% minimum needs to agree ,
however the agreement % could be closer to 100% , just depends on the community involved and how divided they are by the changes.

Hard Fork is just safer as the code guarantees it and the 51% ensures it is the stronger chain.

Soft Fork does not guarantee the code updates won't be reversed at a later date.
The introduction of segwit should have been a hard fork to make certain it could not be deactivated by the miners at a later date, which is still a possibility.

Miners are starting to go to war for the dwindling profits, so their concern for coins health is declining by the day.
Their are no guarantees of what they will or won't do now.
ie: https://sharkpool.cash/
 


I was Red Tagged because Lauda Blows Theymos to get back on DT
The rest are just lauda's personal butt monkeys=> Hhampuz , Vod, TMAN , achow101
Wind_FURY
Hero Member
*****
Offline Offline

Activity: 1218
Merit: 812


Crypto-Games.net: Multiple coins, multiple games


View Profile
November 15, 2018, 05:49:01 AM
 #29


Wouldn't that be a contentious hard fork?


Not necessary, only 51% minimum needs to agree ,

More specifically, in Bitcoin, would the "51% minimum" not result in a contentious hard fork causing a chain-split?

Quote
however the agreement % could be closer to 100% , just depends on the community involved and how divided they are by the changes.

 Cool

Quote
Hard Fork is just safer as the code guarantees it and the 51% ensures it is the stronger chain.

More specifically, in Bitcoin, if it had consensus, and if the hard fork is not merely because of the whims of the developers, or the miners, or the community, then I would agree.

Quote
Soft Fork does not guarantee the code updates won't be reversed at a later date.
The introduction of segwit should have been a hard fork to make certain it could not be deactivated by the miners at a later date, which is still a possibility.

More specifically, in Bitcoin, soft forks assures inclusivity, and that no nodes are dropped. It was what made Segwit as a soft fork ingenious in my opinion. A block size increase, with backwards compatibility, and inclusivity.

Quote
Miners are starting to go to war for the dwindling profits, so their concern for coins health is declining by the day.
Their are no guarantees of what they will or won't do now.
ie: https://sharkpool.cash/
 

What would be your proposal in connection to "hard forks are better"? Cool


▄▄▄████████▄▄▄
▄██████████████████▄
▄██████████████████████▄
██████████████████████████
████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
████████████████████████████
██████████████████████████
▀██████████████████████▀
▀██████████████████▀
▀▀▀████████▀▀▀
   ███████
██████████
██████████
██████████
██████████
██████████
██████████
██████████
██████████
██████████
██████████
██████████
███████
BTC  ◉PLAY  ◉XMR  ◉DOGE  ◉BCH  ◉STRAT  ◉ETH  ◉GAS  ◉LTC  ◉DASH  ◉PPC
     ▄▄██████████████▄▄
  ▄██████████████████████▄        █████
▄██████████████████████████▄      █████
████ ▄▄▄▄▄ ▄▄▄▄▄▄ ▄▄▄▄▄ ████     ▄██▀
████ █████ ██████ █████ ████    ▄██▀
████ █████ ██████ █████ ████    ██▀
████ █████ ██████ █████ ████    ██
████ ▀▀▀▀▀ ▀▀▀▀▀▀ ▀▀▀▀▀ ████ ▄██████▄
████████████████████████████ ████████
███████▀            ▀███████ ▀██████▀
█████▀                ▀█████
▀██████████████████████████▀
  ▀▀████████████████████▀▀ 
✔️DICE           
✔️BLACKJACK
✔️PLINKO
✔️VIDEO POKER
✔️ROULETTE     
✔️LOTTO
DooMAD
Legendary
*
Offline Offline

Activity: 2100
Merit: 1343


Leave no FUD unchallenged


View Profile WWW
November 15, 2018, 02:11:00 PM
 #30

It's worth pointing out that hard forks are only "safe" in the event of the minority fork implementing replay protection.  Otherwise things can get very messy indeed.

franky1
Legendary
*
Online Online

Activity: 2520
Merit: 1464



View Profile
November 15, 2018, 10:06:11 PM
Last edit: November 15, 2018, 10:48:27 PM by franky1
 #31

there is no real point to multiple code bases if and I repeat if the coin's specs are essentially identical.

actually there is
EG, if a road has a 30 mile an hour limit. should we all drive an identical car that has a 30mph limiter in it

or have different types of cars. that way if one brand of car ever had a recall due to bad brakes. it doesnt affct the entire transportation industry, and only affects one brand of car.

imagine if the only ever sugar free soda was pepsi max
     pepsi max de-carbonised,un-food colored, unflavoured is 'compatible' (pepsi branded water is allowed)
the only pants people could wear was blue Levi denim
     Levi denim high knee cut shorts with less pockets is 'compatible'

again staying on one network but being told there should only be one brand of codebase that is a "full node" that does all the tasks.. thats called tyranny.

the reference client should only be a reference to current ruleset code. which people can REFER to when making their own clients.
then the diverse clients all release bips and the community vet them and contribute/compromise until a single unified progressive upgrade can be majority agreed.
EG2015
65%8mb legacy
35% 1mb legacy
high percentile contributed and compromised to 2mb.. which should have been a release all diverse codebases done.
but foolishly a few leaders of the 35% crew backed out, said they wont code it. pretended they were not contributors and couldnt code it.. and instead 2 years later. they whammied in their own alternative while ignoring the 65% interest in more than 1mb legacy

which is where we have the wishy washy code thats not even 4mb true full utilisable limit. lots of multiple X and Y by 4 to fake some other numbers. and we still dont have double transaction counts with fee's averaging only a couple pennies

all because one group didnt want diverse codebases and community involvement. thy just wanted "compatible" sheep that had the wool trimmed off and covering their eyes
(dang it.. i tried not to rant)

....
EG imagine if in 2013 the majority wasnt core 0.7(berkely(locks)) with a few 0.8(leveldb(no locks))
but instead loads of other brands with no lock database

the consensus would have been that 0.7 is stalled so just go straight to using 0.8 and continue growing the chain without orphan
and just call 0.7 dead much sooner and without having to orphan off the a couple dozen blocks..

EG imagine 2018. if someone did do a DDos and everyone was running 0.14+.... do you rally want the entire network of nodes to keep going offline
or would you prefer to have diverse nods that continue while dvs patch something on one brand

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
franky1
Legendary
*
Online Online

Activity: 2520
Merit: 1464



View Profile
November 15, 2018, 10:36:26 PM
Last edit: November 15, 2018, 11:02:24 PM by franky1
Merited by vapourminer (1)
 #32

More specifically, in Bitcoin, would the "51% minimum" not result in a contentious hard fork causing a chain-split?

nope thats project fear,
same as what a certain someone just done by thinking things all end up as a chain split(altcoin creation). and add more fear by saying its up to the minority to alter their altcoin code to stay away(replay protection).

truth be told is 51% is contentious. but its not always a chain split.
it can be where the minority just stall out and hang at a certain block height (2013 proved that an altcoin was not formed.. just 1 chain growing and other nodes stalled)
emphasis no 2 parallel chains growing..
in the case of something being active at low consensus

.. but going back to lets say a low threshold of 51% agreement. that criteria doesnt mean activate. it can mean you have X weeks to upgrade or have your node stalled out when it activates later.
it could also be. now it reached 51% the community has interest so let the diverse nodes code a version that includes it and see if we can get to 75%, then 95%. and only then activate so only 5% is stalled out. (again no parallel chains growing. just one chain growing and 5% nodes are stuck)

i do find it funny how project fear has no clue about a good consensus mechanism and is on a full tirade to only promote one 'brand or doom'

and yes. the majority that have accepted a upgrade can themselves implement a replay protection on the upgrade. without demanding the minority to have to re-code anything.
i too found it hilarious that a certain team refused to add replay protections in an upgrade they done. but wanted those that didnt change code who didnt want the upgrade. were told to change their code..

but thats just the comedy to be expected

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
Wind_FURY
Hero Member
*****
Offline Offline

Activity: 1218
Merit: 812


Crypto-Games.net: Multiple coins, multiple games


View Profile
November 16, 2018, 05:37:36 AM
 #33

More specifically, in Bitcoin, would the "51% minimum" not result in a contentious hard fork causing a chain-split?

nope thats project fear,
same as what a certain someone just done by thinking things all end up as a chain split(altcoin creation). and add more fear by saying its up to the minority to alter their altcoin code to stay away(replay protection).

Who is that "certain someone"?

But specifically in Bitcoin, if the hard fork proposed does not gain consensus, which would always happen because of politics, would you say that it would not end up as a chain-split? Cool

Quote
truth be told is 51% is contentious. but its not always a chain split.
it can be where the minority just stall out and hang at a certain block height (2013 proved that an altcoin was not formed.. just 1 chain growing and other nodes stalled)
emphasis no 2 parallel chains growing..
in the case of something being active at low consensus

Vitalik Buterin was also confident that the DAO bail out would not split Ethereum. It did.

Quote
.. but going back to lets say a low threshold of 51% agreement. that criteria doesnt mean activate. it can mean you have X weeks to upgrade or have your node stalled out when it activates later.
it could also be. now it reached 51% the community has interest so let the diverse nodes code a version that includes it and see if we can get to 75%, then 95%
. and only then activate so only 5% is stalled out. (again no parallel chains growing. just one chain growing and 5% nodes are stuck)

That is weak reason to justify it. There has to be consensus.

Quote
i do find it funny how project fear has no clue about a good consensus mechanism and is on a full tirade to only promote one 'brand or doom'

and yes. the majority that have accepted a upgrade can themselves implement a replay protection on the upgrade. without demanding the minority to have to re-code anything.
i too found it hilarious that a certain team refused to add replay protections in an upgrade they done. but wanted those that didnt change code who didnt want the upgrade. were told to change their code..

but thats just the comedy to be expected

What are you talking about?


▄▄▄████████▄▄▄
▄██████████████████▄
▄██████████████████████▄
██████████████████████████
████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
████████████████████████████
██████████████████████████
▀██████████████████████▀
▀██████████████████▀
▀▀▀████████▀▀▀
   ███████
██████████
██████████
██████████
██████████
██████████
██████████
██████████
██████████
██████████
██████████
██████████
███████
BTC  ◉PLAY  ◉XMR  ◉DOGE  ◉BCH  ◉STRAT  ◉ETH  ◉GAS  ◉LTC  ◉DASH  ◉PPC
     ▄▄██████████████▄▄
  ▄██████████████████████▄        █████
▄██████████████████████████▄      █████
████ ▄▄▄▄▄ ▄▄▄▄▄▄ ▄▄▄▄▄ ████     ▄██▀
████ █████ ██████ █████ ████    ▄██▀
████ █████ ██████ █████ ████    ██▀
████ █████ ██████ █████ ████    ██
████ ▀▀▀▀▀ ▀▀▀▀▀▀ ▀▀▀▀▀ ████ ▄██████▄
████████████████████████████ ████████
███████▀            ▀███████ ▀██████▀
█████▀                ▀█████
▀██████████████████████████▀
  ▀▀████████████████████▀▀ 
✔️DICE           
✔️BLACKJACK
✔️PLINKO
✔️VIDEO POKER
✔️ROULETTE     
✔️LOTTO
DooMAD
Legendary
*
Offline Offline

Activity: 2100
Merit: 1343


Leave no FUD unchallenged


View Profile WWW
November 16, 2018, 02:40:44 PM
 #34

More specifically, in Bitcoin, would the "51% minimum" not result in a contentious hard fork causing a chain-split?

nope thats project fear,
same as what a certain someone just done by thinking things all end up as a chain split(altcoin creation). and add more fear by saying its up to the minority to alter their altcoin code to stay away(replay protection).

Who is that "certain someone"?

Pretty sure he's referring to me, since I mentioned the replay protection bit.  Call me crazy, but I don't think it's realistic to expect BTC developers to check to see if we need to take action each and every time some other coin forks away.  We've had enough of them for it to be a hefty workload if devs on this chain had to worry about Gold/Private/Diamond/Zero/Atom/Smart/etc.  It's not up to devs on this chain to keep an eye on what all the altcoins are doing. 

But then, that's pretty much the attitude I'd expect from Franky1, since developers are apparently his slaves to order about.   Roll Eyes

And here he is yet again saying that devs working on the reference client shouldn't have the freedom to propose and develop BIPs and other changes, as if that was somehow his call to make.  But even though he's keen on taking peoples' freedom away, he's definitely not an authoritarian.  Nope.  Not at all.   Roll Eyes

I mean, If we're going to talk about "project fear", let's start with the demented fruitcake who is convinced that we're on a tyrannical, dev-controlled chain where users have no choice.  I'm pretty sure that sounds like FUD to anyone who isn't wearing a tinfoil hat.

Zin-Zang
Member
**
Offline Offline

Activity: 364
Merit: 11

Killing Lightning Network with a 51% Ignore attack


View Profile
November 16, 2018, 06:39:08 PM
Last edit: November 16, 2018, 07:18:09 PM by Zin-Zang
 #35

It's worth pointing out that hard forks are only "safe" in the event of the minority fork implementing replay protection.  Otherwise things can get very messy indeed.

In a Normal Hard Fork the minority chain has no value and no one supports it.
It just dies off as it should.

But adding replay protection is totally unnecessary unless your users are idiots.

Replay attack is of no danger unless they are playing both sides and sending coins on both chains,
basically playing a double agent trying to profit from both instead of ignoring one completely.
Greed does have consequences.

People that ignore the weaker chain, have no concern because they could care less what happens on the weaker chain.
Since they don't make transactions on the weaker chain , they have no fear of a replay attack on the chain they do support.


However people playing both sides of the coin chains,
all they had to do is hold until the forks stabilized and then create new wallets with different addresses in each separate fork,
and transfer their coins at ~ the same time to the new addresses to avoid any danger of a replay attack.


I was Red Tagged because Lauda Blows Theymos to get back on DT
The rest are just lauda's personal butt monkeys=> Hhampuz , Vod, TMAN , achow101
Wind_FURY
Hero Member
*****
Offline Offline

Activity: 1218
Merit: 812


Crypto-Games.net: Multiple coins, multiple games


View Profile
November 18, 2018, 08:07:10 AM
 #36

It's worth pointing out that hard forks are only "safe" in the event of the minority fork implementing replay protection.  Otherwise things can get very messy indeed.

In a Normal Hard Fork the minority chain has no value and no one supports it.
It just dies off as it should.

But adding replay protection is totally unnecessary unless your users are idiots.


To put everything in context, did DooMAD talk about "normal" hard forks, or contentious hard forks? I am asking for the sake of the lazy readers, like "sometimes" me. Hahaha.


▄▄▄████████▄▄▄
▄██████████████████▄
▄██████████████████████▄
██████████████████████████
████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
████████████████████████████
██████████████████████████
▀██████████████████████▀
▀██████████████████▀
▀▀▀████████▀▀▀
   ███████
██████████
██████████
██████████
██████████
██████████
██████████
██████████
██████████
██████████
██████████
██████████
███████
BTC  ◉PLAY  ◉XMR  ◉DOGE  ◉BCH  ◉STRAT  ◉ETH  ◉GAS  ◉LTC  ◉DASH  ◉PPC
     ▄▄██████████████▄▄
  ▄██████████████████████▄        █████
▄██████████████████████████▄      █████
████ ▄▄▄▄▄ ▄▄▄▄▄▄ ▄▄▄▄▄ ████     ▄██▀
████ █████ ██████ █████ ████    ▄██▀
████ █████ ██████ █████ ████    ██▀
████ █████ ██████ █████ ████    ██
████ ▀▀▀▀▀ ▀▀▀▀▀▀ ▀▀▀▀▀ ████ ▄██████▄
████████████████████████████ ████████
███████▀            ▀███████ ▀██████▀
█████▀                ▀█████
▀██████████████████████████▀
  ▀▀████████████████████▀▀ 
✔️DICE           
✔️BLACKJACK
✔️PLINKO
✔️VIDEO POKER
✔️ROULETTE     
✔️LOTTO
franky1
Legendary
*
Online Online

Activity: 2520
Merit: 1464



View Profile
November 18, 2018, 01:15:09 PM
Last edit: November 18, 2018, 01:32:22 PM by franky1
 #37

But then, that's pretty much the attitude I'd expect from Franky1, since developers are apparently his slaves to order about.  

And here he is yet again saying that devs working on the reference client shouldn't have the freedom to propose and develop BIPs and other changes, as if that was somehow his call to make.  But even though he's keen on taking peoples' freedom away, he's definitely not an authoritarian.  Nope.  Not at all.   Roll Eyes

I mean, If we're going to talk about "project fear", let's start with the demented fruitcake who is convinced that we're on a tyrannical, dev-controlled chain where users have no choice.  I'm pretty sure that sounds like FUD to anyone who isn't wearing a tinfoil hat.
doomad yet again avoiding the topic to poke the bear into a personal social drama...
ill bite.

my mind set is MULTIPLE teams able to operate without the REKT campaigns of core or nothing

my mindset is where if core want to be REFERENCE. then thats meant as having code for CURRENT ruleset. to allow people to have a stable source so others can make their own clients....
........not to be the rule changer source which the code changes daily
........not to insult teams who do take core code
........not to say its a breach of copyright to use core code
........not to use core code, alter it and put in features core doesnt like and get rekt by core people

but hey doomad doesnt understand the technicals which is why he just loves the personal attacks. he has had months to learn and do research, yet has insultingly been very vocal that he wishes to refuse to do research.

im guessing he will play the victim of personal attack, but he is the one poking the bear. so cant cry when the bear bites back

anyway, if he thinks im authoritarian
show me some code that i created that mandated or demanded core do something or get chucked off the network.
then show some code where cores bips mandate and demand non core clients do something or get thrown off the network...

guess which code only exists... which proves who is the authoritarian

again my mindset(OPINION NOT CODE, thus NO TYRANNY from me) is multiple teams to be allowed to run on the network without cores code blocking and knocking them off the network due to it not wanting to follow cores roadmap

..
the funny part is doomad cannot separate the idea that core should not BE bitcoin. but instead core should only participate in bitcoin.
but doomad will pretend to flip flop in and out of that.. one day he says core do have control without needing community permission. next he will say the community would give permission for core to activate.. he just cant make up is mind.

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
franky1
Legendary
*
Online Online

Activity: 2520
Merit: 1464



View Profile
November 18, 2018, 01:36:22 PM
 #38

anyway, back to the topic

to those that do want to learn about full nodes. research
NODE_NETWORK, NODE_BLOOM, NODE_WITNESS, NODE_NETWORK_LIMITED (1037)

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
DooMAD
Legendary
*
Offline Offline

Activity: 2100
Merit: 1343


Leave no FUD unchallenged


View Profile WWW
November 18, 2018, 03:48:25 PM
 #39

my mind set is MULTIPLE teams able to operate without the REKT campaigns of core or nothing

Multiple teams do operate.  You can run BU, XT, Classic, TRB, or BTC1.  All of these clients are running on the BTC network right now and are 100% compatible with the current consensus.  None of them support Core's roadmap, but they're all allowed to run on the network.  If enough users decided to run them, consensus would change.  I don't see any problem here, other than the one you're attempting (and failing) to engineer from nothing.


my mindset is where if core want to be REFERENCE. then thats meant as having code for CURRENT ruleset. to allow people to have a stable source so others can make their own clients....
........not to be the rule changer source which the code changes daily

Your (broken) mindset doesn't make the rules.  There is no rule that says a developer working on Core code can't propose a BIP and there never has been.  There is no rule that says changes can't be made via softfork and there never has been.  There is no rule that says the reference client can't introduce new features and there never has been.  I don't think it's unreasonable to describe someone who would try to introduce such rules as an authoritarian, because such rules would clearly undermine freedom and weaken Bitcoin's permissionless nature.  

Also, I know you haven't got code I can point to that would demonstrate your desire to enforce your totalitarian fascist wishes on everyone.  There's a very good reason for that.  Primarily, it's due to the fact that it's not possible to code rules to enforce your demented wishes.  You're asking for the impossible.  There isn't any code on Earth that can force developers to behave in the way you describe above.  Bitcoin will never function like that because you can't control people.  But if it could function like that, we're all abundantly clear on the part where that's how you'd prefer it to be.  

Tell me how you'd stop any developer from coding what they wanted.  Tell me how you can stop Core proposing new features.  Tell me how you'd prevent softforks.  
You don't have answers to any of that.  Because it's not possible.  Cry about it all you want.  It won't change anything.  The above idea of yours is totally unworkable.

And to top it off, you already have a "stable source so others can make their own clients".  That source is called every single previous version of Bitcoin that has ever been released.  You can pick any one of those previous versions and build what you want from it.  Once again proving that you don't even understand what it is you've got and how good it is.  You have all the freedom in the world and yet all you can do is bitch about what other people are doing with their freedom.  


im guessing he will play the victim of personal attack, but he is the one poking the bear. so cant cry when the bear bites back

I'd have to care what you think to be concerned about personal attacks you make against me.  You're the one whining about insults.  Say whatever you like about me.  


the funny part is doomad cannot separate the idea that core should not BE bitcoin. but instead core should only participate in bitcoin.
but doomad will pretend to flip flop in and out of that.. one day he says core do have control without needing community permission. next he will say the community would give permission for core to activate.. he just cant make up is mind.

I don't know how to explain it to you any other way.  I'm sorry if this is too difficult a concept for you to wrap your feeble mind around:

Developers of any codebase can code what they want.  Users are free to run what they want.  If users don't run it, nothing activates.  This applies to all dev teams equally.

As I've explained to you before, I've used the same argument to defend alternative clients.  This is why it's such an effective argument.  It's universal.  In 2016, before the forks started occurring, when Carlton used to argue that alternative clients shouldn't be allowed to "steal" Core's code, I used this exact same argument.  Remember this thread?  I categorically said that anyone is free to code their own proposals if other developers disagree.  Oddly enough, you didn't seem to have any problems at all with me saying that back then, when it suited your argument, so I don't see why you're so opposed to it now.  Maybe it has something to do with the fact that you're now basically using Carlton's arguments that a certain dev team should be restricted in what they can or can't do.  

But neither of you can overcome the argument that all devs are free to code what they want.  Neither of you can change it.  It's a fact.  You can't fight the cold hard reality of how things actually are.  All devs are free to code what they want.  Including the devs you (and Carlton) don't approve of.  Literally the only difference between you and Carlton is that you both hate different groups of developers.  I'm just here being completely neutral and transparent, like BTC itself.  

What you think Core "should" do doesn't matter.  What matters is people are free to code and run anything they like because the system is 100% permissionless.  As such, Bitcoin is working perfectly.  


Wind_FURY
Hero Member
*****
Offline Offline

Activity: 1218
Merit: 812


Crypto-Games.net: Multiple coins, multiple games


View Profile
November 19, 2018, 05:19:46 AM
 #40

But then, that's pretty much the attitude I'd expect from Franky1, since developers are apparently his slaves to order about.  

And here he is yet again saying that devs working on the reference client shouldn't have the freedom to propose and develop BIPs and other changes, as if that was somehow his call to make.  But even though he's keen on taking peoples' freedom away, he's definitely not an authoritarian.  Nope.  Not at all.   Roll Eyes

I mean, If we're going to talk about "project fear", let's start with the demented fruitcake who is convinced that we're on a tyrannical, dev-controlled chain where users have no choice.  I'm pretty sure that sounds like FUD to anyone who isn't wearing a tinfoil hat.

again my mindset(OPINION NOT CODE, thus NO TYRANNY from me) is multiple teams to be allowed to run on the network without cores code blocking and knocking them off the network due to it not wanting to follow cores roadmap

But is it really the Core developers' fault that the users want to run their software and validate their rules?

Quote
..
the funny part is doomad cannot separate the idea that core should not BE bitcoin. but instead core should only participate in bitcoin.
but doomad will pretend to flip flop in and out of that.. one day he says core do have control without needing community permission. next he will say the community would give permission for core to activate.. he just cant make up is mind.

I believe your debate is not against Core but against the community for its loyal following of Core. Maybe a blockchain networks' decision of what should be or should not be is not made of code but of social consensus.


▄▄▄████████▄▄▄
▄██████████████████▄
▄██████████████████████▄
██████████████████████████
████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
████████████████████████████
██████████████████████████
▀██████████████████████▀
▀██████████████████▀
▀▀▀████████▀▀▀
   ███████
██████████
██████████
██████████
██████████
██████████
██████████
██████████
██████████
██████████
██████████
██████████
███████
BTC  ◉PLAY  ◉XMR  ◉DOGE  ◉BCH  ◉STRAT  ◉ETH  ◉GAS  ◉LTC  ◉DASH  ◉PPC
     ▄▄██████████████▄▄
  ▄██████████████████████▄        █████
▄██████████████████████████▄      █████
████ ▄▄▄▄▄ ▄▄▄▄▄▄ ▄▄▄▄▄ ████     ▄██▀
████ █████ ██████ █████ ████    ▄██▀
████ █████ ██████ █████ ████    ██▀
████ █████ ██████ █████ ████    ██
████ ▀▀▀▀▀ ▀▀▀▀▀▀ ▀▀▀▀▀ ████ ▄██████▄
████████████████████████████ ████████
███████▀            ▀███████ ▀██████▀
█████▀                ▀█████
▀██████████████████████████▀
  ▀▀████████████████████▀▀ 
✔️DICE           
✔️BLACKJACK
✔️PLINKO
✔️VIDEO POKER
✔️ROULETTE     
✔️LOTTO
Pages: « 1 [2] 3 »  All
  Print  
 
Jump to:  

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!