Quote
By doing so it ?solves? many issues that Bitcoin has. These benefits are laid out here.
-Malleability Fixes
-Linear scaling of sighash operations
-Signing of input values
-Increased security for multisig via pay-to-script-hash (P2SH)
-Malleability Fixes:-Malleability Fixes
-Linear scaling of sighash operations
-Signing of input values
-Increased security for multisig via pay-to-script-hash (P2SH)
after activation no immediate fix.
what actually happens is users have to move funds to segwit keypairs (voluntarily opt-in)
its not solving Malleability because Malleability scammers wont opt in.
segwit does not simply prevent malleability for the whole network. people will still malleate tx's
while only some users who were innocent of not performing this attack in the first place are the only ones disabled from performing it by opting in
-Linear scaling of sighash operations
after activation no immediate fix
what actually happens is users have to move funds to segwit keypairs (voluntarily opt-in)
its not solving quadratics because quadratics scammers wont opt in.
infact the new rule core implementation actually causes more quadratics issues
core v0.12 maxtxsigops=4000 (<10seconds validation)
core v0.14 maxtxsigops=16000 (<8 minutes validation)
segwit does not simply prevent quadratics for the whole network. people will still do quadratic spamming, but now even more maliciously
while only some users who were innocent of not performing this attack in the first place are the only ones disabled from performing it by opting in
Quote
Signing of input values
When a hardware wallet signs a transaction, it can easily verify the total amount being spent, but can only safely determine the fee by having a full copy of all the input transactions being spent, and must hash each of those to ensure it is not being fed false data. Since individual transactions can be up to 1MB in size, this is not necessarily a cheap operation, even if the transaction being signed is itself quite small.
When a hardware wallet signs a transaction, it can easily verify the total amount being spent, but can only safely determine the fee by having a full copy of all the input transactions being spent, and must hash each of those to ensure it is not being fed false data. Since individual transactions can be up to 1MB in size, this is not necessarily a cheap operation, even if the transaction being signed is itself quite small.
funny part is.. by changing to "signing of input values".. causes decreased security of multisig.
hint below
Quote
Increased security for multisig via pay-to-script-hash (P2SH)
Multisig payments currently use P2SH which is secured by the 160-bit HASH160 algorithm (RIPEMD of SHA256). However, if one of the signers wishes to steal all the funds, they can find a collision between a valid address as part of a multisig script and a script that simply pays them all the funds with only 80-bits (280) worth of work, which is already within the realm of possibility for an extremely well-resourced attacker.
Multisig payments currently use P2SH which is secured by the 160-bit HASH160 algorithm (RIPEMD of SHA256). However, if one of the signers wishes to steal all the funds, they can find a collision between a valid address as part of a multisig script and a script that simply pays them all the funds with only 80-bits (280) worth of work, which is already within the realm of possibility for an extremely well-resourced attacker.
so segwit one feature causes the need of another feature.. and that has been over played and exaggerated as to suggest LN cannot function without segwit. when infact segwit breaks security in one part to then repair the security.. making them combined. no benefit at all.
afterall an LN is just a 2in 2out tx.. not a 1mb tx like the 'signing of input' feature suggests its meant to avoid.
LN doesnt care about the 'signing of input' feature. because LN tx's will never be 1mb.
oh.. and funny part. it also reveals.. core actually are allowing a single tx to be 1mb!!! seriously. that should have been nipped in the bud years ago
Quote
Efficiency gains when not verifying signatures
Signatures for historical transactions may be less interesting than signatures for future transactions – for example, Bitcoin Core does not check signatures for transactions prior to the most recent checkpoint by default, and some SPV clients simply don’t check signatures themselves at all, trusting that has already been done by miners or other nodes. At present, however, signature data is an integral part of the transaction and must be present in order to calculate the transaction hash.
Segregating the signature data allows nodes that aren’t interested in signature data to prune it from the disk, or to avoid downloading it in the first place, saving resources.
Signatures for historical transactions may be less interesting than signatures for future transactions – for example, Bitcoin Core does not check signatures for transactions prior to the most recent checkpoint by default, and some SPV clients simply don’t check signatures themselves at all, trusting that has already been done by miners or other nodes. At present, however, signature data is an integral part of the transaction and must be present in order to calculate the transaction hash.
Segregating the signature data allows nodes that aren’t interested in signature data to prune it from the disk, or to avoid downloading it in the first place, saving resources.
this is the silliest one of all
if you dont want to be a validation node.. just dont run a full node.
lets node degrade the full node count by pretending a prunned node is a full node..
why even do such a thing of putting litenode features in a full node, other nodes can then no longer sync from it meaning it starts creating a cesspit of nodes that cant sync from each other
Quote
Block capacity/size increase
Since old nodes will only download the witness-stripped block, they only enforce the 1 MB block size limit rule on that data. New nodes, which understand the full block with witness data, are therefore free to replace this limit with a new one, allowing for larger block sizes. Segregated witness therefore takes advantage of this opportunity to [useless] limit to nearly 4 MB, and adds a new cost limit to ensure blocks remain balanced in their resource use (this effectively results in an effective limit closer to 1.6 to 2 MB).
Since old nodes will only download the witness-stripped block, they only enforce the 1 MB block size limit rule on that data. New nodes, which understand the full block with witness data, are therefore free to replace this limit with a new one, allowing for larger block sizes. Segregated witness therefore takes advantage of this opportunity to [useless] limit to nearly 4 MB, and adds a new cost limit to ensure blocks remain balanced in their resource use (this effectively results in an effective limit closer to 1.6 to 2 MB).
only if EVERY transaction inside the native 1mb block has opted in to segwit keypair funding, to then let their witness hang outside the native base block.. emphasis. only if everyone moves to use segwit keypairs
If I had his knowledge about the
