Is this a working model for an anonymous decentralized parcel service?

Is this a working model for a decentralized and anonymous parcel service?

  1. a buyer wants to buy a big cup of noodles. He contacts the seller and they agree on a price: $110 to have his big cup of noodles delivered to his door step.

  2. Both buyer and seller both put in $110 into multisig address simultaniously via an atomic transaction.

  3. Distributor1 pays seller $90 in exchange for package.

  4. Distributor2 pays distributor1 $95 in exchange for package.

  5. Distributor3 pays Distributor2 $100 in exchange for package.

  6. Distributor4 pays distributor3 $110 in exchange for package.

Unknown to the network, distributor4 is the buyer. The network also does not know if the seller was a distributor.

  1. Seller gets $220 when buyer releases escrow and stake funds for payment.

Alternatively: 7. Distributor3 refuses item, distributor2 takes a $100 loss for destroying/buying/stealing the package.

  1. Buyer and seller return $110 to each other. Buyer is fully refunded, and the seller made a profit.

The only issue/attack vector I see with this is the following: self damaging packages.

Seller ships a "time-bomb" - so the seller get the $90, and their $110 refund. So they profit at the loss of whatever distributor was holding the package while it self-destructed.

How would this exploit be fixed? It seems very difficult to fix the self damaging packages exploit and it seems like this attack would work to exploit UPS/USPS if the package had insurance on it.

Also: this is only the backbone of a decentralized parcel system. You'd also need to have the packages have multiple layers from hard to counterfit/unique wrapping paper layers. Each distributor would verify the outside, and take it off to reveal a new outside layer the next distributor would verify. In between each layer would exist a GPG encrypted message for each distributor for further instructions on where to take the package. Extra layers could be used to conceal end user. (I.e I am supposed to ship this but no one is claiming this new layer)

This idea would work like http://GetKanga.com but it'd be more time consuming and require higher distributor involvement which comes as a trade off for completely anonymous and decentralized parcel system.


Comments


[3 Points] None:

[deleted]


[2 Points] galaxyandspace:

you may be interested in this thread: /r/Rad_Decentralization/comments/2bify2/the_united_states_shipping_overlords_usps_ups/


[1 Points] None:

[deleted]


[1 Points] sapiophile:

This is awesome. I had some similar thoughts several years ago, basically applying the Onion Routing model to physical parcels, with literal physical layers that get peeled off. The cascading payments is a big, big improvement that I hadn't thought of.

I feel like the refund-bonus problem is solvable. Let's think about it.


[1 Points] sapiophile:

Ok, so one major problem is that as you've laid it out, the distributors pretty much have a guarantee that the actual value of the package is greater than the amount they've paid to pass it on. So what's to stop malicious distributors from just helping themselves to discount mystery packages? Of course there's reputation, etc., but that's how things go with the markets' vendors now, and plenty of them still exit scam... I suppose a similar rate of scamming could be tolerable...


[1 Points] sapiophile:

So here's another potential problem:

A distributor decides that they want want more fees. Or, maybe, they actually want to compromise the anonymity of things. So, instead of peeling off one layer, they peel off three (or however many), and act as the distributor n jumps ahead of them, and collect the significantly larger payment that that distributor would get.

Solution: The sender broadcasts a series of message that reach all the distributors in the chosen chain prior to shipping the parcel, basically just like "distributor 3112a98d1423de354d2b50169087b842, expect a package before Dec. 12, 2014." Each broadcast message would have to mention only one distributor, because if all the distributors' "names" were included, then it obviously reveals the length of the chain (and potentially allows someone to trace the package if they can tie distributor "name" to an identity or location). Also, both the source and the recipient of the broadcasts must be concealed, and all sent on a common channel, and so it may make sense to do it through a TTL-limited DHT, perhaps something like BitMessage. The sender could include their own public key for reports back from distributors, e.g., if one of the named distributors doesn't actually end up seeing the parcel. If a distributor AFTER the one who didn't see it ends up checking in affirmatively, the double-dipping distributor could be identified easily.


[1 Points] sapiophile:

Another potential problem is the expense and effort of the actual physical packaging. Each layer of packaging that's peeled off at each step must have several properties:

This might be feasible with simple aluminum foil wrapping - e.g., the parcel gets boxed, addressed, and then wrapped with Al foil, then boxed again, addressed, foiled again, and so on. But as for tamper-resistance, I don't have many ideas. I know they sell tamper-evident adhesive tape and such, so that's probably the most economical option, but my knowledge about specifics on this stuff is lacking. Actually, if it's just a matter of foil and special tape, it might be fairly cheap and easy to do...

But either way, it's going to mean pretty high shipping & handling charges. Not to mention that the distributors don't have the infrastructure to do these things in bulk, meaning that their costs will be way higher than, say, USPS.

EDIT: Another potential option would be re-usable packages, perhaps foil-lined Pelican boxes or something similar, which then get shipped back to the seller... a bit like common railroad car pools, etc. but I see a lot of potential problems with that - they're expensive, they potentially compromise the seller's anonymity, they could be bugged or beaconed, etc...