Apologies for the super massive OP. It's necessary though.

"You know how you can tell it's a compromise? Because all parties are equally unhappy!!!!" - Larry David in the "Car Pool Lane" episode of Curb Your Enthusiasm


Larry David is famously pessimistic, but this particular truism applies very aptly to the Segwit proposal, and I will explain why.


4MB is too big. Very quickly after it activates, the transaction spammers could take advantage of the extra space, and stuff all 4MB with spam.




Here's how -

Single sig:
A typical transaction is around 250 Bytes in size, comprising 1 input and 2 outputs (1 output goes to the receiving party, the other goes back to the sender as their change). Only one person controls the spending keys for the input address, so only one signature is required.

Multi sig:
Multi sig transactions are different. They can have a wide range of sizes, while still comprising only 1 input and 2 outputs. The number people needed to sign the transaction increases the size of the transaction, like this:

• 500 Bytes for addresses controlled by 2 parties
• 750 Bytes for adressess controlled by 3 parties
• 1,000 Bytes for addresses controlled by 4 parties
• 1,250 Bytes for addresses controlled by 5 parties
• 1,500 Bytes for addresses controlled by 6 parties

etc.....





Visually:

Single Sig

<  250 bytes   >

|    -    | ||    -    ||
tx data    sig 1



2 party Multi-sig

<        500 bytes       >

|    -    | ||    -    ||    -    ||
tx data    sig 1    sig 2



3 party Multi-sig


<             750 bytes             >

|    -    | ||    -    ||    -    ||    -    ||
tx data   sig 1    sig 2   sig 3



4 party Multi-sig


<                 1000 bytes                  >

|    -    | ||    -    ||    -    ||    -    ||    -    ||
tx data   sig 1    sig 2   sig 3    sig 4

---

So, now that we can see clearly how increasing the number of people need to sign the transaction increases the size of the transaction, here's how it can be used to spam the 4MB size



1 Regular full 1MB block (i.e. HOW IT WORKS NOW)

|||      1 MB limit       |||

 <          1 MB          >

 |      -      | ||      -      ||
   tx data         sigs




1 Segwit block filled with 100% single sig transactions


|||                                                 4 MB limit                                                    |||

 <          1 MB          > <          1 MB          >

 |               -              | ||              -              ||
            tx data                         sigs



1 Segwit block filled with 100% 2 party Multisig transactions


|||                                                 4 MB limit                                                    |||

 <          1 MB          > <                        2 MB                         >

 |               -              | ||                            -                             ||
            tx data                                       sigs



1 Segwit block filled with 100% 3 party Multisig transactions


|||                                                 4 MB limit                                                    |||

 <          1 MB          > <                                     3 MB                                       >

 |               -              | ||                                         -                                          ||
            tx data                                                    sigs



1 Segwit block filled with 100% 4 party Multisig transactions


|||                                                 4 MB limit                                                    |||

 <       0.8 MB       > <                                       3.2 MB                                     >

 |             -             | ||                                           -                                           ||
           tx data                                                    sigs



1 Segwit block filled with 100% 5 party Multisig transactions


|||                                                 4 MB limit                                                    |||

 <    0.667 MB   > <                                       3.333 MB                                     >

 |           -           | ||                                             -                                             ||
        tx data                                                     sigs



1 Segwit block filled with 100% 6 party Multisig transactions


|||                                                 4 MB limit                                                    |||

 <   0.571 MB  > <                                        3.428 MB                                      >

 |          -          | ||                                              -                                              ||
       tx data                                                     sigs

---

So, we can see from this exactly how Segwit's new structure and new blocksize limit can be abused by the spammers: simply create the same mega-flood volumes of transactions as now, using the maximum Multi-sig signing parties they can (the protocol defines 15 multi-sig signing parties as the maximum)


That could potentially produce a maximum of 0.25 MB block of transaction data and 3.75 MB witness block of signature data, cutting tx/s rate to 0.75/s. Not good.





What I hope this demonstrates is that Segwit indeed is not perfect, it's a compromise.

THESE ARE ONLY SCENARIOS. In reality, real users of the Bitcoin network will outcompete the spam using higher fees.


And so, what does increasing the blocksize really achieve? The spam potential scales up at the same ratio the transaction rate does. We'd have more space for transactions, sure, but the TX FEES WILL BE ESSENTIALLY THE SAME. And the blockchain will grow x4 as fast as it does now.





So, I'm not saying Segwit's a bad idea. IT'S A COMPROMISE, WITH DRAWBACKS, AND IMPROVEMENTS. The sooner people genuinely understand the trade-offs, and why small-block people such as myself prefer to keep an absolute 1MB limit, and use 2nd layer networks like Lightning, Sprite etc to achieve TRUE TX SCALING, the better.

This could never work

1. It depends entirely on the capacity of the network (which is highly ironic given the circumstances). The so-called "votes" would be in competition with other transactions for the limited blockspace. This creates distorted incentives to "vote", and a poorly representative poll as a result

2. There is no algorithmic mechanism to enforce the majority preference, the miners or pools who accept these votes could simply take the money and implement nothing.

But the mirror spec does support BIP32/39/44? I received my Trezor recently, and would like it working with Armory ASAP



So 0.96 signing will be recommended for compatibility from now on? And the recommended signing version should freeze at 0.97 assuming the wallet format is finalised in that version?



How does the rewrite improve privacy?



What exactly does the scheme comprise, in comparison to the overall format? It sounds like the scheme is simply a component of the format.



I have to say I like that you've done it this way, it provides flexibility and hence options to the user, allowing each user to use their own judgement of the possible risks of the changes to the code and act accordingly (which you no doubt intended).

If you name is inherently insulting to you, you should take responsibility for choosing it

You can't expect good will from those to whom you demonstrate bad will, Dwarf

I'm not quite sure what the status is with the wallet format. It's obviously changed, but which changes are working now? (even on testnet in the case of PSWPKH)

It's very much a nit, but the format version string still reads 1.35 when I create a new wallet, and it seems rather like the old wallet format has it's address chain folded into the new format somehow? I WANT A NUMBER (even if it's 1.35.0.0.0.1 )

Can I delete the old wallet files, or are they the file system representation of the address chain for the new format?

I'd do it were it not for your false accusation that I hurled insults at you

The evidence that this didn't even happen is in plain black and white on this page

The opposite

Multi signature means a single input signed by more than one key.



How can you pretend not to understnad something so simple.....

There is no "reserved for future use". Franky is a misleading statement incarnate.


The Segwit testnet mined a 4MB block, just by including alot of multi-signature transactions (which obviously have a much heavier transaction:signature ratio than regular transactions)



Do you have any arguments that don't involve subverting plainly observable facts?

When you say "Segwit data", you're talking about the data that signs transactions, to prove that the real user actually sent the money.


Are you sure it's not you misleading everyone dwarf? By pretending that signing the transactions is somehow something new, or unneeded?

This is goatpig's admirable pragmatism at work; there were still bugs like this in 0.95.x, but delaying the release to squash them wasn't really worth the trade-off of not getting the releases out. He's one man, doing the job of several, and at this early stage for the new code in Armory (which AFAIA was a significant re-write), it made more sense to let non-critical bugs slide. Alot of these have been dealt with for 0.96 so far, and certainly some aspect of unconfirmed balances was fixed in the last few days (I know not the details of that though)

I think you're right actually, as the contents of the version string added to coinbase transactions isn't part of the consensus rules, I'm not sure if this is even a soft fork (using the definition of soft forks the Bitcoin developers use). It would, though, eventually fork non-compliant miners from the chain that enforces this, so it's perhaps better described as an unorthodox soft fork.

Or a hard fork by.... by..... users?


off topic


Do you have a useful contribution to make, amaclin?

Segwit IS the compromise, and it's more of a compromise towards big blocks than what you're suggesting.


Which is bigger, 2 MB blocks or 4 MB blocks  

Nice idea, Arubi.

Using a broader reason that includes rejection of BU blocks as a subset is highly desirable, as taking the opportunity to solve multiple problems at once is expedient.


Can anyone think of possible downsides to this approach? What legitimate reason is there for miners to include arbitrary information in their coinbase transactions at all?

Segwit IS the compromise. I've refrained from saying this up until recently, but I think 4MB is too big. I'd be much happier with a Segwit proposal that kept the size at 1MB, but in the hope that others would recognise that 4MB is meeting in the middle, I helped to promote Segwit hoping they would accept it. The fact they have rejected Segwit only demonstrates that bigger blocks has got nothing to do with it, it's about having power over the source code.

The trouble with Sergio is that he insists on patenting everything he's done up to now instead of creating it with an Open Source licence. Saying 2000 tps sounds wonderful, but I would like to see how it's done. I'm just not going to be running closed source code using my money, so unless the source is fully open, this is just Sergio making a bunch of unverifiable promises. We'll see.

Also, this sounds very much like a hard fork. Good luck with that aspect.

And, of course, it's a Bitcoin.com story. Say no more.

BU will have 100% of it's own hashrate, when it actually becomes a coin. It might happen sooner than anyone expects


Bitcoiners hold all the cards jonald, i.e. the nodes. It would be so incredibly easy to force BU to fork away from Bitcoin, and all you're achieving is building the support for making that happen. Thanks for helping

Then why are you so frightened of the truth about Segwit keys?

Like I said, 6-8 weeks is all it would take to move all 14 million outputs, and not all will move straight away anyway, so it will take less than that. No-one will want the old P2PKH & P2SH keys, as they'll be more expensive to spend from once you get your money. Regular business will switch to providing Segwit keys very quickly. So there's very little to worry yourself about

In a month or so, a majority of outputs will be moved to Segwit keys already. No need to worry about Sigops attacks, the exact same attack is possible now, as it's limited to 1MB now and after Segwit. Spamming with old keys won't really work, miners will happily accept higher fees for old keys, or reject old keys (they can make more money if they choose to confirm transactions that fill the whole 4MB limit). Nothing forces miners to accept spammy or attack transactions, as you can see by how much spam gets kicked out of miner's mempools right now.


You're all a bunch of worriers here, you just need the correct information to set your hearts at rest We'll be able to enjoy the ~2MB blocks that Segwit keys will initially yield after only a few weeks, those are the facts.