Pages:
Author

Topic: question - page 6. (Read 5010 times)

legendary
Activity: 1148
Merit: 1014
In Satoshi I Trust
August 29, 2015, 03:27:29 AM
#35
yep. maybe that proposal is just too complicated and will bring too many problems with it.
iam still in favor of a smooth increase over time 2MB, 4 MB, 8MB, 14 MB...

it should be an easy design.
hero member
Activity: 798
Merit: 1000
Move On !!!!!!
August 29, 2015, 02:00:40 AM
#34
Why not mix up those ideas and come up with a better solution? Politics or power wasn't the problem here in the first place, it was about the block size. Those problems about who controls, voting power etc. were just brought up because of who proposes what BIP. Each proposal has their own uniqueness and may help bitcoin in any way, so why not mix all of those and come up with a better solution? Huh

Well this will eventually happen and this is a decision making process that is taking place at the moment.

For God's sake, why doesn't one of these devs doesn't come up with a BIP that just increases block size, on a fixed or a dynamic schedule with no add-ons, with no giving power to anybody more or less.

Now, after reading more and more, it seems to me that every BIP proposal favors someone, gives advantages to someone, and saves somebody's a**. Even BIP100, after reading more about it.
legendary
Activity: 2674
Merit: 2965
Terminated.
August 29, 2015, 01:52:58 AM
#33
If we actually had to give anyone some power, it would be the miners. Don't tell me that you would want to give power to random people who aren't actually doing anything for the network (compared to them).
BIP100 is better than BIP101 in any case. However, since BIP100 isn't implemented changes are possible. Someone needs to tell Jeff to implement the dynamic block size from the other proposal into BIP100 (and the 'problem' would be solved).
legendary
Activity: 3248
Merit: 1070
August 29, 2015, 01:12:40 AM
#32
maybe 2MB now - 4 MB in 2 years and 8MB in 4 years is not that bad...

wasn't this the initial gavin proposal? it was discarded because of the need to fork every time, if i'm not mistaken

hero member
Activity: 756
Merit: 502
CryptoTalk.Org - Get Paid for every Post!
August 29, 2015, 12:52:21 AM
#31

lol.... there is no need to run xt if you want to vote for bip101.

please show me code which does blacklist ip's. you cant...

fudfudfud Wink

http://cointelegraph.com/news/115153/bitcoin-xt-fork-can-blacklist-tor-exits-may-reveal-users-ip-addresses

https://github.com/mikehearn/bitcoinxt/commit/5e62628118e7e5df2c19093911d04d197a12d0e7

and here is the list right now.  Wink

That code does not blacklist IPs. It reduces priority of TOR exit node IPs so that in the event of a denial of service attack against that node, clearnet IPs are prioritized higher.  After the attack is over, any disconnected nodes can reconnect.  Does that really sound like a blacklist to you?

The most common definition of "blacklist" is "a list of people or products viewed with suspicion or disapproval." That's exactly what it is. Hearn's justification is that "jamming attacks via Tor have been observed" -- therefore, isolate and compile a list of said [suspicious] IPs. Now we can speculate all day about which IP addresses will end up on that list in the end (whether that means virtually all known proxies, specific regions, etc) or whether there are more nefarious plans at hand.

At the end of the day, trusting a third party to compile a list of suspicious IPs is the definition of centralization and trust.

Nodes are perfectly capable of recognizing IPs that are DDOSing them, and deprioritizing them accordingly. There is no need for a centralized list. There is no need to isolate TOR. There is ZERO justification to push such a centralized solution. So why do people keep doing it?

I can't help but feel ashamed of the bitcoin community when I see these basic things -- which are antithetical to bitcoin -- justified for no reason.
hero member
Activity: 493
Merit: 500
August 28, 2015, 10:35:35 PM
#30

lol.... there is no need to run xt if you want to vote for bip101.

please show me code which does blacklist ip's. you cant...

fudfudfud Wink

http://cointelegraph.com/news/115153/bitcoin-xt-fork-can-blacklist-tor-exits-may-reveal-users-ip-addresses

https://github.com/mikehearn/bitcoinxt/commit/5e62628118e7e5df2c19093911d04d197a12d0e7

and here is the list right now.  Wink

That code does not blacklist IPs. It reduces priority of TOR exit node IPs so that in the event of a denial of service attack against that node, clearnet IPs are prioritized higher.  After the attack is over, any disconnected nodes can reconnect.  Does that really sound like a blacklist to you?
legendary
Activity: 1484
Merit: 1004
August 28, 2015, 10:28:12 PM
#29

lol.... there is no need to run xt if you want to vote for bip101.

please show me code which does blacklist ip's. you cant...

fudfudfud Wink

http://cointelegraph.com/news/115153/bitcoin-xt-fork-can-blacklist-tor-exits-may-reveal-users-ip-addresses

https://github.com/mikehearn/bitcoinxt/commit/5e62628118e7e5df2c19093911d04d197a12d0e7

and here is the list right now.  Wink
hero member
Activity: 493
Merit: 500
August 28, 2015, 09:31:52 PM
#28
The problem is not on the network bandwidth, CPU just can not finish verifying a large block in 10 minutes before the next one arrives

This just isn't correct.  CPU is not the bottleneck, and will not be the bottleneck.  Your CPU is capable of processing vastly more transaction data than your network card can throw at it.
legendary
Activity: 2422
Merit: 1451
Leading Crypto Sports Betting & Casino Platform
August 28, 2015, 08:42:06 PM
#27
Well, with even Mike Hearn saying that BIP100 is just an idea, I think that we should wait before making harsh assumptions. There's a chance to rethink weaknesses, discuss and implement afterwards. What's good about that however, is that support towards the basis of this proposal has already started forming and it's quite strong. This way I think that there are going to be decent efforts at creating what was expressed in the papers. It's also notable that Jeff is having an 'open' approach for the development.
legendary
Activity: 1988
Merit: 1012
Beyond Imagination
August 28, 2015, 08:37:29 PM
#26
I have noticed that even at today's average 400kb per block transaction data, the synchronization is already painfully slow on a normal PC if you missed several weeks of data. 8MB block will make most of the commercially available computer unable to catch up with the network. The problem is not on the network bandwidth, CPU just can not finish verifying a large block in 10 minutes before the next one arrives
full member
Activity: 196
Merit: 100
August 28, 2015, 02:04:56 PM
#25
a dev should make a BIP that makes block limit increase the same way difficulty increases

I always thought something like this would be ideal. I have been told, however, that a dynamic solution based on actual volume vs. capacity would be easy to attack and lead to more orphaned blocks. Don't really know the details, though. Can anyone help with those? Smiley

You're right, its not easy to measure the parameter that determines the blocksize limit, which is technology available.

One think blocksize limit can be treated as difficulty, one is completely delusional.

hero member
Activity: 756
Merit: 502
CryptoTalk.Org - Get Paid for every Post!
August 28, 2015, 12:59:52 PM
#24
a dev should make a BIP that makes block limit increase the same way difficulty increases

I always thought something like this would be ideal. I have been told, however, that a dynamic solution based on actual volume vs. capacity would be easy to attack and lead to more orphaned blocks. Don't really know the details, though. Can anyone help with those? Smiley
hero member
Activity: 493
Merit: 500
August 28, 2015, 12:56:15 PM
#23
they hoped it would go unnoticed, or that the NEED to change the limit would force poeple to use XT even tho they disagreed with IP blacklisting and the checkpoint thingy.

Prioritizing != blacklisting.
Checkpoint discussion != code change.
sr. member
Activity: 252
Merit: 251
August 28, 2015, 11:00:17 AM
#22
Merchants tend to favor BIP101 and miners tend to favor BIP100.

BIP100 give too much power for miners while BIP101 hide many things from us
But, BIP101 would fail if miners won't support BIP101 Roll Eyes

Maybe we should think about 8MB proposal from miners Roll Eyes

I think you confuse BIP101 and XT. Nonetheless both are open source so can’t really hide anything.

that didnt stop XT from trying.  Tongue

they must really suck at hiding if they use github and comment their commits and even make websites explaining what they do?

ahh now i understand: YOU are the one hiding your agenda and trying to spread FUD

they hoped it would go unnoticed, or that the NEED to change the limit would force poeple to use XT even tho they disagreed with IP blacklisting and the checkpoint thingy.



lol.... there is no need to run xt if you want to vote for bip101.

please show me code which does blacklist ip's. you cant...

fudfudfud Wink
legendary
Activity: 1904
Merit: 1037
Trusted Bitcoiner
August 28, 2015, 10:55:40 AM
#21
Merchants tend to favor BIP101 and miners tend to favor BIP100.

BIP100 give too much power for miners while BIP101 hide many things from us
But, BIP101 would fail if miners won't support BIP101 Roll Eyes

Maybe we should think about 8MB proposal from miners Roll Eyes

I think you confuse BIP101 and XT. Nonetheless both are open source so can’t really hide anything.

that didnt stop XT from trying.  Tongue

they must really suck at hiding if they use github and comment their commits and even make websites explaining what they do?

ahh now i understand: YOU are the one hiding your agenda and trying to spread FUD

they hoped it would go unnoticed, or that the NEED to change the limit would force poeple to use XT even tho they disagreed with IP blacklisting and the checkpoint thingy.

sr. member
Activity: 252
Merit: 251
August 28, 2015, 10:38:41 AM
#20
Merchants tend to favor BIP101 and miners tend to favor BIP100.

BIP100 give too much power for miners while BIP101 hide many things from us
But, BIP101 would fail if miners won't support BIP101 Roll Eyes

Maybe we should think about 8MB proposal from miners Roll Eyes

I think you confuse BIP101 and XT. Nonetheless both are open source so can’t really hide anything.

that didnt stop XT from trying.  Tongue

they must really suck at hiding if they use github and comment their commits and even make websites explaining what they do?

ahh now i understand: YOU are the one hiding your agenda and trying to spread FUD
legendary
Activity: 1148
Merit: 1014
In Satoshi I Trust
August 28, 2015, 10:35:02 AM
#19
maybe 2MB now - 4 MB in 2 years and 8MB in 4 years is not that bad...
legendary
Activity: 2870
Merit: 7490
Crypto Swap Exchange
August 28, 2015, 10:04:10 AM
#18
Merchants tend to favor BIP101 and miners tend to favor BIP100.

BIP100 give too much power for miners while BIP101 hide many things from us
But, BIP101 would fail if miners won't support BIP101 Roll Eyes

Maybe we should think about 8MB proposal from miners Roll Eyes
legendary
Activity: 1904
Merit: 1037
Trusted Bitcoiner
August 28, 2015, 10:19:46 AM
#18
Merchants tend to favor BIP101 and miners tend to favor BIP100.

BIP100 give too much power for miners while BIP101 hide many things from us
But, BIP101 would fail if miners won't support BIP101 Roll Eyes

Maybe we should think about 8MB proposal from miners Roll Eyes

I think you confuse BIP101 and XT. Nonetheless both are open source so can’t really hide anything.

that didnt stop XT from trying.  Tongue
legendary
Activity: 1372
Merit: 1000
--------------->¿?
August 28, 2015, 10:15:51 AM
#17
Merchants tend to favor BIP101 and miners tend to favor BIP100.

BIP100 give too much power for miners while BIP101 hide many things from us
But, BIP101 would fail if miners won't support BIP101 Roll Eyes

Maybe we should think about 8MB proposal from miners Roll Eyes

I think you confuse BIP101 and XT. Nonetheless both are open source so can’t really hide anything.
Pages:
Jump to: