Bitcoin Forum
June 23, 2024, 04:07:22 PM *
News: Voting for pizza day contest
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Which Alt coins implement m-of-n signatures via P2SH?  (Read 861 times)
No_2 (OP)
Hero Member
*****
Offline Offline

Activity: 901
Merit: 1033


BTC: the beginning of stake-based public resources


View Profile
March 20, 2015, 04:04:35 PM
Last edit: March 20, 2015, 06:38:23 PM by No_2
 #1

I'm trying to find a definitive list of Alt coins that implement m-of-n signatures via P2SH.

Does anyone know if such a list exists anywhere?

Does anyone know of any alt currencies which might exist that implement m-of-n for n>=3 via any other means, i.e. extended Multisig?
No_2 (OP)
Hero Member
*****
Offline Offline

Activity: 901
Merit: 1033


BTC: the beginning of stake-based public resources


View Profile
March 25, 2015, 10:47:20 AM
 #2

Bump.
dadon
Legendary
*
Offline Offline

Activity: 1190
Merit: 1002


Pecvniate obedivnt omnia.


View Profile WWW
March 25, 2015, 10:55:52 AM
 #3

Bump.
I could be wrong but i think SDC has something like that.http://www.deepdotweb.com/2015/01/28/shadowcash-zero-knowledge-anonymity/ this explains the system well.
Daedelus
Hero Member
*****
Offline Offline

Activity: 574
Merit: 500



View Profile
March 25, 2015, 12:01:19 PM
 #4

I don't know of a list but the next version on Nxt (NRS 1.5.x) will have Two-phased transactions that I think fits the bill.

Here is the post implementation spec: https://nxtforum.org/general/2-phased-transactions-post-implementation-specification/

Two-Phased Transactions

Two-Phased Transactions is multisig transactions implementation in Nxt but much more powerful.

Simplest example, Alice starts a Two-Phased transaction. In the first stage a transaction is included in a blockchain but it isn’t processed immediately and has the status of ‘pending’. For it to be processed, Bob has to complete the second phase of the transaction by approving it. This has to be done before the deadline set by Alice has elapsed.

Use cases

* Bob approving a transaction of Alice

* Shareholders voting whether to send another 1M Nxt to a marketing service or not

* Nxt whales voting on whether to pay bounty or not

* Multisig wallet protected from a hacker(think about BTER case etc)


Features

* any kind of transaction could be 2-phased

* M-of-N consensus or by-balance consensus or shareholders voting to release transaction

* possible vote threshold setting(e.g. only accounts with 1M+ Nxt or 100+ assets balance could vote)

* whitelist of voters

* blacklist of voters

* transaction could be released only prior to maxHeight


I think it is done a different way to P2SH as that is not planned to be included until version 1.7.x (roughly).
No_2 (OP)
Hero Member
*****
Offline Offline

Activity: 901
Merit: 1033


BTC: the beginning of stake-based public resources


View Profile
March 25, 2015, 12:59:09 PM
 #5

...
I think it is done a different way to P2SH as that is not planned to be included until version 1.7.x (roughly).

Thanks this is very interesting. I take it NXT still supports m-of-n via P2SH?
Daedelus
Hero Member
*****
Offline Offline

Activity: 574
Merit: 500



View Profile
March 31, 2015, 10:06:32 AM
 #6

I've not forgotten about this  Grin Just querying the answer I got.
Daedelus
Hero Member
*****
Offline Offline

Activity: 574
Merit: 500



View Profile
April 01, 2015, 08:38:53 AM
 #7

If P2SH is due out at a later date than two-phased transaction, will Nxt still support support m-of-n via P2SH?

Sure, m-of-n will be easily possible with 1.5.0, P2H isn't needed for that.

I was under the impression P2SH was different to P2H?

No, all is about paying to hash. In bitcoin, P2SH is paying to script hash, but there're no scripts in Nxt.

Ta da. I think I'll need to amend the Nxt Technology Tree Thread, the bit about P2SH in 1.7 seems to be outdated.
Daedelus
Hero Member
*****
Offline Offline

Activity: 574
Merit: 500



View Profile
April 07, 2015, 08:54:55 PM
 #8

Nxt devs have released a testnet version of the next release so the release notes on two phased transactions (phasing) also released:


Phasing.

Phasing API calls:

ApproveTransaction, GetAccountPhasedTransactions,
GetAccountPhasedTransactionCount, GetAssetPhasedTransactions,
GetCurrencyPhasedTransactions, GetPhasingPoll, GetPhasingPolls,
GetPhasingPollVote, GetPhasingPollVotes, GetVoterPhasedTransactions.

A transaction of any type can be phased by adding a phased=true parameter and
an appropriate set of phasing parameters. Phased transactions are accepted in
the blockchain immediately (subject to all usual validations), but are executed
only at finish height, if still valid and if the required quorum has been met.
If not approved, or not valid at finish height, they remain in the blockchain
but are never executed, and any changes they caused to the sender unconfirmed
balance are reversed, except that the fee is not refunded.

In addition to the voting models available in polls, phased transactions can
use a whitelist of accounts (max 10) allowed to vote for the transaction.

It is possible to vote for (approve) up to 10 phased transactions with a single
approval transaction. This transaction will be accepted in the blockchain only
if all phased transactions it is voting for are already in it.

Voting multiple times is allowed but has no effect on vote counting, votes
after the first vote from each account are ignored.

It is also possible to make any transaction phased without needing voting for
approval. This can be used to create transactions with deferred execution.

Pay on reveal secret is supported as a voting model for phased transactions.
When this voting model is used, the phased transaction must include the
hash of a secret chosen by the sender (up to 100 bytes long), and an approval
transaction for it is only accepted if it includes the secret that results in
this hash. It does not matter who the sender of the approval transaction is,
unless a whitelist is also defined. Supported hash functions currently are
sha256, ripemd160, and sha256 followed by ripemd160. The codes to specify them
as parameters are available from the getConstants API.

Finally, it is possible to make a phased transaction that is released or
rejected not on the basis of voting, but based on the presence of other
transactions (linked transactions) in the blockchain at its finish height.
To do that, up to 10 phasingLinkedFullHash transaction hashes can be defined
when creating the phased transaction. Note that this does not create a
dependency between the linked transactions themselves. This feature can be
used to implement atomic execution of transactions of any type, provided the
phased transaction is phasing safe. Transactions already in the blockchain
before the acceptance of the phased transaction can also be linked, as long
as they are not more than 60 days old, or themselves phased transactions.

The deferred execution with no approval needed, pay on reveal secret, and
linked transactions features are currently accessible using the API only, the
UI for them will be completed in a later release.

Similar to voting, the phasing data for phased transaction that finished before
the last trim height is also deleted and only the aggregate approval results
are kept.

The fee for making a transaction phased depends on the voting model selected.
For by-account voting with no minimum balance, or no voting needed, it is 1 NXT
in addition to the regular fee for that particular transaction type. For voting
that depends on voter balances, the additional phasing fee is 20 NXT.

The fee for approving a phased transaction is 1 NXT for each phased
transaction included in the vote.

Full message here: https://nxtforum.org/nrs-releases/nrs-v1-5-0e/ (remember, testnet version only at this stage)
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!