An open letter to the community, from the developers of Breadwallet

[Wind_FURY]

I will try not to quote the whole letter because it is quite long for a forum post. Haha. But you can read it on this website, https://whensegwit.com/

But I will quote the important parts that the community, or the part of it that still cares, should read.

At any rate I believe that using the bech32 addresses will be very disruptive. Plus I would not recommend newbies to use it if they want to receive Bitcoins from everyone.

I honestly have some of my cold storage in a legacy address. Those UTXOs are before the Bitcoin Cash fork, which will have access to future hard forks, and they are more valuable in my opinion. I will not touch it.

As a user it is a hard decision. I hope more merchants will pledge to this cause to make it easier for the users. But the best thing to do is to help spread this message to your favorite merchant and your friends.

SegWit is an impressive upgrade that reduces transaction size and packs more transactions into the bitcoin network, which lowers fees and sets the foundation for future scaling prospects. Pretty much everybody who loves bitcoin agrees that the more we all use SegWit, the better off we’ll be.

Yet, surprisingly, SegWit is only utilized by around 40% of bitcoin transactions today. This means the throughput of the bitcoin network is not fully optimized. Available space is being wasted, which results in higher fees for everyone. Right now fees are fairly affordable, but it won’t be long until we see $50 transaction fees again, just like we did last year. So why hasn’t Segwit reached 100% adoption?

One reason could be a lack of sufficient incentives. The majority of current SegWit transactions are wrapped inside of an address format called P2SH, which is backwards-compatible with clients that don’t support SegWit. This allows the receiver of a transaction to utilize Segwit even if the sender doesn’t support it yet. This is a great way to let individual users do their own part to drive adoption forward, but it doesn’t do much to encourage the sender of the transaction to upgrade.

To all the bitcoiners out there, we encourage you to join us: share this page, start a discussion, be among the first to go full Bech32, and with your help, we'll get SegWit to 100% and take bitcoin to the moon.
Bech32 is a new address format created specifically for SegWit. It allows the direct use of SegWit without the wrapper, on top of other improvements, but is not backwards compatible with clients that don’t support SegWit. The hope for SegWit, as shared by Andreas Antonopoulos (@aantonop), Peter Wuille (@pwuille), and many other industry insiders, is to transition fully to Bech32 and move away from wrapping SegWit transactions in P2SH.

The fact that Bech32 isn’t backwards compatible can actually be used as a tool to speed up adoption. If we can rapidly establish Bech32 as the default address format, and discourage the use of P2SH addresses, we can create a temporary rift where senders are obliged to upgrade their software in order to serve receiving customers. The good news is that sending to a Bech32 address isn’t a particularly challenging feature to implement, making the transition reasonably straightforward. Indeed, BRD has had this capability since early 2018.

One could argue SegWit isn’t yet at 100% because there is little reason to move away from backwards-compatible address formats. Thus, we propose the need to “break” bitcoin by dropping support for these formats altogether, creating a compelling reason for both senders and receivers to upgrade their support of bitcoin and let it become the best it can be.

To do our part, the BRD crypto wallet will convert to 100% Bech32 receive addresses. Support will start with an opt-in period beginning in October 2018, allowing all forward-thinking pioneers to take the plunge into the new Bech32 world and turn their smartphones into a pure SegWit machine. Shortly thereafter, these changes will be rolled out to our entire user base as the default setting.
In preparation of this transition, it is important to get as many companies and services as possible to start supporting Bech32. We are proud to have already secured pledges from 5 of our valued partners—Changelly, Simplex, Kraken, Coinberry, and Coinify—to update their software and enable the ability to send to Bech32 to continue serving our customers.

[1714851257]

1714851257

[1714851257]

1714851257

[1714851257]

1714851257

[o_e_l_e_o]

I agree that a forced conversion will be disruptive, but I can see why they are doing it and props to them for taking the initiative on this.

I think the real issue here is education. I would wager that a significant proportion, probably even a majority, of Bitcoin users don't understand the difference between legacy and Segwit, and even less know the difference between Bech32 and P2SH. I was certainly guilty of this when I first got involved in crypto - it's easy just to buy from an exchange and send to a wallet without having really any idea about what you are doing.

[franky1]

oh wind_fury.. your not a coder. so why are you promoting such scheme without you yourself actually putting in the effort of understanding the ramifications.

forced change!! have you not learned anything.

also the data efficiency of transactions to bytes is not efficient using segwit
segwit signatures are 82bytes instead of 72
segwit addresses are a few bytes longer too

a transaction of X inputs and Y outputs consumes more bytes with segwit than with legacy.

all segwit does it cut and hide some data from the baseblock and hold it else where to make it look like a data saving. but its not a data saving. that hidden data does actually sit on hard drives and does actually take up space. even if devs have coded the base block not to count it.. (meaning the 1mb base limit is a fiction now because its got nothing to do with enforcing 1mb of full data going to hard drives.. thus serves no purpose for hard drive data limiting)


if we were to take away the baseblock limit and let legacy utilise the 4mb 'weight' you will see we can fit in more legacy transactions than segwit transactions.

also because segwit needs part of its data in the baseblock. by removing the 1mb limit. also allow more segwit transactions in the 4mb weight too.. and no longer use the 3mb weight as just the separate area for hidden signatures. but instead to utilise all 4mb for fully combined transaction data.

its far better to get rid of the 1mb limit to up the transaction count of both legacy AND segwit, than trying to enforce a tyranny of making users only transact a certain way

as for pretending that it will help pricing of TX's
devs are actually messing with 'dust' and 'minrelay' fee's to push up the price..
even though the market rate of btc goes up. the dust/minrelay should be coded to go DOWN. but they push up those. and then they gave the bait of a discount only to segwit.

segwit does not actually achieve a real transaction byte efficiency on a hard drive. and if they actually reduced the min fee code when market settle at higher value then the transaction prices would be lower.
to devs its like raising the price of a banana and then sticking a discount sticker for only loyalty card holders

EG. bread 2009 £$0.50.....
retailers inflation..
      bread 2018 £$2 'only 50cents to walmart loyalty card holders'

[DooMAD]

oh wind_fury.. your not a coder. so why are you promoting such scheme without you yourself actually putting in the effort of understanding the ramifications.

I wasn't aware that being a coder was some sort of mandatory prerequisite to contribute to the conversation.  Many people arguably prefer Wind_FURY's insights over your own, so let's play nice, okay?

its far better to get rid of the 1mb limit to up the transaction count of both legacy AND segwit, than trying to enforce a tyranny of making users only transact a certain way

In your opinion.  Clearly the breadwallet devs (who, being coders, you clearly concede have the right to make that determination) disagree with you on that part.

[franky1]

( ^ here comes the onslaught of social group defence and no rebuttle of the transaction per byte of hard drive data inefficiency.)

anyway, ignoring the social drama..
if people care about the network protocol and want to do something to actually allow more transactions per block
here some idea's to promote instead

1. schnorr benefits multisig. so yea use schnorr to impact multisigs and let that benefit those wanting to move funds into LN...
    (ensuring LN remains only a voluntary side service. and not a forced 'got to use' forced thing)
2. reduce the unneeded maxsignop limit which allows 1 transaction to hoard 20% of a block (also reduces linear validation fears)
3. remove the 1mb block to allow fully combined transactions to utilise 4mb weight (improves tx count way more than segwits split block strategy)
4. bring down the dust/min relay to amounts that are 4x lower than 2015 levels and that includes doing it for legacy
(infact it should be more than 6x due to the settling(average) market price difference of 2015-2018)

then we will see more transaction availability and cheaper prices per transaction. without forcing people into addresses types

and if anyone is going to rebut "but what about malleation" well new/reactivated opcodes being added actually reintroduce transaction malleability into segwit transactions.

[amishmanish]

Considering the legacy addresses valuable because they will access the forks is tricky. If we go by this logic, then most "Old businesses" will have their majority funds in Legacy addresses too. Why would they be willing to pay the opportunity cost of forks?
What is understandable is older users wanting to keep their cold-storage wallets as a "Fixed asset", only to be used in an emergency or in the hyperbitcoinization scenario. Avoiding the obvious headache of moving 100s of BTC to a new address may also be one of the reasons.

I just hope that accessing forks is the least of their worries.

[pawanjain]

The approach towards 100% adoption of SegWit looks good to me but I hardly believe this will work. There are thousands of people involved in crypto yet only a few know what all of this is all about. Most of the people holding crypto are just here for the sake of money and hence don't know much of the technical aspects of cryptocurrencies. Just think what if a person having a bech32 address sends/receives bitcoin to/from a non SegWit compatible address.
Things like these might create bigger problems and hence forcing people to use it won't be any good unless they know what they are doing.

[squatter]

At any rate I believe that using the bech32 addresses will be very disruptive. Plus I would not recommend newbies to use it if they want to receive Bitcoins from everyone.

I honestly have some of my cold storage in a legacy address. Those UTXOs are before the Bitcoin Cash fork, which will have access to future hard forks, and they are more valuable in my opinion. I will not touch it.

I wouldn't either. In fact, I think Breadwallet and many other people are laying this on a bit thick.

The whole point of backward compatible updates is that they allow for a smooth transition at the cost of fast adoption. I'm slightly annoyed when I see people rushing others to adopt a voluntary upgrade. One of the reasons Segwit was acceptable to users like me is that it was a soft fork, where I could take my time to upgrade. I prefer other people to be the guinea pigs first.

The P2SH-wrapper was meant to be a transitional stage. I say, embrace the transition. 40% adoption -- without Blockchain.info and others -- is pretty damn good! No need to rush things. I use bech32 addresses for day-to-day transactions, but they're not where most of my funds are stored, and I don't care what other people do. I also agree with this:

I would not recommend newbies to use it if they want to receive Bitcoins from everyone.

[o_e_l_e_o]

I prefer other people to be the guinea pigs first.

I can fully accept that, but we are now over a year down the line. It took 6 months to hit 30% SegWit transactions, and another 6 months to climb from 30% to 40%. If we just sit and wait it could be 5+ years before we reach anything near full adoption.

[franky1]

I prefer other people to be the guinea pigs first.

I can fully accept that, but we are now over a year down the line. It took 6 months to hit 30% SegWit transactions, and another 6 months to climb from 30% to 40%. If we just sit and wait it could be 5+ years before we reach anything near full adoption.

if you actually take the data. and count the tx in's and outs. and see which are 'iswitness'. segwit utilisation is actually only 24% that are 'is witness'

as for utility. if you realise that segwit signatures and addresses are longer (wasting a few bytes) that byte per transaction if they were converted to legacy and allowed to utilise the full 4mb all data included. legacy is more efficient

its like having a 225gram banana taking off its 72gram skin. then adding 15 grams of yellow paint to the banana to identify it as a special banana. and then adding 10grams of paint to the 72gram skin... all so that in one box you can say the banana in box 1 is now 168grams.. but if you want a fully validatable banana and store it as a fully validatable and relayable banana you have to take the other box of skins with you.. which makes the total combined banana weight 250grams.. not 225grams

meaning yea for every 3rd banana you strip you can slide in a 4th stripped banana in the box.
but 4 fully validated combined special bananas is now 1kg(672g+328g)
where as 4 legacy bananas would be 900gram for 4 bananas

again the wishy washy nonsense of "but box 1 is only 672g".. but ignoring the second box that must go with the first box

2boxes=1kg..
1legacy box 900g
'but ignore box 2 and segwit is 672g' (facepalm)

again if the 4mb block was fully open for full transaction data
legacy=17777 tx of 225byte
segwit=16000tx of 250byte

.. the 2 box (1mb:3mb)
legacy=4444 tx of 225 with 0 in box two
segwit=5952 tx in box one. 0.488mb in box 2

so segwit with the 1mb wall is limiting segwit by 10,048tx as you cant put any extra in due to the 1mb wall
and as i said take the limit out. and legacy again offers more

keeping the 1mb is not a 4x capacity growth at all

its all just wishy washy crap

[pooya87]

At any rate I believe that using the bech32 addresses will be very disruptive. Plus I would not recommend newbies to use it if they want to receive Bitcoins from everyone.

that is only true for "receiving" bitcoin not "sending" it. and as you already know you don't have to have only one bitcoin address or even one wallet. you can have as many as you like.
you can have a Bech32 address for sending bitcoin and a Base58 P2PKH address to receive bitcoin. then when you want to spend from that Base58 address you each time send the change to your Bech32 address(es) and have that as your main address. and whenever it is accepted anywhere you just use that.

[ImHash]

meaning yea for every 3rd banana you strip you can slide in a 4th stripped banana in the box.
but 4 fully validated combined special bananas is now 1kg(672g+328g)
where as 4 legacy bananas would be 900gram for 4 bananas

again the wishy washy nonsense of "but box 1 is only 672g".. but ignoring the second box that must go with the first box

2boxes=1kg..
1legacy box 900g
'but ignore box 2 and segwit is 672g' (facepalm)

again if the 4mb block was fully open for full transaction data
legacy=17777 tx of 225byte
segwit=16000tx of 250byte

.. the 2 box (1mb:3mb)
legacy=4444 tx of 225 with 0 in box two
segwit=5952 tx in box one. 0.488mb in box 2

so segwit with the 1mb wall is limiting segwit by 10,048tx as you cant put any extra in due to the 1mb wall
and as i said take the limit out. and legacy again offers more

keeping the 1mb is not a 4x capacity growth at all

I really like your analogies Using bananas and their skins to compare them to bitcoin transactions. Which part of the banana is bitcoin and which part is the address? Which part is the actual data and which part is unspent bitcoin? You make this sound like whoever designed segwit is an imbecile, They are not, If everyone uses segwit then there will be no need for the second box to exist, Second box only exist because people are still using legacy, They haven't upgraded to segwit nodes yet. When everyone does that, You'll have only pealed bananas without any paint.
Why don't you talk about the space for the second boxes in segwit without actually having them on board? You should also talk about the new possibilities if segwit were fully adopted by everyone, Every node. What you are saying is that we should make the bitcoin network big enough to have room for the banana skins while they're on the bananas, People don't eat the skin, They throw them away after they peal the bananas, So why should we keep the skins when we can peal them away just to keep the real deal for when we need to eat the real thing?
Having to go with this analogy would make things much difficult to explain, But I did my best to make it simple for the noobs and such.

[franky1]

a good test to see if the community really want it..
breadwallet should ask BTCC pool (the biggest segwit promoter of 2015-2017) to start using segwit as its address to receive its blockrewards..

its been a year and even they have not done so yet
https://www.blockchain.com/btc/block/0000000000000000000d5996219bc24e4f98c6113c2b29c7a5283e181b631730
-> 13TET...
not
-> bc1q

hmmmm

i might also add this.. and just let people who keep promoting 40%.. to take a few steps back and realise. segwit is not as popular as they thought
https://p2sh.info/dashboard/db/bech32-statistics?orgId=1
(hint: 0.764% of al btc is stored on a bech address (132k coins))
(unspent outputs = ~80k of 50million)

seems just as fast as people put funds into addresses starting bc1q, they take them out

hmmmm

[franky1]

I really like your analogies Using bananas and their skins to compare them to bitcoin transactions. Which part of the banana is bitcoin and which part is the address? Which part is the actual data and which part is unspent bitcoin?

the banana(fruit) is the input, value output value
the skin is the signature/scripts

segwit addresses (bc1q) is the layer of paint added to the fruit to add a few xtra bytes to the data
the layer of paint added to the skin is the extra few bytes th signature uses

You make this sound like whoever designed segwit is an imbecile, They are not,

they went a whole 2 years coding something that doesnt offer real scaling.

If everyone uses segwit then there will be no need for the second box to exist, Second box only exist because people are still using legacy, They haven't upgraded to segwit nodes yet. When everyone does that, You'll have only pealed bananas without any paint.

no... you still nee the skins to verify the transaction is valid.. and also when someone else is syncing from you. they need the skins so they can validate their copy FULLY AND INDEPENDENTLY

as i said if you put the skin back on a segwit tx is 250bytes not 225 like its comparative legacy
so if there was no 2 box and just 1 big box..... segwit vs legacy would if utilising the entire 4mb
be like this
legacy=17777 tx of 225byte
segwit=16000tx of 250byte
as best case scenario

Why don't you talk about the space for the second boxes in segwit without actually having them on board? You should also talk about the new possibilities if segwit were fully adopted by everyone, Every node. What you are saying is that we should make the bitcoin network big enough to have room for the banana skins while they're on the bananas, People don't eat the skin, They throw them away after they peal the bananas, So why should we keep the skins when we can peal them away just to keep the real deal for when we need to eat the real thing?

if your a full node.. you are part of the relay network. you need to show the skin to show the fruit is ripe (legit/valid)
yes people can prune the skin(signatures) . but then they are not part of the blockchain relay/archival network
new nodes wont sync via you because you dont have the signatures for them to self check and validate the blocks they get.

you become just a midweight node(gmax buzzword downstream.. luke jr: filtered). only relaying transactions and the latest block(as long as u dont prune it first). and not helping new users sync up and be part of the network.
EG legacy nodes(<0.13) are not full nodes. they dont get the signatures. they get the peeled banana version and they blindly trust someone else validated the block and blindly pass it on as good. (critical security alert if there was a bug)

if you think deleting the signatures is good.. then maybe you might aswell turn off your full node and just use a litewallet

Having to go with this analogy would make things much difficult to explain, But I did my best to make it simple for the noobs and such.

again with the 2box trick your not getting 16k-17k transactions your only getting
.. the 2 box (1mb:3mb)
legacy=4444 tx of 225 with 0 in box two
segwit=5952 tx in box one. 0.488mb in box 2

segit uses 1.488mb for 5952 basic transaction..
so same basic transaction
same 1.488mb space but as space a legacy can fully utilise
is: 6612 legacy transactions for 1.488mb

but yea. i know you want peeled banana's to make it look good.. but then your not a full node(as explained) so go play with a lite wallet and not have any block data to worry about because you trust other nodes to tell you the skin is ripe

[Wind_FURY]

oh wind_fury.. your not a coder. so why are you promoting such scheme without you yourself actually putting in the effort of understanding the ramifications.

But yet you, who acts like you're smarter than everyone, lies and resorts to gaslighting in every argument.

forced change!! have you not learned anything.

I know the ramifications. Read my OP. Did I say "Hurray! Do it!"?

also the data efficiency of transactions to bytes is not efficient using segwit
segwit signatures are 82bytes instead of 72
segwit addresses are a few bytes longer too

Start a topic in development and technical discussion. I want to see you debate with the real developers.

[jseverson]

a transaction of X inputs and Y outputs consumes more bytes with segwit than with legacy.

I just want to point out that Breadwallet's main reasoning behind their open letter is actually lower fees, and lower block weight resulting in more transactions per block than just legacy. You may be right that Segwit is actually more inefficient memory-wise, but they're not at all commenting on where development should be, or should have headed -- just that Segwit has lower fees now.

I'm against forced updates as much as any other person, but this seems more like a plea than a forced order. People really should do their own research before upgrading though.

[Pursuer]

also the data efficiency of transactions to bytes is not efficient using segwit
segwit signatures are 82bytes instead of 72
segwit addresses are a few bytes longer too

Start a topic in development and technical discussion. I want to see you debate with the real developers.

this part at least is not something you need a developer to debate! it is easy and very obvious. he is correct. SegWit transactions add extra bytes to the transactions for the 00 flag, the size of witness at the end,... you can check a SegWit transaction yourself and see. but the problem with that comment is that it is only focusing on one part and that being the size of a tx. and the difference however is not that big!

SegWit was never meant for scaling alone. SegWit was meant to do multiple things such as fixing malleability problem and in addition to that it was meant to increase capacity with a soft fork maintaining backward compatibility so we don't need to hard fork.
then that malleability fix can open up room for other development such as a much more secure LN on top of bitcoin.

[franky1]

oh wind_fury.. your not a coder. so why are you promoting such scheme without you yourself actually putting in the effort of understanding the ramifications.

But yet you, who acts like you're smarter than everyone, lies and resorts to gaslighting in every argument.

lies?
kinda funny..
i actually go out of my way to do the math. i even post in examples, stats and other things.
did you even check the link about the UTXO set
UTXO DATA CANT LIE
its stuck in the blockchain.. its literally above the laws of truth that cant be edited..

but hey. when others who just say "he lies".. they can never actually back it up .. they just say "wrong because wrong"
wow such powerful proof.

ok you called me a liar.. so.. show me a UTXO set that has 20 million segwit addresses(40%)
show me a month of blocks that have actual real 40% segwit utility
show me a month of blocks that have actual real 30% segwit utility

the only parts people cant agree on is my method of explaining.
i try to keep it simple using analogies or rounding numbers for simple math demo purposes. then get some anal social drama queens try knitpicking my ELI-5 explanations without taking it all into context of simple explanation

i understand you are new to segwit and still learning. but these discussions with me devs and others have been going on for a couple years now. so yea sometimes when a non-dev gets involved and tries social drama distractions of name calling by poking the bear.. yea i bite..

forced change!! have you not learned anything.

I know the ramifications. Read my OP. Did I say "Hurray! Do it!"?

also the data efficiency of transactions to bytes is not efficient using segwit
segwit signatures are 82bytes instead of 72
segwit addresses are a few bytes longer too

Start a topic in development and technical discussion. I want to see you debate with the real developers.

i have done.
but they just send in their non-dev buddies to social drama the topic to death.
but just so you know. devs have once they put their personal attack hats on the floor and start wearing their critical thinking caps. end up changing some code or plans.

the funny thing is. segwit and LN is not open dev desired. its actually contracted employed code that benefits financial investors that contracted them to make bitcoin LN compatible.

[franky1]

SegWit was never meant for scaling alone. SegWit was meant to do multiple things such as fixing malleability problem and in addition to that it was meant to increase capacity with a soft fork maintaining backward compatibility so we don't need to hard fork.
then that malleability fix can open up room for other development such as a much more secure LN on top of bitcoin.

this is not me poking the bear or countering anything you have to say.
but now devs are adding/reactivating some opcodes that reintroduce malleability attacks done using bech addresses...

(i just thought that was something funny worth adding to your point)

the devs know all about it. and they were wanting to rename a few opcodes with warnings.
(they had to take a few steps back and re-think a few things)

[franky1]

a transaction of X inputs and Y outputs consumes more bytes with segwit than with legacy.

I just want to point out that Breadwallet's main reasoning behind their open letter is actually lower fees, and lower block weight resulting in more transactions per block than just legacy. You may be right that Segwit is actually more inefficient memory-wise, but they're not at all commenting on where development should be, or should have headed -- just that Segwit has lower fees now.

I'm against forced updates as much as any other person, but this seems more like a plea than a forced order. People really should do their own research before upgrading though.

its not lower fee's
dont you get it.
its like walmart.. raise the prices via increasing(not decreasing) the minrelay/dust..
and then put a sticky label on that says 'rollback' 75% off if your a walmart loyalty card holder

the relay/dust should be 10x lower than they were in 2015.. they are not. infact they are higher than 2015
then ontop they x4 legacy transactions prices..

its a bait and switch