New evidence of the non-existent connection between Satoshi and DPR:

http://bitslog.wordpress.com/2013/11/26/refutation-to-ronshamir-paper-on-dprsatoshi-link/

Two of the oldest blocks rewards (used by the paper authors to relate DPR to Satoshi) that were collected by 12higDjoCCNXSA95xZMWUdPvXNmkAduhWv and that not part of the Satoshi mining pattern.





Best regards, Sergio.

(Also posted on reddit)
From the "paper":

"The Bitcoin community believes [9] that the vast majority of the early mining operations were carried out by Satoshi Nakamoto, and that during this early period he accumulated about one million bitcoins (..) by mining most of the first 20,000 blocks. "

[9] Lerner S. D.: The Well Deserved Fortune of Satoshi Nakamoto, Bitcoin creator, Vi-sionary and Genius, Bitslog, 17 april 2013, http://bitslog.wordpress.com/2013/04/17/the-well-deserved-fortune-of-satoshi-nakamoto/

This is totally misleading!

From my a post just a few days after that: http://bitslog.wordpress.com/2013/04/24/satoshi-s-fortune-a-more-accurate-figure/

"Another interesting fact is that the pattern starts just after the genesis block, in block 1. ...It seems that block 12 is the first mined by another user."

So two hours after the true Bitcoin genesis block was released, there were other people mining. And other early miners during 2009 accumulated more than 300K bitcoins.

Also the older generation txs received by that address (block heights 357 and 509) does not seem to be part of the Satoshi mining pattern (this I will re-check today)

So the conclusion of the paper is completely flawed.

Sergio D. Lerner.

If this "80 msec delay" is the delay of the block being accepted by 51% of the nodes, then it means that most miners are loosing money by accepting a fee lower than 0.00333 BTC/KByte, which is the case most of the time.

This is because each 80 msec costs 25*80/1000/60/10 = 0.00333 BTC
Most of the current blocks have lower fees per Kbyte.

In turns this means that, if miners start acting rationally, a standard transaction cost should be at least USD 83 cents, with current exchange rate. Which in turns means if header-only-push is not implemented, the Bitcoin value cannot rationally be higher than 270 USD/BTC, since a 1 USD fee seems too much for most of the common payments.


Is this correct?

And I don't think SHA-256 was broken.

The simpler explanation is that Satoshi did have a good state-of-the-art computer. Justified by the occam's razor principle.
 

My current thought on the matter :

32 zerobits / 10 min , 4.2 Ghash/block
● Satoshi CPUs: 7.1 mhash/s (aprox)

State of the art 2009

● Intel i7-920 CPU: 6 mhash/s
(@ 4 cores) (Introduced Nov 2008)


My opinion is that Satoshi was doing multitasking on 5 threads, but since version 0.1 did not allow internal multitasking, and he didn't wanted to run 6 copies of the client (and store 6 copies of the blockchain) he created a special version of the Satoshi client which sent to 5 other "client" threads some hashing work to be done. But these threads were dumb, and only did the hashing part (no pubkey management, no extra-nonce incrementing). So Satoshi had to split the nonce space in order to avoid wasting work. He chose a range of 10 lsbs per thread because that represents a time (100 msec) that does not generate much IPC traffic and can wait for the remaining threads to finish without killing them if the one thread finds the solution for the block.

Best regards!

I have no time to read carefully the paper but..

Some time ago I posted in http://bitslog.wordpress.com/2013/06/26/the-bitcoin-eternal-choice-for-the-dark-side-attack-ecdsa/ a solution to another attack that may also work to protect from this attack:


This protocol protects from the appearance of simultaneously competing blocks but also from other attacks that may based on hidden branches. So I'll refer the method as "hidden-branch-protection".

Does it help?

Possible vector of attack:
If Carol does not give Alice a newly generated public key C each time the protocol is run, then Alice can provide Carol a fake TX_0 TXID (for example, a TXID of another transaction that Alice wants to steal from Carol).
Same happens if Bob does not give Carol a newly generated address each time, then Carol can attack Bob.

Also when the protocol reads {A,C} and {C,B} , these C's should be different, so it would be better to call the second key C'.

To avoid another (minor) problem on how to establish secure and authenticated connections between 3 participants it would be preferable that step D is changed so instead that Bob sends HX to Alice, is Carol who sends XH to Alice (received in the previous step). This removes the need that Alice connects to Bob.

I love the diagram. This must go right to the wiki.

I was thinking that the same can be accomplished by the protocol socrates1024 describes for p2p trading here https://bitcointalk.org/index.php?topic=193281.msg3315031#msg3315031.

The idea is that a p2p trade takes place, but for the same cryptocoins instead of two different cryptocoins.
Also only the traders know if they have exchanged coins or they have simulated a coin exchange.

Before they start the protocol they first choose randomly if they will simulate or not.
If it is a simulation, then pubkeyB is replaced by pubkeyA' in TX1 and pubkeyA is replaced by pubkeyB' in TX3.

In both cases it requires 4 transactions (2 bail ins and 2 trigger transactions).

How these two protocols compare ?

The socrates1024 is very easy to analyze.

Interesting protocol, I will analyze more carefully. I suppose the retep version is the one being discussed.

bytemaster: Your idea of using hash collisions is good, but is not new!

I proposed it on my paper MAVEPAY, April 16, 2012  (and even then I thought I wasn't  something new).

Here is the part of the paper where the Colission POW (as I called it) is proposed, available in http://bitslog.files.wordpress.com/2012/04/mavepay1.pdf

The Collision POW:
The collision POW is based on the difficulty of finding partial preimage collisions of two messages. The packet broadcast has the following properties:
•packet=< command, nonce1, nonce2, bn >
•tmp=Hash(command||bn).
•pow1=Hash(tmp||nonce1).
•pow2=Hash(tmp||nonce2).
•pow1 and pow2 must be prefixed by some predefined number of zero bits and share some number of following bits (the remaining bits can differ).
The related attack is the partial collision attack.

Birthday attacks require large amounts of memory and so preclude the use of GPUs and other massively parallel computer architectures. An attacker is therefore less capable of using these technologies to mount a command flooding attack.

Could you please add a reference in your paper to the Collision Pow of MAVEPAY ?

Best regards, Sergio.

Could you provide a link to the exact post where you elaborate the idea of Proof-of-Harddrive ?

side-topic: Also a node could prioritize nodes which store the full block-chain. This can be done with a variety of protocols known as  Proof of Storage and Proof of Retreivability.

Gmaxwell: Your idea is excellent, but needs some changes to prevent an obvious query forwarding attack.

Suppose client C wants to prove the server S that he keeps the data. When client C connects to server S, it also connects to some client D, acting as a server. Then server S sends the seed to client C, client C forwards the same seed to client D. Also each query is forwarded.
S cannot detect C is cheating, because he is in fact checking D storage. Then the seed must be chosen by a fair coin-flip or similar protocol.

New proposed Setup Protocol

C chooses a seed c and sends it to S.
S chooses a seed s and sends it to C.
Both agree that seed = H (c | s)

Also it's important to note that C may not store all the tree, but only a precomputed top. To effectively detect if C is in fact storing almost all the tree or not, S would need to make many time measurements of C responses, averaging the elapsed time.

This socrates1024 protocol seems to be much better than some others I saw. I can't find any drawback.

In the thread https://bitcointalk.org/index.php?topic=307211.0 I propose a method to protect users money from attackers by creating 2-step transactions, so users can roll-back if an attacker attempts to do step 1. The first step can be reverted using cold storage keys. I called it the "Tick method".

I realized that the same method could be implemented much more easily if transactions could specify a time/block number after they are unable to be accepted in the block chain.

Currently nLockTime has a threshold:

int LOCKTIME_THRESHOLD = 500000000; // Tue Nov  5 00:53:20 1985 UTC

Values lower than LOCKTIME_THRESHOLD are considered block numbers and values higher than LOCKTIME_THRESHOLD they are considered unix timestamps.
Since Bitcoin didn't existed from 1985 to 2009, I propose a soft-fork where nLockTime in ranges:

nLockTime in (LOCKTIME_THRESHOLD to 510000000): Valid before block (nLockTime- LOCKTIME_THRESHOLD+262634) (190 years avail, upto 2203)
nLockTime in (510000000 to 1230000000): Valid before time (nLockTime-510000000+1230000000): 22.8 years avail (up to 2036)

Code change should look something like: (note: I'm not taking into account txin.IsFinal(), this is just an example)

  
There may be many more use case (Mike Hearn?)

Best regards,
 Sergio.

I posted more thoughts about the btcusr idea (which I named BitBanknotes, so it can be referred) in my blog:

http://bitslog.wordpress.com/2013/10/09/a-disturbing-idea-bitbanknotes/

The probability to hash above n is 1/2^128, so it should be considered practically impossible to achieve.

Informal Proof: As you see, any payment that goes out from Txo MUST go through any TxIn, and then it MUST go thought the corresponding TxOut transaction, which are separated exactly delta time. Since the private keys of Txo(i) are not stored in the hot wallet, there is no other way to redeem the funds.

Also note that by burning the ticks periodically, you prevent both TxIn and TxOut for being published simultaneously.

Note that you MUST also monitor the block-chain for the tick burning transactions, if a tick is missing for too long, then you MUST also follow the theft procedure.

The "Tick" method

Let's say you have X BTC divided in N transaction outputs Txo(i)=(TxHash(i),outN(i)) for 0<=i<N  (for simplicity suppose each output has exactly X/N BTC)
To simplify the explanation, let K(output) be the input (hash + outN + signature ) to redeem the output.

Preparation stage

Once a month, you use a secure computer, load cold storage keys and:

1. you create a sequence of transactions TxTick(0)...TxTick(M-1) called "ticks".

Each Tick transaction pays almost the same amount to the following (minus the fees). So TxTick(j).input[0] redeems the funds stored in the output of TxTick(j-1).output[0]. Each ticks uses a different destination address. Also each tick transaction has a nLockTime set at equally spaced deadlines (separation of delta time). (e.g. once a day, or once an hour). The ticks must cover the time for the full month.

2. For each Txo(i) and each TxTick(j) you create two transactions TxIn(i,j) and TxOut(i,j).

TxIn(i,j) has two inputs and one two outputs:
- TxIn(i,j).input[0] = K(Txo(i))
- TxIn(i,j).input[1] = K(TxTick(j).output[0])
- TxIn(i,j).output[0] = new unique address

TxOut(i,j) has two inputs and one output:

- TxOut(i,j).input[0] = K(TxIn(i,j).output[0])                (signature has SIGHASH_NONE flag)
- TxOut(i,j).input[1] = K(TxTick(j+delta).output[0])     (signature has SIGHASH_NONE flag, here delta is the time interval to lock funds)
- TxOut(i,j).output[0] = empty (to be filled at payment time)


All TxIn and TxOut and TxTick transactions go to the hot wallet. All private keys generated during the process go to cold storage (or at least are encrypted and the encryption-key is cold stored)

Normal use

Each tick-interval, you broadcast the corresponding TxTick to be included in the blockchain, so previous tick outputs cannot be reused.

Suppose you want to pay X/K (exactly one Txo, say Txo(i)) to the address DstAddr.

1. Choose TxIn(i,j) and TxOut(i,j), where j is the next tick which has not been spent.
2. Fill the field TxOut(i,j).input[0] with DstAddr.
3. Broadcast TxIn(i,j).
3. Wait one delta interval
4. Broadcast TxOut(i,j), and the payment is done.


Theft

In case that the hot wallet is compromised by an attacker, and the attacker is willing to spend your funds he will be forced to broadcast a TxIn() transaction.

If you're monitoring the block-chain, then you will have a delta interval to open your cold storage keys and immediately re-send all funds stored in unspent Txo AND in the TxIn's recently broadcasted to a newly generated addresses.

Best regards, I hope this helps (as long as I know, it has never been proposed before)

If you wish to send me the bounty, my address is: 17mcFB7Xyymd9hxp2bgNPz1ruWsdoPoCnZ