Quote from: icopress on Today at 12:09:13 AM

I can’t remember where it is, but I know for sure that the signed message is somewhere in the public domain (it contains the full text of the agreement).

The same conditions should have been with OG (but the link with his name is no longer active). ^{[https://bitcointalk.org/T19/OgNasty.txt]}

Quote from: https://bitcointalk.org/T19/DarkStar_.txt

-----BEGIN BITCOIN SIGNED MESSAGE-----
T19 MULTISIG CONTRACT

This is a contract between DarkStar_ ("signer") and theymos.
Signer agrees to participate in a 3-of-5 multisig contract
securing up to 1500 bitcoins, in return for 0.75 bitcoins per
year.

Signer will generate a new Bitcoin public/private keypair for
use in this contract, publish the public key, and keep the
private key perpetually secret and secure (even past the end of
the contract). This public key will be used in a 3-of-5 multisig
Bitcoin-smart-contract.

The bitcoins covered by the contract remain owned by and in the
possession of theymos. This contract does not create a separate
entity, and the signers are not through this contract operating
any type of custodial account. Whenever bitcoins legitimately
leave the possession of the multisig contract, it can only be
because of a direction from theymos, authorized either near the
time of the transaction or through in-advance instructions.

In all matters involving the multisig keys, signer will follow
the instructions of theymos, possibly including detailed
in-advance instructions, as long as the instructions are
reasonably practical to implement, legal, and any extraordinary
costs are reimbursed by theymos. For example, if signer receives
an authenticated instruction from theymos telling him to sign a
certain partially-signed transaction as soon as possible using
the standard transaction-signing algorithm, then signer must do
so, and in this example there should be no extraordinary costs.

From the start, this special in-advance contingency instruction
is in place: (Note that this goes beyond what would normally be
a "reasonably practical" instruction.) If the signer has good
reason to believe that theymos will be unable to issue any
instructions under this contract for more than 1 year -- for
example due to him dying, becoming long-term-indisposed,
disappearing without a trace, being overdue on the yearly fee
required under this contract for more than 6 months, or
explicitly stating that he will be unable to issue instructions;
but not simply because theymos has demonstrated a habit of not
issuing instructions for a long time --, then signer will in a
very public fashion work with the other multisig signers,
bitcointalk.org staff, and notable bitcointalk.org users to see
to the creation of a US non-profit organization with a mission
similar to "In order to increase freedom in the world: Operate
bitcointalk.org and/or sites similar to bitcointalk.org, work
toward the long-term success of Bitcoin, and work toward more
widespread decentralization and applied cryptography." If a
suitable organization already exists, then a new one need not be
created. Once an organization exists which 3 of 5 signers can
agree has a sufficiently-matching mission statement and an
organizational/management structure capable of effectively
fulfilling it, then they are instructed to create and sign a
Bitcoin transaction to send all of the bitcoins covered by the
multisig to the organization. Signer agrees in advance to forego
future yearly fees indefinitely and to forgive past unpaid fees
if this contingency instruction is triggered.

This contract is terminated only if any of the below occur:
1) Theymos demands the private key from signer, and signer
produces it as required.
2) Signer sends theymos his private key on his own initiative
in order to exit the contract.
3) Due to the complete execution of the contingency
instruction, the multisig contract covers no more bitcoins.

After the first yearly fee is paid and the contract is ongoing,
non-payment of a future yearly fee does not terminate the
contract or otherwise end signer's responsibilities under this
contract except possibly via the contingency instruction, though
signer has a right to demand payment of the fee. If signer fails
to follow instructions as required by this contract, then no fee
is due from that point.

Signer must use reasonable methods of securely authenticating
instructions, encrypting/securing the private keys, and
encrypting the private keys if they are transmitted to theymos
(but in a way that theymos can decrypt, such as by encryption to
his PGP public key). If any of the bitcoins protected by the
multisig arrangement are lost/stolen due clearly & directly to
insufficient care by signer, then signer will be responsible for
these losses. Signer has a right to demand, and typically should
demand, non-repudiable authentication such as a PGP signature
from theymos for any instructions.

Authentication guidelines: the exact means of authentication is
left somewhat vague above in order to allow for the flexible
handling of weird circumstances. Usually theymos will send
signers PGP-signed instructions. If these instructions involve
signing a partially-signed transaction which already has
theymos's multisig signature, then this is sufficient
authentication unless signer has some reason to suspect a
problem. If not, then signer should be skeptical -- theymos's
multisig key is in cold storage, while his PGP public key (and
well-known 1NXY... address) is not. If in doubt, delay, demand
more proof, and make the whole thing public. theymos has been
around for almost 10 years, so there's a nearly-endless amount
of info about him which could be used as part of authentication
if necessary. For example, you could demand a signature from his
published forum cold storage addresses, have him provide old
chat log excerpts, provide bank statements with forum-related
expenses, publish some of bitcointalk.org's unpublished source
code, etc. Do not sign any transactions if there is any
reasonable doubt surrounding authentication. If worst comes to
worst and it seems impossible that theymos will ever be able to
be confidently authenticated, then this would warrant triggering
the contingency instruction; better that than giving the BTC to
a thief.

Signer's public key for the multisig:
022b94eb3a6608aef8f18620dff203833ccf601d1800e49dfe2b8dc7326706c091

Signer's Bitcoin address for receiving the first year's payment:
bc1qjw4n3mu5q2hlzjca3ufkhyn7pzmw6pshruzu9f
-----BEGIN SIGNATURE-----
1DarkStrRagcDjWtsPGxkav4WG3poLXzDS
G4r0hCYSqUw8wsFWzSX6u5pOegMTIjngFBxLwMN9Nh4ARWQRYHiVs7oypxub1EahZof5FbrYfLt2N+jdK5ew0kg=
-----END BITCOIN SIGNED MESSAGE-----
-----BEGIN PGP SIGNATURE-----
Comment: theymos signature with sha256

iF4EAREIAAYFAlzbj74ACgkQxlVWk9q1kee0bQEAm6IcgYQ3Wpv2RN2guAI4eMsj
zeNz48HpRM0OzHpbziAA/RoBE6JTL1G2VR/4HquSfo+qEEPUEfI/oemvmML8Mntm
=P2oi
-----END PGP SIGNATURE-----