Bitcoin Forum

Bitcoin => Bitcoin Discussion => Topic started by: LiteCoinGuy on December 30, 2015, 05:00:59 PM



Title: Small blocksize increase should be done first and SegWit second
Post by: LiteCoinGuy on December 30, 2015, 05:00:59 PM
Why I feel a small blocksize increase should be done first and SegWit done, as soon as safely possible, second

It is important to realize that SegWit actually is a block-size increase if you don't play semantic games. They are breaking apart the block data into two streams, both of which have to be stored on the users hard drive. The combined size of the two streams will increase the disk space requirements for full nodes.

It is important to note the hypocrisy here. For months the core party line against having a blocksize increase was because it would hurt centralization due to the increased bandwidth and disk space requirements. However, SegWit has essentially the same increased bandwidth and disk space requirements as a simple blocksize increase. It is the same data, just stored into two separate streams instead of one. Now, they are all in favor of increasing the bandwidth and disk space requirements (in the form of SegWit) but their excuse is that it can be done via a 'safe' soft fork instead of an 'evil' hard fork. The goal posts move an awful lot with these guys.

The reason to do SegWit is less about scaling and more because it is a relatively clean fix to the long standing transaction malleability problem.

The reasons not to hold up a blocksize increase for SegWit should be obvious. Remember, both approaches ARE a blocksize increase. It is just that one plays a semantic game by breaking the blocks apart into two interleaved streams of data; which adds a remarkable amount of complexity by the way.

Let's compare the two approaches.

Increase the blocksize limit

    -A single line code change to the client
    -Unlikely to break hardly any existing software anywhere or, if it does, the fix will also just be a one line code change
    -Has roughly the same disk footprint requirements as SegWit
    -Does nothing about transaction malleability
    -Requires a hard fork
    -Could be done on a much shorter time scale since the risk is extremely low and updating software extremely trivial
    -Immediately provides a doubling of the transaction capacity of the entire bitcoin network as soon as it is activated.

SegWit

    -Fixes transaction malleability (YEAH!)
    -Increases disk space requirement roughly the same as a blocksize increase would.
    -It is a highly complex code change that will require a lengthy period of time to be fully vetted and tested.
    -If done as a soft-fork, instead of a hard fork, it will be even more complicated and 'silently' break nearly every piece of software in the existing infrastructure
    -Breaks almost all wallets, nodes, and block-explorer type apps, requiring a significant code refactor to be able to parse and correctly interpret the separate signature stream. Could cause some wallets and explorers to crash and many nodes to fail to validate fully.
    -If done as a hard fork it is much, much, safer, because it won't be activated until most of the network has upgraded their software and with a substantial lead time.
    -Doesn't actually achieve the transaction throughput benefit until the entire software infrastructure has switched over to using the new feature; which will be 'opt-in'.

In my opinion, we should do both, but do a 2mb blocksize increase as soon as possible and SegWit once it has been fully vetted and thoroughly tested.

Unlike the vast screaming hordes, I do not believe that hard forks are dangerous or something to be avoided. I strongly believe we need to change this mentality. The bitcoin ecosystem must be agile enough to upgrade software on a fairly regular basis; this is a basic requirement of any modern software development project.

I much prefer that SegWit be done as a hard fork, it is simply much, much, safer to do it that way. It introduces a lot of complexity and will have numerous dangerous side effects throughout the ecosystem if done 'silently' as a soft-fork.

https://www.reddit.com/r/btc/comments/3ypkhd/why_i_feel_a_small_blocksize_increase_should_be/



that would be a compromise and the war could be over. everyone (except Peter Todd) can live with that.


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: Amph on December 30, 2015, 05:45:55 PM
afaik segwit, it's only an effective 2mb increase as average with a 4mb as a peak, so it would be pointless to do it after a mini increase like 2mb


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: LiteCoinGuy on December 30, 2015, 08:05:50 PM
afaik segwit, it's only an effective 2mb increase as average with a 4mn as a peak, so it would be pointless to do it after a mini increase like 2mb

segwit is an increase of only 1,75 - 2 MB in the mid term and much more complicated than the 2 MB increase.

a 2 MB hard fork (which everyone agrees on and has zero risks / easy to deploy) will at least double the capazity.

funny that we are now at 2 MB and not even then some devs like Peter Todd agree on that. i guess when one or two people can veto against the will of 99%, bitcoin is in trouble.


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: keepdoing on December 30, 2015, 08:18:28 PM
afaik segwit, it's only an effective 2mb increase as average with a 4mn as a peak, so it would be pointless to do it after a mini increase like 2mb

segwit is an increase of only 1,75 - 2 MB in the mid term and much more complicated than the 2 MB increase.

a 2 MB hard fork (which everyone agrees on and has zero risks / easy to deploy) will at least double the capazity.

funny that we are now at 2 MB and not even then some devs like Peter Todd agree on that. i guess when one or two people can veto against the will of 99%, bitcoin is in trouble.
This is a good proposal / thread.  So simple, so realistic.  Would be nice to see some sort of mini-automated scaling built in to the increase at a minimum.  But the above highlight really is the issue.  You've got a few people that are willing to sink the ship to get their way, even if in the end they drown themselves.  So sad.


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: helloeverybody on December 30, 2015, 08:26:02 PM
From mu limited knowledge on the subject, from what ive read so far there will be a blocksize increase at some point correct? and if so then why not at least move us up to 2mb to at least keep us going in the meantime?


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: BitcoinNewsMagazine on December 30, 2015, 08:41:25 PM
Core developers have made it crystal clear they will do whatever is in their power to delay the hardfork required for a blocksize increase. I think the best you can hope for is SegWit integration by soft fork about April 2016, then a hardfork about one year later to adopt the BIP miners most prefer.


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: keepdoing on December 30, 2015, 08:47:40 PM
Core developers have made it crystal clear they will do whatever is in their power to delay the hardfork required for a blocksize increase. I think the best you can hope for is SegWit integration by soft fork about April 2016, then a hardfork about one year later to adopt the BIP miners most prefer.
If I honestly believed that was a possible outcome - I would sell my bitcoins today.


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: Amph on December 30, 2015, 09:13:40 PM
afaik segwit, it's only an effective 2mb increase as average with a 4mn as a peak, so it would be pointless to do it after a mini increase like 2mb

segwit is an increase of only 1,75 - 2 MB in the mid term and much more complicated than the 2 MB increase.

a 2 MB hard fork (which everyone agrees on and has zero risks / easy to deploy) will at least double the capazity.

funny that we are now at 2 MB and not even then some devs like Peter Todd agree on that. i guess when one or two people can veto against the will of 99%, bitcoin is in trouble.

actually it seems that segwit is even less, around 1.3, i had a conversation with a guy here saying this https://bitcointalk.org/index.php?topic=1299293.msg13328502#msg13328502


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: brg444 on December 30, 2015, 09:18:38 PM
afaik segwit, it's only an effective 2mb increase as average with a 4mn as a peak, so it would be pointless to do it after a mini increase like 2mb

segwit is an increase of only 1,75 - 2 MB in the mid term and much more complicated than the 2 MB increase.

a 2 MB hard fork (which everyone agrees on and has zero risks / easy to deploy) will at least double the capazity.

funny that we are now at 2 MB and not even then some devs like Peter Todd agree on that. i guess when one or two people can veto against the will of 99%, bitcoin is in trouble.

actually it seems that segwit is even less, around 1.3, i had a conversation with aguy here saying this https://bitcointalk.org/index.php?topic=1299293.msg13328502#msg13328502

Obviously no one knows but 1.3 is pretty conservative.

Understand that service providers and wallets responsible for most of the transactions on the network have a strong economic incentive to be proactive and implement SW as soon as possible so it is reasonable to expect SW to be deployed by most major companies quite quickly.



Title: Re: Small blocksize increase should be done first and SegWit second
Post by: Lauda on December 30, 2015, 10:36:24 PM
Why I feel a small blocksize increase should be done first and SegWit done, as soon as safely possible, second
'Why I (a person without no relevant background) feel we should do X before Y' is what I read. Not trying to be offensive but this has zero meaning to the important people in the ecosystem.


One of the main problems is that people (especially some of the developers) are afraid of a hard fork. I have no idea why that is. If there were warnings pretty much everywhere about the required change (incl. alert system), I'm pretty sure that we would come close to 99% of clients upgrading to the next version. I always wondered why they don't bump it up to 2 MB or something and then proceed with their roadmap. Those so called "developers for X years" that are complaining about complexity of the code are just average (if not worse) developers that have never worked on really huge projects.


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: maokoto on December 30, 2015, 10:49:37 PM
Yes, the blocksize things seems to be a neverending issue, although in most people's eyes it does not seem as complicated and the majority advocates the blocksize rise.


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: franky1 on December 30, 2015, 11:34:46 PM
segwit is a sham!

the reasons for the 1mb block rule is that nodes hard drives should only grow by 1mb a block..

segwit wants to trick the bitcoin-core (fullnode) code by throwing only 70% of txdata into the 1mb block and putting the other 30% on the side.. but that simply makes fullnodes hard drives 1.3mb growth per block... which invalidates the whole damn point of the 1mb limit in the first place!

if lite clients want only 0.7mb per block by throwing away signatures.. then let them parse and ignore that data when they save the data locally to their lite client hard drives.. because bait and switching data in a full node is just tricking the blocklimit rule... which is implimented to keep hard drive space of full nodes below 1mb..
so it makes no sense to keep the 1mb block limit if hard drive storage increases by 1.3mb a block.. as the only reason for the limit is hard drive space rationing..

segwit just makes no sense in respects to the data structure of splitting the chain for full nodes.. again that all can be done by lite clients without even touching bitcoin-core source code


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: brg444 on December 30, 2015, 11:45:36 PM
segwit is a sham!

the reasons for the 1mb block rule is that nodes hard drives should only grow by 1mb a block..

segwit wants to trick the bitcoin-core (fullnode) code by throwing only 70% of txdata into the 1mb block and putting the other 30% on the side.. but that simply makes fullnodes hard drives 1.3mb growth per block... which invalidates the whole damn point of the 1mb limit in the first place!

if lite clients want only 0.7mb per block by throwing away signatures.. then let them parse and ignore that data when they save the data locally to their lite client hard drives.. because bait and switching data in a full node is just tricking the blocklimit rule... which is implimented to keep hard drive space of full nodes below 1mb..
so it makes no sense to keep the 1mb block limit if hard drive storage increases by 1.3mb a block.. as the only reason for the limit is hard drive space rationing..

segwit just makes no sense in respects to the data structure of splitting the chain for full nodes.. again that all can be done by lite clients without even touching bitcoin-core source code

The point of segwit is not to persist with the 1MB limit but to accomodate more room for transactions without having to do a hard fork and meanwhile solve a plethora of issues with regards to malleability.

It doesn't want to trick anyone and you're talking a whole lot of nonsense.


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: keepdoing on December 30, 2015, 11:56:42 PM

The point of segwit is not to persist with the 1MB limit but to accomodate more room for transactions without having to do a hard fork and meanwhile solve a plethora of issues with regards to malleability.

It doesn't want to trick anyone and you're talking a whole lot of nonsense.
More lying nonsense from the Blockstream Puppets.  The MAIN point of Segwit is to buy time so that Blockstream can gain advantage in it's war for control over the financial institutions.

Mike Hearn is willing to mutate Bitcoin into a monster that can be used to crush the people.  Blockstream Puppets want to cripple Bitcoin so they can control it, keep it in a box that only they have the keys to.

Bunch of Biased, Untrustworthy, Selfish, Shortsighted, Greedy Scum.   It's like watching 2 political parties have a debate.  You know that while both have differing pitches, they both are lying and in the end you'll all get screwed.  2 sides of the same coin.


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: brg444 on December 30, 2015, 11:59:23 PM

The point of segwit is not to persist with the 1MB limit but to accomodate more room for transactions without having to do a hard fork and meanwhile solve a plethora of issues with regards to malleability.

It doesn't want to trick anyone and you're talking a whole lot of nonsense.
More lying nonsense from the Blockstream Puppets.  The MAIN point of Segwit is to buy time so that Blockstream can gain advantage in it's war for control over the financial institutions.

 ::)

I mean I understand if you feel alone this Christmas but no need to come and spread your delusions all over the forum.


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: franky1 on December 31, 2015, 12:02:33 AM

The point of segwit is not to persist with the 1MB limit but to accomodate more room for transactions without having to do a hard fork and meanwhile solve a plethora of issues with regards to malleability.

It doesn't want to trick anyone and you're talking a whole lot of nonsense.

accomodating more transactions means making full nodes store over 1mb of hard drive storage, which negates the whole point of the 1mb limit.
accomodating more transactions means upgrading peoples clients to be able to stay part of the network if miners are using segwit.. (meaning its not a soft fork)

a soft fork is where fullnodes see no difference, require no upgrades and its just other people that treat the data differently locally to themselves.. a hard fork is where it affects everyone and they need to upgrade their bitcoin-core to stay part of the same network..

segwit should not make such change to bitcoin-core.. as making miners change how a block is created and is relayed IS A HARD FORK!!! because other people would need to upgrade too just to get the same data as miners push out


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: brg444 on December 31, 2015, 12:02:38 AM
segwit is a sham!

the reasons for the 1mb block rule is that nodes hard drives should only grow by 1mb a block..

segwit wants to trick the bitcoin-core (fullnode) code by throwing only 70% of txdata into the 1mb block and putting the other 30% on the side.. but that simply makes fullnodes hard drives 1.3mb growth per block... which invalidates the whole damn point of the 1mb limit in the first place!

if lite clients want only 0.7mb per block by throwing away signatures.. then let them parse and ignore that data when they save the data locally to their lite client hard drives.. because bait and switching data in a full node is just tricking the blocklimit rule... which is implimented to keep hard drive space of full nodes below 1mb..
so it makes no sense to keep the 1mb block limit if hard drive storage increases by 1.3mb a block.. as the only reason for the limit is hard drive space rationing..

segwit just makes no sense in respects to the data structure of splitting the chain for full nodes.. again that all can be done by lite clients without even touching bitcoin-core source code

The point of segwit is not to persist with the 1MB limit but to accomodate more room for transactions without having to do a hard fork and meanwhile solve a plethora of issues with regards to malleability.

It doesn't want to trick anyone and you're talking a whole lot of nonsense.

It's just a hard fork tho. Srsly. What's the big woop?

Have a look at network nodes version distribution?

Although knowing you people surely you wouldn't feel bad about leaving a couple of persons behind.


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: BlindMayorBitcorn on December 31, 2015, 12:04:09 AM
^Not true. I have a strong sense of decency!


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: franky1 on December 31, 2015, 12:05:14 AM

Have a look at network nodes version distribution?

Although knowing you people surely you wouldn't feel bad about leaving a couple of persons behind.

so you admit, that people would need to upgrade and download a new version just to be a full node and stay part of the network...
hmmmm hard fork!


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: brg444 on December 31, 2015, 12:08:04 AM
accomodating more transactions means upgrading peoples clients to be able to stay part of the network if miners are using segwit.. (meaning its not a soft fork)

No.

Full nodes who have not updated can still safely use and deal with regular transactions and fully verify every economic activity they are involved with.

require no upgrades and its just other people that treat the data differently locally to themselves..

That's exactly what segwit does

segwit should not make such change to bitcoin-core.. as making miners change how a block is created and is relayed IS A HARD FORK!!!

Not true, miners will still push out blocks containing regular transactions which the full nodes who haven't updated can still fully verify.

Segwit does not change the nature of the blocks so as to make it incompatible with older Core versions. That's just plain wrong.


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: franky1 on December 31, 2015, 12:12:56 AM
all im saying is that while bitcoin-core can stay the same...

people can if they want less data is download a lite client that ignores data it doesnt need..

but changing bitcoin core, which will mean everyone needs to upgrade to bitcoin-core-sw is a damn hard fork.. and these bitcoin-core-sw would still be storing 1.3mb of data even with a 1.0mb block rule.. which makes the point of the rule useless..

because relaying data that has no signatures will throw up errors for people running older versions of bitcoin-core.. meaning bitcoin-core users would need to upgrade just to see and accept these new blocks..

so it is a hard fork!!


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: franky1 on December 31, 2015, 12:20:12 AM

Not true, miners will still push out blocks containing regular transactions which the full nodes who haven't updated can still fully verify.

Segwit does not change the nature of the blocks so as to make it incompatible with older Core versions. That's just plain wrong.

2 merkle tree's instead of one sounds very much like changing the nature of a block making relayed data incompatible with older clients
relaying txdata without signatures sounds like making relayed data incompatible with older clients

older clients that receives a block(with 1.3mb data(with signatures) will throw up an error
older clients that receives a block(with 1.0mb data(no signatures) will throw up an error

in both cases they will orphan those blocks and treat them as invalid. which is a fork! as they would only accept standard blocks..

and if you are going to now say that mining pools dont handle blocks differently.. then that means that there will still be a 4000tx per 1mb limit as always and not the 5000tx potential segwit 'promises'

the only way segwit can promise more transactions is to change how blocks are created and relayed.. which will affect older clients..


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: franky1 on December 31, 2015, 12:28:51 AM
so brg444
answer this
will segwit just be a lite client that doesnt change anything for bitcoin-core. but allows people the option to download a lite client that stores only 0.7mb per block
thus not affecting older versions or current versions of bitcoin-core. nor increasing tx/s because miners dont change anything

or

will segwit want miners to upgrade so that they change to 2merkle tree's and store 1.3mb of data, so that they can bait and switch 5000tx per block in the main merkle.. meaning older bitcoin-core users will get errors requiring an upgrade just to be able to accept these new blocks..


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: brg444 on December 31, 2015, 01:19:43 AM

Not true, miners will still push out blocks containing regular transactions which the full nodes who haven't updated can still fully verify.

Segwit does not change the nature of the blocks so as to make it incompatible with older Core versions. That's just plain wrong.

2 merkle tree's instead of one sounds very much like changing the nature of a block making relayed data incompatible with older clients
relaying txdata without signatures sounds like making relayed data incompatible with older clients

older clients that receives a block(with 1.3mb data(with signatures) will throw up an error
older clients that receives a block(with 1.0mb data(no signatures) will throw up an error

in both cases they will orphan those blocks and treat them as invalid. which is a fork! as they would only accept standard blocks..

and if you are going to now say that mining pools dont handle blocks differently.. then that means that there will still be a 4000tx per 1mb limit as always and not the 5000tx potential segwit 'promises'

the only way segwit can promise more transactions is to change how blocks are created and relayed.. which will affect older clients..

I'd very much like to answer your questions but you are seemingly so confused I really don't know where to start.

May I suggest reading the BIP? https://github.com/bitcoin/bips/pull/265

You have a fundamental misunderstanding of how it works.

Quote
As a soft fork, older software will continue to operate without modification.  Non-upgraded nodes, however, will not see nor validate the witness data and will consider all witness programs as anyone-can-spend scripts (except a few edge cases in version 0 witness programs which are provably unspendable with original script semantics). Wallets should always be wary of anyone-can-spend scripts and treat them with suspicion. Non-upgraded nodes are strongly encouraged to upgrade in order to take advantage of the new features.


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: franky1 on December 31, 2015, 01:37:31 AM

Quote
As a soft fork, older software will continue to operate without modification.  Non-upgraded nodes, however, will not see nor validate the witness data and will consider all witness programs as anyone-can-spend scripts (except a few edge cases in version 0 witness programs which are provably unspendable with original script semantics). Wallets should always be wary of anyone-can-spend scripts and treat them with suspicion. Non-upgraded nodes are strongly encouraged to upgrade in order to take advantage of the new features.

witness data is transaction info!!!!!

to older clients it would appear as screwed up tx's it cant validate.. meaning old clients will fork because they dont see it as valid..
meaning to stay on the network validating transactions (which is what a fullnode should do) they need to upgrade
meaning its a damned hard fork!! because not upgrading makes old (true fullnodes) become limp and unsecure!!

seriously are you being paid by the guys that want segwit!!


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: brg444 on December 31, 2015, 01:39:43 AM

Quote
As a soft fork, older software will continue to operate without modification.  Non-upgraded nodes, however, will not see nor validate the witness data and will consider all witness programs as anyone-can-spend scripts (except a few edge cases in version 0 witness programs which are provably unspendable with original script semantics). Wallets should always be wary of anyone-can-spend scripts and treat them with suspicion. Non-upgraded nodes are strongly encouraged to upgrade in order to take advantage of the new features.

witness data is transaction info!!!!!

to older clients it would appear as screwed up tx's it cant validate.. meaning old clients will fork because they dont see it as valid..
meaning to stay on the network validating transactions (which is what a fullnode should do) they need to upgrade
meaning its a damned hard fork!! because not upgrading makes old (true fullnodes) become limp and unsecure!!

seriously are you being paid by the guys that want segwit!!

Segwit is a feature. It is not forced on everyone. If you do not choose to you can still send and receive regular transactions whose signature data is not segregated.

Full nodes continue to validate regular transactions.
Upgraded full nodes validate Segwit data

Happy?

We can't have this conversation if you continue to play stupid.


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: franky1 on December 31, 2015, 01:44:50 AM

Full nodes continue to validate regular transactions.
Upgraded full nodes validate Segwit data

Happy?

We can't have this conversation if you continue to play stupid.

full nodes should validate ALL DATA.. this is forcing full nodes to become limp and not full nodes. and to require upgrade to become full nodes again..

its not a soft fork at all..
please stop looking at your increased bank account, look outside the box and realise that its a fork.. that does not benefit any true full nodes as the true full nodes would be storing 1.3mb of data.. instead of 1.. while you SW fan boys tell people its only 1mb

seriously if people need to upgrade just to fully validate.. then you might aswell just raise the limit to 2mb because people that want to be full nodes will be upgrading anyway..


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: brg444 on December 31, 2015, 01:51:14 AM

Full nodes continue to validate regular transactions.
Upgraded full nodes validate Segwit data

Happy?

We can't have this conversation if you continue to play stupid.

full nodes should validate ALL DATA.. this is forcing full nodes to become limp and not full nodes. and to require upgrade to become full nodes again..

its not a soft fork at all..
please stop looking at your increased bank account, look outside the box and realise that its a fork.. that does not benefit any true full nodes as the true full nodes would be storing 1.3mb of data.. instead of 1.. while you SW fan boys tell people its only 1mb

seriously if people need to upgrade just to fully validate.. then you might aswell just raise the limit to 2mb because people that want to be full nodes will be upgrading anyway..

You can continue to fully validate whatever transactions you are involved with as long as you don't need to deal with SW.

If you must receive or sent transactions involved segwit than you upgrade.

The security model is exactly the same for full nodes who don't upgrade


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: johnyj on December 31, 2015, 03:11:25 AM
IMO, the biggest difficulty for SW to be adopted is its complexity

Some ideas are easy to explain but hard to execute. Other ideas are easy to execute but hard to explain. Segregated witness (segwit) seems to be the latter.

Ok it is very easy to write the code and implement it, but to convince the users to use your client is totally another story. Since SW is so difficult to explain, majority of users without enough time to dig into the slides and codes for weeks will just ignore it and take the simple approach of raise the block to 2MB

If you are operating a million dollar worth of mining farms, are you going to risk your investments on a set of not-time-tested new architecture which even the author have difficulty to explain to you how it works?


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: franky1 on December 31, 2015, 03:35:24 AM
IMO, the biggest difficulty for SW to be adopted is its complexity

Some ideas are easy to explain but hard to execute. Other ideas are easy to execute but hard to explain. Segregated witness (segwit) seems to be the latter.

Ok it is very easy to write the code and implement it, but to convince the users to use your client is totally another story. Since SW is so difficult to explain, majority of users without enough time to dig into the slides and codes for weeks will just ignore it and take the simple approach of raise the block to 2MB

If you are operating a million dollar worth of mining farms, are you going to risk your investments on a set of not-time-tested new architecture which even the author have difficulty to explain to you how it works?


if mining pools dont upgrade. they wont accept SW transactions..  as told here:
You can continue to fully validate whatever transactions you are involved with as long as you don't need to deal with SW.
If you must receive or sent transactions involved segwit than you upgrade.
and users of SW will drop it and go back to bitcoin-core v0.12 instantly because their SW tx's are not being accepted and validated

if mining pools do upgrade to v0.13sw. the merkle tree is now 2 not one. and the data bloat for mining pools is 1.3mb not 1.0. (which negates the point of the 1mb)
v0.12 full node clients will then feel limp and receiving data they cannot check and so they are forced to upgrade..

now in my last 2 sentences.. if mining pools and full node clients are upgrading and mining pools are happy to have more than 1mb of data per block(which they have to be to even allow SW).. we might aswell up the block limit to 2mb and not have to make 2 merkle tree's

the SW fanboys are underselling the impact and overselling the features.. just for a 30% possible reduction for liteclients (but 30% increase for full nodes)

there are easier ways to increase the blocksize and implement malleability fixes. which if people need to upgrade.. should be done properly.. not this half assed manipulation that is only a temporary fix..

separately, lite clients can still save data by simply not saving signatures when they put it on their hard drives.. which should be a local decision for that lite client.. not a network decision


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: Cconvert2G36 on December 31, 2015, 03:41:05 AM
-snip-
If you must receive or sent transactions involved segwit than you upgrade.

The security model is exactly the same for full nodes who don't upgrade

These two sentences are contradictory.


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: LiteCoinGuy on December 31, 2015, 11:12:33 AM
IMO, the biggest difficulty for SW to be adopted is its complexity

Some ideas are easy to explain but hard to execute. Other ideas are easy to execute but hard to explain. Segregated witness (segwit) seems to be the latter.

Ok it is very easy to write the code and implement it, but to convince the users to use your client is totally another story. Since SW is so difficult to explain, majority of users without enough time to dig into the slides and codes for weeks will just ignore it and take the simple approach of raise the block to 2MB

If you are operating a million dollar worth of mining farms, are you going to risk your investments on a set of not-time-tested new architecture which even the author have difficulty to explain to you how it works?


i agree.

Sipa has even agreed (on IRC) that the closer short term (2016) numbers are around 1.25 with soft fork adoption rates based on historical data, NOT 1.75x. 1.75x is a assumption of 100% adoption including all wallet providers, exchanges, PSP's upgrading to support SW style transactions, which we can all agree is not going to happen in 2016. Its going to take 6 months to code, test and deploy IF we are lucky, which puts us at 2017 before 100% adoption occurs.


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: brg444 on December 31, 2015, 02:16:00 PM
if mining pools dont upgrade. they wont accept SW transactions..  

That just tells me you don't know what the hell you're talking about. SegWit, as with every other softfork, is enforced when a supermajority of miners upgrade.

if mining pools do upgrade to v0.13sw. the merkle tree is now 2 not one.

FOR SEGWIT TRANSACTIONS. Regular transactions w/ signature data still contained within original merkel tree still exist ie. backward compatible.

v0.12 full node clients will then feel limp and receiving data they cannot check and so they are forced to upgrade..

Are nodes who did not yet upgrade to a version supporting CLTV also not full nodes because they can't verify related transactions?

now in my last 2 sentences.. if mining pools and full node clients are upgrading and mining pools are happy to have more than 1mb of data per block(which they have to be to even allow SW).. we might aswell up the block limit to 2mb and not have to make 2 merkle tree's

backward compatible. nodes who choose not to upgrade will still process at maximum 1mb of data per block.



Title: Re: Small blocksize increase should be done first and SegWit second
Post by: ATguy on January 01, 2016, 07:57:44 AM
One of the main problems is that people (especially some of the developers) are afraid of a hard fork. I have no idea why that is. If there were warnings pretty much everywhere about the required change (incl. alert system), I'm pretty sure that we would come close to 99% of clients upgrading to the next version. I always wondered why they don't bump it up to 2 MB or something and then proceed with their roadmap.


Obviously even emergency hardforks had been used in the past where you had update immediatelly, but it created havoc. For acceptable hardfork no one needs to fear (or make argue of fear to prevent hardfork), you need the change in Bitcoin client long time preferrably almost a year before most nodes naturally updates to this version of the Bitcoin client. But obviously even increasing to 2MB is not plan of current Bitcoin devs for 2016, they just pave the way to Blockstream


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: MyBTT on January 01, 2016, 09:39:27 AM
Yes, the blocksize things seems to be a neverending issue, although in most people's eyes it does not seem as complicated and the majority advocates the blocksize rise.
People continue to make such a big deal about the block size. Our opinions aren't going to change anything. The person or company that made Bitcoin, will decide what to do about the block size. The 1MB block size was put in place to stop spam and to increase the security of Bitcoin. Why fix something that isn't broken? It is fine as it is, we don't need to change it.


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: Cconvert2G36 on January 01, 2016, 09:42:35 AM
Yes, the blocksize things seems to be a neverending issue, although in most people's eyes it does not seem as complicated and the majority advocates the blocksize rise.
People continue to make such a big deal about the block size. Our opinions aren't going to change anything. The person or company that made Bitcoin, will decide what to do about the block size. The 1MB block size was put in place to stop spam and to increase the security of Bitcoin. Why fix something that isn't broken? It is fine as it is, we don't need to change it.

Questions? jobs@blockstream.com


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: Lauda on January 01, 2016, 09:45:48 AM
Obviously even emergency hardforks had been used in the past where you had update immediatelly, but it created havoc. For acceptable hardfork no one needs to fear (or make argue of fear to prevent hardfork), you need the change in Bitcoin client long time preferrably almost a year before most nodes naturally updates to this version of the Bitcoin client. But obviously even increasing to 2MB is not plan of current Bitcoin devs for 2016, they just pave the way to Blockstream
But how hard would it be to schedule a hard fork for late 2016? I'm pretty sure that almost everyone would upgrade by then and this could be used both to:
1) Increase the block size
2) Remove fear of a hard fork


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: Cconvert2G36 on January 01, 2016, 09:58:47 AM
If I may...

Yes, the blocksize things seems to be a neverending issue, although in most people's eyes it does not seem as complicated and the majority advocates the blocksize rise.
People continue to make such a big deal about the block size.

Lots of people want to be able to use Bitcoin and hope to use it more in the future.

Quote
The person or company that made Bitcoin

*Pretending you didn't say that.*

Quote
Why fix something that isn't broken? It is fine as it is, we don't need to change it.

Doing nothing is still doing something, and it could price a bunch of potential users out too early.

And here's (https://medium.com/@octskyward/on-consensus-and-forks-c6a050c792e7#.q4xiib92n) why soft forks aren't really forks.

Am I wrong?

Well they're definitely forks... with something like segwit, not so soft unless you upgrade just like you would preceding a hard fork.


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: BlindMayorBitcorn on January 01, 2016, 10:03:20 AM
^Why is a hard fork preferable? Is it?


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: Lauda on January 01, 2016, 10:04:35 AM
^Why is a hard fork preferable? Is it?
It definitely is not. I mean, specifically in the case of SegWit it could be done differently and probably with less complexity with a hard fork. However, usually a hard fork is not the preferred way of making upgrades.


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: Cconvert2G36 on January 01, 2016, 10:07:23 AM
A hard fork would break old nodes in an obvious manner. A soft fork would give the illusion that nothing had changed on your old node (even though it had). LukeJr (I believe) is credited with devising some opcode magic to shoehorn segwit in with a soft fork.


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: BlindMayorBitcorn on January 01, 2016, 10:13:20 AM
In the article (https://medium.com/@octskyward/on-consensus-and-forks-c6a050c792e7#.q4xiib92n) I mentioned, the author suggests miners and merchants should both prefer a hard fork.

Quote
If you are a miner or a merchant, you should prefer changes to be made via hard forks.

[If you are a merchant] you really want to be sure that a transaction that’s paying you is valid according to the majority, and you want that as fast as possible. That means your node needs to be running the majority rule set. If you get left behind, you can be defrauded. This means you need to know ASAP if you’re no longer in the majority, and you want to ignore transactions that you couldn’t verify.



Title: Re: Small blocksize increase should be done first and SegWit second
Post by: Cconvert2G36 on January 01, 2016, 10:17:13 AM
The "author" is an obvious Government Stooge working for the Big Banks... you expect me to read that?


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: BlindMayorBitcorn on January 01, 2016, 10:18:04 AM
The "author" is an obvious Government Stooge working for the Big Banks... you expect me to read that?

Lol. Oh! mercy :D

Edit: imagine someone else said it. Would it still be wrong? :)


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: franky1 on January 01, 2016, 10:27:00 AM
if mining pools dont upgrade. they wont accept SW transactions..  

That just tells me you don't know what the hell you're talking about. SegWit, as with every other softfork, is enforced when a supermajority of miners upgrade.
if mining pools do upgrade to v0.13sw. the merkle tree is now 2 not one.

FOR SEGWIT TRANSACTIONS. Regular transactions w/ signature data still contained within original merkel tree still exist ie. backward compatible.

so your admitting that it needs everyone to upgrade to work. your admitting something wont work if people dont upgrade.. thank you :D thats a hard fork!


v0.12 full node clients will then feel limp and receiving data they cannot check and so they are forced to upgrade..
Are nodes who did not yet upgrade to a version supporting CLTV also not full nodes because they can't verify related transactions?

emphasis on the word FULL.
if its not doing the full work its not a full node. so if a old version cant see, verify, understand a transaction, then its no longer a full node..
the description is in its name .. FULL

now in my last 2 sentences.. if mining pools and full node clients are upgrading and mining pools are happy to have more than 1mb of data per block(which they have to be to even allow SW).. we might aswell up the block limit to 2mb and not have to make 2 merkle tree's

backward compatible. nodes who choose not to upgrade will still process at maximum 1mb of data per block.
i think you need to really stop looking at your bank balance and start thinking real hard about segwit..
its only the SW clients that will store atmost 1mb as they are ignoring the signature merkle..

EG
(by the way dont knit pick numbers, their just examples.. concentrate on the reasoning)
lets say a miner was SW upgraded
lets say a normal tx was 250bytes 1pay,1receive(220 tx data 156 signature)
-----
Input:
Previous tx: f5d8ee39a430901c91a5917b9f2dc19d6d1a0e9cea205b009ca73dd04470b9a6
Index: 0
scriptSig: 304502206e21798a42fae0e854281abd38bacd1aeed3ee3738d9e1446618c4571d10
90db022100e2ac980643b0b82c0e88ffdfec6b64e3e6ba35e7ba5fdd7d5d6cc8d25c6b241501

Output:
Value: 5000000000
scriptPubKey: OP_DUP OP_HASH160 404371705fa9bd789a2fcd52d2c580b65d35549d
OP_EQUALVERIFY OP_CHECKSIG
-----
if all tx were normal it could fit <2700 tx in 1mb.. right
but remember sw promises more transactions per block

so a sw miner sets the tx merkle to 1mb and the sig merkle to Xmb
now the tx merkle can store 4,500tx (tx 1mb/220byte=4500)
but the sig merkle is 0.7mb (totalling 1.7mb for tx+sig)

yea many fanboys will say things are great if as they can have 4500tx's for only 1mb
but regular unupgraded full nodes will have either
blocks being 1.7mb (containing 100% normal tx)
blocks being 1mb but (containing txdata they cant verify as it looks like a pay to script)
or something in between


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: keepdoing on January 01, 2016, 03:01:43 PM
Obviously even emergency hardforks had been used in the past where you had update immediatelly, but it created havoc. For acceptable hardfork no one needs to fear (or make argue of fear to prevent hardfork), you need the change in Bitcoin client long time preferrably almost a year before most nodes naturally updates to this version of the Bitcoin client. But obviously even increasing to 2MB is not plan of current Bitcoin devs for 2016, they just pave the way to Blockstream
But how hard would it be to schedule a hard fork for late 2016? I'm pretty sure that almost everyone would upgrade by then and this could be used both to:
1) Increase the block size
2) Remove fear of a hard fork
I think everyone pretty much just needs to get it through their head that there is probably going to be a messy, divisive hard fork unless people step up to the plate and come up with an intelligent, fair solution, which also will most likely involve a hard fork, but that can be done with as much concensus as possible.

And I absolutely agree it could be done by late 2016.  I actually don't see a problem with it happening in early/mid 2016.  The solutions are there.  Let's not pretend that there is still some sort of magical line of code that is missing and therefore preventing this.  This is primarily a political issue.   The Blockstream Players are blocking it.  They forced Hearns/Gavin to attempt XT, which at least was an attempt at progress, even if it was overambitious and stupid.

But I want to address THE most important line in the above post....  "Remove Fear of a hard fork."

The problem is not primarily fear of a hard fork, it is the uncertainty surrounding the competency and trustworthiness of those making the decisions.  We can get through a hard fork - all it takes is solid leadership.  The rest is FUD.


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: ATguy on January 01, 2016, 03:25:00 PM
Obviously even emergency hardforks had been used in the past where you had update immediatelly, but it created havoc. For acceptable hardfork no one needs to fear (or make argue of fear to prevent hardfork), you need the change in Bitcoin client long time preferrably almost a year before most nodes naturally updates to this version of the Bitcoin client. But obviously even increasing to 2MB is not plan of current Bitcoin devs for 2016, they just pave the way to Blockstream
But how hard would it be to schedule a hard fork for late 2016? I'm pretty sure that almost everyone would upgrade by then and this could be used both to:
1) Increase the block size
2) Remove fear of a hard fork
I think everyone pretty much just needs to get it through their head that there is probably going to be a messy, divisive hard fork unless people step up to the plate and come up with an intelligent, fair solution, which also will most likely involve a hard fork, but that can be done with as much concensus as possible.

And I absolutely agree it could be done by late 2016.  I actually don't see a problem with it happening in early/mid 2016.  The solutions are there.  Let's not pretend that there is still some sort of magical line of code that is missing and therefore preventing this.  This is primarily a political issue.   The Blockstream Players are blocking it.  They forced Hearns/Gavin to attempt XT, which at least was an attempt at progress, even if it was overambitious and stupid.

But I want to address THE most important line in the above post....  "Remove Fear of a hard fork."

The problem is not primarily fear of a hard fork, it is the uncertainty surrounding the competency and trustworthiness of those making the decisions.  We can get through a hard fork - all it takes is solid leadership.  The rest is FUD.


Here is what Satoshi wrote how to increase block size limit:

It can be phased in, like:

if (blocknumber > 115000)
    maxblocksize = largerlimit

It can start being in versions way ahead, so by the time it reaches that block number and goes into effect, the older versions that don't have it are already obsolete.

When we're near the cutoff block number, I can put an alert to old versions to make sure they know they have to upgrade.


So if you put such line in Bitcoin Core 0.12, where blocknumber happens at end 2016/early 2017, by then probably Bitcoin Core 0.14 will be out and most full nodes will be running on Bitcoin Core 0.12 or better so the hardfork will impact only those running today version of Bitcoin Core 0.11.2 or older which will be notified to upgrade near the cutoff block number anyway - not much to fear of such hard fork.

But it needs planning ahead plus the will to follow original Bitcoin project which current Blockstream Core devs have not intentions for


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: CIYAM on January 01, 2016, 03:35:48 PM
Just increasing the block size "does not scale" (keep doing that and you'll end up with blocks with so many txs that it will actually take longer than 10 minutes to verify them all not to mention that internet bandwidth doesn't follow Moore's law).

This has been pointed out again and again but still seems to be (most likely purposely) not picked up by many of the posters here.

Stop thinking politics and start thinking engineering - please.


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: keepdoing on January 01, 2016, 03:43:39 PM
Just increasing the block size "does not scale" (keep doing that and you'll end up with blocks with so many txs that it will actually take longer than 10 minutes to verify them all not to mention that internet bandwidth doesn't follow Moore's law).

This has been pointed out again and again but still seems to be (most likely purposely) not picked up here.

Stop thinking politics and start thinking engineering - please.

I cry "FUD!"

NOBODY has suggested limiting other solutions.  NOBODY says sidechains can't continue to exist and be developed and improved upon.  Most people aren't suggesting Segregated Witness might not have a place to help take some load off.  NOBODY is saying to raise the Block Size and then forever stop working on improvements.

The only engineering limitation being put on this is by the BLOCKSTREAM Players.  They want to limit engineering options, thereby guaranteeing the sole  survival of their engineering model.

No - this is political.  It is pretty much purely political at this point. 


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: CIYAM on January 01, 2016, 03:49:06 PM
No - this is political.  It is pretty much purely political at this point.  

Indeed it is obvious that you are only interested in making this political - so why not just stop posting the technical nonsense then (as has been pointed out to you by others) and just post your political rants.

No need to confuse the newbies with technobabble is there (or is there)?



Title: Re: Small blocksize increase should be done first and SegWit second
Post by: ATguy on January 01, 2016, 03:56:58 PM
Just increasing the block size "does not scale" (keep doing that and you'll end up with blocks with so many txs that actually will take longer than 10 minutes to verify them all).

This has been pointed out again and again but still seems to be (most likely purposely) not picked up here.

Stop thinking politics and start thinking engineering - please.



1 MB is just round number thats why it was choosen, yet many treat this 1 MB as holy unchangable number today.

This number should be whatever the average computer can process/store to keep Bitcoin decentralized, not a fixed number when people have faster computers with more storage and faster internet over a time - the maximum blocksize should exactly follow such average people computer speed ups to keep the same decentralization, yet noone cares and just paving the way to more centralized offchain solutions when I argue there is still room for blocksize increase over time based on average computer speed/storage/internet increases without loosing any decentralization

BTW if your holy number was choosen 256 KB instead in the past, where we would be today - start thinking please


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: CIYAM on January 01, 2016, 03:59:37 PM
BTW if your holy number was choosen 256 KB instead in the past, where we would be today - start thinking please

It is really disappointing that I have to repeat myself again but I will:

Just increasing the block size won't scale.

Do you get it yet?

(the question is not about 1MB or 2MB or 10MB but about how Bitcoin can scale)


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: keepdoing on January 01, 2016, 03:59:46 PM
No - this is political.  It is pretty much purely political at this point.  

Indeed it is obvious that you are only interested in making this political - so why not just stop posting the technical nonsense then (as has been pointed out to you by others) and just post your political rants.

No need to confuse the newbies with technobabble is there (or is there)?



I'm not the one that made it political.  The fact are the facts.  Again... what technobabble?  

I support Lightning Network, am open to SegWit, but acknowledge that almost universal concensus exists that the block size be raised.  

Yet, Blockstream Players have decided that to follow almost universal majority concensus that block size needs raising is a threat to their plan to gain monopolistic advantage in their minority vision of how bitcoin should develop.  And they are abusing their conflicted interest positions as Comitters to do so.  

It's very simple, and yes it is political, and there is no technobabble needed to understand the concept.


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: keepdoing on January 01, 2016, 04:01:48 PM
BTW if your holy number was choosen 256 KB instead in the past, where we would be today - start thinking please

It is really disappointing that I have to repeat myself again but I will:

Just increasing the block size won't scale.

Do you get it yet?

(the question is not about 1MB or 2MB or 10MB but about how Bitcoin can scale)


FUD.  Lying FUD.  Again, no one is suggesting that we JUST raise blocksize and then immediately stop all other technological innovation.


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: CIYAM on January 01, 2016, 04:02:00 PM
Yet, Blockstream Players have decided that to follow almost universal majority concensus that block size needs raising is a threat to their plan to gain monopolistic advantage in their minority vision of how bitcoin should develop.  And they are abusing their conflicted interest positions as Comitters to do so.  

You say it is a threat to their plan to gain monopolistic advantage but you don't even explain why - would you care to do that?


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: CIYAM on January 01, 2016, 04:03:02 PM
FUD.  Lying FUD.  Again, no one is suggesting that we JUST raise blocksize and then immediately stop all other technological innovation.

You really ought to learn to stop posting rubbish.

Try and actually "read what people post" before using the FUD word.

You are starting to look like not only a shill but also a troll - so choose your next words carefully if you actually want to continue any dialogue with me (it doesn't bother me one bit to just "unwatch" this topic as I do many such other topics that involve such posters).


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: keepdoing on January 01, 2016, 05:01:47 PM
Yet, Blockstream Players have decided that to follow almost universal majority concensus that block size needs raising is a threat to their plan to gain monopolistic advantage in their minority vision of how bitcoin should develop.  And they are abusing their conflicted interest positions as Comitters to do so.  

You say it is a threat to their plan to gain monopolistic advantage but you don't even explain why - would you care to do that?

It is simple enough for an 8 year old to understand....

Keep 1 mb blocks, and the only way that Bitcoin continues to grow is via Sidechain buildout.  All other possible avenues are killed dead in their tracks. 

Of course, Blockchain players then star yapping about "oh, but bigger blocks aren't needed yet - and when they are we will get to it."  Problem with that is that there is already concensus, and Blockstream players are blocking it, so the whole Trustworthiness of Leadership is raised.  The whole conflict of interest is raised.

When you get to a situation like that, investment and development in other directions is stifled because people get nervous when you have unsteady and obviously interest-conflicted leadership.  So that slows competitive process.

So the next stupid argument you will try and drag me into is "specifics".  You'll say tell me "specifically how they gain monopolistic advantage".  But that is so obvious I am not going to get in that mud pit with you, except to say...

By abusing their authority over the engineering decisions made with bitcoin, they effectively limit, delay and cut off funding for competitive strategies, and they increase their own potential customer base by creating an atmosphere of doubt regarding competitive strategies.  I mean - if I am a bank..... what solution am I going to choose?  The one whose leadership actually controls the technology, or one that is at the mercy of their competitor?

And this is why Blockstream Players are forcing a hard fork, or a fiat to arise.  If they weren't acting so blatantly in their own self interests, then others might accept a Bitcoin only path, trusting in fair and open engineering solutions to roll out over time.

But nobody trusts the Blockstream Players anymore.  I don't trust Mike Hearn.  I don't Trust the Blockstream Players.

Bitcoin Governance is currently flawed and doomed on its current path.  It cannot ever be trusted in an as-is setup.


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: CIYAM on January 01, 2016, 05:07:50 PM
It is simple enough for an 8 year old to understand....

You should try and be less insulting if you actually want anyone to pay attention to a single word that you say. :)

But nobody trusts the Blockstream Players anymore.  I don't trust Mike Hearn.  I don't Trust the Blockstream Players.

If you think that Mike Hearn works for Blockstream then you are rather seriously confused (I think even an 8yo could even work that out). :D

And if you don't think that Mike Hearn works for Blockstream then exactly who do you trust (as it would appear to be absolutely no-one)?


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: thejaytiesto on January 01, 2016, 05:25:53 PM
afaik segwit, it's only an effective 2mb increase as average with a 4mn as a peak, so it would be pointless to do it after a mini increase like 2mb

segwit is an increase of only 1,75 - 2 MB in the mid term and much more complicated than the 2 MB increase.

a 2 MB hard fork (which everyone agrees on and has zero risks / easy to deploy) will at least double the capazity.

funny that we are now at 2 MB and not even then some devs like Peter Todd agree on that. i guess when one or two people can veto against the will of 99%, bitcoin is in trouble.

No hard fork has zero risk, seg wit has much lower risk than 2 mb hardfork. Also where did you get that "everyone agrees" with that? as far as I know a lot of people disagree with that.


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: keepdoing on January 01, 2016, 05:36:32 PM

If you think that Mike Hearn works for Blockstream then you are rather seriously confused (I think even an 8yo could even work that out). :D

And if you don't think that Mike Hearn works for Blockstream then exactly who do you trust (as it would appear to be absolutely no-one)?

Don't be intentionally stupid.  Of course Mike doesn't work for Blockstream.  But politically they are no different is my point.  They both try and shove their solutions down the community throat.   I've made that clear in all my posts and you are just trying to confuse and muddle things.   I've actually come to believe Mike's approach deserves a bit more respect, seeing as how he probably reacted out of utter frustration in dealing with the Blockstream Players.

The Blockstream Players are simply finally being revealed for what they are.... manipulative liars.   It doesn't really excuse the way Mike handled it (basically I just think XT would have worked if he hadn't gotten overly ambitious).

And regarding trust... I basically at this point simply do not trust anyone having anything to do with Blockstream having a Comitt position.


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: keepdoing on January 01, 2016, 05:40:14 PM
No hard fork has zero risk, seg wit has much lower risk than 2 mb hardfork. Also where did you get that "everyone agrees" with that? as far as I know a lot of people disagree with that.
I think the main risk is being caused by the political toxicity of the issue.  Blockstream Players are intentionally creating the toxicity.  They are aware that this creates more inherent danger in a Hard Fork.  Therefore they get what they want.... no progress in block growth, no solutions that offer anything other than exclusive sidechain solutions.


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: CIYAM on January 01, 2016, 05:44:31 PM
Don't be intentionally stupid.

Again - you just can't help yourself but to be a fucking rude asshole can you?

Here is a big hint for you - if you don't be an asshole then maybe people might actually even bother to read what you post.

I've actually come to believe Mike's approach deserves a bit more respect, seeing as how he probably reacted out of utter frustration in dealing with the Blockstream Players.

As I suspected you are actually an XT shill being paid by none other than Mike himself (he probably has enough BTC to pay for another year's worth of this at least).


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: keepdoing on January 01, 2016, 06:01:04 PM
Don't be intentionally stupid.

Again - you just can't help yourself but to be a fucking rude asshole can you?

Here is a big hint for you - if you don't be an asshole then maybe people might actually even bother to read what you post.

I've actually come to believe Mike's approach deserves a bit more respect, seeing as how he probably reacted out of utter frustration in dealing with the Blockstream Players.

As I suspected you are actually an XT shill being paid by none other than Mike himself (he probably has enough BTC to pay for another year's worth of this at least).

Getting under your skin am I?  Lost your cool and cursing like a sailor :)

And I've made it clear that I think Mike's version of XT was ill thought out, overambitious and not in best interest of Bitcoin.  So you are just flat out lying also.

ROFL.... Here's your only real problem.... I don't support sidechains as an exclusive solution.  I don't support rampant and careless big block building on the main chain exclusively.

I support wisdom, unbiased leadership, sound decisions that open the doors for individuals to use bitcoin, small business companies to use bitcoin,  midsize banks to use bitcoin, and governments to us bitcoin.  In others words... a Total Solution, which is what Bitcoin is capable of.


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: CIYAM on January 01, 2016, 06:04:09 PM
ROFL.... Here's your only real problem.... I don't support sidechains as an exclusive solution.  I don't support rampant and careless big block building on the main chain exclusively.

Where exactly did I say that I support sidechains as an exclusive solution?

(answer - in your dreams - so again you are basically lying - is it so hard to tell the truth?)


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: keepdoing on January 01, 2016, 06:22:14 PM
ROFL.... Here's your only real problem.... I don't support sidechains as an exclusive solution.  I don't support rampant and careless big block building on the main chain exclusively.

Where exactly did I say that I support sidechains as an exclusive solution?

(answer - in your dreams - so again you are basically lying - is it so hard to tell the truth?)


Sorry, now you are just walking into the mud pit, and challenging me to crawl in.  Just took a shower.  Have things to do today.  Maybe tomorrow.


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: CIYAM on January 01, 2016, 06:26:03 PM
Sorry, now you are just walking into the mud pit, and challenging me to crawl in.  Just took a shower.  Have things to do today.  Maybe tomorrow.

I see - so you have nothing further to offer to this topic (as I suspected) - I will unwatch it now so you can enjoy chatting to yourself tomorrow.

@OP - I hope you can see the friends that you are gathering. :D


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: LiteCoinGuy on January 01, 2016, 06:37:13 PM
BTW if your holy number was choosen 256 KB instead in the past, where we would be today - start thinking please

It is really disappointing that I have to repeat myself again but I will:

Just increasing the block size won't scale.

Do you get it yet?

(the question is not about 1MB or 2MB or 10MB but about how Bitcoin can scale)


indeed, but we would win time and could come up with a good solution. there would be no fee-market too which is harmful at this early stage.


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: CIYAM on January 01, 2016, 06:42:06 PM
indeed, but we would win time and could come up with a good solution. there would be no fee-market too which is harmful at this early stage.

I really don't see the problem.

Currently I can use Bitcoin to move huge amounts of money from one country to another without resorting to "bags of cash" or "loads of jewellery" yet somehow even though Bitcoin is not even been properly used for just this purpose (i.e. remittance) we have to panic and increase the block size so that people can buy coffees for BTC.

There are very few people in the world that are even paid in BTC - so why the fuck do we need to sell coffees in BTC?

Why can't you guys wait for BTC to be successful in the very area it *should kick ass in* (which is remittance) before you demand your *coffees* need to be able to be paid for in BTC?


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: franky1 on January 01, 2016, 06:54:16 PM
average hard drives over the last 16 years has doubled every 2 years
3,6,12,24,48,96,192,384,765

yea some people in 2000 had 2gb hard drives some had 4gb hard drives
yea some people in 2016 have 500gb hard drives, some have 1tb hard drives.

but an increase of doubling every 2 years is a natural rise.. even satoshi envisioned that (every 105,000 blocks).. then people complaining about bloat wont complain about it as they will be getting larger hard drives to compensate

i agree that it wont suddenly make bitcoin handle visa transaction volumes in 6 months.. but thats because people are not realising how fake visa's suggested volume is.. especially when visa's system is not actually one system, but multiple separate systems with mutliple separate databases. and thus their actual handling of tx's per system is far far less.. and thus far less to worry about.

especially anytime right now.

and the reason most people are waiting more than 10 minutes per block is not to do with bloat.. its to do with miners limiting transactions out of greed..
https://blockchain.info/charts/avg-block-size?timespan=30days

0.75mb is the average maximum... not 0.99mb

meaning on average there is plenty of room for more transactions per block... if only the miners would stop being greedy and just accept all transactions and stop blaming other reasons..

orphans only happen because miners do not stale their attempts when a competing block is solved.. this has nothing to do with transaction numbers. but more to do with miners greed hoping that if they push on and continue to solve their block, and then push on and hope to solve the next block before anyone else.. their previous block becomes valid and the competitors block becomes the orphan..

if miners just accepted transactions as they come and then stale their attempts if a competitor solves first.. then transactions wont get delayed and orphans wont happen.. its just that simple.. greed is the blame not bloat.


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: keepdoing on January 01, 2016, 06:56:30 PM
indeed, but we would win time and could come up with a good solution. there would be no fee-market too which is harmful at this early stage.

I really don't see the problem.

Currently I can use Bitcoin to move huge amounts of money from one country to another without resorting to "bags of cash" or "loads of jewellery" yet somehow even though Bitcoin is not even been properly used for just this purpose (i.e. remittance) we have to panic and increase the block size so that people can buy coffees for BTC.

There are very few people in the world that are even paid in BTC - so why the fuck do we need to sell coffees in BTC?

Why can't you guys wait for BTC to be successful in the very area it *should kick ass in* (which is remittance) before you demand your *coffees* need to be able to be paid for in BTC?

PROBLEM: Some people like to tell other people what bitcoin "should" be used in, and whether or not other people should be able to buy coffee with bitcoin.  Thank G-d people are thinking for me, or I might do something horribly independent and private without their being able to track it.


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: CIYAM on January 01, 2016, 07:08:10 PM
PROBLEM: Some people like to tell other people what bitcoin "should" be used in, and whether or not other people should be able to buy coffee with bitcoin.  Thank G-d people are thinking for me, or I might do something horribly independent and private without their being able to track it.

Again you are spouting nonsense as seems to be your thing.

I will unwatch this topic also as I have no interest in reading any more of your stupid posts.

If any of the people in this topic actually want to be taken seriously then you really need to rethink your topics.

Spouting nonsense and attacking people might be fun but it doesn't actually change the minds of anyone that is actually intelligent.

(perhaps this is a Donald Trump thing)


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: keepdoing on January 01, 2016, 07:16:04 PM
PROBLEM: Some people like to tell other people what bitcoin "should" be used in, and whether or not other people should be able to buy coffee with bitcoin.  Thank G-d people are thinking for me, or I might do something horribly independent and private without their being able to track it.

Again you are spouting nonsense as seems to be your thing.

I will unwatch this topic also as I have no interest in reading any more of your stupid posts.

If any of the people in this topic actually want to be taken seriously then you really need to rethink your topics.

Spouting nonsense and attacking people might be fun but it doesn't actually change the minds of anyone that is actually intelligent.

(perhaps this is a Donald Trump thing)

Bu Bye!  See ya!  Although - you have said before you were going to ignore me.  I knew it was too good to be true.

I still like the general concepts espoused by the OP.  Too bad he included a suggestion for increasing block size as part of the overall solution.  That unfortunately has rubbed the Blockstream Players the wrong way, and they are comig out of the woodwork en masse spreading FUD, nonsensical confusion, spinning facts etc.


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: LiteCoinGuy on January 01, 2016, 07:27:54 PM
indeed, but we would win time and could come up with a good solution. there would be no fee-market too which is harmful at this early stage.

I really don't see the problem.

Currently I can use Bitcoin to move huge amounts of money from one country to another without resorting to "bags of cash" or "loads of jewellery" yet somehow even though Bitcoin is not even been properly used for just this purpose (i.e. remittance) we have to panic and increase the block size so that people can buy coffees for BTC.

There are very few people in the world that are even paid in BTC - so why the fuck do we need to sell coffees in BTC?

Why can't you guys wait for BTC to be successful in the very area it *should kick ass in* (which is remittance) before you demand your *coffees* need to be able to be paid for in BTC?


i did not write anything about coffee.

lets assume i use it for remittance and want to sent 10 USD to india (which is alot there) and transaction fees rise over the next months. now i have to pay 10-15% in fees. great usecase bitcoin.  ::)


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: CIYAM on January 01, 2016, 07:30:12 PM
i did not write anything about coffee.

lets assume i use it to remittance and want to sent 10 USD to india (which is alot there). now i have to pay 10-15% in fees (1-1,50 USD). great usecase.  ::)

I pay 0% fees for my BTC txs - so why are yours costing 10-15%?

(we are clearly not arguing about BTC at all but now some imagined fee percentage that you invented)


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: franky1 on January 01, 2016, 07:47:28 PM
i did not write anything about coffee.

lets assume i use it to remittance and want to sent 10 USD to india (which is alot there). now i have to pay 10-15% in fees (1-1,50 USD). great usecase.  ::)

I pay 0% fees for my BTC txs - so why are yours costing 10-15%?

(we are clearly not arguing about BTC at all but now some imagined fee percentage that you invented)


0 fee's???????

ok $10, input into localbitcoins.. cheapest valuation =$444 per btc
so $10=0.022653   
ok 0.022653, input into localbitcoins.. cheapest valuation =27488.89 INR / BTC
= 622 INR

google: dollar to indian rupee: https://www.google.co.uk/search?q=dollar+to+indian+rupee
$10=662 INR

622 vs 662 =6% loss ($0.60 cost or 40 rupee cost)


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: CIYAM on January 01, 2016, 07:51:46 PM
0 fee's???????

Yes - when I sent the 200 BTC back to the forum do you think I paid a fee?


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: franky1 on January 01, 2016, 07:57:30 PM
0 fee's???????

Yes - when I sent the 200 BTC back to the forum do you think I paid a fee?


bitcoin 0 fee's technically or 0.0001 if you cant wait.. i agree.. but when you start talking about fiat prices from one country to another.. exactly what WU is all about.. there is a cost when dealing with the fiat at either side of bitcoin... if bitcoin was to be used as the middleman for fiat remittance.. which is 6% atleast


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: CIYAM on January 01, 2016, 08:00:50 PM
bitcoin 0 fee's technically or 0.0001 if you cant wait.. i agree.. but when you start talking about fiat prices from one country to another.. exactly what WU is all about.. there is a cost when dealing with the fiat at either side of bitcoin... if bitcoin was to be used as the middleman for fiat remittance.. which is 6% atleast

You are just making up stats now.

I was using BTC to move money from Australia to China years ago and I actually profited from the remittance (which is something unheard of in moving money from one country to another).

So I moved AUD to China and got more RMB than the AUD/CNY exchange rate at the time - do you understand that?


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: franky1 on January 01, 2016, 08:24:12 PM

You are just making up stats now.


making up??
https://i.imgur.com/0Dw7xcm.jpg

now i dare you to show me a local bitcoin method to convert $10 into 482 INR

go on.. show me your stats.. as i just showed you the 9% loss (6% loss if US dollar 9% loss is australian dollar )
the only mistake i made in my stats in previous post was i used USD not AUD as the origin of the remittance.

now have a nice day


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: LiteCoinGuy on January 01, 2016, 09:52:07 PM
http://up.picr.de/24152517zb.jpg


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: keepdoing on January 01, 2016, 11:08:52 PM
Unfortunately I don't think some people care about facts / options.  They care about keeping control. 


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: CIYAM on January 02, 2016, 03:11:15 AM

It is a pity that people want to worship Satoshi and don't recognise the mistakes that he made (little-endian numbers in txs being one of the worst).

Moore's law never applied to bandwidth which is the problem that Bitcoin has in regards to scaling (not storage or processing power).


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: LiteCoinGuy on January 02, 2016, 10:48:55 PM

It is a pity that people want to worship Satoshi and don't recognise the mistakes that he made (little-endian numbers in txs being one of the worst).

Moore's law never applied to bandwidth which is the problem that Bitcoin has in regards to scaling (not storage or processing power).


https://s3.amazonaws.com/media.nngroup.com/media/editor/2014/08/08/internet-bandwidth-nielsens-law-1983-2914.png

https://www.nngroup.com/articles/law-of-bandwidth/

law-of-bandwidth


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: pereira4 on January 02, 2016, 10:52:23 PM
Why is people comparing Bitcoin to visa? that's nonsense. VISA is a payment procesor of fiat, it's not money. Bitcoin is it's own money, as well processing the transactions of this very unique money. Its like comparing apples to oranges.


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: keepdoing on January 02, 2016, 11:07:00 PM
Why is people comparing Bitcoin to visa? that's nonsense. VISA is a payment procesor of fiat, it's not money. Bitcoin is it's own money, as well processing the transactions of this very unique money. Its like comparing apples to oranges.
I have Bitcoin.  I can't spend them directly easily at all.  So Coinbase has a Visa Debit card that links directly to my bitcoin account/wallet.  I can now purchase things directly out of my Bitcoin Wallet - ANYWHERE.  I've bought coffee.  I've bought gasoline, food, etc.

Dollar is money that interfaces with transactional capabilities offered by Visa.
Euro is money that interfaces with transactional capabilities offered by Visa.
....and Bitcoin is money that interfaces with transactional capabilities offered by Visa.

The current difference is that right now it is difficult to spend my Bitcoin without intermediary transaction assistance.  Not really a big deal.  But if Bitcoin wants to be spent without an intermediary, it needs to scale to be able to handle transactions like Visa.  That is why the comparison - because VISA is the transaction intermediary that currently links ALL Major currencies, including Bitcoin.


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: CIYAM on January 03, 2016, 02:42:17 AM
Quote
Nielsen's Law of Internet bandwidth states that:

    a high-end user's connection speed grows by 50% per year

Why is it that when people quote stuff they only quote the bit that serves their own point?

:)


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: Amph on January 03, 2016, 09:02:34 AM
Why is people comparing Bitcoin to visa? that's nonsense. VISA is a payment procesor of fiat, it's not money. Bitcoin is it's own money, as well processing the transactions of this very unique money. Its like comparing apples to oranges.

i also see bitcoin as a payment processor, not only as a money, since it has his own circuit, which is the blockchain

so it can be comparable easily to anything that involve money, since it is a complete system


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: Cuidler on January 03, 2016, 10:39:11 AM
The current difference is that right now it is difficult to spend my Bitcoin without intermediary transaction assistance.  Not really a big deal.  But if Bitcoin wants to be spent without an intermediary, it needs to scale to be able to handle transactions like Visa.  That is why the comparison - because VISA is the transaction intermediary that currently links ALL Major currencies, including Bitcoin.

It is big deal, everytime you use intermediary, you pay some % to the intermediary. And VISA taking about 2% if Im correct, pretty huge % considering it might be possible to spend Bitcoin directly without the VISA need - thats the point of Bitcoin as I understand


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: keepdoing on January 03, 2016, 12:58:29 PM
The current difference is that right now it is difficult to spend my Bitcoin without intermediary transaction assistance.  Not really a big deal.  But if Bitcoin wants to be spent without an intermediary, it needs to scale to be able to handle transactions like Visa.  That is why the comparison - because VISA is the transaction intermediary that currently links ALL Major currencies, including Bitcoin.

It is big deal, everytime you use intermediary, you pay some % to the intermediary. And VISA taking about 2% if Im correct, pretty huge % considering it might be possible to spend Bitcoin directly without the VISA need - thats the point of Bitcoin as I understand
There will always be a fee.   Bitcoin is not fee free.  Bitcoin is not anonymous.  Bitcoin is not magical money that you won't have to pay taxes on.  It will be subservient to all the market forces that currently exist.  By the time Bitcoin is a global currency on the magnitute of the dollar, it will have all the oversight current currencies have.

The difference between Blockstream Vision & XT/Unlimited Vision is that Blockstream wants to make sure everyone has to have numbered identifiable accounts in Sidechain Bank Accounts in order to functionally use Bitcoin.  XT/Unlimited wants everyone to have the OPTION of either using a bank, using bitcoin as a link into current system, or holding your bitcoin yourself, or actually using your bitcoin yourself - directly Peer to Peer at all levels, even buying coffee.

I believe that as time passes and people begin to be more educated as to what is actually the Blockstream Vision - they will see that it aims for a much more manipulative & robust fee structure.   If you can control and limit the way Bitcoin is used, you can control the fees.  Historically I see that anytime a group can control a fee - they take advantage of that to raise those fees through the sheer power of exercise of that control.

Don't believe me?  Well, ASK YOURSELF..... How are the Blockstream Players acting now, just in the infancy of Bitcoin?  Because they stacked the Core Comitt deck with their people, they now control what paths are, and are not, accepted with Bitcoin.  They keep politically manipulating the system..... doing these headfake promises to raise blocksize (which is the majority concensus), but then they always eventually redirect/misdirect the conversation to one excuse or another as to never actually doing it.  Blockstream is using its control to exercise its power over Bitcoin Community.   

If you want to see the future of a thing, all you need to do is look at where it came from, and where it is.


Instead of using VISA, you'll be using LIGHTNING.... and you will be paying for it.


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: keepdoing on January 03, 2016, 01:21:35 PM
Here's another way to look at it.

In the current system, you can keep your cash in your bank accounts and they can track everything you do.  They can even "lock down" your cash and keep you from it.   But you can also get paid directly in actual physical cash, and spend it directly.  Someone can pay you in cash, and you can spend it, OR you can just stuff it under a mattress, or bury it in a pail in your backyard.   The downside to the current system is that whether it is in a bank, or stuffed under your mattress - it still isn't totally safe, because it can be manipulated and devalued through the Federal/Central Reserve Banks, crooked Mega Market forces etc.

In the current system, the historical hedge against this was Gold/Silver.  It always act as a hedge against these manipulations.  It is a central repository of value that is physical, can be personally possessed, and is universally recognized across country borders - convertible into any global currency.   The problem with Gold is that it is limited to use primarily as a store of value.  But it is not "Usable" as an actual day to day currency.

In the current system, there is also the "VISA" transaction network.  Visa acts as an electronic transaction database to allow people to move Cash/Currency around.  It's really just a database transactional system with fees.

ALL of these separate aspects come together to create the current system.  

Enter Bitcoin....

Bitcoin has the capability of being ALL of these things.  It can act as a Digital Gold, but it can also act as Cash.  It inherently has its own "VISA" transaction network.

But the only way you get ALL of this from the Bitcoin system, is to have a COMBINATION of larger blocks, and more processing power, and ALSO Sidechains.  This is the XT/Unlimited Solution.  Allow for it ALL!

Enter Blockstream Players.....  They just want Bitcoin to be "Gold" and "VISA" only - no spendable "Bitcoin Cash".  They want everything you do to be via an "Account" on a sidechain.  You'll be numbered & tracked.  Oh, you'll still be able to move larger quanitities of personal "Bitcoin Gold" around on the main chain.  But just like current real gold, it'll be big and clunky and hard to actually directly spend..... unless you eventually "launder" it back into the System of Sidechain Banks.  And those banks will be no different than the current banks and financial systems that exist today.  So in a Blockstream Vision world - nothing really changes.  In some ways it is worse than what we have now.


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: franky1 on January 03, 2016, 01:26:03 PM
blockstream = bitinstant 2.0.. but instead of mtgox codes,bitstamp codes and btc-e codes they will use... liquid.


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: DooMAD on January 03, 2016, 01:41:11 PM
I'm still not convinced that Blockstream is the devil, but I can see how some people have reached that mindset in such a polarised discussion.  As no one has outlined any particular downside to simply throwing in all of the proposed solutions, LN, Segwit, and a small blocksize increase, can we not all just get behind that and do it now?  There's seemingly little point arguing over which one should come first or second, just get them all ready to go and get it all over and done with in a single fork.


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: keepdoing on January 03, 2016, 01:59:40 PM
I'm still not convinced that Blockstream is the devil, but I can see how some people have reached that mindset in such a polarised discussion.  As no one has outlined any particular downside to simply throwing in all of the proposed solutions, LN, Segwit, and a small blocksize increase, can we not all just get behind that and do it now?  There's seemingly little point arguing over which one should come first or second, just get them all ready to go and get it all over and done with in a single fork.

I don't understand what you don't understand.  There are NO plans for a Blocksize Increase.  Blockstream Players are blocking it.  THEY have the power to implement, or block implementation.  They are blocking it.  They have made it clear that with the untested vision of Segwit & LN - this is all that will be needed for years to come.

The ONLY way that a blocksize increase will happen is through a divisive fork.  As it stands, forces are lining up for a Fork War.  XT/Unlimited vs Blockstream/CoreDev.  Only hope of avoiding that war is for someone in CoreDev to grow a pair and make an intelligent decision.

PS.... just so there is clarity.... NOBODY I know has suggested that the solutions of Blockstream (Lightning for example) are evil.  NOBODY.  The only "evil" as you call it, is that Blockstream Players have hijaaked the governance system and are disallowing any idea that is not biased towards their vision.


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: franky1 on January 03, 2016, 02:05:29 PM
I'm still not convinced that Blockstream is the devil, but I can see how some people have reached that mindset in such a polarised discussion.  As no one has outlined any particular downside to simply throwing in all of the proposed solutions, LN, Segwit, and a small blocksize increase, can we not all just get behind that and do it now?  There's seemingly little point arguing over which one should come first or second, just get them all ready to go and get it all over and done with in a single fork.

blockstream want their liquid coin to be pegged for bitcoin.. so in short term liquid is worth the same.. then by reading some of the proposals they want to do to bitcoin, they want to ruin bitcoin so that people will play with their liquid..

EG
ReplaceByFee
this means that without a signature anyone can edit the recipients funds..
this was proposed so that retailers that see a customers transaction can play around with that tx to change the values to ensure it has the highest fee to ensure the retailer gets paid.
the ideology is good as it means the retailer can fight a customer who tries to double spend.. the realism is that a retailer can leave the customers 'change' address empty.
.. i think you can see how this can be abused.

no block limit increase
by not doing block limit increases, but instead allowing their own altcoins to have such larger capacity, will further kill off bitcoins usability and desirability.

confidential transactions
by adding 2.5kb of data to a transaction they can hide the bitcoin value a customer will see.. this means it can literally hide how much you are sending to an address.. though some want more anonymity.. by adding it to bitcoin it will bloat the transaction. by making it so that there will only be < 400 transactions a block instead of the potential of ~4000
.. i think you can see how without upping the block limit, and then reducing the number of transactions allowed.. will hurt bitcoin

blockstream want their 'liquid' coins to eventually be worth $400+ without actually doing 7 years of mining and spending billions on electric to achieve it.. then kill off bitcoin so that it forces people to use their coins..


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: DooMAD on January 04, 2016, 11:26:01 AM
I'm still not convinced that Blockstream is the devil, but I can see how some people have reached that mindset in such a polarised discussion.  As no one has outlined any particular downside to simply throwing in all of the proposed solutions, LN, Segwit, and a small blocksize increase, can we not all just get behind that and do it now?  There's seemingly little point arguing over which one should come first or second, just get them all ready to go and get it all over and done with in a single fork.

blockstream want their liquid coin to be pegged for bitcoin.. so in short term liquid is worth the same.. then by reading some of the proposals they want to do to bitcoin, they want to ruin bitcoin so that people will play with their liquid..

EG
ReplaceByFee
this means that without a signature anyone can edit the recipients funds..
this was proposed so that retailers that see a customers transaction can play around with that tx to change the values to ensure it has the highest fee to ensure the retailer gets paid.
the ideology is good as it means the retailer can fight a customer who tries to double spend.. the realism is that a retailer can leave the customers 'change' address empty.
.. i think you can see how this can be abused.

no block limit increase
by not doing block limit increases, but instead allowing their own altcoins to have such larger capacity, will further kill off bitcoins usability and desirability.

confidential transactions
by adding 2.5kb of data to a transaction they can hide the bitcoin value a customer will see.. this means it can literally hide how much you are sending to an address.. though some want more anonymity.. by adding it to bitcoin it will bloat the transaction. by making it so that there will only be < 400 transactions a block instead of the potential of ~4000
.. i think you can see how without upping the block limit, and then reducing the number of transactions allowed.. will hurt bitcoin

blockstream want their 'liquid' coins to eventually be worth $400+ without actually doing 7 years of mining and spending billions on electric to achieve it.. then kill off bitcoin so that it forces people to use their coins..


I'm close to agreeing, but maybe just a touch more moderately.  It's fair to raise issues with any "features" like these containing glaring pitfalls, but the proposals like ReplaceByFee and Confidential Transactions will only find their way into circulation if the majority of nodes decide to run software containing them.  It's also fair to point out legitimate conflicts of interest with Blockstream, which I agree there are many.  But there's still a difference between conflict of interest and full blown conspiracy and I'm not sure we've reached that point just yet.  There's little difference between this conspiracy stance and the one where people were suggesting that Gavin and Mike were trying to "take over".  I never took that argument seriously, because it sounds crazy.  I'm not saying there aren't problems with Blockstream, as it does have certain insidious qualities, but maybe just tone it down a notch?


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: keepdoing on January 04, 2016, 03:03:55 PM
I'm still not convinced that Blockstream is the devil, but I can see how some people have reached that mindset in such a polarised discussion.  As no one has outlined any particular downside to simply throwing in all of the proposed solutions, LN, Segwit, and a small blocksize increase, can we not all just get behind that and do it now?  There's seemingly little point arguing over which one should come first or second, just get them all ready to go and get it all over and done with in a single fork.

blockstream want their liquid coin to be pegged for bitcoin.. so in short term liquid is worth the same.. then by reading some of the proposals they want to do to bitcoin, they want to ruin bitcoin so that people will play with their liquid..

EG
ReplaceByFee
this means that without a signature anyone can edit the recipients funds..
this was proposed so that retailers that see a customers transaction can play around with that tx to change the values to ensure it has the highest fee to ensure the retailer gets paid.
the ideology is good as it means the retailer can fight a customer who tries to double spend.. the realism is that a retailer can leave the customers 'change' address empty.
.. i think you can see how this can be abused.

no block limit increase
by not doing block limit increases, but instead allowing their own altcoins to have such larger capacity, will further kill off bitcoins usability and desirability.

confidential transactions
by adding 2.5kb of data to a transaction they can hide the bitcoin value a customer will see.. this means it can literally hide how much you are sending to an address.. though some want more anonymity.. by adding it to bitcoin it will bloat the transaction. by making it so that there will only be < 400 transactions a block instead of the potential of ~4000
.. i think you can see how without upping the block limit, and then reducing the number of transactions allowed.. will hurt bitcoin

blockstream want their 'liquid' coins to eventually be worth $400+ without actually doing 7 years of mining and spending billions on electric to achieve it.. then kill off bitcoin so that it forces people to use their coins..


I'm close to agreeing, but maybe just a touch more moderately.  It's fair to raise issues with any "features" like these containing glaring pitfalls, but the proposals like ReplaceByFee and Confidential Transactions will only find their way into circulation if the majority of nodes decide to run software containing them.  It's also fair to point out legitimate conflicts of interest with Blockstream, which I agree there are many.  But there's still a difference between conflict of interest and full blown conspiracy and I'm not sure we've reached that point just yet.  There's little difference between this conspiracy stance and the one where people were suggesting that Gavin and Mike were trying to "take over".  I never took that argument seriously, because it sounds crazy.  I'm not saying there aren't problems with Blockstream, as it does have certain insidious qualities, but maybe just tone it down a notch?
I must admit that the last sentence of Franky's post is something I hadn't considered.  But it is possible, and does make long term sense as an option that I would guess has at least been weighed by Blockstream players.  

So then to move on to the comments by DooMad - there is a very fine line between conflict of interest (which is simply an observational FACT regarding Blockstream involvement with Core Dev >>> Lightning/Liquid, and with Mike Hearn's involvement with XT>>>R3CEV/Banks - it just is what it is and it is obvious) and then to move that line just slightly to reach "Conspiracy Theory."  And regarding "conspiracy theory", it has a tendency to be assoiated with tinfoil hat nutjobs and nonsense - and YET, sometimes they really are "out to get you" :)  Or in this case.... to take their conflict of interest positions, and then conciously, and with determined effort attempt to leverage that for their own ends, in clear conflict with the greater good.

And honestly, I think that it really isn't that far of a leap given the situations - to make that jump.  And that relates to both Blockstream & Hearns.  I still have a gut feeling that Gavin really tries and wrestles with moral dilemnas, loyalty to the overall technology and vision etc.  I'm not sure how he is doing with that - but I give him a star for at least pretending to try in his own mind.

The SOLUTION would be that a middle road is taken.  Small (2mb) immediate increase - but with automatic increases, albeit at a slower more controlled pace than XT.  At the same time, full encouragement and kudos to Sidechain development to continue and grow.  Regarding SegWig, I'm all for it from what I can understand, just not as THE 100% immediate solution.  I defer to the technology experts on this matter.  If it can be implemented safely, and without negative consequences, and without creating any irreversible consequences - I say go for it, or anything else that improves and strengthens the overall technology.

The blocksize increase MUST happen in any rational solution - and I reference the clear concensus on this fact.  And even if you want to argue concensus, I still say that you cannot have a small group with clear conflict of interest making decisions that can so dramatically hinder the growth or possibilities inherent in the technology.  I also say that you must incorporate some sort of automated increase, because Bitcoin has grown up a bit.  It now plays in the world of global finance.  Global finance needs stability to survive.  It needs predictability.  You are not going to see mass adoption be embraced by those that can make it happen... in the current environment where there is even a remote possibility that you have small "Core" of biased and conflict challenged individuals that could destroy/hijaak/jeopardize the system at heir future whim.  So you have to at least establish a few years worth of stable and foreseeable path in the technology.  This would be HUGE, and would immediately free up investment time, money and resources to get to work.

Lastly - this middle of the road solution is actually the BEST path for Bitcoin, the most balanced path.  It allows Bitcoin to grow, but to allow it to do so in a more controlled fashion than XT.  The technology surrounding mining and node buildout can continue to parallel that growth at a reasonable pace.  That protects the decentralization.  And because there are smaller blocksize caps looming in stages, there is still enough emphasis and benefit put on sidechain solutions in order to keep main chain transactions manageable.

So everybody gets something.  The biggest winner is the technology itself.  It isn't choked and crippled, nad kept safe in this little controlled box (Blockstream Vision), and it isn't fed steroids and forced to grow in an unhealthy and forced manner (XT Vision).

It is sane.  It is rational.   And what is really really scary is that this clear and simple path can't find a way forward.  And right now.... I don't think you can blame this on Mike Hearn / XT anymore.

RIGHT NOW.... the blame is on Blockstream Players.  They alone hold the keys to this sane, intelligent middle road.

WILL THE REAL CORE/DEV PLEASE STAND UP?!?!?!


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: LiteCoinGuy on January 04, 2016, 04:47:37 PM
I'm still not convinced that Blockstream is the devil, but I can see how some people have reached that mindset in such a polarised discussion.  As no one has outlined any particular downside to simply throwing in all of the proposed solutions, LN, Segwit, and a small blocksize increase, can we not all just get behind that and do it now?  There's seemingly little point arguing over which one should come first or second, just get them all ready to go and get it all over and done with in a single fork.

i dont think they are the devil because they want bitcoin to succeed like all of us. but at the same time they give a shit about the majority of people (scalling bitcoin?!). they moved zero in their position. the smallest compromise would be 2MB - but not with some of these people (Peter Todd etc). that is not a good way to deal with other peoples opinions. even people like Jeff Garzik are fucked up...i guess that means alot.


Title: Re: Small blocksize increase should be done first and SegWit second
Post by: keepdoing on January 05, 2016, 03:13:43 PM
I'm still not convinced that Blockstream is the devil, but I can see how some people have reached that mindset in such a polarised discussion.  As no one has outlined any particular downside to simply throwing in all of the proposed solutions, LN, Segwit, and a small blocksize increase, can we not all just get behind that and do it now?  There's seemingly little point arguing over which one should come first or second, just get them all ready to go and get it all over and done with in a single fork.

blockstream want their liquid coin to be pegged for bitcoin.. so in short term liquid is worth the same.. then by reading some of the proposals they want to do to bitcoin, they want to ruin bitcoin so that people will play with their liquid..

EG
ReplaceByFee
this means that without a signature anyone can edit the recipients funds..
this was proposed so that retailers that see a customers transaction can play around with that tx to change the values to ensure it has the highest fee to ensure the retailer gets paid.
the ideology is good as it means the retailer can fight a customer who tries to double spend.. the realism is that a retailer can leave the customers 'change' address empty.
.. i think you can see how this can be abused.

no block limit increase
by not doing block limit increases, but instead allowing their own altcoins to have such larger capacity, will further kill off bitcoins usability and desirability.

confidential transactions
by adding 2.5kb of data to a transaction they can hide the bitcoin value a customer will see.. this means it can literally hide how much you are sending to an address.. though some want more anonymity.. by adding it to bitcoin it will bloat the transaction. by making it so that there will only be < 400 transactions a block instead of the potential of ~4000
.. i think you can see how without upping the block limit, and then reducing the number of transactions allowed.. will hurt bitcoin

blockstream want their 'liquid' coins to eventually be worth $400+ without actually doing 7 years of mining and spending billions on electric to achieve it.. then kill off bitcoin so that it forces people to use their coins..


I'm close to agreeing, but maybe just a touch more moderately.  It's fair to raise issues with any "features" like these containing glaring pitfalls, but the proposals like ReplaceByFee and Confidential Transactions will only find their way into circulation if the majority of nodes decide to run software containing them.  It's also fair to point out legitimate conflicts of interest with Blockstream, which I agree there are many.  But there's still a difference between conflict of interest and full blown conspiracy and I'm not sure we've reached that point just yet.  There's little difference between this conspiracy stance and the one where people were suggesting that Gavin and Mike were trying to "take over".  I never took that argument seriously, because it sounds crazy.  I'm not saying there aren't problems with Blockstream, as it does have certain insidious qualities, but maybe just tone it down a notch?
I must admit that the last sentence of Franky's post is something I hadn't considered.  But it is possible, and does make long term sense as an option that I would guess has at least been weighed by Blockstream players.  

So then to move on to the comments by DooMad - there is a very fine line between conflict of interest (which is simply an observational FACT regarding Blockstream involvement with Core Dev >>> Lightning/Liquid, and with Mike Hearn's involvement with XT>>>R3CEV/Banks - it just is what it is and it is obvious) and then to move that line just slightly to reach "Conspiracy Theory."  And regarding "conspiracy theory", it has a tendency to be assoiated with tinfoil hat nutjobs and nonsense - and YET, sometimes they really are "out to get you" :)  Or in this case.... to take their conflict of interest positions, and then conciously, and with determined effort attempt to leverage that for their own ends, in clear conflict with the greater good.

And honestly, I think that it really isn't that far of a leap given the situations - to make that jump.  And that relates to both Blockstream & Hearns.  I still have a gut feeling that Gavin really tries and wrestles with moral dilemnas, loyalty to the overall technology and vision etc.  I'm not sure how he is doing with that - but I give him a star for at least pretending to try in his own mind.

The SOLUTION would be that a middle road is taken.  Small (2mb) immediate increase - but with automatic increases, albeit at a slower more controlled pace than XT.  At the same time, full encouragement and kudos to Sidechain development to continue and grow.  Regarding SegWig, I'm all for it from what I can understand, just not as THE 100% immediate solution.  I defer to the technology experts on this matter.  If it can be implemented safely, and without negative consequences, and without creating any irreversible consequences - I say go for it, or anything else that improves and strengthens the overall technology.

The blocksize increase MUST happen in any rational solution - and I reference the clear concensus on this fact.  And even if you want to argue concensus, I still say that you cannot have a small group with clear conflict of interest making decisions that can so dramatically hinder the growth or possibilities inherent in the technology.  I also say that you must incorporate some sort of automated increase, because Bitcoin has grown up a bit.  It now plays in the world of global finance.  Global finance needs stability to survive.  It needs predictability.  You are not going to see mass adoption be embraced by those that can make it happen... in the current environment where there is even a remote possibility that you have small "Core" of biased and conflict challenged individuals that could destroy/hijaak/jeopardize the system at heir future whim.  So you have to at least establish a few years worth of stable and foreseeable path in the technology.  This would be HUGE, and would immediately free up investment time, money and resources to get to work.

Lastly - this middle of the road solution is actually the BEST path for Bitcoin, the most balanced path.  It allows Bitcoin to grow, but to allow it to do so in a more controlled fashion than XT.  The technology surrounding mining and node buildout can continue to parallel that growth at a reasonable pace.  That protects the decentralization.  And because there are smaller blocksize caps looming in stages, there is still enough emphasis and benefit put on sidechain solutions in order to keep main chain transactions manageable.

So everybody gets something.  The biggest winner is the technology itself.  It isn't choked and crippled, nad kept safe in this little controlled box (Blockstream Vision), and it isn't fed steroids and forced to grow in an unhealthy and forced manner (XT Vision).

It is sane.  It is rational.   And what is really really scary is that this clear and simple path can't find a way forward.  And right now.... I don't think you can blame this on Mike Hearn / XT anymore.

RIGHT NOW.... the blame is on Blockstream Players.  They alone hold the keys to this sane, intelligent middle road.

WILL THE REAL CORE/DEV PLEASE STAND UP?!?!?!

Maybe what is needed is for someone to write up a petition?  I wonder if something like the above (reworded, tweeked, possibly with more technical specifics albeit limited for flexibility in final solution - but general enough in conceptualization) should be adopted?

It appears to me that an unbendable, unnegotiable situation currently exists.  Petitions can be a powerful force in these types of situations.   Hearns tried the other path.... blunt force alternative.  Right now we have what looks like American Politics.  Far Left vs Far Right, and nobody in the middle speaking for common sense.  Perhaps a Petition, if crafted to a sane middle path, could be that voice?