How Many Full Nodes Bitcoin Online ?

[VB1001]

 "Welcome Bitcoin Full Nodes"

- If you are here, it means that your curiosity about BTCitcoin is increasing.

Hello everyone, this post is not for Bitcoin Core support, It's a little guide, it's distributed in 2 parts.
The first is a poll by vote, feel free to vote if you have an active node.
Second part is for the new arrival, rookie and of course for all the members of
Bitcointalk, we report the benefit of a complete active node 24/7 on the network.

- You have a Full Node running, please if yes, vote the poll, Thanks.

Before starting, although it is a very repeated topic in the forum, but the previous publications, are forgotten in the amount of new publications every day.

- What makes a Full Node?

• Full nodes download every block and transaction and check them against Bitcoin's most up to date consensus rules.
• Independently validating all formats of transactions.
• Independently validating full unstripped/unprunned block data.
• Filtering transactions and blocks to light node peers so as not to download all transactions in the network.
• Sending historical blocks to nodes that have been deactivated for a while.
• Transmit all formats of new transactions and relay all formats of valid transactions via peers.
• Running a full node is the only way you can use Bitcoin in a trustless way.

- Lets start:

You have a Full Node 24/7 , tell your experience ?
(Copy the header and answer)

Do you have any suggestions for Bitcoin Core Node and Wallet in the new updates ?
(Copy the header and answer)

What do not you like about Bitcore Node ?
(Copy the header and answer)

Now a sensitive issue, you think that the Bitcoin network would have to reward in some way the complete nodes 24/7?
(Copy the header and answer)

- Or participate directly with your opinion, of course.



I do not detail an installation guide because in the links of the Bitcoin Core website it is perfectly documented.
For your safety, always download from the official website.

- Info. BTCitcoin & Documents

• Genesis Block is the first block of a Blockchain 03/Jan/2009
• Symbol BTC
• Ticker BTC
• Max Supply 21.000.000 BTC
• Circulating Supply 17.409.362 BTC
• Lost +/- 4.000.000 BTC
• Satoshi Nakamoto White Paper https://bitcoin.org/bitcoin.pdf

- Installation available, Windows, Mac OS X, Linux, ARM Linux and Ubuntu

• Download Bitcoin Core https://bitcoin.org/en/download
• What Is a Full Node https://bitcoin.org/en/full-node
• Running Node Mode Pruned https://bitcoin.org/en/full-node#reduce-storage
• Open Port 8333 https://bitcoin.org/en/full-node#testing-connections
• Security of your wallet https://bitcoin.org/en/secure-your-wallet#online
• Check and setup your Online Node https://bitnodes.earn.com/
• Bitcointalk Bitcoin Technical Support https://bitcointalk.org/index.php?board=4.0

- Installation Guide

• Full Node Lightning Network
• Full Node VPS (Virtual Private Server)
• Full Node Raspberry Pi

- BTCooks

• Mastering Bitcoin by Andreas M. Antonopoulos
• The Book Of Satoshi by Phil Champagne

- Movies

• Banking on Bitcoin
• Escaping the Global Banking Cartel (Andreas Antonopoulos) https://www.youtube.com/watch?v=LgI0liAee4s

- Online Nodes

• Bitcoin Core Nodes https://luke.dashjr.org/programs/bitcoin/files/charts/software.html
• Bitnodes Live Map https://bitnodes.earn.com/nodes/live-map/

Thanks for participating !!!

(The links will be updated with more information.)

[1715338987]

1715338987

[1715338987]

1715338987

[1715338987]

1715338987

[1715338987]

1715338987

[1715338987]

1715338987

[1715338987]

1715338987

[franky1]

* Full nodes download every block and transaction and check them against Bitcoin's most up to date consensus rules.
* Independently validating all formats of transactions
* Independently validating full unstripped/unprunned block data
* Filtering transactions and blocks to light node peers so as not to download all transactions in the network.
* Sending historical blocks to nodes that have been deactivated for a while.
* Transmit all formats of new transactions and relay all formats of valid transactions via peers.
* Running a full node is the only way you can use Bitcoin in a trustless way.

fixed that for you

[VB1001]

* Full nodes download every block and transaction and check them against Bitcoin's most up to date consensus rules.
* Independently validating all formats of transactions
* Independently validating full unstripped/unprunned block data
* Filtering transactions and blocks to light node peers so as not to download all transactions in the network.
* Sending historical blocks to nodes that have been deactivated for a while.
* Transmit all formats of new transactions and relay all formats of valid transactions via peers.
* Running a full node is the only way you can use Bitcoin in a trustless way.

fixed that for you

Thanks for your appreciation 

[Last of the V8s]

Yeah no, you can run really old nodes that don't validate any of the newer rules and transactions.
Luke-jr said somewhere sth like 'well they aren't full nodes then', but many disagree.

lol Segwit is optional they said.

So yes a nice topic about a very important part of Bitcoin - run a full node, people.

* Running a full node is the only way you can use Bitcoin in a trustless way.

[bitserve]

Yeah no, you can run really old nodes that don't validate any of the newer rules and transactions.
Luke-jr said somewhere sth like 'well they aren't full nodes then', but many disagree.

lol Segwit is optional they said.

So yes a nice topic about a very important part of Bitcoin - run a full node, people.

* Running a full node is the only way you can use Bitcoin in a trustless way.

I know.

But why did YOU call me a socialist? I wanna know.

[Toxic2040]

Im not sure its safe out here guy's.....guy's?

-----------
Yes, Yes, Yes, No.

+1 WOsMerit anyhow for decent newb post. Seems legit.

Carry on.

[VB1001]

Yeah no, you can run really old nodes that don't validate any of the newer rules and transactions.
Luke-jr said somewhere sth like 'well they aren't full nodes then', but many disagree.

lol Segwit is optional they said.

So yes a nice topic about a very important part of Bitcoin - run a full node, people.

* Running a full node is the only way you can use Bitcoin in a trustless way.

I know.

But why did YOU call me a socialist? I wanna know.

Keep calm, do not fight, be patient, lol

Im not sure its safe out here guy's.....guy's?

-----------
Yes, Yes, Yes, No.

+1 WOsMerit anyhow for decent newb post. Seems legit.

Carry on.

Sure, I think it's one of the issues that newcomers do not know.
Thanks for the support

[Last of the V8s]

But why did YOU call me a socialist? I wanna know.

reported for off topic.
do you run a full node? sir?
do you agree with that pruning? eh?

[HairyMaclairy]

My 2010 laptop has a new lease of life running as a full node.  Best possible use it could be put to.

[d_eddie]

You have a Full Node 24/7 , tell your experience ?

My linux node runs 24/7. It's easy to manage: only updating the software requires some work now and then.

Do you have any suggestions for Bitcoin Core Node and Wallet in the new updates ?

When a new version is published, it would be nice to have automatic update packages pushed to appropriate servers too. Signed and all, of course.

Now a sensitive issue, you think that the Bitcoin network would have to reward in some way the complete nodes 24/7?

Economic rewards are for miners. Your own security is your reward, I guess.


(Gentlemen! Please. This is not the WO thread.)

[bitserve]

But why did YOU call me a socialist? I wanna know.

reported for off topic.
do you run a full node? sir?
do you agree with that pruning? eh?

It's completely on topic. In fact I am the only one that voted that I don't run a full node. That's MY vote.

I stopped running it like three/four years ago.

Yes, I do agree with pruning in some cases. (ie: better than nothing).

Socialist why?

[VB1001]

You have a Full Node 24/7 , tell your experience ?

My linux node runs 24/7. It's easy to manage: only updating the software requires some work now and then.

Do you have any suggestions for Bitcoin Core Node and Wallet in the new updates ?

When a new version is published, it would be nice to have automatic update packages pushed to appropriate servers too. Signed and all, of course.

Now a sensitive issue, you think that the Bitcoin network would have to reward in some way the complete nodes 24/7?

Economic rewards are for miners. Your own security is your reward, I guess.


(Gentlemen! Please. This is not the WO thread.)

The best answer !!!

Greetings

I have to make everyone respond like that.

(Gentlemen! Please. This is not the WO thread.)

I do not care today is the opening of the thread and it is an honor to have them here

If with this thread we get 1 new node, We won a little more battle 

[Last of the V8s]

But why did YOU call me a socialist? I wanna know.

reported for off topic.
do you run a full node? sir?
do you agree with that pruning? eh?

It's completely on topic. In fact I am the only one that voted that I don't run a full node. That's MY vote.

I stopped running it like three/four years ago.

Yes, I do agree with pruning in some cases. (ie: better than nothing).

Socialist why?

Can you not afford a 2010 laptop, like your comrade up there^, to run a full node?
It would strengthen the network. Or do you prefer to leech off your fellow man?
Or are you broke from paying taxes for the universal healthcare in your country (that you said you support)?

Note to commies and real people alike: 2010 laptops are fine as nodes but unsafe for keeping bitcoin on. Keep your bitcoin on an air-gapped much older machine, mkay?
Don't let the govt take your money yo.

I have to make everyone respond like that.

y tho?

[bitserve]

I don't see any reason to run a full node nowadays. Mining nodes do have an incentive to be run. Non-mining nodes don't, or do they?

[VB1001]

But why did YOU call me a socialist? I wanna know.

reported for off topic.
do you run a full node? sir?
do you agree with that pruning? eh?

It's completely on topic. In fact I am the only one that voted that I don't run a full node. That's MY vote.

I stopped running it like three/four years ago.

Yes, I do agree with pruning in some cases. (ie: better than nothing).

Socialist why?

Can you not afford a 2010 laptop, like your comrade up there^, to run a full node?
It would strengthen the network. Or do you prefer to leech off your fellow man?
Or are you broke from paying taxes for the universal healthcare in your country (that you said you support)?

Note to commies and real people alike: 2010 laptops are fine as nodes but unsafe for keeping bitcoin on. Keep your bitcoin on an air-gapped much older machine, mkay?
Don't let the govt take your money yo.

I have to make everyone respond like that.

y tho?

y tho?

I say this because I see that the structure is understood to respond.

[VB1001]

I don't see any reason to run a full node nowadays. Mining nodes do have an incentive to be run. Non-mining nodes don't, or do they?

Many nodes, more decentralization, better for the network and for Bitcoin.

Rewards for having an active node, you do not have.

(Bitnodes ran a program to incentivize full node operators until the end of 2015)

This topic is interesting for this reason is in the OP

[bitserve]

I don't see any reason to run a full node nowadays. Mining nodes do have an incentive to be run. Non-mining nodes don't, or do they?

Many nodes, more decentralization, better for the network and for Bitcoin.

Rewards for having an active node, you do not have.

(Bitnodes ran a program to incentivize full node operators until the end of 2015)

This topic is interesting for this reason is in the OP

The thing is I don't think non-mining nodes add much security or decentralisation to the network. If you already are a major economic player, ie: an exchange, then yes, running a node adds security for both the network and yourself. Other than that I don't see much advantage. This is not a democracy, no one is gonna care if my node reject a transaction but if Bitstamp node rejects it, that has some real impact. On the other hand are nodes at the front of major pools which obviously have a great impact on the network but those do have an indirect incentive being a fundamental part of the miners behind.

[VB1001]

I don't see any reason to run a full node nowadays. Mining nodes do have an incentive to be run. Non-mining nodes don't, or do they?

Many nodes, more decentralization, better for the network and for Bitcoin.

Rewards for having an active node, you do not have.

(Bitnodes ran a program to incentivize full node operators until the end of 2015)

This topic is interesting for this reason is in the OP

The thing is I don't think non-mining nodes add much security or decentralisation to the network. If you already are a major economic player, ie: an exchange, then yes, running a node adds security for both the network and yourself. Other than that I don't see much advantage. This is not a democracy, no one is gonna care if my node reject a transaction but if Bitstamp node rejects it, that has some real impact. On the other hand are nodes at the front of major pools which obviously have a great impact on the network but those do have an indirect incentive being a fundamental part of the miners behind.

A question, in the collapse of transactions 2017 perhaps with thousands and thousands of active nodes we would not have had the problem in the network.

[franky1]

The thing is I don't think non-mining nodes add much security or decentralisation to the network. If you already are a major economic player, ie: an exchange, then yes, running a node adds security for both the network and yourself. Other than that I don't see much advantage. This is not a democracy, no one is gonna care if my node reject a transaction but if Bitstamp node rejects it, that has some real impact. On the other hand are nodes at the front of major pools which obviously have a great impact on the network but those do have an indirect incentive being a fundamental part of the miners behind.

if a full node was run just by mining pools. of course they would ignore their competitions efforts and just want their own blocks to win. so there needs a unbiased outsider group deciding what gets added to a chain.

normal home users that need to monitor just 1-5 addresses dont need to monitor every transaction of every block every day. and normal home internet would bottleneck the propogation if a home user was to foolishly want to connect to 120 nodes.
infact mathematically its better for home users to only connect to 10 nodes

however merchants that need to validate hundreds/thousands of transactions they are more needing to have a reliable ledger. so businesses are more important. because if they dont relay transactions of their customers then the merchant wont get paid if a pool doesnt add a transaction to a block.

where as users would prefer not to relay transactions and hope pools dont receive it. because they hope merchants would see a unconfirm and react, while hope a pool dont receive and confirm. so users are not actually needing to have a reliable ledger, users prefer slow networks because they hope the merchant act on the unconfirmed transaction so a user can double spend

with all that said..
if all users are just running core. unedited.. they are not decentralising th network. they are just distributing the chain
distributing and decentralising are 2 different things

[bitserve]

I don't see any reason to run a full node nowadays. Mining nodes do have an incentive to be run. Non-mining nodes don't, or do they?

Many nodes, more decentralization, better for the network and for Bitcoin.

Rewards for having an active node, you do not have.

(Bitnodes ran a program to incentivize full node operators until the end of 2015)

This topic is interesting for this reason is in the OP

The thing is I don't think non-mining nodes add much security or decentralisation to the network. If you already are a major economic player, ie: an exchange, then yes, running a node adds security for both the network and yourself. Other than that I don't see much advantage. This is not a democracy, no one is gonna care if my node reject a transaction but if Bitstamp node rejects it, that has some real impact. On the other hand are nodes at the front of major pools which obviously have a great impact on the network but those do have an indirect incentive being a fundamental part of the miners behind.

A question, in the collapse of transactions 2017 perhaps with thousands and thousands of active nodes we would not have had the problem in the network.

No. It would have changed nothing. First because only mining nodes process the tx's into blocks and second because the blocks were already up the hard limit.

Adding more nodes, even mining ones, would not raise the limit.

[VB1001]

Since I have Bitcoin I have always had a Full Node online, first on an old PC, then on a laptop and now I will install it on a 24/7 server where I have my music, photography and video server.

It the least i can do for Bitcoin. lol

[JayJuanGee]

It seems that the poll should include categories of people who might not currently have a full node, but consider decent chances that they will run a full node in the future.

[Last of the V8s]

A question, in the collapse of transactions 2017 perhaps with thousands and thousands of active nodes we would not have had the problem in the network.

No it's the miners who include some of the backlog of transactions into the blocks.
The node you are running checks whether they did that according to your rules.

[VB1001]

It seems that the poll should include categories of people who might not currently have a full node, but consider decent chances that they will run a full node in the future.

Ok I will update the voting options.

This technical discourse is the best when you learn and awaken interest in its beginnings and how the Bitcoin network works.

I hope it continues like this for a long time.

[vapourminer]

my node is a "part time" full node, and lives on my daily driver desktop. no pruning i want the entire blockchain so i can validate it myself, even off line, right to the genesis block if need be. its only 206 gb, well within even old home computer specs. i just point it to its own dedicated ssd.

but due to VERY slow internet (1.5 megabits/sec) i only run it every few days, or if im sending or expecting to receive something i need to verify at once. after all, MY node is the one i trust. when its running my internet is pretty much useless for anything else but basic browsing. thus the "as needed" thing.

keeping blocks and bandwidth requirements small(ish) to the point where basically anyone, with almost any computer from the last 10 years or so, can run a full on node with mainstream (or below to a point) internet is a main strength of btc imo.

everyone who uses btc should be able validate the blockchain themselves if they want, which would need a full node with a full copy of the blockchain. else why trust it?

[fenican]

It's sad that, after nearly a decade since the Genesis block (01/03/2009), the total size of all the transactions ever done on Bitcoin is only about 200GB. Holy low volume, Batman. We need more people using the coin.

[VB1001]

my node is a "part time" full node, and lives on my daily driver desktop. no pruning i want the entire blockchain so i can validate it myself, even off line, right to the genesis block if need be. its only 206 gb, well within even old home computer specs. i just point it to its own dedicated ssd.

but due to VERY slow internet (1.5 megabits/sec) i only run it every few days, or if im sending or expecting to receive something i need to verify at once. after all, MY node is the one i trust. when its running my internet is pretty much useless for anything else but basic browsing. thus the "as needed" thing.

keeping blocks and bandwidth requirements small(ish) to the point where basically anyone, with almost any computer from the last 10 years or so, can run a full on node with mainstream (or below to a point) internet is a main strength of btc imo.

everyone who uses btc should be able validate the blockchain themselves if they want, which would need a full node with a full copy of the blockchain. else why trust it?

Very interesting message, a conventional PC running a full node online with a 1.5 Mbs Internet connection, perfect, this is the goal.

[franky1]

bitnodes.earn.com
under 10k nodes.. (less that 7k are full nodes)
over 3000 of all under 10k nodes of mixed ability (full and not so full) are on servers

gotta laugh.

you cant be decentralised if you all who are running one of the 1400+ nodes on amazon.. are running a node on amazon.
if your running a node on amazon and ur not a business.. your just not seeing the point of running a node

anyway https://bitnodes.earn.com/nodes/?q=1037
less than 7k are shown as being full nodes

[VB1001]

The new requests of the participants will be published in a single thread that I will update.

I encourage you to publish your opinions, if we get enough we will look for the way to send them to the Bitcoin Core team.

If you like Bitcoin, put a Node in your life, Bitcoin was not born just to make money.

An important detail that differentiates us, remember, we are all Bitcoin !!!

[franky1]

2 idea's devs ignore simple because i dont kiss their ass:

1. fee priority
though i personally am a white brit. i can see the impact fee's have on multiple countries because i actually went and visited countries. when thinking of decentralisation its best to think about others. not just a typical rich wall street american

imagine a country where 25cents/pence was 5 hours labour for a dozen countries
saying 25cents is not acceptable as its ruling out the desires of a dozen countries
saying $1 is cheap is ruling out several dozen countries desires

if the rich want to pay more because its still cheaper than other methods. then they should pay more

EG bring back a fee priority mechanism
fee =
total sats=(bytes + (total input value/1000))*(144 - confirms of inputs)

this formula would make it so that
a. if someone was to spam the network everyblock(1confirm resend) they pay 143 times more than someone that only spends once a day.
b. those that send more, pay more.. they can all afford 0.1%
c. if someone had a bloated tx of 2.5kb vs someone with only 250bytes the bloater pays 10x more for the 10x space they consume
d. this just gets a easy to automate fee. while still allowing people to add more if they want to wave their hands in the air that they want priority.

2. initial block download headache
these days 200gb is storage the size of a finger nail. its not "servr farm". these days a 4tb hard drive is less than a single persons grocery bill for one week. so again no debate about size of price needs to be FUD'd

the real issue people actually have is having to wait.
yep thats the real complaint. having to wait hours to spend funds.

the solution is simple. dont do block download first before displaying balance. do a quick wallet check and get the addresses of local node and SPV/bloom details about them.. that way within seconds of opening up the node people know a UNVERIFIED BALANCE, which is better than nothing. if they spend and find out the bloom data was faked. then no harm the tx wont relay and wont confirm.. but atleast users can actually do something when they open their node.
then the initial block download becomes a background activity people dont notice because they are not having to wait for the IBD before even seeing a balance verified or unverified

[bitserve]

^

About your first point. Fees has nothing to do with non-mining nodes. Well, yes, there is a minimum fee and any tx with lower fee gets dropped by all nodes but, in the end, it is miners that decide what practical minimum fees are needed to be included in the next block. I don't think there's nothing the developers need to do about that... it's up the fee market.

About your second point. That's what SPV wallets are for. You are proposing that a full node somehow "degrades" itself into an SPV which basically defeats its own purpose.

[franky1]

^

About your first point. Fees has nothing to do with non-mining nodes. Well, yes, there is a minimum fee and any tx with lower fee gets dropped by all nodes but, in the end, it is miners that decide what practical minimum fees are needed to be included in the next block. I don't think there's nothing the developers need to do about that... it's up the fee market.

About your second point. That's what SPV wallets are for. You are proposing that a full node somehow "degrades" itself into an SPV which basically defeats its own purpose.

1. mining bribes can remain miners choice.
im talking about a NETWORK rule that takes the guess work out of min fee just to be relayed peer 2 peer.
saying its "upto the fee market" is useless
if everyone is checking the same website that estimates the market.. then everyone pays the same amount.
meaning someone spamming the network pays the same amount as someone that only spends once a day.
meaning someone in america spending $4 on a coffee pays the same as someone in third world who pays $0.10 for coffee

again think outside the box of rich american rule. think about a fairer variable rule that alters depending on circumstance. thus not ruling out lower classes

a rule that penalises spam spending habits. infact to be devils advocate it would actually make people that want to spend many times a day, find it cheap to use LN. where as those who only spend once a day who wont benefit from LN still find it cheap to use onchain. remove bias and removing forced adoption of LN, allowing choice, teaching people better money handling habits. takes the guess work out of it. takes out the everyone must visit this fee estimate site. taking out the america knows best so fees are set to american spending standards

2 bloom filters before IBD
. its not about making a full node an SPV. its about letting a user get on with their lives while they remain part of the p2p network

imagine wanting to play GTA game.
would you prefer to wait a day downloading from torrents and then play. or get a quick demo that allows you to do a training mission while the full game torrent downloads in the background... you will soon understand that frustrations are then removed because people get to do something rather than just looking at a download % screen

[VB1001]

If after reading this thread you feel curious to mount a node you can do it for little money.

The simplest thing is to use your computer and install it.
You can buy a hard drive and store the largest part of the node on the hard drive.
This will be to invest a small amount of $ and apart from installing the node we will gain storage space for other files.

If you have a NAS you can run it 24/7 full time.

[vapourminer]

my node is a "part time" full node, and lives on my daily driver desktop. no pruning i want the entire blockchain so i can validate it myself, even off line, right to the genesis block if need be. its only 206 gb, well within even old home computer specs. i just point it to its own dedicated ssd.

[...]

keeping blocks and bandwidth requirements small(ish) to the point where basically anyone, with almost any computer from the last 10 years or so, can run a full on node with mainstream (or below to a point) internet is a main strength of btc imo.

everyone who uses btc should be able validate the blockchain themselves if they want, which would need a full node with a full copy of the blockchain. else why trust it?

Very interesting message, a conventional PC running a full node online with a 1.5 Mbs Internet connection, perfect, this is the goal.

i should clarify that running a full or part time node on your daily driver isnt the ideal way to do so, but as ive shown it can certainly be done. dedicated hardware is better, an off the shelf system from the last decade should be able to handle it. even some netbooks from a while ago should have the chops and those are dirt cheap. 320 gig drive, atom cpu, ubuntu or other flavor of linux.. poof, btc node.

reason mine is still on a daily driver is im lazy, and because back in 2011, when i first installed the btc wallet and started mining, it was to my desktop at that time. this same wallet/node has just been moved to the replacement daily drivers when i build new ones. i was in it more for the tech then, the "magic interetz money" bit was a fun meme that possibly might help pay for my gaming videocards, but hardly one i took seriously until i had leaned a lot more about how banks and fiat worked.

once i understood the whitepaper and its implications.. well thats when the tech took a second seat to the real meaning of btc.. which is be your own bank.

as for keeping btc on a node on a daily driver desktop.. well mine has pocket change. how your main stack of btc should be secured really depends on your comfort and knowledge level of hardware, software, security. if its an amount that you cant risk, paper wallets, hardware wallets, air gapped computer wallets.. all these and more are options, and i would use a combination of them.

[VB1001]

my node is a "part time" full node, and lives on my daily driver desktop. no pruning i want the entire blockchain so i can validate it myself, even off line, right to the genesis block if need be. its only 206 gb, well within even old home computer specs. i just point it to its own dedicated ssd.

[...]

keeping blocks and bandwidth requirements small(ish) to the point where basically anyone, with almost any computer from the last 10 years or so, can run a full on node with mainstream (or below to a point) internet is a main strength of btc imo.

everyone who uses btc should be able validate the blockchain themselves if they want, which would need a full node with a full copy of the blockchain. else why trust it?

Very interesting message, a conventional PC running a full node online with a 1.5 Mbs Internet connection, perfect, this is the goal.

i should clarify that running a full or part time node on your daily driver isnt the ideal way to do so, but as ive shown it can certainly be done. dedicated hardware is better, an off the shelf system from the last decade should be able to handle it. even some netbooks from a while ago should have the chops and those are dirt cheap. 320 gig drive, atom cpu, ubuntu or other flavor of linux.. poof, btc node.

reason mine is still on a daily driver is im lazy, and because back in 2011, when i first installed the btc wallet and started mining, it was to my desktop at that time. this same wallet/node has just been moved to the replacement daily drivers when i build new ones. i was in it more for the tech then, the "magic interetz money" bit was a fun meme that possibly might help pay for my gaming videocards, but hardly one i took seriously until i had leaned a lot more about how banks and fiat worked.

once i understood the whitepaper and its implications.. well thats when the tech took a second seat to the real meaning of btc.. which is be your own bank.

as for keeping btc on a node on a daily driver desktop.. well mine has pocket change. how your main stack of btc should be secured really depends on your comfort and knowledge level of hardware, software, security. if its an amount that you cant risk, paper wallets, hardware wallets, air gapped computer wallets.. all these and more are options, and i would use a combination of them.

Today with the popularity of Bitcoin, new users do not bother to know what Bitcoin really is, they are only interested in earning fast money.
It's a shame not to have been here at the beginning of Bitcoin, you are part of something very special.
When someone asks me what Bitcoin is, I try to explain what it is and take the opportunity to tell him to read a bit about Bitcoin, one of the books that is pretty well explained is Mastering Bitcoin Unlocking Digital Cryptocurrencies.



If everyone who comes to Bitcoin understood their technology, we would have more nodes working.
Thank you

[VB1001]

You have a Full Node 24/7 , tell your experience ?

I only run full-nodes when i use my computer since computer isn't designed to run 24/7

If this is true, it depends on the computer, it is not convenient to be there 24/7, at least you need a box that is well ventilated to maintain a correct temperature.

Do you have any suggestions for Bitcoin Core Node and Wallet in the new updates ?

Better linux support such as release .appimage, .rpm or .deb since install from .tar.gz is inconvenient and not all linux distro support 3rd-party repository by default

Good point I will add to the requests.

What do not you like about Bitcore Node ?

Minimal UI and could run on low-end/barebone-pc, few people even manged to run Core and LND on Raspberry Pi 3 which is amazing IMO

If I think the same thing, the interface is a bit poor and they have to design it to adapt it and install it with any device, if they do not, it is difficult to move forward.

Now a sensitive issue, you think that the Bitcoin network would have to reward in some way the complete nodes 24/7?

No, especially it could weaken Bitcoin security/decentralization

If after reading this thread you feel curious to mount a node you can do it for little money.

The simplest thing is to use your computer and install it.
You can buy a hard drive and store the largest part of the node on the hard drive.
This will be to invest a small amount of $ and apart from installing the node we will gain storage space for other files.

If you have a NAS you can run it 24/7 full time.

Yes, you can run full nodes with low money, but that doesn't apply to some developing/3rd-world country.

Higher electronic taxes, weak USD/country's fiat exchange rate and high inflation make electronic/electronic component expensive.
Additionally, running computer/server 24/7 (on long term) cost more money than buy an HDD due to electricity price.

You're right, here I made a mistake, there are many parts in the world that unfortunately can not afford something like this, for low wages, very high electricity costs, instability in the electricity grid or for political reasons.

Thanks for commenting.

I answer by quoting in green, very instructive your answers.

Regards.

[somac.]

Nice Thread.

I've had a full node in the past, and will again soon. I'm setting up a bitcoin and lightning node on a Raspberry Pi as we speak. I'm going with the raspiblitz setup, it's pretty sweet and very simple.

link for anyone who is interested

https://github.com/rootzoll/raspiblitz

[vapourminer]

It's a shame not to have been here at the beginning of Bitcoin, you are part of something very special.

it 1st showed up on my radar mid 2011 when a few computer tech sites started posting about it. i happened to have hardware that met the gpu requirements, so figured why not? i had no idea it would take off as it has, figured it was just a neat experiment on digital money. although in retrospect i should have.

When someone asks me what Bitcoin is, I try to explain what it is and take the opportunity to tell him to read a bit about Bitcoin, one of the books that is pretty well explained is Mastering Bitcoin Unlocking Digital Cryptocurrencies.

yup, got that book on my end table. a must read for anyone who wants to understand (or at least understand better) btc rather than just use it.

[VB1001]

Nice Thread.

I've had a full node in the past, and will again soon. I'm setting up a bitcoin and lightning node on a Raspberry Pi as we speak. I'm going with the raspiblitz setup, it's pretty sweet and very simple.

link for anyone who is interested

https://github.com/rootzoll/raspiblitz

Good news, I hope when you have it online, tell us your experience, I visited the link, the tutorial has a lot of information for the configuration.

Regards.

[VB1001]

It's a shame not to have been here at the beginning of Bitcoin, you are part of something very special.

it 1st showed up on my radar mid 2011 when a few computer tech sites started posting about it. i happened to have hardware that met the gpu requirements, so figured why not? i had no idea it would take off as it has, figured it was just a neat experiment on digital money. although in retrospect i should have.

When someone asks me what Bitcoin is, I try to explain what it is and take the opportunity to tell him to read a bit about Bitcoin, one of the books that is pretty well explained is Mastering Bitcoin Unlocking Digital Cryptocurrencies.

yup, got that book on my end table. a must read for anyone who wants to understand (or at least understand better) btc rather than just use it.

You are giving me a lot of envy, healthy, but envy.
Receiving the first Bitcoins mined at home had to be fantastic.
It was a good experiment and save the Bitcoins until today is the best reward.
Congratulations.

Regarding the book, yes, you would have to force it to buy it before having Bitcoin, another one that I recommend is Satoshi Nakamoto White Paper https://bitcoin.org/bitcoin.pdf

The book and the White Paper are required reading.

[VB1001]

Bitstamp (twitter) they have published this photo recommending installing a Full Node to improve the network.



We are not alone.

[VB1001]

Nodes online:



BTCitcoin Core / 9468

https://coin.dance/nodes/core

[@Mbit]

In the future I want to run a full node
I have questions
I need a very powerful computer?
How much CPU power?
How much hard disk Gb?
Hard disk HDD or SSD?
Nice thread and design, I still have no merits, I would give 1 merit but I do not have.

[vapourminer]

In the future I want to run a full node
I have questions

most info you need is in a link right in the 1st post:
https://bitcoin.org/en/full-node#minimum-requirements

I need a very powerful computer?

no. a rasperry pi 3 would do. or an intel atom from any netbook. basically if the computer less than 10 years old it will do.

How much hard disk Gb?
Hard disk HDD or SSD?

500 gb should last a few years at the rate the blockchain is growing. currently the blockchain is ~210gb. a ssd will make syncing faster but not needed, mechanical drives are fine for a node.

blockchain growth chart can be found here:
https://www.statista.com/statistics/647523/worldwide-bitcoin-blockchain-size/

[VB1001]

I only run full-nodes when i use my computer since computer isn't designed to run 24/7

If this is true, it depends on the computer, it is not convenient to be there 24/7, at least you need a box that is well ventilated to maintain a correct temperature.

It's true, especially if you use cheap or old parts. I'll measure my ventilation, temperature and avg. watt usage later.

When someone asks me what Bitcoin is, I try to explain what it is and take the opportunity to tell him to read a bit about Bitcoin, one of the books that is pretty well explained is Mastering Bitcoin Unlocking Digital Cryptocurrencies.

yup, got that book on my end table. a must read for anyone who wants to understand (or at least understand better) btc rather than just use it.

Make sure you read 2nd edition as it contains newer technology (such as SegWit) and fix few wrong information.

Also, it's free (and legal, obviously) at https://github.com/bitcoinbook/bitcoinbook. So people don't have excuse anymore.

Nodes online:



BTCitcoin Core / 9468

and actual full nodes number is higher as most full nodes client don't enable port-forwarding, even though there's no accurate way to measure it's number

Thanks for the 2nd edition book, Antonopoulus.
Ventilation is essential for the indoor temperature, a good fan will improve sure.
Yes, I know, I'm going to add information about the number of visible nodes with more than 8 active connections and those who are only active as clients.

[VB1001]

Running Full Node

The Bitcoin Core GUI are several icons. If you hover over the signal strength icon, it will tell you how many connections you have.



The icon won’t turn "green" until you have more than 8 active connections, which only happens if inbound connections are allowed.

Peer info in Bitcoin Core GUI https://bitcoin.org/en/full-node#gui-peer-info

Peer info in Bitcoin Core daemon https://bitcoin.org/en/full-node#daemon-peer-info

[VB1001]

In the future I want to run a full node
I have questions
I need a very powerful computer?
How much CPU power?
How much hard disk Gb?
Hard disk HDD or SSD?
Nice thread and design, I still have no merits, I would give 1 merit but I do not have.

Thanks for your support.

Regards.

[VB1001]

Good web on the state of the Lightning Network

Number of Nodes
Number of Channels
Network Capacity
and more information

Lightning Network Search and Analysis Engine https://1ml.com/

[The Sceptical Chymist]

Many nodes, more decentralization, better for the network and for Bitcoin.

Rewards for having an active node, you do not have.

I get the reason for running a node, but I don't have the spare memory/computing power to do so--and there's no reward for running one, so I temporarily un-ignored this section and voted "no" because I saw your thread in Meta. 

Don't laugh at me or call me names, but I was experimenting with earning interest through PIVX and downloaded the whole blockchain and kept it running, and it just made everything else on my computer run really slow.  I'm not a huge computer guy, don't own any spare laptops or anything, and my internet connection isn't the greatest, so I nixed that whole idea.  As an aside, I think I bought the PIVX when it was around $3 and look where it is now: $0.49.  So I'd like to say screw PIVX in addition to everything I wrote above.

[franky1]

https://bitnodes.earn.com/nodes/
it says 9737 differnt types of nodes at time of posting
if you then search for 1037 (tag that suggests running full node services)
it says 6295 at time of posting

thats 65% of nodes are full nodes


and going back to the near 10k diverse nodes.. if you search out the current block height
it says 5805 at time of posting
thats under 60% that are uptodate of all nodes.

which means that the 65% of full nodes are not all uptodate

oh. also out of the near 10k nodes 30% of them are all hoarded on amazon, hetzner and digital ocean servers. meaning not decentralised.

so the representation of decentralised, diverse, uptodate and fully validating nodes is more closer to 3k than it is to 10k

[VB1001]

Many nodes, more decentralization, better for the network and for Bitcoin.

Rewards for having an active node, you do not have.

I get the reason for running a node, but I don't have the spare memory/computing power to do so--and there's no reward for running one, so I temporarily un-ignored this section and voted "no" because I saw your thread in Meta.  

Don't laugh at me or call me names, but I was experimenting with earning interest through PIVX and downloaded the whole blockchain and kept it running, and it just made everything else on my computer run really slow.  I'm not a huge computer guy, don't own any spare laptops or anything, and my internet connection isn't the greatest, so I nixed that whole idea.  As an aside, I think I bought the PIVX when it was around $3 and look where it is now: $0.49.  So I'd like to say screw PIVX in addition to everything I wrote above.

If, unfortunately, the connection to the Internet is indispensable, be it good, this is a difficult point to solve, I am sure that if I did not have these problems I would have an online node.

https://bitnodes.earn.com/nodes/
it says 9737 differnt types of nodes at time of posting
if you then search for 1037 (tag that suggests running full node services)
it says 6295 at time of posting

thats 65% of nodes are full nodes


and going back to the near 10k diverse nodes.. if you search out the current block height
it says 5805 at time of posting
thats under 60% that are uptodate of all nodes.

which means that the 65% of full nodes are not all uptodate

oh. also out of the near 10k nodes 30% of them are all hoarded on amazon, hetzner and digital ocean servers. meaning not decentralised.

so the representation of decentralised, diverse, uptodate and fully validating nodes is more closer to 3k than it is to 10k

Your answer is a good reason to encourage everyone to install a Full Node,
I hope that this thread arouses curiosity and we increase the number.

[bitart]

VB1001:
Please search the forum how to combine quotes from different posts from different members into one reply. Don't worry, it's easy
The above 2 posts has been made with 6 minutes difference, so it would be just easier to edit the first reply and insert the content of your second reply into the first post. You can also delete the second post, the topic would become more easy to read and you won't get reported in the end (it's against the rules to post several replies in a row into the same topic).

[vit05]

Nodes online:



BTCitcoin Core / 9468

This graphic is wrong, or, at least, not totally true about the real number. According to @gmaxwell: "that page only lists ones that accept inbound connections". The actual number could be over 50 thousand. Still, it may sound small, but it is not. This number already guarantees the necessary statistical reliability. And more nodes would be useful to ensure individual security and privacy, but would not be totally necessary or urgent at this time.

I do not know if bitcoin-seeder still works, but it could deliver better numbers: https://github.com/sipa/bitcoin-seeder

[VB1001]

<...>

Ok, I'm going to try the software bitcoin-seeder.

Bitcoin is only useful if it is decentralized.
The larger the hashrate a single miner controls, the more centralized Bitcoin.

One of the reasons why the increase in the size of the Bitcoin block is not a solution, is because if the block increases in size, the individual nodes will be excluded.
This is a danger for any network, not just Bitcoin.
The larger the block size the more centralization.

Start more individual Full Nodes is the solution.

[franky1]

If, unfortunately, the connection to the Internet is indispensable, be it good, this is a difficult point to solve, I am sure that if I did not have these problems I would have an online node.

home users that naively think connecting their (imagine worse case)1mb connection to 100 nodes is helping. it is not.
if you have low bandwidth its better to only connect to 10 nodes. thus the 10 nodes get the data relayed sooner.

no one wants to be connected at a speed of 0.01. when they could be connected to a node at 0.1
it puts less strain on the user AND less strain on the network this way.

imagine it this way. your house. you want to open it up as a homeless shelter. it can only accommodate 10 beds happily.
do you think cramming in 100 people is helping those people. or is it better to help just 10 people and let others find another house where if everyone offered a room for 10 people everyone becomes happy.

so in short if your bandwidth is tight. just connect to less nodes, better for you, better for those connected to you.
if 10 nodes is a problem. try 5, if that a problem try 2.. just dont go up to high numbers and then cry that your internet is super slow

[franky1]

Nodes online:
BTCitcoin Core / 9468

This graphic is wrong, or, at least, not totally true about the real number. According to @gmaxwell: "that page only lists ones that accept inbound connections".

AFAIK it's not wrong as it only show full nodes which open listening port 8333 and configure forwarding ports properly, the page should state this information.

You also can use https://luke.dashjr.org/programs/bitcoin/files/charts/software.html to check more accurate number, even though i'm not sure how updated is the page.

If, unfortunately, the connection to the Internet is indispensable, be it good, this is a difficult point to solve, I am sure that if I did not have these problems I would have an online node.

home users that naively think connecting their (imagine worse case)1mb connection to 100 nodes is helping. it is not.
--snip--

You're right, but some client by default only connect to up-to 8 nodes and people who can tweak such configuration should able to know that it doesn't help the network.

probably better if your gonna use lukes charts to atleast use the more useful one
https://luke.dashjr.org/programs/bitcoin/files/charts/branches.html ~65% are capable of being full nodes, but it doesnt really show how many actually are (not prunned)

and as for home users with bad internet or using it as an excuse i have seen many times when they post their logs they ramped up their connection count

[VB1001]

Interesting article:

Pierre Rochard > "Lightning Adoption Will Basically Mirror Bitcoin Adoption"

https://bitcoinmagazine.com/articles/pierre-rochard-lightning-adoption-will-basically-mirror-bitcoin-adoption/

Easiest Bitcoin Lightning Guide!

https://medium.com/@pierre_rochard/windows-macos-lightning-network-284bd5034340

[franky1]

what you'll find is that in the network. the whole consensus of solving byzantine generals problem has been bypassed. with near everyone just following one general now(core) and any dev team that wants to propose a new rule/feature that opposes the core roadmap ends up getting knocked off the network.. there is less need of a decentralised network(their view). as the "generals"(plural) has been sidelined and relegated off network. and now its one general and tens of thousands of loyal soldiers blindly following.

its gone from a byzantine generals solution for a decentralised generals network. to a singular general for a distributed soldier network

people end up not wanting to archive 10 years of data. just to wade through all that data just to ensure their $100 is confirmed.
holding the data if they are just interested in a few addresses becomes a waste of hard drive utility so they end up prunning it, thus they no longer become able to be a node that others can sync from

.. also you being a DNS seed is not being a full node. its just being a yellow pages directory to guide users to each other, essentually. which if you without bias dont set it to just list core nodes(as all DNS should do), would help if a revolution occured to bring core down a peg or two back down to an equal playing field with other nodes that want to get back to a united community of byzantine generals,
so it has purpose for some independent people to be DNS seed nodes to ensure the network doesnt become full 100% core only centralised.
.....
but back to the users being full nodes...
the situation will get worse when things are really pushed to pursuade users off the bitcoin network and into using another network like lightning.

because lightning network is not a bitcoin layer. it is its own network that allows multiple coins.
(bitcoin layer is just the sponsorship advertising buzzword many people use to try faming up that their project is part of the crypto industry, to garner investment)

users using the lightning network will find in a couple years that funds from litecoin, vertcoin or bitcoin are locked to be unspendable on their respective networks in a smart contract with a "factory/watchtower" entity. and this entity would need to monitor those multiple chains as a masternode.(super bloated mega node) to then when convinced the locks are locked. offer out a un-chained(unconfirmed) 'payment' to users that allows users to open channels. so that users can use phone apps to make payments instead of lugging around laptops/desktops when they visit starbucks

these factories become the gatekeepers (i would say banks but people hate when i say it, even if factually correct). this is so that users dont need to wait for their locked funds timeout to close a channel and broadcast a tx to the respective coin networks. they can just close channel and let the factory audit and then refresh them with a new un-chained(unconfirmed) 'payment' to reopen a new channel at any time.

this allows users to open/close channels more frequently if their co-partner in-channel is offline
yea i know your thinking the optimism of how great and user friendly it is. but. if you think about the whole network security of phone app users needing to trust a factory/masternode(bank) who has the real privatkey co-sign control of the real funds
and that the factory has to be a masternode monitoring the networks and also many users channels...
its not healthy. or secure, especially when the channels themselves are not byzantine general solved either

the only reasons the bitcoin network is told to people that blockchains dont work and impractical and slow. is due to the limitations of a blockchain imposed by the developers.(bitcoin is not AI self coding.. devs code it. devs put in the limitations, devs can remove them too)

anyway, take the initial block download argument. people dont really object to the blockchain data size. as a 256gb data is less than a fingernail(microsd) size, not a server size
its the fact that its coded that users cant even check a unverified balance to be able to do anything until the chain is synced.
if only they realised they could bloomfilter(request specific data of specific addresses) from peers first. just to get a unverified balance instantly. and then make the verifying/syncing more of a background secondary task that goes on less noticably so that people are not twiddling their thumbs waiting to see if they even have a balance/imported the correct wallet/keys

many people are too optimistic about lightning(future multicurrency banking system) but dont realise that to "be your own bank" on LN requires being a masternode of multiple chains. which is much more than just full noding one chain
(if you still think LN is bitcoin only feature.. research chainhash registry code in LN aswell as atomic swaps)


many people are too optimistic about lightning(future multicurrency banking system) but dont realise that its not a 'scaling bitcoin' its a take people away from bitcoin and use 12decimal payment values PEGGED to bitcoin via a masternode

many people are too optimistic about lightning(future multicurrency banking system) but dont realise that its not scaling bitcoin because its taking people off the bitcoin network where people wont want to be bitcoin full nodes as they are never going to be using bitcoin network daily

but anyways.. we are already seeing the dilution of the community bing diverted away from bitcoin. we are starting to see where the term "bitcoin maximalists" are being used as a derogatory term even to make it fel like if you support bitcoin as a payment network and want bitcoin to be secure and to scale then your 'dirt'

[VB1001]

^
Thanks for the analysis, your argument is very complete, I can not debate it because my knowledge in Bitcoin technology is very recent, but these innovations can serve to make Bitcoin adoption faster to the base of the population, which does not know how to save, buy, sell ​​or pay with Bitcoin.

They are projecting Bitcoin all over the Internet:

Tim Draper Backed OpenNode Startup Raises $1.25 Million



https://www.nasdaq.com/article/bitcoin-payment-processor-opennode-gets-125m-from-investors-cm1071687

Bitcoin Space:

The move is an interesting one, as it removes the dependency on a physical internet connection through traditional ADSL connections and fibre optic networks.

https://cointelegraph.com/news/bitcoin-from-space-blockstream-cso-explains-its-satellite-services

Maybe he's right, surely, if Bitcoin does not react, every time we will be less decentralized.

[franky1]

^
Thanks for the analysis, your argument is very complete, I can not debate it because my knowledge in Bitcoin technology is very recent, but these innovations can serve to make Bitcoin adoption faster to the base of the population, which does not know how to save, buy, sell ​​or pay with Bitcoin.

if you can understand the history of how banks came about in the 18th-19th century by locking gold up(call it bitcoin 8 decimal point value transactions locked outputs) and then hand people unaudited promissory(bank) notes(call it 12 decimal unconfirmed non blockchain transactions of value pegged to multiple coins(dependant on which coin you locked/atomically linked to)) then you will be on your way to understand what LN is doing with its latest concepts and direction.

as we all know what happened to the gold:bank imbalance after people stopped wanting to withdraw gold(bitcoin) but take silver(litecoin) coins out instead.

just remember LN wont by paying with real confirmed guaranteed funds. the developers have made it clear use at own risk. there is no way to guarantee fund confirmation.

LN is also not user adoption ready. and wont be for years, by which it will only fit a small niche of those wanting to spend under $100 for purchases of far less daily.

LN is to make people move away from the bitcoin network.
by definition that is not scaling bitcoin network in any way. its diluting/offsetting/removing utility

alot of people are already questioning the whole have fiat. then get a crypto, then lock a crypto to then split up unconfirmed crypto into multiple accounts to hope for productive regular use.... when its far easier to just use fiat to buy a few giftcards. job done.
(i have seen many other questions asked by average joe questioning is crypto better than fiat)

yes i understand th utopia. yes i understand as a bitcoiner myself all the other benefits of it. but for the outsider looking in. see LN as another barrier wall against adoption. "another room inside a room that needs to be walked through" (one reply was) "just to spend crypto as fast as say applepay or bank notes"

[DdmrDdmr]

<...>

My personal Full Node up-time status doesn’t seem to fit into any of the provided options. I run a full node "every now and then", meaning I could go days or even weeks without turning it on (and then patiently waiting to the sync to take place when I do).
 
I have on an external 4TB USB 3.0 disk, so as not to clutter my smaller SSD main drive, and since I have little spare time, I’m happy following the above procedure to look into things whenever I get some linear time to do so (which is seldom currently).

[VB1001]

What do you think?

Synching Data Between Bitcoin Nodes Is About to Get Easier, Minisketch is a new solution that’s trying to solve an old problem.

Blockstream co-founder Pieter Wuille, Bitcoin Core contributor and fellow Blockstream co-founder Gregory Maxwell, and Blockstream software engineer Gleb Naumenko.

https://bitcoinmagazine.com/articles/synching-data-between-bitcoin-nodes-about-get-easier/

[franky1]

What do you think?

Synching Data Between Bitcoin Nodes Is About to Get Easier, Minisketch is a new solution that’s trying to solve an old problem.

Blockstream co-founder Pieter Wuille, Bitcoin Core contributor and fellow Blockstream co-founder Gregory Maxwell, and Blockstream software engineer Gleb Naumenko.

https://bitcoinmagazine.com/articles/synching-data-between-bitcoin-nodes-about-get-easier/

firstly trying to get mempools synced is meant to be about if everyone has the same tx set before a pool mines a block, then all that needs to be sent as a confirmed block is the headers and list of txid's. thus reducing the data needed to be sent when a confirmed block is created.

but here lays the issues
1. "the tx fee freemarket flaw"
this is where certain nodes drop certain tx's at DIFFERENT dust/min relay levels. meaning different people will have different mempool sets.

so trying to get people to keep every tx again. is counter intuitive to the whole drop tx if under dust/min relay fee 'free market'
easier solution is get rid of the tx free market and implement a consensus (all node agree on) fee structure so when tx's are relayed initially they all keep the same tx's in mempool and not have to drop tx's using fee freemarket. to then suddenly need to grab hundreds of transactions from X and hundreds of tx from Y AGAIN

2. distributed mempool
highlighting not the freemarket part. but the individual picky nodes. some nodes such as those that are "downstream filtered"(gregs buzzword) non-segwit nodes dont relay non-segwit unconfirmed tx's,

also some nodes that are run by pools fill their blocks with their own zero fee tx data which they dont relay the tx's out pre confirm purely to cause latency issues for thir competition(BTCC pool done this a few years back). so it wont solve the issue because different nodes have different ways of doing things.

i do find it funny that it was these very same devs that wanted a fee freemarket by removing a fee priority mechanism to make individualising mempools, that are now seeing the flaw in it.. even if they dont want to admit it the cause/effect on their implementation

but allowing nodes to relay tx's and drop them due to "fee free market" but then have to interrogate nodes to list their entire mempools(actually causing more bandwidth) and pick up the tx's AGAIN(more bandwidth again).. is silly..

imagine it 3 different nodes with sat 5 tx(out of in each of thier mempools due to different tx fee level preferences
1,2, a,b,c
1,2,3,4,c
1,a,b,c,d

they all initially did get 1,2,3,4,a,b,c,d at initial relay.. but freemaket let them drop certain tx.
now the third node has to ask the first node for the list.. 1,2,a,b,c (more data than initial relay)
now the third node has to ask the first node for the missing.. 2 (more data than initial relay)
.
now the third node has to ask the second node for the list.. 1,2,3,4,c (more data than initial relay)
now the third node has to ask the second node for the missing.. 3,4 (more data than initial relay)

now the second node has to ask the first node for the list.. 1,2,a,b,c (more data than initial relay)
now the second node has to ask the first node for the missing.. a,b (more data than initial relay)
.
now the second node has to ask the third node for the list.. 1,a,b,c,d (more data than initial relay)
now the second node has to ask the third node for the missing.. a,b,d (more data than initial relay)

now the first node has to ask the second node for the list.. 1,2,3,4,c (more data than initial relay)
now the first node has to ask the second node for the missing.. 3,4 (more data than initial relay)
.
now the first node has to ask the third node for the list.. 1,a,b,c,d (more data than initial relay)
now the first node has to ask the third node for the missing.. d (more data than initial relay)

the solution is much more simple.. get rid of the free market that lets nodes drop tx's in the initial relay. thus they would ALL have them all first go-around. without having to interrogate EACH connected node, after dropping.. because their would be no drop in the first place.

3. issue
"Minisketch generalizes this by sending various types of ‘sums’ of the data. The result is that with N different sums, you can find N differences … As long as the number of differences between the sets is not more than the number of ‘sums’ sent, minisketch will always succeed in finding all the differences."

lets call (the node interrogation) or as they call it 'sending sums'  X
lets call bloom filtring the missing transactions Y
X)now the first node has to ask the third node for the list.. 1,a,b,c,d (more data than initial relay)
y)now the first node has to ask the third node for the missing.. d (more data than initial relay)

by getting rid of the "free market" and getting back to a consensus fee priority formulae/structure that everyone follows means that X is not needed. and Y becomes a smaller percentage of missing tx's that it becomes insignificant to need X

what makes me laugh though. is then saying that nodes can then do 16/24 connections instead of 8.. i laugh because imagine having to do the X command(sending sums to 2-3 times more nodes.....(facepalm)

again solution is much more simply. get rid off the freemarket that allows individualised mempools at the initial relay, to then not need to re-interrogate nodes and re-relay transactions.. then you will get to conect to 16-24 nodes as oppose to 8. and no need extra bandwidth and commands/sums playing around.

[gmaxwell]

firstly trying to get mempools synced is meant to be about if everyone has the same tx set before a pool mines a block, then all that needs to be sent as a confirmed block is the headers and list of txid's. thus reducing the data needed to be sent when a confirmed block is created.

Our work is not related to making "mempools synced", though they are naturally similar.

Our work is exclusively related to eliminating the massive overheads from relaying transactions the first time through as they go around the network.
 

to then suddenly need to grab hundreds of transactions from X and hundreds of tx from Y AGAIN

That doesn't happen in the Bitcoin protocol, no one has proposed for it to happen, and it isn't needed.

It's really a shame that people are forced to waste their time correcting you simply because you are so persistent and voluminous in your inaccuracies that you manage to confuse many people even though your posts are not very convincing.

i do find it funny that it was these very same devs that wanted a fee freemarket by removing a fee priority mechanism to make individualising mempools, that are now seeing the flaw in it..

Your statement here makes no sense.  Nodes prioritize transactions by feerate, none of that has been removed.  The only "individualizing" in practice is that a low memory host might reduce their mempool size. This is, in any case, totally unrelated to removing the relay inefficiencies.

but allowing nodes to relay tx's and drop them due to "fee free market" but then have to interrogate nodes to list their entire mempools(actually causing more bandwidth) and pick up the tx's AGAIN(more bandwidth again).. is silly..

Again, Bitcoin nodes don't interrogate nodes to list mempools nor pick up transactions again, no one has proposed they do, because there is no reason to do that.

Just pre-empting another confused tangent: There is a "mempool" p2p message which was added to the protocol by bitpay for the purpose of surveilling the network under a dishonest justification, which was later realized to be a privacy problem and the privacy leak was removed (and after that bitpay's staff recommended removing it from the protocol).  Bitcoin Core has no ability to send a mempool p2p request and never has had the ability to do so. It might be interesting to do so at initial startup to quick start the mempool and give miners something to mine after being offline for a while, but at the moment no one is working on that, AFAIK.

they all initially did get 1,2,3,4,a,b,c,d at initial relay..

The problem we are addressing is that if you have 100 peers, each of your hundred peers will advertise (or have advertised to them) each of those 8 transactions, using 100x the bandwidth on those advertisements as if you had only one peer.

the solution is much more simple.. get rid of the free market that lets nodes drop tx's in the initial relay. thus they would ALL have them all first go-around. without having to interrogate EACH connected node, after dropping.. because their would be no drop in the first place.

The need for nodes to potentially drop transactions has nothing to do with free market behaviour and everything to do with nodes not having infinite storage to keep the transactions.  But there is, again, no interrogation-- they don't need to go refetch them again.

X)now the first node has to ask the third node for the list.. 1,a,b,c,d (more data than initial relay)
y)now the first node has to ask the third node for the missing.. d (more data than initial relay)

You've misunderstood what we've accomplished here.

If at some point during the initial relay of transactions,  you receive from your other peers TX  A, B, C, D, E, F  and I get TX B, C, D, E, F In the historical Bitcoin protocol each of those 6 values would be sent across the link between us (potentially twice).

Instead, you could send me the single value X = A xor B xor C xor D xor E xor F,  or I could send you the single value Y = B xor C xor D xor E xor F.  

After the single value is exchanged whomever received it computes  X xor Y = A -- the missing transaction, even though neither of us knew in advance which transaction was missing.

Minisketch generalizes this to support any number of differences.  The data sent is exactly equal to the number of different values, regardless of how big the original sets are. (In fact, the first value in a minisketch is exactly what I described above: the xor of all the elements in your set).

So, if you have received in relay A, B, C, D ... X  and I have  already received B, C, D ... X, Y, Z;   Then I need send you only three values (or you me): The xor of all my values, the xor of all my values cubed, and the xor of all my values to the fifth power... and then you will know that I am missing A from you, and you are missing Y, Z from me.  And by doing this we send only three values on the link between us in the initial relay instead of 26 - 52 (depending on how much duplication there is from concurrent sends).

by getting rid of the "free market" and getting back to a consensus fee priority formulae/structure that everyone follows means

There has never been and can never been a "consensus priority formula", because priority by its very definition is external to consensus.  But the behaviour of existing nodes is consistent-- they keep and drop the same transactions, subject to having them in the first place, and subject to the restriction that anything configured to use less memory obviously can't keep as much.

to then not need to re-interrogate nodes and re-relay transactions.. then you will get to conect to 16-24 nodes as oppose to 8. and no need extra bandwidth and commands/sums playing around.

There is no re-interrogation, no-rerelay in Bitcoin, nor is any proposed.  It exists only in the imaginary protocol that you spend your days attacking and confusing people with.  The inefficiency in Bitcoin that we're working to resolve exists in the initial relay itself, and would still exists even if nodes had no mempools at all.

[El duderino_]

Hey gonna show of my HAT in here

WoW already few pages in here gonna read them tomorrow (try) so i hopefully gonna know how it all works as well.

Good job in here man

[jojo69]

holy shit

[Hueristic]

FUD

A shitload of troll corrections

W00ps, broke my rule again +sM, wish I had 50 to give you.

[VB1001]

My technical knowledge is not at the necessary level, for such a deep debate, but this type of answers are what encourage to study and learn more how Full Nodes work.

[El duderino_]

My technical knowledge is not at the necessary level, for such a deep debate, but this type of answers are what encourage to study and learn more how Full Nodes work.

@the very moment i’m best of with increasing stash and HODL haha
Have to read Some when i’m back home, cause forgot my laptop.... and just saw that last post by gmax, that shows me i only know like 2-5% or something
A thread like this is Brain coocking for me @the moment
Hope to learn much in here gonna do my best
Already thx for all your guy’s Effort in here

[franky1]

flip:

Our work is not related to making "mempools synced", though they are naturally similar.

flop:

subject to having them in the first place, and subject to the restriction that anything configured to use less memory obviously can't keep as much.

^ here you are saying "subject to" meaning you know nodes can configure settings and end up holding different data.
you try to hint everyone has consistant data and near same... but then say people can put restrictions and configure...

meaning this makes mempools not have same data and thus NEED data, thus need to check other peers nodes to see who has what to then get the data needed.

i know your meaningless tests just spin up 8 nodes and look for a pre minisketch stat and a post minisketch stat... but how about actually configure the 8 nodes to have different "restrictions" and "configurations" and then see the difference compared to your meaningless test of spinning 8 nodes of same config
after all its you that says there is no fixed consensus of config and no way you WANT there to be a config consensus that fixes everyone to using the same settings... so actually do some realistic tests where the configs of the 8 nodes are random and not the same if you really believe theres no way they can be the same

hint if node A has 1,2,3,4,5,7
hint if node B has 1,2,4,5,7,8
hint if node C has 2,3,5,6,7,8
your mini sketch wont have A just check(interrogate) B and then not have to bother with checking C.. because B does have 3. but doesnt have 6. so minisketch then needs to check C and realise it needs 6 from C
so mini sketch wont result in only needing to check just one node and that is the end of it. minisketch will still check other nodes too
flip:

Our work is exclusively related to eliminating the massive overheads from relaying transactions the first time through as they go around the network.

flop

to then suddenly need to grab hundreds of transactions from X and hundreds of tx from Y AGAIN

That doesn't happen in the Bitcoin protocol, no one has proposed for it to happen, and it isn't needed.

dont run tests under perfect circumstances of out of 8 nodes 7 nodes hold same data so one node only needs to check one node to complete and thats it. realise that all 8 nodes will have different tx's and so all 8 will still need to be checked.. remember you said it there isnt and cant be a consensus of all nodes accepting the same transactions blah

also think big picture about ALSO compact blocks and bloom filtering. imagine not just initial relay "exclusivity" of just a small data set of INV.. for initial relay, but also solving the wider issue of getting transactions that a mempool wont have if it were to get a compact block
.. what i am saying is with minisketch if indeed is less data than old methods.. try it against getting the best accumulation of mempool transactions so that compact blocks can actually be accomplished

or.. are you leaving that for 4 years time due to "conservative"
no wonder after 3 years things have not really progressed due to scaling. if you think a proposed feature should only be used for an exclusive purpose. and only has benefit on optimal conditions, which you only test it under.

try some out of box thinking

i will make one apology
i am sorry i dont kiss your ass or treat you as a king.
but you have plenty of ass kissers so maybe you do need someone thats not just gonna agree and accept what you offer as the ultimate solution.. even if the solution is for "exclusive use" in one small utility and only under certain use-case

eg "segwit solves malleability"...
nope it doesnt solve malleabillity.. it "exclusively" offers a non malleable tx format IF people only use this "exclusive" tx format, by which that "exclusive" tx format needs to avoid certain opcodes, or else people could malleate tx's that use the certain format

so i apologise for not just being an ass kisser, but an echo chamber of kissing, slurping and cheers does not help critical thinking

[gmaxwell]

Transaction relay and the mempool are mostly separate:

Here is a simplified flowchart:

 tx -> [would mempool accept?] -no--> [add to rejected tx list; drop]
                                                     -yes-> [copy transaction]  -[copy1]-> [relay pool] --> [offer to peers]
                                                     -[copy2]-> [store in mempool] -[confirm, pushed past limit, expire] -> [drop]


The mempool is only involved in tx relay by getting used as a filter: don't bother relaying anything onwards that you wouldn't mempool with the assumption that other nodes and miners mempools are largely similar to yours.

Mempools being different between peers doesn't result in redundant transaction broadcasts. No process actively tries to make mempools similar to each other because none is needed.  There is no need in the protocol for mempools to be consistent, so it doesn't try to make them consistent.  They are naturally pretty consistent on long running nodes, however, but if they weren't it would all continue to work fine. In particular, a transaction being dropped does not cause it to be requested over and over again from peers because transactions are only offered once (when they are newly accepted) and because the node remembers the txids it rejected and thus knows not to fetch them again if a second peer happens to offer them. Transactions are also rarely dropped because they failed to meet the minimum feerate because nodes explicitly tell their peers the minimum feerate they'll accept so only transactions meeting that threshold are offered.

Our work on minisketch aims to make the bolded part in that flowchart more efficient by making it possible for all your peers to offer you all the txn they learned and for you to offer all of them all that you learned while using bandwidth equal to what would be used if everyone magically knew what their peers hadn't heard of yet and only offered them what they hadn't heard of yet.

The above claims of "only testing on 8 nodes" are just whole cloth fabrication and don't make any sense... our work is validated, as is usual, with measurements on the real network (because duh), and with a topology simulator that simulates tens of thousands of nodes.

The poster above seems to have misunderstood the proposal as some effort to synchronize mempools and then believed it would waste capacity constantly resending a transaction when one node had a transaction and one of its peers had dropped the transaction.   Handling cases like peers with differently sized mepools would be a consideration if we were attempting to synchronize mempools, but we're not nor would we have a reason to do so.  Instead, we're synchronizing the list of transactions nodes would have announced to each other.... So if alice and bob are connected, and both would have told each other about TxA then no data needs to be sent for TxA.  In the existing protocol either Alice or Bob (or both) would transmit the existence of TxA to each other, which is a waste because they both already knew about it.

I think I've made more than a fair effort in correcting these misunderstandings. I hope someone else will pick up the torch before the posters persistence spreads the misunderstanding further and perhaps ultimately demoralizes the developers to the point where we give up on this completely uncompensated voluntary work improving the protocol.

[HairyMaclairy]

Thank you for your hard work gmax.  

Many of us do not have sufficient technical knowledge to systematically refute the points made by Franky - but we can recognize Bcash talking points when we see them.  

Trolls seek to divert precious resources (our time) by sending us on wild goose chases.  It is far easier and faster to talk shit than to refute it.  You are too kind when you refer to Franky’s deliberate misstatements as misunderstandings.

Having comprehensively demonstrated that Franky is not credible, we can all safely ignore his further comments without a need to continually show why he is wrong.

Mission accomplished.  

[franky1]

Transaction relay and the mempool are mostly separate:
Here is a simplified flowchart:

tx -> [mempool accept?] -no--> [add to rejected tx list; drop]

^ highlighting the flaw even at step 1

as i clarified in PM to not ramble on in this topic
my point was by having the ability to drop

when the peers interrogate each other(step 2) after dropping the tx.
the peer in "flowchart" will again request the same TX ,,,,, and then drop it (rinse and repeat)

then....
when a block comes along. that includes reference to the tx that the peer in flowchart keeps dropping. then the peer yet again asks other peers that same dang tx again because...
drum roll.....
its not in its mempool

which over all means the same tx keeps getting broadcast and dismissed more than once

all because a node is allowed to drop tx's due to silly things like customised relay limits

the solution:
is remove the "drop" for silly reasons like min relay
then the tx's are accepted.. and then everyone gets the tx at first go around. without repeats.
and without needing to retry again even after getting a compact block.. because
drum roll.....
the tx IS in the mempool.
thus allowing a block to be verified quick because the node RETAINS the tx
AND has not caused as much bandwidth usage because it hasnt dropped tx's to need to re pickup tx's

big picture:
the whole point of relaying unconfirmed transactions to everyone
the whole point of non mining nodes having a mempool
is to KEEP transactions so that when a compact block comes along nodes can verify it quickly without causing latency/propagation delays from asking for tx's.


by allowing "drop" and by saying its ok for peers to have different transaction sets.. is just saying its ok to make the network work harder by having nodes request data repeatedly.

the only time a tx should really be dropping a tx is if the signatures fail or the UTXO is spent.... not because of random user preference

so get rid of the user preference and then everyone gets to have a full mempool of tx's by default.. to then not cause latency issues at the compact block validation event and not cause bandwidth issues with re-grabs

P.S to HairyMaclairy
i am not even a Bcash guy.. so fail on you
but you much like most kiss asses do love to think if core dev gets poked. your sheep defense response is to folow a script
about bcash

you need to open your mind that if someone loves bitcoin. but finds a flaw or does not agree with how a dev is messing with bitcoin.. it might be because they person poking at a dev actually cares more about bitcoin than the dev does.

oh and if you want to believe that gmax is a poor guy, not making money.

ultimately demoralizes the developers to the point where we give up on this completely uncompensated voluntary work improving the protocol.

yep $101mill / 9 founders = more than a chicken nugget... so dont feel pity for him like he is a starving coder on his last penny only coding bitcoin out of love

sorry gmax. i know i playd some drum rolls. buy im not gonna play you a violin... seriously YOU playing the poor guy card!?

[bitserve]

Let's see if I have gotten this right... In simple words:

- Gmaxwell minisketch proposal is a way to reduce bandwidth usage by nodes during the relay of tx's. It does so by detecting which tx's are needed to be transmitted so that only those that are missing get transmitted to the other node. It is not part of the bitcoin consensus and fully optional so that it only gets used only between supporting pairs of nodes.

- Franky1 argues against the drop of some tx's by the nodes for not meeting the criteria of min relay fee which is a node operator configurable value. He thinks that nodes should not drop those tx's (only in case of signature mismatch or already spent/insufficient inputs). He also argues that if tx's were not dropped in first instance there would be no need for that "re-relay" of those missing tx's "over and over".

- It is not clear (to me) if that is what actually happens (the re-relay of those tx's repeated times) but from gmaxwell post it seems that it is not the case.

- 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.

So, if the above is correct... everything reduces to franky1 being against min relay which has nothing to do with gmaxwell proposal?

Sorry if I have stepped into this conversation without the necessary knowledge but, at this point, it has caught some of my attention and would like to know if I got it or not.

[bitserve]

eg "segwit solves malleability"...
nope it doesnt solve malleabillity.. it "exclusively" offers a non malleable tx format IF people only use this "exclusive" tx format, by which that "exclusive" tx format needs to avoid certain opcodes, or else people could malleate tx's that use the certain format

So it does indeed offer a valid solution to the malleability problem, doesn't it?

[franky1]

eg "segwit solves malleability"...
nope it doesnt solve malleabillity.. it "exclusively" offers a non malleable tx format IF people only use this "exclusive" tx format, by which that "exclusive" tx format needs to avoid certain opcodes, or else people could malleate tx's that use the certain format

So it does indeed offer a valid solution to the malleability problem, doesn't it?

it has not SOLVED malleation

the foolish thing is that its a anti-malleability option not solution.. its something that the payer has to choose to use.

if your a impending recipient of funds on the bitcoin network. waiting to be paid.. you obviously are not the one making the transaction. right..
so your not the one in a position to choose
your not the one that is able to say that its solved for you. because you dont know what the payer will do when paying you.

so you cant say to yourself things are solved and there is no need to worry about malleability..
a malicious person wanting to be malicious will use malleability against you and you cant stop them

imagine it this way, there is a gun crisis in a country.. instead of making a no gun law for the whole country. what happens is that authorities offer a voluntary no commitment cardboard box for people to put a gun in should they not want to use a gun

do you think gun lovers are going to choose to put down their gun by using the box?
are gun haters going to suddenly have a sigh of relief that there are no more guns?

[bitserve]

eg "segwit solves malleability"...
nope it doesnt solve malleabillity.. it "exclusively" offers a non malleable tx format IF people only use this "exclusive" tx format, by which that "exclusive" tx format needs to avoid certain opcodes, or else people could malleate tx's that use the certain format

So it does indeed offer a valid solution to the malleability problem, doesn't it?

it has not SOLVED malleation

the foolish thing is that its a anti-malleability option not solution.. its something that the payer has to choose to use.

if your a impending recipient of funds on the bitcoin network. waiting to be paid.. you obviously are not the one making the transaction. right..
so your not the one in a position to choose
your not the one that is able to say that its solved for you. because you dont know what the payer will do when paying you.

so you cant say to yourself things are solved and there is no need to worry about malleability..
a malicious person wanting to be malicious will use malleability against you and you cant stop them

imagine it this way, there is a gun crisis in a country.. instead of making a no gun law for the whole country. what happens is that authorities offer a voluntary no commitment cardboard box for people to put a gun in should they not want to use a gun

do you think gun lovers are going to choose to put down their gun by using the box?
are gun haters going to suddenly have a sigh of relief that there are no more guns?

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?

[Lannie25]

There plenty in the internet it you will browse it.
The one thing good about it is that it serves a secuirty to validate some transactions and blocks other nodes which is suspicious.

[franky1]

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.
....

Sorry if I have stepped into this conversation without the necessary knowledge but, at this point, it has caught some of my attention and would like to know if I got it or not.

im against features that get offered as solving big picture issues but end up not solving the big picture issues of what the initial feature intent is
but devs avoiding the obvious more simple way to solve an issue network wide for everyone

EG segwit. offered as solution to malleation.. result people still are victimised by malleation after segwit activation
because the victim is not part of the choice to choose to malleate or not of funds it gets/doesnt get.
EG funny part. after pretending malleation is solved. they introduce RBF to actually help malleators malleate

as for the tx transmission bandwidth and the compact block big picture surrounding a bandwidth concern
the big picture is transactions get sent around the network of non mining nodes so that nodes have a store of transactions ready for when a block is created the node has the transactions in mempool to quickly validate the block and not need to regrab transactions after the blocks arrives. to allow quick propagation of blocks.

the whole point of relaying transactions is to give nodes transactions
dropping them defeats the whole point of sending them in the first place.
thus making relaying transactions pointless if now devs think its ok to not keep transactions

if gmaxwell thinks dropping transactions is perfectly fine then why even bother sending transactions to non mining nodes.
save more bandwidth by only sending transactions to nodes that flag that they are pools, by having a mining flag for instance
(yes you will argue that will cause more propagation issues.. i will reply yes welcome to the issue as i was being reverse psychological to prove a point)

also when
nodeX gets a tx from a peerA and drops it. that does not mean the next peerB suddenly doesnt need to send the same tx to
nodeX. peer B will still see nodeX doesnt have the tx and WILL resend it... and nodeX will drop it again
peer C will still see nodeX doesnt have the tx and will send it... nodeX will drop it

its not fixing the big picture of getting nodes to keep transactions so that compact blocks can propagate quickly. as the whole point of relaying transactions to non mining nodes is to give them transactions they dont have.

and the minisketch doesnt solve the problem of having to get the same data from peer b, c.

yet by removing the drop for silly reasons. means when node X gets tx from A.. it wont need to get it from B, C .. and wont need to get it after a block is solved... because.. big picture. it would already have it

oh, and if peer B,C doesnt have the tx to give. peer B,C wont get it from nodeX because node X didnt keep it so peer B and C will then be going through the same process of using bandwidth to try getting it from other peers

if everyone just kept to a same rule of only drop invalid transactions. everyone would all keep the same valid transactions without having to re send transactions or interrogate peers or re grab after compact block arrives.

and yes i can pre-empt the next empty argument
some fool will argue that peer A sent it at initial relay so now its peer Bs problem.. guess what
when a block is solved. guess who nodeX is going to ask again... yep. nodeA
and guess what nodeA will do. nodeA will resend it

some fool will argue that my concern only amounts to maybe 1 tx now and then..
nope if a node is saying drop transactions under 1000sat fee. there will be more than 1 tx now and again involved

devs always know of flaws, but instead of SOLVING the big picture they just OFFER flimsy, reduce the chances of flaw but not remove it

think about it
devs say this minisketch under their default setting tests shows a reduction of bandwidth to then allow a node that usually connects to 8 nodes could connect to 16-24 nodes (2-3x reduction) but thats not 7x reduction to allow 56 nodes.

and because settings are configurable around drops. if they ran tests using variable settings instead of just spinning up 8 nodes using defaults. the reduction would be LESS than 2-3x

and ontop of that. nodes still end up grabbing data after a compact block. meaning although they grabbed a tx severals times from peers at initial relay. they still grab again at block receipt. causing block propagation delays

where as removing configurable settings for silly reasons would actually give a better bandwidth reduction and make compact blocks not need to trigger as much bandwidth for the same dang tx's

and an outside the box thought. if they actually removed the drop for silly reasons and put in a fee priority formulae that al nodes utilitise so that there still remains control over spammy dust. a fee formulae can actually make spammers pay more for sending spammy dust without it affecting everyone fees at block confirm.

but nah.. devs just wanna OFFER flimsy stuff.. and not SOLVE the big picture

[franky1]

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

[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

[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.

[hv_]

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

I respect your patience. I ve already given up at the point where ppl believe a full node does not mine...

Anyway the LN buddy group is very limited and behaves like a gold - cult. It cannot grow very big as u can show with baby maths. So let them play, they wont listen a sec.

[franky1]

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

finally someone that wants to keep the topic on track
..
im a realist. so lets also look at the negative to atleast put things into prospective to have a fair balance

if you discount all the sybil nodes running on amazon, hertzner,digital ocean, ovh (>35%)
you will find the 35% of 99.9% uptime taken away. will make that 20 hour average far worse

[franky1]

Anyway the LN buddy group is very limited and behaves like a gold - cult. It cannot grow very big as u can show with baby maths. So let them play, they wont listen a sec.

problem with the gold-cult of the 18th century who made profit from vaulting up gold.. is that them small groups took gold from people and the gold cultists became the banks of 21st century.

LN is the same business plan as 18th century, "dont play with gold its too 'weighted' play with co-managed accounts an unaudited promissory notes for convenience...

i still laugh at the 2016 LNconcept:18th century banks "dont worry all promissory notes ar 100% backed by gold"
i still laugh at the 2018 LNfactory:20th century banks "dont worry bank notes are convenient even if you cant get gold out easily"


the funny part is all these unicorns promoting LN buddy group(behaving LIKE gold-cult).. are people that wont be the actual factory CEO(bank owners) that become the actual "gold-cult"
the real bank owner "gold-cult" would be coinbase, blockstream, circle.. all subsidiaries of DCG.CO
they just think if they kiss blockstream ass, then they will get hired by the real playa's

[VB1001]

Results for December 2018 / How Many Full Nodes Bitcoin Online ?

[Gary Levanevskii]

I once used a full node. I think it would be a good thing to use the full node again. I think I’ll do it soon.

[VB1001]

Happy Birthday 10th Bitcoin, 3/Jan/2019

Genesis Block 03/Jan/2009

Hash:

04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f

CoinBase
04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f7 2206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73
(decodificado) ��
EThe Times 03/Jan/2009 Chancellor on brink of second bailout for banks

https://www.blockchain.com/btc/tx/4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b

"The Times 03/Jan/2009 Chancellor on brink of second bailout for banks."




The Times 03/Jan/2019 Bitmex, 10th anniversary of Bitcoin, "ThanksSatoshi" is included in the Coinbase input.



Hash:

000000000000000000037e741045a99121918e6ee717108fc77ec40b7419a829

CoinBase
030d7608040b771a5c2f205468616e6b735361746f736869202f4254432e434f4d2ffabe6d6d2ce fdddb4341345a5f494751a87e59567f4ddc88488dfff0df7bfc7cf57c0f22010000000000000042 14622919ba000000000000
(decode)? v? w? \ / ThanksSatoshi /BTC.COM/ mm , CA4Z_IGQ ~YV?M ܈ H { | |?? B? b)?

https://www.blockchain.com/btc/tx/bd9d5c05d4f5e7256160f27a55678c3b8f0c38914c20c471b87832f46576c9a1?show_adv=true

https://twitter.com/BitMEXResearch/status/1080590401323450368

[VB1001]

Lightning Network Graphics







https://twitter.com/richardchen39/status/1080988170471247872

Real Time Lightning Network Statistics

https://1ml.com/statistics

[franky1]

seeing as topic creator has meandered into the depths of LN.
and to conclude my point about LN's issues with bitcoin

especially with the "proof of keys" initiative. (people should care more about 100% ownership than no/co-controlled convenience)

(numbers are loose pencil calculated back of the envelope of bytes that go into the 1mb base)(i didnt count witness as they dont apply to the tx count limit)
(being very economical(i rounded down bytes) to prevent the fluffy pony crowd arguments)

5k nodes, 18k channels = ~3.6 channels per node

to continue, open the ~4 channels lets call that 330bytes 1 in 4 out
close channels 4 in 8 out lts call that 670bytes

so lets call each user 1000bytes per open and close (being very economical with numbers)

so each block is the equivalent of 1000 users data requirement for LN overall (if no one else uses the bitcoin network for pure bitcoin network usage)
you would thing, wow thats great 144,000 users a day (if no one else uses the bitcoin network for pure bitcoin network usage)
you would think, wow great thats 8million users wanting 2 months lockin. (if no one else uses the bitcoin network for pure bitcoin network usage)

but no

thats means if 8 million users all opened. realise they made a mistake and closed on same day. it would take 2 months to sort out the bottleneck(if no one else uses the bitcoin network for pure bitcoin network usage)

lets word it another way 144,000 users can enter and leave LN each day (if no one else uses the bitcoin network for pure bitcoin network usage)

see why the bitcoin network needs scaling even if LN is used

silly people think the solution to this is just to force people to not be allowed to lock funds up for 1 day. and instead mandate people lock funds up for 2weeks-2months
silly people think the solution to this is just to force people use factories to not be allowed to unlock funds and instead reopen offchain mandate people never to unlock funds unless they pay a factory a large fee

[VB1001]

Bitrefill LN

With Thor, users can purchase an empty channel (potentially also for their friends or business partners) with crypto. Users don’t need to put up any money in the payment channel themselves, while Bitrefill maintains the channel, funded on their end for 30 days. As such, you can immediately start accepting payments through Bitrefill’s channel to you.

https://bitcoinmagazine.com/articles/bitrefill-channel-opening-service-makes-accepting-lightning-payments-easy/

[franky1]

Bitrefill LN

With Thor, users can purchase an empty channel (potentially also for their friends or business partners) with crypto. Users don’t need to put up any money in the payment channel themselves, while Bitrefill maintains the channel, funded on their end for 30 days. As such, you can immediately start accepting payments through Bitrefill’s channel to you.

https://bitcoinmagazine.com/articles/bitrefill-channel-opening-service-makes-accepting-lightning-payments-easy/

yep key words "purchase".. "users dont put payment in themselves"

imagine bitreill as a factory
imagine bitreill as fortknox
people give 0.10000000btc to bitrefill (8 decimal bitcoins). these get locked under bitrefills control

bitrefil then opens a channel for 30 days and puts its own(unconfirmed/unaudited) 12 decimal tx into it. which because its not broadcastable onchain (bitcoin network will reject 12 decimal). bitrefil are happy to say user gets 0.100000000000. as at the 30th day it going to be bitrefil that gets to close the channel and aggregate the value. as they are the controller of funding

what then happens is bitrefil charge the user to get back the real 8 decimal BTC via the user paying the onchain fee and a exit LN fee... or for no/low price they can renew a new channel

much like how banks handled gold a couple centuries ago with the 'golds too expensive to unvault. how about take these silver coins(atomic swap for LTC) or just reopen a bank account and get new crisp unaudited bank notes(12 decimal unconfirmed tx value in channel)

[VB1001]

Utreexo, sync Bitcoin Straight From Your Phone

Simply put, it addresses what is known as the UTXO set, or the code that gives information on whether a bitcoin has been spent.

Source > https://www.coindesk.com/this-scaling-tech-could-let-you-sync-bitcoin-straight-from-your-phone

[Artemis3]

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

When someone resorts to personal attacks, it means he or she is out of arguments, and resorts to this in desperation for having lost the debate.

[franky1]

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

When someone resorts to personal attacks, it means he or she is out of arguments, and resorts to this in desperation for having lost the debate.

oh look more poking the bear.. ill bite, yet again..
but before i begin. i did try avoiding the pokes of the bear for the hypocritical point of what is wrote above in regards to ad-hom. where i tried to avoid derailing into persona comments unrelated to bitcoin full node issues.
but seeing as more than one person wants a response. ill give it.

i make points about how core devs are doing things that are taking people off the network. bitcoin is not some AI that self codes. yes i mention devs by name such as wuille lukeJr and gmax
that is not ad-hom. that is highlighting who is involved

i have never made a comment about gmaxwell personal attributes that had nothing to do with the topic. EG i do not meander into attacks about his beard or the way he walks down a sidewalk.

instead i talk about bitcoin issues caused by devs. and yes its those devs that cause issues should be mentioned.
the funny part is how instead of understanding the content of the issues such as how their code has got negative impact. they want to meander the topic into appearing as if its a personal attack.
they keep writing code. but then pretend to be powerless janitors that cant code. they themselves play the ad-hom game by changing bitcoin but whenever anyone highlights the changes. suddenly the commenter must be some personal attacker.

the buzzwords "ad-hom" is an old and repeated strategy the core devs keep falling back on as their way to avoid answering why they are coding what they code.
the funny part though is if you done a word count on insulting/vulgar words. you will find those who are in core friendly group are the ones that do more 'attacks'. but i do not care about their vulgar meanders. i just continue to highlight the issues about bitcoin. and let them circle their out-dated tactics of avoiding listening to the community.

sorry but devs are not the victims here. greg got well paid to stifle bitcoin between 2015-2017 and has enough income to live happily because of it.
if you think greg is not involved in a "roadmap". well here is the advert naming it
https://bitcoin.org/en/bitcoin-core/capacity-increases
and here is the roadmap itself. note the creator at the top
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html
what bitcoin has become is a network where:
if it doesnt follow cores roadmap, opposers are deemed not as a counter option. but as an attacker that needs to disappear.
devs prefer to have less people using the network
devs do not want bitcoin to be a unique success, as they are happy to program other networks and promote other networks and even promote their involvement of pushing counter options off the network

note. the false promotion
"been working on scalability for several years" (that was wrote in 2015 meaning they have ben scaling for years prior)
yet. satoshi in 2010 mentioned the 7tx/s number and so yea 2018-19 i questioned gmax about his "working on scaling BITCOINS SYSTEM" to show m one single day that out paces numbers known about since 2010, to show that scaling is actually occurring

oh and a further point about when Gmax shot himself in the foot with the example block of 12k+ Tx's before segwit. i knew about that in 2015. and do you know why i excluded it from the main conversation. because that block contains no signatures and as such, as a true full validating node. bypassing that block and auto passing it as good, without validating signatures. is a security risk.

do you think its good security for nodes to just pass blocks around without signatures and just treat the data as passable.. can you even try to consider the auditing/security risks. without diverting the topic to sound like it must be ok because you trust the devs that allow nodes to accept such a unvalidated set of tx

[VB1001]

I understand the different opinions in the debate and it is good that readers see all the technical points, but it is also interesting to continue informing about the state of the network of nodes and how important it is for Bitcoin.

Bitcoin (BTC) Network Nodes Grow Up Over 10,000 After Difficult Times in 2018

The number of reachable nodes was 10214 with the largest number of them located in the United States. The U.S. accounts for 24.37% of the total of Bitcoin nodes around the world, equal to 2491. The U.S. is followed by Germany with 1949 reachable nodes (19.06%). France was located in the third place with 677 nodes or 6.62% of the total number of nodes around the world. The top 10 places include the Netherlands, China, Canada, the United Kingdom, Singapore, Russia and Japan.

Source >https://bitcoinexchangeguide.com/bitcoin-btc-network-nodes-grow-up-over-10000-after-difficult-times-in-2018/

I sincerely appreciate the participation of everyone in this thread of Full Nodes.

[VB1001]

Two very interesting articles.

- The first Taproot:

Taproot Is Coming: What It Is, and How It Will Benefit Bitcoin

https://bitcoinmagazine.com/articles/taproot-coming-what-it-and-how-it-will-benefit-bitcoin/

- The second Graftroot:

How Delegating Signatures Allows for Near-Infinite Spending Variations

https://bitcoinmagazine.com/articles/graftroot-how-delegating-signatures-allows-near-infinite-spending-variations/

In both articles there are direct links to the original proposals of the developers.

[Last of the V8s]

https://twitter.com/lopp/status/1104088607000854528
I ran this survey about operating Bitcoin nodes 3 years ago; please fill it out if you have a moment so that we can see if sentiments have changed!
https://docs.google.com/forms/d/e/1FAIpQLScOopaaULcpVe0boWHKrvrP0XIj_G6ZodLrv73jO3HQDVfpQA/viewform

-might be interesting

[VB1001]

^
A very complete poll, It is very well made and the result in the impeccable presentation.
 
Cypherpunk movement UP

Thx.

[VB1001]

Lightning Network Reaches Milestone 5m Capacity

Network nodes now number 7773, an increase of 11 percent versus one month ago, while the number of channels has reached 39,126,
24 percent more than at the start of March.

https://bitcoinist.com/bitcoin-lightning-network-reaches-milestone-5m-capacity/

[VB1001]

"Research: 60% of All Bitcoin Full-Nodes Are Still Vulnerable to Inflation Bug"

According to bitcoin (BTC) node stats reported on the website of bitcoin core developer Luke Dashjr, 60.22% of the coin’s full-nodes are running software still vulnerable to the inflation bug at press time.

https://cointelegraph.com/news/research-60-of-all-bitcoin-full-nodes-are-still-vulnerable-to-inflation-bug

If what you say is true, you must update all the nodes.

My Full Node is already updated 0.18.0

[VB1001]

HTC to Launch EXODUS 1s, Smartphone With Full Node Capacity

The phone can support the pruned version at all times, but the use of the full blockchain will require an additional SD card.
Additionally, it is recommended that users only run a node off of a stable Wi-Fi connection due to the large data requirements and have a way to recharge the phone on hand.

https://bitcoinmagazine.com/articles/htc-launch-exodus-1s-smartphone-full-node-capacity/

Nice news.

[VB1001]

^
I'm still using my full node 24/7

But I like to report the news presented by the companies and more when it comes to the possibility of installing a complete node in a phone.

The people of the street are the ones who will take us to the massive adoption with news like this, presenting their product to the public with Bitcoin for their promotion in the market.

I would like to see news like this every day.

People who are not part of Bitcointalk or the virtual currency forums do not want, nor are they interested in how to manage a full node with their wallet, they want to send and receive BTC in an application on their phone without complications.

We already know that this does not work like that and then the claims will come...

I would not buy the phone either.

About the code I found this:

The phone also comes with a built-in hardware wallet, known as the Zion Vault. First introduced with the Exodus 1 earlier this year, the Zion Vault stores cryptocurrency keys in a trusted execution environment, allowing users to easily own and spend cryptocurrencies without exposing them to malicious applications.

The Exodus 1s will take the vault a step further, releasing a software development kit (SDK for the Zion Vault. The new toolkit will allow developers to explore integrating cryptocurrencies and the smartphone with third-party apps. “We understand it takes a community to ensure strength and security,” HTC said in the announcement, “so it’s important to the EXODUS team that our community have the best tools available to them.”

https://cryptobriefing.com/htc-phone-bitcoin-full-node/

[franky1]

most phone based 'full nodes' are not full nodes.

firstly by default they hold a pre installed blockchain (defeats purpose of decentralised syncing)
(also risk of man in middle malware preinstalled)

secondly, if prunned the 'node' no longer becomes a seed for other nodes to leach from thus losing 'full' ability of aiding the network

thirdly some of these apps dont ip link to random other full nodes but API call known/named nodes of the phone software(their own special dns)

fourthly although 5g has the speed to relay current data propagation fast. the line rental plans of cell phones become a hindrence

this is why full nodes should be for landline/computers... and litewallets for cell phone. after all a cellphone would overheat/break quick if used as a 24/7 piece of equipment thats always charged and in use.
trying to make bitcoin go backwards by making it attempt to run on any device including a glorified calculator, does not help the network

[VB1001]

"Maxwell, Wuille Co-Author Proposal for a Big Boost to Bitcoin’s Bandwidth"

Called Erlay, the proposed protocol alters the way transactions are relayed so that they use significantly less bandwidth, an important resource for the nodes that make up the network. The authors include The University of British Columbia researcher Gleb Naumenko as well as two bitcoin development heavy-weights: Greg Maxwell and Pieter Wuille.

https://www.coindesk.com/maxwell-wuille-co-author-proposal-for-a-big-boost-to-bitcoins-bandwidth

A little more information about this:

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016994.html

https://arxiv.org/abs/1905.10518

[franky1]

"Maxwell, Wuille Co-Author Proposal for a Big Boost to Bitcoin’s Bandwidth"

i had a discussion with gmax about minisketch utility a while back
he was wanting to use minisketch just for the compact block part of network protocol once a block was confirmed. the funny point i was trying to make him realise was, why are nodes foolishly ignoring transactions at the initial transaction relay to even need to mini sketch at blockheader propagation.

seems it took him long enough to cotton on to sort out the initial transaction relay part

gotta find it funny how theres lines of code to ignore transactions using min fee and min dust at initial tx relay. then more code to analyse whats missing and grab them same tx's later