š
Original date posted:2015-02-12
š Original message:A similar idea was proposed by Sirer and me as a part of two-phase proof of
work (2P-PoW) [1]. In 2P-PoW the first phase is Bitcoin's standard PoW and
the second phase requires the signature. This way Bitcoin doesn't lose its
mining power (read: security) in one day, but rather it is possible to
gradually switch from the current PoW to the signature-based one, slowly
phasing out the existing hardware and mining datacenters.
For a more general view of nonoutsourceable puzzles you can check out
Miller et al.'s paper [2].
Ittay
[1]
http://hackingdistributed.com/2014/06/18/how-to-disincentivize-large-bitcoin-mining-pools/
[2] https://cs.umd.edu/~amiller/nonoutsourceable.pdf
------------------------------
>
> Message: 2
> Date: Wed, 11 Feb 2015 08:54:15 +0000
> From: Hector Chu <hectorchu at gmail.com>
> Subject: [Bitcoin-development] Proposal: Requiring a miner's signature
> in the block header
> To: bitcoin-development at lists.sourceforge.net
> Message-ID:
> <
> CAAO2FKEFxC_byt4xVJb0S-7yy0M7M-Av7MHUH-RBDuri_GAFtw at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> A proposal for stemming the tide of mining centralisation -- Requiring a
> miner's signature in the block header (the whole of which is hashed), and
> paying out coinbase to the miner's public key.
>
> Please comment on whether this idea is feasible, has been thought of
> before,
> etc., etc. Thank you.
>
> Motivation
> ----------
>
> Mining is centralising to a handful of pool operators. This is bad for a
> number of political reasons, which we won't go into right now. But I have
> always believed that some years down the line, they could hold the users
> hostage and change the rules to suit themselves. For instance by
> eliminating
> the halving of the block reward.
>
> Solution
> --------
>
> Currently the block header is formed by the pool operator and distributed
> for
> hashing by the pooled miners. It is possible to divide the work among the
> miners as the only thing that is used to search the hash space is by
> changing
> a nonce or two.
>
> I propose that we require each miner to sign the block header prior to
> hashing. The signature will be included in the data that is hashed.
> Further,
> the coinbase for the block must only pay out to the public key counterpart
> of
> the private key used to sign the block header.
>
> A valid block will therefore have a signature in the block header that is
> verified by the public key being paid by the coinbase transaction.
>
> Ramifications
> -------------
>
> Work can no longer be divided among the pooled miners as before, without
> sharing the pool's private key amongst all of them. If the pool does try to
> take this route, then any of the miners may redeem the coinbase when it
> matures. Therefore, all miners will use their own key pair.
>
> This will make it difficult to form a cooperating pool of miners who may
> not
> trust each other, as the block rewards will be controlled by disparate
> parties
> and not by the pool operator. Only a tight clique of trusted miners would
> be
> able to form their own private pool in such an environment.
>
> Attacks
> -------
>
> Pooled hashpower, instead of earning bitcoins legitimately may try to break
> the system instead. They may try a double-spending attack, but in order to
> leverage the pool to its full potential the pool operator would again have
> to
> share their private key with the whole pool. Due to the increased
> cooperation
> and coordination required for an attack, the probability of a 51% attack is
> much reduced.
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
> Message: 3
> Date: Wed, 11 Feb 2015 10:25:27 +0100
> From: Natanael <natanael.l at gmail.com>
> Subject: Re: [Bitcoin-development] Proposal: Requiring a miner's
> signature in the block header
> To: Hector Chu <hectorchu at gmail.com>
> Cc: bitcoin-development at lists.sourceforge.net
> Message-ID:
> <CAAt2M1_qj0r03=
> Ref9mN7bJLg-odep3m5teZ7JWDLC+zknQdQQ at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Den 11 feb 2015 09:55 skrev "Hector Chu" <hectorchu at gmail.com>:
> >
> > A proposal for stemming the tide of mining centralisation -- Requiring a
> > miner's signature in the block header (the whole of which is hashed), and
> > paying out coinbase to the miner's public key.
> >
> > Please comment on whether this idea is feasible, has been thought of
> before,
> > etc., etc. Thank you.
> >
> > Motivation
> > ----------
> >
> > Mining is centralising to a handful of pool operators. This is bad for a
> > number of political reasons, which we won't go into right now. But I have
> > always believed that some years down the line, they could hold the users
> > hostage and change the rules to suit themselves. For instance by
> eliminating
> > the halving of the block reward.
>
> [...]
>
> > I propose that we require each miner to sign the block header prior to
> > hashing. The signature will be included in the data that is hashed.
> Further,
> > the coinbase for the block must only pay out to the public key
> counterpart of
> > the private key used to sign the block header.
>
> [...]
>
> > This will make it difficult to form a cooperating pool of miners who may
> not
> > trust each other, as the block rewards will be controlled by disparate
> parties
> > and not by the pool operator. Only a tight clique of trusted miners would
> be
> > able to form their own private pool in such an environment.
>
> People already trust things like cloud mining, so your solution with
> increasing technical trust requirements won't help. But you will however
> break P2Pool instead.
>
> Also, note that threshold signatures (group signatures) could probably be
> used by an actual distrusting pool's miners. There are already a proof of
> concept for this implemented with secp256k1 that works with Bitcoin clients
> silently. This wouldn't prevent such a pool from working.
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150212/518ed3b1/attachment.html>;
Ittay [ARCHIVE] /
npub1n8ā¦637cg
2023-06-07 15:30:04
in reply to nevent1qā¦4zk2
Author Public Key
npub1n8ytpf4jzavm7hl9t5zksuefcguu6k3frvztqqc4kgcdkwduqesq0637cgPublished at
2023-06-07 15:30:04Event JSON
{
"id": "2323ff6cf17504b0fd6a84482b50ea82ced6c54348816f22c52eca4f42cb0ca9",
"pubkey": "99c8b0a6b21759bf5fe55d05687329c239cd5a291b04b00315b230db39bc0660",
"created_at": 1686151804,
"kind": 1,
"tags": [
[
"e",
"a27447558e2c18eb9e16ddaee1ffa66ad78386dbe3a17b2a401bc665222c72a8",
"",
"root"
],
[
"e",
"6fc3d2cb14e11016c8e76dd7599ad5db374dad72f2c00906c2c2ac32fd1d74cd",
"",
"reply"
],
[
"p",
"f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2"
]
],
"content": "š
Original date posted:2015-02-12\nš Original message:A similar idea was proposed by Sirer and me as a part of two-phase proof of\nwork (2P-PoW) [1]. In 2P-PoW the first phase is Bitcoin's standard PoW and\nthe second phase requires the signature. This way Bitcoin doesn't lose its\nmining power (read: security) in one day, but rather it is possible to\ngradually switch from the current PoW to the signature-based one, slowly\nphasing out the existing hardware and mining datacenters.\n\nFor a more general view of nonoutsourceable puzzles you can check out\nMiller et al.'s paper [2].\n\nIttay\n\n[1]\nhttp://hackingdistributed.com/2014/06/18/how-to-disincentivize-large-bitcoin-mining-pools/\n\n[2] https://cs.umd.edu/~amiller/nonoutsourceable.pdf\n\n------------------------------\n\u003e\n\u003e Message: 2\n\u003e Date: Wed, 11 Feb 2015 08:54:15 +0000\n\u003e From: Hector Chu \u003chectorchu at gmail.com\u003e\n\u003e Subject: [Bitcoin-development] Proposal: Requiring a miner's signature\n\u003e in the block header\n\u003e To: bitcoin-development at lists.sourceforge.net\n\u003e Message-ID:\n\u003e \u003c\n\u003e CAAO2FKEFxC_byt4xVJb0S-7yy0M7M-Av7MHUH-RBDuri_GAFtw at mail.gmail.com\u003e\n\u003e Content-Type: text/plain; charset=\"utf-8\"\n\u003e\n\u003e A proposal for stemming the tide of mining centralisation -- Requiring a\n\u003e miner's signature in the block header (the whole of which is hashed), and\n\u003e paying out coinbase to the miner's public key.\n\u003e\n\u003e Please comment on whether this idea is feasible, has been thought of\n\u003e before,\n\u003e etc., etc. Thank you.\n\u003e\n\u003e Motivation\n\u003e ----------\n\u003e\n\u003e Mining is centralising to a handful of pool operators. This is bad for a\n\u003e number of political reasons, which we won't go into right now. But I have\n\u003e always believed that some years down the line, they could hold the users\n\u003e hostage and change the rules to suit themselves. For instance by\n\u003e eliminating\n\u003e the halving of the block reward.\n\u003e\n\u003e Solution\n\u003e --------\n\u003e\n\u003e Currently the block header is formed by the pool operator and distributed\n\u003e for\n\u003e hashing by the pooled miners. It is possible to divide the work among the\n\u003e miners as the only thing that is used to search the hash space is by\n\u003e changing\n\u003e a nonce or two.\n\u003e\n\u003e I propose that we require each miner to sign the block header prior to\n\u003e hashing. The signature will be included in the data that is hashed.\n\u003e Further,\n\u003e the coinbase for the block must only pay out to the public key counterpart\n\u003e of\n\u003e the private key used to sign the block header.\n\u003e\n\u003e A valid block will therefore have a signature in the block header that is\n\u003e verified by the public key being paid by the coinbase transaction.\n\u003e\n\u003e Ramifications\n\u003e -------------\n\u003e\n\u003e Work can no longer be divided among the pooled miners as before, without\n\u003e sharing the pool's private key amongst all of them. If the pool does try to\n\u003e take this route, then any of the miners may redeem the coinbase when it\n\u003e matures. Therefore, all miners will use their own key pair.\n\u003e\n\u003e This will make it difficult to form a cooperating pool of miners who may\n\u003e not\n\u003e trust each other, as the block rewards will be controlled by disparate\n\u003e parties\n\u003e and not by the pool operator. Only a tight clique of trusted miners would\n\u003e be\n\u003e able to form their own private pool in such an environment.\n\u003e\n\u003e Attacks\n\u003e -------\n\u003e\n\u003e Pooled hashpower, instead of earning bitcoins legitimately may try to break\n\u003e the system instead. They may try a double-spending attack, but in order to\n\u003e leverage the pool to its full potential the pool operator would again have\n\u003e to\n\u003e share their private key with the whole pool. Due to the increased\n\u003e cooperation\n\u003e and coordination required for an attack, the probability of a 51% attack is\n\u003e much reduced.\n\u003e -------------- next part --------------\n\u003e An HTML attachment was scrubbed...\n\u003e\n\u003e ------------------------------\n\u003e\n\u003e Message: 3\n\u003e Date: Wed, 11 Feb 2015 10:25:27 +0100\n\u003e From: Natanael \u003cnatanael.l at gmail.com\u003e\n\u003e Subject: Re: [Bitcoin-development] Proposal: Requiring a miner's\n\u003e signature in the block header\n\u003e To: Hector Chu \u003chectorchu at gmail.com\u003e\n\u003e Cc: bitcoin-development at lists.sourceforge.net\n\u003e Message-ID:\n\u003e \u003cCAAt2M1_qj0r03=\n\u003e Ref9mN7bJLg-odep3m5teZ7JWDLC+zknQdQQ at mail.gmail.com\u003e\n\u003e Content-Type: text/plain; charset=\"utf-8\"\n\u003e\n\u003e Den 11 feb 2015 09:55 skrev \"Hector Chu\" \u003chectorchu at gmail.com\u003e:\n\u003e \u003e\n\u003e \u003e A proposal for stemming the tide of mining centralisation -- Requiring a\n\u003e \u003e miner's signature in the block header (the whole of which is hashed), and\n\u003e \u003e paying out coinbase to the miner's public key.\n\u003e \u003e\n\u003e \u003e Please comment on whether this idea is feasible, has been thought of\n\u003e before,\n\u003e \u003e etc., etc. Thank you.\n\u003e \u003e\n\u003e \u003e Motivation\n\u003e \u003e ----------\n\u003e \u003e\n\u003e \u003e Mining is centralising to a handful of pool operators. This is bad for a\n\u003e \u003e number of political reasons, which we won't go into right now. But I have\n\u003e \u003e always believed that some years down the line, they could hold the users\n\u003e \u003e hostage and change the rules to suit themselves. For instance by\n\u003e eliminating\n\u003e \u003e the halving of the block reward.\n\u003e\n\u003e [...]\n\u003e\n\u003e \u003e I propose that we require each miner to sign the block header prior to\n\u003e \u003e hashing. The signature will be included in the data that is hashed.\n\u003e Further,\n\u003e \u003e the coinbase for the block must only pay out to the public key\n\u003e counterpart of\n\u003e \u003e the private key used to sign the block header.\n\u003e\n\u003e [...]\n\u003e\n\u003e \u003e This will make it difficult to form a cooperating pool of miners who may\n\u003e not\n\u003e \u003e trust each other, as the block rewards will be controlled by disparate\n\u003e parties\n\u003e \u003e and not by the pool operator. Only a tight clique of trusted miners would\n\u003e be\n\u003e \u003e able to form their own private pool in such an environment.\n\u003e\n\u003e People already trust things like cloud mining, so your solution with\n\u003e increasing technical trust requirements won't help. But you will however\n\u003e break P2Pool instead.\n\u003e\n\u003e Also, note that threshold signatures (group signatures) could probably be\n\u003e used by an actual distrusting pool's miners. There are already a proof of\n\u003e concept for this implemented with secp256k1 that works with Bitcoin clients\n\u003e silently. This wouldn't prevent such a pool from working.\n\u003e -------------- next part --------------\n\u003e An HTML attachment was scrubbed...\n\u003e\n\u003e ------------------------------\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150212/518ed3b1/attachment.html\u003e",
"sig": "10e48a48eb3330bf09f13066eddc9d569e4aa124128406b0904dcfe9dd38117ec33c86e94301b3b1bf352f5f48726c6e7e91b01dd03106bddfe582675fb5361e"
}