How Many Full Nodes Bitcoin Online ?

[franky1]

anyway this topic has got so derailed.

anyway. if nodes want to be fullnodes and validate all transactions, keep all transactions and when a block arrives confirm block and keep block.
then having configurable features that then dont validate, dont keep and dont send full data is not a full node. especially if the configurations are for silly things that can be solved in a multitude of other ways

i know blah blah blah rebuttal of define full node define less than full node define litenode define spv

but in short if you going to
prune the block archive,
reduce mempool holding
cause issues with block propagation latency
drop transactions
not relay certain tx
drop and regrab

your not helping the network

if core want to be the "full node" provider. they should concentrate on being a full node and concentrate on fixing network wide flaws. let other teams play around with providing less than full nodes user configurable flimsy stuff..

or more appropriate. core fans shouldnt do REKT campaigns on other teams that also wanna be full node providers

[1713852799]

1713852799

[bitserve]

AFAIK the main problem of malleability was that exchanges could get fooled by a malleated tx such that their software couldn't recognise the malleated (broadcasted by the attacker) tx had indeed suceeded and the original one didn't, so they would end replaying it making a double (or multiple by rinse and repeat) spend themselves. <- REAL spends, don't confuse with the "double spend" attack.

It seems to me THAT problem has a solution now as exchanges can use the "specific format" that makes malleability impossible.

Ok, main problem solved.

Now go to the next one... You are saying that if I am the receiver I don't control the sending tx, which is true. So the "attacker" can choose to send me a tx which is susceptible of malleability, ok. And now what? The "attacker" is going to send me multiple malleated tx's? What can I say... thanks?

I think I am not getting it... can you use another example but instead of guns use a real life example on how that would be detrimental to me as a receiver of a Bitcoin tx?

yea your not getting it...you think the main problem is solved..
EG
if i sent you a tx of
1franky(0.1) -> bc1qexchange(0.1)
that tx is not a segwit tx. i can still malleate my signature to change the txid even when you want the funds to arrive at a segwit bc1q address

so an exchange will still get transactions that can be malleated..

all an exchange has control over is. if an exchange CHOOSES to only use segwit. then the exchange itself cannot malleate..
it doesnt mean an exchange cant be victim to malleation

segwits false promise was to solve malleability for the bitcoin network.. it hasnt
segwits real purpose was to add a gateway tx format to a different network which the different network would offer different things

Of course you can malleate your own legacy transactions, so what?

I only care if I have received the BTC in the intended deposit address and how many confirmations it has. You can malleate and rebroadcast your tx as many times as you want (which is pointless because as soon as the first one wins the race all the rest will get rejected), I don't care what the txid is as I am not checking for it.

You have failed to provide an example about how that known behaviour would become a PROBLEM/attack vector in real life.

Yes, Segwit main purpose was always to facilitate the integration of L2 and to allow more transactions without having to increase the block size just yet. The fact that it does offer a viable solution to the transaction malleability problem was more of a side effect / secondary goal.

P.S.: Also, transaction malleability was a problem due to poor coding and lack of redundancy/cross checks on whatever exchange got affected (if any). A simple reconciliation of the balance of input addresses BEFORE doing any retry would have easily detected and stopped the exploit.

[franky1]

Of course you can malleate your own legacy transactions, so what?

You have failed to provide an example about how that known behaviour would become a PROBLEM/attack vector in real life.

you failed to understand the malleability problem
though this is offtopic... and i know im being poked by an obvious fan groupy based on certain terms you use, ill bite
you said:

It seems to me THAT problem has a solution now as exchanges can use the "specific format" that makes malleability impossible.

i replied

if i sent you 1franky(0.1) -> bc1qexchange(0.1)

you said

Of course you can malleate your own legacy transactions, so what?

so even when you as an exchange use a specific format... i can still malleate a tx to you
maybe go do some research.. you know... google

hint, its not about confirmed transactions. never was about confirmed transaction.. never has been about confirmed transactions.
if you want to argue and say there never was a problem then take that up with the devs who obviously thought there was a problem for them to do what they did and promote what they did.

also lightning network is not a layer two feature of bitcoin.
its a completely separate network that allow multiple different coins to get locked up and then people get to play around on this other network.

its not scaling bitcoin network. its diverting people away from using the bitcoin network.
might be worth you doing research beyond the utopian dream promotional material

...
lets get some things straight here.
for people to be on this forum means they have already heard about bitcoin and crypto.. after all they didnt magicly just gt dropped into the forum.

they dont need the wishy washy only positive advertising of utopian dreams and empty promises.. they want to know what is really going on.. both good and bad.

i understand there is a group of people that only want to overpomise and fluffy cloud unicorn stuff with positive chatter.. but thats just not really doing much because to read that stuff here in the forum is advertising to people that already been advertised to.

people want to know whats beyond the fluffy clouds

[gmaxwell]

- Also it seems to me that in any case minisketch has nothing to do about that because the drop of the tx's due to not meeting the min relay criteria is a previous step in the protocol. Minisketch just adds an optional and more efficient (bandwidth wise) way of dealing with a preexistent situation.

You've got it.

The "re-relay" problem that he imagines isn't actually a thing, but even if it were, minisketch would just be an unrelated improvement:  Nodes communicate their minfeerate to peers and don't get offered stuff they'll just drop due to fees. Existing things they do drop (due to being double spends, arriving while they're in the process of changing their fee filter, etc) they remember the txids so they won't fetch them again if a peer offers them, which itself doesn't happen much because txn are only offered when the peer initially accepts them.

allow more transactions without having to increase the block size just yet.

https://blockchair.com/bitcoin/block/544791
Size (bytes)    1,700,065

Last I checked 1700065 was greater than 1000000. Segwit increased the blocksize, but didn't increase the size that lite clients have to deal with or break compatibility.

facilitate the integration of L2

Not really, I mean that might have been why many people on the forum found it exciting,  but separating out witnesses was proposed back in 2012 when no one was really thinking much about L2.   Unintended malleability is just a source of 1001 awful corner cases that are really hard for wallets to handle except by refusing to spend your own unconfirmed outputs, or other similarly terrible and burdensome workarounds. We previously tried fixing these problems via BIP62 but it was just a finger in a failing dam, because the original design was flawed we kept finding more and more avenues and were forced to abandon that approach.  Lightning was proposed before segwit was a thing and at least theoretically lightning can be done without it-- but in practice without the ability to control malleability it is just too awful and dangerous to write any automatic transaction processing software, so after segwit was proposed which completely solved that issue lightning developers decided to wait on its availability.

Also, transaction malleability was a problem due to poor coding and lack of redundancy/cross checks on whatever exchange got affected (if any). A simple reconciliation of the balance of input addresses BEFORE doing any retry would have easily detected and stopped the exploit.

Not quite-- MTGox's claims were indeed just trying to cover up his insolvency cover-up, but even without that easily fixed accountability screwup malleability is a problem because of spending change output.  There were several big attacks that really messed up and took down basically every big fund sender (e.g. bitstamp)-- we kept them under control by getting miners to blacklist various attack patterns, but that kind of workaround can be evaded by sufficiently motivated attackers.  It actually was important to fix the general case for reasons unrelated to mtgox.  Mtgox just seized on and exaggerated an existing problem that had given then a little trouble (and unlikely ~everyone else actually caused them some funds loss, rather than just a jammed wallet) ... but it still was actually an existing problem.  It was strategic for mtgox to lie in this way, had they imagined some totally new fake problem to blame their insolvency on they would have instantly been called out.

I really don't understand why FUDsters have had any success with the "malleability isn't fixed".  The fact that it's possible to intentionally make a malleable transaction even exists as a useful and intentional feature: e.g. the ability to create anyonecanpay transactions where other people provide part of the funds after you sign. The malleability issue was always that it wasn't possible to spend an unconfirmed output (e.g. as your change, wallets have always refused to spend unconfirmed outputs by other people due to the risk of double spending) without those dependant spends (and their ancestors) being maliciously invalidated by someone else.   -- it's not like intentional malleability is avoidable, after all you could also always double spend yourself.

I guess some people are just pathologically uncomfortable with anyone else having any choice at all in their life.  The fact that you could choose to intentionally make a transaction that they allow other people to modify, and then have to deal with the consequences yourself just seems to drive some people wild.  Similarly, the fact there is some buried command-line configuration option that virtually no one sets to increase the minimum feerate your node will accept-- with essentially no consequence for anyone but yourself-- causes the same people to melt down ... the idea that other people can make their own free choices seems to leave some unable to sleep and stuck obsessively posting about it. The fact that their choice harms no one and is fundamentally impossible to prevent is apparently just not relevant to these people.

Unfortunately, other people see the floods of posts and think that there must be some issue.  But no: sadly, some people on the internet are just broken.

It's really frustrating that they'll say anything to sustain their obsessions ... like above "they introduce RBF to actually help malleators malleate" uh no, third part malleability always either lower feerates or keeps it the same, so if RBF mattered at all it would actually make malleability less sucessful by allowing the original to replace (in practice it doesn't because the mallated txn is only larger by one byte). Not only is the claim untrue, if anything it's the opposite of the truth.  But the speaker will never suffer any negative consequence that he cares about for spreading this lie, and it might convince some ignorant party... so he'll do it every time.

[franky1]

allow more transactions without having to increase the block size just yet.

https://blockchair.com/bitcoin/block/544791
Size (bytes)    1,700,065

Last I checked 1700065 was greater than 1000000.

last time i checked 3169 transactions was not more than the 4200tx of 7tx/s
last time i checked 3169 transactions didnt need 1.7mb
last time i checked 1.7mb for ~3200tx is not hard drive efficient transacting (over 500bytes average per transaction (facepalm))

last time i checked the whole 7tx/s capability. =604ktx a day
we have not had a single day of more that 600k... allthough the fluffy unicorns will promote 4x weight is now achievable........
oh and dont try with the 'theres no demand' pfft. there have been many days of mempools being above average and people waiting more then one block.. but last time i checked even in them situations we didnt get a single day above a 600k tx day

come on wheres the utupian fluffly cloud of upto 24,000tx a day
.. go on admit it. the witness scale factor limits actual full utility of 4mb weight, due to how transactions are fully(legacy) and partially(segwit) still limited to a 1mb limit hidden from being called a 1mb base block due to the wishy washy code of witness scale factor

come on wheres the utupian fluffly cloud of upto 24,000tx a day
.. go on admit it. even if everyone was to only use segwit transactions the expectation would be only a 2.5x utility average

[franky1]

wallets have always refused to spend unconfirmed outputs

last time i checked you could actually broadcast an ancester and broadcast a child and a blockcreator would include the ancester and child in the same block
thus the child that has funds originating from the ancester doesnt need to wait for a confirm(separate block)

all the block creator would do is make sure the child was listed after the ancestor in the same block. and it would be treated as valid

[franky1]

I guess some people are just pathologically uncomfortable with anyone else having any choice at all in their life.  The fact that you could choose to intentionally make a transaction that they allow other people to modify, and then have to deal with the consequences yourself just seems to drive some people wild.  

put the shoe on the other foot.. think outside your echo chamber box of fluffy clouds and utopia

i guess devs who pretend to care about network and user security are comfortable with not caring about the network and security. letting users who are not technical unintentionally make transactions that others can modify,. and then just saying its upto the users to deal with the consequences themselves....

Similarly, the fact there is some buried command-line configuration option that virtually no one sets to increase the minimum feerate your node will accept-- with essentially no consequence for anyone but yourself-- causes the same people to melt down

no consequence to others?
.. block latency/propagation delays for their peers..
...only getting transactions relayed if you pay more just to get your peers to relay/retain your transaction
...peers need to send transactions more then once due to the other person dropping..

*separating out witnesses was proposed back in 2012 when no one was really thinking much about L2.  
#Lightning was proposed before segwit was a thing

*chicken or #egg.. choose one then stick with it.. which came first?

It's really frustrating that they'll say anything to sustain their obsessions ... like above "they introduce RBF to actually help malleators malleate" uh no, third part malleability always either lower feerates or keeps it the same, so if RBF mattered at all it would actually make malleability less sucessful by allowing the original to replace (in practice it doesn't because the mallated txn is only larger by one byte). Not only is the claim untrue, if anything it's the opposite of the truth.  But the speaker will never suffer any negative consequence that he cares about for spreading this lie, and it might convince some ignorant party... so he'll do it every time.

im laughing..
people who RBF DONT lower the fee for the second(replacement) tx...
they increase the fee as a bribe to blockcreators to include the second tx with the greater fee and drop the first one with the lower fee.
i do laugh that you think malleators would even try to do RBF using a lower fee replacement....

seriously. im laughing now.
you really do try to downplay things and hide issues under the rug.

the mindset is comedy
1. let users deal with consequences
2. theres a big picture flaw but this feature wont solve it, its "exclusive" to only reduce potentially a small amount of change
3. offering choice is a users problem
4. devs cant solve the issue its impossible

It's really frustrating

whats really infuriating to you, is that some people just wont be sheep and kiss asses then just bite their lip
i know you want to be a founders, a team leader, a chief, a boss, a top guy because you dont like having people to answer to and dont like having people tell you when your not doing your job properly..
.. but welcome to the real world

and no your not on your last chicken nugget with no money left so are wanting to hear violins.
everyone knows your well paid. so dont play the victim card

[gmaxwell]

last time i checked 3169 transactions was not more than the 4200tx of 7tx/s
last time i checked 3169 transactions didnt need 1.7mb

Bitcoin's capacity has never been "tx/s", the "7tx/s" number comes from assuming every transaction would be a 2-in-1-out transaction.  The block I gave an example of would have only held slightly more than half the number of transactions without segwit. You can also see the effect of the increased capacity because fees have dropped to almost nothing again.

The block I linked to spent 9,039 inputs, which would have been impossible prior to segwit: each input takes 147 bytes, so without segwit a block could only have spent 6,802 even if it made no outputs at all. The block I linked to also made 3,553 outputs.

If all you care about is number of transactions, this block has 12,239... or 20.3 tx/s ... though they are all very small inefficient one-in-one-out transactions without real signatures. Size wise they are functionally segwit transactions because they have empty scriptsigs (technically one byte). (And yes, because segwit was a softfork, segwit-like transactions could be included in the chain from day one, they didn't have to wait for segwit -- they only had to wait for segwit to be secure).

last time i checked 1.7mb for ~3200tx is not hard drive efficient transacting (over 500bytes average per transaction (facepalm))

Again your posts are the opposite of the truth.  Services now use sendmany (and indiviguals sometimes coinjoin) combining many transactions into one. This makes the much more efficient. One transaction does the work of three but is only 1.5x the size...

wallets have always refused to spend unconfirmed outputs

last time i checked you could actually broadcast an ancester and broadcast a child and a blockcreator would include the ancester and child in the same block
thus the child that has funds originating from the ancester doesnt need to wait for a confirm(separate block)
all the block creator would do is make sure the child was listed after the ancestor in the same block. and it would be treated as valid

You have maliciously misquoted my message.

everyone knows your well paid

In fact, I haven't made any income for since 2017-12-31-- beyond a couple tens of dollars worth a month for helping with forum moderation. I live off selling investments. Not that it's any of your business. But for the record, just in case there are other similar pieces of shit to you that think it's okay to treat your fellow man like dirt relentlessly lying and throwing shit at him simply because you think he earns more than you. I hoped that the dishonest attacks would diminish if I had not further relationship or contact with Blockstream, and for the most part that has been true: It turns out that most of the slimeballs can't find anything negative to say except for baseless slander about where I work. Now, without that to hang their arguments on, they're mostly left either lying about where I work, or saying nothing.

I feel sad that you are such a loathsome and dishonest person, and sad for the world for all the damage you do to it.

[franky1]

now we really are going off subject. but he pokes, so ill bite. i know he had me on ignore for along time so i guess he has alot on his chest he wants to cough up.. just a pitty that the issues raised are concerning bitcoin code. which he is involved in thus he cant really blame me for bitcoin flaws that he and his his team dont want to fix, or he and his team have caused to sway people away from bitcoin...

but anyway

The block I linked to spent 9,039 inputs, which would have been impossible prior to segwit: each input takes 147 bytes, so without segwit a block could only have spent 6,802 even if it made no outputs at all. The block I linked to also made 3,553 outputs.

but do you want to know a real funny thing. something you tripped up with when you said impossible to let in ~9000 inputs
into a block pre segwit... here it is.. your words

If all you care about is number of transactions, this block has 12,239... or 20.3 tx/s ... though they are all very small inefficient transactions.

block 367853
Mined on    2015-08-01
Transaction count    12,239
Input count    13,176
Output count    12,917

year 2015=legacy block = pre segwit(2017)

but i do find it funny you shot yourself in your own foot with your own ammo.. by saying legacy couldnt handle it,, but then display it could... comedy gold..

EDIT: actually because of the comedy above of shooting yourself in the foot. ill actually give you a merit

anyway
i knew about that block and tx count.. secondly i dont deal with utopian single use case fluffy clouds. hense why i only mentioned the 7tx/s more rational numbers of rational usage and i broadened it to a 600k tx a day
because in reality people dont rely on single case examples. they prefer average expectations of real possible utility

and yes individual transactions is an indicator of individual users... batched transactions is an indicator of foolish people trusting funds to exchanges/middlemen and services.. so yea. i prefer to measure bitcoin by its transaction count
..

so since 2015.. when you first made the roadmap.. knowing what bitcoin was capable of (your own gunshot above) what have devs actually done to get passed a rational 600k a day tx expectation..
and please please dont refer to features that are purposed to divert people off the network

last time i checked 1.7mb for ~3200tx is not hard drive efficient transacting (over 500bytes average per transaction (facepalm))

Again your posts are the opposite of the truth.  Services now use sendmany (and indiviguals sometimes coinjoin) combining many transactions into one. This makes the much more efficient.

batching transactions was a thing even back in 2015 and before that........ so.. nothings different.

everyone knows your well paid

In fact, I haven't made any income for over a year now-- beyond a couple tens of dollars worth a month for helping with forum moderation. I live off selling investments. Not that it's any of your business.  But for the record, just in case there are other similar pieces of shit to you that think it's okay to treat your fellow man like dirt relentlessly lying and throwing shit at him simply because you think he earns more than you.  I'm sure that you suffer because your paid shilling doesn't pay well, but that isn't anyone elses problem... And indeed, I am far from broke, but that doesn't make continued efforts worth any time in particular.
The fact of the matter is that I'm not paid to work on Bitcoin, I've done it because I love it and care about its contribution to the world... but it's probably just not worth it when dishonest shills like you can just bury everything in shit and discord and almost no one will do anything to stop you.  Maybe the world just isn't ready for bitcoin.

1. i learned that ages ago that your ready to retire. which is why people should care more about bitcoins network security rather than devs. devs retire, devs move onto different projects, devs get bored.
too many people think your immortal and will be around forever. fact is even you have to admit you wont be,
you already semi retired when you left(well you announced you left) blockstream
.. devs move on retire, get old, have medical issues. get bored.. many reasons to not depend on a dev and only depend on network security.
.. just like satoshi, just like hal, just like many other devs... your not the first, and you wont be the last.
holding you up as an immortal god that will last forever.. caring more about you then network security of a global system is not in peoples interest.

2. your interests are not bitcoins network interests. or the communities interests. you made that clear by saying many things over many years about how things should not be fixed and left for users to deal with the consequences, users should just fork off, and many other things
 you guys even have the cowardice to still 9+ years on to call it an experiment. a betatest, a 0.x version. and to pretend at any community event to be just janitors when it comes to community desires, but then suddenly maintainers, chief technical officers of "the reference" "the core" when it comes to feature you want

3. i dont get paid to shill. i dont get paid to kiss ass. if anyone tried to pay me to change my opinion i would laugh at their attempts. even if someone tried to twist my words and then attempt to make a 25btc bet with me to prove a word twist, id just laugh at them. because they are the ones that are failing.

my income is from investments i made from 2012 and i am happy. i get to travel the world. some may think that because im posting night and day means i have some sleep problem due to bitcoin issues. when infact its simply me adjusting to different timezones

4. as for your actions i learned early on. you set yourself a goal of a one way street one direction future for bitcoin.. well not a street. lets call it a roadmap.
this roadmap is leading to getting people to mve their funds into locked vaults (issue: many more UTXO locked for longer periods than expected, while reducing the number of tx counts onchain).. just to push people into using a different network which is using th same business model as banks did in the 18th century in regards to gold

the thunderdome: 1 gold may enter 100 silver may leave... oops sorry i admit that was a misquote.. but close enough to hint at the lightning business plan compared to banking

5. and before you continue coding features not designed for network security, but for privacy of certain users..that WILL bloat transactions further.. yea i know u want to keep witness scale factor in play to hide how much bloat that feature will add to hard drives

ill say this
removing users ability to transparently audit bitcoins value.(confidential transactions) might look like a user convenience for the privacy conscious. but from a network security/audit prospective.. it just turns into a ledger of data it cant audit.
i know you'll say thats the point of your TX bloating 'payment codes'.. oops i mean commitments.. but it just makes the archived data just a ledger of useless data to the decentralised world.
things like that lead to people thinking, whats the point in being a full node

so instead of telling the community to go fork off oops lets use your words bilateral fork
so instead of telling the community alternative networks offer more than the bitcoin network does

how about actually stop pretending you care about bitcoin. and actually care about it. or man up and put your concentration to the real projects you care more about, like the alternative network known as lightning.. which i know you want because your investors ($101m) will want to get some returns on their investment. and yes. although you announced you left as a CTO, we all know deep down your still tied to it

[bitserve]

@franky1 I don't understand why you insist in the constant bashing and ridiculous ad hominem attacks against gmaxwell.

No, I am not a "groupie fan" as you say. While I do appreciate the work of Core there are some things I don't completely agree. Ie: At the time, I would have preferred that consensus went for Segwit2x, it didn't happen though... And consensus is much more important than some political/technical details.

I am an L2/LN fan though. You seem to be not, it's ok.

You seem to have studied or at least devoted enough time to learning many of the technical details of Bitcoin and to be somewhat knowledgeable in the subject. In contrast, some of your conclusions or narrative seem to be wrong. For example it has been clearly demonstrated that your strong narrative against Minisketch and some of your support points were (either intentionally or not) completely misleading and/or plainly wrong.

If you focused your effort in more objective facts instead of trying to desperately find arguments to support your preconceived and misleading conclusions maybe you would be way more constructive. Just saying.


@gmaxwell Thank you very much for all the clarifications and your contributions to Bitcoin!

[Toxic2040]

@gmaxwell

Never doubt that your hard work with bitcoin is unappreciated...it is very much so. That your taking the time to form coherent rebuttal's against a obvious troll is commendable as well.

Thank you.
tc

[franky1]

In contrast, some of your conclusions or narrative seem to be wrong. For example it has been clearly demonstrated that your strong narrative against Minisketch and some of your support points were (either intentionally or not) completely misleading and/or plainly wrong.

the thing is i see the big picture.
EG
issue: with bandwidth in relation to sending transactions so that users have them before a block is transmitted
reason: so that a block can be compact and users then dont need to grab transactions after compact block

instead of thinking of bigbox solutions that solve the whole issue. devs waste months and years on "exclusive" things that only handle a small offering, and only a offering for people who choose to use it. while not solving the broader big picture problem for the whole network

EG minisketch does not ensure nodes have every VALID transaction so that when a block arrives it can quickly validate a block without delay.
all because devs let users have configurable settings to play around and cause bottlenecks by being biased against certain transactions. thus ending up needing to retransmit transactions, causing delays in propagating blocks... all for the sake of 'user choice' which does affect other people (imagine the '8 degrees of separation theory' playing a game of chinese whispers)

if core want to be the defacto full node and network security offering the most efficient node that has least chance of block propagation latency.. then be a full node. take out all the funk that reduces a core node from being a full node. take out the user configurable stuff that can cause resends and latency. then you will find that resends and latency dont happen by default

if some users cant handle being a full node then they have the choice of electrum and other spv/litenodes
....
my other issue is how core devs dont want other teams to offer a full node option.. (unless the other team are actually colleagues/buddies)
take luke Jr's mandated follow core rules or get "f**k off" the network (UASF(it was actually a MCHF:mandated controversial hardfork)) or what greg would call a bilateral fork
take greg also loving the idea of hard forks if core dont get their way and others are trying to offer something different ON THE NETWORK

What you are describing is what I and others call a bilaterial hardfork-- where both sides reject the other.

I tried to convince the authors of BIP101 to make their proposal bilateral by requiring the sign bit be set in the version in their blocks (existing nodes require it to be unset). Sadly, the proposals authors were aggressively against this.

funny part about the whole 2016-17 saga is that if core actually went with a segwitx2. it would have activated segwit much sooner.. and without the august hard fork
funny part is all the drama of core pretending to delay things to avoid a hardfork, ended up with one happening anyway due to their one direction, push it till its forced, no consideration for the community, no compromise to find a middleground mindset

if core actually listened and actually compromised some of cores demands to meet communities wishes.. core would have got segwit sooner and the community would have got more legacy utility.

and last funny part. with the now 95% core dominance. there is no actual reason to keep the witness scale factor in play, as there is not a controversial enough diversity of nodes to cause issues.. i find it funny because the august 1st event could have ben utiiised better to get rid of the (hidden by witness scale factor) 1mb allowance area completely. thus letting both legacy and segwit actually both function and both have full access to upto 4mb..

but no.. they done a half assed job because they have a roadmap that goes against opening utility on the network, because they need people to move over to LN so that greg and lukes investors can make some returns

[franky1]

I am an L2/LN fan though. You seem to be not, it's ok.

i am not dead against lightning. i understand its NICHE. but i am a realist who is happy to be loud enough to inform people of its negatives and limitations. i dont like the false advertising "this is a fluffy unicorn solution that will solve everything" over promise that keeps happening
here are the devs themselves admitting LN has issues. limitations, complications
https://youtu.be/8lMLo-7yF5k?t=570

as for lightning. calling it a bitcoin layer or a bitcoin feature is just propaganda sponsorship buzzwords to make investors think they are buying into bitcoin because a separate network is throwing the word bitcoin about ALOT(too often).
funny thing is like how blockstream throw in the word bitcoin to get investment.. but then try to downplay and say that the money they get from blockstream investors has nothing to do with bitcoin development
or how litecoin is bitcoins silver
or how circle is bitcoin service (though its actually a FIAT business)

LN is a separate network. if no bitcoiners used LN, LN would still function. as its a separate network that litecoin and vertcoin and other coins can already do and will continue to use no matter if bitcoin is popular or not.

research it. hint: chainhash
here ill even show you a few lines of code that LN is not a bitcoin feature but a separate network for different coins
https://github.com/lightningnetwork/lnd/blob/master/chainregistry.go#L580

Code:

	litecoinMainnetGenesis = chainhash.Hash([chainhash.HashSize]byte{
		0xe2, 0xbf, 0x04, 0x7e, 0x7e, 0x5a, 0x19, 0x1a,
		0xa4, 0xef, 0x34, 0xd3, 0x14, 0x97, 0x9d, 0xc9,
		0x98, 0x6e, 0x0f, 0x19, 0x25, 0x1e, 0xda, 0xba,
		0x59, 0x40, 0xfd, 0x1f, 0xe3, 0x65, 0xa7, 0x12,
	})

	// chainMap is a simple index that maps a chain's genesis hash to the
	// chainCode enum for that chain.
	chainMap = map[chainhash.Hash]chainCode{

		bitcoinTestnetGenesis:  bitcoinChain,
                litecoinTestnetGenesis: litecoinChain,

		bitcoinMainnetGenesis:  bitcoinChain,
		litecoinMainnetGenesis: litecoinChain,
}

also knowing it locks up coins on network is going to cause UTXO sets get locked up. which lets say just VISAUSA user numbers(not global) used LN. thats 189million UTXO locked for long time periods and not transacting onchain. which will strain fullnodes UTXO issues while fullnode users are then seeing 'empty blocks' leading to less people wanting to be full nodes

having empty blocks is not making bitcoin better, its making bitcoin worse because all it does is when pools want/need fee's to pay for mining. the fee's for the FEWER users remaining on bitcoins network will have to pay more to get a confirm.

again diverting people off network does not help the network.
oh and please dont even bother with the old myth of "gigabytes by midnight" is the only other solution to a non-LN situation
oh and please dont even bother with the old myth of to pay miners limitations are needed on the network to force users to pay more.
oh and please dont bother with the old myth that LN solves the problem for everyone. LN is for a niche of users that spam alot and often. not everyone spends every day so having to lock funds up, spread funds over channels and be online all the time just to get paid is not a benefit to them.

there are many ways. to ofset the spammers from the ones that wont benefit
here is one which doesnt cause every user on the bitcoin network needing an increasing average fee.
(EG current situation. if one person spams txs into a block everyone has to pay a higher fee to bribe a pool)

while also (unbiasedly) persuading the spam every block regular spenders who 'could' benefit from LN to then use it
as using the bitcoin network is costing just the spammers more

so lets think about a priority fee thats not about rich vs poor(like the old one). not about a network wide everyone should pay an estimated average increased fee(like currently) but about respend spam and bloaters pay more, and everyone else pays for what they use dependant on personal circumstance.

lets imagine we actually use the tx age combined with CLTV to signal the network that a user is willing to add some maturity time if their tx age is under a day, to signal they want it confirmed but allowing themselves to be locked out of spending for an average of 24 hours because they are happy to wait to get cheaper fees.. or rduce the lock if they want priority by paying more for less delay.

and where the bloat of the tx vs the blocksize has some impact too... rather than the old formulae with was more about the value of the tx


as you can see its not about tx value. its about bloat and age.
this way
those not wanting to spend more than once a day and dont bloat the blocks get preferential treatment onchain.
if you are willing to wait a day but your taking up 1% of the blockspace. you pay more
if you want to be a spammer spending every block. you pay the price
and if you want to be a total ass-hat and be both bloated and respending often you pay the ultimate price

and lastly about lightning..
if you research into eltoo and read about the purpose of factories. to vault coins up(step 1) and then separately a step away from the blockchain create unconfirmed/unaudited payments.. which are then sent to users for users to use those as their channel open initial states(not blockchained UTXO)

this makes factories like the fortknox of gold then offering promissory notes.
the purpose then is to PREVENT USERS from just exiting back to bitcoins network. but instead hand back the unconfirmed updated initial state payment. to a factory. and the factory just give them new crisp unfolded payments to open channels.

meaning people are less able to individually just exit back to bitcoins network.. much like how banks done it with the gold/bank note business plan in the 18th century.. and we know how that played out

thunderdome: 2 may enter but only 1 may leave
LN factory: bitcoin and litecoin may enter but only litecoin may leave
banks: gold and silver may enter, but only silver may leave

yes factories are designed to reduce/prevent users broadcasting back to the bitcoin network.
you can dress it up in as many pink dresses and fluffy unicorns of how its a benefit. but atleast be open minded to the consequences.. after all banks done the fluffy unicorn promotions too about how returning back to gold was 'bad' and stayin with vaulted up gold while playing with unaudited payment methods was good

again i understand LN's NICHE utility for the few that may need it. but over selling LN as the utopia solution for all. and selling it as a feature of bitcoin.. is going too far. especially as those overselling LN are the ones saying bitcoin cant cope.. which leads to actually people prefering to leave LN using other coins.. thus not helping bitcoin

[hv_]

^

Yep. And full nodes honest mine and are incentivized by coinbase rewards and fees in future.

All other peripheral 'nodes' must follow, can do some recon jobs or relay some few new txs.

LN and other peripheral non bitcoin tech only weaken bitcoin s original economy.

[VB1001]

I have a question from some external Bitcointalk people, but they are interested in Bitcoin (this is good):
What solution is there in an exponential adoption of Bitcoin if the number of payments / transactions increases exponentially?

[bitserve]

I have a question from some external Bitcointalk people, but they are interested in Bitcoin (this is good):
What solution is there in an exponential adoption of Bitcoin if the number of payments / transactions increases exponentially?

It would depend on the timeline.

If it was an exponential rise incredibly fast.... well, here is one of the reasons why I am a fan of L2/LN. But even in that case.... and many people won't like my answer:

Third party LN wallets.

Yes, what I mean is not everybody running their LN wallet.... I mean that if the rise of adoption were so huge and fast it would probably be "trusted" third parties offering wallets (similar of having some coins on a exchange) with many well funded open LN channels to act as a proxy for you. They would act in a similar way as a bank does.... but instead of controlling the majority of your funds it would only be a small pocket change amount you would think enough for your daily/weekly spendings. Of course your coins on that site would just be an OIU but they won't need to constantly open and close channels to other major parties bloating the blockchain. That way the amount of blockchain tx's won't be as much impacted. Your main stash would remain under the control of your keys, on the blockchain.

Of course I want to believe that in that situation there would be some consensus to also REASONABLY rise the block size limit as needed.

But, in any case, in the scenario you are describing, it would be needed to divert a majority of tx's (the popular "coofee" and "pocket change" tx's)  via L2 and maybe even through L2 "proxies" (third party L2 online wallets).

[Wind_FURY]

I am an L2/LN fan though. You seem to be not, it's ok.

i am not dead against lightning. i understand its NICHE. but i am a realist who is happy to be loud enough to inform people of its negatives and limitations. i dont like the false advertising "this is a fluffy unicorn solution that will solve everything" over promise that keeps happening
here are the devs themselves admitting LN has issues. limitations, complications
https://youtu.be/8lMLo-7yF5k?t=570

Like any other software development, it will have limitations. Bitcoin too can be viewed as a software experiment that could fail.

as for lightning. calling it a bitcoin layer or a bitcoin feature is just propaganda sponsorship buzzwords to make investors think they are buying into bitcoin because a separate network is throwing the word bitcoin about ALOT(too often).

funny thing is like how blockstream throw in the word bitcoin to get investment.. but then try to downplay and say that the money they get from blockstream investors has nothing to do with bitcoin development
or how litecoin is bitcoins silver
or how circle is bitcoin service (though its actually a FIAT business)

LN is a separate network. if no bitcoiners used LN, LN would still function. as its a separate network that litecoin and vertcoin and other coins can already do and will continue to use no matter if bitcoin is popular or not.

Lightning is NOT a separate network. All coins transfered within those payment channels ARE Bitcoins deposited in a 2-for-2 multisig address that have their transactions recorded locally, for the time being, until the channel closes, and the final state of the channel is broadcasted on-chain like an ordinary Bitcoin transaction.

Stop gaslighting.

research it. hint: chainhash
here ill even show you a few lines of code that LN is not a bitcoin feature but a separate network for different coins
https://github.com/lightningnetwork/lnd/blob/master/chainregistry.go#L580

Code:

	litecoinMainnetGenesis = chainhash.Hash([chainhash.HashSize]byte{
		0xe2, 0xbf, 0x04, 0x7e, 0x7e, 0x5a, 0x19, 0x1a,
		0xa4, 0xef, 0x34, 0xd3, 0x14, 0x97, 0x9d, 0xc9,
		0x98, 0x6e, 0x0f, 0x19, 0x25, 0x1e, 0xda, 0xba,
		0x59, 0x40, 0xfd, 0x1f, 0xe3, 0x65, 0xa7, 0x12,
	})

	// chainMap is a simple index that maps a chain's genesis hash to the
	// chainCode enum for that chain.
	chainMap = map[chainhash.Hash]chainCode{

		bitcoinTestnetGenesis:  bitcoinChain,
                litecoinTestnetGenesis: litecoinChain,

		bitcoinMainnetGenesis:  bitcoinChain,
		litecoinMainnetGenesis: litecoinChain,
}

What is chainhash?

[franky1]

Lightning is NOT a separate network. All coins transfered within those payment channels ARE Bitcoins deposited in a 2-for-2 multisig address that have their transactions recorded locally,

im literally laughing now.
all coins are bitcoin deposits...

hilarious
you do know LN can function without bitcoin..
respectfully please do some research properly outside the echo chamber of your buddy group

[franky1]

here we go again another poke at the bear from the same buddy group derailing the topic. but ill bite

WINDFURY take this as a respectful message
go actually research LN outside the scope of just asking your certain buddies.
i kind of doubt you even watched the video from the lightning developers themselves
as it has become very apparent that a certain group is becoming an echo chamber only wanting to promote the fluffy cloud and unicorn over promises of another network

if you think LN is the bitcoin network. ask yourself what N stands for in LN.. lightning is not abbreviated to BNF(bitcoin network feature).. LN is not a blockchain either. and its not something that will fail if no bitcoiner used it.

LN is not dependant on bitcoins network. it is a separate network for multiple coins to vault up and be pegged into
(the 12 decimal payments are the pegged tokens)
LN will continue to run without bitcoin.

by chainhash that is an identifier buzzword so that (lets call them) masternodes can monitor multiple chains. by knowing
which chain is which.
LN is not coded to be just a bitcoin feature. its not for just bitcoins benefit, its not to make bitcoin unique

by masternode i mean a node thats a fullnode of many blockchains not just 1
(which is comedy itself. "full node of just bitcoin will become too big" bitcoin cant cope.. but LN masternodes will be fine being full node of many chains)
its funny because if LN nodes can cope with 3+ chains then nodes can cope with 1chain.

meaning if people can be masternodes of many chains they can be fine with being it for just 1.. which counters the rhetoric of one network is 'too big')

as it has become very apparent that a certain group is becoming an echo chamber.

research eltoo factories. not with the fluffy unicorn mindset of finding buzzwords like "oh look they called it eltoo to it must be a L2 thing" (thats just sponsorship buzzwordatory games that many play to gain investment by throwing in the word bitcoin into everything. EG coinbase and circle do it. yet they are fiat businesses handling different currencies. not sole services aiming at serving bitcoin alone to make only bitcoin have unique offerings)

so respectfully
look beyond the unicorn buzzwords with a critical mindset, look behind the buzzword illusion, and find the realistic stuff.


now lets take factories
onchain                                  |   offchain
(1)user->factory(vault UTXO)  | (2)factory(vaultutxo)&factoryhub(12dec peg)
                                             |                       ->(3)factoryhub&user->(4a)user&partnerA
                                             |                                                      ->(4b)user&partnerB
                                             |                                                      -> (4c)user&partnerC
                                                                     ^                             ^
                                               each->is a step AWAY from a tx that holds a onchain UTXO


i know what your next thinking.. that partner C holds co-signature control of users initial state 2 and 3 for security..
but no. for "privacy" they dont want the factory to be part of a 3-of-3 multisig where factory(hub) sees every payment users and partners do. where it would then require factory to sign off on each state change of the channel
also user wont be able to open channels with partner A and partner B
as then states 2 and states 3 become 5-of-5 multisigs making things more complex

and partner C doesnt want 'user' to broadcast back to bitcoin easily. hense why when closing a channel 'user' has to go back to factory and factory then decides if something should be broadcast. factory would notify C if user gave factory a close request (all off chain) and 'user' only then gets to sign a (2) close state to get back to (1) if factory agrees

emphasis: user C wont get sign off control of 'users' 2,3 but would be presented with OFFCHAIN UNCONFIRMED listing of
1,2,3,4 .. purely to show taint. (requiring trust) that 'user' hasnt secretly given more of the (3) value to another channel
because C is trusting factory will notify C if 'user' was playing games in other channels with funds that are meant to be for the 4c channel.

the whole point of factories is to have the factoryhub(3) aggregate transactions(4) and re-release a non blockchain payments(3) so that user channels(4) dont need to broadcast to the network to close channels.
they simply adjust 12 decimal payments between 3 and 4 to close a channel and re-open another channel with either the same person or a different person
or then request closing the user/factory hub(3) channel. to then get to a 8 decimal state(2) that can be signed out and put back to a coin networks blockchain

yes fluffy unicorn crowd will spin the positives. of less utility requirement of bitcoins network
but learn the critical concern of such too less utility of bitcoins network

if you think you can walk into starbucks and buy a coffee where by your using a LN masternode.. then ill laugh at whichever unicorn buddy told you so.
users will end up with phone apps that rely and trust on a server(factory) to monitor the blockchain

the best analogy for you to understand is user channels are like electrum litewallets. that communicate to electrum servers. whereby the electrum server decides if it should relay the transactions to the bitcoin network.

we already had in this debate about the min fee issue of transactions not getting around and not put into mempools. and many people complain that if the fee's are not right then a tx isnt sent..
even things like bread wallet. if the transaction doesnt use segwit outputs they wont relay transactions

and yes
the factory(masternodes) will be the "severs are needed" making a network centralised" argument that they play on bitcoin.. funny thing is taking utility away from bitcoin, to avoid bitcoin being a "server for 1 chain" by
wait for it....
... using an alternative network of "server for 3+chains".......
its funny because is not giving people more control. its giving them less control by locking funds into such network that is going to be more centralised

ill word it differently
ln promoter: "bitcoin will become servers we need another network to reduce bitcoin utility to avoid this"
btc realist: "maintaining 1 chain? you want another network that maintains multiple coins"
ln promoter: "yes"
btc realist: "and these masternodes of LN how many chains will they maintain"
ln promoter: "3+, but shhhh we need to reduce bitcoin utility"
btc realist: "but LN then becomes a network of server nodes of +3 requirements"
ln promoter: "yes, but shhhh we need to reduce bitcoin utility"

again you may think that people can run up just a lightning node for just bitcoin. but lightning nodes are already being coded as masternodes that by default have code for monitoring bitcoin and litecoin (look at previous post that already has the litecoin chainhash in its codebase by default)

imagine it this way
99% of users will be phone app litewallets using factories
0.9% master users wanting to be factories to earn some income just downloading the compiled .exe as they are not tech savvi.
0.1% will be tech savvi devs that will play around and not be default masternodes but able to code their own single chain independent use nodes that dont use factories nor litewallet

and if you think you will be one of the popular factory nodes. well forget it. coinbase, circle will as they along with blockstream
have been given hundreds of millions in investment over the years and the investors want some ROI
(why do you think the gameplay of the NYA agreement happened with the 3 card trick(NYA,UASF,bilateral) in 2017 played out like it did)

[bitfocus]

BTC core and it's uptime is like 20 hours a day.