Pages:
Author

Topic: Working on an idea for simple web-based alternative to bitcoin-otc web of trust - page 3. (Read 2758 times)

legendary
Activity: 1330
Merit: 1000
Bitcoin
Hi Audenx,

Love the idea you have here. Def. needs this in the community. I'll see if I can contribute some more thought to it!
newbie
Activity: 44
Merit: 0
Can you just post the idea here, cause your website is completely down, for me.

Edit 7-March-2013: Website now reflects most recent pitch. Version 0.01 pitch archived here.

===

Sure! The website currently contains simply my v0.01 marketing pitch for the idea. dscotese's feedback above has already got me revising for the v0.02 pitch Smiley

Here's the original pitch:

Show off your trustworthiness with AudenX.

AudenX watches the Bitcoin blockchain for a simple pattern of small Bitcoin transfers that signals two parties' satisfaction with a transaction. Cumulatively, AudenX trades can be used to gauge a party's trustworthiness.

How does it work?

Step 1

Well, Alice, first you must grab a partner. That guy Bob who wanted to sell you a pair of alpaca socks for 1 Bitcoin? Yeah, he'll do just fine.

Each of you will need your own Bitcoin address to serve as your AudenX identity for your transaction. Make sure to keep the private key for your AudenX identity secure, because you'll want to keep using this identity to build the public record of your trustworthiness.2

Step 2

Create a new "scorecard" for your transaction.

Your scorecard is a new Bitcoin address, meaning an address that's never appeared on the blockchain before. Use any Bitcoin address generator or wallet that you like to create this address. The only requirement is that you, Bob, or both of you together must be able to make payments from the scorecard address.

Step 3

Pick a number, any number. (Well, any non-zero, non-negative number.)

Say you picked the number 10. Now 10 will represent the score for a completely satisfactory transaction experience.

To initiate the transaction, you and Bob each send 10 Satoshis (or 10 microBitcoins, or any order of magnitude you like — just keep it relatively small) to your scorecard address.

Once both transfers are complete, send the total scorecard balance (20 Satoshis, in this case) to AudenX3. That's a signal to AudenX that Alice and Bob have just started a transaction, and as an added bonus the transfer helps fund future development of services for the AudenX community.

Step 4

Make your trade! Sling those socks, and pay that coin. You can conduct your trade however you want, and you don't need to use your AudenX identity addresses to send or receive payments related to the trade.

Step 5

Rate your trade. Were you satisfied 100%? Then send another 10 Satoshis to your scorecard. Was Bob satisfied? Then he sends another 10 Satoshis to the scorecard address. Once both transfers are complete, send the balance (20 Satoshis) to AudenX. That's a signal to us that Alice and Bob finished a transaction, and that transaction scored 20 out of 20. Way to go, you two!

And you're done!
 
legendary
Activity: 1498
Merit: 1000
Can you just post the idea here, cause your website is completely down, for me.
newbie
Activity: 44
Merit: 0
If and when miners start relying on transaction fees much more than block rewards, these transactions won't get confirmed as easily as they are now.  So I'm thinking of another idea that doesn't require them.

I was also worrying about confirmation fees, but you came up with a smarter idea to address that than I did. I had simply been imagining a future scenario where the value of building your trust record is worth paying the incremental miner fees to "register" each transaction using the AudenX pattern, but that might be too optimistic if confirmation fees become significant.

Instead of making two new transactions to reflect the beginning of and subsequent satisfaction with a transaction X, put that information into an input in the next transaction N from an address known to belong to the same user who paid BTC in transaction X.

That seems like a step in the right direction. Not sure if this is exactly what you are describing, but after reading your response I started thinking the signaling pattern could be modified as follows. In addition to reducing cumulative confirmation fees, it eliminates the need for a "scorecard" address:

Alice (1AliceAudenXIdentityAddress) agrees to pay 1 BTC to Bob (1BobAudenXIdentityAddress) for a pair of alpaca socks. Both parties want the transaction to be reflected on their AudenX (1AudenXAddressOfRecord) trust histories.

Alice kicks off the AudenX process by creating a Bitcoin transaction. Let's call this transaction the "Alice-to-Bob-Open" signal.

INPUT: 1AliceAudenXIdentityAddress
OUTPUT1: 1BobPaymentAddress (1 BTC)
OUTPUT2: 1BobAudenXIdentityAddress (0.0001 BTC)
OUTPUT3: 1AudenXAddressOfRecord (0.00001 BTC)

Bob confirms that he's participating in this AudenX process by creating a Bitcoin transaction in response. Since he doesn't owe Alice any Bitcoin, he piggybacks his AudenX signal on top of a payment he owes to Wordpress. Let's call this transaction the "Bob-to-Alice-Open" signal.

INPUT: 1BobAudenXIdentityAddress
OUTPUT1: 1WordpressPaymentAddress (0.5 BTC)
OUTPUT2: 1AliceAudenXIdentityAddress (0.0001 BTC)
OUTPUT3: 1AudenXAddressOfRecord (0.00001 BTC)

AudenX, having received two payments, examines the associated transactions and can recognize the signals Alice-to-Bob-Open and Bob-to-Alice-Open. AudenX ignores any transaction outputs that don't fit the signaling pattern. Now AudenX knows that Alice and Bob have started a transaction. (Until AudenX sees the closing signals from Alice and Bob, the AudenX pattern is incomplete. Incomplete patterns can reflect negatively on an AudenX identity's trustworthiness, because it indicates that two parties haven't resolved their transaction, which might indicate a dispute, or the inability of one or both parties to signal correctly.)

When Alice and Bob complete their alpaca-socks-for-Bitcoin trade, they can indicate their satisfaction with the trade as being equal to, less than, or greater than the baseline score (which they each set at 0.0001 BTC in this example). Say Alice is 110% satisfied with the socks she's received, but Bob's a bit annoyed that Alice took so long to respond to his email requesting her shipping address, so he's just 90% satisfied.

To save on confirmation fees, the parties wait to send their final AudenX satisfaction scores until their next Bitcoin transaction. Then they create transactions like these:

"Alice-to-Bob-Close" signal (piggybacked on Alice's payment to the grocery store):

INPUT: 1AliceAudenXIdentityAddress
OUTPUT1: 1GroceryStorePayment (0.75 BTC)
OUTPUT2: 1BobAudenXIdentityAddress (0.000115 BTC) <-- 115% satisfied
OUTPUT3: 1AudenXAddressOfRecord (0.00001 BTC)

"Bob-to-Alice-Close" signal (piggybacked on top of Bob's dinner date tab):

INPUT: 1BobAudenXIdentityAddress
OUTPUT1: 1DinnerAndAMovieDate (1.10 BTC)
OUTPUT2: 1AliceAudenXIdentityAddress (0.000090 BTC) <-- 90% satisfied
OUTPUT3: 1AudenXAddressOfRecord (0.00001 BTC)

What do you think?
sr. member
Activity: 444
Merit: 250
I prefer evolution to revolution.
I like the idea of using "dust" for information.  You've got two extra "transactions-that-look-like-spam" in the requirements for building this WOT in the blockchain.  If and when miners start relying on transaction fees much more than block rewards, these transactions won't get confirmed as easily as they are now.  So I'm thinking of another idea that doesn't require them.

TL;TD: Instead of making two new transactions to reflect the beginning of and subsequent satisfaction with a transaction X, put that information into an input in the next transaction N from an address known to belong to the same user who paid BTC in transaction X.

My idea would be easiest if a bitcoin client were created that automated it.  Most transactions involve some change, which means there are at least two outputs, one of which belongs to the payer.  If the client enabled the user to create a "Who I Trust" (WIT) address, then it could remind the user at some user-specified interval of time after a bitcoin payment to rate the transaction ("Did you get what you paid for?", say on a scale of 1 to 10).  The client stores this answer but doesn't use it until the user makes another payment (to anyone, anywhere).  This second payment includes an extra output to the WIT address that reflects the user's satisfaction with the previous transaction.

The user can register his or her WIT address at AudenX and then you can write software to analyze the BC (like you're planning to anyway, I assume) that would identify transactions in which that WIT address was an output.  The analysis your software does, based on a WIT address, identifies other addresses that (we assume) belong to the owner of the WIT address.  Transactions to and from those addresses may or may not belong to others who have registered a WIT address.  If they do, then AudenX's analysis can produce a report saying User X was satisfied that he got what he paid for from User Y.

As usual, I invite people to correct any shortcomings in my understanding of bitcoin.
newbie
Activity: 44
Merit: 0
Hi there.

I'm brainstorming the minimum viable product for an alternative to bitcoin-otc. My current idea is summed up here on my website. I'd love for you more experienced members of the Bitcoin community to tear apart the idea so I can make it better. Comments welcome.

Thanks!

===

Edits:

7-Mar-2013: Updated pitch. Archived v0.01 pitch, replaced with v0.02 pitch.
Pages:
Jump to: