Bitcoin Forum
November 10, 2024, 07:17:38 AM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 [2]  All
  Print  
Author Topic: help with finding issues in a modifcation of Bitcoin core  (Read 3376 times)
spin
Sr. Member
****
Offline Offline

Activity: 362
Merit: 262


View Profile
May 26, 2015, 08:15:51 AM
 #21

So why not have low priority outbound connections or something like that(basically any outbound connections above 8 are marked as low priority)? These could be connections that nodes will drop if regular priority incoming connections are competing for space. That could be a way to implement this responsibly so that low priority connections only use excess slots and won't compete for space with regular priority connections.
The next flag you'd ask for is for a configurable option to override the low priority status...

If you liked this post buy me a beer.  Beers are quite cheap where I live!
bc1q707guwp9pc73r08jw23lvecpywtazjjk399daa
bitsolutions
Sr. Member
****
Offline Offline

Activity: 261
Merit: 257



View Profile
May 26, 2015, 08:22:38 AM
 #22

So why not have low priority outbound connections or something like that(basically any outbound connections above 8 are marked as low priority)? These could be connections that nodes will drop if regular priority incoming connections are competing for space. That could be a way to implement this responsibly so that low priority connections only use excess slots and won't compete for space with regular priority connections.
The next flag you'd ask for is for a configurable option to override the low priority status...
So you think it's better to just ignore the issue and hope people don't modify the source?

Mining Software Developer.
coinfusion
Full Member
***
Offline Offline

Activity: 141
Merit: 100


View Profile
May 27, 2015, 04:03:32 AM
 #23

So why not have low priority outbound connections or something like that(basically any outbound connections above 8 are marked as low priority)? These could be connections that nodes will drop if regular priority incoming connections are competing for space. That could be a way to implement this responsibly so that low priority connections only use excess slots and won't compete for space with regular priority connections.
The next flag you'd ask for is for a configurable option to override the low priority status...
So you think it's better to just ignore the issue and hope people don't modify the source?

If you are going to make a modification, maybe you could also add some sort of indicator to the node you are connecting to which alerts it that you already have a large amount of connections -- That way others could chose to refuse your connections.
gmaxwell
Moderator
Legendary
*
expert
Offline Offline

Activity: 4270
Merit: 8805



View Profile WWW
May 27, 2015, 04:25:24 AM
 #24

So you think it's better to just ignore the issue and hope people don't modify the source?
I think I've arguably done more to advance privacy in Bitcoin than the next two people combined, I've also done a lot of research towards reducing resource exhaustion attacks.   No one is advocating "just ignoring";  but the fact that we're not yet able to completely mitigate the risk of harm due to chimpanzees with firearms does not mean that it would be wise to start handing out uzis at the zoo or, especially, that we're somehow obligated to arm those primates who have failed find any firearms on their own.
bitsolutions
Sr. Member
****
Offline Offline

Activity: 261
Merit: 257



View Profile
May 28, 2015, 04:01:19 AM
 #25

So you think it's better to just ignore the issue and hope people don't modify the source?
I think I've arguably done more to advance privacy in Bitcoin than the next two people combined, I've also done a lot of research towards reducing resource exhaustion attacks.   No one is advocating "just ignoring";  but the fact that we're not yet able to completely mitigate the risk of harm due to chimpanzees with firearms does not mean that it would be wise to start handing out uzis at the zoo or, especially, that we're somehow obligated to arm those primates who have failed find any firearms on their own.

I see privacy as a somewhat separate issue....if someone wants privacy there are plenty of ways to go about that such as using tor. I don't think people should expect privacy when running a full node from a public IP address. Anyways if someone is running a node with unlimited inbound and outbound connections from a high speed connection they are themselves still providing network resources.

Mining Software Developer.
spin
Sr. Member
****
Offline Offline

Activity: 362
Merit: 262


View Profile
May 28, 2015, 10:02:58 AM
 #26

I see privacy as a somewhat separate issue....if someone wants privacy there are plenty of ways to go about that such as using tor. I don't think people should expect privacy when running a full node from a public IP address. Anyways if someone is running a node with unlimited inbound and outbound connections from a high speed connection they are themselves still providing network resources.
Most people care at least a little about privacy.
Anyways if someone is running a node with unlimited inbound and outbound connections from a high speed connection they are themselves still providing network resources.
You are taking away from everyone else's network resources and centralising and decreasing privacy.  It's not a positive balance.

If you liked this post buy me a beer.  Beers are quite cheap where I live!
bc1q707guwp9pc73r08jw23lvecpywtazjjk399daa
bitsolutions
Sr. Member
****
Offline Offline

Activity: 261
Merit: 257



View Profile
May 28, 2015, 04:30:54 PM
 #27

Most people care at least a little about privacy.
I'm not saying I don't care, I think if someone does care about the privacy of a transaction they should take proper measures to protect their privacy and shouldn't expect privacy on a public Bitcoin node.

Mining Software Developer.
spin
Sr. Member
****
Offline Offline

Activity: 362
Merit: 262


View Profile
June 01, 2015, 09:01:26 AM
 #28

I'm not saying I don't care, I think if someone does care about the privacy of a transaction they should take proper measures to protect their privacy and shouldn't expect privacy on a public Bitcoin node.
What you seem to be saying is, because you feel that no-one should expect privacy, you have a right to attack the network and break any privacy others have.

If you liked this post buy me a beer.  Beers are quite cheap where I live!
bc1q707guwp9pc73r08jw23lvecpywtazjjk399daa
bitsolutions
Sr. Member
****
Offline Offline

Activity: 261
Merit: 257



View Profile
June 01, 2015, 03:07:21 PM
 #29

I'm not saying I don't care, I think if someone does care about the privacy of a transaction they should take proper measures to protect their privacy and shouldn't expect privacy on a public Bitcoin node.
What you seem to be saying is, because you feel that no-one should expect privacy, you have a right to attack the network and break any privacy others have.
I'm saying it's stupid to expect privacy when using the public IP's, if people want privacy they should not be broadcasting a transaction from a full node directly from their real IP address.

Mining Software Developer.
coinfusion
Full Member
***
Offline Offline

Activity: 141
Merit: 100


View Profile
June 03, 2015, 01:46:11 AM
 #30

....add some sort of indicator....

C'mon guys, no suggestions to check RFC3514?  I was hoping someone would cheer me up.
Pages: « 1 [2]  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!