Bitcoin Forum
March 04, 2024, 07:15:05 PM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 »
1  Alternate cryptocurrencies / Speculation (Altcoins) / [KMD] Komodo speculation on: October 24, 2016, 01:23:11 PM
2  Alternate cryptocurrencies / Announcements (Altcoins) / [ANN][KMD][dPoW] Komodo - An Open, Composable Smart Chain Platform, Secured by B on: September 01, 2016, 06:59:27 PM

3  Alternate cryptocurrencies / Altcoin Discussion / 1 BTC bounty for a pure C implementation of zcash miner on: June 23, 2016, 12:34:50 PM
The current zcash miner is in C++, but I want a pure C version. There is already C versions of blake, but not of the main birthday problem as zcash uses

4  Bitcoin / Development & Technical Discussion / Are secp256k1 library questions appropriate here, or doomed to be buried in alts on: June 13, 2016, 07:14:21 PM
I asked a question about schnorr sigs that is in the libsecp256k1 library that is in bitcoin
I have seen other posts about schnorr sigs in the bitcoin technical section
In my experience, alt coin devs dont know anywhere near as much as bitcoin devs

So, I wanted to ask for help in how to use the schnorr sigs here. but it was buried in the altcoins section

Hopefully it is not inappropriate to ask whether I can use a combined pubkey using the combine pubkey function in the mainstream libsecp256k1 library that is in bitcoin, to create a bitcoin transaction for the bitcoin network.

notice this is about bitcoin.

I know I can use the schnorr function to validate a combined signature, but I dont think that would work in a bitcoin script, so I was trying to get a combined signature indirectly that can be verified with the existing bitcoin network
5  Alternate cryptocurrencies / Altcoin Discussion / libsecp256k1 schnorr sigs - how to determine the number of signers on: June 06, 2016, 10:40:19 AM
I have been experimenting with the schnorr combined signatures and I cant figure out how to directly determine the number of signers.

From what I am seeing, the combined pubkey will say any combined pubkey with any subset of signers is valid.

I dont see a clean way to get a specific threshold validation. Is the process to iterate through all the pubkeys from each signer to see which ones validate against the combined signature? Otherwise it seems that some sort of combinatorial explosion of combined pubkey needs to be made to find the exact set of signers.

but I only need the number of signers, not the exact ones, so I am hoping there is a simple way

6  Bitcoin / Development & Technical Discussion / are there any actual stats on chain reorgs, by depth? on: March 18, 2016, 08:12:21 PM
I know the odds for a deep reorg are small, but I was hoping some website is keeping stats on how often the small reorgs are happening. I guess it would be relative to a specific node, unless there is some internal bitcoind stats that can be queried across all peers.

I am assuming that 10 block deep reorg is very rare, but wanted to get statistical confirmation.

It would incur a several minute recalculation cost to have to regenerate the data for all the blocks after the reorg, so dont want to set this at something that happens every day. But no sense to set it so it would be expected to happen once a year.

The shorter the delay, the faster things will work for realtime queries as it minimizes the amount of data that needs to be scanned that is not in the parallel format. Though, now I think about it, maybe I can make a special case for smaller bundle at the end.

Regardless, of the realtime calc speed, I currently delay creation of a bundle until 10 blocks after the last block of that bundle and wanted to know what is the probability that it will need to be regenerated base on real world stats

7  Bitcoin / Development & Technical Discussion / address balances at specific block? on: March 15, 2016, 12:13:36 PM
Does anybody know how to query balances for all addresses as of a specific block?

I would think some sort of query layer on top of insight block explorer?

My use case is that I want to do a brute force verification of all addresses that I have generated with the iguana parallel sync. Now that I have this data, I cant find any easy way to verify it...

8  Bitcoin / Development & Technical Discussion / Segwit details? N + 2*numtxids + numvins > N, segwit uses more space than 2MB HF on: March 15, 2016, 11:20:53 AM
I cant find the changes needed to be made to support segwit.

It must change the protocol and blockchain format, so I would imagine there is some obvious place I overlooked where to find it.

9  Bitcoin / Development & Technical Discussion / SIGHASH precedence for multisig? on: March 02, 2016, 02:25:49 PM
As you know there are several SIGHASH types, each signature has a byte at the end to indicate how it was signed.

I searched, but could not find any definitive explanation of the precedence and how all the various SIGHASH types affect each other.

For most inputs with a single signer, this is a moot issue, though even that doesnt seem to be true as some parts of an input appear to propagate to the entire tx, or its outputs or at least something beyond the apparent scope of the vin that is being signed.

But for a multisig output that is being signed by multiple signers and where the signers are using different SIGHASH types, I think there needs to be a defined way of figuring out what SIGHASH mode is in effect.

A few lines in the official docs leaves a lot to the imagination. Is it even valid for there to be different SIGHASH types in the same vin? Maybe it is just rejected if they dont all match? Or maybe there is an implicit precedence that applies?

10  Bitcoin / Development & Technical Discussion / Using compact indexes instead of hashes as identifiers. on: February 26, 2016, 03:50:34 AM
An implementation idea would be to assume that SIGHASH_ALL is used for all these, it seems that other SIGHASH modes are rarely used and not sure it makes sense to support them for radically new usecases.
Well everything I described there is completely compatible with all scripthash types; so no real need to limit flexibility. Assuming the sighash code is separate and reused, it shouldn't increase implementation complexity.

Also, is there a reason that a unique number be used to identify each txid and even output script (address)? To my thinking, after a block is past any chance of being reorganized, then there is a canonical ordering of all blocks, and therefore all tx and vins and vouts.

Since each spend currently requires the 32byte txid and vout, mapping this to 4 or 6 bytes creates a lot of space savings. There is a lot of redundancy in the blockchain with each txid potentially being duplicated once for each vout.
That could be done-- but there is no need to do so normatively.  E.g. Peers could agree to transmit data using these compressed indexes, while still hashing the original values. This has the advantage of having the IDs not change out from under already authored transactions, and making sure that offline devices don't need access to (or to trust) external index providers.

The other big redundancy are reused addresses, which are actually rmd160 hashes inside spend scripts. Using the canonical ordering of everything, then each rmd160 hash would map to a 32bit index and with the vast majority of scripts being standard a few more bytes can be encoded into a few bits. However, with the coming diaspora of p2sh script proliferation, it could be that address numbering wont be so effective in the future.
This would undermine the privacy/fungibility properties of bitcoin as a whole to incentivize parties to reuse addresses. Bitcoin's privacy strongly depends on non-reuse, and additional pressure against it for the benefit of saving  on the order 12 bytes per txout doesn't sound like a win-- especially as it would be used to justify bad software, bad businesses practices, and bad public policy that force users to reuse.  Access to those indexes would have to be handled quite carefully since if you paid the wrong one the funds would be stolen.

Thanks for your thoughts!
I used to think BTC blockchains' exponential growth was a big problem. Then I realized I could distill it to one quarter the size and also sync in parallel at bandwidth speeds. Now I dont worry about blockchain bloat so much.

I think we have to admit that a large part of the BTC blockchain has been deanonymized. And until new methods like CT are adopted, this will only get worse.

So rather than fight a losing battle, why not accept that there are people that dont care much about privacy and convenience is more important. In fact they might be required to be public. The canonical encoding allows to encode the existing blockchain and future public blockchain at much better than any other method as it ends up as high entropy compressed 32bit numbers, vs 32byte txid + vout. The savings is much more than 12 bytes, it takes only 6 bytes to encode an unspent, so closer to 30 bytes. A lot of bitcoin processing is slow due to a variety of reasons. Being able to do computations via standard integers allows for an order of magnitude faster operations in many cases. I think the usage of a DB is the cause of most of the slowdown. Since the blockchain mostly never changes, there is no need for using ACID compliant DB operations for everything. With my design all nodes are doing txindex=1 and it takes very little time to "rescan" a new privkey as everything already has the tx already in linked lists and hash tables.

The assumption is that each node is maintaining the canonical indexes, otherwise trust is required. With that assumption, this indexing system can be viewed as a highly efficient lossless codec, so not sure why you consider it bad software. I assume you dont consider using gzip a bad practice? I try hard to preserve compatibility with the existing bitcoin core. What I describe does not change the network protocol at all, that is a separate post Smiley

I am not advocating to change the signed tx to be based on 32 bit numbers! All I recommend is to encode them internally (when beyond the practical chance of being reorged) as 32 bits. All nodes will end up with the same numbering. However, all external interactions continue with the fully expanded form, else it wouldnt be compatible at all. All bundles and subsets of bundles would have verifiable hashes and this will create an efficient encoding for permanent archival storage, with arguably isomorphic behavior to the current raw blockchain inside a DB. The tx that are signed and verified are of course using the fully expanded form. However, if you just want to explore the blockchain, nobody really cares about the exact txid, just that funds went from A to B.

These are not just thoughts, but description of a working system that syncs entire blockchain and creates the above data structures in about half hour if you have enough bandwidth and 8 cores. It is bandwidth limited, so for a slow home connection of 20mbps, it takes 6hrs for full sync. I am currently debugging the unspents handling, but the rest is basically working and just needs validation. And this part is derived from MGW which has been in service for a couple years.

I wanted to use the standard bitcoin RPC test suite and I assume what is in the repo is the most complete set? Is there some bruteforce RPC tester that will use large parts of the RPC that can be used as a validation step for new implementation of bitcoin core?

11  Bitcoin / Development & Technical Discussion / sendrawtransaction wire protocol? on: February 24, 2016, 07:40:53 AM
The bitcoin rpc has sendrawtransaction, but at the wire protocol level, there is the "INV", "getdata" and "data" messages.

I couldnt find much documentation on the proper way for a node that doesnt have the networkservices bit set to push a transaction to the network.

From what I am seeing if network services bit is set, then just by sending INV message with the txid, the other nodes will do a getdata message and the transaction can be sent back with the data message.

I am not seeing consistent behavior for a node that is not a relaying node. Is there something special that needs to be done or maybe some detailed docs on how best to do a sendrawtransaction.


P.S. I am writing a full node from scratch, so I cant rely on any local or external bitcoind
12  Alternate cryptocurrencies / Announcements (Altcoins) / Declaration of Independence - Atomic Cross Chain Asset Standard on: February 21, 2016, 11:35:39 PM
Declaration of Independence

We the asset holders hereby declare our independence from any single blockchain.

An open and jointly developed specification on cross chain atomic asset transfers will be developed. Any current or future blockchain is invited to join.

Each blockchain will need to not only promise protections for asset holder interests, they need to live up to them. Otherwise, all the assets will simply move to blockchains that do.

Additionally, once assets become mobile, the different blockchains will start to differentiate themselves with better features for the assets. Better liquidity, better fees, more functions.

This ability for the asset holder to choose where their assets reside is the only protection from the tyranny of the hardfork.

Traditional companies trade on multiple exchanges, it is time for decentralized assets to distribute the blockchains they exist on. Maintaining a constant total number of assets issued across all blockchains will allow maintaining a fixed total, but only if each participating blockchain follows strict rules on asset issuance.

The reality is that everything in crypto trades against BTC. One of the conditions for cross chain assets is the ability to trade directly against BTC, preferably native BTC and not a derivative. I will be working on a reference implementation as a first draft and look forward to collaborate with all other asset oriented projects.

This is an interop standards effort and it needs to be blockchain agnostic and asset centric.


P.S. I am not asking for any funds or investments.
13  Bitcoin / Development & Technical Discussion / Atomic swaps using cut and choose on: February 14, 2016, 10:53:32 PM
continuing from as it seems the OP locked it for some reason...

   // Four initial states are BOB_sentoffer, ALICE_gotoffer, ALICE_sentoffer, BOB_gotoffer
    // the initiator includes signed feetx and deck of 777 keypairs
    // the responder chooses one of 777 and returns it with "BTCchose" message
    // "BTC<msg> are message events from other party (message events capped at length 8)
    // "lowercas" are special events, <TX> types: <fee>, <dep>osit, <alt>payment, <acl> is altcoin claim
    // "<TX>found" means the other party's is confirmed at user specified confidence level
    // BTC_cleanup state just unwinds pending swap as nothing has been committed yet
    // states instantdex_statecreate(s,n,<Name of State>,handlerfunc,errorhandler,<Timeout State>,<Error State>
    // a given state has a couple of handlers and custom events, with timeouts and errors invoking a bypass
    s = instantdex_statecreate(s,n,"BTC_cleanup",BOB_processfunc,0,0,0);
    s = instantdex_statecreate(s,n,"BOB_claimdeposit",BOB_processfunc,0,0,0);
    s = instantdex_statecreate(s,n,"ALICE_reclaim",BOB_processfunc,0,0,0);
    s = instantdex_statecreate(s,n,"BOB_sentoffer",BOB_processfunc,0,"BTC_cleanup",0);
    s = instantdex_statecreate(s,n,"BOB_sentprivs",BOB_processfunc,0,"BTC_cleanup",0);
    s = instantdex_statecreate(s,n,"BOB_gotoffer",BOB_processfunc,0,"BTC_cleanup",0);
    s = instantdex_statecreate(s,n,"ALICE_sentoffer",ALICE_processfunc,0,"BTC_cleanup",0);
    s = instantdex_statecreate(s,n,"ALICE_gotoffer",ALICE_processfunc,0,"BTC_cleanup",0);
    s = instantdex_statecreate(s,n,"ALICE_sentprivs",ALICE_processfunc,0,"BTC_cleanup",0);
    s = instantdex_statecreate(s,n,"ALICE_wait3",ALICE_processfunc,0,"BTC_cleanup",0);
    s = instantdex_statecreate(s,n,"ALICE_waitfee_privs",ALICE_processfunc,0,"BTC_cleanup",0);
    s = instantdex_statecreate(s,n,"ALICE_waitdeposit_privs",ALICE_processfunc,0,"BTC_cleanup",0);
    s = instantdex_statecreate(s,n,"ALICE_waitfee_deposit",ALICE_processfunc,0,"BTC_cleanup",0);
    s = instantdex_statecreate(s,n,"ALICE_waitprivs",ALICE_processfunc,0,"BTC_cleanup",0);
    s = instantdex_statecreate(s,n,"ALICE_waitfee",ALICE_processfunc,0,"BTC_cleanup",0);
    s = instantdex_statecreate(s,n,"ALICE_waitdeposit",ALICE_processfunc,0,"BTC_cleanup",0);
    s = instantdex_statecreate(s,n,"BOB_sentdeposit",BOB_processfunc,0,"BTC_claimdeposit",0);
    s = instantdex_statecreate(s,n,"BOB_altconfirm",BOB_processfunc,0,"BTC_claimdeposit",0);
    s = instantdex_statecreate(s,n,"ALICE_sentalt",ALICE_processfunc,0,"BTC_claimdeposit",0);
    s = instantdex_statecreate(s,n,"ALICE_waitconfirms",ALICE_processfunc,0,"BTC_claimdeposit",0);
    s = instantdex_statecreate(s,n,"BOB_sentpayment",BOB_processfunc,0,"BTC_claimdeposit",0);
    s = instantdex_statecreate(s,n,"ALICE_claimedbtc",BOB_processfunc,0,0,0);
    s = instantdex_statecreate(s,n,"BOB_claimedalt",BOB_processfunc,0,0,0);

    // events instantdex_addevent(s,*n,<Current State>,<event>,<message to send>,<Next State>)
    // gotoffer states have sent BTCchose already
    // alice needs to wait for various items

    // following states cover all permutations of the three required events to make altpayment
    // wait for last event and send out altpayment

    // now Bob's turn to make sure altpayment is confirmed and send real payment
    // if BTCprivM doesnt come in, altcoin needs to be monitored for alice's claim

I haven't gone through it step by step but that is a good way to do it.

At any time each party is in a given state right?  Why are there 4 start states?  Shouldn't it just be that Bob is in one state and Alice is in another?

For example, Bob starts in BOB_start and Alice starts in Alice_waiting_for_trade_request, or something similar.

If a node receives an offer from another party, then it creates a thread to handle it, like a web-server right?

I guess that means that Alice effectively starts at Alice_received_trade_request, or equivalent.  Since the waiting_for_trade_request is implicit by listening on the socket.

Bob_start causes Bob to send his offer and then transition to Bob_offer_sent.

Bob_offer_sent could timeout within 30-60 seconds and cause Bob to transition to Bob_cancel_offer.  Alternatively, it Alice accepts the offer, they could transition to the fee and 777 pairs exchange.  There is no point in wasting processing if the other party isn't accepting the trade.

I guess it depends on how fine grained the state resolution should be.

Also, there could be a step where both sides decide who is Alice and who is Bob, since the person who offers the trade may not necessarily be Bob.
To avoid insanity I always designate the bitcoin side as Bob and the altcoin side as alice. That way all the directions and scripts are always the same.

Implementation wise, yes it is possible to have just one starting state for both sides, however we have the situation that either party can be the first one to place a quote in the orderbook, ie a bid or ask and this creates 4 possible starting states with 2 parties involved.

alice starts with bid, alice starts with ask, bob starts with bid, bob starts with ask.

notice that alice can be in two of these states at the same time, actually N of them as using the state machine approach each trade that is matched is its own state machine, relatively independent of others (some details like total available balance vs chance that more has been put in the orderbook than funds available, existing trades that are pending)

So that is why 4 possible starting states for when there are two sides to a trade. Internally I have two initial states that bifurcates depending on whether it is alice or bob. Also, before an exchange is ready to be put into the state machine, a lot of onetime prep needs to be done and I wanted the state machine to be as pure as possible and not be cluttered with initial setup.

14  Economy / Services / need someone familiar with finite field arithmetic to write whitepaper on: September 18, 2015, 08:56:47 PM
I created an algorithm that solves a relevant problem and I am looking for someone to write a formal whitepaper for it

I am not sure even where to start to find such a person.

15  Bitcoin / Project Development / Jumblr - decentralized bitcoin mixer 0.1% fee on: September 13, 2015, 12:09:44 PM
I am not sure if this is the right place to post about this, but this weekend I wrote a SuperNET agent which implements the coinshuffle ( using realtime offchain broadcast packets.

Once there are enough participants, the privacy achieved will be close to using bitmessage for mixing, eg very, very good.

You need to have a bitcoin RPC available locally and at no time do you lose control of your funds. I searched, but I could not find any other decentralized bitcoin mixer, so maybe mine is the first?

Since there are no servers to manage, the costs are low, but it does use the network and so I set the fee at 0.1%. This allows many rounds of shuffling for the same cost as the centralized mixers without any third party risk.

This all came together so fast ( it doesnt even have a name yet!

I am looking for people to help test this and also to market this service. It is implemented as a meta-exchange called "shuffle" within InstantDEX, but it really is a totally different type of function and it works with bitcoins or any bitcoin fork without any changes needed.

To go from the low level API to a usable service, I think the following things are needed:

1. Name
2. GUI
3. Testing
4. Marketing

I hope to find people that can help as the only thing I can do well is write C code.

16  Economy / Service Discussion / Jumblr - decentralized bitcoin mixer with 0.1% fee on: September 13, 2015, 12:07:28 PM
I am not sure if this is the right place to post about this, but this weekend I wrote a SuperNET agent which implements the coinshuffle ( using realtime offchain broadcast packets.

Once there are enough participants, the privacy achieved will be close to using bitmessage for mixing, eg very, very good.

You need to have a bitcoin RPC available locally and at no time do you lose control of your funds. I searched, but I could not find any other decentralized bitcoin mixer, so maybe mine is the first?

Since there are no servers to manage, the costs are low, but it does use the network and so I set the fee at 0.1%. This allows many rounds of shuffling for the same cost as the centralized mixers without any third party risk.

This all came together so fast ( it doesnt even have a name yet!

I am looking for people to help test this and also to market this service. It is implemented as a meta-exchange called "shuffle" within InstantDEX, but it really is a totally different type of function and it works with bitcoins or any bitcoin fork without any changes needed.

To go from the low level API to a usable service, I think the following things are needed:

1. Name
2. GUI
3. Testing
4. Marketing

I hope to find people that can help as the only thing I can do well is write C code.


17  Bitcoin / Development & Technical Discussion / Successful atomic cross chain protocol on: September 06, 2015, 10:51:47 AM
Based on Tier Nolan's idea, I have made a way to atomically trade between BTC and NXT/NXTassets. I should be able to combine two such swaps so effectively a BTC <-> ALT (that supports p2sh) would be able to be done.

I lobbied for NXT to support pay on reveal of secret (to specific destination) where the funds are locked using rmd160(sha256(secret)) and it is released when the secret that hashes to that value is submitted.

It took several attempts to solve this and there could well still be some edge cases, and this will be going into InstantDEX as a meta-exchange called "wallet". So best to find any flaws before it goes into beta test.

Here is the protocol:

0. Alice and Bob agree to the terms of the trade and share the pubkeys of their published address. Bob sends the rmd160(sha256(onetimepubkey)) to Alice along with a NXT release on secret linked to the same hash.

1. Both calculate the same p2sh address which allows redemption via 2of2 multisig or normal spend by Bob's onetimepubkey

2. Alice sends to Bob an unsigned funding transaction to the p2sh address for the amount agreed upon.

3. Bob creates a multisig refund tx for the entire amount back to Alice timelocked into the future, signs and sends to Alice.

4. Alice verifies the refund is proper and if it is, broadcasts the funding transaction, which creates a spendable output

5. Due to malleability, Bob needs to wait until it has enough confirms (1 should be enough?) for the value being traded. When he is satisfied, he spends the funds from the p2sh address using the normal path and this publishes his pubkey.

6. Alice submits this pubkey to release the NXT side of the transaction.

The above is the theory, in reality there are a few nasty surprises. If you use timelock and have a sequenceid of -1, timelock is ignored and it gets into the blockchain right away and the input is marked as spent immediately. If you have a sequenceid that is not -1, it is rejected with {"code":-26,"message":"64: non-final"}. So, Alice will have to keep in pocket the refund transaction and make sure to submit it if Bob hasnt revealed his pubkey.
This was from a manual run:

Alice addr:14XrJHhqMvDszMMwKR2d6u5PPvDeRieQoG -> 03b4143b6e7a064a78bc66dab0ca72251fea3d6fd8db1f4c48b91996d7af62dd05
Bob addr: 17Y5rr67RpTtuCd929dS6muyKZmjqJZQpr -> 037387677a21b8ebb472ff2d00892098dcd990a9a21b09b8e22aefece8b1cbbdc0
Bob's onetime addr 1NBKFDmmHSpSzFnP9bX5bDWnm9zqD6nUv4 -> 03c8a7e64c763e908549aa0f93974ab346a559b486eba32bf14338542b4282b916 -> e84e0808b8cd32c38fa2093a490efabc6be53d7a

Both can now calculate p2sh address of 37FsSwJ59z5UuRjNFjtfNYWVFquBEsUGHC from the redeemscript:
OP_IF OP_2 03b4143b6e7a064a78bc66dab0ca72251fea3d6fd8db1f4c48b91996d7af62dd05 037387677a21b8ebb472ff2d00892098dcd990a9a21b09b8e22aefece8b1cbbdc0 OP_2 OP_CHECKMULTISIG
OP_ELSE OP_DUP OP_HASH160 e84e0808b8cd32c38fa2093a490efabc6be53d7a OP_EQUALVERIFY OP_CHECKSIG

I just combined a standard 2of2 and standard pubkeyhash into an conditional, but having never dealt with p2sh till this weekend, nor with signing of bitcoin tx, it was quite a lot of work to get this working as there doesnt seem to be any real support for custom p2sh scripts. Anyway, thanks to jgarzik's libbcoin, I was able to get the signing working in a day and stumbled about figuring out the "obvious" things about p2sh scripts.

[As an aside, if there is a way to verify that e84e0808b8cd32c38fa2093a490efabc6be53d7a is from the third pubkey of a 2of3 multisig address, then there would have been no need for any custom redeemscript. Just normal spends to a 2of3 multisig would have worked (with bob having 2 of the three addresses). Unfortunately I think it is crypto hard to go from msig address + pubkeyhash and 2 of 3 pubkeys to the third pubkey. And if that is not possible, then Alice has no way to know that bob didnt just give her a bogus pubkeyhash]

Bob sends to Alice: e84e0808b8cd32c38fa2093a490efabc6be53d7a
NXT tx: 1117487717739855000 hashed_secret:   cc863b881f35bbeca374b25d018d4e17dc4aa19b Hash:   RIPEMD160_SHA256

and Signed refund tx in pocket: 0100000001a9b3602a28960f1d855d1f52eea54f5e8b6fff469d54083ce433962b1c16dfe100000 000f800483045022100d1439b9170a6d14e07dc6a11dd5c1aab80df302fe4f1de77e12c7859ba20 361f02202dcc946b75995b62fb798b68e9bd443988c4004187f3c5cae52831b9415a712c0147304 40220754d43345edbeffd25cdfc6cbed16f59b1ef25c02092ff1752f0386e6a624e3d022075ef75 78ccb2bbd0a8c58394ed7e4c5803b6ee66691623342fe19862146fda9f01514c6363522103b4143 b6e7a064a78bc66dab0ca72251fea3d6fd8db1f4c48b91996d7af62dd0521037387677a21b8ebb4 72ff2d00892098dcd990a9a21b09b8e22aefece8b1cbbdc052ae6776a914e84e0808b8cd32c38fa 2093a490efabc6be53d7a88ac68a510ec550130750000000000001976a91426be0216d0089626b3 fc3a81f7d844f31a47e0fd88ac34b20500

then Alice broadcasts funding tx e1df161c2b9633e43c08549d46ff6f8b5e4fa5ee521f5d851d0f96282a60b3a9

Bob sees it on the blockchain and spends: 176026872b52b952c4649ee0b44026f87e2282aaaea7994117659a699662ae0a which reveals 03c8a7e64c763e908549aa0f93974ab346a559b486eba32bf14338542b4282b916.

Alice see's Bob's spend and submits an NXT phasing approval tx.

Prior to Alice funding the p2sh address, at worst some of Bob's temporary NXT reserves are held up for a time. After the trade is funded, we have a few cases:

a) Bob spends, Alice approves, both are happy
b) Bob doesnt spend to his address, then after timelock, Alice is able to submit the timelocked refund
c) edge cases: ?

clearly the timelocks need to be set properly, maybe 10 BTC blocks ahead and make it double the estimated time on the NXT side

All steps other than 5, can happen in seconds, so this is a BTC block timeframe in the mainstream case, 10 BTC blocks in the refund case. Not bad for a fully decentralized trade.

Once I verify a timelocked tx I am making can be submitted after the specified block, then I will fully integrate this into InstantDEX

18  Bitcoin / Development & Technical Discussion / multisig using Curve25519 on: October 12, 2014, 03:11:32 AM
First off I remind you I am just a simple C programmer and not a cryptographer. If anybody has the math background to confirm or deny my experimental finding, please post!

I was experimenting with Curve25519 yesterday and I observed a very useful property that allows the creation of multisig.

Now I doubt it was just in the few cases that I discovered that works. I bruteforce searched thousands of combinations and found a very simple relationship that I believe can be used for arbitrary M of N signatures.

The fundamental property of Curve25519 is that if A and B know each others public key, they can create a shared secret. Let A and B be the private keys and a and b the public keys:

curve25519(A,b) == curve25519(B,a)

I searched and searched on the Internet to find little actual useful info, so I started with the above and my intuition and searched for combinations that created the same result and there were many, but the simplest and clearest was:

Add C and c to the above and denote S_ab to being the result of curve25519(A,b) or curve25519(B,a) (they are the same)

curve25519(A,S_bc) == curve25519(B,S_ac) == curve25519(C,S_ab)!

This relationship is quite useful and it is probably obvious to anybody familiar with curve25519 so maybe I am just getting excited over nothing, but the recommendation is to immediately hash the output S_ab. Presumably to avoid any low entropy sections of the point and once you do this, the above relationship does not work as you end up totally scrambling the location of the point in the finite field. I call this the rawsharedkey and maybe it has been explored in depth so we can get some math proofs of the above relationship.

We also know that curve25519(A,curve25519(B,curve25519(C,seed))) is equal to all the permutations of order, I think this is because the field forms an abelian group, but it has been a long time since I did any abstract algebra so I probably have the terms wrong. It is just a fancy way of saying the order doesnt matter.

So how to use these math properties to make multisig?

Since S_xy is constant for each set of keypairs for each node, these values can actually be cached locally. Of course this means that the presence of S_xy in the output does not mean that either X or Y actually signed anything. Turns out this is fine, as the final step requires the signing node to actively participate and the final output can be processed till the dogs come home:

sha256(seed ^ curve25519(A,S_bc))
sha256(seed ^ curve25519(B,S_ac))
sha256(seed ^ curve25519(C,S_ab))

all the above produce the identical result and proves that A, B and C all signed it with the seed (which should have a timestamp in it) and since it goes through sha256 the output gives no useful info about A, B or C. I am not sure if S_xy is leaking any info to the nodes that get access to it, but I dont think so as it is the output of curve25519 and that's supposed to be hard to reverse.

Since it is safe to publish the final number, A, B and C publish it and everybody can verify if 0, 1, 2 or 3 signers signed it. The enforcement of following the result is beyond the scope of this thread

Now, how can this be generalized? I feel strongly that the "triangle" relationship can be generalized, but so far my experimental results are not finding the right sequence.

Let me ramble a bit, that sometimes helps Smiley

Starting with the fundamental triangle:
curve25519(A,S_bc) == curve25519(B,S_ac) == curve25519(C,S_ab)

Let us replace C,c with D, d:
curve25519(A,S_bd) == curve25519(B,S_ad) == curve25519(D,S_ab)

The problem is these are different values as it is S_ab combined with C vs D, however, we can use the priv/pub equivalence:

curve25519(d,curve25519(C,S_ab)) ?? curve25519(c,curve25519(D,S_ab))

nope, that didnt work, but as expected:

curve25519(D,curve25519(C,S_ab)) == curve25519(C,curve25519(D,S_ab))
which means:

curve25519(D,curve25519(C,S_ab)) ==  curve25519(C,curve25519(D,S_ab))  == curve25519(B,curve25519(D,S_ac))  == curve25519(A,curve25519(D,S_bc))

Hey! That means there is a 4 signer solution, but this requires multiple signings and then correlations, so not exactly what I am looking for. Anyway I hope to get some math help here so an efficient M of N multisig using curve25519 is possible. Experimentally I found the triangle relationship, which I am not sure if it is trivially obvious or something significant.

19  Alternate cryptocurrencies / Announcements (Altcoins) / [ANN] ATOMIC: in SuperNET CORE - single blockchain for trading all coins&assets on: September 13, 2014, 06:37:58 AM

Decentralized, Cross-Chain Exchanges for all Blockchain Technologies

Visit the website:
Read the documentation:

ATOMIC on NXT Asset Exchange: 11694807213441909013
ATOMIC on CoinMarketCap:

Everyone reading this already understands that crypto-currency in one form or another is here to stay, it will be the future of transaction, ledger, voting, communication and much more. However, before crypto-currency becomes something that the general public will use it must be ATOMIC. Cross chain trading currently requires the use of a centralized exchange or a workaround which introduces central points of failure, and require that funds be frozen (nLockTime) or a contract to be used until it can be confirmed that the exchange did actually happen. This is where ATOMIC comes into play. ATOMIC is the spiderweb that will attach the blockchains and assets of all of the crypto-currencies.

What is ATOMIC
• A Decentralized Autonomous Corporation. ATOMIC will be run transparently, with direct community involvement, open source, and once a critical mass has been reached it will become a full DAC with no central points of failure, agenda, laws or anything else that could slow it down.
• Cross-chain trading (think NXT to BTC) in a 100% decentralized, contract and fund freezing free way.
• Trading of assets (ex: Gold to Silver)
• Proof Of Exchange (POE) and Proof Of Gateway (POG) these are two brand new crypto-currency technologies which will allow for members of the spider network performing exchanges and verifications to profit in entirely new ways without any special mining hardware or setup.

Why do we need ATOMIC
• 100% transparent and public ledger backed exchanges across blockchains (trading of any asset or any coin)
• Transactions from one blockchain to another will be as fast, if not significantly faster than any existing centralized method of exchange.
• The ability to spend any coin, anywhere (ex: ATOMIC will allow users to spend NXT at a store which only accepts payments to a BTC wallet) without having to wait for a deposit, confirmations, exchange, withdrawal, more confirmations and then finally spend the coins.
• As ATOMIC is run as a DAC it can constantly be changed by the community, without any agenda or central management to prevent progress.

How ATOMIC will work
• ATOMIC will make use of blockchain and wallet technologies but will not be a coin in itself, 'mining' will be a combination of POE and POG.
• POE: Proof of Exchange will act to verify that an exchange between two blockchains has been completed successfully, in a publicly verifiable ledger. Once an exchange has been declared confirmed by ATOMIC, it will be double checked at 4 checkpoints.
• POG: Proof of Gateway will insure that the exchange process happens as quickly as possible. As part of the decentralized spiderweb ATOMIC, 'miners' who are able to confirm exchanges the fastest will receive the largest percentage of the POG fee reward. (Ex: first confirmation: 25% of the reward, second confirmation %15 of the reward, and so on descending returns for each additional confirmer up until 100% of the reward has been paid out at which point the exchange will be confirmed)

End of summary, please read the rest of the documentation here:

#### original OP
11694807213441909013 is the correct assetid, anything else is a fake one

[Dividend Announcement]

NXTventure will offer a 1:10 Atomic dividend, asset 11694807213441909013. The ex-dividend block will be as of 1400 GMT on Tuesday. NXTventure assetholders of record that block will receive the dividend.

For every 10 NXTventure assets you own, 1 Atomic asset will be sent as a dividend.

Atomic is a joint venture project where I will only be offering advices, but it is for what I feel is a promising new tech. I cannot stop the tradings from happening, but I advise to wait for finding the details before trading and if you are buying then please do not be making any large buys until you know what Atomic is. Only buy with small amounts and this is still months away from any release. I will not take any responsibility for the market pricings.

There are just so many deals going on that I am just completing them so I can take it off my todo list. Again, I advise no buying panic.


P.S. JLH has received 10% of Atomic
20  Alternate cryptocurrencies / Announcements (Altcoins) / [ANN] SuperNET NXT asset 12071612744977229797, SUPERNET KMD assetchain in summer on: August 30, 2014, 04:56:53 AM

This OP will only be updated with the most important news. - 100+ page report on SuperNET

Task Boards: &
We currently use Github AND Phabricator for task management.
Guide for new devs:
Iguana Dev Team and their Roles:

Iguana TABS (like pages, includes details on content of tabs):

Some general info:

SuperNET is an initiative designed to:

- Unite disparate cryptocurrencies by fostering collaboration
- Reward innovation, talent and active coin communities
- Share resulting benefits with CORE members and extend advantages to all crypto currencies

--- >


Client v.0
This is a temporary but fully functional client release. SuperNET client v1 is under development.

The real action is going on in SuperNET Slack, which is also where SuperNET announcements are made first.

Supernet Forum

Newsletter signup:
SuperNET Newsletters archive:



Poloniex: UNITY (this is the same as SuperNET asset)

Nxt Asset Exchange

NXT Asset 12071612744977229797 - all others are fake assets!
Issuer acct NXT-MRBN-8DFH-PFMK-A4DBM, make sure to verify before trading.


[SuperNET Dividends]

SuperNET assetholders receive dividends according to the size of their investment.
The dividends are automatically transferred to their holding account on Nxt AE or Bter via the Nxt dividend mechanism.

Asset Dividends paid to this date

Read more about the assets and what features they represent below, under [SuperNET CORE Services and affiliates].

Future SuperNET revenue dividends

SuperNET will make revenues from the fees its core assets receive, as well as advertising revenue and shared fees with third parties. Targeted advertising similar to Google’s AdWords will allow website administrators to serve relevant adverts directly to the cryptocurrency community, with revenue being returned to SuperNET participants.

50% will be distributed as follows:
10 percent for overhead
20 percent for coin communities, according to their proportional contribution
5 percent for Nxt core development
5 percent for BTCD stakers
10 percent unallocated, for discretionary spending to maximise the market cap of SuperNET

The other 50% will go to SuperNET assetholders using the NXT dividend mechanism.


SuperNET/UNITY is a very diversified asset that is the sum of all its parts. Keep in mind that these are mostly independent projects and different ones will come online at different times, so there won’t be a switch that just starts a flood of dividends. It will start with a small trickle and as the dozens of dividend sources all combine and grow, the SuperNET dividend will eventually become quite substantial.

With SuperNET, we have financial ties with the core coins and this will be needed to ensure continued cooperation, especially if we are in a prolonged bear market. What is easy to join, is easy to unjoin and I much rather have few coins with long term commitment to build upon. Only the coins that want to be featured in the SuperNET GUI and getting the cross promotion and technical integration, need to let us buy 10%. If they just want to use the SuperNET services, any coin can do this. Coins without redeeming features wont benefit from being part of SuperNET as nobody will use them. Still, any coin or website is free to connect to SuperNET and make its services available to its communities.


[SuperNET CORE coins]


BITS (SuperNET CORE component!)

To learn more about what features each core coin contribute to SuperNET, see the SuperNET Newsletters.

Attention coin representatives:

Please send your application to join SuperNET CORE to


[SuperNET CORE services and affiliates]

Teleport. Darkpaper:

Telepathy. Whitepaper:

InstantDEX. Near real-time trading between cryptocurrencies.
SuperNET core owns 241,485 InstantDEX.
InstantDEX fees will flow through these and be dividended out to SuperNET investors.

NXTprivacy. Contains all of jl777 / SuperNET’s privacy-related projects.
SuperNET core owns 241,485 NXTprivacy.
NXTprivacy dividends will flow through these and be dividended out to SuperNET investors.

Tradebots (NXTcoinsco). Allows creation of custom decentralized tradebots.
SuperNET core owns 241,485 Tradebots/NxtCoinsco.
NxtCoinsco dividends will flow through these and be dividended out to SuperNET investors.

Coinomat. Enables you to exchange Bitcoins directly in the client.
Coinomat is also the issuer of CoinoUSD (asset ID 12982485703607823902), a USD-tied asset, which can be traded directly from the SuperNET client, thus creating the first NXT/USD decentralized market. CoinoUSD can be withdrawn via Coinomat services, for example to VISA / Mastercard.

SuperNET card (cryptocard). Half-anon withdrawals of NXT and other SuperNET coins.
Dividends will flow to SuperNET holders through NXTprivacy.

neoDICE is similar to that of the legendary satoshiDice, with a few differences, the most important one been the near realtime processing of the wagers.
100% of neoDICE revenues will be distributed to assetholders. This indirectly includes SuperNET, so UNITY holders will receive dividends from neoDICE. UNITY holders will receive dividends from neoDICE through Privatebet > NXTprivacy.

Pangea. Decentralized poker application. Uses provably random numbers and will take advantage of the built-in privacy features of SuperNET.
20% of revenues will go to SuperNET holders through Privatebet > NXTprivacy.
SuperHODL contains 414’454.1309 of 1’000’000 Pangea = 41.45%. SuperNET internal holdings: 0.06%

Omnigames (asset ID: 7441230892853180965).Freemium mobile games that use cryptocurrency for in-game purchases.
80% of Omnigames revenues will be distributed to assetholders.
20% of revenues will go to marketing affiliates, with Privatebet handling the SuperNET players for omnigames.

Omnigames will be dividended out as an asset at the usual rate of 7.5% to both NXTventure and SuperNET, with 5% going to JLH.
SuperHODL contains 400’000 of 1’000’000 Omnigames = 40.00%. SuperNET holds 7.5%

ATOMIC (asset ID 11694807213441909013). Designed to enable 100% decentralized trading for all coins and assets on a single blockchain. It will be integrated into the core of SuperNET.

Freemarket (asset ID 134138275353332190). A decentralized physical goods store (similar to a decentralised eBay).
20% of FreeMarket listing fees (7.77 NXT per listed item from 2015) will go to SuperNET. Download the NXT Freemarket install here:

Jay (asset ID: 8688289798928624137). A light wallet and a decentralised plug-in network.

James writes: ‘Jay will allow people without any software on their system to run the SuperNET GUI and access all coins. I want this to be accessible from, so it would just have the latest SuperNET GUI directly available from the website. It will do local client signing, so they can safely do money tx for any coin connected to the SuperNET, not just core coins!’ Possible uses include a plug-in store for downloads, multiwallet and generally allowing crypto to have a lower entry barrier due to avoiding the requirement of downloading blockchains.

Jay will be dividended out as an asset at the usual rate of 7.5% to both NXTventure and SuperNET, with 5% going to JLH. Timing is undecided.
SuperHODL contains 400’000 of 1’000’000 Jay = 40.00%. SuperNET holds 7.50%

NXTweb. A series of fee-generating sites, the first one being a crowdfunding website:
SuperNET will receive 25 percent of NXTweb’s NET profit.

SNN, SuperNET News Network (asset ID 15113552914305929842), will be ‘a community owned and operated media outlet, with stories and content written by a wide range of contributors about crypto technologies and markets’.

75 percent of SNN revenues will be distributed to its assetholders. Revenue sources include advertising, subscriptions and pay-per-view. SuperNET holds X% of SNN.
SuperHODL contains 700’000 of 1’000’000 SNN = 70.00%. SuperNET holds 7.50%

BOOST (asset ID 9719950459730291994) is a startup incubator that provides zero-interest loans for new NXT companies and will have close links with NXTventure, both in funding and adopting new companies. It will act as a conduit for small companies that want to become a qualified NXTventure listing.

SkyNET (asset id: 6854596569382794790). FinHive has made an agreement with SkyNET to become a wholly owned subsidiary of SkyNET. All future revenues from FinHive operations will flow through SkyNET. Revenues in excess of operating costs will be distributed as dividends to SkyNET assetholders.

MyNxt. Is making an online SuperNET client.
SuperHODL contains 17’200 of 100’000 MyNXT = 17.20%

Coinimal Euro-crypto gateway.
Profit-sharing deal with SuperNET: In return for being featured as the EUR-gateway in the SuperNET, Coinimal GmbH will distribute 51% of the profit generated through the SuperNET Plugin to SuperNET. The Profit Share will be paid monthly in Bitcoin.


[NAV buywall]

A buy wall at NAV has been put up on BTer and NXT AE. This to allow holders to sell at NAV (Net Asset Value) should they need to. The buywall is based on the value of the cryptocurrencies backing SuperNET, but not the assets added for free. explains in a bit more detail.


SuperTraders are a team of cryptocurrency traders with a proven track-record of returns. Their aim is to increase SuperNET’s NAV through trading on different exchanges. They hold a maximum of 10 percent of SuperNET’s working capital, or around 570 BTC. Their capital is awarded incrementally as they increase their own bankrolls through successful trading, thereby increasing confidence and limiting downside risk. Each time they increase their bankroll by 50 percent, SuperNET also increase their available funds by 50 percent. The aim is to allocate the largest bankroll to the SuperTrader with the largest and most consistent gains.

More details:



SuperNET nodes

SuperNET’s infrastructure is a network of servers (nodes), that are publicly visible and will be used to store files in the cloud as well as relaying transactions and messages. If you are able to help set these up and maintain them, please contact Azeh on the bitcointalk forum.


As we get closer to initial release with core functions, we need to have the infrastructure, especially MMatrix. So SuperNET contracted for 10 mega servers to start and will probably get a lot more. For people concerned about the “Instant” of InstantDEX and core capacity of DHT this solves that, as the best software running on snotkitten class hardware will just not provide the performance people will expect.


[Calling SuperNET]

SuperNET’s functionality will be available via a series of API calls.

A ‘passthru’ API call has been added to allow non-SuperNET core coins to access the features of SuperNET. This adds enormous versatility to SuperNET, in that any coin community can now customise it and use it for their own coin, if they wish.
James writes, ‘If there are specific functions that you want to make into SuperNET API, you can code it up and I can merge it in. In SuperNET.conf, the “coins” array describes how to interface to a coin’s daemon and there is a bitcoind_RPC function that invokes it via RPC, so within SuperNET you can call your daemon and encapsulate this in the SuperNET JSON API. Once your coin/service has an API, then with an HTML5/Javascript panel in the SuperNET GUI, all users of SuperNET will have direct (and easy) GUI access.

‘Just like we enhance the NXT GUI into SuperNET, any coin can enhance the SuperNET reference with their own features. Assuming it is a cool feature then SuperNET would be wanting to make it part of the reference release.
‘I think with a “passthru” API that sends the JSON to a coin daemon (even remote), it will simplify coins connecting up to SuperNET. They can update (or fork reference SuperNET GUI) and enhance the SuperNET with their coin’s features. Only their community would have all the code needed to use their coin’s functions. For the ones that have functionality that we want in the core, it then becomes a matter of merging the code and putting it into the reference implementation.’


[Bug hunting rewards]

There are big bug hunting rewards available for anyone who can identify significant bugs in the SuperNET API. Rewards of UNITY will be paid out to anyone who can find problems, with a sliding scale of amounts. Rewards will be paid out at the end of each week to bug-finders and will continue for 5 weeks (until early January 2015).

Interested? PM noashh or jl777.



SuperNET fundraising process: CLOSED

If you still have TOKEN you must redeem to get dividends
If you have TOKEN on NXT AE, send it to: NXT-7Y5B-J8LQ-SL5P-3ULFL (alias: RedeemTOKEN)
It will be converted to SuperNET and sent back to your account. This is done via a manual process run by valarmg

[Official Funds Raised Report]

Sep 23rd
bter 303370.1402 + NXT AE 267873 TOKEN = 571243.1402 TOKEN

1201.4874086 BTC, 13836576.42463729 + 33252122.74985353 NXT, 37559.38107027 BTCD, 713706.73861822 CNY, 5403 VIA, 435658.49 VRC

1201.4874086 BTC
BTCD rate 0.01252290 BTC 37559.38107027 = 470.3524 BTC equiv
NXT rate 0.00007890 BTC   47088699.1745 = 3715.3 BTC equiv
VRC rate 0.00014073 BTC   435658.49 = 61.31 BTC equiv
VIA rate 0.00029967 BTC   5403 = 1.6191 BTC equiv
CNY rate ¥ 2486 per BTC 713706.73861822 = 287.09 BTC equiv

total BTC equiv = 5737.1589

Total UNITY issued

A total of 816061 SuperNET (UNITY) has been issued.

CNY - Bter
BTCD - Azeh escrow acct RA7FDvaNFXZNLqosSbCWFbypuvijJNQw5J
BTC - effectsToCause (VRC), coinsolidation (BTM), crypto_zoidberg (BBR) ...

Escrow Details
Requestor - jl777
Approver - cobaltskky
Authorization Committee of 7:
n3lz0n - NXT-WFTS-BJQR-3V25-6S65F

Bonus plan for jl777

2 bonuses of each 5 percent of UNITY will be paid to James if the following conditions are met:

1. A tripling of market cap by the end of 2014.
2. A tenfold increase in market cap by the end of 2015.

The 3x Bonus threshold is 5737.1589 * 3 = 17211.4767 before end of 2014
The 10x Bonus threshold is 57371.589 before end of 2015

If the conditions are not met, the 5% UNITY will instead go into SuperNET as working capital.



[A few more links]

SuperNET acct.

SuperNET holding acct.

Funding request thread


CMC asset market

Prediction Markets

Tech Tree in the works:

Pages: [1] 2 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!