📅 Original date posted:2015-07-26
📝 Original message:(Resending to the new bitcoin-dev list after sending to the old list)
2015-07-25 21:34 GMT+02:00 Jorge Timón <jtimon at jtimon.cc>:
> Then why do you assume they have a policy limit that not even bitcoin core
> itself maintains (the default limit was moved from 42 to 83 [counting the
> op_return and pushes])?
>
> The policy check is not a consensus rule. Other implementations may have
> another default or not have a limit at all.
Thank you for pointing this out.
That's right. Bitcoin core now support 80 bytes data by default. And
yes, I was wrong in assuming 40 bytes policy in all implementations,
even if 40 bytes was the limit in bitcoin core at the time of writing
the BIP.
If there's a need to increase the size of the nonce, for example to
128 bits instead of the 48 bits as designed in BIP 120, then we can of
course do that, either now or in a subsequent version of PoP.
As noted before though, a longer nonce also means bigger QR codes
generated from the BIP 121 URIs. So I think that 48 bits is a good
tradeoff right now. And as stated in BIP120, a server generating PoP
requests should try to detect brute force attacks, or at least delay
the response (containing the nonce) by some 100 ms or so.
Do you think we need a bigger nonce? In that case, why?
If PoP later becomes an extension of BIP70, then there is no such size
constraint on the nonce, since it will be part of some kind of (e.g.)
PopRequest message and not contained in a QR encoded URI.
/Kalle
Kalle Rosenbaum [ARCHIVE] /
npub1uw…55zf7
2023-06-07 15:43:37
in reply to nevent1q…cj3p
Author Public Key
npub1uwweecasakwtk96j3vjmkjenhnhyv4rku382txq0kmexjwuh4w2st55zf7Published at
2023-06-07 15:43:37Event JSON
{
"id": "ca1cf34dc398feb00a5137eba0c90d8ea2d5af71616a92a9f228a5d19cb3e187",
"pubkey": "e39d9ce3b0ed9cbb17528b25bb4b33bcee465476e44ea5980fb6f2693b97ab95",
"created_at": 1686152617,
"kind": 1,
"tags": [
[
"e",
"c618a60e66f76a881e58dd42cf1d41eaad30f1dbeccc51c4b29c645c6d64153f",
"",
"root"
],
[
"e",
"d520f0227b9cb3fdf9ec170f45bd7baca6d65c966ed69ac68fc1b16770ceff1d",
"",
"reply"
],
[
"p",
"29893ebd1701ae21591c4f0a8c73d8eb2696e4dec64e856a2e1f3ddd060eadd9"
]
],
"content": "📅 Original date posted:2015-07-26\n📝 Original message:(Resending to the new bitcoin-dev list after sending to the old list)\n\n2015-07-25 21:34 GMT+02:00 Jorge Timón \u003cjtimon at jtimon.cc\u003e:\n\u003e Then why do you assume they have a policy limit that not even bitcoin core\n\u003e itself maintains (the default limit was moved from 42 to 83 [counting the\n\u003e op_return and pushes])?\n\u003e\n\u003e The policy check is not a consensus rule. Other implementations may have\n\u003e another default or not have a limit at all.\n\nThank you for pointing this out.\n\nThat's right. Bitcoin core now support 80 bytes data by default. And\nyes, I was wrong in assuming 40 bytes policy in all implementations,\neven if 40 bytes was the limit in bitcoin core at the time of writing\nthe BIP.\n\nIf there's a need to increase the size of the nonce, for example to\n128 bits instead of the 48 bits as designed in BIP 120, then we can of\ncourse do that, either now or in a subsequent version of PoP.\n\nAs noted before though, a longer nonce also means bigger QR codes\ngenerated from the BIP 121 URIs. So I think that 48 bits is a good\ntradeoff right now. And as stated in BIP120, a server generating PoP\nrequests should try to detect brute force attacks, or at least delay\nthe response (containing the nonce) by some 100 ms or so.\n\nDo you think we need a bigger nonce? In that case, why?\n\nIf PoP later becomes an extension of BIP70, then there is no such size\nconstraint on the nonce, since it will be part of some kind of (e.g.)\nPopRequest message and not contained in a QR encoded URI.\n\n/Kalle",
"sig": "574e56930c461407ec99494f0169756bb2e2c2c7f4ad5fd8abd215b2229070a064eac7376b0d0dc64d365cd9ab7f9a0c7529db02ff2ce481bba528426540cbf0"
}