It's often insufficient to store just the *hash* of the data to
timestamp it in the blockchain, at least for many potential
applications of timestamping. The problem is that you can't at any
time definitively declare that you know the *earliest* timestamped
instance of the data. The reason is that it is possible for someone to
have timestamped it earlier and just hasn't revealed it yet. If what
you really want is timestamped *publication*, then it's necessary to
put the actual *data* in the chain.

I'll make this clearer with a concrete example. The example is a
digital art contest, where the prize for best jpeg committed before
the deadline (judged by a predesignated semi-trusted panel) is some
Bitcoins. The protcol has two phases, "commit" and "publish". The
first phase is from the start of the contest until the commitment
deadline - since no one wants to reveal their artwork where someone
could race a copy in with an earlier timestamp, they only reveal
hashes/commitments of the data. The sx embed-addr command would work
fine for this phase. In the second phase, from the commitment deadline
until the reward is finally disbursed, you need to publish the data
where the judges can see it. Suppose we use bitcointalk forums for
this phase - also suppose bitcointalk is untrusted and can
censor/delay posts. Then the attack is simply to prevent the real
winner from publishing his jpg on the forum until the contest is
judged and the prize is already sent out to a stooge and it's too
late.

This attack is prevented if in the second phase, everyone reveals
their art directly in the blockchain, rather than in an untrusted
delayable forum. The general way to derive an example like this is to
replace the vague condition like "you are assumed the creator unless
anyone can reveal an earlier one" with an irrevocable action like
sending some actual bitcoins to the creator.

I understand that storing actual data in the blockchain is a "no-no"
because it fills up the utxo indexes. The sx embed-addr command could
probably be modified to support this anyway. The main point of this
note is to dispel the common myth that "just the hash" suffices for
every timestamping application. Sometimes the actual data is necessary
too.

</longrant>


On Sun, Sep 8, 2013 at 11:36 AM, Amir Taaki <genjix@???> wrote:
> > (also in reply to Caleb James Delisle)
>
> Yeah well you create a beautiful sculpture or CG artwork, and you want
> to create some digital artifact to prove it was you (beyond reasonable
> doubt).
>
> You take your photo, file or whatever, put it into the tool and then
> send some BTC to embed the address in the blockchain.
>
> Anyone with access to the same file can generate the same address and
> lookup the timestamp on blockchain.info
>
> Unless anyone can provide an earlier timestampped photo of your
> sculpture, you are assumed to be the creator.
>
> The really interesting part is when with coloured coins, this asset
> (or parts of the asset) are transferrable to other people.
>
> On 08/09/13 16:40, Robert Williamson wrote:
>> Sure I'm up for the mailing list. I might not be able to contribute
>> that much regularly.
>>
>> Your embed command is cool. Its better than the current .jar file
>> I've seen to generate the addresses. Its just that embedding data
>> can be a bit more expensive now that the dust limit is in effect.
>> And the funds are then essentially lost as in this recent
>> transaction.
>>
>> https://blockexplorer.com/tx/77822fd6663c665104119cb7635352756dfc50da76a92d417ec1a12c518fad69
>>
>> I had the thought a while ago that maybe using something similar
>> to this transaction puzzle would be better, as it would at least
>> allow for the outputs to be spent.
>>
>> https://en.bitcoin.it/wiki/Script#Transaction_puzzle
>>
>> But I'm not sure if it is seen as standard and if it would be
>> relayed by the reference client. There are race attack issues with
>> it though. And peer can rebroadcast the redeeming tx and send the
>> funds somewhere else if it isn't confirmed.
>>
>> On 8 Sep 2013 15:19, "Amir Taaki" <genjix@???
>> <mailto:genjix@riseup.net>> wrote:
>>
>> Sounds great. I'll take a look now.
>>
>> Do you want to be on a mailing list with a whole bunch of us?
>>
>> Just added a command to sx to generate embed addresses so you can
>> embed records of data into the blockchain. That way you can put
>> some data in, and be the first to make a timestampped record of it
>> in the blockchain.
>>
>> cat my_sculpture.jpg | sx embed-addr
>> 1N9v8AKBqst9MNceV3gLmFKsgkKv1bZcBU
>>
>> then send btc to the address. the record will now be on the
>> blockchain.
>>
>>> Looks good, Interface is good.
>>>
>>>
>>> I'll have some free time on the train later, but right now it
>> looks like
>>> std::promise and std::future aren't working correctly inside the
>>> while loop.
>>>
>>> I've uploaded a 5MB bootstrap to
>>> /home/bob/bootstrap/bootstrap.height17333.dat if you wanted to
>> test, I'm
>>> not sure there are any orphans up to that height, or if there are
>>> any orphans at all saved into any of the bootstraps, but I might
>>> be
>> able to
>>> figure it out.
>>>
>>> I have some other commits to work through too, mainly I've
>> reworked the
>>> determ.cpp example to be more like priv.cpp so you can generate
>>> a
>> seed or
>>> addresses or master public key.
>>>
>>>
>>>
>>>
>>>
>>> On 8 September 2013 06:45, Amir Taaki <genjix@???
>> <mailto:genjix@riseup.net>> wrote:
>>>
>>>> http://i.imgur.com/bnMJ04N.png
>>>>
>>>> this is some really crappy prototype experimental code (proof
>>>> of concept), but i wanted it working before the 20th.
>>>>
>>>> https://github.com/spesmilo/sx/blob/master/src/wallet.cpp
>>>>
>>>> I've just got to get the send command working now.
>>>>
>>>> i'll design a proper one later. for now this is just a quick
>>>> hack.
>>>>
>>>>> Thanks, I'm downloading an old one to
>>>> /home/bob/bootstrap/bootstrap.dat
>>>>> its 4.5GB but i cant really remember what height it is to,
>>>>> it's
>> currently
>>>> got
>>>>> an ETA of 3hours.
>>>>>
>>>>> You can grab a copy of it from here if you want
>>>>> https://s3.amazonaws.com/robertwilliamson/bootstrap.dat aws
>> might be
>>>> the
>>>>> reason for it being slow though. S3 can sometimes have pretty
>>>>> heavy performance issues.
>>>>>
>>>>> Checksums are
>>>>>
>>>>> Adler32: FA0EEF4C CRC32: DDF59E6B MD5:
>>>>> 1B437D44213B7D98C974546B55834D10 SHA-1:
>>>>> 985380032B618281EC5B9B49AFDCC99A4BCD69EB SHA-256:
>>>> BF658C7055B733BFC15EA167F298C5599B89D220B14DBE7C8EF20B18E468C451
>>
>>>>
>>>>
>>>>> I'll download the newest one eventually. I can also trim one
>> out and
>>>> just
>>>>> have the first 1,000 or so blocks ~260 KB for testing.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 7 September 2013 19:49, Amir Taaki <genjix@???
>> <mailto:genjix@riseup.net>> wrote:
>>>>>
>> Yes, treat it like it's ours.
>>
>> If you go to Berlin, then definitely introduce yourself to
>>> Joerg and
>> say hi from me.
>>
>> I'll have a look. Well, first I need a bootstrap.dat so tell
>>> me once
>> it's downloaded to your server.
>>
>> On 07/09/13 17:47, Robert Williamson wrote:
>>> Thanks, I've logged on, am I ok to download a bootstrap.dat onto
>>> it, it will be ~ 10GB?
>>
>>> Sorry, I'm pretty tied up at the moment and I don't have any
>>> spare holiday time I can take from work until the new year. But
>>> I'd like to meet up and attend something then.
>>
>>> I'm staying in Kreuzberg in Berlin for a long weekend in
>>> November apparently Bitcoin is becoming big over there, but
>>> that's all the holiday time I can get. I'd be good to see how
>>> they accept payments, for the most part it looks like many shops
>>> just have android wallet, which leaves them liable if the phone
>>> is lost/stolen/damaged, seems they'd be a good target audience
>>> for using master public keys and a deterministic point of sale
>>> device to limit the amount of Bitcoins that could be lost.
>>
>>> Turns out the implementation I was writing to send the blocks to
>>> a node was a bit over the top and I'm not sure if the protocol
>>> would allow it without making it much more complicated.
>>
>>> I've so far come up with this, but I keep ending up with a
>>> segmentation fault. The actual reading of the file works fine
>>> all the way to the full height, I can get the block_type blk and
>>> hash the header which match those on blockexplorer.
>>
>>> Any chance you could have a look? handle_store is the same as
>>> the one from poller.cpp, except I've had to comment out
>>> fetch_block_locator
>>> https://gist.github.com/Bobalot/93617a8f2d5ac8a5cf12
>>
>>> Perhaps it would be better to create a poller object and then
>>> feed the blocks into it rather than directly using chain.store.
>>
>>> Thanks again,
>>
>>> Bob
>>
>>
>>
>>
>>
>>
>>> On 6 September 2013 18:46, Amir Taaki <genjix@???
>>> <mailto:genjix@riseup.net> <mailto:genjix@riseup.net
>>> <mailto:genjix@riseup.net>>> wrote:
>>
>>> done. password is hello11
>>
>>> ssh bob@46.4.92.107 <mailto:bob@46.4.92.107>
>>> <mailto:bob@46.4.92.107 <mailto:bob@46.4.92.107>>
>>
>>> see what I added to the end of your .bashrc, you have
>>> libbitcoin/obelisk/sx installed (it's in your ~/usr). you can do
>>> this using the --prefix configure switch (see the history).
>>
>>> this way different users can all develop alongside each other on
>>> the same system. i'm happy to give you root if you ever need it.
>>
>>> btw do you think you'd be able to make this event?
>>
>>> https://wiki.unsystem.net/index.php/Calafou/Electrum_Meeting
>>
>>>> bob will do. On 6 Sep 2013 17:05, "Amir Taaki"
>>>> <genjix@??? <mailto:genjix@riseup.net>
>>> <mailto:genjix@riseup.net <mailto:genjix@riseup.net>>> wrote:
>>>>
>>> That's the end goal, but first we need the tools for that.
>>
>>> On 06/09/13 16:14, Robert Williamson wrote:
>>>> I see you meant creating a wallet lib, I was thinking you
>>>> meant something more like the full electrum frontend. I look
>>>> forward to seeing it.
>>>>>
>>>>
>>
>>
>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
> > _______________________________________________
> unSYSTEM mailing list: http://unsystem.net
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/unsystem



--
Andrew Miller