📅 Original date posted:2014-06-15
📝 Original message:Andreas Schildbach <andreas <at> schildbach.de> writes:
> Generally I like the simplicity of this BIP. Still, I have more questions:
>
> What is the use of the Transactions message? Note the Payment message
> already contains a transactions field that could be signed.
Transactions message sole purpose is to allow easy signing of all
transactions
i don't think you can serialise a single field
maybe i missed something, not sure
> Can you
> briefly describe the whole flow of messages on an example, including the
> BIP70 messages?
I'll get back to the list with something tomorrow,
can be useful in the BIP as an example anyway I guess.
> Should we allow adding multiple signatures (from different instant
> providers
maybe in some different scheme of "instantness" that could be useful,
although i wonder if it's possible to keep the BIP simple with
such non immediately obvious use cases.
> or maybe while transitioning to another PKI)?
another PKI, not sure, I understand there are already somewhat weak industry
schemes to revoke.
I do wonder if there's any better and more "future proof" way.
I'll think about it but for now I hope someone with more experience can
share some insight.
Lawrence Nahum [ARCHIVE] /
npub1q9…w5u98
2023-06-07 15:22:41
in reply to nevent1q…tqcq
Author Public Key
npub1q96r67z2pgf6zg3t7zkxd77fdgzz8euhwazmkdh4adrlrlt40unqnw5u98Published at
2023-06-07 15:22:41Event JSON
{
"id": "2b2a04fcf13cfbd9f86b0587042f4939ebc74b4e3b74eecce5141f6aedeb03d7",
"pubkey": "01743d784a0a13a1222bf0ac66fbc96a0423e7977745bb36f5eb47f1fd757f26",
"created_at": 1686151361,
"kind": 1,
"tags": [
[
"e",
"ed0eede28e160c2ef8ddd5af1ee3069fdb0eb5f4c939c1c09a1a5f338c30c628",
"",
"root"
],
[
"e",
"ea99d847204346273b9a645b816c949e05b82af746119f0365213d9b20a6930a",
"",
"reply"
],
[
"p",
"3215b3d77dff1f84eeb5ad46fb1206a8d1657b3ea765a80b5489ece3a702d2bc"
]
],
"content": "📅 Original date posted:2014-06-15\n📝 Original message:Andreas Schildbach \u003candreas \u003cat\u003e schildbach.de\u003e writes:\n\n\u003e Generally I like the simplicity of this BIP. Still, I have more questions:\n\u003e \n\u003e What is the use of the Transactions message? Note the Payment message\n\u003e already contains a transactions field that could be signed.\n\n \n\nTransactions message sole purpose is to allow easy signing of all \ntransactions\ni don't think you can serialise a single field\nmaybe i missed something, not sure\n\n\u003e Can you\n\u003e briefly describe the whole flow of messages on an example, including the\n\u003e BIP70 messages?\n\nI'll get back to the list with something tomorrow, \ncan be useful in the BIP as an example anyway I guess.\n\n\u003e Should we allow adding multiple signatures (from different instant\n\u003e providers\n\n\nmaybe in some different scheme of \"instantness\" that could be useful, \nalthough i wonder if it's possible to keep the BIP simple with \nsuch non immediately obvious use cases.\n\n\n\u003e or maybe while transitioning to another PKI)?\n\nanother PKI, not sure, I understand there are already somewhat weak industry \nschemes to revoke.\nI do wonder if there's any better and more \"future proof\" way.\nI'll think about it but for now I hope someone with more experience can \nshare some insight.",
"sig": "c4e41a0e0a85171a4c50c2978c656f9b45fd6ee134f63dff01f5cfcaff27d7cd4d07b23d4b3151fd1754c58d0de9ee5cde01b1da30077e493635a39f6f8351e0"
}