@Murch
stacking since: #127838
366 sats \ 0 replies \ @Murch 30 Oct \ on: What are you working on this week? meta
I have been traveling a lot in the past few weeks and a lot happened. I was on vacation, went to the Core Dev meeting and attended TABConf. We announced Localhost Research, a new Bitcoin Core contributor office that we are launching in the Bay Area last weekend.
Work piled up a bit. I already went through new questions on Bitcoin Stack Exchange, co-hosted the Bitcoin Optech Recap and BitDevs yesterday, agreed to a podcast appearance about Cluster Mempool in a couple weeks, went through a bunch of emails. I still need to (not sorted by priority):
- Take some notes about the conversations I had last week at TABConf
- Review a paper on consensus changes
- Review the new compatibility matrix on Optech
- Do about 20 reviews on Bitcoin Core pull requests
- Address review on my own Bitcoin Core pull request
- Address review on my BIP-2 successor draft
- Go over a ton of activity in the BIPs repository from the last weeks
So, I will work on some of that.
Every person has only 24h per day. We cannot be involved in every decision that affects our lives, nor would we as a society be able to decide anything if every single person were to speak on every single topic. You can of course pretend that decisions made by people outside your direct vicinity don’t affect your life if that’s your preference, but if other people decide to weigh in on societal processes by electing someone to represent their interests that’s outside of your self-sovereignty. A representative probably won’t always be exactly in line with your position on everything, and some representatives often fall short of their mandate, but in a functioning democracy they may still help achieve an outcome that benefits overall. Democracy is a messy process of compromises, but the alternative of sticking your head in the sand doesn’t seem all that appealing either.
I spent some time on flights in the past few weeks, so I got around to watching
- Please Stand By
- The Fall Guy
- Furiosa
The Fall Guy was great. The other two were okay.
As one of the co-hosts, I’m obviously biased, but if you are trying to keep up with Bitcoin development, Mike Schmidt and I put out the weekly Bitcoin Optech Recap, where we and our guests talk about the content of the weekly Bitcoin Optech Newsletter.
red: A+B+C+D+E = x
green: B+C+D+E+G+H+I = x
yellow: C+D+G+H+F = x
blue: D+E+H+I+J = x
red - green: A - (G+H+I) = 0
A = G+H+I
green - yellow: B+E+I - F = 0
F = B+E+I
green - blue: B+C+G - J = 0
J = B+C+G
We notice that there are three symmetric groups of letters. As starting points for any solution, A, F, and J are interchangeable, B, G, and I are interchangeable, and C, E, and H are interchangeable.
Since A…J are each unique values and integers from [1..10], the minimum value for three letters to be summed is 1+2+3 = 6. A, F, J must be 6 or bigger.
None of B, C, E, G, H, I can be bigger than 7, as 7 + 2 + 1 = 10
We suspect that D is 7. Proof by contradiction:
Let’s assume A = 6. If A is six, G, H, and I must be 1, 2, and 3 in some configuration.
If that’s the case, for F = B+E+I to be valid, I must be 1 and B and E must be 4 and 5. Otherwise, F would be bigger than 10. However, for the same reason, G would have to be one and B+C would be 9 which is in contradiction to the requirement that each number only appears once. Due to the symmetry, it follows that none of A, F, and J can be 6.
Let’s assume A = 7. This means that G, H, and I must be 1, 2, 4 in some order. It would follow that I is either 1 or 2.
- If I were 4, F would necessarily be greater than 10 as the next two lowest numbers we can use for B and E are 3 and 5.
- If I is 2, B and E must be 3 and 5, which makes F 10. This leaves C to be at least 6, in which case J would be at least 10 as well 3+6+1 = 10. F and J cannot both be 10.
- If I is 1, B and E could be 3 and 5 or 3 and 6. 3a. Let’s assume they are 3 and 6, which makes F = 10. Then the lowest remaining number for C is 5. This would make J at least ten via J = 3+C+2. Again, both J and F would be 10. We follow that due to the symmetry, neither A, F, or J can be 7. A, F, and J must be 8, 9, and 10.
Among B, C, E, G, H, and I three characters appear twice in our formulas for A, F, and J and three appear only once.
Let’s assume one of B, G, and I were 7, for example B. This leads to F = 7+E+I and J = 7+C+G. Let’s assume E and I are 1 and 2, which makes F 10. J ends up being bigger than 10. It follows that B, G, and I cannot be 7.
Let’s assume one of C, E, or H is 7, e.g. H. If H is 7, G and I have to be 1 and 2 for A to only be 10, let’s say G is 1 and I is 2 (the other pick is symmetric).
It follows that F and J have to be either 8 or 9 each.
- Let’s say F is 8, it follows that B + E = F - I = 6. This would only be possible if B and E could either 1 and 5, 2 and 4, or 3 and 3. 1 and 2 are already assigned, and 3 and 3 is not permitted.
- Let’s say F is 9. Because I is already 2, B and E must be 3 and 4. This leaves J to be 8. G is 1 and B is either 3 or 4. C would have to be 4 or 3 respectively, but both are taken.
Because neither the three letters A, F, and J, nor the three letters B, G, and I, nor the three letters C, E, or H can be 7, given all the restrictions, only D can be 7.
Per a close look, we guess that the three letters that only appear once should be 4, 5, and 6, and see that the following configuration would be viable:
A = G+H+I = 1 + 6 + 3 = 10
F = B+E+I = B + E + 3 = 2 + 4 + 3 = 9
J = B+C+G = 2 + 5 + 1 = 8
I.e. A = 10, B = 2, C = 5, D = 7, E = 4, F = 9, G = 1, H = 6, I = 3, J = 8
Checking back in the original formulation of the problem:
red: A+B+C+D+E = 10 + 2 + 5 + 7 + 4 = 28
green: B+C+D+E+G+H+I = 2 + 5 + 7 + 4 + 1 + 6 + 3 = 28
yellow: C+D+G+H+F = 5 + 7 + 1 + 6 + 9 = 28
blue: D+E+H+I+J = 7 + 4 + 6 + 3 + 8 = 28
Q.E.D.
Is it?
The only part that refers to the documentary is that it’s "far from the first journalistic attempt to put an identity to the Nakamoto pseudonym". That might be a brief synopsis, but hardly a "critical evaluation of a piece of work".
While the context is nice, this appears to be a description of the prior attempts more than a review of the Money Electric documentary.
- The bakery is right between Hong’s house and Jeya’s house.
- The library is 120 m closer to Jeya from the bakery.
- Hong had to cycle to the bakery and then 120 m more.
- Jeya had to cycle 120 m less than the way to the bakery.
- Hong cycled 2×120 m = 240 m more than Jeya.
- They both arrive at the same time, so Hong cycling
faster enabled her to cycle 240 m more. Per , we learn that Hong and Jeya cycled for 16 minutes. - In 16 minutes, Jeya cycled
to the library.
As we discussed in yesterday's Optech Recap, package relay, TRUC transactions and Pay-to-Anchor well hopefully what lightning channels with zero fee in the commitment transaction in the next year or two. This would remove a huge source of channel closures.
Oh, I missed that 329 byte input last time. I would suspect that an uncompressed pubkey was in play.
That was beautiful ngl, not quite the same but Greg Walker also made something similar with his explorer
Oh cool, I hadn’t seen that addition to Greg’s site yet.
ECDSA signatures are not fixed in size. High-s signatures became non-standard after 2014LOL, are Schnorr (for P2TR) & FALCON (for upcoming P2QRH) safe from this ?
Yeah, ECDSA signatures used a weird encoding, but the schnorr signatures have a fixed size encoding. No idea about P2QRH, that seems a bit far out still.
I can offer this 2-of-2 P2TR transaction meanwhile, if that is of help: https://mempool.space/tx/905ecdf95a84804b192f4dc221cfed4d77959b81ed66013a7e41a6e61e7ed530
wrapped segwit where inputs can have both an input script and witness items.Is this about Nested P2WPKH & P2WSH ? I might have to redo this part again to fix this
Yeah, that’s right. Nested P2WPKH/P2WSH is another term for Wrapped P2WPKH/P2WSH.
it should maybe be pointed out that in the serialization the witness structure is separate from the input and output sections.Yes, i'm using the same TX structuring as what currently used by Bitcoin Optech Calculator. I don't mind separating the witness part with dedicated space though
Yeah, we did not make that distinction in the calculator, because the weight of the witness stack directly is dictated by the input type. However, as soon as one input has a witness stack, you need a witness structure, and a witness structure must contain a witness stack for every single input. For non-segwit inputs the witness stack consists simply of a witness item counter that is 0, but this means that the weight of non-segwit inputs goes up by one weight unit when they are combined with segwit inputs.
You can see the separate witness structure for example in the yogh.io explorer that nicely visualizes the transaction serialization (I picked a 2-of-3 wrapped segwit example from your list above): https://yogh.io/tx/23e2e8453fd9d00fc38833e996e042c35d60f5ac2196a2462a44930323694c17/
P2SH 2-of-3 should be 293–297Now that is confusing, i still don't understand how can the same address have different scriptSig (what could possibly caused that ?)Here for example : https://mempool.space/tx/c7d8845045a4f3bd998bc1dbe63928f1e22029e5b056c00a56c2e478a2a08960?mode=details The 5th input has :
- TX ID + Vout = 36 + 4
- scriptSig length = 3
- scriptSg = 255
- Total = 298
And not just once, the second example also behaves the sameThis one example has even bigger input size :
- TX ID + Vout = 36 + 4
- scriptSig length = 3
- scriptSig = 286
- Total = 329, is this a non-standard example ?
Ah, fair point. I haven’t verified, but given the date of the transaction I can still suggest a possible explanation. ECDSA signatures are not fixed in size, among other things, the r and s component of the signature varies in size depending on whether the value falls in the upper half or lower half of the value range. High-s signatures became non-standard after 2014, given that your example is from 2012, I expect that some of the signatures are high-s.
P2SH-P2WSH 2-of-3 should be 139–139.5For input size 139 vB & 139.25 vB i can find example of that, but haven't found any example of 139.5 vB input size
b426792a6f8f78e59172c1a65db1da4b60797162f9081b6f7a8b31665597d537 should fit the bill.
Thanks, may i ask a favor for one or two mainnet example of P2TR 2-of-3 scriptpath tho, it's for research purpose i promise
Sorry, I don’t have one on hand from the top of my head, but I will think about how to find one.
Okay, now I have a little more time.
The "Script Type" table was a bit confusing to me.
I assume that the third column only refers to the second column and the first column is independent. At first I was reading the table as rows, and that didn’t make sense to me.
Regarding the transaction components:
- minor typo: it’s "Marker" and "Flag"
- The two columns seem to represent legacy inputs and native segwit inputs, but there is also a transitory mix of the two: wrapped segwit where inputs can have both an input script and witness items.
- Also given that you reference serialization artifacts like the script length, it should maybe be pointed out that in the serialization the witness structure is separate from the input and output sections.
You may be interested in my opinionated BIP draft for transaction terminology here: https://github.com/murchandamus/bips/pull/1 (I really need to pick that up again!)
Regarding the block size/weight: given that unfortunately megabyte can both refer to 1000² bytes and 1024² bytes, to be clear the block size limit was 1,000,000 bytes which corresponds to just 1,000,000 vB, not 4,000,000 vB (see e.g. https://bitcoin.stackexchange.com/a/53626/5406).
Regarding Results:
- As mentioned in my other comment, the smallest possible OP_RETURN output should come in as 11 bytes.
- Regarding the multisig stuff, I think that some of them are off by a byte or so, e.g.:
- P2SH 2-of-3 should be 293–297 (see https://bitcoin.stackexchange.com/a/114254/5406), unless you are allowing high-s?
- P2SH-P2WSH 2-of-3 should be 139–139.5
Regarding P2A, the 13 vB output would always be the same across all anchors, since it’s a standard template.
Thanks for sharing your research, very cool!
I can't find any example of it with 105 vB input size yet
It’s really 418 weight units, which would translate to 104.5 vB, but the way vsize is defined, it’s supposed to be rounded up to the next integer. To be fair, I think I’ve been inconsistent on that one in the past years.
Pay to Taproot (P2TR). Scriptpath 2-of-3²: 82.75 vB–115.5 vB
This is out of my knowledge, for now i only know about keypath and 2-of-2 P2TR, interested to find these example i haven't found before but i have no tools to automate this (i do it manually)
I think the shortest nulldata output is 11 B.
Kudos for your efforts. Most of this looks good, but there are a few mistakes here and there. I’m prepping for the Optech Recap, so I’ll have to get back to this later, but I wanted to point out that a lot of the same information is compiled in topics tagged "transaction-weight" on Bitcoin Stack Exchange: https://bitcoin.stackexchange.com/questions/tagged/transaction-weight?tab=Frequent, e.g. https://bitcoin.stackexchange.com/a/75124/5406, https://bitcoin.stackexchange.com/questions/100159/what-is-the-size-and-weight-of-a-p2wpkh-input