Some musings about the differences between Peter's proof-of-sacrifice (you
did the work but elected to make the small reward chance unclaimable), vs
conventional actually doing the work but then destroying the bitcoin!
- proof-of-sacrifice seems similiar to hashcash except its difficulty is
time stamped and measured against the bitcoins dynamic difficulty,
(coordinated inflation control being something posited but never
implemented in hashcash). So thats kind of interesting, particularly if
you can do it with very low bandwidth, and decentralized; unclear.
- with proof-of-sacrifice its more offline because you do not need an on
block-chain double spend protection (via flood-fill, validation, and block
chain mining) because it is simply "unspendable", though you could show
the same proof to multiple people. In any case the values are far too low
to spam the block chain with.
- because proof-of-sacrifice is small you can afford to mine them on the
spot and make them payable to the identity of the recipient, like cheques:
they identify the recipient, so they are automaticaly non-respendable in
the eyes of the recipient (he keeps his own double-spend db, and people
wont accept cheques made payabe to other people). This is how hashcash
works for email. Also a time-stamp ensures you dont even need a big
double-spend db, as you can prune it if you reject expired cheqes.
- you could give a proof-of-sacrifice a private key, just like bitcoins;
then they could be pre-mined and identity or other info could be signed
later. However then you have double spending issues again. You can
- I mentioned amortizable hashcash under-contribution feature you can make
it so the recipient uncovers the actual value of the coin (if it is
merge-mined). (Put recipient public key in coinbase, hash for min share
size eg 32-bits leading 0s call that "collision"; send to recipient, he
decrypts the hash with private key, so the decryption is verifiable with
public key. Then the full value of the coin is
zerobit( collision ) + zerobits( decrypt( collision ) )
if that alternate validation was allowed in bitcoin.
- what about if a pool could lock the reward (rather than receive it or
destroy it) eg some kind of merkle root instead of a public key hash in
the reward recipient address field in the coinbase. Then the miners who
created that block have actual share proofs that are claims against
something eventually redeemable. Maybe if they collect enough
share-proofs to reach a minimum bitcoin transaction size, they can redeem
a big strip of shares for a few mBTC, but claims below that are rejected
by the network due to tx fee. (btw I think it seems possible to have a
publicly auditable pool so it cant skim nor disclaim shares.)
>I've been thinking about a decentralized way to create an anonymous
>identity, something I think it key to any number of decentralized, P2P
>and anonymous markets.
There were some systems that charged hashcash for pseudonyms i2p names (i2p
is a ToR like system)... see htp://www.i2p2.e/naming.html then there was of
course namecoin. There was some remailer/email nymserver integration as
well.
>Getting back on topic, somewhat, one idea I had for creation cost of a
>SIN was associating the creation cost of a SIN with a bitcoin
>transaction's miner fee. Anybody in the world could, therefore,
>create a SIN in a decentralized fashion, simply by following a
>published protocol for burning a specified amount of bitcoins via
>miner fee. It can be cryptographically proven with 100% certainty who
Yes it seems that having a proof-of-sacrifice that hardens the block chain
is the important part.
When you said destroy-via-miner-fee:
>Don't forget: 4. destroy-via-miner-fee, which is useful because it
>provides funding for a public service (bitcoin transaction
>verification).
Is that directly possible? Because the reward transaction has no source,
and no fee? Or can you put a 25BTC fee in the reward transaction in the
coinbase?
If so that seems like the best option for proof-of-sacrifice rather than
proving destroying the possibility of reward. But alternatively the bitcoin
foundation as recipient, or EFF etc. 25BTC is a big reward might have some
double roll-over lottery effects - everyone piles in for the occasional
25BTC!
Adam
On Mon, May 13, 2013 at 02:38:15PM -0400, Jeff Garzik wrote:
>On Mon, May 13, 2013 at 6:54 AM, Adam Back <a...@cypherspace.org> wrote:
>> On Mon, May 13, 2013 at 07:31:21AM +0000, John Dillon wrote:
>>>[with] merge-mining [you get] more value from just one unit of work.
>>
>> correct.
>>
>>>But Peter's coinbase hashcash protocol carefully ensures [...] the amount
>>>of value the miner would have then given away in a "anyone-can-spend"
>>>output.
>>
>> I think there are 3 choices:
>>
>> 1. merged-mine (almost zero incremental cost as the bitcoin mining return is
>> still earned)
>>
>> 2. destroy bitcoin (hash of public key is all 00s so no computible private
>> key)
>>
>> 3. anyone-can-spend (= first to spend gets coin?)
>
>Don't forget: 4. destroy-via-miner-fee, which is useful because it
>provides funding for a public service (bitcoin transaction
>verification).
>
>(a tangent, but related)
>
>I've been thinking about a decentralized way to create an anonymous
>identity, something I think it key to any number of decentralized, P2P
>and anonymous markets. My main focus, for this identity project, is
>to develop a decentralized protocol for generating a UUID-like unique
>identifier (bitstring), in a way that has some amount of creation cost
>attached (to prevent creating a billion of such tokens etc.). I call
>it a system identifier, or SIN.
>
>Once you have a SIN, you may associate the SIN with a GPG fingerprint,
>email address, real name, login credentials, etc. eBay-like
>marketplaces publish SIN ratings (though it displays on screen as
>"jgarzik" not "1234-abcd-5678-def0"). Standard-and-Poors style
>ratings agencies would similarly rate a business's SIN. SIN's build a
>reputation and trust over time, while controlling their own anonymity
>(or lack thereof). Anybody may abandon a SIN at any time. Ownership
>of a SIN is cryptographically proven via digital signature.
>
>Getting back on topic, somewhat, one idea I had for creation cost of a
>SIN was associating the creation cost of a SIN with a bitcoin
>transaction's miner fee. Anybody in the world could, therefore,
>create a SIN in a decentralized fashion, simply by following a
>published protocol for burning a specified amount of bitcoins via
>miner fee. It can be cryptographically proven with 100% certainty who
>made such a transaction, and the miner fee attaches a creation cost to
>ensure that SINs are not -too- cheap.
>
>Burn-via-miner-fee is a useful tool outside of this example. It funds
>a public service, providing a positive feedback loop for miners who
>receive fees via such services.
>
>--
>Jeff Garzik
>exMULTI, Inc.
>jgar...@exmulti.com
------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
