Bitcoin Forum
May 08, 2024, 04:36:45 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 [14] 15 16 17 18 19 20 21 22 »
261  Economy / Trading Discussion / Proposal for Security Standards for Bitcoin Exchanges on: July 26, 2012, 05:01:03 AM
Someday, enough money will be stolen that the Bitcoin community will consider using public key cryptography that was invented back in the 70s.


Proposal for Security Standards for Bitcoin Exchanges (and any other "centralized" storage of people's money)

Everyone: please add your own security proposals to this thread.  :-)

-- NO passwords should be stored on server OR client side.

-- No client-side passwords should be used on the server side at all (hashed or not.)

-- ALL transaction requests must be digitally signed on the client side.

-- All transaction receipts must be server-signed (and must contain a copy of the original client-signed request.) This prevents the server from forging any of your transactions.

-- Receipt should prove the current balance, and the newest receipt is always the winner in any dispute. (Meaning the receipt IS the account.) This prevents the server from changing your balance without permission.

-- Receipt should also prove which instruments are valid and which transactions have cleared. (Meaning the receipt IS the transaction history.) This prevents any instruments you haven't authorized from impacting your account.

-- All recurring transactions (such as trades processing over time from a specific market offer) should result in a server-signed receipt in the user's inbox.

-- All market trades should contain a copy of the user's original signed offer, as well as details on how many trades have processed from the offer.

-- All server requests must contain a request number that increments with each message. This prevents attackers from intercepting messages and sending them again.

-- All server requests must contain the server ID that the message is intended for. This prevents attackers from intercepting messages and sending them to other servers.

-- All transactions must contain a transaction number that was previously issued (and signed for). These numbers must be listed on every receipt until signed as closed. (Server can prove entire transaction history without having to store it.)

-- All transactions must contain a signed balance agreement. All incoming receipts must be verifiable against the last signed balance agreement.

-- All source code must be publicly available for audit.

-- All source code must be subjected to an automated code scanner. (Static AND dynamic analysis.)

-- All Bitcoins must be bailed into a system such that individual servers cannot steal bitcoins from their own users, or be hacked and have hackers steal bitcoins from their users. (This is technically possible in Bitcoin...)

-- All currencies issued on the server, including Bitcoins, must have reserves that are publicly auditable.

Also preferable:
-- Users should sign all transactions on a crypto-card.
-- An additional authentication layer should be provided via crypto-tokens with passwords that change every 90 seconds.

These are the standards I demand for anyone who is going to hold my money.

How about you?



262  Bitcoin / Bitcoin Discussion / Re: Bitcoinica MtGox account compromised on: July 26, 2012, 04:35:21 AM
Nothing makes me feel more safe than the sweet sound of words like, "Javascript in the browser."
263  Bitcoin / Bitcoin Discussion / Re: Open-Transactions VIDEOS... on: July 25, 2012, 05:31:45 PM
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!
264  Economy / Service Announcements / Re: [ANN] Easywallet.org - web based wallet, iPhone/Android clients with QR Codes on: July 23, 2012, 10:30:04 AM
Make sure your "salted hashed" passwords or IDs are produced using a key derivation algorithm, and not a conventional hashing algorithm.

Conventional hashing is designed to run quickly, but key derivation is designed to run slowly.
 
265  Bitcoin / Bitcoin Discussion / Re: Hocnet: A competitively decentralized internet using Bitcoins on: July 23, 2012, 03:38:47 AM
A mesh nework of trust assigned nodes sounds really backwards.
Imho the way to go is for no node to trust other nodes. As for routing just depend on capacity, relay times etc.

Correct: a node will start out not trusting any other nodes. Therefore it will not be willing to relay packets unless it receives payment for doing so.
And the more it is able to trust any given node to provide that payment, the more packets it will be able to relay before demanding it.
If the protocol is not designed to handle this, then the network will suffer from a "tragedy of the commons" when it could instead be growing like an organism (once digital cash is used to solve issues of resource allocation.)
266  Bitcoin / Bitcoin Discussion / Re: Hocnet: A competitively decentralized internet using Bitcoins on: July 22, 2012, 11:55:35 PM
--- A decentralized mesh network is a "holy grail" of freedom and an important goal to work towards.

--- Such a network is subject to a "tragedy of the commons" and will fail, until digital cash is used to solve issues of resource allocation. (Mojo Nation would have succeeded here, if they had used Bitcoin for the currency instead of Beenz/Flooz. You haven't actually tried a digital cash solution, unless you actually used real digital cash.)

--- Once digital cash is used to solve issues of resource allocation, then wireless mesh routers will start popping up all over the place, like mushrooms, the same as ATMs do today.

--- The solution is for any Node to relay packets for other nodes UP TO A LIMIT, based on a trust value it assigns to each other node.

--- When a node has earned more trust, then other nodes will forward more packets to it, before reaching their limit and demanding payment. (Whereas nodes with less trust, will have to pay more often.)

--- When the limit is reached, payment should be settled using a transaction server such as Open-Transactions.  (http://open-transactions-tv.github.com/) These servers can run anonymously, for a profit.

--- Once voting pools are added to OT (allowing Bitcoin reserves to be stored safely on the blockchain as multisig transactions, so hackers and transaction servers cannot steal them) then Bitcoins can be used to exchange onto/off-of the transaction servers, and to convert into any other asset type (on markets, on those same transaction servers.)

--- Network nodes should be able to demand payment in any currency type they wish, and should be able to pay for whatever resources they need, all at the protocol level.

When this is set up, the network will grow like an organism.

Again: trust units, eventually settled up on transaction servers, eventually settled up in Bitcoin and other currencies. Bitcoin is an essential part of the protocol, since it enables transaction servers to operate anonymously at a profit, but should not be used directly for the microtransactions themselves, since that is infeasible on the blockchain.
267  Bitcoin / Bitcoin Discussion / Re: Open-Transactions update... on: July 22, 2012, 01:00:28 PM
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!
268  Bitcoin / Bitcoin Discussion / Re: Open-Transactions update... on: July 17, 2012, 11:57:33 PM
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.

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
269  Bitcoin / Bitcoin Discussion / Re: Open-Transactions update... on: July 17, 2012, 11:57:09 AM

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.
270  Bitcoin / Project Development / Re: [Private Alpha] Open Transactions server on: July 16, 2012, 12:31:45 PM
Wake me when there's a web interface.

I'm waiting for the movie.


re: the movie. As knotwork said, videos have been posted already. Links are also on the OT Wiki (main page.)

FYI: New videos have already been recorded. I am about to post 10 more + and recording a few more tonight.
----------------------------------------------------------------------

re: the web interface. There are only two ways you are going to have a web interface on OT....

1. You trust the web server operator to manage your private keys. (See previous incidents:
Bitcoinica, MyBitcoin, MtGox, etc.) Not only that, but you trust that the code is perfect, with no cross-
site scripting, no buffer overflows, no sql injection, etc being possible. You also trust hackers not to
get in. You also trust the day-to-day security practices of your web site operator, as well as any of
their employees who might have access to your private key, with which your money is ultimately controlled.

I don't know why people prefer this so much but I do understand the market need for a web interface.
I will be happy to work on this project also, but it will need to be a commercial project or otherwise
funded. How much free work do you expect from me? Roll up your sleeves!

2. My preference: Make a commercial-quality client which operates as a systray icon, having only a menu
as its interface (and some dialogs.) Then make lightweight plugins for Chrome, Firefox, i2p, Skype,
Retroshare, AppScale, OpenStack, Magneto, Joomla, etc. This is the most secure way to do it, and also
gives the widest range of integration at the cheapest maintenance cost.


What I'd do, for those preferring ( 1 ) over ( 2 ), is just have a green button on the UI that says something
like, "Click here to download the installed version or Mobile app. It's more secure!" And migrate people over.
And make sure installable versions are available for all platforms.

------

Once people are storing their wallets on their mobile devices, these devices are going to start getting hacked.

We need mobile devices that use smart cards or usb keys, where we can run the OT engine / Bitcoin engine
(any crypto) outside of the device itself. Preferably also where we are using Serval protocol for voice and
CJDNS for data, and Mesh networks--these sorts of things, not centralized providers. And digital cash is
necessary to solve issues of resource allocation that will arise.

What is a good device we can buy now, and use as a normal phone, that we can later upgrade the software on
and it will function as described above?





271  Alternate cryptocurrencies / Altcoin Discussion / Re: AdCoin on: July 14, 2012, 11:31:41 AM
Open Transactions is certainly interesting. How do you prevent someone from just creating more coins though ?

I love good questions.

This is actually two questions, however:

1. How do you prevent the issuer from just creating more coins?
2. How do you prevent a transaction server from just creating more coins?



1. How do you prevent the issuer from just creating more coins?

The issuer can create as many coins as he wants: he is the issuer. Presumably he has an adequate supply of real-world gold/bitcoins/etc in his possession, in order to redeem the units he issues according to the terms of the contract he used to issue them.

One thing the issuer cannot do is issue coins without signing for them in the process. The receipts are unforgeable. But the rest from there (enforcement, storage and auditing of physical gold, etc) is more a governance issue than a technical one. It's between you and the issuer, and the jurisdiction.

With Bitcoin there is a great solution possible, which I have been discussing here for months now: Use multisig transactions (ON the blockchain itself) to enable the storage of Bitcoins in voting pools. This way, no single issuer or transaction server has the ability the move funds out of the pool until the other pool members have taken a vote. (For example, if MyBitcoin had been storing their reserves in a blockchain pool, then everyone would have been able to recover their funds, when the site disappeared, instead of losing their money...)

A fitting solution that the Bitcoin "issuer" on any OT server should actually be a pool of voters on the Blockchain. I can't wait to implement this protocol.


2. How do you prevent a transaction server from just creating more coins?

A transaction server (issuers can release units of their currency onto multiple servers) is already unable to forge a receipt in a transaction with you or any other legitimate user. This is because the user must form the receipt first, and sign it, and only then does the server verify and countersign. The server will reject your transaction if your receipt is false, and the server cannot change or fake the receipt later, because the server cannot forge your signature.

Here is the weakness: the server can create a "dummy account" and sign a false receipt for it (collusion between server and account) and thus create units in that account which could later be spent into the general population. However, it is impossible to spend such units without having them show up on an audit. Therefore there must be an auditing protocol between the transaction server and the issuer to insure the total number of units in circulation is the same as the number on the issuer's last signed receipt.

If you combine an auditing protocol, with OT's unforgeable receipts, and Bitcoin voting pools, it makes it possible to run "low trust transaction servers" for Bitcoin on OT -- which could even operate anonymously! And provide Bitcoin-backed markets and exchanges, Bitcoin-backed untraceable cash, Bitcoin-backed scriptable smart contracts, etc where the users can feel safer knowing that the server will be unable to steal their coins.


272  Bitcoin / Bitcoin Discussion / Open-Transactions VIDEOS... (Automated Escrow!!) on: July 13, 2012, 11:56:56 AM
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







273  Bitcoin / Project Development / Re: RFC -- Distributed Bitcoin Stock Exchange (DBSE) on: July 11, 2012, 12:48:27 AM
I think OT is currently the more [snip]. But Ripple will be better. What will it miss that OT has (for decentralized trading of crypto-assets)?

When will people understand...

It's not OT or Ripple. It's OT and Ripple.

It's not Bitcoin or gold. It's Bitcoin and gold.

It's not either/or -- the future that is coming, is a combination of all of these things.
274  Bitcoin / Bitcoin Discussion / Re: Bitcoin for kids on: July 02, 2012, 08:33:52 AM
I thought of open transactions (and maybe I'll still look into), but I really want something very simple that works very much like a typical Bitcoin client works (with similar a addressing scheme, etc).

CREATE ASSET ACCOUNT -- SOURCE CODE
Code:
   def OT_ME::create_asset_acct(SERVER_ID, NYM_ID, ASSET_TYPE_ID) 
    {
        var ot_Msg := OTAPI_Func()
        // -------------------------
        var theRequest := OTAPI_Func(ot_Msg.CREATE_ASSET_ACCT, SERVER_ID, NYM_ID, ASSET_TYPE_ID)
        var     strResponse = theRequest.SendRequest(theRequest, "CREATE_ASSET_ACCT")
        
        return strResponse
    }
------------------------------------------------------------------------------------------

SHOW ACCOUNT BALANCE:

~/Projects/Open-Transactions/include
> opentxs balance

Welcome to Open Transactions -- version 0.82.h
PLEASE SIGN YOUR PASSPHRASE:

    Balance: 1211
eMldMMiKfJRO8B8yJjzcezs9xvSt7dkdlWt50e8CDxn   (FT's Silver)

------------------------------------------------------------------------------------------

SOURCE CODE for "balance" command, using OT API:

Code:
def details_account_balance(strID)
{
    var strName          = OT_API_GetAccountWallet_Name(strID)
    var strBalance       = OT_API_GetAccountWallet_Balance(strID)
    
    OT_API_Output(0, "\n    Balance: ") //stderr
    print(strBalance) // stdout
    OT_API_Output(0, strID + "   (" + strName + ")\n\n") //stderr
}
------------------------------------------------------------------------------------------

SHOW CASH PURSE (on local client):

~/Projects/Open-Transactions/include
> opentxs showpurse

Welcome to Open Transactions -- version 0.82.h
PLEASE SIGN YOUR PASSPHRASE:

Total value: 1
Token count: 1

Index   Value   Series   ValidFrom      ValidTo      Status
0         1      0      1339606926   1355158926      valid


------------------------------------------------------------------------------------------

WITHDRAW CASH:

~/Projects/Open-Transactions/include
> opentxs withdraw

Welcome to Open Transactions -- version 0.82.h
PLEASE SIGN YOUR PASSPHRASE:

Enter the amount as integer[1]: 109

Server response (withdraw_cash): SUCCESS withdrawing cash! (From account on server, to local purse.)
Success retrieving intermediary files for account.


------------------------------------------------------------------------------------------

SOURCE CODE for withdraw cash:

Code:
    var madeEasy	= OT_ME()

    var strResponse = madeEasy.withdraw_cash(Server, strMyNymID, MyAcct, strAmount)
    var strAttempt  = "withdraw_cash"
    // ***************************************************************
    
    // Interpret the server's reply...
    
    var nInterpretReply = InterpretTransactionMsgReply(Server, strMyNymID, MyAcct, strAttempt, strResponse)
    
    if (1 == nInterpretReply)
    {    
        // Download all the intermediary files (account balance, inbox, outbox, etc)
        // since they have probably changed from this operation.
        //
        var bRetrieved = madeEasy.retrieve_account(Server, strMyNymID, MyAcct) //bForceDownload defaults to false.
        
        OT_API_Output(0, "\n\nServer response ("+strAttempt+"): SUCCESS withdrawing cash! (From account on server to local purse.) \n")
        OT_API_Output(0, (bRetrieved ? "Success" : "Failed") + " retrieving intermediary files for account.\n")
    }

------------------------------------------------------------------------------------------

VIEW (UPDATED) BALANCE:

~/Projects/Open-Transactions/include
> opentxs balance

Welcome to Open Transactions -- version 0.82.h
PLEASE SIGN YOUR PASSPHRASE:

    Balance: 1102
eMldMMiKfJRO8B8yJjzcezs9xvSt7dkdlWt50e8CDxn   (FT's Silver)

------------------------------------------------------------------------------------------

VIEW UPDATED PURSE (on local client):

~/Projects/Open-Transactions/include
> opentxs showpurse

Welcome to Open Transactions -- version 0.82.h
PLEASE SIGN YOUR PASSPHRASE:

Total value: 110
Token count: 7

Index   Value   Series   ValidFrom   ValidTo   Status
0      1      0   1339606926   1355158926      valid
1      100      0   1339606926   1355158926      valid
2      1      0   1339606926   1355158926      valid
3      5      0   1339606926   1355158926      valid
4      1      0   1339606926   1355158926      valid
5      1      0   1339606926   1355158926      valid
6      1      0   1339606926   1355158926      valid


~/Projects/Open-Transactions/include
>

------------------------------------------------------------------------------------------

SOURCE CODE for "show purse":

Code:
            var strAmount = OT_API_Purse_GetTotalValue(Server, MyPurse, strPurse)
            print("\n\nTotal value: " + strAmount)
            
            // Loop through purse contents and display tokens.
            var nCount =  OT_API_Purse_Count(Server, MyPurse, strPurse)
            // ----------------------
            if (nCount > 0)
            {
                print("Token count: " + nCount.to_string() + "\n")
                print("Index\tValue\tSeries\tValidFrom\tValidTo\t\tStatus")

                var nIndex = -1
                
                while (nCount > 0)
                {
                    --nCount
                    ++nIndex  // on first iteration, this is now 0.
                    // -------------------
                    var strToken = OT_API_Purse_Peek(Server, MyPurse, MyNym, strPurse)
                    var strNewPurse = OT_API_Purse_Pop(Server, MyPurse, MyNym, strPurse)                    
                    strPurse = strNewPurse
                    // ------------------------------------------
                    var strDenomination = OT_API_Token_GetDenomination(Server, MyPurse, strToken)
                    var nSeries         = OT_API_Token_GetSeries      (Server, MyPurse, strToken)
                    var strValidFrom    = OT_API_Token_GetValidFrom   (Server, MyPurse, strToken)
                    var strValidTo      = OT_API_Token_GetValidTo     (Server, MyPurse, strToken)
                    var strTime         = OT_API_GetTime()
                    // ------------------------------------------
                    // Output the token...
                    
                    var strStatus = (strTime.to_int() > strValidTo.to_int()) ? "expired" : "valid"
                    
                    print(nIndex.to_string() + "\t" + strDenomination + "\t" + nSeries.to_string() + "\t" + strValidFrom + "\t" + strValidTo + "\t" + strStatus)
                    // ------------------------------------------
                } // while
            } // if nCount > 0


More examples here:  https://github.com/FellowTraveler/Open-Transactions/wiki/Use-Cases

Support available.

Full examples for using the high-level API are also available in Java (in the Moneychanger test GUI),
as well as in the new opentxs high-level command-line interface (which itself is actually written in OT script):

Code:

> opentxs help

Welcome to Open Transactions -- version 0.82.h

PLEASE SIGN YOUR PASSPHRASE:
From command-line-opt.ot (defaults):
Using as server: tBy5mL14qSQXCJK7Uz3WlTOKRP9M0JZksA3Eg7EnnQ1
Using as mynym: T1Q3wZWgeTUoaUvn9m1lzIK5tn5wITlzxzrGNI8qtaV
Using as myacct: eMldMMiKfJRO8B8yJjzcezs9xvSt7dkdlWt50e8CDxn
Using as hisacct: iT4nJZbqlT8EPd4ZjWKsA9YxsAboO334sCJ0oYdgh1G
Using as 'his' nym: SP8rPHc6GMRPL517UL5J8RK2yOiToyVqMaj3PUHvLzM


Commands:

acceptall accept all receipts in myacct's inbox.
activate activate a smart contract or payment plan.
addsignature add a signature to a contract without releasing others.
balance display balance for a specific account.
canceloffer cancel a still-running, recurring market offer.
cancelplan cancel a still-running, recurring payment plan.
checknym download a nym's public key based on his ID.
cheque write a cheque.
confirm confirm your agreement to a smart contract or payment plan.
decode OT-base64-decode out of armor.
decrypt decrypt ciphertext using nym's private key.
delmail delete an in-mail item.
deloutmail delete an out-mail item.
deposit deposit cash, cheque, voucher, or tokens.
discard discard/cancel a not-yet-cashed, outgoing instrument.
encode OT-base64-encode into armor.
encrypt encrypt plaintext to a nym's public key.
exchange exchange in/out of a basket currency.
getcontract download an asset or server contract by its ID.
inbox display inbox of a particular account.
issueasset issue a currency contract onto an OT server.
mail display in-mail for a particular nym.
newacct create a new asset account.
newasset create a new asset contract.
newbasket create a new basket currency.
newkey create a new symmetric key.
newnym create a new nym.
newoffer create a new market offer.
newserver create a new server contract.
outbox display outbox of a particular account.
outmail display out-mail for a particular nym.
outpayments display contents of outgoing payments box.
pass_decrypt password-decrypt a ciphertext using a symmetric key.
pass_encrypt password-encrypt a plaintext using a symmetric key.
payments display contents of incoming payments box.
records display contents of record box.
refresh download latest intermediary files for myacct.
refreshnym download latest intermediary files for mynym.
register register a nym onto an OT server.
sendmsg send a message to another nym's in-mail.
showacct show account stats for a single account.
showbaskets show basket currencies issued on a particular server.
showmint show a mint file for specific asset ID. Download if necessary.
showmyoffers show mynym's offers on a particular server and market.
showoffers show all offers on a particular server and market.
showpurse show contents of cash purse.
sign sign a contract, releasing all other signatures first.
stat display wallet contents.
transfer send a transfer from myacct to hisacct.
trigger trigger a clause on a running smart contract.
verifyreceipt verify your intermediary files against the last signed receipt.
verifysig verify a signature on a contract.
voucher withdraw a voucher (cashier's cheque).
withdraw withdraw cash. (From acct on server into local purse.)

275  Alternate cryptocurrencies / Altcoin Discussion / Re: Timekoin on: June 29, 2012, 09:12:41 AM
"No offense, but a trained monkey could write an OT client."

The description of open transactions is not easy to understand.  Can grandma run open transactions gui client or server?  No.   Why don't you make a gui client similar to the bitcoin client (that is too complicated too Electrum would be Better)   with automatic setup.

I will remind you that Open-Transactions is a software library, not an end-user application. If you want a grandma-friendly UI, then you will have to write it, not me. The only UI I have provided is a test GUI to go along with the API, which is intended only to make things easier for developers by providing sample code for the complete OT API. Don't confuse that test UI (intended for developers using the API) with the proper UI design necessary for end users!

As for who will write the actual "iPhone app" or "Android app" or "Mac app"--each of these is a full project on its own. I cannot write them all. The truth is, there are many different applications that could be written with OT, not just wallets. But again, I cannot write them all. Certainly the amount of free work I am contributing to the cause, with my current project, is already enough? You cannot possibly ask me to take on additional projects!

Here is a mock GUI

============
Total Quickcoins in circulation fixed at:
Balance Quickcoin:  
send to: ____________ address book
receive from: ____________ address book
============

I don't want to waste braincells to learn what nyms, contracts, baskets, markets, reoccurring, deed/title, escrow, ripple are.  Soon as I saw that goodbye. I want a fixed currency amount that can not be hacked.  I would not even like to see a bitcoin type id but have it hidden, where Id's are actual names.  Hank_Williams:df345r3jtyughn45y654yrhtrthrth

Yes, the mock GUI that you propose could easily be implemented using the OT API. Using the sample code above, and other samples I have provided on my "Use Cases" page, you should have no problem doing so. The whole point of OT was to enable you to do so. There is no reason to tell Grandma of contracts, basket currencies, markets, or nyms -- that is a user interface design issue specific to your GUI. I encourage you to take another look at the above sample code and ask yourself if it's really that hard to understand. Also take a look at the samples on the Use Cases page ( https://github.com/FellowTraveler/Open-Transactions/wiki/Use-Cases ) and ask yourself honestly if it's really so complicated to make a GUI like one you describe, using that API.

You might be surprised.
276  Alternate cryptocurrencies / Altcoin Discussion / Re: Timekoin on: June 28, 2012, 10:59:43 AM
I don't know how open transactions works, but I don't like how complicated it is.  Seems there are contracts to do this and that, and we want is a coin.  If you had a lot of 5 and 10 coins it would save space too.

Complicated??

------------------------------------------------------------------------------------------

SHOW ACCOUNT BALANCE (on server):

~/Projects/Open-Transactions/include
> opentxs balance

Welcome to Open Transactions -- version 0.82.h
PLEASE SIGN YOUR PASSPHRASE:

    Balance: 1211
eMldMMiKfJRO8B8yJjzcezs9xvSt7dkdlWt50e8CDxn   (FT's Silver)

------------------------------------------------------------------------------------------

SOURCE CODE for "balance" command, using OT API:

Code:
def details_account_balance(strID)
{
    var strName          = OT_API_GetAccountWallet_Name(strID)
    var strBalance       = OT_API_GetAccountWallet_Balance(strID)
    
    OT_API_Output(0, "\n    Balance: ") //stderr
    print(strBalance) // stdout
    OT_API_Output(0, strID + "   (" + strName + ")\n\n") //stderr
}
------------------------------------------------------------------------------------------

SHOW CASH PURSE (on local client):

~/Projects/Open-Transactions/include
> opentxs showpurse

Welcome to Open Transactions -- version 0.82.h
PLEASE SIGN YOUR PASSPHRASE:

Total value: 1
Token count: 1

Index   Value   Series   ValidFrom      ValidTo      Status
0         1      0      1339606926   1355158926      valid


------------------------------------------------------------------------------------------

WITHDRAW CASH:

~/Projects/Open-Transactions/include
> opentxs withdraw

Welcome to Open Transactions -- version 0.82.h
PLEASE SIGN YOUR PASSPHRASE:

Enter the amount as integer[1]: 109

Server response (withdraw_cash): SUCCESS withdrawing cash! (From account on server, to local purse.)
Success retrieving intermediary files for account.


------------------------------------------------------------------------------------------

SOURCE CODE for withdraw cash:

Code:
    var madeEasy	= OT_ME()

    var strResponse = madeEasy.withdraw_cash(Server, strMyNymID, MyAcct, strAmount)
    var strAttempt  = "withdraw_cash"
    // ***************************************************************
    
    // Interpret the server's reply...
    
    var nInterpretReply = InterpretTransactionMsgReply(Server, strMyNymID, MyAcct, strAttempt, strResponse)
    
    if (1 == nInterpretReply)
    {    
        // Download all the intermediary files (account balance, inbox, outbox, etc)
        // since they have probably changed from this operation.
        //
        var bRetrieved = madeEasy.retrieve_account(Server, strMyNymID, MyAcct) //bForceDownload defaults to false.
        
        OT_API_Output(0, "\n\nServer response ("+strAttempt+"): SUCCESS withdrawing cash! (From account on server to local purse.) \n")
        OT_API_Output(0, (bRetrieved ? "Success" : "Failed") + " retrieving intermediary files for account.\n")
    }

------------------------------------------------------------------------------------------

VIEW (UPDATED) BALANCE (on server):

~/Projects/Open-Transactions/include
> opentxs balance

Welcome to Open Transactions -- version 0.82.h
PLEASE SIGN YOUR PASSPHRASE:

    Balance: 1102
eMldMMiKfJRO8B8yJjzcezs9xvSt7dkdlWt50e8CDxn   (FT's Silver)

------------------------------------------------------------------------------------------

VIEW UPDATED PURSE (on local client):

~/Projects/Open-Transactions/include
> opentxs showpurse

Welcome to Open Transactions -- version 0.82.h
PLEASE SIGN YOUR PASSPHRASE:

Total value: 110
Token count: 7

Index   Value   Series   ValidFrom   ValidTo   Status
0      1      0   1339606926   1355158926      valid
1      100      0   1339606926   1355158926      valid
2      1      0   1339606926   1355158926      valid
3      5      0   1339606926   1355158926      valid
4      1      0   1339606926   1355158926      valid
5      1      0   1339606926   1355158926      valid
6      1      0   1339606926   1355158926      valid


~/Projects/Open-Transactions/include
>

------------------------------------------------------------------------------------------

SOURCE CODE for "show purse":

Code:
            var strAmount = OT_API_Purse_GetTotalValue(Server, MyPurse, strPurse)
            print("\n\nTotal value: " + strAmount)
            
            // Loop through purse contents and display tokens.
            var nCount =  OT_API_Purse_Count(Server, MyPurse, strPurse)
            // ----------------------
            if (nCount > 0)
            {
                print("Token count: " + nCount.to_string() + "\n")
                print("Index\tValue\tSeries\tValidFrom\tValidTo\t\tStatus")

                var nIndex = -1
                
                while (nCount > 0)
                {
                    --nCount
                    ++nIndex  // on first iteration, this is now 0.
                    // -------------------
                    var strToken = OT_API_Purse_Peek(Server, MyPurse, MyNym, strPurse)
                    var strNewPurse = OT_API_Purse_Pop(Server, MyPurse, MyNym, strPurse)                    
                    strPurse = strNewPurse
                    // ------------------------------------------
                    var strDenomination = OT_API_Token_GetDenomination(Server, MyPurse, strToken)
                    var nSeries         = OT_API_Token_GetSeries      (Server, MyPurse, strToken)
                    var strValidFrom    = OT_API_Token_GetValidFrom   (Server, MyPurse, strToken)
                    var strValidTo      = OT_API_Token_GetValidTo     (Server, MyPurse, strToken)
                    var strTime         = OT_API_GetTime()
                    // ------------------------------------------
                    // Output the token...
                    
                    var strStatus = (strTime.to_int() > strValidTo.to_int()) ? "expired" : "valid"
                    
                    print(nIndex.to_string() + "\t" + strDenomination + "\t" + nSeries.to_string() + "\t" + strValidFrom + "\t" + strValidTo + "\t" + strStatus)
                    // ------------------------------------------
                } // while
            } // if nCount > 0


No offense, but a trained monkey could write an OT client.
277  Bitcoin / Development & Technical Discussion / Re: cbitcoin - Bitcoin implementation in C. Currently in development. on: June 06, 2012, 03:45:22 PM
Language fanboy detected.

hey, if i had to write something in C, i would use python.

Fair enough. However, Python was not specifically written as a replacement for C and C++.

D *was* specifically written as a replacement for C and C++.

Therefore, I think you are comparing apples and oranges.

For example, D, like C, would be an appropriate tool for writing a system-level driver.  Python, on the other hand, most likely would NOT be an appropriate tool for such a task.

(Apples and oranges...)


278  Bitcoin / Development & Technical Discussion / Re: cbitcoin - Bitcoin implementation in C. Currently in development. on: June 06, 2012, 03:05:25 PM
If I had to write something in straight-C, I would use the D language.
if i had to use X, i would use something different and unrelated Y.

WTF? the reason for using C is that its simple, small and portable. which i suspect that D is not.

Anyone who writes C programs would do well to research the D language.

Ditto for C++, but for entirely different reasons.

D is the perfect replacement for both (each for different reasons.)

I have programmed C and C++ for over 20 years, everything from controller cards to Windows, to Linux, to Mac, to Android, and FreeBSD. (Do your own research, just giving my opinion. Take it for whatever it's worth.)

-FT




279  Bitcoin / Development & Technical Discussion / Re: cbitcoin - Bitcoin implementation in C. Currently in development. on: June 04, 2012, 02:22:05 PM
If I had to write something in straight-C, I would use the D language.
280  Bitcoin / Project Development / Re: Unofficial Open Transactions and Moneychanger Builds (Updated 24 Apr. 12) on: May 08, 2012, 08:17:46 AM
A hacker trying to impersonate your passphrase dialog will be very unlikely to guess the exact goat picture that you chose for yours, and thus will be unable to trick you into entering your passphrase into an imposter dialog. Without this security precaution, the hacker could make a fake dialog that would look correct to thousands of people.  But WITH this security precaution, the hacker would have to guess the individual password image used by each and every one of those thousands of people (and it's extremely unlikely that he could do that...) When his fake dialog pops up, any near-victim would immediately see that it's the wrong dialog, since it does not feature the unique password image that person chose when he first installed OT.

I hope that clears it up.  I'm sure da2ce7 will contact you soon to help figure out the issue you are having.

What's stopping the hacker's software from reading your settings file for OT and finding out what password picture it uses?

I've seen this technique on yahoo mail before, where the attacker has to put up a fairly generic webpage and doesn't have access to your password picture.  But if the hacker already planted software on your system, I would think it has access to everything it needs to impersonate the dialog.

The OT settings file isn't encrypted yet, but I'm storing the picture file location inside the settings file, so that when the day comes that the settings ARE encrypted, the location will be safe in there as well.

(da2ce7, FYI, this is why the picture path is stored in OT settings instead of generic Java settings...)

As for a compromised system, I agree there's not much you can do about that, except try to practice better security.

I do, however, believe that as a result of that, things are going to have to move towards smart cards.

-FT
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 [14] 15 16 17 18 19 20 21 22 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!