Smart Contracts – Permissions and Grouping Users on the Blockchain

Here's a really minimal example that keeps two lists. When both parties approve the same hash, the document hash (id) is copied to the approved list.

Just a sketch to possibly give you some ideas. Seems to work. No warranty.

pragma solidity ^0.4.6;

contract TwoSigs {

    address public partyA;
    address public partyB;

    struct documentStruct {
        bool approvedByA;
        bool approvedByB;
    }

    // this data is all publicly explorable

    mapping(bytes32 => documentStruct) public documentStructs;
    bytes32[] public documentList; // all
    bytes32[] public approvedDocuments; // approved

    // for event listeners    

    event LogProposedDocument(address proposer, bytes32 docHash);
    event LogApprovedDocument(address approver, bytes32 docHash);

    // constructor needs to know who A & B are

    function TwoSigs(address addressA, address addressB) {
        partyA = addressA;
        partyB = addressB;
    }

    // for convenient iteration over both lists
    function getDocumentsCount() public constant returns(uint docCount) {
        return documentList.length;
    }

    function getApprovedCount() public constant returns(uint apprCount) {
        return approvedDocuments.length;
    }

    // propose / Approve

    function agreeDoc(bytes32 hash) public returns(bool success) {
        if(msg.sender != partyA && msg.sender != partyB) throw; // stranger. abort. 
        if(msg.sender == partyA) documentStructs[hash].approvedByA = true; // could do else. it's A or B.
        if(msg.sender == partyB) documentStructs[hash].approvedByB = true; 

        if(documentStructs[hash].approvedByA == true && documentStructs[hash].approvedByB == true) {
            uint docCount = documentList.push(hash);
            LogApprovedDocument(msg.sender, hash);
        } else {
            uint apprCount = approvedDocuments.push(hash);
            LogProposedDocument(msg.sender, hash);
        }
        return true;
    }

}

This touches several parts of how Ethereum works. I'll try to explain it in an understandable way:

1.) Ethereum has "externally owned accounts" (EOAs) and "contract accounts". EOAs are much like normal bank accounts. They have an address (IBAN) and a balance (in Ether). Essentially, the EOAs owner possesses a public key pair, of which only he knows the private key. The matching public key "is" the EOAs "address" - the "IBAN". Now, only the EOAs owner can transfer Ether (="withdraw or wire money") from that account - by using the private key in the process. In short, EOAs are "directly owned and controlled" by their respective owners. Contract accounts do not "belong" to anyone. They simply exist on their own and store smart contract code. They also have an address etc, but noone possesses the matching private key. Therefore, the comprised smart contract logic controls the contract account. For a better explanation see also: https://github.com/ethereumbook/ethereumbook. Consider buying the book if you work with Ethereum. It is worth every cent!

2.) The scenario you describe could have a smart contract (i.e. contract account, not EOA) that accepts payments from customers (i.e. from EOAs) and then stores a list of who (= which address) payed. In a smart contract, that can be done e.g. via a mapping. The money payed to the smart contract can then be forwarded to the "business owner's" address (EOA).

So all in all, to your questions:

• No, you would have a contract account accepting reservations
• Technically, you can also have a payment via VISA and just store the "receipt" in the chain. Wouldn't advise you to though!!! You can also go and use your own reservation token. I guess paying in Ether is the best approach here. Anyhow: Why are you thinking about implementing this in Ethereum in the first place?
• Your web3.js simply sends transactions to the blockchain. I guess you would have a web-app which allows a customer to make a reservation which is then payed (and recorded) on the Blockchain. Here, the customer would use his wallet (e.g. Metamask) to pay to your account, and your backend would listen to an event telling you that the reservation and payment went through.

3.) Depending on what you want to do exactly, you can also issue a (non-fungible) token for reservations. Customers who want to "buy" a reservation buy a token. See, e.g. https://ethereum.org/en/developers/docs/standards/tokens/erc-721/ for a standard for such a token.

4.) Anyhow, consider the fact that storing personal information on the blockchain is bad practice, as everything is public and cannot be deleted afterwards. A better approach might be one where your customer pays you (e.g. in ether) and you then issue a so-called "verifiable claim" for him, stating that you confirm his reservation and payment. This happens off-chain and only a hash is stored on the blockchain. The general approach is called "Self-Sovereign Identity" (SSI). See systems like "Sovrin" or "uPort" if you want to follow up on this. https://medium.com/uport/erc1056-erc780-an-open-identity-and-claims-protocol-for-ethereum-aef7207bc744

Hope this could help you.