Topic: Open-Transactions VIDEOS... (Automated Escrow!!) (Read 2466 times)
This is awesome work. Love the background music too!!
AWESOME!
Just to make it even easier, here are THREE NEW VIDEOS, covering the Escrow smart contract! (In addition to the other three videos I already posted for the Two-Way Trade smart contract.)
Available as of now, at the same link: http://open-transactions-tv.github.com/
A total of 13 videos are now posted there, so let me know what you guys think, or if you have any requests.
-Fellow Traveler
Available as of now, at the same link: http://open-transactions-tv.github.com/
A total of 13 videos are now posted there, so let me know what you guys think, or if you have any requests.
-Fellow Traveler
Okay, after watching the vids I have what may seem to be some dumb questions but here goes ....
- what is the difference between a smart contract "two-way-trade" and an automated escrow?
It seems like they effectively achieve the same end in that they put fund in a third location (this time inside the smart-contract) until both parties sign off that they are happy and the trade proceeeds ... (btw this is very cool that you can do this)
- what is the difference between a smart contract "two-way-trade" and an automated escrow?
It seems like they effectively achieve the same end in that they put fund in a third location (this time inside the smart-contract) until both parties sign off that they are happy and the trade proceeeds ... (btw this is very cool that you can do this)
They are different:
Two-way trade: There are 2 parties: Alice and Bob. Take X units of currency Y from Alice, take Z units of currency W from Bob, and then give Alice's funds to Bob, and give Bob's funds to Alice (end.)
Escrow: There are 3 parties: Alice, Bob, and Judge Judy. Take X units of currency Y from Alice, and stash them in the contract for Z days. (She is paying these to Bob in return for some offline consideration. For example, perhaps Bob is selling guitars online, and Alice is waiting to receive a physical guitar from Bob in the snail mail, which she is purchasing from him.) The physical item that Alice is purchasing must be noted ON the smart contract, in the "consideration" field.
Normally, the guitar shows up in the mail, and then after Z days, the money that was stashed in the contract is then automatically transferred to Bob. However, if Alice has not received the guitar within Z days, she can file a dispute (by triggering a "dispute" clause, which is just another script on the same contract.) This sends a notice to all three parties, giving Bob an opportunity to respond. Then Judge Judy has D days to make a decision, based on Alice's dispute text, Bob's response text, and the text of the consideration field itself, which ideally describes the exact criteria for determining whether or not Bob has fulfilled his obligation. Judge Judy receives a small fee for signing onto the contract, and an additional fee if she actually has to get involved and adjudicate a dispute.
Quote
So now the responsibilty of successful execution of the trade has been placed on a third-party, in this case the automated mechanism of smart-contract performed by the Open-Transactions server. In view of this, would it be possible to extend the two-way-trade smart-contract to be executed on two or more servers in case of failure to execute at the primary? (like as a back-up clause?)
Normally an Open-Transactions instrument must be redeemed at the same server where it was issued. Various protocols are possible however, especially if I allow HTTP POST actions from inside the smart contracts. Also consider the Bitcoin blockchain supports multisig and contracts -- so all kinds of combinations are theoretically possible.
Okay, after watching the vids I have what may seem to be some dumb questions but here goes ....
- what is the difference between a smart contract "two-way-trade" and an automated escrow?
It seems like they effectively achieve the same end in that they put fund in a third location (this time inside the smart-contract) until both parties sign off that they are happy and the trade proceeeds ... (btw this is very cool that you can do this)
Also it seems like conceptually it is the crypto-financial equivalent to those rotating glass teller gizmos you see at late-night service stations and some banks ... where you place your cash, cheque-deposit slip, withdrawl request or whatever on one side of the glass turn-table and the teller places their receipt, cash or other stuff on the other side and when it is all good someone hits a lever and the turntable rotates around .... trade done. Both parties can see what is being placed for trade without handing over ownership .. until which time as the mutally-agreed upon mechanism takes over ... in this case the two-way-trade smart contract.
So now the responsibilty of successful execution of the trade has been placed on a third-party, in this case the automated mechanism of smart-contract performed by the Open-Transactions server. In view of this, would it be possible to extend the two-way-trade smart-contract to be executed on two or more servers in case of failure to execute at the primary? (like as a back-up clause?)
- what is the difference between a smart contract "two-way-trade" and an automated escrow?
It seems like they effectively achieve the same end in that they put fund in a third location (this time inside the smart-contract) until both parties sign off that they are happy and the trade proceeeds ... (btw this is very cool that you can do this)
Also it seems like conceptually it is the crypto-financial equivalent to those rotating glass teller gizmos you see at late-night service stations and some banks ... where you place your cash, cheque-deposit slip, withdrawl request or whatever on one side of the glass turn-table and the teller places their receipt, cash or other stuff on the other side and when it is all good someone hits a lever and the turntable rotates around .... trade done. Both parties can see what is being placed for trade without handing over ownership .. until which time as the mutally-agreed upon mechanism takes over ... in this case the two-way-trade smart contract.
So now the responsibilty of successful execution of the trade has been placed on a third-party, in this case the automated mechanism of smart-contract performed by the Open-Transactions server. In view of this, would it be possible to extend the two-way-trade smart-contract to be executed on two or more servers in case of failure to execute at the primary? (like as a back-up clause?)
watching
I'm back, with THREE NEW VIDEOS, just posted today!
http://open-transactions-tv.github.com/
This time the subject is SMART CONTRACTS, and I encourage you to read
the article as well:
https://github.com/FellowTraveler/Open-Transactions/wiki/Smart-contracts
--------------------------------------------
"Smart Contracts" are custom-scriptable agreements that multiple parties
can sign and then activate on an OT server. Using a simple script
language, you (or your lawyer) can design your own agreements and then
OT will bring your scripted clauses to life!
--------------------------------------------
Demo: TWO-WAY TRADE (3 videos)
For my first demo, I've chosen "two-way trade" because it seems like the
simplest possible example.
Basically, Alice and Bob want to trade some "gold" for "bitcoins" (any
two asset types.) Neither one of them wants to "go first" and risk
sending their half of the money--they prefer to be GUARANTEED that the
other party will reciprocate, before paying.
Therefore, the "two-way trade" smart contract insures that it has safely
obtained all the money from BOTH parties, before switching ownership
over to the new recipients!
---------------------------------------------
Coming soon: "Escrow" smart contract.
This version introduces a 3rd party arbiter (Judge Judy), for cases
where Alice is paying Bob for some PHYSICAL ITEM that he's sent her in
the snail-mail.
In the event of any dispute, it's up to Judy to adjudicate and make a
final decision!
-FT
P.S. Your donations go to help fund the test GUI development.
BTC: 1NtTPVVjDsUfDWybS4BwvHpG2pdS9RnYyQ
(Then you can have smart contracts in the GUI instead of command-line only.)
P.P.S. As I said before, I have a special announcement coming up soon,
so keep your eyes peeled!
http://open-transactions-tv.github.com/
This time the subject is SMART CONTRACTS, and I encourage you to read
the article as well:
https://github.com/FellowTraveler/Open-Transactions/wiki/Smart-contracts
--------------------------------------------
"Smart Contracts" are custom-scriptable agreements that multiple parties
can sign and then activate on an OT server. Using a simple script
language, you (or your lawyer) can design your own agreements and then
OT will bring your scripted clauses to life!
--------------------------------------------
Demo: TWO-WAY TRADE (3 videos)
For my first demo, I've chosen "two-way trade" because it seems like the
simplest possible example.
Basically, Alice and Bob want to trade some "gold" for "bitcoins" (any
two asset types.) Neither one of them wants to "go first" and risk
sending their half of the money--they prefer to be GUARANTEED that the
other party will reciprocate, before paying.
Therefore, the "two-way trade" smart contract insures that it has safely
obtained all the money from BOTH parties, before switching ownership
over to the new recipients!
---------------------------------------------
Coming soon: "Escrow" smart contract.
This version introduces a 3rd party arbiter (Judge Judy), for cases
where Alice is paying Bob for some PHYSICAL ITEM that he's sent her in
the snail-mail.
In the event of any dispute, it's up to Judy to adjudicate and make a
final decision!
-FT
P.S. Your donations go to help fund the test GUI development.
BTC: 1NtTPVVjDsUfDWybS4BwvHpG2pdS9RnYyQ
(Then you can have smart contracts in the GUI instead of command-line only.)
P.P.S. As I said before, I have a special announcement coming up soon,
so keep your eyes peeled!
Nice !
I've got another video posted! (Basket currencies GUI.)
Actually, *THREE* new videos (total of SEVEN posted in the past week):
http://open-transactions-tv.github.com
--- #7: Basket currencies (Moneychanger test-GUI)
--- #6: opentxs CLI: Misc tips / tricks
--- #5: opentxs CLI: Writing and depositing a cheque
(The other two videos cover more of the new OT command-line tool,
"opentxs.")
Enjoy!
-Fellow Traveler
P.S. Remember, your donations go to pay our Indian developer who works
on the test GUI. (He's about halfway done with the PAYMENTS screen and
the SMART CONTRACTS screen.)
BTC: 1NtTPVVjDsUfDWybS4BwvHpG2pdS9RnYyQ
P.P.S. Upcoming videos: ESCROW smart contract! (At command line :-( Test
GUI screen coming soon.) Also, TWO-WAY TRADE smart contract (at command
line.) Also, I have a special announcement coming up soon, so keep an eye out!
Actually, *THREE* new videos (total of SEVEN posted in the past week):
http://open-transactions-tv.github.com
--- #7: Basket currencies (Moneychanger test-GUI)
--- #6: opentxs CLI: Misc tips / tricks
--- #5: opentxs CLI: Writing and depositing a cheque
(The other two videos cover more of the new OT command-line tool,
"opentxs.")
Enjoy!
-Fellow Traveler
P.S. Remember, your donations go to pay our Indian developer who works
on the test GUI. (He's about halfway done with the PAYMENTS screen and
the SMART CONTRACTS screen.)
BTC: 1NtTPVVjDsUfDWybS4BwvHpG2pdS9RnYyQ
P.P.S. Upcoming videos: ESCROW smart contract! (At command line :-( Test
GUI screen coming soon.) Also, TWO-WAY TRADE smart contract (at command
line.) Also, I have a special announcement coming up soon, so keep an eye out!
Excellent, usability is very important.
Video number 4 is showing some kind of bug... You withdraw cash to 999,901
You deposit only, 3x 25 value coins, using indexes 1,3,5, but in actuallity it also transfers one of the 1 value coins. Your balance shows up as 999,977, and when you list the purse again it is down to 3x 1 value coins instead of the 4 that were there.
Video number 4 is showing some kind of bug... You withdraw cash to 999,901
You deposit only, 3x 25 value coins, using indexes 1,3,5, but in actuallity it also transfers one of the 1 value coins. Your balance shows up as 999,977, and when you list the purse again it is down to 3x 1 value coins instead of the 4 that were there.
It could be a bug that grabbed an extra token...
Or more likely it's an artifact of editing. (Sometimes you'll see IDs or amounts change, due to editing between clips.) A couple times I had a bug and paused to fix it, then unpaused to keep recording, and edited out the in-between. FYI.
However, if you are able to reproduce any real bugs, please post them here:
https://github.com/FellowTraveler/Open-Transactions/issues?state=open
Excellent, usability is very important.
Video number 4 is showing some kind of bug... You withdraw cash to 999,901
You deposit only, 3x 25 value coins, using indexes 1,3,5, but in actuallity it also transfers one of the 1 value coins. Your balance shows up as 999,977, and when you list the purse again it is down to 3x 1 value coins instead of the 4 that were there.
Video number 4 is showing some kind of bug... You withdraw cash to 999,901
You deposit only, 3x 25 value coins, using indexes 1,3,5, but in actuallity it also transfers one of the 1 value coins. Your balance shows up as 999,977, and when you list the purse again it is down to 3x 1 value coins instead of the 4 that were there.
Nice job bit-hero!
Great work!
Okay, the first 4 videos are posted!
http://open-transactions-tv.github.com/
As I said above, these videos cover:
1. automake, the data folders, intro to the new "opentxs" command-line interface, and the client-side scripting.
2. opentxs CLI: adding server contracts to the wallet, issuing currencies.
3. opentxs CLI: account-to-account transfer, and (server-side) generating a new cash mint.
4. opentxs CLI: withdrawing / depositing cash
---------------------------------
Coming soon (already recorded):
5. opentxs CLI: Write / deposit cheque.
6. opentxs CLI: Misc tricks.
7. "Moneychanger" test GUI: Basket currencies: how to create + exchange in/out.
---------------------------------
Also coming soon (already recorded):
8-10: The "two-way trade" smart contract is demoed, with receipts going to inboxes, etc.
11-13: The "escrow" smart contract, in depth.
---------------------------------
Recording soon: OT API instructional videos.
Fellow Traveler
1NtTPVVjDsUfDWybS4BwvHpG2pdS9RnYyQ
P.S. donations are used to pay our indian programmer for work on test GUI. Two new screens, coming soon: payments GUI screen, and smart contracts GUI screen.
I just wanted to give you guys an update on the Open-Transactions project.
I am aiming OT to become the premier open-source platform for transaction processing, vouchers and financial instruments, market trades, smart contracts, etc, for Bitcoin and other currencies.
The idea is to enable wallet and site developers by providing a standard crypto API for all manner of contracts and financial transactions. (So you can focus on the site you are building, instead of a myriad of lower-level issues.)
As I have posted here previously, I anticipate that Bitcoin is going to continue experiencing a series of embarrassing and destructive site-hacking incidents, until we are able to get a standard, community-scale, secure platform into place.
Over the past 6 months or so, a significant amount of work has gone into bringing Open-Transactions to the next level, and making it more accessible...
Specifically:
1. We have listened to your concerns regarding complexity of the OT-API, and have responded. A high-level API has been created, which wraps the lower-level API. Most OT transactions can now be accomplished in as little as 1-3 lines of code. (The Java test GUI, Moneychanger, has also been updated to use this high-level API, so sample code is available in Java for all use cases.) We continue to support developers on the IRC channel and the mailing list, and the API page has also been updated.
2. A full client-side scripting engine has been incorporated, so you can write "UNIX-style" OT scripts. The full high-level and low-level OT APIs are both available from inside your scripts.
3. A new command-line client ("opentxs") has been written in OT SCRIPT, with simple, accompanying script sample code for all of the OT use cases. (BTW we are currently using the excellent ChaiScript: http://www.chaiscript.com/ but also OT is designed to easily swap in any other language you prefer.)
4. Automake has now been added to OT, and Windows builds are also starting to become available via da2ce7.
I have just recorded a series of new videos, which I will be releasing over the next few couple of weeks.
(I will post links here, and to the OT wiki: http://github.com/FellowTraveler/Open-Transactions/wiki )
On the upcoming videos:
Video 1: (Intro.) The new "opentxs" command-line interface, the OT data folders, and the OT script environment.
Video 2: "opentxs" CLI: Adding server contracts to the wallet, issuing assets, creating nyms, creating asset accounts.
Video 3: "opentxs" CLI: Sending account-to-account transfer, receiving pending transfers in the inbox, creating the cash mint.
Video 4: "opentxs" CLI: Withdrawing and depositing cash, and displaying contents of the cash purse.
Video 5: "opentxs" CLI: Writing and depositing cheques.
Video 6: "opentxs" CLI: Misc: refresh, verifyreceipt, getcontract, encode/decode, encrypt/decrypt, etc.
Video 7: "Moneychanger" test GUI: Creating basket currencies, and exchanging in/out of basket currencies.
Video 8: "opentxs" CLI: Smart contracts. I have two working smart contracts I demo, two-way-exchange, which allows users to directly cross-exchange assets of dissimilar asset types.
Video 9: "opentxs" CLI: We also have a working escrow smart contract,which allows Alice to send money to Bob on a (say) 30-day delay (for example if he is shipping her a guitar as an e-bay sale.) The money is stashed safely inside the contract, and goes to Bob automatically in 30 days, unless Alice files a dispute--which then automatically notices the parties to request feedback, and then notices a third-party arbiter, who has X days to examine the terms and feedback before rendering a judgment. (The dispute/judgment process being nothing more than scripted clauses on the smart contract.) All three parties must be original signers to the agreement.
Video 10: The high-level OT API. At least one video on programming to the OT API, just to demonstrate just how easy it has become
(There are also 2 older videos already posted to the OT wiki a few months back, which demo the Moneychanger test GUI.)
------------------------------------------------------------------------------------
A NOTE on PASSWORD SECURITY, and KEY MANAGEMENT
I have done a significant amount of work in the past couple months upgrading the OT password-management capabilities. I thought I would update you guys on our work, because spreading this sort of knowledge is good for the entire Bitcoin community.
First of all, when passwords are used in OT they are destroyed as soon as the transaction is finished, and in the meantime they are stored exclusively in a class intended for that purpose, OTPassword. This class is careful to zero its memory upon destruction, and employs certain tricks in code to insure said zeroing doesn't get removed by the optimizer. OTPassword also takes pains to lock its internal memory (so it won't swap to disk, or at least is much less likely to do so.) I also added code to OT to try and prevent it from core dumping, for the same reason. These are the same sorts of tricks employed by ssh-agent and similar software, to protect secrets in RAM when in use by the application.
Next, the passphrase is put through a key-derivation algorithm, in order to generate a "derived key." This is because we never want to store the user's actual passphrase, even just in RAM. Converting it to a derived key gives us something we can use while processing a transaction, without having to store the user's actual passphrase. Why do we use a key derivation algorithm instead of a hash? (Answer: because hashes are designed to run quickly, whereas key derivation algorithms are designed to run slowly.)
Next, the derived key is used to unlock the master key, which is just a random number and which is used as the "passphrase" for all of the private keys (the nyms) in the wallet. The classes OTSymmetricKey and OTMasterKey have been added recently, and also OTEnvelope has been updated to support symmetric keys, in addition to lists of nyms. This way you can have a single "master key" for all of the nyms in your wallet.
The master key is stored in RAM (inside an OTPassword object) until a timeout. For example, if you set your master key to timeout after 300 seconds (5 minutes) then OT will keep the master key open internally for 5 minutes, and use that instead of asking you to re-type your passphrase--until the 5 minutes are up. After that, the master key will expire and you will be forced to enter your passphrase again in order to unlock it and use any of your private nyms. (This is just like the functionality you probably already have on your system keychain.)
Speaking of the system keychain, the OTKeyring class has been added with support for the gnome-keyring, the Mac Keychain, the KDE kwallet, and Windows DPAPI (these are all protected-memory APIs.) I am hoping that this sort of tie-in can open up OT to alternative authentication methods such as smartcards and usb tokens (and keep that stuff localized to existing, standard APIs outside of OT.)
The OT server doesn't store any passwords, since all OT messages are signed. Neither does the client store any, and its private keys are kept in encrypted form on disk. No secret-splitting, yet, but it's coming someday.
All right, that's it for now. Keep an eye open for the new videos, I'll be posting them soon!
-Fellow Traveler
1NtTPVVjDsUfDWybS4BwvHpG2pdS9RnYyQ
I am aiming OT to become the premier open-source platform for transaction processing, vouchers and financial instruments, market trades, smart contracts, etc, for Bitcoin and other currencies.
The idea is to enable wallet and site developers by providing a standard crypto API for all manner of contracts and financial transactions. (So you can focus on the site you are building, instead of a myriad of lower-level issues.)
As I have posted here previously, I anticipate that Bitcoin is going to continue experiencing a series of embarrassing and destructive site-hacking incidents, until we are able to get a standard, community-scale, secure platform into place.
Over the past 6 months or so, a significant amount of work has gone into bringing Open-Transactions to the next level, and making it more accessible...
Specifically:
1. We have listened to your concerns regarding complexity of the OT-API, and have responded. A high-level API has been created, which wraps the lower-level API. Most OT transactions can now be accomplished in as little as 1-3 lines of code. (The Java test GUI, Moneychanger, has also been updated to use this high-level API, so sample code is available in Java for all use cases.) We continue to support developers on the IRC channel and the mailing list, and the API page has also been updated.
2. A full client-side scripting engine has been incorporated, so you can write "UNIX-style" OT scripts. The full high-level and low-level OT APIs are both available from inside your scripts.
3. A new command-line client ("opentxs") has been written in OT SCRIPT, with simple, accompanying script sample code for all of the OT use cases. (BTW we are currently using the excellent ChaiScript: http://www.chaiscript.com/ but also OT is designed to easily swap in any other language you prefer.)
4. Automake has now been added to OT, and Windows builds are also starting to become available via da2ce7.
I have just recorded a series of new videos, which I will be releasing over the next few couple of weeks.
(I will post links here, and to the OT wiki: http://github.com/FellowTraveler/Open-Transactions/wiki )
On the upcoming videos:
Video 1: (Intro.) The new "opentxs" command-line interface, the OT data folders, and the OT script environment.
Video 2: "opentxs" CLI: Adding server contracts to the wallet, issuing assets, creating nyms, creating asset accounts.
Video 3: "opentxs" CLI: Sending account-to-account transfer, receiving pending transfers in the inbox, creating the cash mint.
Video 4: "opentxs" CLI: Withdrawing and depositing cash, and displaying contents of the cash purse.
Video 5: "opentxs" CLI: Writing and depositing cheques.
Video 6: "opentxs" CLI: Misc: refresh, verifyreceipt, getcontract, encode/decode, encrypt/decrypt, etc.
Video 7: "Moneychanger" test GUI: Creating basket currencies, and exchanging in/out of basket currencies.
Video 8: "opentxs" CLI: Smart contracts. I have two working smart contracts I demo, two-way-exchange, which allows users to directly cross-exchange assets of dissimilar asset types.
Video 9: "opentxs" CLI: We also have a working escrow smart contract,which allows Alice to send money to Bob on a (say) 30-day delay (for example if he is shipping her a guitar as an e-bay sale.) The money is stashed safely inside the contract, and goes to Bob automatically in 30 days, unless Alice files a dispute--which then automatically notices the parties to request feedback, and then notices a third-party arbiter, who has X days to examine the terms and feedback before rendering a judgment. (The dispute/judgment process being nothing more than scripted clauses on the smart contract.) All three parties must be original signers to the agreement.
Video 10: The high-level OT API. At least one video on programming to the OT API, just to demonstrate just how easy it has become
(There are also 2 older videos already posted to the OT wiki a few months back, which demo the Moneychanger test GUI.)
------------------------------------------------------------------------------------
A NOTE on PASSWORD SECURITY, and KEY MANAGEMENT
I have done a significant amount of work in the past couple months upgrading the OT password-management capabilities. I thought I would update you guys on our work, because spreading this sort of knowledge is good for the entire Bitcoin community.
First of all, when passwords are used in OT they are destroyed as soon as the transaction is finished, and in the meantime they are stored exclusively in a class intended for that purpose, OTPassword. This class is careful to zero its memory upon destruction, and employs certain tricks in code to insure said zeroing doesn't get removed by the optimizer. OTPassword also takes pains to lock its internal memory (so it won't swap to disk, or at least is much less likely to do so.) I also added code to OT to try and prevent it from core dumping, for the same reason. These are the same sorts of tricks employed by ssh-agent and similar software, to protect secrets in RAM when in use by the application.
Next, the passphrase is put through a key-derivation algorithm, in order to generate a "derived key." This is because we never want to store the user's actual passphrase, even just in RAM. Converting it to a derived key gives us something we can use while processing a transaction, without having to store the user's actual passphrase. Why do we use a key derivation algorithm instead of a hash? (Answer: because hashes are designed to run quickly, whereas key derivation algorithms are designed to run slowly.)
Next, the derived key is used to unlock the master key, which is just a random number and which is used as the "passphrase" for all of the private keys (the nyms) in the wallet. The classes OTSymmetricKey and OTMasterKey have been added recently, and also OTEnvelope has been updated to support symmetric keys, in addition to lists of nyms. This way you can have a single "master key" for all of the nyms in your wallet.
The master key is stored in RAM (inside an OTPassword object) until a timeout. For example, if you set your master key to timeout after 300 seconds (5 minutes) then OT will keep the master key open internally for 5 minutes, and use that instead of asking you to re-type your passphrase--until the 5 minutes are up. After that, the master key will expire and you will be forced to enter your passphrase again in order to unlock it and use any of your private nyms. (This is just like the functionality you probably already have on your system keychain.)
Speaking of the system keychain, the OTKeyring class has been added with support for the gnome-keyring, the Mac Keychain, the KDE kwallet, and Windows DPAPI (these are all protected-memory APIs.) I am hoping that this sort of tie-in can open up OT to alternative authentication methods such as smartcards and usb tokens (and keep that stuff localized to existing, standard APIs outside of OT.)
The OT server doesn't store any passwords, since all OT messages are signed. Neither does the client store any, and its private keys are kept in encrypted form on disk. No secret-splitting, yet, but it's coming someday.
All right, that's it for now. Keep an eye open for the new videos, I'll be posting them soon!
-Fellow Traveler
1NtTPVVjDsUfDWybS4BwvHpG2pdS9RnYyQ
Jump to: