Bitcoin Forum
October 23, 2017, 06:24:10 AM *
News: Latest stable version of Bitcoin Core: 0.15.0.1  [Torrent]. (New!)
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 [26] 27 28 29 30 31 32 33 34 35 36 37 38 39 40 »
  Print  
Author Topic: ...  (Read 59340 times)
brg444
Hero Member
*****
Offline Offline

Activity: 644

Bitcoin replaces central, not commercial, banks


View Profile
August 27, 2015, 01:40:06 AM
 #501

I can actually tell you right now  Grin Fees will be raised !
Yes, I'm sure about this.  Grin
And then you will hear users screaming around because they are paying up to 1$ or more (some thinks that it's ok to pay 20$) to get confirmations.
For some, the confirmation will arrive after hours or days.

What do you think that will happen after this? Do you think that users will continue to use Bitcoin or just one of the other 500 alternatives? (and there are some that are pointing to take the place of Bitcoin)

Less users = higher price?
I think NOT Wink

Some of you have no clue about all of this Roll Eyes (or are in bad faith, maybe you just own other coins ...)

Where did you get the impression that transactions was all the rage in Bitcoin?

An important majority of coins are actually sitting pretty in cold storage/paper wallets some untouched for several years already.

We're a long way from 1$ fees anyway.

Do you think that more users = necessarily higher price?

Maybe, just maybe you're not thinking this through properly?

"I believe this will be the ultimate fate of Bitcoin, to be the "high-powered money" that serves as a reserve currency for banks that issue their own digital cash." Hal Finney, Dec. 2010
1508739850
Hero Member
*
Offline Offline

Posts: 1508739850

View Profile Personal Message (Offline)

Ignore
1508739850
Reply with quote  #2

1508739850
Report to moderator
1508739850
Hero Member
*
Offline Offline

Posts: 1508739850

View Profile Personal Message (Offline)

Ignore
1508739850
Reply with quote  #2

1508739850
Report to moderator
1508739850
Hero Member
*
Offline Offline

Posts: 1508739850

View Profile Personal Message (Offline)

Ignore
1508739850
Reply with quote  #2

1508739850
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1508739850
Hero Member
*
Offline Offline

Posts: 1508739850

View Profile Personal Message (Offline)

Ignore
1508739850
Reply with quote  #2

1508739850
Report to moderator
1508739850
Hero Member
*
Offline Offline

Posts: 1508739850

View Profile Personal Message (Offline)

Ignore
1508739850
Reply with quote  #2

1508739850
Report to moderator
1508739850
Hero Member
*
Offline Offline

Posts: 1508739850

View Profile Personal Message (Offline)

Ignore
1508739850
Reply with quote  #2

1508739850
Report to moderator
VirosaGITS
Hero Member
*****
Offline Offline

Activity: 910


Want to save $? Use Coupon Code VOFF5 at GPUShack


View Profile
August 27, 2015, 01:41:03 AM
 #502

portion of the bitcoin community is going to reverse their decision on a fork that allow the devs to upload an IP black list.
There isn't any fork that allow devs to upload any IP black list, you are just parrot that repeat the first word that you hear without know the meaning.

Are you kidding?

https://github.com/bitcoinxt/bitcoinxt/commit/73c9efe74c5cc8faea9c2b2c785a2f5b68aa4c23

Quote
The code has both a static list and a list that's downloaded when the node starts.

It starts with a blacklist of Tor exit nodes that allow when there is a heavy load on the network to prioritize transaction coming from Tor nodes.

In simpler terms. This allow to kick off certain transactions if the load remain for a certain period of time.

Ethereum Mining Calculator - Simple, elegant, mobile-friendly Ethereum Mining Profitability Calculator
gpuShack mining hardware - Your one stop shop for all GPU mining related hardware! Use Coupon Code VOFF5 to save on any order.
ethOS - #ethosdistro on freenode - linux distro that mines Ethereum out-of-the-box.
HostFat
Staff
Legendary
*
Offline Offline

Activity: 2604


I support freedom of choice


View Profile WWW
August 27, 2015, 01:42:14 AM
 #503

If we persist on doing that someone WILL take advantage of the free space. Now what happens if 8MB blocks get filled up way before the intended increase?
The connection of the common nodes aren't able to share easily this kind of blocks, so there will be orphan blocks, miners will lose money.
Do you know what happen when a miner lose money by doing something? Easy, he will stop doing it, because he wants more money.  Shocked  Roll Eyes
It is easy, a simple logic, but all of you are full of propaganda.

NON DO ASSISTENZA PRIVATA - The Rock Trading (ref): A good exchange / gateway Ripple, with support for multisig, since 2007. 
https://bitcointa.lk: Bitcointalk backup if offline - Bitcoin Foundation Italia - Blog: http://theupwind.blogspot.it
HostFat
Staff
Legendary
*
Offline Offline

Activity: 2604


I support freedom of choice


View Profile WWW
August 27, 2015, 01:51:11 AM
 #504


Are you kidding?

https://github.com/bitcoinxt/bitcoinxt/commit/73c9efe74c5cc8faea9c2b2c785a2f5b68aa4c23

Quote
The code has both a static list and a list that's downloaded when the node starts.

Quote from: VirosaGITS
portion of the bitcoin community is going to reverse their decision on a fork that allow the devs to upload an IP black list.
Do you know the difference betwean the words "uploading" and "downloading"?

Do you know that if you set a proxy then XT will not download any list from torproject.org ?
Do you know that you can just start the node with this flag -disableipprio flag XT will not download any list from torproject.org ?


And one more thing, do you know what does this code on Bitcoin Core?  
OMG all of them will know your IP! Shocked

Code:
       vSeeds.push_back(CDNSSeedData("bitcoin.sipa.be", "seed.bitcoin.sipa.be")); // Pieter Wuille
        vSeeds.push_back(CDNSSeedData("bluematt.me", "dnsseed.bluematt.me")); // Matt Corallo
        vSeeds.push_back(CDNSSeedData("dashjr.org", "dnsseed.bitcoin.dashjr.org")); // Luke Dashjr
        vSeeds.push_back(CDNSSeedData("bitcoinstats.com", "seed.bitcoinstats.com")); // Christian Decker
        vSeeds.push_back(CDNSSeedData("xf2.org", "bitseed.xf2.org")); // Jeff Garzik
        vSeeds.push_back(CDNSSeedData("bitcoin.jonasschnelli.ch", "seed.bitcoin.jonasschnelli.ch")); // Jonas Schnelli


You are just another parrot.

NON DO ASSISTENZA PRIVATA - The Rock Trading (ref): A good exchange / gateway Ripple, with support for multisig, since 2007. 
https://bitcointa.lk: Bitcointalk backup if offline - Bitcoin Foundation Italia - Blog: http://theupwind.blogspot.it
VirosaGITS
Hero Member
*****
Offline Offline

Activity: 910


Want to save $? Use Coupon Code VOFF5 at GPUShack


View Profile
August 27, 2015, 01:53:40 AM
 #505


Are you kidding?

https://github.com/bitcoinxt/bitcoinxt/commit/73c9efe74c5cc8faea9c2b2c785a2f5b68aa4c23

Quote
The code has both a static list and a list that's downloaded when the node starts.

Quote from: VirosaGITS
portion of the bitcoin community is going to reverse their decision on a fork that allow the devs to upload an IP black list.
Do you know the difference betwean the words "uploading" and "downloading"?

Do you know that if you set a proxy then XT will not download any list from torproject.org ?
Do you know that you can just start the node with this flag -disableipprio flag XT will not download any list from torproject.org ?


And one more thing, do you know what does this code on Bitcoin CoreShocked

Code:
        vSeeds.push_back(CDNSSeedData("bitcoin.sipa.be", "seed.bitcoin.sipa.be")); // Pieter Wuille
        vSeeds.push_back(CDNSSeedData("bluematt.me", "dnsseed.bluematt.me")); // Matt Corallo
        vSeeds.push_back(CDNSSeedData("dashjr.org", "dnsseed.bitcoin.dashjr.org")); // Luke Dashjr
        vSeeds.push_back(CDNSSeedData("bitcoinstats.com", "seed.bitcoinstats.com")); // Christian Decker
        vSeeds.push_back(CDNSSeedData("xf2.org", "bitseed.xf2.org")); // Jeff Garzik
        vSeeds.push_back(CDNSSeedData("bitcoin.jonasschnelli.ch", "seed.bitcoin.jonasschnelli.ch")); // Jonas Schnelli


You are just another parrot.

Here's the part you missed:

The IP list thats included in the commit:
http://pastebin.com/F15aHDMJ

It doesn't need to be downloaded from tor project.

Ethereum Mining Calculator - Simple, elegant, mobile-friendly Ethereum Mining Profitability Calculator
gpuShack mining hardware - Your one stop shop for all GPU mining related hardware! Use Coupon Code VOFF5 to save on any order.
ethOS - #ethosdistro on freenode - linux distro that mines Ethereum out-of-the-box.
HostFat
Staff
Legendary
*
Offline Offline

Activity: 2604


I support freedom of choice


View Profile WWW
August 27, 2015, 01:57:58 AM
 #506


Here's the part you missed:

The IP list thats included in the commit:
http://pastebin.com/F15aHDMJ

It doesn't need to be downloaded from tor project.
They are just all tor exit nodes! Roll Eyes
What do you think that they'll care about this?
They are public servers, they work as public servers!

XT isn't even going to give a shit about them until it receives a possible DoS attack.
And it isn't going to connect them, it will just put them under a low priority, to avoid getting too many connections from them (because the DoS attack)

Damn it! You don't really know what you are talking about, just repeating repeating ...

NON DO ASSISTENZA PRIVATA - The Rock Trading (ref): A good exchange / gateway Ripple, with support for multisig, since 2007. 
https://bitcointa.lk: Bitcointalk backup if offline - Bitcoin Foundation Italia - Blog: http://theupwind.blogspot.it
VirosaGITS
Hero Member
*****
Offline Offline

Activity: 910


Want to save $? Use Coupon Code VOFF5 at GPUShack


View Profile
August 27, 2015, 02:00:35 AM
 #507


Here's the part you missed:

The IP list thats included in the commit:
http://pastebin.com/F15aHDMJ

It doesn't need to be downloaded from tor project.
They are just all tor exit nodes! Roll Eyes
What do you think that they'll care about this?
They are public servers, they work as public servers!

XT isn't even going to give a shit about them until it receives a possible DoS attack.
And it isn't going to connect them, it will just put them under a low priority, to avoid getting too many connections from them (because the DoS attack)

See? I guess you're the parrot. I said they put up a list of black listed ip. And they did. They get low priority. How can this be exploited, how easily can ips be added to the list is beside the point thats up to the code engineers to decide and i trust them over you;

Leave me alone.

Ethereum Mining Calculator - Simple, elegant, mobile-friendly Ethereum Mining Profitability Calculator
gpuShack mining hardware - Your one stop shop for all GPU mining related hardware! Use Coupon Code VOFF5 to save on any order.
ethOS - #ethosdistro on freenode - linux distro that mines Ethereum out-of-the-box.
canth
Legendary
*
Offline Offline

Activity: 1442



View Profile
August 27, 2015, 02:03:12 AM
 #508

The longest chain is what the majority of the network chooses.
If the majority of the network will be on XT or anything else that support BIP101 (or others), than it will be the chain, it will be "the Bitcoin".

We have to see what will happen when the 1MB limit will be reached...

XT isint happening. There's already too much hashpower put toward not accepting XT. So unless XT supporter suddenly buy 75% up from 1% of the total network's hashrate. Its not happening.

This blacklist score being an ip list uploaded by the dev is so shady, there's just no way actual volume of people will support it. Ever.

Yes, because nobody ever changes their minds. Besides, if you're right then what is there to argue about? Seems like a lot of angst about something that has no chance of happening.

Indeed. Nothing to argue about.

I don't think the educated portion of the bitcoin community is going to reverse their decision on a fork that allow the devs to upload an IP black list. That is such a massive security flaw, its no wonder BIP100 gained 30 time the support of XT in 1 day.

Of course that's just what i believe. I could be totally wrong and people may decide to purposely vote in a fork that allow a certain person to destroy bitcoin if he desire.

Aren't you tired of going on and on about a feature that can be disabled by one line?  -disableipprio

canth
Legendary
*
Offline Offline

Activity: 1442



View Profile
August 27, 2015, 02:07:15 AM
 #509


Have you read BIP101? It proposes jumping the blocksize limit to 8 MB next year, and then doubling of the blocksize limit every 2 years, for 20 years. That gives us 8192 MB blocks in 21 years. And that's what the sane bitcoiners should want?


1) It's easier to soft fork to a lower blocksize in the future if blocks are "too large" since it only requires miner support.
2) Really - you think that 8GB blocks in 20 years is obviously crazy? 1gbit bandwidth, although not widespread, is currently available today. It seems hardly unreasonable to think that technical advances in two decades are not going to be able to keep up. If we're wrong, refer to #1.

The issue with a large increase is it creates a slippery slope. Raising the blocksizing is essentially subsidizing transactions. If we persist on doing that someone WILL take advantage of the free space. Now what happens if 8MB blocks get filled up way before the intended increase? It is not an improbable scenario that we could see bigger block get filled surprisingly quickly & the increase will have been more or less for nothing.

If we take the decision to continue subsidizing transactions right now because of pressure from certain groups we will inevitably create a precedent and reinforce the belief of users that they somehow have a RIGHT for block space and therefore make it forever more difficult to refuse it. Imagine the subsequent pressure if Bitcoin grows by a couple orders of magnitude and users start seeing their transaction fees go up when they were told it would forever be nearly free.

This here is an opportunity to put a check on these false expectations and discourage business plans that were planning to unnecessarily fill up the blocks w/ their own transactions. People need to understand that there is cost to having this system run securely and we should stop trying to externalize them.


You haven't done the math. It's far easier to accommodate 100,000 transactions with a $0.05 fee/trx in a block than get 1000 transactions with a $5 fee/trx. Larger blocks = more trx = more users = more fees.

Also, there is no guarantee that demand will come because max block sizes are larger. We aren't in the "Bitcoin's success is guaranteed" universe. It's going to take a crapload of work to get 100m people using Bitcoin and higher fees are not the way to get there.

VirosaGITS
Hero Member
*****
Offline Offline

Activity: 910


Want to save $? Use Coupon Code VOFF5 at GPUShack


View Profile
August 27, 2015, 02:07:44 AM
 #510

The longest chain is what the majority of the network chooses.
If the majority of the network will be on XT or anything else that support BIP101 (or others), than it will be the chain, it will be "the Bitcoin".

We have to see what will happen when the 1MB limit will be reached...

XT isint happening. There's already too much hashpower put toward not accepting XT. So unless XT supporter suddenly buy 75% up from 1% of the total network's hashrate. Its not happening.

This blacklist score being an ip list uploaded by the dev is so shady, there's just no way actual volume of people will support it. Ever.

Yes, because nobody ever changes their minds. Besides, if you're right then what is there to argue about? Seems like a lot of angst about something that has no chance of happening.

Indeed. Nothing to argue about.

I don't think the educated portion of the bitcoin community is going to reverse their decision on a fork that allow the devs to upload an IP black list. That is such a massive security flaw, its no wonder BIP100 gained 30 time the support of XT in 1 day.

Of course that's just what i believe. I could be totally wrong and people may decide to purposely vote in a fork that allow a certain person to destroy bitcoin if he desire.

Aren't you tired of going on and on about a feature that can be disabled by one line?  -disableipprio

Nope. I don't like how it allow people to trigger code that deprioritize certain IPs. Just the thought of adding this kind of code is heading down the wrong path.

I have no idea what would be the effect on the network if a portion of the network did not use the default and used -disableipprio instead.

Ethereum Mining Calculator - Simple, elegant, mobile-friendly Ethereum Mining Profitability Calculator
gpuShack mining hardware - Your one stop shop for all GPU mining related hardware! Use Coupon Code VOFF5 to save on any order.
ethOS - #ethosdistro on freenode - linux distro that mines Ethereum out-of-the-box.
HostFat
Staff
Legendary
*
Offline Offline

Activity: 2604


I support freedom of choice


View Profile WWW
August 27, 2015, 02:09:22 AM
 #511

@VirosaGITS

LOL
You can even add all the possible IPs to the list, then they will have all the same priority, and just during a DoS attack  Roll Eyes

Do you know that will happen when a dev will add other IP to this list? Someone will see it because ... it's an open source project!

Do you check every day what devs add to the Bitcoin Core?

Again, it isn't a black list, it is a "low priority list", that enable it self only IF there is a DoS attack.


So, because of this, it's better to put all the Bitcoin network in a trash can a let the market go somewhere else  Roll Eyes

If you don't like this list, fork it, it is just a click on the github repository.

I have no idea what would be the effect on the network if a portion of the network did not use the default and used -disableipprio instead.
It will be as the Bitcoin Core works now. Someone thinks that nodes now are easy target for DoS attack.
You think not, then, better for yourself.

NON DO ASSISTENZA PRIVATA - The Rock Trading (ref): A good exchange / gateway Ripple, with support for multisig, since 2007. 
https://bitcointa.lk: Bitcointalk backup if offline - Bitcoin Foundation Italia - Blog: http://theupwind.blogspot.it
canth
Legendary
*
Offline Offline

Activity: 1442



View Profile
August 27, 2015, 02:10:13 AM
 #512

portion of the bitcoin community is going to reverse their decision on a fork that allow the devs to upload an IP black list.
There isn't any fork that allow devs to upload any IP black list, you are just parrot that repeat the first word that you hear without know the meaning.

Are you kidding?

https://github.com/bitcoinxt/bitcoinxt/commit/73c9efe74c5cc8faea9c2b2c785a2f5b68aa4c23

Quote
The code has both a static list and a list that's downloaded when the node starts.

It starts with a blacklist of Tor exit nodes that allow when there is a heavy load on the network to prioritize transaction coming from Tor nodes.

In simpler terms. This allow to kick off certain transactions if the load remain for a certain period of time.

LOL. Seriously...your logic is seriously lacking. How would anyone know what IP addresses transactions are going to come from before they are transmitted? Maybe they do this magic IP address <-> Bitcoin address lookup in the sky?

canth
Legendary
*
Offline Offline

Activity: 1442



View Profile
August 27, 2015, 02:15:01 AM
 #513

The longest chain is what the majority of the network chooses.
If the majority of the network will be on XT or anything else that support BIP101 (or others), than it will be the chain, it will be "the Bitcoin".

We have to see what will happen when the 1MB limit will be reached...

XT isint happening. There's already too much hashpower put toward not accepting XT. So unless XT supporter suddenly buy 75% up from 1% of the total network's hashrate. Its not happening.

This blacklist score being an ip list uploaded by the dev is so shady, there's just no way actual volume of people will support it. Ever.

Yes, because nobody ever changes their minds. Besides, if you're right then what is there to argue about? Seems like a lot of angst about something that has no chance of happening.

Indeed. Nothing to argue about.

I don't think the educated portion of the bitcoin community is going to reverse their decision on a fork that allow the devs to upload an IP black list. That is such a massive security flaw, its no wonder BIP100 gained 30 time the support of XT in 1 day.

Of course that's just what i believe. I could be totally wrong and people may decide to purposely vote in a fork that allow a certain person to destroy bitcoin if he desire.

Aren't you tired of going on and on about a feature that can be disabled by one line?  -disableipprio

Nope. I don't like how it allow people to trigger code that deprioritize certain IPs. Just the thought of adding this kind of code is heading down the wrong path.

I have no idea what would be the effect on the network if a portion of the network did not use the default and used -disableipprio instead.

What do you think should happen when a node has all of its incoming connections exhausted? Should the node reject new connections? Drop existing ones? How should they be prioritied? Hearn picked what will work for most, non-Tor using, non-power users. A Tor user is fully capable of turning off the feature and 99% of the other users will never have it engaged since they won't be under attack for incoming connections.

Hell, most users don't even know enough to enable incoming connections through NAT and UPNP is notoriously unreliable even when it's enabled. Basically, this feature will affect very, very few.

VirosaGITS
Hero Member
*****
Offline Offline

Activity: 910


Want to save $? Use Coupon Code VOFF5 at GPUShack


View Profile
August 27, 2015, 02:20:16 AM
 #514

Not sure why you double posted, but sure. I get what you're saying.

But tell me, if the TX backlog was getting full. Then there was heavy DoS on the network. What would happen to the transactions request from Tor users? Would be still be processed at some point, even when the BTC system is inclined to drop off transactions that will not make it to a block after X conditions are met?

Ethereum Mining Calculator - Simple, elegant, mobile-friendly Ethereum Mining Profitability Calculator
gpuShack mining hardware - Your one stop shop for all GPU mining related hardware! Use Coupon Code VOFF5 to save on any order.
ethOS - #ethosdistro on freenode - linux distro that mines Ethereum out-of-the-box.
canth
Legendary
*
Offline Offline

Activity: 1442



View Profile
August 27, 2015, 02:24:36 AM
 #515

Not sure why you double posted, but sure. I get what you're saying.

But tell me, if the TX backlog was getting full. Then there was heavy DoS on the network. What would happen to the transactions request from Tor users? Would be still be processed at some point, even when the BTC system is inclined to drop off transactions that will not make it to a block after X conditions are met?

By heavy DoS on the network, do you mean all nodes? If there was, then we'd have a big problem period - doesn't matter if you are on Tor, running XT or core.

If only some nodes are being DoS'ed then it's fine. Tor users would get dropped from certain XT nodes under attack (and that have the anti-DDoS feature enabled). Other XT nodes would not be under attach and would accept Tor connections. In short, it would be fine for Tor users as well as regular users only certain regular users would have fewer problems since they'd have a feature that might reduce the connection attacks.

HostFat
Staff
Legendary
*
Offline Offline

Activity: 2604


I support freedom of choice


View Profile WWW
August 27, 2015, 02:25:45 AM
 #516

Not sure why you double posted, but sure. I get what you're saying.

But tell me, if the TX backlog was getting full. Then there was heavy DoS on the network. What would happen to the transactions request from Tor users? Would be still be processed at some point, even when the BTC system is inclined to drop off transactions that will not make it to a block after X conditions are met?
Ooooh! Lips sealed

The TX backlog full is different from a DoS attack of connections on the single node.

The code that put in low priority these IP is activated only if the node is getting a DoS attack of connection on itself, only itself.

There isn't any correlation with the amount of TX the it receives from the network and the connections.

Connections =/= TXs

IF a node is under DoS (by receiving many connection from an attacker) then it (only it) will put Tor connections under low priority. (while under attack)
A rightful request from Tor will have to ask connections from one of the other 6000/7000 nodes.

NON DO ASSISTENZA PRIVATA - The Rock Trading (ref): A good exchange / gateway Ripple, with support for multisig, since 2007. 
https://bitcointa.lk: Bitcointalk backup if offline - Bitcoin Foundation Italia - Blog: http://theupwind.blogspot.it
kano
Legendary
*
Online Online

Activity: 2240


Linux since 1997 RedHat 4


View Profile
August 27, 2015, 02:40:57 AM
 #517

Not sure if you are being disingenuous or you really don't understand. I'll give you the benefit of the doubt and assume the latter.

BIP101 activates *only* if XT has >75% of hashing power.

No, it activates when >75% of the last 1000 blocks *say* they were mined by XT. That can happen with less than 75% of the hash power saying they are running XT, and you also can't assume that just a block was mined by XT just because it says it was. It is quite possible for me to mine blocks saying I'm willing to accept "big blocks" when I'm actually not.


Only gamblers would run XT marked mining operations without accepting larger blocks. I for one don't believe that a significant amount of hashing power will choose to risk the outcome of a contentious hard fork that they would clearly be responsible for by their deceiptful indication of larger block support. Not a likely scenario IMO.
The only pool producing XT blocks is apparently doing exactly that - just marking them as "XT version" and no more.
See slush's comments about his pool.

But more importantly, no pool in their right mind would be running the XT code yet.
The XT code has been severely lacking in testing compared to normal Core code changes.

Pool: https://kano.is Here on Bitcointalk: Forum BTC: 1KanoPb8cKYqNrswjaA8cRDk4FAS9eDMLU
FreeNode IRC: irc.freenode.net channel #kano.is Majority developer of the ckpool code
Help keep Bitcoin secure by mining on pools with full block verification on all blocks - and NO empty blocks!
VirosaGITS
Hero Member
*****
Offline Offline

Activity: 910


Want to save $? Use Coupon Code VOFF5 at GPUShack


View Profile
August 27, 2015, 02:54:15 AM
 #518

Not sure why you double posted, but sure. I get what you're saying.

But tell me, if the TX backlog was getting full. Then there was heavy DoS on the network. What would happen to the transactions request from Tor users? Would be still be processed at some point, even when the BTC system is inclined to drop off transactions that will not make it to a block after X conditions are met?

By heavy DoS on the network, do you mean all nodes? If there was, then we'd have a big problem period - doesn't matter if you are on Tor, running XT or core.

If only some nodes are being DoS'ed then it's fine. Tor users would get dropped from certain XT nodes under attack (and that have the anti-DDoS feature enabled). Other XT nodes would not be under attach and would accept Tor connections. In short, it would be fine for Tor users as well as regular users only certain regular users would have fewer problems since they'd have a feature that might reduce the connection attacks.

Well its true that if its just self-defense of a single node its much less of a big deal.

I would have imagined DDoS focusing on the bigger nodes, slowing the overall network significantly, then combined with a TX spam attack. It would have allowed transaction request from Tor nodes to be dropped since they are lower priority and the network would already be saturated with "legit" tx spam.

This would effectively allowing to filter out transaction from the black listed ip range.

A massive attack of such magnitude isint that unlikely when you think of the several government who doesn't like BTC. To me it just seemed like it was another vulnerability.


Ethereum Mining Calculator - Simple, elegant, mobile-friendly Ethereum Mining Profitability Calculator
gpuShack mining hardware - Your one stop shop for all GPU mining related hardware! Use Coupon Code VOFF5 to save on any order.
ethOS - #ethosdistro on freenode - linux distro that mines Ethereum out-of-the-box.
Eastwind
Hero Member
*****
Offline Offline

Activity: 896



View Profile
August 27, 2015, 03:16:11 AM
 #519

I shall not support XT if it blacklists some ip address.
HostFat
Staff
Legendary
*
Offline Offline

Activity: 2604


I support freedom of choice


View Profile WWW
August 27, 2015, 03:19:24 AM
 #520

I shall not support XT if it blacklists some ip address.
Here a new parrot.

NON DO ASSISTENZA PRIVATA - The Rock Trading (ref): A good exchange / gateway Ripple, with support for multisig, since 2007. 
https://bitcointa.lk: Bitcointalk backup if offline - Bitcoin Foundation Italia - Blog: http://theupwind.blogspot.it
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 [26] 27 28 29 30 31 32 33 34 35 36 37 38 39 40 »
  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!