Multi-signature Transactions & The Nature of Markets

[Dread Pirate Roberts]

This point has come up a lot recently and although I do not intend to get into any great detail on the subject in public, I do need to highlight some issues which this single suggestion encompasses well. Some of the points I wish to raise are similar to what would be discussed between staff and the very highest echelons of Silk Road when we consider new ideas.

I'm not aware of who first suggested it, but there is word spreading that multi-signature addresses are somehow the holy grail on online markets and that it would stop bugs, thefts and problems faced from law enforcements, but this severely overlooks a lot of the practical problems we face as an online market. Yes it is true that it is theoretically more secure than the current bitcoin system as it is backed by strong crypto - but in practice it does not convert so well given steps must be taken in addition to usual market practices.

Right now, as an approximate market figure, PGP uptake is between 8% and 12% (unknown reason for fluctuations but US timezones have the lowest PGP uptake of all). PGP is a relatively straight forward step towards protecting your privacy and as far as the learning curve goes, it is certainly below that of learning to sign multi-signature transactions. So the evidence right now to suggest implementing the idea would be more beneficial than harmful is not true as we find preventing customers from having an easy to use interface will drive them to other markets, ones which are usually less secure and less trustworthy as we have seen with Sheep marketplace. Do not forget, Sheep was cast the eye of doubt when it first come about but because it was an easier to use interface, it took the lions share of the market above Black Market Reloaded which has a long and stable history.

Another concern highlighted by my fellow staff is that to sign a transaction you have two options - local storage or remote services. Remote services would negate the point of the implementation so for this we shall disregard that consideration leaving us with local storage. If a person was to have their hardware seized, holding a bitcoin wallet will then tie you in to the block chain which cannot be concealed and is certainly one of the strongest pieces of evidence which could be presented against an individual. This risk can be significantly mitigated through the use of encryption layers but to the average user it is unlikely they would take such measures and so we are only actually leaving more evidence in less secure places.

Multi-signature transactions will also mean the transaction must be known to all 3 parties and therefore the bitcoin trail faces increased exposure. Silk Road operates and protects users by making it impossible for one party to identify which deposit or withdrawals belongs to which buyer or vendor, something not possible with multi-signature transactions. It could be argued that mixing services may be employed to mitigate such risks but our research has shown only a fraction of users actually mix their bitcoins effectively before placing them into our system and so I have no confidence in such a setup as it provides further evidence for "honeypot vendors" should they ever be set up looking to arrest buyers, and it further prevents lazy vendors from being caught if they do not take the proper precautions. Most users do not mix their bitcoins, but an even smaller user share is those who mix their bitcoins without a single point of failure (ie use more than 1 company/service to mix them) and so if law enforcement were to gain leverage over a mixing service or continued their program of illegally tapping into such services (a credible threat) then this brings the risk of huge exposure for tens of thousands of users.

I hope this has helped clarify at least some of the reasons the administration is reluctant to implement this suggestion in its current form. We do have some ideas to counter some of the above ourselves, but even with that it is difficult to see this as a step in the right direction just yet. We are all for making use of proven technology, but at the same time we must make it as accessible as possible to not drive away those who aren't comfortable with it just yet.

[whitelightwhiteheat]

wow, am amazed at that 8-12% figure given all that's occurred recently

what the hell is it gonna take to get people to wise up?

[Yoda]

Right now, as an approximate market figure, PGP uptake is between 8% and 12%

Holy shit!   How is this figure determined?

Looks like I have a lot of work to do.   

[Loki]

\
Right now, as an approximate market figure, PGP uptake is between 8% and 12% (unknown reason for fluctuations but US timezones have the lowest PGP uptake of all). PGP is a relatively straight forward step towards protecting your privacy and as far as the learning curve goes, it is certainly below that of learning to sign multi-signature transactions. So the evidence right now to suggest implementing the idea would be more beneficial than harmful is not true as we find preventing customers from having an easy to use interface will drive them to other markets, ones which are usually less secure and less trustworthy as we have seen with Sheep marketplace. Do not forget, Sheep was cast the eye of doubt when it first come about but because it was an easier to use interface, it took the lions share of the market above Black Market Reloaded which has a long and stable history.

True, people dont have any incentive to secure themselves and typically dont. DPR (the original one) created SR with libertarian values, meaning it practices self-responsibility. I dont think this DPR shares any of the same values as the old one even though he felt it necessary to steal the old DPR's brand. At least if he did then users putting themselves at risk wouldnt be his concern, SR was never meant to be a nanny state but an online platform where people have the choice of being as secure as they want.

Another concern highlighted by my fellow staff is that to sign a transaction you have two options - local storage or remote services. Remote services would negate the point of the implementation so for this we shall disregard that consideration leaving us with local storage. If a person was to have their hardware seized, holding a bitcoin wallet will then tie you in to the block chain which cannot be concealed and is certainly one of the strongest pieces of evidence which could be presented against an individual. This risk can be significantly mitigated through the use of encryption layers but to the average user it is unlikely they would take such measures and so we are only actually leaving more evidence in less secure places.

The current implementation of p2p escrow (only in practice at themarketplace on i2p) involves the use of a local wallet, either QT or electrum, that a user must use to send and recieve payment. There really is no way around this as putting a wallet anywhere else means trusting the service, and we all know where that leads. I dont see the problem with this though, the real world equivalent of a local wallet is, you guessed it, a wallet. A real wallet. How many of us dont carry one? If you really wanted to cater to those who for some reason shrink back at the idea of actually having to install a piece of software then there is no reason the same couldnt be achieved with an online 3rd party service.

As for a wallet being siezed, it would be easier to seize a hosted wallet simply by serving the hosting company. In any case "tieing one into the blockchain" isnt as much evidence as per the assumptions in your scenario, already having been caught with drugs. Though i like how you dodged the fact that all tx's going into and out of your tumbler can still be associated relatively easily (as was done with SR1 in a research paper and Sheep later on by armchair detectives) with SR.

Im going to bold this so no one misses this: Any transcation going into or out of SR can be easily associated with SR, even if SR's tumbler makes it confusing to trace the path of payments. With a p2p escrow system there is no such association, as everything is p2p.

Multi-signature transactions will also mean the transaction must be known to all 3 parties and therefore the bitcoin trail faces increased exposure. Silk Road operates and protects users by making it impossible for one party to identify which deposit or withdrawals belongs to which buyer or vendor, something not possible with multi-signature transactions. It could be argued that mixing services may be employed to mitigate such risks but our research has shown only a fraction of users actually mix their bitcoins effectively before placing them into our system and so I have no confidence in such a setup as it provides further evidence for "honeypot vendors" should they ever be set up looking to arrest buyers, and it further prevents lazy vendors from being caught if they do not take the proper precautions. Most users do not mix their bitcoins, but an even smaller user share is those who mix their bitcoins without a single point of failure (ie use more than 1 company/service to mix them) and so if law enforcement were to gain leverage over a mixing service or continued their program of illegally tapping into such services (a credible threat) then this brings the risk of huge exposure for tens of thousands of users.

Once again its not your responsibility to make sure others dont willingly throw themselves into harms way. You and other site administrators have done their part in attempting to educate users about the safety basics of these marketplaces, if people want to be stupid and reckless then no technology is going to protect them. Your arguments about honeypot vendors and backdoored mixing services is specious and unfounded, why bother collecting bitcoin addresses when you have the customers name and address.

I hope this has helped clarify at least some of the reasons the administration is reluctant to implement this suggestion in its current form. We do have some ideas to counter some of the above ourselves, but even with that it is difficult to see this as a step in the right direction just yet. We are all for making use of proven technology, but at the same time we must make it as accessible as possible to not drive away those who aren't comfortable with it just yet.

No one said p2p had to become the defacto, offer it as 1 of 2 ways to pay. If people want to trust you with thier money then thats their choice to make, as for the rest of us, let the market speak for itself.

[El Presidente]

Some good points on all sides of the argument and it must be said that we are indeed a proponent of direct payments, or more specifically of having a choice.

However a fundamental problem with person to person transactions is that it places the onus on both parties to wash themselves of the bitcoin trail somehow. This is difficult for skilled individuals knowledgeable in the arts, for the average buyer/seller it is almost beyond reach.

The main scenario we would see is LEO posing as buyers and then being able to ascertain with a high degree of certainty the vendors BTC address. We would expect them to very swiftly kick down the doors of any commercial outfit offering pseudo-anonymity mixing such as Blockchain and extract whatever records were necessary for identifying the user or the actual end wallet.

Until that nut is cracked, a market site holding the coins adds a hop and some 'distance' between buyer and seller and makes it harder for LEO to identify a vendor assuming

a) The site is not run by LEO
b) The records on the site to do not fall into LEO hands

Despite this we still think a choice is always better than having no options but vendors should be aware of the risk of direct payments.

[Tessellated]

wow, am amazed at that 8-12% figure given all that's occurred recently

what the hell is it gonna take to get people to wise up?

I must have extra smart customers because about 60% of my orders are PGP'd.

[Loki]

However a fundamental problem with person to person transactions is that it places the onus on both parties to wash themselves of the bitcoin trail somehow. This is difficult for skilled individuals knowledgeable in the arts, for the average buyer/seller it is almost beyond reach.

Thats actually a problem with any site, p2p or not. Vendors should always be doing this, though buyers have the option depending on how they bought their coin.

The main scenario we would see is LEO posing as buyers and then being able to ascertain with a high degree of certainty the vendors BTC address. We would expect them to very swiftly kick down the doors of any commercial outfit offering pseudo-anonymity mixing such as Blockchain and extract whatever records were necessary for identifying the user or the actual end wallet.

You realize you can create as many of these as you want.

Until that nut is cracked, a market site holding the coins adds a hop and some 'distance' between buyer and seller and makes it harder for LEO to identify a vendor assuming

a) The site is not run by LEO
b) The records on the site to do not fall into LEO hands

That hop is otherwise known as a big red target. LEO cant ID vendors who mix and cashout safely no matter where they got the coin from, even directly from LEO.

Loki,

How about you develop a market using a p2p escrow system, fund it, advertise it, and see where 'the marketplace' decides to do business.

Dont have to, it already exists.

themarketplace.i2p

[Tessellated]

Dont have to, it already exists.

themarketplace.i2p

Time will tell if it is practical with the current state of bitcoin clients and customer education. I am glad a marketplace is testing this out.

[Mr Lucy]

\
Right now, as an approximate market figure, PGP uptake is between 8% and 12% (unknown reason for fluctuations but US timezones have the lowest PGP uptake of all). PGP is a relatively straight forward step towards protecting your privacy and as far as the learning curve goes, it is certainly below that of learning to sign multi-signature transactions. So the evidence right now to suggest implementing the idea would be more beneficial than harmful is not true as we find preventing customers from having an easy to use interface will drive them to other markets, ones which are usually less secure and less trustworthy as we have seen with Sheep marketplace. Do not forget, Sheep was cast the eye of doubt when it first come about but because it was an easier to use interface, it took the lions share of the market above Black Market Reloaded which has a long and stable history.

True, people dont have any incentive to secure themselves and typically dont. DPR (the original one) created SR with libertarian values, meaning it practices self-responsibility. I dont think this DPR shares any of the same values as the old one even though he felt it necessary to steal the old DPR's brand. At least if he did then users putting themselves at risk wouldnt be his concern, SR was never meant to be a nanny state but an online platform where people have the choice of being as secure as they want.

Another concern highlighted by my fellow staff is that to sign a transaction you have two options - local storage or remote services. Remote services would negate the point of the implementation so for this we shall disregard that consideration leaving us with local storage. If a person was to have their hardware seized, holding a bitcoin wallet will then tie you in to the block chain which cannot be concealed and is certainly one of the strongest pieces of evidence which could be presented against an individual. This risk can be significantly mitigated through the use of encryption layers but to the average user it is unlikely they would take such measures and so we are only actually leaving more evidence in less secure places.

The current implementation of p2p escrow (only in practice at themarketplace on i2p) involves the use of a local wallet, either QT or electrum, that a user must use to send and recieve payment. There really is no way around this as putting a wallet anywhere else means trusting the service, and we all know where that leads. I dont see the problem with this though, the real world equivalent of a local wallet is, you guessed it, a wallet. A real wallet. How many of us dont carry one? If you really wanted to cater to those who for some reason shrink back at the idea of actually having to install a piece of software then there is no reason the same couldnt be achieved with an online 3rd party service.

As for a wallet being siezed, it would be easier to seize a hosted wallet simply by serving the hosting company. In any case "tieing one into the blockchain" isnt as much evidence as per the assumptions in your scenario, already having been caught with drugs. Though i like how you dodged the fact that all tx's going into and out of your tumbler can still be associated relatively easily (as was done with SR1 in a research paper and Sheep later on by armchair detectives) with SR.

Im going to bold this so no one misses this: Any transcation going into or out of SR can be easily associated with SR, even if SR's tumbler makes it confusing to trace the path of payments. With a p2p escrow system there is no such association, as everything is p2p.

Multi-signature transactions will also mean the transaction must be known to all 3 parties and therefore the bitcoin trail faces increased exposure. Silk Road operates and protects users by making it impossible for one party to identify which deposit or withdrawals belongs to which buyer or vendor, something not possible with multi-signature transactions. It could be argued that mixing services may be employed to mitigate such risks but our research has shown only a fraction of users actually mix their bitcoins effectively before placing them into our system and so I have no confidence in such a setup as it provides further evidence for "honeypot vendors" should they ever be set up looking to arrest buyers, and it further prevents lazy vendors from being caught if they do not take the proper precautions. Most users do not mix their bitcoins, but an even smaller user share is those who mix their bitcoins without a single point of failure (ie use more than 1 company/service to mix them) and so if law enforcement were to gain leverage over a mixing service or continued their program of illegally tapping into such services (a credible threat) then this brings the risk of huge exposure for tens of thousands of users.

Once again its not your responsibility to make sure others dont willingly throw themselves into harms way. You and other site administrators have done their part in attempting to educate users about the safety basics of these marketplaces, if people want to be stupid and reckless then no technology is going to protect them. Your arguments about honeypot vendors and backdoored mixing services is specious and unfounded, why bother collecting bitcoin addresses when you have the customers name and address.

I hope this has helped clarify at least some of the reasons the administration is reluctant to implement this suggestion in its current form. We do have some ideas to counter some of the above ourselves, but even with that it is difficult to see this as a step in the right direction just yet. We are all for making use of proven technology, but at the same time we must make it as accessible as possible to not drive away those who aren't comfortable with it just yet.

No one said p2p had to become the defacto, offer it as 1 of 2 ways to pay. If people want to trust you with thier money then thats their choice to make, as for the rest of us, let the market speak for itself.

+1 Nicely said, and also because you got too much dislike...

[missbliss]

hi hi

from what i read on the bitcoin forums, there appears to be a big push for the CoinJoin type of transactions to combat the Coin Validation ideas. CoinJoin being the 2-of-2 style where it's many inputs and many outputs.  this seems to be a good method of hiding exactly which inputs go to which outputs. it's also currently in use on the network already, and is advocated by a number of the bigger BTC developers.  it's also trustless, so even the server and other parties dont know what goes where!

without divulging too much, maybe DPR or another admin can shed some light on whether incorporating those transactions would help with our collective privacy.

i believe this has nothing to do with multi sig, which as DPR correctly stated is still a bit too "geeky" for the layperson to correctly figure out. that may all change when multi sig gets a GUI implementation in the upcoming client releases.

finally, this is intended to be more for privacy than escrow protection, so please dont confuse the two! perhaps there is some esoteric way of chaining transactions from a protected multi sig direct buyer/seller escrow where the private key is not hosted by the site, and upon release gets forwarded into a CoinJoin transaction to mask the output.... but thinking about the specifics of that makes my head hurt, especially when trying to calculate transaction fees and commission!

xoxo
-mb

[DoctorClu]

I have never understood the thinking behind this. Equated to street narcotic sales, this sort of debate is like expecting that it is solely the responsibility of your average drug dealer to protect the buyer from law enforcement. Both sides must take their own steps to protect one another if sales are to continue. Obviously, this requires a certain level of trust. The main difference in this scenario of course is anonymity. The buyers of the Silk Road do not know the identity of their vendors, yet vice versa, the vendor has the name and address of the buyer. This is where that same level of trust has to come into play. The market provides a medium for the exchange to occur but so long as the correct precautions are taken on both sides, that medium should not know the identity of either party.

PGP is the obvious and most elegant way to perform these transactions. If a buyer is not willing or is not knowledgeable enough to use it, they are their own worst enemy and would remain so under multi-signature transactions. The current system isn't broken so I see no need to change it.

[StringerBell]

As it is important to be up to date with the latest development it is also important for an organization to not jump
on board with all the latest changes in theory's that has not yet been proved! Change is important but also stability.
It feels good to read that DPR have a balanced and science based approach to this project!

[missbliss]

I have never understood the thinking behind this. Equated to street narcotic sales, this sort of debate is like expecting that it is solely the responsibility of your average drug dealer to protect the buyer from law enforcement. Both sides must take their own steps to protect one another if sales are to continue. Obviously, this requires a certain level of trust. The main difference in this scenario of course is anonymity. The buyers of the Silk Road do not know the identity of their vendors, yet vice versa, the vendor has the name and address of the buyer. This is where that same level of trust has to come into play. The market provides a medium for the exchange to occur but so long as the correct precautions are taken on both sides, that medium should not know the identity of either party.

PGP is the obvious and most elegant way to perform these transactions. If a buyer is not willing or is not knowledgeable enough to use it, they are their own worst enemy and would remain so under multi-signature transactions. The current system isn't broken so I see no need to change it.

hi hi

i think you may be slightly over assuming in some areas. for instance, there is no guarantee the name and address on shipping info i receive is the same person who is making the purchase.  you can just as easily enter your neighbor's information, or a co-worker, or someone completely random!

again, as i stated above, multi sig as it exists RIGHT NOW is not feasible for the average user to correctly wield. when the various BTC wallet clients get GUI upgrades that incorporate multi sig, it may be much much easier for them to do. in fact, it should be completely transparent to the user if it's implemented correctly.

in my hypothetical chained example, the buyer would deposit instead of to their normal SR deposit address, it would be a special address specific to that particular order, created on the fly. that multi sig address would then hold the coins in escrow until the buyer signs the transaction and releases the coins to the seller, in this case a virtual address. then, once released, SR automatically forwards the sale balance minus commission into a p2p CoinJoin transaction that eventually ends up into a vendor's withdrawal address. if done correctly there is no way for the buyer to know what that final address is, nor the vendor to know what the originating deposit came from, nor even the SR server itself!!

xoxo
-mb

[StevieHyperD]

Firstly DPR thanks for addressing this, I have been banging the drum for this myself and I am glad it has been at least considered.

While I agree there are issues around people anonymising the bitcoin trail and handling the bitcoin client in a manner that is secure, I think it is unfair to not use this technology because some choose to ignore recommended OpSec. While I do wish people would increase there security (and am shocked by the 12% figure, I honestly thought it would be in the high 80s), you can't force people to look after themselves. In my opinion SR should be the opposite of a "nanny state". There are many threads helping users increase OpSec, and I have personally tried to help people adopt more secure processes. Users do at some point have to take responsibility for themselves, I believe SR's role should be to publicise it as much as possible, but not to enforce it.

How about enabling such an option for those that wish to pursue it? Those who are less inclined to do so can carry on with the status quo. I worry no one will take it up but I am willing to put myself forward as a guinea pig to test a transaction.

I personally think the best thing we can do right now with the lack of mainstram support for multi sigs is create a script that makes the process easier. I.e. generates a 1 time public/private key for users that they can submit for the transaction and ultimately sign with a payee address. Similar thing for the vendor, and on top of that increase knowledge about how to hide the bitcoin trail (i.e new addresses for all transactions, don't cluster coins at a single address etc). I do however worry that a huge increase in the number of multi sig transactions could draw attention, but that is even more reason to start off small.

I do have a certain affinity to SR, but my gut tells me the paradigm is shifting, and I hope this doesn't lead to a demise before its time of the new incarnation of what I found to be one of the most liberating creations of the last decade. Please don't take any of this as negative criticism, like I say I appreciate that you have given it some thought and considered it, but times are a changing, and sometimes people need to be dragged kicking and screaming into a new era.

[Angel Eyes]

I was one of the vendors talking ( loudly ) about solutions to escrow risk earlier this week.  I liked the multisig idea but I think it is too complex in its current implementation, and as DPR points out it has other problems as well.

The key issue here is that vendors and customers are being ripped off on a regular basis and this needs to stop or at least be mitigated in some way to keep this model viable.  Even if we all think DPR is honest, which I think many of us do, this doesn't help the model if a lot of other sites wind up going the "Sheep route".  It will cast a pall over the whole business model and many will be just "waiting" for DPR to do the same.  The more directly SR2 tackles this issue the more trusted they will be.

The only currently viable method that I've seen to reduce escrow risk is to make it more profitable for site owners to earn their money by running the site than by skipping out with the coins (if anyone believes that lame story from Sheep's owner about someone else stealing all the coins I have a bridge I'd like to sell them).

I do totally agree with DPR that a complicated site will turn buyers away.  His Sheep versus BMR example is a pretty good one, though I might add that BMR was running slow for that whole period and may have turned off a lot of buyers.

That said, what can we do to reduce escrow risk (not to mention exchange rate risk)?  I propose that we, as @El Presidente suggests, allow vendors to create their own policies from a range of preselected options.  For example, there could be a normal escrow option that works just like it does now.  There could also be a 50/50, a 30/70 or other up front and on delivery payment schedule.  That would reduce the amount of coin stored on the site for any length of time by a considerable amount and allow vendors to have immediate access to at least a portion of the funds.  A new vendor might have to use the original escrow option for a given number of transactions before they are allowed to use the more trusted options.  All funds could still pass through the site's obfuscation system.

If darkwallet's ideas come to fruition the mixing issue will go away.  CoinJoin, if implemented widely, is a brilliant idea.  But it doesn't do anything to reduce escrow and rate risk that vendors and customers face every day. 

Allowing up front payments of up to 50% will allow vendors to access their funds faster, reduce amounts in escrow by up to 50%,  and will even simplify at least one thing -- if an order is lost in shipping the buyer and seller don't have to do anything.  They each take a 50% loss and share the pain (of course that is for vetted, proven vendors only, and is subject to their own policies -- many vendors offer reship for a lost order).

That's my two cents anyway .

[anontoker]

DPR, isn't it possible for you to encrypt a user's shipping info using the vendor's provided PGP key on the market?

Just askin' as this would raise that 15%..

[Angel Eyes]

DPR, isn't it possible for you to encrypt a user's shipping info using the vendor's provided PGP key on the market?

Just askin' as this would raise that 15%..

Not a bad idea at all @anontoker! 

Also, I'd say, for our customers at least, PGP adoption is more like 60-70%

[anontoker]

DPR, isn't it possible for you to encrypt a user's shipping info using the vendor's provided PGP key on the market?

Just askin' as this would raise that 15%..

Not a bad idea at all @anontoker! 

Also, I'd say, for our customers at least, PGP adoption is more like 60-70%

Thanks, I'm tryin' for at least 10 more useful posts before I get to 500.

To be honest I like the idea myself.

[Dread Pirate Roberts]

We are very much against implementing automatic PGP encryption as it actually does not benefit security. If law enforcement were to compromise our servers, then they could get a copy of the address before encrypting it to the vendors PGP key and circumvent that measure effectively, this would then lead people into a false sense of security.

As I have said, we are exploring this suggestion further but until we can resolve some of the problems it poses then we will not be implementing it. Multiple options could be integrated, but I believe right now the time could be better spent in other areas allowing bitcoin clients time to better implement multi-signature transactions into their base code and therefore when the time comes it is a more accessible part of transactions we can then place it as a higher priority.

[Angel Eyes]

We are very much against implementing automatic PGP encryption as it actually does not benefit security. If law enforcement were to compromise our servers, then they could get a copy of the address before encrypting it to the vendors PGP key and circumvent that measure effectively, this would then lead people into a false sense of security.

As I have said, we are exploring this suggestion further but until we can resolve some of the problems it poses then we will not be implementing it. Multiple options could be integrated, but I believe right now the time could be better spent in other areas allowing bitcoin clients time to better implement multi-signature transactions into their base code and therefore when the time comes it is a more accessible part of transactions we can then place it as a higher priority.

That's a great point DPR -- if the site is compromised encrypting on the site is useless, and if the site isn't compromised then LE can't (easily ?) see the addresses that are unencrypted anyway... and it will make users complacent.

How about giving us the option to do 50/50 upfront/on delivery type arrangements?  I'm not saying we need it tomorrow, but just something to implement over the next couple months or so?

[Hiniguel]

wow, am amazed at that 8-12% figure given all that's occurred recently

what the hell is it gonna take to get people to wise up?

I must have extra smart customers because about 60% of my orders are PGP'd.

About 80% for me. Guess UK people got a little spooked after the arrests(Pete and the 3 other guys), it seemed the UK thought they were untouchable before.

[Hiniguel]

However a fundamental problem with person to person transactions is that it places the onus on both parties to wash themselves of the bitcoin trail somehow. This is difficult for skilled individuals knowledgeable in the arts, for the average buyer/seller it is almost beyond reach.

Let me point out 2 basic facts here:

No blackmarket user has ever been busted in total or in part due to blockchain analysis that we know of; I can state this in considerable confidence based on the dozens of cases I have compiled in my article. Almost all criminal complaints on SR or other market users I have read either do not mention blockchain or mention that they couldn't figure it out.
Thousands of users have been burned badly by blackmarkets absconding with deposits & escrows

I hope these facts are useful for weighing the utility of multisig.

Even tumbling your coins still makes them traceable, but it just makes it so time consuming, requires so much man power, it's difficult and so expensive that they simply can't do it.

Some university proessor published a paper on it recently.

[StringerBell]

About money upfront and partly escrow, it could be something that could be earned by trusted vendors after 300-400 sales or something.
Maybe it would decrease vendors asking for full FE for cash flow reasons as well.

But something that are essential that often are to be forgotten is that most people who are using the marketplace ain't elitist
experts that are used to browse the forum, use pgp etc. These are the people vendors earn a lot of money of. It's important
for these people to feel safe enough to make a purchase. If it wasn't for escrow Silk road wouldn't be such a mass success in the first place.

[besam191]

We are very much against implementing automatic PGP encryption as it actually does not benefit security. If law enforcement were to compromise our servers, then they could get a copy of the address before encrypting it to the vendors PGP key and circumvent that measure effectively, this would then lead people into a false sense of security.

As I have said, we are exploring this suggestion further but until we can resolve some of the problems it poses then we will not be implementing it. Multiple options could be integrated, but I believe right now the time could be better spent in other areas allowing bitcoin clients time to better implement multi-signature transactions into their base code and therefore when the time comes it is a more accessible part of transactions we can then place it as a higher priority.

thanks DPR, auto PGP has always confused me as to what type of attack it is supposed to protect. With PGP; all info is protected unless both a node AND the site have their info compromised.
We should all stop stop being polarizing and accept that this decision is not in our own hands. whatever works the best will prevail. were just here for the ride

[anontoker]

@DPR That makes sense.

I'm disappointed I wasn't helpful but perhaps next time.

Thanks for taking the time to explain things to us.

[Angel Eyes]

That's a great point DPR -- if the site is compromised encrypting on the site is useless, and if the site isn't compromised then LE can't (easily ?) see the addresses that are unencrypted anyway... and it will make users complacent.

No, that's not quite it. If a site gets compromised SR-style with an image taken of the server or the server is seized outright, then it doesn't matter whether the PGP was done in-browser or not - the messages are still unreadable. The PGP will work.

Auto PGP is a problem when the compromise is a flipping scenario like Hushmail or Lavamail or (some day if not already) safe-mail.net: where the operators are coerced into performing a MITM and collecting all messages post-MITM.

DPR2 seems to think the latter scenario is more relevant to SR2 than the former.

You say there is no problem if "the PGP is done in-browser" but that's not really true.  Remember that the encryption code used in-browser will be provided by the site.  A compromised site means a compromised encryption process.  Its actually the same as the lavabit problem exactly.  Its true that messages encrypted prior to LE compromising the site won't be accessible to them but post-compromise everything will be available.

@StringerBell, I disagree that it takes 300 transactions for a vendor to become reliable enough to their customers that they will trust vendors with a 50% upfront arrangement.  The truth is this could be done on a customer basis.  If the customer trusts the vendor they can choose the 50% option.  If they don't they can use the normal escrow system.  It doesn't need anything more, and vendors could offer discounts for customers who pay 50% upfront to entice them to use it.  I'd say after 30 positive orders this system could be put in place.  30 real orders is enough to see if a vendor is selling something real or not IMO.

Can it be gamed?  Yes.  Can the current system be gamed the same way?  Yes.

[Angel Eyes]

And I'd like to point out that this discussion isn't some kind of how-many-angels-can-dance-on-the-head-of-a-pin type silliness.  We got burned for almost $3,000 when Sheep went down.  And the past two days the value of my escrow dropped to almost half its original value.

If I had only lost $1500 on Sheep and had been able to sell half the coins in escrow before the drop I'd be A LOT happier right now, and I know I'm not alone.  This is our livelihoods.

So lets keep this focused.  Offering customizable escrow arrangements will go a long way to making many of us feel like not only are our problems being addressed, but also that the likelihood of us being fleeced again will be greatly reduced.  DPR not offering us a solution is telling us he doesn't want the pie he controls to be smaller.  That doesn't inspire confidence.  Not because I think he's going to take the pot, but this is a wild world, and LE can come crashing in at any time.  So can we get a response on this idea or not?

I thought this site was about liberty -- about the freedom to do business the way we choose -- consenting adults making arrangements in ways that work for them.  But all I keep hearing is attempts to nanny customers and vendors through prescripted deals so customers can feel "safe".  The idea that both parties in a transaction can come to an arrangement that work for them -- isn't that what SR stands for?  Without this very freedom -- freedom of transaction -- we risk being just another black market site, losing all of our ethical and moral reasons for being here.

[Angel Eyes]

The truth is combining multi-sig with flexible escrow arrangements (e.g., 50/50 upfront/ondelivery) provide the optimum in escrow and exchange rate protection.

Any site that implements them as options will show vendors their needs are being taken seriously.

[Loki]

Well people, as dpr correctly pointed out, p2p escrow right now is a complicated procedure with no clear guidelines, if you really want p2p escrow to work then hop on over to either themarketplace's reddit or get onto their forums (on i2P ) themarketplace.i2p/forum/index.php and offer some ideas that would simplify the system. For now a guide is being written up to help people understand the process and to have the whole thing done with just a local wallet and the site, but this is all still beta and theres alot of room for improvement.

To note DPR's claim that local wallets dont have this feature is false, the two main clients, QT and Electrum have the p2sh feature and are being developed to be more user friendly in the coming months.