Re: [Bitcoin-development] merged mining hashcash bitcoin (Re: Coinbase TxOut Hashcash)
On Tue, May 14, 2013 at 5:25 AM, Adam Back a...@cypherspace.org wrote: On Mon, May 13, 2013 at 06:00:27PM -0400, Jeff Garzik wrote: When a transaction's input value exceeds its output value, the remainder is the transaction fee. The miner's reward for processing transactions is the 25 BTC initial currency distribution + the sum of all per-transaction fees. A destroy-by-miner fee transaction is a normal bitcoin transaction sent by any user, that might look like Input 1: 1.0 BTC Output 1: 0.5 BTC (the miner fee is implicitly 0.5 BTC, paid to whomever mines the transaction into a block) Sadly the bitcoin protocol prevents zero-output, give-it-all-to-the-miner transactions. Well if it is a later transaction, not an integral part of the reward transaction (that is definitionally mined by being serialized into the coinbase), the user may elect to withhold the promised transaction give-to-miner, so thats not so good. That evaluation largely depends on the needs of the service in question. In my decentralized identity (SIN) example, you merely need to prove to the cloud that you sacrificed some bitcoins to any-miner. The confirmed, in-chain, non-coinbase transaction becomes the root node for off-chain identity data. The penalty for the user withholding the sacrifice transaction is that their SIN is not created. That incentive may not exist in that way, in another service. Or do you mean to say you could have (implicit reward 25BTC) and reward transaction .001 BTC to self and 24.999 BTC with existing bitcoin format and validation semantics? That would be close enough to give-to-miner. Also the output sum 0BTC limitation could be changed to = maybe... (just one well placed character :) Just referring to a standard, fee-bearing, user-created bitcoin transaction, where output_value input_value. The fee is paid to the first miner who includes that transaction in a block, as part of the protocol. -- 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
Re: [Bitcoin-development] merged mining hashcash bitcoin (Re: Coinbase TxOut Hashcash)
On Tue, May 14, 2013 at 12:50:27PM -0400, Jeff Garzik wrote: Well if it is a later transaction, not an integral part of the reward transaction (that is definitionally mined by being serialized into the coinbase), the user may elect to withhold the promised transaction give-to-miner, so thats not so good. [...] [...] Just referring to a standard, fee-bearing, user-created bitcoin transaction, where output_value input_value. The fee is paid to the first miner who includes that transaction in a block, as part of the protocol. Yes but thats inferior in the sense that it is spamming the bitcoin payment protocol slightly, to the small reward of miners, and involves actual money and traceability to real-name (where did you get the coin from to spend). If alternatively you just proof you direct mined on a block with a coinbase that immediately makes payment to future miners its better because: a) you can do that with no new traffic for the bitcoin network (except when you mine a whole block, you'll post it); and b) anyone with a reasonable verification on the blockchain head (even if the spender has to give it to them!) can verify it without any other network traffic; and c) if its micro-mined on the spot it can be bound to the service whereas if you give it to fees as an on network transaction you are limited to values above the min tx fee. So idealy I think you need to be able to simultanously mine and give reward to future block miners. What you could do with out that is d) mine for the reward of bitcoin foundation/software author/or service provider. In the last case (service provider) its an extreme form of Rivests peppercoin probabilistic payment Adam -- 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
Re: [Bitcoin-development] merged mining hashcash bitcoin (Re: Coinbase TxOut Hashcash)
On Mon, May 13, 2013 at 07:31:21AM +, 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?) Surely in 3 if you mine the bitcoin its no particular assurance a you will do your best to make sure that it is *you* tht spends it, so it devolves to merged-mine. (Eg delay revealing it for 10 seconds while you broadcast your spend widely) Peter talks about value, but the proof only proves cost equal to bitcoin. Those are not the same thing. And they are so-far non-respendable. I still dont understand what he was saying. If you do please speakup. I think potentially a publicly auditable pooled mining protocol would be a place to start thinking about respendble micropayments. I made a post on the bitcointalk forum outlining how that could be done: https://bitcointalk.org/index.php?topic=1976.msg2035637#msg2035637 if you have a publicly auditable pool, where users can prove to each other outside of the bitcoin transaction log that they contributed a number of shares to a block, those could be traded somehow. Possibly eg with the pool keeping a double-spend db. If the payments are low value, people maybe happy trusting a pool. If the pool cheats, everyone stops using the pool. You rely on the pool not to spend the backing bitcoin blocks. But it remains possible for the pool to cashout people who collected enough shares. Probably you could do that with blinding if desired. [probabilistic micro-payments] I think you are misremembering [...] It is not a probabalistic scheme. You are right I was thinking of Rivest's peppercoin. In this way one can merge mine bitcoin hashcash to the benefit of the recipient (or some beneficiary trusted not to be paying the proceeds to the spammer). And in a way that scales to email scale, and does not involve installing a bitcoin client in every client, nor mail server. Blockchain header data may very well be one of the most widely distributed single data sets in the history of mankind, and most of its closest cousins are definitions such as the ASCII table or near definitions like the DNS root servers. Not something with new data every 10 minutes. Well there doesnt need to be a one-true-blockchain DNS, though the power to output a hash at any reasonable rate is a big proportion of the network power. And the outputs are instantly verifiable, so it forms a kind of trapdoor hashchain (where the trap door is not a secret but havng a huge amount of CPU power). And there can and should be many blockchain via DNS. For namesaces in general another approach other than DHT/flood is numerous competing hierarchical, heavily cached, but publicly auditable. Cheaters are shunned. Same effect, more scalable, most people are not cheating most of the time. http://cypherspace.org/p2p/auditable-namespace.html Adam -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] merged mining hashcash bitcoin (Re: Coinbase TxOut Hashcash)
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 +, 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
Re: [Bitcoin-development] merged mining hashcash bitcoin (Re: Coinbase TxOut Hashcash)
On Mon, May 13, 2013 at 5:12 PM, Adam Back a...@cypherspace.org wrote: 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? When a transaction's input value exceeds its output value, the remainder is the transaction fee. The miner's reward for processing transactions is the 25 BTC initial currency distribution + the sum of all per-transaction fees. A destroy-by-miner fee transaction is a normal bitcoin transaction sent by any user, that might look like Input 1: 1.0 BTC Output 1: 0.5 BTC (the miner fee is implicitly 0.5 BTC, paid to whomever mines the transaction into a block) Sadly the bitcoin protocol prevents zero-output, give-it-all-to-the-miner transactions. -- 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
Re: [Bitcoin-development] merged mining hashcash bitcoin (Re: Coinbase TxOut Hashcash)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 - 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. Sorry I don't have time for a full reply due to some other commitments, but you remind me of an idea bouncing around to use a Merkle Sum tree as a way to split one sacrifice among an arbitrarily large set of users. Credit goes to Gregory Maxwell (according to the wiki) and the idea is to have the roots of the tree be account numbers (pubkeys here) and account amounts. He proposed it for off-chain transaction account ledgers, but the idea works equally well here to split some initial sacrifice into lots of little bits. For instance a on-chain sacrifice to an anyone-can-pay output could be split into enough parts to make it useful even when tx fees become large. Incidentally all this stuff about rivest paywords is probably silly, why not just commit your sacrifice to a pubkey and make signatures saying what your new balance is for each message and how much you intended to spend? This allows for easy fraud proof creation, and gives you a choice of either lying to some nodes, and getting poor propagation, or being honest and spending the amount you should have. For DoS protection it seems to me that mostly trusting nodes to give accurate balances, enforced with a fraud proof system to halt double-spending, is perfectly adequate. But no sense implementing so much complexity right at the start of the effort! Just a thought for where things can go in the future. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBCAAGBQJRkaGUAAoJEEWCsU4mNhiPKsoH/1zhTBS/rINhF8oxxFoScD6i 0ybiUarIQEmmpAr3i46oMcSrw0SiOoiUzj6zvJorA21ddoErkTDVpMWI18RnKFos bTC4NVzvcegLdnbYb+76XKOCMc1dchFXq+WEGRdu/WKzOL7ODUUKAl/hG2Fk4lPU 3x8mHq0k2pqMAYX5/TX0w0pDnS227L+V1O3EoZD86MjR/CliHsZyBnXIqyqV4rY8 354JswKQ/XWb85gwZwFq1WXsFIZAep+eRVqmOluu3Ol97c5G85utNYDkg2hALURy gfpwmXKPFGm8h2lE1cMaOxkvQHOOPH8v7WdoBx08/ojhsyQNMpND4xej5FP/e5c= =vrFC -END PGP SIGNATURE- -- 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
