belcher
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 25, 2016, 10:59:03 AM Last edit: July 25, 2016, 02:55:17 PM by belcher |
|
rico666 fails to assume good faith in the wiki. He should spend less time getting angry and more time educating himself on bitcoin's security model. What are the odds that he uses an SPV wallet or web wallet for his actual bitcoin transactions? Quite high I bet, which means anyone could print infinite bitcoins out of thin air and his wallet would happily accept them. If the attacker had some hash power they could make them have confirmations too. When I first posted that article, several bitcoin experts and core developers including adam back and gmaxwell told me it was good.
|
1HZBd22eQLgbwxjwbCtSjhoPFWxQg8rBd9 JoinMarket - CoinJoin that people will actually use. PGP fingerprint: 0A8B 038F 5E10 CC27 89BF CFFF EF73 4EA6 77F3 1129
|
|
|
achow101
Moderator
Legendary
Offline
Activity: 3486
Merit: 6802
Just writing some code
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 25, 2016, 12:48:19 PM |
|
Pretty much sure. If it hasn't changed radically in the past 24h. It's mindless. "You should run a full node, because ... 'privacy'" - which actually is an outright lie.
In what way is that an "outright lie"? Running a full node protects your privacy. It also makes your wallet more secure, which it does talk about as well. The article does not just talk about privacy. It talks about how beneficial full nodes to the network are and then gives advices how to run a crippled "full node" (pruned, limiting connections, bandwidth targeting and disabling listening, -blocksonly, ...) which isn't a full node anymore - ofc.
How are those not full nodes anymore? None of those things (pruning, limiting connects, limiting bandwidth) are part of the definition of a full node ( https://en.bitcoin.it/wiki/Full_node#What_makes_a_full_node.3F). The only thing that makes a full node "full" is that it has to download, verify, and validate every single block and transaction. Pruning still does that, it downloads every block and transaction. After it checks them, the data is deleted because it isn't necessary to store all of that. It simply won't be able to bootstrap another node, but that behavior is not part of what defines a full node. Limiting connections and bandwidth also do no detract from the behavior that a full node is supposed to have, validating blocks and transactions. blocksonly, same thing. Except it doesn't care about unconfirmed transactions, which is the only "crippling" that I see, but not that much of a problem as it still verifies and validates all of the blocks and the transactions in them. So again, how are they not full nodes? So? That's some faking that could skew statistics - or malevolently bind "good nodes" shortly. It's not a faking that could actually pretend in concrete data transfer a true full node. I do not care about faking statistics, I care about the robustness of the Bitcoin network.
Actually they could be used in a sybil attack against one node, where those fake nodes take up all of the connections of a node and serve that node an alternate blockchain. Furthermore, there could be fake nodes that relay, but don't check. They could just be extra bandwidth that sends blocks and transactions around, but it isn't helpful if those fake nodes are not checking the blocks and transactions to make sure that they are valid. So they pretend to be a full node, but aren't actually doing the job a full node is supposed to. WHAT? The "you" in de-anonymized is who exactly? The one sending the tx? The node operator? It doesn't matter - why is there a deanonymization you think? I didn't write the fingerprint would contain IP addresses. Fingerprint of a relaying node could very well point to a Bitcoin address (for the receiving funds). Are you telling me Bitcoin addreses break the idea of privacy? ![Wink](https://bitcointalk.org/Smileys/default/wink.gif) Think before you dismiss something as terrible idea. You sure you want to participate in a technical discussion leading to some advancement or do you prefer a "technical discussion" where you can excel in thinking of ways how something doesn't work or why it's not possible? The concept I'm talking about has several problems, but deanonymization isn't one of them. Blowing things out of proportion is. ![Wink](https://bitcointalk.org/Smileys/default/wink.gif) Because as it stands, you would have n transactions (to relaying nodes) for every 1 transaction (which makes it into the block). And who should relay these? ... This is something that probably should be addressed with a sidechain - actually IMHO the perfect use case candidate for that. There is a deanonymization because there is a list of nodes that have relayed the transaction. The issue comes in with the node that created the transaction. That node would be the first node to attach its fingerprint to the list. Thus all of its peers, when they receive the transaction, can see that only one node has relayed that transaction. It will also know which peer relayed that transaction with one node on its list so it knows the ip address of the person sending the Bitcoin in that transaction. Now those peers know that that node can spend from certain addresses, and because they have the ip address of that node, they can further deanonymize the owner of the node and the addresses in his transactions.
|
|
|
|
mmortal03
Legendary
Offline
Activity: 1762
Merit: 1011
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 25, 2016, 08:59:57 PM |
|
"Nodes with open ports are able to upload blocks to new full nodes. In all other ways they are the same as nodes with closed ports." The contributor of those two lines makes it sound as if this difference between the two is negligible, when it isn't. Please elaborate on this. We might as well have the discussion here rather than the wiki talk page. [Removed from quote the parts not relevant to my concerns]I see you've added some words about miners using the p2p network to propagate blocks, future solutions like BIP152. From what I know most miners directly connect to each other's IPs because they would not be remotely competitive if they used the p2p network. The main bottleneck here isn't bandwidth so adding more peers to the p2p network won't improve it. The main bottleneck today is mostly verification time since hashing and ECDSA can take long. My concern with those two lines is simply that nodes with open ports do something very important that nodes with closed ports do not do. That's all I meant by that. As far as my added words, and your points about bandwidth, no, a p2p solution for the miners is still feasible from what I've read. It needs to be solved, if it's possible. We don't need miners requiring centralized methods, if possible. Maybe someone has made an argument elsewhere that a centralized solution for this particular issue will always be more economically preferable/efficient than a p2p one, and, thus, any p2p solutions to it should not be developed? Such a conclusion (not saying it's yours) doesn't seem to follow, at least in my mind. We still need more efficient p2p options to fall back on *even* if centralized options for certain aspects of the network will remain economically superior.
|
|
|
|
gmaxwell
Moderator
Legendary
Offline
Activity: 4228
Merit: 8641
|
"Nodes with open ports are able to upload blocks to new full nodes. In all other ways they are the same as nodes with closed ports." The contributor of those two lines makes it sound as if this difference between the two is negligible, when it isn't. In fact, that quoted text sounds like it's overstating the differences-- nodes without open ports still forward blocks too. The difference is that they make outbound connections and so they can't connect to each other... and now that HS support is integrated, even that difference is diminishing.
|
|
|
|
Syke
Legendary
Offline
Activity: 3878
Merit: 1193
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 26, 2016, 03:59:50 PM |
|
The bottom line is this. The cost to run a full node is virtually zero. Therefore, your incentive available to give to the full nodes is also virtually zero. Anything above that will be greatly exploited.
|
Buy & Hold
|
|
|
Shiroslullaby
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 26, 2016, 05:02:59 PM |
|
I agree with Syke now, but what about in the future? What happens down the road when all the coins are mined? Transaction fees from verifying transactions becomes the only way to earn money?
I know this is a long time from now, but it's something to think about. Does anyone have any info as to what keeps the network going once all the available coins have been discovered?
|
|
|
|
Syke
Legendary
Offline
Activity: 3878
Merit: 1193
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 26, 2016, 11:26:18 PM |
|
I agree with Syke now, but what about in the future?
There's no change. Non-mining full nodes will always be virtually free to run. Does anyone have any info as to what keeps the network going once all the available coins have been discovered?
Transaction fees paid to mining nodes. We'll never run out of new blocks to be mined.
|
Buy & Hold
|
|
|
DumbFruit
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 27, 2016, 01:51:23 PM |
|
How about this; Put a "transaction redistributor" layer in wallets, so that users can either choose miners to send their transactions to, maybe simply based on presumed geographical node positions and hashrate, or else have a third party handle it for them. The third party is trusted to have them mined in a decentralized manner. They might certify miners, in order to verify non-collusion, but how the third party ensures decentralization is open to competition. If the transaction doesn't verify over a certain period of time, or if users no longer trust a third party for any reason, users could always fall back to standard broadcasting of transactions. This way, users can try enforcing a decentralized mining process, even though it would mean slower confirmation times, and slightly more expensive fees. For this to have any chance of working, miners would have to be primarily funded through transaction fees. I find that interesting because it's a separate reason why funding miners through inflation is improper, and why a robust fee market is desirable. I previously disliked funding through inflation only because a good medium of exchange should have a stable supply, for easier economic calculation, and the inflation rate isn't found through a market process.
I think this would be a difficult product to get users to adopt, because there doesn't appear to be any immediate benefit to them. It is also hard to establish trust with a third party, due to the nature of it being surprisingly difficult to prove nodes are decentralized, and therefore also difficult to ensure third parties are being effective.
Nonetheless, it is at least a method to incentivize decentralized nodes, and doesn't seem likely to make the situation worse.
|
By their (dumb) fruits shall ye know them indeed...
|
|
|
mmortal03
Legendary
Offline
Activity: 1762
Merit: 1011
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 27, 2016, 02:51:31 PM |
|
The difference is that they make outbound connections and so they can't connect to each other... and now that HS support is integrated, even that difference is diminishing.
The fact that closed port nodes still make outbound connections is completely fair, but I don't know that I agree with what you're saying about hidden service support, at least, as it currently stands. True, having the technical capability there to be able to keep regular ports closed but still accept incoming connections over Tor *does* mean that closed port nodes can now, once configured as a Tor HS, more fully help to distribute the network. But in the practical sense, it's just an option that's available. How many people who don't forward their ports are jumping at the chance to configure their setup to run as an HS? If, instead, HS support was fully automated, without the user even needing to install Tor -- say it was even turned on by default whenever an open port was not detected -- *that* would diminish the differences. Something like that might even be made to allow non-Tor outbound connections to run *concurrently* with HS connections so that there would be no substantial hit on bandwidth. I'm not an expert, so, something like that could be an awful change for other reasons, but my point is that doing something like *that* is what I would categorize as moving closed port nodes, practically speaking, towards more comprehensive use by the network.
|
|
|
|
RealBitcoin (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 27, 2016, 03:43:36 PM |
|
I am just amazed how professional and competent the bitcoin development team is. There are issues in bitcoin but they will be resolved because we have some of the most intelligent people working on this.
This is why this conversation needs to happen, the node count is an issue, it's not an immediate issue, but it could be in the future, so better prepere for it now than later.
|
|
|
|
|
Syke
Legendary
Offline
Activity: 3878
Merit: 1193
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 27, 2016, 06:34:45 PM |
|
Sorry but that is not true. The cost is convenience, hardware space, CPU computing power and network bandwidth.
You don't need a dedicated server to run a bitcoin node. Just slap it on an existing server for free. There're millions of servers out there that could be turned into nodes for no cost. I know, because I have one. And you underestimate the ability of people to exploit incentives. Let's say there is a real cost of $1 to run a bitcoin node. If you provide a $1.01 incentive, people will immedately spin up thousands of nodes and drain all incentives. So your incentive can never cover the cost to run the node which means any "incentive" is not an incentive at all.
|
Buy & Hold
|
|
|
RealBitcoin (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 27, 2016, 06:39:17 PM |
|
You don't need a dedicated server to run a bitcoin node. Just slap it on an existing server for free. There're millions of servers out there that could be turned into nodes for no cost. I know, because I have one.
But why would people do that if they dont make money? You could lease that server out to many people that pay you. People wont be altruists to just use it for bitcoin nodes. You need to pay them somehow. And you underestimate the ability of people to exploit incentives. Let's say there is a real cost of $1 to run a bitcoin node. If you provide a $1.01 incentive, people will immedately spin up thousands of nodes and drain all incentives. So your incentive can never cover the cost to run the node which means any "incentive" is not an incentive at all.
Yes, and in the result you get many new nodes. Now if we can limit the node to 1 / IP, then it would be great.
|
|
|
|
Syke
Legendary
Offline
Activity: 3878
Merit: 1193
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 27, 2016, 06:50:33 PM |
|
Now if we can limit the node to 1 / IP, then it would be great.
Great, and do you have any idea how many IPv6 addresses are possible?
|
Buy & Hold
|
|
|
RealBitcoin (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 27, 2016, 06:55:25 PM |
|
Now if we can limit the node to 1 / IP, then it would be great.
Great, and do you have any idea how many IPv6 addresses are possible? For each new IP you need a new internet subscription. An ISP only gives you 1 IP at a time / subscription.
|
|
|
|
TransaDox
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 28, 2016, 08:48:27 AM |
|
Still it has to have some kind of incentive, if not monetary then what?
How do you incentivize full nodes to be created, by individuals, and limit it to 1 / person?
That is the real question.
Incentive is participation. If one doesn't run a full node; one cannot participate in the network. If one has a wallet; one is running a full node...period. Today it has implications for the blockchain size which everyone is in denial about but that is a different issue. This also means that it doesn't matter how many nodes one runs but there is no real incentive to run more than one so a limit is moot. Every wallet is a full node and that means millions of them on every platform rather than a few altruistic hard-core fanatics or greedy, infrastructure rich parasites.
|
|
|
|
rico666
Legendary
Offline
Activity: 1120
Merit: 1037
฿ → ∞
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 28, 2016, 01:18:12 PM |
|
rico666 fails to assume good faith in the wiki. He should spend less time getting angry and more time educating himself on bitcoin's security model. About education: I've been longer a - registered - contributor to Wikipedia than Bitcoin actually exists. Trying to educate me about AGF is like trying to count - slowly - from 1 to 10 in front of a sentient computer. ~ (c) Douglas Adams The article is not about "bitcoin's security model", it is about it's authors twisted view of the bitcoin ecosystem. That's what made me angry in the 1st place. What are the odds that he uses an SPV wallet or web wallet for his actual bitcoin transactions? Quite high I bet
Stop right there. You lost the bet. What was the wager? When I first posted that article, several bitcoin experts and core developers including adam back and gmaxwell told me it was good. When my youngest son played the flute at some school event, I also told him it was good. This is not an endorsement of his flute skill, nor of my musical perception skill. There is a czech saying "weak pupils have to be praised more often" - is that what you want? More praise? Rico
|
|
|
|
rico666
Legendary
Offline
Activity: 1120
Merit: 1037
฿ → ∞
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 28, 2016, 01:26:08 PM |
|
Great, and do you have any idea how many IPv6 addresses are possible?
For each new IP you need a new internet subscription. An ISP only gives you 1 IP at a time / subscription. Uh... I got a /48 IPv6 net for every account with our ISP. If I am not entirely mistaken, this is 2 80 addresses... Even if you stayed in IPv4 land, then you have HP, IBM, the US military and what not with their Class-A networks. And even if you somehow could/would reduce it to a node per IP, it's quite discriminatory in almost any NAT environment. => I do not think that is a viable solution. Rico
|
|
|
|
rico666
Legendary
Offline
Activity: 1120
Merit: 1037
฿ → ∞
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 28, 2016, 01:35:01 PM |
|
And you underestimate the ability of people to exploit incentives. Let's say there is a real cost of $1 to run a bitcoin node. If you provide a $1.01 incentive, people will immedately spin up thousands of nodes and drain all incentives. So your incentive can never cover the cost to run the node which means any "incentive" is not an incentive at all.
P E R F E C T !!! Thanks for bringing this up. Let's scrap the mining incentive. Same story. Rico
|
|
|
|
belcher
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 28, 2016, 02:32:30 PM |
|
As far as my added words, and your points about bandwidth, no, a p2p solution for the miners is still feasible from what I've read. It needs to be solved, if it's possible. We don't need miners requiring centralized methods, if possible. Maybe someone has made an argument elsewhere that a centralized solution for this particular issue will always be more economically preferable/efficient than a p2p one, and, thus, any p2p solutions to it should not be developed? Such a conclusion (not saying it's yours) doesn't seem to follow, at least in my mind. We still need more efficient p2p options to fall back on *even* if centralized options for certain aspects of the network will remain economically superior.
Please say where you've read that. I think it might be wrong, because this short talk has data which shows miners today would not be even remotely competitive if they used the p2p network: https://www.youtube.com/watch?v=Y6kibPzbrIcOf course I agree this is not a great situation to be in, and it would be better without a centralized solution, but right now the relay network is all we've got. People running nodes with open ports likely won't do anything to improve that, more scaleable software will. The main aim of that article was to convince more people to use wallets backed by their own full nodes, especially in the shadow of the hostile hard fork attempts from the block size conflict.
|
1HZBd22eQLgbwxjwbCtSjhoPFWxQg8rBd9 JoinMarket - CoinJoin that people will actually use. PGP fingerprint: 0A8B 038F 5E10 CC27 89BF CFFF EF73 4EA6 77F3 1129
|
|
|
|