Tag Info

"Multisignature" addresses on Ethereum differ from that of Bitcoin. Though both networks allow for arbitrary complex transactions, the concepts are not intrinsically the same:
In Bitcoin, there are 2 major classes of transactions:
pay to pubkey (addresses starting with "1")
pay to script hash (addresses starting with "3", also known as P2SH)
The former is ...

The wallet exposed a function:
// constructor - just pass on the owner array to the multiowned and
// the limit to daylimit
function initWallet(address[] _owners, uint _required, uint _daylimit) {
initDaylimit(_daylimit);
initMultiowned(_owners, _required);
}
which was in charge of initializing the wallet owners. However, the author forgot to ...

I am not sure if it is still useful for you but surely can help many other people to save time. So please mark as an answer if that was an issue.
This error comes from special comments like this /** */ and has nothing to do with code in your Wallet.sol
Somewhere in the code, and what's most frustrating in unknown file there is a function like this (real ...

Smart contracts expose multiple functions as a public API. In general, to interact with any contract, its ABI (different from API) must be used to properly encode/decode messages to/from a contract. This is true regardless of function or event.
The Mist multisig wallet is based on the code at https://raw.githubusercontent.com/ethereum/dapp-bin/master/wallet/...

Just got in touch with avsa who was kind enough to point me in the correct direction:
[{"constant":false,"inputs":[{"name":"_owner","type":"address"}],"name":"removeOwner","outputs":[],"type":"function"},{"constant":false,"inputs":[{"name":"_addr","type":"address"}],"name":"isOwner","outputs":[{"name":"","type":"bool"}],"type":"function"},{"constant":true,"...

Your multisig wallet is not vulnerable to the Parity multisig hack recently. There is no known vulnerability in the standard Mist multisig wallet.
That said, if your wallet was created prior to June 2016, it may have a different vulnerability discussed here: https://blog.ethereum.org/2016/06/24/security-alert-smart-contract-wallets-created-in-frontier-are-...

The contract code in dapp-bin is outdated.
If you navigate to the repository of the meteor-dapp-wallet you will find the updated Wallet.sol:
//sol Wallet
// Multi-sig, daily-limited account proxy/wallet.
// @authors:
// Gav Wood <g@ethdev.com>
// inheritable "property" contract that enables methods to be protected by requiring the acquiescence of ...

The default wallet contract has a threshold for "high value" transactions that require multiple signatures, whereas "low value" transactions need only a single signature. This value is specified on deployment.

The simplest pooled staking approach would be to have the validation code for an account be a multi-sig verifier instead of a single-sig verifier, ie. it would expect signatures from M of a given set of N public keys (you can make this more efficient using threshold sigs instead of multisig).

I'd start off by saying it might not be possible. You might just have to transfer your funds into a new wallet contract. But if you're looking to try anyway...
Look into this function:
https://github.com/ethereum/meteor-dapp-wallet/blob/master/Wallet.sol#L245
// (re)sets the daily limit. needs many of the owners to confirm. doesn't alter the amount ...

Multisignature in the bitcoin sense would typically mean you need n-of-m private keys to sign a transaction to make it valid. https://en.bitcoin.it/wiki/Multisignature
In the Ethereum sense, Multisignature can mean anything. From the Ethereum Wallet (Mist): "This is a joint wallet controlled by 3 owners. You can send up to 100 ether per day. Any transaction ...

It was fixed on Jul 19, this is the Pull Request.
As stated in their release notes, you need to make sure your parity version is 1.6.10 or above.
Here is a post explaining the exploit, you can check for yourself that now there is a only_uninitialized modifier in the constructor.
Update: As of 11/7/2017, all Parity multi-sig wallets deployed after July ...

The entire Ethereum ecosystem is in the beginning stages. Mistakes are to be expected, but they should of course not be tolerated if it involves large amounts of money.
There are basically two types of vulnerabilities that can allow funds to be stolen:
Programmer mistakes
For example, the re-entrancy vulnerability used to be commonplace. Most DApp ...

You can use your recovery sheet which contains 2 of the 3 required private keys.
Place both private keys into a text file on your computer, open Geth or Parity and import it (or put it directly into the keystore of each client).
Start your favorite client and make sure both wallets are imported, sometimes you have to unlock and re-encrypt them.
And ...

You should use a mapping to store the certificates and two mappings to index by issuers and recipients. Best approach might be both issuers an recipients are Ethereum addresses.
struct cert {
uint256 certId;
address issuerAddress;
address recipientAddress;
string certContent;
timestamp issuingDate;
}
mapping (uint256 => cert) ...

Recently I worked on universal Solidity smart contract for multi-signature: https://github.com/bitclave/Multiownable
You can easily ship multi-signatire functionality to any smart contract by subclassing from Multiownable and adding onlyManyOwners modifier to methods you want to protect. This is an example of simplest multisig wallet you may imagine:
...

Summary
Your comparison will never work.
The compiled code at 0x01861C6Dfab20bAe0FA4EE698912630697D78cE4 is way too small to represent the compiled wallet.sol source code.
Why do you think the contract code at the address 0x01861C6Dfab20bAe0FA4EE698912630697D78cE4 is the wallet.sol compiled code?
Details
Compiled Code At Address ...

Since light protocole is not released, you won't have any direct mean to call a contract from a mobile phone app.
You can still find (I can't find one, Syng.io is over and I don't know what Syng.im will be) or create an app that connects to a node using RPC api, but you'll have to trust a node.
You could also create a contract that you can trigger only by ...

AFAIK there is no native multisig address mechanism in Ethereum. Multisig in Ethereum terms is a simple smart contract that checks all necessary signatures and if conditions defined by a contract are met the contract release funds.
Please follow this example to understand how that works.

Using a multisig wallet contract requires that each address that was registered as a co-owner is able to call the wallet contract validate method.
Jaxx only supports ether transfer from an address to another but doesn't support contract method interactions. For now you have to use mist or any software that can interact with contracts as Geth or any other ...

The contract you're looking at is a stub. If you look at the contract's code and select Switch to Opcodes View, you can see it references another contract at 0x273930d21e01ee25e4c219b63259d214872220a2 with source code and abi published.

The easiest way is to call confirm(...) with the the operation value of the ConfirmationNeeded event.
I've created a multisig wallet on my Dev blockchain at address 0xb58Cb29C4689661498986ce80157c899507EDC4b.
I used the following JavaScript code to extract the ConfirmationNeeded event with the operation value:
var walletABIFragment = [{"anonymous":false,"...

Both JS api and RPC methods are possible.
Creating a contract using the web3 JS api:
You only need a running node to connect your web3 and the contract source code.
Then you could have a look at the web3 api wiki and use the Ethereum Wallet Dapp multisig contract source code.
First, compile the source code (using solc is nice or from an RPC call) then ...

This error refers to the bad formatting of Doxygen tags within DocString comments (commonly known as NatSpec Format comments).
If you do not format these tags value correctly, the Solidity compiler " moans " and does not compile (even if the rest of the code is correct unfortunately !).
Solving your problem
NB: Your question is really old and I couldn't ...

You could use an approach similar to the Balance Proofs in Raiden's implementation of state channels. Basically you can have the customer sign a confirmation that only the customer could have possibly signed, and then verify that signature in a Solidity contract.
In your particular example I would approach it like this:
Merchant stores the customer's ...