Bitcoin Forum
July 17, 2019, 07:38:00 AM *
News: Latest Bitcoin Core release: 0.18.0 [Torrent] (New!)
 
   Home   Help Search Login Register More  
Poll
Question: You have an Active Node Full Time ?
24/7 - 20 (39.2%)
12/7 - 1 (2%)
A few hours a day - 4 (7.8%)
Never - 10 (19.6%)
In the future maybe - 10 (19.6%)
It is not of your interest - 6 (11.8%)
Total Voters: 51

Pages: « 1 2 3 [4] 5 6 7 »  All
  Print  
Author Topic: How Many Full Nodes Bitcoin Online ?  (Read 15709 times)
franky1
Legendary
*
Offline Offline

Activity: 2450
Merit: 1451



View Profile
December 21, 2018, 06:26:22 PM
Last edit: December 21, 2018, 08:00:39 PM by franky1
Merited by vapourminer (1), bones261 (1), VB1001 (1)
 #61

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'

I DO NOT TRADE OR ACT AS ESCROW ON THIS FORUM EVER.
Please do your own research & respect what is written here as both opinion & information gleaned from experience. many people replying with insults but no on-topic content substance, automatically are 'facepalmed' and yawned at
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1563349080
Hero Member
*
Offline Offline

Posts: 1563349080

View Profile Personal Message (Offline)

Ignore
1563349080
Reply with quote  #2

1563349080
Report to moderator
1563349080
Hero Member
*
Offline Offline

Posts: 1563349080

View Profile Personal Message (Offline)

Ignore
1563349080
Reply with quote  #2

1563349080
Report to moderator
VB1001
Sr. Member
****
Offline Offline

Activity: 294
Merit: 695


"Four Wheel Drive"


View Profile
December 22, 2018, 08:57:19 AM
 #62

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

1PCm7LqVkhj4xRpKNyyEeekwhc1mzK52cT
franky1
Legendary
*
Offline Offline

Activity: 2450
Merit: 1451



View Profile
December 22, 2018, 07:57:30 PM
Last edit: December 22, 2018, 09:31:52 PM by franky1
 #63

^
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"

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

Activity: 546
Merit: 2434

There are lies, damned lies and statistics. MTwain


View Profile WWW
December 25, 2018, 07:25:33 PM
 #64

<...>
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
Sr. Member
****
Offline Offline

Activity: 294
Merit: 695


"Four Wheel Drive"


View Profile
December 27, 2018, 09:37:07 AM
 #65

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/

1PCm7LqVkhj4xRpKNyyEeekwhc1mzK52cT
franky1
Legendary
*
Offline Offline

Activity: 2450
Merit: 1451



View Profile
December 27, 2018, 11:36:25 AM
Last edit: December 27, 2018, 03:23:58 PM by franky1
 #66

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

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

Activity: 2772
Merit: 2333



View Profile
December 27, 2018, 09:45:21 PM
Last edit: December 27, 2018, 09:58:22 PM by gmaxwell
Merited by Hueristic (1), infofront (1), bones261 (1), bitserve (1), VB1001 (1)
 #67

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

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

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

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

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

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

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

Quote
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.
micgoossens
Hero Member
*****
Online Online

Activity: 756
Merit: 2321


BTFD, on to 15K a coin !!!!


View Profile
December 28, 2018, 12:15:40 AM
 #68

Hey gonna show of my HAT in here Cheesy

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

XhomerX10 designed my nice avatar HATs!!!!!  Thanks Bro
jojo69
Legendary
*
Offline Offline

Activity: 1442
Merit: 1795


no FOMO


View Profile
December 28, 2018, 01:03:03 AM
 #69

holy shit

This is not some pseudoeconomic post-modern Libertarian cult, it's an un-led, crowd-sourced mega startup organized around mutual self-interest where problems, whether of the theoretical or purely practical variety, are treated as temporary and, ultimately, solvable.
Censorship of e-gold was easy. Censorship of Bitcoin will be… entertaining.
Hueristic
Legendary
*
Offline Offline

Activity: 2058
Merit: 1215


Doomed to see the future and unable to prevent it


View Profile
December 28, 2018, 03:30:11 AM
 #70


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

VB1001
Sr. Member
****
Offline Offline

Activity: 294
Merit: 695


"Four Wheel Drive"


View Profile
December 28, 2018, 08:04:28 AM
 #71

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.

1PCm7LqVkhj4xRpKNyyEeekwhc1mzK52cT
micgoossens
Hero Member
*****
Online Online

Activity: 756
Merit: 2321


BTFD, on to 15K a coin !!!!


View Profile
December 28, 2018, 09:42:22 AM
Merited by VB1001 (1)
 #72

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 Roll Eyes
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

XhomerX10 designed my nice avatar HATs!!!!!  Thanks Bro
franky1
Legendary
*
Offline Offline

Activity: 2450
Merit: 1451



View Profile
December 28, 2018, 04:02:26 PM
Last edit: December 28, 2018, 04:46:48 PM by franky1
Merited by infofront (1)
 #73

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

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

Activity: 2772
Merit: 2333



View Profile
December 28, 2018, 10:14:00 PM
Last edit: December 29, 2018, 04:29:32 AM by gmaxwell
Merited by HairyMaclairy (5)
 #74

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

Activity: 896
Merit: 1447


Degenerate bull hatter & Bitcoin monotheist


View Profile
December 28, 2018, 11:32:24 PM
Last edit: December 28, 2018, 11:45:09 PM by HairyMaclairy
 #75

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

Activity: 2450
Merit: 1451



View Profile
December 29, 2018, 03:56:45 AM
Last edit: December 29, 2018, 04:31:48 AM by franky1
 #76

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!?

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

Activity: 896
Merit: 763


HODL.


View Profile
December 29, 2018, 09:27:02 AM
 #77

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.

19VBmRQVqrtNTGiwngZutwREagcKxJgVZM
bitserve
Hero Member
*****
Offline Offline

Activity: 896
Merit: 763


HODL.


View Profile
December 29, 2018, 09:49:26 AM
 #78


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?

19VBmRQVqrtNTGiwngZutwREagcKxJgVZM
franky1
Legendary
*
Offline Offline

Activity: 2450
Merit: 1451



View Profile
December 29, 2018, 12:43:57 PM
 #79


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?

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

Activity: 896
Merit: 763


HODL.


View Profile
December 29, 2018, 01:04:52 PM
 #80


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?

19VBmRQVqrtNTGiwngZutwREagcKxJgVZM
Pages: « 1 2 3 [4] 5 6 7 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!