đ
Original date posted:2018-03-15
đ Original message:Sorry if I missed the rationale earlier, but why not just do a transaction,
with a FORKID specifically for this? Then a node can have a mempool
acceptance test that returns true even if the signature is not valid as per
Bitcoin consensus, but only due to the FORKID?
This way basically any wallet can support this provided generic FORKID
support.
On Thu, Mar 15, 2018 at 8:38 PM, Karl Johan Alm via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Thu, Mar 15, 2018 at 2:14 PM, Luke Dashjr <luke at dashjr.org> wrote:
> > Not necessarily specific UTXOs (that would contradict fungibility, as
> well as
> > be impossible for hot/cold wallet separation), but just to prove funds
> are
> > available. The current sign message cannot be used to prove present
> possession
> > of funds, only that you receive funds.
>
> By saying "not necessarily specific UTXOs", are you saying it may be
> spent outputs? I'm a little confused I think.
>
> On Thu, Mar 15, 2018 at 8:53 PM, Jim Posen <jim.posen at gmail.com> wrote:
> > In this general signing-a-script context, I think a verifier might want
> to
> > see the time conditions under which it may be spent. The proof container
> > could include an optional nLockTime which defaults to 0 and nSequence
> which
> > defaults to 0xFFFF...
>
> Good point!
>
> >> I think it would just use the default (SIGHASH_ALL?) for simplicity.
> >> Is there a good reason to tweak it?
> >
> > I took another look and there should definitely be a byte appended to the
> > end of the sig so that the encoding checks pass, but I think it might as
> > well be a 0x00 byte since it's not actually a sighash flag.
>
> I think the sighash flag affects the outcome of the actual
> verification, but I could be mistaken.
>
> -Kalle.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180315/e55106e6/attachment.html>;
Greg Sanders [ARCHIVE] /
npub1jdâŚ3gh0m
2023-06-07 18:11:14
in reply to nevent1qâŚ3s8a
Author Public Key
npub1jdl3plz00rvxwc6g2ckemzrgg0amx5wen4kfvs3laxtssxvk9cvsf3gh0mPublished at
2023-06-07 18:11:14Event JSON
{
"id": "765e8a4fda0500043eeb585c0c0bbd02bba6d274f4880902b164520b6c7dc2c5",
"pubkey": "937f10fc4f78d8676348562d9d886843fbb351d99d6c96423fe9970819962e19",
"created_at": 1686161474,
"kind": 1,
"tags": [
[
"e",
"fde6d8b8cd384fa838810364bd9a6edd18aea9246ae8127a644187087642ae18",
"",
"root"
],
[
"e",
"ebd0424a7e911770709dcfab03eb94baae68d0c2335bcf797091cf08be7a8bcc",
"",
"reply"
],
[
"p",
"cf98d015f410ea690e93370543fcb2c3129303ca3921fd6d463206f557722518"
]
],
"content": "đ
Original date posted:2018-03-15\nđ Original message:Sorry if I missed the rationale earlier, but why not just do a transaction,\nwith a FORKID specifically for this? Then a node can have a mempool\nacceptance test that returns true even if the signature is not valid as per\nBitcoin consensus, but only due to the FORKID?\n\nThis way basically any wallet can support this provided generic FORKID\nsupport.\n\nOn Thu, Mar 15, 2018 at 8:38 PM, Karl Johan Alm via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e On Thu, Mar 15, 2018 at 2:14 PM, Luke Dashjr \u003cluke at dashjr.org\u003e wrote:\n\u003e \u003e Not necessarily specific UTXOs (that would contradict fungibility, as\n\u003e well as\n\u003e \u003e be impossible for hot/cold wallet separation), but just to prove funds\n\u003e are\n\u003e \u003e available. The current sign message cannot be used to prove present\n\u003e possession\n\u003e \u003e of funds, only that you receive funds.\n\u003e\n\u003e By saying \"not necessarily specific UTXOs\", are you saying it may be\n\u003e spent outputs? I'm a little confused I think.\n\u003e\n\u003e On Thu, Mar 15, 2018 at 8:53 PM, Jim Posen \u003cjim.posen at gmail.com\u003e wrote:\n\u003e \u003e In this general signing-a-script context, I think a verifier might want\n\u003e to\n\u003e \u003e see the time conditions under which it may be spent. The proof container\n\u003e \u003e could include an optional nLockTime which defaults to 0 and nSequence\n\u003e which\n\u003e \u003e defaults to 0xFFFF...\n\u003e\n\u003e Good point!\n\u003e\n\u003e \u003e\u003e I think it would just use the default (SIGHASH_ALL?) for simplicity.\n\u003e \u003e\u003e Is there a good reason to tweak it?\n\u003e \u003e\n\u003e \u003e I took another look and there should definitely be a byte appended to the\n\u003e \u003e end of the sig so that the encoding checks pass, but I think it might as\n\u003e \u003e well be a 0x00 byte since it's not actually a sighash flag.\n\u003e\n\u003e I think the sighash flag affects the outcome of the actual\n\u003e verification, but I could be mistaken.\n\u003e\n\u003e -Kalle.\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180315/e55106e6/attachment.html\u003e",
"sig": "0a1140ee6684a5687f6dafcec0ee758070dec7c786265d2c36a29e73a51edcf70cd343756b494d41cd90fef63c07671eeb787d89dc75a5696abd6d0b570cd22e"
}