📅 Original date posted:2015-01-23
📝 Original message:On Fri, Jan 23, 2015 at 4:18 PM, slush <slush at centrum.cz> wrote:
> Can you send me any reference about this? Of course if that solves the
> problem, hard fork would not be necessary anymore. I'm just not aware of
> any.
Sure; will aggregate up the citations when I'm not travling later today.
> To sign transaction with hundreds of inputs on device with limited memory
> capabilities, I need to stream all previous transactions into device, for
> every signed input.
>
> That means roughly 200^2 transaction verifications for 200 inputs to sign.
> Very slow, but does not limit the device for any particular size of signed
> transaction.
I'm not sure where the ^2 is coming from. So what I'd understand that
you'd do is stream in the input txid:vouts which you spend, then you'd
stream the actual inputs which would just be hashed and value
extracted (but no other verification), and you'd build a table of
txid:vout->value, then the actual transaction to be signed.
This should have O(inputs) hashing and communications overhead. Is
there a step I'm missing?
Gregory Maxwell [ARCHIVE] /
npub1f2…crwet
2023-06-07 15:29:03
in reply to nevent1q…n709
Author Public Key
npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwetPublished at
2023-06-07 15:29:03Event JSON
{
"id": "3c44d8627113e788e902fdefa0272c4f0907ed86126c50dd89fa96b7e06c10ec",
"pubkey": "4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73",
"created_at": 1686151743,
"kind": 1,
"tags": [
[
"e",
"6dc832bdb706e2f61589ea679669c46a49f00ca991f53b93fef09a1a229115c6",
"",
"root"
],
[
"e",
"b956ddf157c71633e92ec00a69e8b27e4a69a3dd1842c8e3d1fc28e97dcbb8d9",
"",
"reply"
],
[
"p",
"eb7ca795057ca7cabde6f541c741e661d013414934e5934c2e04c6677625c99a"
]
],
"content": "📅 Original date posted:2015-01-23\n📝 Original message:On Fri, Jan 23, 2015 at 4:18 PM, slush \u003cslush at centrum.cz\u003e wrote:\n\u003e Can you send me any reference about this? Of course if that solves the\n\u003e problem, hard fork would not be necessary anymore. I'm just not aware of\n\u003e any.\n\nSure; will aggregate up the citations when I'm not travling later today.\n\n\u003e To sign transaction with hundreds of inputs on device with limited memory\n\u003e capabilities, I need to stream all previous transactions into device, for\n\u003e every signed input.\n\u003e\n\u003e That means roughly 200^2 transaction verifications for 200 inputs to sign.\n\u003e Very slow, but does not limit the device for any particular size of signed\n\u003e transaction.\n\nI'm not sure where the ^2 is coming from. So what I'd understand that\nyou'd do is stream in the input txid:vouts which you spend, then you'd\nstream the actual inputs which would just be hashed and value\nextracted (but no other verification), and you'd build a table of\ntxid:vout-\u003evalue, then the actual transaction to be signed.\n\nThis should have O(inputs) hashing and communications overhead. Is\nthere a step I'm missing?",
"sig": "1e49c833c55a29de59e198fa776528f46bdee8ca44a061e0d32b3a4ebbf4a0f8bf3551b5f1eccd7747ca0e95664e8e1f2177bdec93654f2240a8cf918417ad7b"
}