Re: Nonsense about increasing the 21M supply cap

Quote

1) Are you talking about the UTXO model?

Yes. In general, I think that this:

Code:

+----------------------------------------------+ +----------------------------------------------+
| Alice 1.00000000 BTC -> Bob 0.50000000 BTC | | Bob 0.50000000 BTC -> Charlie 0.10000000 BTC |
| Alice 0.49999000 BTC | | Bob 0.39999000 BTC |
+----------------------------------------------+ +----------------------------------------------+

Will take more on-chain space, than this:

Code:

As you can see, the final outcome is exactly the same. Fees are identical, amounts are identical, but the batched transaction will take less space, than non-batched two transactions, just because in the first case, you have to store Bob's data on-chain, but in the second case, Bob can just keep a proof locally, but nobody else needs that proof.

Quote

2) It will be awesome if you support your claims with proper mathematical calculations.

Let's assume, that we use these regtest addresses:

Code:

bcrt1qtgaawjdc9ntf0gcujfu0rx25tnddh65zj7fyd2 Alice
bcrt1qgne9hgmelwfq25tv9p74hvrhpu54fp5hyhtku5 Bob
bcrt1q56n28k46acsalrah3vgqykv70s3crv8fk7k7pq Charlie
bcrt1qhv22hzfzppuzuyfhamx8wujez3wpgjv6xvf2xr AliceChange
bcrt1qlxyv80uq4c5mj6r6r05ue9h92n8hhx283sqhcp BobChange

And let's assume, that we use 1000 satoshis per transaction, as a fee. Then we have:

Code:

+----------------------------------------------+
| Alice 1.00000000 BTC -> Bob 0.50000000 BTC |
| Alice 0.49999000 BTC |
+----------------------------------------------+
| Weight: 560 bytes |
+----------------------------------------------+

Transaction data:

Code:

decoderawtransaction 02000000000101757b4468801a1c03822502563e78f363c03678e6fc7f41dd3c9f9692e62947830000000000fdffffff0280f0fa020000000016001444f25ba379fb9205516c287d5bb0770f2954869798ecfa0200000000160014bb14ab892208782e1137eecc777259145c14499a0246304302202576b269429202db4638df0e5108924c52e93c3e39ee19a28fba899cd0f0d1f3021f5a234876825606b6597cbbccdda771d000894ce657a2c63dbb93474d3a1edd0121037d9652e4ab7eb49882c3a803ac412bd727002c717d33f33e389c6ad7014adc7a65000000
{
"txid": "8823421a1086bd01c06220cbae230513d359e4e6c2eea5d1133c4d2dfb7402f7",
"hash": "7e6c1fab5dc6575f0478036b03de68a24bdd8c28393e4875337595c19a1aa7f5",
"version": 2,
"size": 221,
"vsize": 140,
"weight": 560,
"locktime": 101,
"vin": [
{
"txid": "834729e692969f3cdd417ffce67836c063f3783e56022582031c1a8068447b75",
"vout": 0,
"scriptSig": {
"asm": "",
"hex": ""
},
"txinwitness": [
"304302202576b269429202db4638df0e5108924c52e93c3e39ee19a28fba899cd0f0d1f3021f5a234876825606b6597cbbccdda771d000894ce657a2c63dbb93474d3a1edd01",
"037d9652e4ab7eb49882c3a803ac412bd727002c717d33f33e389c6ad7014adc7a"
],
"sequence": 4294967293
}
],
"vout": [
{
"value": 0.50000000,
"n": 0,
"scriptPubKey": {
"asm": "0 44f25ba379fb9205516c287d5bb0770f29548697",
"desc": "addr(bcrt1qgne9hgmelwfq25tv9p74hvrhpu54fp5hyhtku5)#3m4hqnkd",
"hex": "001444f25ba379fb9205516c287d5bb0770f29548697",
"address": "bcrt1qgne9hgmelwfq25tv9p74hvrhpu54fp5hyhtku5",
"type": "witness_v0_keyhash"
}
},
{
"value": 0.49999000,
"n": 1,
"scriptPubKey": {
"asm": "0 bb14ab892208782e1137eecc777259145c14499a",
"desc": "addr(bcrt1qhv22hzfzppuzuyfhamx8wujez3wpgjv6xvf2xr)#e4k5ccyh",
"hex": "0014bb14ab892208782e1137eecc777259145c14499a",
"address": "bcrt1qhv22hzfzppuzuyfhamx8wujez3wpgjv6xvf2xr",
"type": "witness_v0_keyhash"
}
}
]
}

Second transaction:

Code:

+----------------------------------------------+
| Bob 0.50000000 BTC -> Charlie 0.10000000 BTC |
| Bob 0.39999000 BTC |
+----------------------------------------------+
| Weight: 561 bytes |
+----------------------------------------------+

Transaction data:

Code:

decoderawtransaction 02000000000101f70274fb2d4d3c13d1a5eec2e6e459d3130523aecb2062c001bd86101a4223880000000000fdffffff028096980000000000160014a6a6a3dabaee21df8fb78b1002599e7c2381b0e91856620200000000160014f988c3bf80ae29b9687a1be9cc96e554cf7b99470247304402205412c259d4dd8a783159f545509c086ea1fe85ea0a716ab98d45195fb1bc6b10022047c8a7faed2379f7d6e589301cd7e22b01c3dd642c4c9db8f0de6ee705cdb5b1012102248ba02ebf822efc4e118755efc6b2afb1e3208b071f3056e0d666a35459599465000000
{
"txid": "53f552546ddac64d9e8cf061ef88af32e8bc180d91f546273711884d81746cf6",
"hash": "945c80db2d8208a4388983500641fef5c4104e88526c336158335d2dce918148",
"version": 2,
"size": 222,
"vsize": 141,
"weight": 561,
"locktime": 101,
"vin": [
{
"txid": "8823421a1086bd01c06220cbae230513d359e4e6c2eea5d1133c4d2dfb7402f7",
"vout": 0,
"scriptSig": {
"asm": "",
"hex": ""
},
"txinwitness": [
"304402205412c259d4dd8a783159f545509c086ea1fe85ea0a716ab98d45195fb1bc6b10022047c8a7faed2379f7d6e589301cd7e22b01c3dd642c4c9db8f0de6ee705cdb5b101",
"02248ba02ebf822efc4e118755efc6b2afb1e3208b071f3056e0d666a354595994"
],
"sequence": 4294967293
}
],
"vout": [
{
"value": 0.10000000,
"n": 0,
"scriptPubKey": {
"asm": "0 a6a6a3dabaee21df8fb78b1002599e7c2381b0e9",
"desc": "addr(bcrt1q56n28k46acsalrah3vgqykv70s3crv8fk7k7pq)#nje9902a",
"hex": "0014a6a6a3dabaee21df8fb78b1002599e7c2381b0e9",
"address": "bcrt1q56n28k46acsalrah3vgqykv70s3crv8fk7k7pq",
"type": "witness_v0_keyhash"
}
},
{
"value": 0.39999000,
"n": 1,
"scriptPubKey": {
"asm": "0 f988c3bf80ae29b9687a1be9cc96e554cf7b9947",
"desc": "addr(bcrt1qlxyv80uq4c5mj6r6r05ue9h92n8hhx283sqhcp)#zyauga6q",
"hex": "0014f988c3bf80ae29b9687a1be9cc96e554cf7b9947",
"address": "bcrt1qlxyv80uq4c5mj6r6r05ue9h92n8hhx283sqhcp",
"type": "witness_v0_keyhash"
}
}
]
}

Batched version:

Code:

Transaction data:

Code:

decoderawtransaction 02000000000101757b4468801a1c03822502563e78f363c03678e6fc7f41dd3c9f9692e62947830000000000fdffffff038096980000000000160014a6a6a3dabaee21df8fb78b1002599e7c2381b0e91856620200000000160014f988c3bf80ae29b9687a1be9cc96e554cf7b994798ecfa0200000000160014bb14ab892208782e1137eecc777259145c14499a0247304402206e84fee8ff1300776dfac9e506e9f3bb3bc2e2be992109a526c61d8ca4ffe9ac02204260554c76d8c637ba861b31af150faa4ba780a391ad4fe35c9dec4b348521f90121037d9652e4ab7eb49882c3a803ac412bd727002c717d33f33e389c6ad7014adc7a65000000
{
"txid": "a7a857cddc4196baa72254fcd2b7d20416b3fbbde27ce5bd166c47886c2796b4",
"hash": "97552eaf1b84bd0b6b06e15c1f4dd4d28d412b4f77ab8ffe827a9508e79616f4",
"version": 2,
"size": 253,
"vsize": 172,
"weight": 685,
"locktime": 101,
"vin": [
{
"txid": "834729e692969f3cdd417ffce67836c063f3783e56022582031c1a8068447b75",
"vout": 0,
"scriptSig": {
"asm": "",
"hex": ""
},
"txinwitness": [
"304402206e84fee8ff1300776dfac9e506e9f3bb3bc2e2be992109a526c61d8ca4ffe9ac02204260554c76d8c637ba861b31af150faa4ba780a391ad4fe35c9dec4b348521f901",
"037d9652e4ab7eb49882c3a803ac412bd727002c717d33f33e389c6ad7014adc7a"
],
"sequence": 4294967293
}
],
"vout": [
{
"value": 0.10000000,
"n": 0,
"scriptPubKey": {
"asm": "0 a6a6a3dabaee21df8fb78b1002599e7c2381b0e9",
"desc": "addr(bcrt1q56n28k46acsalrah3vgqykv70s3crv8fk7k7pq)#nje9902a",
"hex": "0014a6a6a3dabaee21df8fb78b1002599e7c2381b0e9",
"address": "bcrt1q56n28k46acsalrah3vgqykv70s3crv8fk7k7pq",
"type": "witness_v0_keyhash"
}
},
{
"value": 0.39999000,
"n": 1,
"scriptPubKey": {
"asm": "0 f988c3bf80ae29b9687a1be9cc96e554cf7b9947",
"desc": "addr(bcrt1qlxyv80uq4c5mj6r6r05ue9h92n8hhx283sqhcp)#zyauga6q",
"hex": "0014f988c3bf80ae29b9687a1be9cc96e554cf7b9947",
"address": "bcrt1qlxyv80uq4c5mj6r6r05ue9h92n8hhx283sqhcp",
"type": "witness_v0_keyhash"
}
},
{
"value": 0.49999000,
"n": 2,
"scriptPubKey": {
"asm": "0 bb14ab892208782e1137eecc777259145c14499a",
"desc": "addr(bcrt1qhv22hzfzppuzuyfhamx8wujez3wpgjv6xvf2xr)#e4k5ccyh",
"hex": "0014bb14ab892208782e1137eecc777259145c14499a",
"address": "bcrt1qhv22hzfzppuzuyfhamx8wujez3wpgjv6xvf2xr",
"type": "witness_v0_keyhash"
}
}
]
}

Then, instead of having weight of 560 bytes + 561 bytes = 1121 bytes, you have a single weight of 685 bytes.

Quote

3) Don't forget about network data propagation delays.

You don't have to remove all data right away. You can use a similar strategy, as pruned nodes, and for example keep the full data, from the last 288 blocks. But: in the long-term scenario, you can remove in-the-middle proofs, because they are not needed for Initial Blockchain Download.

Quote

4) Remember that blockchain security relies on full nodes that do all verifications in full against all protocol rules. Full nodes never rely on any spv-like proofs. There is no compromise here on what is better. There are no "options" here to think about.

SPV proofs are not needed, to make sure, that the system is honest. They are needed only to show, who was inside. All signatures are valid in both versions: batched and non-batched. You need a valid ECDSA signature, to move any coins anywhere, no matter what.

Quote

5) Finally. Could you estimate what is % of transactions go in chains "Alice->Bob->Charlie" within short time intervals compared to stand-alone transactions "Alice to Bob"? If transactions which could be "batched" are very rare, then how can you get any non-marginal efficiency improvement here?

I didn't create any on-chain statistics yet, but I can see, that there are many unconfirmed transactions, which could be batched. In the example above, where you can see two typical one-input-two-output transactions, you can see, how it can be batched into a single one-input-three-output transaction, doing exactly the same things.

And note, that batching just two transactions into one, is the simplest case. If you batch for example 10 transactions, then you will save more space, while consuming the same inputs, and making the same final outputs.