The workaround in that case is to provide a signed hash instead of just a hash. In this case, the extension to the protocol is simple: have the creator distribute his art along with a signature made by the same key that owns the initial receiving address.

Andrew Miller <amiller@???> wrote:

>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
>_______________________________________________
>unSYSTEM mailing list: http://unsystem.net
>https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/unsystem