Luke-Jr [ARCHIVE] on Nostr: 📅 Original date posted:2011-09-13 🗒️ Summary of this message: Gavin Andresen ...
📅 Original date posted:2011-09-13
🗒️ Summary of this message: Gavin Andresen proposes standard multi-signature transactions for better wallet backup and security, and suggests using deterministic keychains and signmessage for improved security.
📝 Original message:On Tuesday, September 13, 2011 10:43:27 AM Gavin Andresen wrote:
> 3) I'd really like to come to consensus on one or more
> 'multi-signature' standard transactions to enable much better wallet
> backup and security.
More important in this area, IMO, is support for deterministic keychains in
wallets. Type 2, according to gmaxwell's original spec, seems pretty ideal,
and significantly improves security for many use cases. Since it allows a
wallet to contain a public keychain without the matching private keychain,
webservers, POS, and other services can be provisioned only with the keychain
required to generate/access infinite public keys, and without the private
keyroot needed to spend them.
The ideal scenario in this regard, as I see it, is this:
- Webserver wallets are provisioned with multiple public keychains (one per
webserver), and configured to use a specific one for getnewaddress/etc. By
provisioning them with *all* the public keychains, their listtransactions/etc
can see the transactions sent to other webservers, necessary to show
confirmations to the end user and such.
- Business keeps a locked-down *offline* wallet with the private keychains for
all the forementioned public keychains. Only this wallet has the information
required to spend the income. The wallet is encrypted, and can only be
accessed by staff with the proper position/authority to authorize expenses.
- A third wallet is used by staff to prepare expense transactions. It keeps
track of locking coins it knows are in the process of being spent, and any
staff member can create new ones. Once created, they must submit the
transaction to a staff member with the proper authority to bring it to the
offline transaction-signing wallet (on a USB key), where it is signed, and
returned to this third wallet.
Another feature that needs some attention is signmessage. It can be used to
send a transaction id/summary to a specified email address signed by the
sending key of the same transaction (these can be added to the send-money
GUI). This would allow merchants to publish a single payment address and still
be able to verify which customers sent payment.
Published at
2023-06-07 02:25:03Event JSON
{
"id": "a5b48694203d036d2a3cfa0292410eee5369d3718af125ae1ee75e1662c8315c",
"pubkey": "6ac6a519b554d8ff726a301e3daec0b489f443793778feccc6ea7a536f7354f1",
"created_at": 1686104703,
"kind": 1,
"tags": [
[
"e",
"e288f0e159cec0d13055701fb4b9fdef9d33d820e161931a4b4eea1797e302f0",
"",
"root"
],
[
"e",
"701cc82e9e4a0d097d0501ba8e7c8ab2f114f2d4cd82748ce2e37e54290c1d3a",
"",
"reply"
],
[
"p",
"857f2f78dc1639e711f5ea703a9fc978e22ebd279abdea1861b7daa833512ee4"
]
],
"content": "📅 Original date posted:2011-09-13\n🗒️ Summary of this message: Gavin Andresen proposes standard multi-signature transactions for better wallet backup and security, and suggests using deterministic keychains and signmessage for improved security.\n📝 Original message:On Tuesday, September 13, 2011 10:43:27 AM Gavin Andresen wrote:\n\u003e 3) I'd really like to come to consensus on one or more\n\u003e 'multi-signature' standard transactions to enable much better wallet\n\u003e backup and security.\n\nMore important in this area, IMO, is support for deterministic keychains in \nwallets. Type 2, according to gmaxwell's original spec, seems pretty ideal, \nand significantly improves security for many use cases. Since it allows a \nwallet to contain a public keychain without the matching private keychain, \nwebservers, POS, and other services can be provisioned only with the keychain \nrequired to generate/access infinite public keys, and without the private \nkeyroot needed to spend them.\n\nThe ideal scenario in this regard, as I see it, is this:\n- Webserver wallets are provisioned with multiple public keychains (one per \nwebserver), and configured to use a specific one for getnewaddress/etc. By \nprovisioning them with *all* the public keychains, their listtransactions/etc \ncan see the transactions sent to other webservers, necessary to show \nconfirmations to the end user and such.\n- Business keeps a locked-down *offline* wallet with the private keychains for \nall the forementioned public keychains. Only this wallet has the information \nrequired to spend the income. The wallet is encrypted, and can only be \naccessed by staff with the proper position/authority to authorize expenses.\n- A third wallet is used by staff to prepare expense transactions. It keeps \ntrack of locking coins it knows are in the process of being spent, and any \nstaff member can create new ones. Once created, they must submit the \ntransaction to a staff member with the proper authority to bring it to the \noffline transaction-signing wallet (on a USB key), where it is signed, and \nreturned to this third wallet.\n\n\nAnother feature that needs some attention is signmessage. It can be used to \nsend a transaction id/summary to a specified email address signed by the \nsending key of the same transaction (these can be added to the send-money \nGUI). This would allow merchants to publish a single payment address and still \nbe able to verify which customers sent payment.",
"sig": "1715c86b7a6b403c313ad974be350f7f483d20ebb8fd89a563760a84a97d4c5d21503258064e027fdb68cd7934109ae392425414ed99658aa6f38deadd9ac8f6"
}