Transaction 1850fd2b4ca15e7bf2ebc8f57e4cddfc6a45405ecf8388efe1080b52a5c258a9

1 Input
  • bf1f3bb9ea5cd9967888aa03c8b03480a66761f13ced801d282f7160a11801b8:4
    OP_DATA_32(32) 32e94d247d9aca2ade2106c8cde5a73da6e5e827048dadd5e1af9cd490e232cf
    OP_CHECKSIG(172)
    OP_0(0)
    OP_IF(99)
    OP_DATA_3(3) ord
    OP_DATA_1(1) 
    OP_DATA_16(16) application/json
    OP_0(0)
    OP_PUSHDATA2(77) {"subject":"Bitcoin P2P e-cash paper","content":{"format":"email","body":"I'll try and hurry up and release the sourcecode as soon as possible to serve as a reference to help clear up all these implementation questions.\n\n\nRay Dillinger (Bear) wrote:\n\u003e When a coin is spent, the buyer and seller digitally sign a (blinded)\n\u003e transaction record.\n\nOnly the buyer signs, and there's no blinding. \n\n\n\u003e If someone double spends, then the transaction record \n\u003e can be unblinded revealing the iden
    OP_PUSHDATA2(77) tity of the cheater. \n\nIdentities are not used, and there's no reliance on recourse. It's all prevention.\n\n\n\u003e This is done via a fairly standard cut-and-choose \n\u003e algorithm where the buyer responds to several challenges\n\u003e with secret shares\n\nNo challenges or secret shares. A basic transaction is just what you see in the figure in section 2. A signature (of the buyer) satisfying the public key of the previous transaction, and a new public key (of the seller) that must be satisfied to spend
    OP_PUSHDATA2(77) it the next time.\n\n\n\u003e They may also receive chains as long as the one they're trying to\n\u003e extend while they work, in which the last few \"links\" are links\n\u003e that are *not* in common with the chain on which they're working.\n\u003e These they ignore. \n\nRight, if it's equal in length, ties are broken by keeping the earliest one received.\n\n\n\u003e If it contains a double spend, then they create a \"transaction\" \n\u003e which is a proof of double spending, add it to their pool A, \n\u003e b
    OP_PUSHDATA2(77) roadcast it, and continue work.\n\nThere's no need for reporting of \"proof of double spending\" like that. If the same chain contains both spends, then the block is invalid and rejected. \n\nSame if a block didn't have enough proof-of-work. That block is invalid and rejected. There's no need to circulate a report about it. Every node could see that and reject it before relaying it.\n\nIf there are two competing chains, each containing a different version of the same transaction, with one trying to give money
    OP_PUSHDATA2(77) to one person and the other trying to give the same money to someone else, resolving which of the spends is valid is what the whole proof-of-work chain is about.\n\nWe're not \"on the lookout\" for double spends to sound the alarm and catch the cheater. We merely adjudicate which one of the spends is valid. Receivers of transactions must wait a few blocks to make sure that resolution has had time to complete. Would be cheaters can try and simultaneously double-spend all they want, and all they accomplish is that
    OP_PUSHDATA2(77) within a few blocks, one of the spends becomes valid and the others become invalid. Any later double-spends are immediately rejected once there's already a spend in the main chain. \n\nEven if an earlier spend wasn't in the chain yet, if it was already in all the nodes' pools, then the second spend would be turned away by all those nodes that already have the first spend.\n\n\n\u003e If the new chain is accepted, then they give up on adding their\n\u003e current link, dump all the transactions from pool L back i
    OP_PUSHDATA2(77) nto pool\n\u003e A (along with transactions they've received or created since\n\u003e starting work), eliminate from pool A those transaction records\n\u003e which are already part of a link in the new chain, and start work\n\u003e again trying to extend the new chain.\n\nRight. They also refresh whenever a new transaction comes in, so L pretty much contains everything in A all the time.\n\n\n\u003e CPU-intensive digital signature algorithm to \n\u003e sign the chain including the new block L. \n\nIt's a Hashcash
    OP_PUSHDATA2(77) style SHA-256 proof-of-work (partial pre-image of zero), not a signature. \n\n\n\u003e Is there a mechanism to make sure that the \"chain\" does not consist\n\u003e solely of links added by just the 3 or 4 fastest nodes? 'Cause a\n\u003e broadcast transaction record could easily miss those 3 or 4 nodes\n\u003e and if it does, and those nodes continue to dominate the chain, the\n\u003e transaction might never get added.\n\nIf you're thinking of it as a CPU-intensive digital signing, then you may be thinking of a ra
    OP_PUSHDATA2(77) ce to finish a long operation first and the fastest always winning.\n\nThe proof-of-work is a Hashcash style SHA-256 collision finding. It's a memoryless process where you do millions of hashes a second, with a small chance of finding one each time. The 3 or 4 fastest nodes' dominance would only be proportional to their share of the total CPU power. Anyone's chance of finding a solution at any time is proportional to their CPU power.\n\nThere will be transaction fees, so nodes will have an incentive to receive a
    OP_PUSHDATA2(77) nd include all the transactions they can. Nodes will eventually be compensated by transaction fees alone when the total coins created hits the pre-determined ceiling.\n\n\n\u003e Also, the work requirement for adding a link to the chain should\n\u003e vary (again exponentially) with the number of links added to that\n\u003e chain in the previous week, causing the rate of coin generation\n\u003e (and therefore inflation) to be strictly controlled.\n\nRight.\n\n\n\u003e You need coin aggregation for this to scale. T
    OP_PUSHDATA2(77) here needs to be\n\u003e a \"provable\" transaction where someone retires ten single coins\n\u003e and creates a new coin with denomination ten, etc. \n\nEvery transaction is one of these. Section 9, Combining and Splitting Value. \n\n\nSatoshi Nakamoto\n\n\n\n---------------------------------------------------------------------\nThe Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com\n\n"},"source":{"name":"cryptography","url":"http://www.metzdowd.com/piper
    OP_PUSHDATA1(76) mail/cryptography/2008-November/014858.html"},"date":"2008-11-15T04:43:00Z"}
    OP_ENDIF(104)
1 Outputs
  • 1850fd2b4ca15e7bf2ebc8f57e4cddfc6a45405ecf8388efe1080b52a5c258a9:0
    • value  546
    address  bc1par0s4uucpjhvgesastmsdyvna642gjhcmf7ge4t8khh4ddvp3kyscrxmwp