Bitcoin 20MB Fork - page 43. | Bitcointalksearch.org

onemorebtc

sr. member

Activity: 266

Merit: 250

Quote from: inBitweTrust on February 19, 2015, 11:06:40 PM

Quote from: onemorebtc on February 19, 2015, 10:51:34 PM

i would very much like any idea to add incentives to run a node - for validating and submitting transactions and distributing old transactions or blocks.

Article discussing some of the problems and how not all nodes are alike:

https://medium.com/@lopp/bitcoin-nodes-how-many-is-enough-9b8e8f6fd2cf

Some various ideas-

1) Peter Todds Tree Chains may include ways to encourage decentralization
2) Justus Ranvier method of adding price discovery - http://bitcoinism.liberty.me/2015/02/09/economic-fallacies-and-the-block-size-limit-part-2-price-discovery/
3) TBF - https://getaddr.bitnodes.io/nodes/incentive/ to pay nodes directly can be done on a larger scale
4) Multi-use VPS's could be created that were discounted or free and run full nodes for profit or non profit
5) 0.11 Prune node feature will add a different type of "full" node to secure the network
6) further optimizations within core to make nodes more inexpensive to run and operate(most of the cost is not disk space but bandwidth)

Anyone else is free to contribute more to this list.

i want add: tell people its important!
as i said: even if know what p2p means i never bothered to check because bitcoin seems so strong. the incentive program was a friendly reminder that it would be a good idea to run one

inBitweTrust

hero member

Activity: 658

Merit: 501

Quote from: onemorebtc on February 19, 2015, 10:51:34 PM

i would very much like any idea to add incentives to run a node - for validating and submitting transactions and distributing old transactions or blocks.

Article discussing some of the problems and how not all nodes are alike:

https://medium.com/@lopp/bitcoin-nodes-how-many-is-enough-9b8e8f6fd2cf

Some various ideas-

1) Peter Todds Tree Chains may include ways to encourage decentralization
2) Justus Ranvier method of adding price discovery - http://bitcoinism.liberty.me/2015/02/09/economic-fallacies-and-the-block-size-limit-part-2-price-discovery/
3) TBF - https://getaddr.bitnodes.io/nodes/incentive/ to pay nodes directly can be done on a larger scale
4) Multi-use VPS's could be created that were discounted or free and run full nodes for profit or non profit
5) 0.11 Prune node feature will add a different type of "full" node to secure the network
6) further optimizations within core to make nodes more inexpensive to run and operate(most of the cost is not disk space but bandwidth)

Anyone else is free to contribute more to this list.

onemorebtc

sr. member

Activity: 266

Merit: 250

Quote from: inBitweTrust on February 19, 2015, 10:47:20 PM

Quote from: onemorebtc on February 19, 2015, 10:39:18 PM

true, what is your opinion about letting the node owner decide which percentage he wants to share?

Yes, I think we should have a mix of full archival nodes, DHT sharded nodes where the owner decides the percentage of the whole blockchain they want to download and share, and full pruned nodes, and SPV clients.

Quote from: onemorebtc on February 19, 2015, 10:39:18 PM

with a decentralized opensource system like bitcoin its just not possible to force anything about the user.

e.g. if my server could not save the share bitcoin-core wants to save/distribute there are only two possibilities for me: stop my node or change the code to the size which works for me

We cannot and should not force users to do anything, but can always build in incentives outside or within bitcoin core that increase node count and distribution. Some have already been discussed and some not.

so we both have reached consensus...
atm bitcoin foundation has a reward program for nodes (which is the reason i started mine - not to profit: i just realized they are needed atm, and i dont have a problem running it for the next years)

i would very much like any idea to add incentives to run a node - for validating and submitting transactions and distributing old transactions or blocks.

inBitweTrust

hero member

Activity: 658

Merit: 501

Quote from: onemorebtc on February 19, 2015, 10:39:18 PM

true, what is your opinion about letting the node owner decide which percentage he wants to share?

Yes, I think we should have a mix of full archival nodes, DHT sharded nodes where the owner decides the percentage of the whole blockchain they want to download and share, and full pruned nodes, and SPV clients.

Quote from: onemorebtc on February 19, 2015, 10:39:18 PM

with a decentralized opensource system like bitcoin its just not possible to force anything about the user.

e.g. if my server could not save the share bitcoin-core wants to save/distribute there are only two possibilities for me: stop my node or change the code to the size which works for me

We cannot and should not force users to do anything, but can always build in incentives outside or within bitcoin core that increase node count and distribution. Some have already been discussed and some not.

onemorebtc

sr. member

Activity: 266

Merit: 250

Quote from: inBitweTrust on February 19, 2015, 10:32:35 PM

Quote from: onemorebtc on February 19, 2015, 10:22:13 PM

IMHO: more decentralization is not possible with bigger blocksizes except you would accept that not every node keeps everything.

I believe there are solutions to increase decentralization and security with larger blocks, and before we discuss those options in detail we should first address how much decentralization is needed for nodes.

The scale goes from every user having a full unpruned node on all the time to no decentralization at all and a single database. We currently have ~6,400 live nodes on average for 3-5 million BTC users. Thus 1 node per 468 to 781 users.
what ratio and other considerations(I.E.. ASN distribution) should we aim for?

Personally, the concern for full node centralization is valid but not nearly as much as the security vulnerabilities we have from mining centralization where we essentially have a 4 of 7 multisig between the largest pools.

We need to tackle both issues however.

true, what is your opinion about letting the node owner decide which percentage he wants to share?

a good distribution about all asn's would be obviously a better alternative - with a decentralized opensource system like bitcoin its just not possible to force anything about the user.

e.g. if my server could not save the share bitcoin-core wants to save/distribute there are only two possibilities for me: stop my node or change the code to the size which works for me

inBitweTrust

hero member

Activity: 658

Merit: 501

Quote from: onemorebtc on February 19, 2015, 10:22:13 PM

IMHO: more decentralization is not possible with bigger blocksizes except you would accept that not every node keeps everything.

I believe there are solutions to increase decentralization and security with larger blocks, and before we discuss those options in detail we should first address how much decentralization is needed for nodes.

The scale goes from every user having a full unpruned node on all the time to no decentralization at all and a single database. We currently have ~6,400 live nodes on average for 3-5 million BTC users. Thus 1 node per 468 to 781 users.
what ratio and other considerations(I.E.. ASN distribution) should we aim for?

Personally, the concern for full node centralization is valid but not nearly as much as the security vulnerabilities we have from mining centralization where we essentially have a 4 of 7 multisig between the largest pools.

We need to tackle both issues however.

onemorebtc

sr. member

Activity: 266

Merit: 250

Quote from: inBitweTrust on February 19, 2015, 10:19:25 PM

Quote from: onemorebtc on February 19, 2015, 10:09:13 PM

i still dont see why this lowers security as you claimed (you said this would raise node count - i think this too, and this would actually increase security a little). it adds complexity but there is always a tradeoff to make.

I am not claiming security will decrease with the fork. I am merely suggesting the ones against this hardfork have fears that aren't completely illusory, and we might see more centralization as they fear due to the costs (mainly bandwidth) being too high to support full unpruned nodes.

I am just suggesting that we can take steps or possibly incorporate other changes to address these fears and add more decentralization at the same time we increase block size conservatively. We need to be more specific however of what degree of decentralization and security is appropriate. I haven't heard many details as of yet of what we should be aiming before besides mostly vague fears and opposition to change.

IMHO: more decentralization is not possible with bigger blocksizes except you would accept that not every node keeps everything.

i guess i misunderstood you then.

inBitweTrust

hero member

Activity: 658

Merit: 501

Quote from: onemorebtc on February 19, 2015, 10:09:13 PM

i still dont see why this lowers security as you claimed (you said this would raise node count - i think this too, and this would actually increase security a little). it adds complexity but there is always a tradeoff to make.

I am not claiming security will decrease with the fork. I am merely suggesting the ones against this hardfork have fears that aren't completely illusory, and we might see more centralization as they fear due to the costs (mainly bandwidth) being too high to support full unpruned nodes.

I am just suggesting that we can take steps or possibly incorporate other changes to address these fears and add more decentralization at the same time we increase block size conservatively. We need to be more specific however of what degree of decentralization and security is appropriate. I haven't heard many details as of yet of what we should be aiming for besides mostly vague fears and opposition to change in general.

onemorebtc

sr. member

Activity: 266

Merit: 250

Quote from: inBitweTrust on February 19, 2015, 09:37:37 PM

Quote from: onemorebtc on February 19, 2015, 09:23:57 PM

that still doesnt answer my question.
may i ask why it is not enough to secure the blockchain that way?

i assume that all miners already have full blockchains and we are only talking about new nodes (old nodes already have/had the full copy and therefor a validated utxo)

new nodes would still connect to running nodes - they just wont deliever all old transactions. blockheight, headers and pow is still all the same.

i fail to see a way how a new node could be tricked or has lower security if all old transactions are obtained in a different (even centralized) way

Downloading the whole blockchain from a single torrent or source is fine if it is verified with other unpruned full nodes .
What is mainly being discussed here is either:

1) Many pruned full nodes of ~1GB in size boostrapping and creating a verified UTXO from a combination of archival full nodes which are unpruned (how many of these should be sufficient is the question)

2) Many pruned full nodes of ~1GB in size + another 1-5% of a redundantly sharded blockchain using DHT on each node verifying each other
or
3) Combination of the above

0.11 will likely include the feature to create full pruned nodes and is expected to come out in approx. 6 months so you will now see 3 types of clients in the future-

SPV clients
Full pruned nodes with verified UTXO that are around 1GB in size
Full nodes with the whole unpruned blockchain

Thus the conversation will shift from increasing the current amount of full nodes from 6400 back to 10k , to focusing on this and talking about how many Full pruned nodes we want out in the ecosystem as well to secure the network.

I would like to hear what degree of security and decentralization the people against this hardfork would like so we could both work towards a common objective.

i do understand that we are talking about putting transactions (not blocks) on dht.

it seems archival nodes are the same as a raw centralized download (at least comparable)?
thats why i asked if it is still verifiable and trustless if transactions are downloaded from a single location (just imagine the extreme: only one archive node)

i still dont see why this lowers security as you claimed (you said this would raise node count - i think this too, and this would actually increase security a little). it adds complexity but there is always a tradeoff to make.

inBitweTrust

hero member

Activity: 658

Merit: 501

Quote from: onemorebtc on February 19, 2015, 09:23:57 PM

that still doesnt answer my question.
may i ask why it is not enough to secure the blockchain that way?

i assume that all miners already have full blockchains and we are only talking about new nodes (old nodes already have/had the full copy and therefor a validated utxo)

new nodes would still connect to running nodes - they just wont deliever all old transactions. blockheight, headers and pow is still all the same.

i fail to see a way how a new node could be tricked or has lower security if all old transactions are obtained in a different (even centralized) way

Downloading the whole blockchain from a single torrent or source is fine if it is verified with other unpruned full nodes .
What is mainly being discussed here is either:

1) Many pruned full nodes of ~1GB in size boostrapping and creating a verified UTXO from a combination of archival full nodes which are unpruned (how many of these should be sufficient is the question)

2) Many pruned full nodes of ~1GB in size + another 1-5% of a redundantly sharded blockchain using DHT on each node verifying each other
or
3) Combination of the above

0.11 will likely include the feature to create full pruned nodes and is expected to come out in approx. 6 months so you will now see 3 types of clients in the future-

SPV clients
Full pruned nodes with verified UTXO that are around 1GB in size
Full nodes with the whole unpruned blockchain

Thus the conversation will shift from increasing the current amount of full nodes from 6400 back to 10k , to focusing on this and talking about how many Full pruned nodes we want out in the ecosystem as well to secure the network.

I would like to hear what degree of security and decentralization the people against this hardfork would like so we could both work towards a common objective.

onemorebtc

sr. member

Activity: 266

Merit: 250

Quote from: inBitweTrust on February 19, 2015, 09:18:51 PM

Quote from: onemorebtc on February 19, 2015, 09:11:47 PM

my question was if the blockchain is retrieved from a central location (eg dropbox, bitcoin foundation, my http server) if it is still verifiable in a trustless manner.

No, verifying one full archival node with many pruned UTXO full nodes is not sufficient enough. It could work, but at the expense of security where the full content of those archived blocks could be manipulated.

that still doesnt answer my question.
may i ask why it is not enough to secure the blockchain that way?

i assume that all miners already have full blockchains and we are only talking about new nodes (old nodes already have/had the full copy and therefor a validated utxo)

new nodes would still connect to running nodes - they just wont deliever all old transactions. blockheight, headers and pow is still all the same.

i fail to see a way how a new node could be tricked or has lower security if all old transactions are obtained in a different (even centralized) way

inBitweTrust

hero member

Activity: 658

Merit: 501

Quote from: onemorebtc on February 19, 2015, 09:11:47 PM

my question was if the blockchain is retrieved from a central location (eg dropbox, bitcoin foundation, my http server) if it is still verifiable in a trustless manner.

No, verifying one full archival node with many pruned UTXO full nodes is not sufficient enough. It could work, but at the expense of security where the full content of those archived blocks could be manipulated.

onemorebtc

sr. member

Activity: 266

Merit: 250

Quote from: inBitweTrust on February 19, 2015, 09:08:06 PM

Quote from: onemorebtc on February 19, 2015, 08:56:57 PM

i like the proposal that any node keeps some configurable amount of transactions (say 10% to be VERY conservative)

edit: afaik it should be enough if the hole blockchain is anywhere (bitcoin foundation?) to download from. with -rescan it should do the same? please correct me...

No, the people arguing against this hardfork do indeed have some valid concerns. We don't want one or a few centralized sources to store archival or reference full historical nodes for us to bootstrap pruned nodes or partial DHT based nodes.

Personally, I would want a large distribution of Full (non pruned ) nodes on different a wide distribution of ASNs and with many different competing groups of people with different interests.

We definitely do not want a central organization like a government or TBF controlling this.

The question is how much would be sufficient to secure the network because the mere fact that we have increased the blocksize limit to 20MB doesn't mean we have to sacrifice the values we share with the people against this hard fork?

my question was if the blockchain is retrieved from a central location (eg dropbox, bitcoin foundation, my http server) if it is still verifiable in a trustless manner.

if thats the case i dont see any problem with distributing it from a central location - as long as enough people keep a copy (atm i could store and distribute up to 2tb without problems on my rootserver - i expect that i can keep more in a few years [and yes i have a node])

inBitweTrust

hero member

Activity: 658

Merit: 501

Quote from: onemorebtc on February 19, 2015, 08:56:57 PM

i like the proposal that any node keeps some configurable amount of transactions (say 10% to be VERY conservative)

edit: afaik it should be enough if the hole blockchain is anywhere (bitcoin foundation?) to download from. with -rescan it should do the same? please correct me...

No, the people arguing against this hardfork do indeed have some valid concerns. We don't want one or a few centralized sources to store archival or reference full historical nodes for us to bootstrap pruned nodes or partial DHT based nodes from.

Personally, I would want a large distribution of Full (non pruned ) nodes on a wide range of ASNs and controlled by many different competing groups of people with different interests.

We definitely do not want a central organization like a government or TBF controlling this.
The mere fact that we will be increasing the blocksize limit doesn't mean we have to sacrifice the values we share with the people against this hard fork.

The question is how many would be sufficient to secure the network?

P.S... While I applaud TBF attempt at addressing our concerns with the lack of full nodes with this program -
https://getaddr.bitnodes.io/nodes/incentive/

I think it is insufficient and frankly quite pathetic attempt at a real growing problem.

onemorebtc

sr. member

Activity: 266

Merit: 250

Quote from: dooglus on February 19, 2015, 08:42:28 PM

Quote from: DeathAndTaxes on February 16, 2015, 12:44:25 PM

You don't need a full copy of the historical chain to create the UTXO

I think you have that backwards. How can you create the UTXO if you don't have a full copy of the chain?

Quote from: DeathAndTaxes on February 16, 2015, 12:44:25 PM

a DHT can ensure that a full copy exists even if you only have a portion of it.

I don't think it can ensure that. All the nodes storing a certain block could disappear from the network at the same time. Where's the full copy now?

i like the proposal that any node keeps some configurable amount of transactions (say 10% to be VERY conservative)

edit: afaik it should be enough if the hole blockchain is anywhere (bitcoin foundation?) to download from. with -rescan it should do the same? please correct me...

inBitweTrust

hero member

Activity: 658

Merit: 501

Quote from: dooglus on February 19, 2015, 08:42:28 PM

I think you have that backwards. How can you create the UTXO if you don't have a full copy of the chain?

How many full nodes with the full copy of the distributed chain do you think is necessary to maintain both a fair distribution level and redundancy for security?

Quote from: dooglus on February 19, 2015, 08:42:28 PM

I don't think it can ensure that. All the nodes storing a certain block could disappear from the network at the same time. Where's the full copy now?

Either we could have enough redundancy with DHT to make this probabilistically impossible, or have enough archival full historical nodes. I would suggest both.

Currently, we have only ~6,400 full nodes active. I believe this number is too low and I assume you do as well. What is the bare minimum of nodes that would make you feel comfortable? Is it a set amount given enough distribution worldwide? Is there a certain ratio of bitcoin users to full node maintainers that makes you feel comfortable?

dooglus

legendary