Decentralized Trustless Sentinels

The Counterparty Protocol’s Broadcast Message Type itself can support many practical applications, some of which are listed below.

[list]
[li]Warrant Canary - https://en.wikipedia.org/wiki/Warrant_canary[/li]
[li]Dead Man’s Switch - https://en.wikipedia.org/wiki/Dead_mans_switch[/li]
[li]Heartbeat - https://en.wikipedia.org/wiki/Heartbeat_%28computing%29[/li]
[li]Keepalive - https://en.wikipedia.org/wiki/Keepalive[/li]
[li]Watchdog Timer - https://en.wikipedia.org/wiki/Watchdog_timer[/li]
[/list]These applications are all essentially the same thing, which could be termed Trusted Sentinels. They rely on continual feeds of broadcasts. Warrant Canaries may be of particular interest to Bitcoin/Counterparty related businesses and users - http://www.reddit.com/r/Bitcoin/comments/1z5z4r/bitcoin_exchanges_should_publish_a_warrant_canary/. A user friendly implementation of a Warrant Canary within Counterwallet would attract a lot of attention and draw many new and existing cryptocurrency users. It would also highlight the Counterparty Protocol as an avenue to extract increased functionality from the Bitcoin network.

Placing bets on some of these types of broadcasts could be very interesting indeed.




Prometheus,
Cyberneticist

I also happen to think broadcast messages are exciting.

Wouldn’t it be possible to make a distributed marketplace with enhanced broadcasts?

All you’d need to do is treat the broadcast text as the ad title and link to a JSON file with links to images and detailed descriptions.

This is a very interesting idea. I like the idea of a Dead Man’s Switch being setup using broadcast signals.

[quote author=Giants link=topic=354.msg2421#msg2421 date=1400801678]
I also happen to think broadcast messages are exciting.

Wouldn’t it be possible to make a distributed marketplace with enhanced broadcasts?

All you’d need to do is treat the broadcast text as the ad title and link to a JSON file with links to images and detailed descriptions.
[/quote]


How would you compensate people for displaying those broadcasts on their sites?

[quote author=Aaron_BitSpot link=topic=354.msg2438#msg2438 date=1400994295]
This is a very interesting idea. I like the idea of a Dead Man’s Switch being setup using broadcast signals.
[/quote]

Certainly the Dead Man’s Switch functionality is an exciting prospect. To elaborate on it a bit: A good use case would be when someone is taking part in some dangerous activity (climbing a mountain, for example), one could imagine the user (climber) frequently pressing a button (on a smartwatch, for example) which sends the Dead Man’s Switch broadcast (embedded in the Bitcoin Blockchain for all the world to see) to confirm that the user is not currently incapacitated. In the event that the broadcast doesn’t get sent for a pre negotiated time, the user is assumed to be incapacitated and some action can be taken (sending out a search and rescue team, for example). *Coordinate/GPS data could be attached to the Dead Man’s Switch broadcasts in this example.

In the event of the user needing to abandon the Dead Man’s Switch, the broadcast feed can be locked. It can then be assumed that the user chose to lock it and forgo any of it’s benefits/security.

You could imagine the mountain climber in the above example betting that he will survive his expedition (that his Dead Man’s Switch won’t timeout). His loved ones could take the other side of the bet as a type of health/life assurance.

Would it be possible to bet on the time between successive broadcasts natively in the Counterparty Protocol?

[quote]How would you compensate people for displaying those broadcasts on their sites? [/quote]

Blockscan.com doesn’t get compensated for displaying public data. blockchain.info isn’t directly compensated for providing their public data.

Having a distributed marketplace alone would be interesting enough for people to develop a Web interface for. Could even do it in Counterwallet. Just fork the code if need be and there’s your real distributed marketplace.

I know that blockshan.com doesn’t get directly compensated for that, my question was more around "Who does?"


When you mention a marketplace, I assume there’s something being exchanged in exchange for something else.
Who would be the buyers, sellers and what would be exchanged in return for what?

[quote author=something link=topic=354.msg2456#msg2456 date=1401086098]
I know that blockshan.com doesn’t get directly compensated for that, my question was more around "Who does?"

When you mention a marketplace, I assume there’s something being exchanged in exchange for something else.
Who would be the buyers, sellers and what would be exchanged in return for what?
[/quote]

What do you think people would list for sale on a censorship resistant distributed marketplace?

There isn’t a business model behind OpenBazaar. What there is, is demand for a censorship resistant marketplace that can’t be shut down.

Let me spell it out for you: you can run Silk Road on top of Counterparty, inside Counterwallet.

[quote author=Equality 7-2521 link=topic=354.msg2449#msg2449 date=1401053737]
[quote author=Aaron_BitSpot link=topic=354.msg2438#msg2438 date=1400994295]
This is a very interesting idea. I like the idea of a Dead Man’s Switch being setup using broadcast signals.
[/quote]

Certainly the Dead Man’s Switch functionality is an exciting prospect. To elaborate on it a bit: A good use case would be when someone is taking part in some dangerous activity (climbing a mountain, for example), one could imagine the user (climber) frequently pressing a button (on a smartwatch, for example) which sends the Dead Man’s Switch broadcast (embedded in the Bitcoin Blockchain for all the world to see) to confirm that the user is not currently incapacitated. In the event that the broadcast doesn’t get sent for a pre negotiated time, the user is assumed to be incapacitated and some action can be taken (sending out a search and rescue team, for example). *Coordinate/GPS data could be attached to the Dead Man’s Switch broadcasts in this example.

In the event of the user needing to abandon the Dead Man’s Switch, the broadcast feed can be locked. It can then be assumed that the user chose to lock it and forgo any of it’s benefits/security.

You could imagine the mountain climber in the above example betting that he will survive his expedition (that his Dead Man’s Switch won’t timeout). His loved ones could take the other side of the bet as a type of health/life assurance.

Would it be possible to bet on the time between successive broadcasts natively in the Counterparty Protocol?
[/quote]

Yes, this idea (and that of Trusted Sentinels, generally) is excellent. Who wants to build a Dead Man’s Snitch application (to start with) on top of Counterparty?

There isn’t currently a way of betting on the time between broadcasts, and I’m not sure that there should be. As it is, the feed operator could just broadcast a value equal to the number of seconds since the last broadcast, and then users could bet on that.

It looks like Truecrypt could have benefited from using a Warrant Canary and/or a Dead Man’s Switch within Counterparty!

http://www.reddit.com/r/netsec/comments/26pz9b/truecrypt_development_has_ended_052814/

Another potentially interesting application of the Counterparty Broadcast functionality would be to relinquish control of a Bitcoin Public Key by publishing it’s Private Key in a broadcast. The Private Key subsequently becomes common knowledge and would destroy the relationship of any pseudonymous identity associated with the corresponding Public Key.

How much data can be attached to a Broadcast? Is there even room for a Private Key?

[quote author=Equality 7-2521 link=topic=354.msg2575#msg2575 date=1402232141]
How much data can be attached to a Broadcast? Is there even room for a Private Key?
[/quote]

The maximum size of the text within a Counterparty broadcast is 52 bytes https://github.com/CounterpartyXCP/counterpartyd/blob/master/lib/broadcast.py.

The size of a Bitcoin private key is 256 bits (32 bytes) so what you are proposing could work https://en.bitcoin.it/wiki/Private_key

[quote author=Global_trade_repo link=topic=354.msg2593#msg2593 date=1402373163]
[quote author=Equality 7-2521 link=topic=354.msg2575#msg2575 date=1402232141]
How much data can be attached to a Broadcast? Is there even room for a Private Key?
[/quote]

The maximum size of the text within a Counterparty broadcast is 52 bytes https://github.com/CounterpartyXCP/counterpartyd/blob/master/lib/broadcast.py.

The size of a Bitcoin private key is 256 bits (32 bytes) so what you are proposing could work https://en.bitcoin.it/wiki/Private_key
[/quote]

Thank you for the response. When you couple the ability to relinquish control over a private key and the ability to use Warrant Canaries and Dead Man’s Switches within Counterparty you allow for certain projects (like Truecrypt) to shut up shop more gracefully (if that is indeed what happened in that case).

We are about to go slightly off topic now but this is a potentially interesting use of the Counterparty Protocol broadcast function which could still be considered a sentinel when used in a particular manner.

An employer may demand an employee or contractor to provide regular chained updates (broadcasts) of work completed. This is particularly important for work that must be signed off on and completed at particular times (and not simply back dated or batch completed the night before a report on said work is due for example). A classic example is of a Laboratory Workbook. We have just discovered a similar idea is already implemented - http://proofofscience.appspot.com/. This idea has important implications for broadcasting ideas such that they enter the public domain.

The Counterparty Protocol and the Bitcoin Blockchain would be ideal for Defensive Publication - https://en.wikipedia.org/wiki/Defensive_publication.

I think it would be interesting to explore the potential of having conensus based betting, where several broadcasts have to agree in order for the bets to be filled.

What do you mean by “filled”? 

Created or decided?

He means decided. I.e. the bets would be matched or resolved.

OK. 

They’re matched by the protocol when a counterparty is found, but resolved by the feed owner.

When several broadcasts have to agree = > means a hybrid feed that’s decided based on inputs from 2-of-3 feeds.
When feed owners have to agree = > a normal feed that’s decided if the majority votes one way.

The first kind - should be done with Smart Contracts
The second kind - multisig?  (I’m not sure if it’s possible to use multisig for that - if not, Smart Contracts).

I haven’t thought how the first type might be used. It would certainly increase the risk of a failure if any of the input feeds doesn’t get decided or gets incorrectly decided. 
It might be easier to create a single feed that provides different outcomes or use Smart Contracts to lower the fees and risks. But probably there’s some useful scenario I haven’t thought of.



The maximum size of the text within a Counterparty broadcast is 52 bytes https://github.com/CounterpartyXCP/counterpartyd/blob/master/lib/broadcast.py.

This is now thankfully outdated. Broadcast and asset description text can now be 1K+. arbitrarily long asset descriptions and broadcast texts · CounterpartyXCP/counterparty-core@1f42b0c · GitHub

Wow, 1K+! How is that possible?