Online hash calculator - Online tools

How to protect your intellectual property rights for the article before giving it to editorial board?

Hi everyone! Recently I have faced a problem of defending my intellectual property rights for the article. I want to submit my article to some very respectful economic magazine, but before doing this I want to be 99% sure that no one will steal results of my research before it becomes public available. So what is the best way to protect my rights? Thank you for your answers in advance.
submitted by Financial_cog to austrian_economics [link] [comments]

1st Round AMA Answers!

Based on the volume of questions from the East and West, we have compiled them all here. We also want to make sure the community has a chance to see all of the answers in a neat and orderly presentation.
Reddit 1st AMA Answers
What do you mean by “side chains”? Will the Hcash main chain run parallel with other chains, or are other chains plugged in based on certain block numbers? My question is based around the vertical and parallel scalability I see with EOS. What is the interaction with the side chains? Is this faster than vertical scaling?
Side chains will run parallel and be interoperable with the main chain. Side chains allow for new, more efficient, consensus mechanisms as well as smart contract functionality. Eventually other major blockchains will be interoperable with Hcash, through side chains and relays, DAG EVM for ETH, and other “Layer 2” solutions (Lightning Network for BTC and BTC forked code). Side chains allow for different scalability methods, flexibility and accessibility.
Is quantum resistance to protect against hacking, or against “fast mining” (preventing inequality between PoW miners)? How is it possible to guarantee quantum resistance? Isn’t our understanding of quantum computing just based on theories since quantum computers are not fully functional yet?
Quantum resistance is the protection against attacks made by quantum computers, which is currently contrasted by what we know about classical computers. Quantum computers weaken the security assumptions of certain types of cryptography, including ECDSA. If ECDSA were broken, attackers could steal balances in addresses that have made previous spends because the ECDSA public key for the address is revealed to the blockchain. Addresses with unexposed ECDSA keys will be resistant to this type of attack, as they are secured by RIPEMD160 and their ECDSA keys have not been revealed. Quantum resistance does not mean quantum proof. Quantum resistance means that quantum-based attacks do not have a significant advantage over the computers we have today. Based on what we currently know, our signature scheme is quantum resistant. No one knows what the future holds which is why it is important to always continue research and development into quantum resistant cryptography.
What do you mean by “exchange of value and valuable information”? Is this the exchange of coins and smart contracts?
The “value” you are referring is not derived from our current understanding of value (fiat). The “true value” that blockchain systems hold is stored in the hashes themselves. Data and information is king.
Imagine that in 2 years, a kid walks up to you and asks, “What do you do and how does it help society?”
We are one of many projects that helped build a more secure web of connected devices, and revolutionized peoples’ opinion on value and what really matters.
An uninformed businessman who has no understanding of blockchain, but has heard Bitcoin approaches you. How do you explain your product and the benefits to him so that he remembers to give you a call the next day?
Tell him to do his research on blockchain first before selling him on some grand idea. Smart investors grow a stable smart economy, not dumb money.
After reviewing the Hcash source code on GitHub, I've found that almost all the Hcash main chain code has been written by SJTU (Shanghai Jiao Tong University), for example What have other contributors, such as the Nucleus Team, done for Hcash?
Shanghai Jiao Tong University’s Lab of Cryptography and Computer Security is the primary contributor to the main chain code. It is no small feat to have the 4th best university in China working on this project. The Nucleus Team is working with them to finish main chain testing. After the main chain launch, the Nucleus team will focus on the future development for Hcash including our side DAG EVM and main chain Lightning interoperability.
The main chain public repo hasn’t been updated very frequently.
Please refer to our new GitHub. The frequency of updates will increase as we approach/ pass the main chain launch.
When will the swap from Hshares to Hcash take place?
The swap to the main chain will take place after the main chain launch mid-February. Announcements will be made as to how and where you can swap your Hshares for Hcash.
What is the exact date of main chain launch?
The main chain launch will take place mid-February. We are aiming for release on February 15th.
Will you provide interoperability for all the existing blockchains?
We hope to provide interoperability for all blockchains in the future. That is a lot of work though. We will start with the larger chains that have healthy development and community sizes first. To make this easier, we plan to provide a back-end solution for new blockchains to make this process easier.
Will the interoperability between the blockchains support both transfer of data and transfer of value?
What is a block-less blockchain? Is this a traditional distributed system?
A block-less blockchain accomplishes the same goals as a traditional blockchain by using consensus to determine the order of transactions. A block-less blockchain, such as a DAG, allows for faster consensus without traditional block size requirements. Faster consensus means higher throughput.
How will Hcash bridge block-less and traditional blockchains?
Through relays between our main chain and side DAG. A more technical analysis will be available in our upcoming yellow paper.
What signature scheme will you use to achieve quantum resistance? Why?
Hcash is using the BLISS signature scheme. Hcash’s version of BLISS has been hardened to mitigate side channel attacks. BLISS was chosen for its efficient key and signature size.
Provide an overview as to how inoperability will be achieved.
We will be using relays to Hashed Timelock Contracts for Lightning Network interop on our main chain, relays and colored coins that operate with our DAG EVM, bridges to side chains for more uncommon chains, and back-end protocols for newer blockchains.
Specifically, what is the theory behind Hcash’s interoperability?
This answer would be longer than the entire AMA. Unfortunately, the specifics will have to wait until the yellow paper release. In the meantime, I would read the Lightning Network whitepaper because it is an excellent source of information. You could also research BTC relays and EVMs.
What is the timeline for interoperability? Will this be the main focus of Hcash? When can be expect an Alpha version?
We will be updating the roadmap in Q2. Interop timeframes will be easier to gauge after the main chain release. There are quite a few ideas around what we would like to tackle next, whether it would be assisting other projects on Lightning Network development, the DAG EVM implementation, or possibly both at the same time.
How will swap values be calculated when switching between blockchains? Is it based on the current market value?
Yes, it would be based on the current, real time market value.
Will you update the whitepaper to include a comprehensive overview of interoperability, its theory and its exchange functions?
In the coming months we plan to do an update on the white paper. The technical analysis will be provided in our yellow paper. These will be detailed in the updated roadmap to be released after the main chain launch.
Can you explain who will use the Hcash? I am trying to figure out where the supply and demand will come from.
Our target audience is everyone, from people playing mobile games to supporting business and government logic. The supply and demand will come with the need to transfer more and more data across multiple platforms. As for the economic model, this has not been outlined yet. We will be exploring all methods that fall in line with creating smart economies, including 2 token models.
Will you be hiring an advertising team?
We are already expanding Western marketing, primarily in the US. More focus on this will come soon after the main chain.
What are ring signatures in cryptography? How do they work?
At this time, we are exploring more efficient transaction schemes, such as bulletproofs. Bulletproofs can reduce the computational power needed for privatized/ anonymous transactions.
Most of us understand the interoperability of the network. What is a specific use case for Hcash? What role will Hcash have in the network? What makes it a requirement for interoperability? If someone has Bitcoin and wants to convert it to Ethereum using Hcash’s network wallet, is Hcash used as a fee for that conversion?
Here is an analogy. You walk into an arcade with 20 different machines. Each of these machines takes a different token, but you only have coins that operate with one of these machines. This would be the type of solution we hope to provide. Fees can be paid with Hcash. In the future we can explore taking fees in other denominations as well. More of this would be explained in detail with our yellow paper and economic model.
Baidu 1st AMA Answers
What specific date will the main chain go online?
Main chain release is mid-February, but we are aiming for launch on February 15th.
Are you willing to divulge how many apps you have in development for the Hcash main chain?
The primary focus right now is to improve the stability of the Hcash main chain. This will ensure successful launches in the future for developers on our side DAG EVM.
What is the Martian’s current relationship to Hcash? Is he still part of its team?
The Hcash team is currently located on Earth. The last I heard the Martian was returning to Mars.
Will the main chain go up according to schedule? Are there any problems with Hcash? The specialist sales team was made up of shareholders/ investors, right?
Provided no unforeseen circumstances, we are on schedule for the main chain release. There are roadblocks and disconnects with every project. This is a new world of technology we are exploring. I think the team you may be referring to is the Hcash Foundation themselves. A lot of the Western marketing and development is being handled by the Nucleus Team.
Is the code on GitHub all original? Are all developments executed on GitHub? Why is there so little original code? There are so few modifications. I also noticed there are remarkably few references to the code. Most of them are from documents that have been updated.
Many engineers have worked to contribute to the blockchain community over the years. We are taking advantage of the hard work and research that has been done while also making our own meaningful contributions for others to use in their code. It is important to acknowledge the contributions of others. The work completed by Decred in particular has allowed us to grow. Now we will have our chance to contribute back to them and others with our post quantum signature scheme and NG implementation. There are advantages of having similar projects that people don’t realize. For example, after our main chain launch we can explore assisting with development on the Lightning Network. As for GitHub, you will see activity increase when the main chain launches.
What is scope of the Hcash R&D team?
To assess, research and develop cutting edge decentralized consensus mechanisms and applications.
Hcash is currently collaborating with three universities. Shanghai Jiao Tong University has been working on the main chain quantum resistance. What are the main responsibilities of the other two universities?
Building blockchain technology is a group effort. The other teams have also been researching other options for main chains, smart contracts etc. For example, Dr. Joseph Liu from Monash University is working on ring signature schemes to continue our research and development into privatized transactions. We are looking forward to taking the best efforts of all teams and bringing them to the blockchain communities at large, starting with the post quantum implementation from LoCCS at Shanghai Jiao Tong University.
The Westerners working on Hcash don't seem very enthusiastic. They aren't following a lot of people on Twitter. Does the team have any clearer plans for increasing publicity?
The Westerners are primarily focused on the technology, development, and creating more content. The community management will be increasing transparency and activity in time. More Western marketing can be done after the launch of the main chain.
Are there plans to get onto more exchanges such as Bittrex?
When moon? We are constantly considering all options to allow users to access Hcash. Currently we are listed amongst some of the top exchanges like Binance and growing exchanges like KuCoin.
When will quantum resistant technology be implemented into Hcash? Where can we follow the developments being made and is there anywhere we can go to participate in the project?
Quantum resistant technology is available now on GitHub at and will be available for use outside of the testing environment when the main chain launches in the middle of February.
Where do you download the wallet? How do you mine?
The wallet for the new main chain can be found on GitHub at You can mine on the new main chain by joining a pool or using the hcashd node to solo-mine.
When will Hshares swap Hcash? Can you announce a general time?
Hshares can be redeemed for Hcash after the main chain launches in the middle of February. Announcements will be made regarding how and where to swap your Hshares for Hcash.
Will there be an address mapping when Hshares swaps to Hcash like there was with EOS? What other kind of mechanism will be used for the coin swap?
A snapshot of Hshares will be included in the Genesis (first) block of Hcash’s launch to allow users to convert their Hshares into Hcash. An announcement will be made as to how, when and where conversions will take place.
When will the main chain that can support smart contracts go online? When will tokenization for Hcash take place?
Smart contract functionality will be available when our side DAG launches. Users, businesses and developers will be able to build dApps, launch tokens and more. We are making sure the main chain is a stable foundation before adding our DAG to the Hcash ecosystem.
There aren't many updates on GitHub and there aren’t many contributors. What kind of coordination is going on with the development team?
Both the Nucleus Team and members of Shanghai Jiao Tong University LoCCS are working together to finalize testing. Updates are being made to our GitHub at
Based on what I've been reading, Shanghai Jiao Tong University is mainly responsible for the main chain portion of the project. How is their team doing? How many research students in their labs are helping them?
Shanghai Jiao Tong is responsible for building and launching the new main chain. Their team there has been doing a great job with research and development and we look forward to seeing more of their work. The Nucleus Team is currently working with them to finish testing. After testing, the Nucleus team will focus on the future development of the project including our side DAG. I do not know the size of their team as we have not visited their lab.
Can you confirm that the main chain will finally go up in mid-February? Is it just a hypothetical date and then a further delay?
The primary responsibility is to make sure the main chain is stable and secure so that it can be used as the foundation to add other important features to the Hcash ecosystem, like smart contracts and hidden transactions. Everyone is working very hard to hit the target release date of mid-February. We are planning on mid-February for the launch unless anything unexpected comes up.
What is the status of these interoperability features? When is the main chain going online?
Main chain will be released mid-February. The interoperability features depend on the stability of the network. Our side DAG EVM will be the quickest addition to the Hcash ecosystem that will allow for ETH interoperability. Lightning Network on the main chain will require further research and development.
Won’t zero knowledge proofs conflict with the system’s throughput?
We are currently working on more uncommon implementations of zero proof knowledge, such as bulletproofs that allow for efficient transaction speeds. We can also achieve higher throughput with our side DAG.
Thank you to everyone who participated! Round 2 of our AMA session leading up to the launch of the main chain will be announced shortly 😊
submitted by Mr_Handsome_Nucleus to hcash [link] [comments]

Atomic Swap with USDT: Swap Online solution in two hundred lines of code

Atomic Swap with USDT: Swap Online solution in two hundred lines of code
On the eve of the release on the mainnet, the team of the cross-chain wallet Swap Online is publishing a research study and the code of the atomic swapusing USDT.

USD Tether — the equivalent of the dollar on Omni Layer

The solution described above with the protocol “over” the Bitcoin network gave life to one of the most controversial cryptocurrency projects of the last two years — Tether. Tether (symbol Tether — ₮, ticker — USDT) is a hybrid cryptocurrency with a rate binding to one US dollar. Moreover, according to the assurances of Tether Limited, the issuer of the given tokens, the “binding” is to be understood literally, as each purchased token of USDT corresponds to one US dollar available at the disposal of the company.
If we take the three largest exchanges based on their daily turnover of transactions at the time of writing (Binance, OKEx and HuObi), and then track the five most popular trading pairs for each, we will encounter USDT in 13 out of 15 cases.

USDT — the token with the largest capitalization in the world.

All this generates great community interest in faster, safer and cheaper solutions for exchanging Tether into other currencies. Obviously, such a solution could be atomic swaps, which are instant, decentralized cross-chain exchanges. The Komodo laboratory, the main headliners of this technology, who presented it in the autumn of 2017, reported on the successful exchange of KMD to USDT carried out on the BarterDEX platform, Komodo’s own exchanger.
At the same time, according to our data, the developers of Komodo made a swap on the ERC20-a version of Tether, which is only available in 3% of cases. Approximately 60 million USDT from global turnover can thus be exchanged using this method, which, obviously, cannot be considered as a solution to the problem. Striking examples of imperfections of existing solutions can be found even on Etherscan.
This fall, the team of Swap Online is ready to present an atomic swap with Tether. And here’s how we did it.

How Omni conducts transactions

To carry out the Omni transaction, a user needs to create a regular Bitcoin transaction-transfer of 546 satoshi (minimum) with an additional output storing payload using the OP_RETURN op-code. An example of such a transaction. The payload is a mandatory part of any Omni transaction, as it is a sequence of bytes containing all the necessary information about the transaction.

Let us consider what information is stored in the payload itself

transaction marker — 4 bytes, the mandatory part of any Omni payload is always equal to 0x6f6d6e69 — ASCII code omni. If the first 4 bytes of the sequence are not equal to 0x6f6d6e69, then this sequence is not a payload of Omni.
version — 2 bytes, an analog version of the transaction in Bitcoin. For the described algorithm to work, version 0 is used, or that is the same as 0x0000.
transaction type — 2 bytes, transaction type, for an atomic swap it is sufficient to use only “Simple send” transactions, as simple send is the usual sending of omni currency from its address to the address of the recipient. Simple send corresponds to the transaction type code 0, that is, the next 2 bytes 0x0000. Other possible types of transactions exist in Omni.
token identifier — 4 bytes, identifier of the currency used. For example TetherUS has the identifier 31 or 0x0000001f. All tokens created by the Omni protocol at this time can be seen via the following link.
amount — 8 bytes, for a transaction of type Simple send, this is the amount of the sent currency.
As you can see, payload does not store the addresses of senders and recipients of the transactions, these addresses are determined by the Bitcoin transaction in which the payload output was detected. By scanning inputs, the Omni protocol determines who makes the transfer by finding the output of the corresponding address from among the inputs of the transaction p2pkh.
Thus, for a transfer from Alice to Bob of, for example, 50,000,000 TetherUS, we need to create a Bitcoin transaction where one of the inputs will refer to the p2pkh output corresponding to the Alice address. It is also important that this entry be the first in this transaction (the index of this entry in the received transaction would be is minimal or none at all). One of the outputs of this transaction should be the output of p2pkh to Bob’s address, and another output must have been one of the outputs with the following payload:
Example 1
Example 2

Atomic Swap on Omni Layer

Suppose that Alice and Bob are willing to make an inter-blockchain exchange of cryptocurrencies. Alice wants to exchange the units of any Omni currency, for example TetherUS (the given currency has the currency identifier # 31 in the Mainnet, then in the text we will only talk about this currency of the Omni protocol, since it is the most popular at the moment, but the algorithm below will work for any currency of the Omni protocol as well) for b units of a cryptocurrency working on another blockchain. (Omni works on top of the Bitcoin blockchain, of course, according to the algorithm below it is possible to exchange TetherUS for Bitcoins, but due to their work on one and the same blockchain, this exchange can be done in a different, more efficient way).


A — blockchain of Bitcoin.
B — the blockchain of the cryptocurrency for which TetherUS is being exchanged.
a — the sum of TetherUS, which Alice wants to exchange.
b — the sum of the cryptocurrency of the adjoining blockchain B, to which Alice wants to exchange her a TetherUS.

Creating a Transaction

1) Bob generates a random value secret.
2) Bob calculates the secretHash by performing the following operation: secretHash = RIPEMD160 (secret)
3) Bob creates and sends an htlc transaction sealed by secretHash
4) Bob sends Alice a secretHash value, and a hash of the hrlc transaction he created in the previous paragraph in order for Alice to make sure that the correct htlc transaction is actually present in the B blockchain.
5) Alice received from Bob the secretHash and hash of the htlc-transaction Bob created, and is convinced that such a transaction is really present in the B blockchain, and that this is indeed a htlc-transaction sealed by the secretHash value.
6) using the received secretHash, Alice creates the following transaction and translates it into the Bitcoin blockchain:
Let us call such a transaction financing_tx. In fact, it is almost an ordinary Bitcoin htlc transaction that is used in atomic swap with the only difference that in the amount field, 546 satoshi is the minimum number of Bitcoins that can be at the output of the transaction, below this value, Bitcoin counts the transaction as dust and does not conduct it.
7) Alice creates a transaction according to the following scheme:
Let us call this transaction redeem_tx. Alice creates such a transaction with two inputs: the first is the input referencing the output of funding_tx, which contains the htlc script. Alice does not sign this script, that is, the SigScript field remains completely empty. The second input is the input referring to any unspent exits of Alice, the main condition is that at this output stage there are enough Bitcoins to pay the transaction fee, and this entry is signed by Alice with her private key with the signature type SIGHASH_ALL (that is, she signs the entire transaction except for SigScript fields on the inputs transaction, which makes this transaction immutable. The outputs of the same transaction are the elementary Simple Send and a TetherUS from Alice to Bob (details of what Simple Send, payload is and how it works can be found in another section).
8) Alice sends Bob the redeem_tx created in the previous paragraph and the one she signed herself.
9) Bob got the redeem_tx sent by Alice, checks it, just looks through the inputs and outputs, making sure that this is really a transaction that Alice should have created using the real algorithm. After that, Bob signs the transaction with his private key and provides the secret value in the SigScript of the corresponding redeem_tx entry.
10) Bob sends the signed redeem_tx transaction to the blockchain, thereby transferring the TetherUS currency from Alice to himself. Note — before carrying out this step, we still need to check that Alice’s address has the necessary amount of TetherUS.
11) Alice looks through blockchain A and gets the value secret and uses it in the B blockchain to transfer the funds using the htlc transaction Bob created in point 3. The exchange ends here.
Stating the obvious: naturally the timelock value used by Bob when creating the htlc-transaction must be significantly longer than the timelock that Alice uses, since her htlc transaction should be spent earlier than the htlc created by Bob. This is necessary so that Bob cannot manage to spend both htlc.


Thus, connecting Omni Layer to Swap Online allows users to cover transactions.

Full research you may find in our Github

C++ source code for creating TX
C++ source code for redeem TX

Swap.Online Essential Links

Website: GitHub: Email: [email protected] Telegram: Facebook: Twitter: Wiki: Bitcointalk:
submitted by noxonsu to SwapOnline [link] [comments]

17.956 Hacked Brainwallet Passwords

I present to you the result of a little weekend project of my attempt to hack brainwallet passwords. Please note that I didn't steal anybodies money. I've done this just because I was curious.
My program works like this:
  1. Calculate the RIPEMD160 for large password lists and stores them as key-value pairs in a database (RIPEMD160 -> password). I've used leveldb for this.
  2. With a blockchain parser I parse the blockchain and extract all the RIPEMD160 hashes of each bitcoin address.
  3. Then I just make a lookup of each hash in the database, and if I find an entry, I've cracked a brainwallet.
  4. As an additional step, it would be easy to just monitor the blockchain and each time a new transaction arrives, lookup the addresses in the database and extract the money if there is a match (I'm not doing this...)
Here are some things I've learned that I'd like to share:
Most important lesson:
submitted by martinus to Bitcoin [link] [comments]

BIP Number Request: Open Asset | Nicolas Dorier | May 26 2016

Nicolas Dorier on May 26 2016:
Open Asset is a simple and well known colored coin protocol made by Flavien
Charlon, which has been around for more than two years ago.
Open Asset is OP_RETURN to store coin's color. Since then, the only
modification to the protocol has been for allowing OA data to be into any
push into an OP_RETURN.
The protocol is here:
I asked to Flavien Charlon if he was OK if I submit the protocol to the
mailing list before posting.
Additional BIP number might be required to cover for example the "colored
address" format:
But I will do it in a separate request.
Here is the core of the Open Asset specification:
Title: Open Assets Protocol (OAP/1.0)
Author: Flavien Charlon
Created: 2013-12-12
This document describes a protocol used for storing and transferring
custom, non-native assets on the Blockchain. Assets are represented by
tokens called colored coins.
An issuer would first issue colored coins and associate them with a
formal or informal promise that he will redeem the coins according to
terms he has defined. Colored coins can then be transferred using
transactions that preserve the quantity of every asset.
In the current Bitcoin implementation, outputs represent a quantity of
Bitcoin, secured by an output script. With the Open Assets Protocol,
outputs can encapsulate a quantity of a user-defined asset on top of
that Bitcoin amount.
There are many applications:
could then be traded frictionlessly through the Bitcoin
could withdraw and deposit money in colored coins, and trade those, or
use them to pay for goods and services. The Blockchain becomes a
system allowing to transact not only in Bitcoin, but in any currency.
of colored coins. The door would only open when presented with a
wallet containing that specific coin.
==Protocol Overview==
Outputs using the Open Assets Protocol to store an asset have two new
asset stored on the output.
many units of that asset are stored on the output.
This document describes how the asset ID and asset quantity of an
output are calculated.
Each output in the Blockchain can be either colored or uncolored:
both undefined).
non-null asset ID.
The ID of an asset is the RIPEMD-160 hash of the SHA-256 hash of the
output script referenced by the first input of the transaction that
initially issued that asset (script_hash =
RIPEMD160(SHA256(script))). An issuer can reissue more of an
already existing asset as long as they retain the private key for that
asset ID. Assets on two different outputs can only be mixed together
if they have the same asset ID.
Like addresses, asset IDs can be represented in base 58. They must use
version byte 23 (115 in TestNet3) when represented in base 58. The
base 58 representation of an asset ID therefore starts with the
character 'A' in MainNet.
The process to generate an asset ID and the matching private key is
described in the following example:

The issuer first generates a private key:


He calculates the corresponding address:


Next, he builds the Pay-to-PubKey-Hash script associated to that

address: OP_DUP OP_HASH160
010966776006953D5567439E5E39F86A0D273BEE OP_EQUALVERIFY

The script is hashed: 36e0ea8e93eaa0285d641305f4c81e563aa570a2

Finally, the hash is converted to a base 58 string with checksum

using version byte 23:
The private key from the first step is required to issue assets
identified by the asset ID
ALn3aK1fSuG27N96UGYB1kUYUpGKRhBuBC. This acts as a
digital signature, and gives the guarantee that nobody else but the
original issuer is able to issue assets identified by this specific
asset ID.
==Open Assets Transactions==
Transactions relevant to the Open Assets Protocol must have a special
output called the marker output. This allows clients to recognize such
transactions. Open Assets transactions can be used to issue new
assets, or transfer ownership of assets.
Transactions that are not recognized as an Open Assets transaction are
considered as having all their outputs uncolored.
===Marker output===
The marker output can have a zero or non-zero value. The marker output
starts with the OP_RETURN opcode, and can be followed by any sequence
of opcodes, but it must contain a PUSHDATA opcode containing a
parsable Open Assets marker payload. If multiple parsable PUSHDATA
opcodes exist in the same output, the first one is used, and the other
ones are ignored.
If multiple valid marker outputs exist in the same transaction, the
first one is used and the other ones are considered as regular
outputs. If no valid marker output exists in the transaction, all
outputs are considered uncolored.
The payload as defined by the Open Assets protocol has the following format:
! Field !! Description !! Size
! OAP Marker || A tag indicating that this transaction is an
Open Assets transaction. It is always 0x4f41. || 2 bytes
! Version number || The major revision number of the Open Assets
Protocol. For this version, it is 1 (0x0100). || 2 bytes
! Asset quantity count || A
var-integer] representing the number of items in the asset
quantity list field. || 1-9 bytes
! Asset quantity list || A list of zero or more
[ LEB128-encoded] unsigned integers
representing the asset quantity of every output in order (excluding
the marker output). || Variable
! Metadata length || The
var-integer] encoded length of the metadata field. || 1-9
! Metadata || Arbitrary metadata to be associated with
this transaction. This can be empty. || Variable
Possible formats for the metadata field are outside of
scope of this protocol, and may be described in separate protocol
specifications building on top of this one.
The asset quantity list field is used to determine the
asset quantity of each output. Each integer is encoded using variable
length [ LEB128] encoding (also
used in [
Google Protocol Buffers]). If the LEB128-encoded asset quantity of any
output exceeds 9 bytes, the marker output is deemed invalid. The
maximum valid asset quantity for an output is 263 - 1
If the marker output is malformed, it is considered non-parsable.
Coinbase transactions and transactions with zero inputs cannot have a
valid marker output, even if it would be otherwise considered valid.
If there are less items in the asset quantity list than
the number of colorable outputs (all the outputs except the marker
output), the outputs in excess receive an asset quantity of zero. If
there are more items in the asset quantity list than the
number of colorable outputs, the marker output is deemed invalid. The
marker output is always uncolored.
After the asset quantity list has been used to assign an
asset quantity to every output, asset IDs are assigned to outputs.
Outputs before the marker output are used for asset issuance, and
outputs after the marker output are used for asset transfer.
This example illustrates how a marker output is decoded. Assuming the
marker output is output 1:
Data in the marker output Description ----------------------------- 
0x6a The OP_RETURN opcode. 0x10 The PUSHDATA opcode for a 16 bytes payload. 0x4f 0x41 The Open Assets Protocol tag. 0x01 0x00 Version 1 of the protocol. 0x03 There are 3 items in the asset quantity list. 0xac 0x02 0x00 0xe5 0x8e 0x26 The asset quantity list: - '0xac 0x02' means output 0 has an 
asset quantity of 300.
 - Output 1 is skipped and has an 
asset quantity of 0
 because it is the marker output. - '0x00' means output 2 has an 
asset quantity of 0.
 - '0xe5 0x8e 0x26' means output 3 
has an asset quantity of 624,485.
 - Outputs after output 3 (if any) 
have an asset quantity of 0.
0x04 The metadata is 4 bytes long. 0x12 0x34 0x56 0x78 Some arbitrary metadata. 
===Asset issuance outputs===
All the outputs before the marker output are used for asset issuance.
All outputs preceding the marker output and with a non-zero asset ...[message truncated here by reddit bot]...
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

2 humble proposals for Litecoin's proposition

One of the key aspects of success on the web is the proposition. I'm into Litecoin because it has a great proposition (zero pre-mining, stronger crypto for mining, 2m30s block, etc). Let me just give you one example of a failed proposition just so everyone knows where I'm coming from.
Failed proposition Microsoft once had its encyclopedia, Encarta. But MS saw the writing on the wall: wikipedia and user-generated content would kill them. So at one point, they "opened" Encarta for people to edit. Unfortunately, if you clicked edit, unlike wikipedia, you were first led to a page full of legalese telling you that you were about to transfer your intellectual property rights to Microsoft Corporation, etc. As people saw that, they basically went FU and didn't bother improving Encarta. These days, you can read about Encarta on wikipedia, ironically.
Proposition is extremely important, and it's mostly psychological. The best book about it is "Here comes everybody".
I have been thinking a lot about this, and I think it would be productive for all of our community if we were to discuss how can we subtly improve Litecoin without alterations to code (i.e., no risks). What I mean are minor tweaks in the perception and the proposition of Litecoin.
So I would like to throw some ideas out there:
Idea #1. 256-bit standard address: instead of reducing the SHA256 to RIPEMD160, and creating even the (minute) probability of collusion, we should think about having more security than Bitcoin and use RIPEMD256. The core of the system doesn't even have the idea of "address", so this could be done, correct me if I'm wrong, easily--zero risk. There might opposition to this, as it increases our blockchain size, by 92bits per new, changed, address. Yet, I would love to be able to brag about Litecoin's stronger crypto in addresses and in mining. Scrypt is way better than SHA2 and Litecoin is already more secure than bitcoin (architecturally, not in hashing power, due to the influx of ASICs). But we may also want to differentiate by having stronger, harder to break addresses.
Idea #2. The "unit" (or "Schelling point"). In bitcoin, there are two clear "units": one bitcoin and one satoshi. But 1 bitcoin = 100 million satoshis makes for unnatural calculations and some cognitive overload (see, for instance, this card experiment, or this simple cognitive reflection task, or the hard Monty hall problem). These situations and experiments show that people have a hard time (cognitively) dealing with even simple problems. I think we can do better if we use what's on already people's minds: cents, and create/name the "Lite", with 1 Litecoin = 1,000,000 Lites (with 1 Lite being 100 Lite-cents).
As a silly example, it is smoother and easier to tell friends "Just paid 2 bucks on a million Lites" than "Just paid 200 bucks on a bitcoin". The words million and billion are associated with wealth, in a way that "coin" isn't. "You have 56 million lites?" sounds and feels better than "you have 56 litecoin?" I'm not talking about dropping the name litecoin (it's awesome), but about naming the quote-"smallest unit"-endquote as something that makes for immediate calculation (and of course the real "smallest unit" would be a cent of a "Lite").
I'm sorry for the wall of text. But I think we can improve Litecoin's proposition, and that if we do so, we'll have an even bigger lead against the other cryptocurrencies out there. From Zimbabwe dollars to gold, money is about trust and confidence. Let's be cryptographically stronger than anyone out there, and let's let those who join us make immediate, natural, system 1 calculations.
Again, I'm sorry for the wall of text, I thank you for reading this far, and may Litecoin have a long prosperous life!
submitted by asymmetric_bet to litecoin [link] [comments]

Authentication BIP | Jonas Schnelli | Aug 08 2016

Jonas Schnelli on Aug 08 2016:
As already mentioned in the recent BIP151 thread
I propose the following authentication scheme to basically allow MITM
detection and rejection in conjunction with BIP151.
The proposed authentication BIP does require BIP151.
The propose BIP does assume, node operators want to build trusted
connections for various reasons.
BIPs mediawiki github page available here:

BIP: ???
Title: Peer Authentication
Author: Jonas Schnelli
Status: Draft
Type: Standards Track
Created: 2016-03-23
== Abstract ==
This BIP describes a way how peers can authenticate – without opening
fingerprinting possibilities – to other peers to guarantee ownership
and/or allowing to access additional or limited services.
== Motivation ==
We assume peer operators want to limit the access of different services
or increase datastream priorities to a selective subset of peers. Also
we assume peers want to connect to specific peers to broadcast or filter
transactions (or similar action that reveals sensitive informations) and
therefore they want to authenticate the remote peer and make sure that
they have not connected to a MITM.
Benefits with peer authentication:
specific peers
node fingerprinting (fee estimation)
authenticated peers
A simple authentication scheme based on elliptic cryptography will allow
peers to identify each other and selective allow access to restricted
services or reject the connection if the identity could not be verified.
== Specification ==
The authentication scheme proposed in this BIP uses ECDSA, ___secrets
will never be transmitted___.
___Authentication initialization must only happen if encrypted channels
have been established (according to BIP-151 [1]).___
The encryption-session-ID is available once channels are encrypted
(according to BIP-151 [1]).
The identity-public-keys used for the authentication must be pre-shared
over a different channel (Mail/PGP, physical paper exchange, etc.). This
BIP does not cover a "trust on first use" (TOFU) concept.
The authentication state must be kept until the encryption/connection
Only one authentication process is allowed per connection.
Re-authenticate require re-establishing the connection.
=== Known-peers and authorized-peers database ===
Each peer that supports p2p authentication must provide two users
editable "databases"

known-peers contains known identity-public-keys together with a

network identifier (IP & port), similar to the "known-host" file
supported by openssh.

authorized-peers contains authorized identity-public-keys

=== Local identity key management ===
Each peer can configure one identity-key (ECC, 32 bytes) per listening
network interface (IPv4, IPv6, tor).
The according identity-public-key can be shared over a different channel
with other node-operators (or non-validating clients) to grant
authorized access.
=== Authentication procedure ===
Authentication after this BIP will require both sides to authenticate.
Signatures/public-keys will only be revealed if the remote peer could
prove that they already know the remote identity-public-key.

-> Requesting peer sends AUTHCHALLENGE (hash)

<- Responding peer sends AUTHREPLY (signature)

-> Requesting peer sends AUTHPROPOSE (hash)

<- Responding peer sends AUTHCHALLENGE (hash)

-> Requesting peer sends AUTHREPLY (signature)

For privacy reasons, dropping the connection or aborting during the
authentication process must not be possible.
=== AUTHCHALLENGE message ===
A peer can send an authentication challenge to see if the responding
peer can produce a valid signature with the expected responding peers
identity-public-key by sending an AUTHCHALLENGE-message to the remote
The responding peer needs to check if the hash matches the hash
calculated with his own local identity-public-key. Fingerprinting the
requesting peer is not possible.
32bytes challenge-hash `hash(encryption-session-ID || challenge_type ||
challenge_type is a single character. i if the
AUTHCHALLENGE-message is the first, requesting challenge or r if
it's the second, remote peers challenge message.
=== AUTHREPLY message ===
A peer must reply an AUTHCHALLENGE-message with an AUTHREPLY-message.
| 64bytes || signature || normalized comp.-signature || A signature of
the encryption-session-ID done with the identity-key
If the challenge-hash from the AUTHCHALLENGE-message did not match the
local authentication public-key, the signature must contain 64bytes of
The requesting peer can check the responding peers identity by checking
the validity of the sent signature against with the pre-shared remote
peers identity-public-key.
If the signature was invalid, the requesting peer must still proceed
with the authentication by sending an AUTHPROPOSE-message with 32
random bytes.
=== AUTHPROPOSE message ===
A peer can propose authentication of the channel by sending an
AUTHPROPOSE-message to the remote peer.
If the signature sent in AUTHREPLY was invalid, the peer must still
send an AUTHPROPOSE-message containing 32 random bytes.
The AUTHPROPOSE message must be answered with an
AUTHCHALLENGE-message – even if the proposed requesting-peers
identity-public-key has not been found in the authorized_peers database.
In case of no match, the responding AUTHCHALLENGE-message must
contains 32 bytes of zeros.
| 32bytes || auth-propose-hash || hash || `hash(encryption-session-ID
== Post-Authentication Re-Keying ==
After the second AUTHREPLY message (requesting peers signature ->
responding peer), both clients must re-key the symmetric encryption
according to BIP151 while using ___a slightly different re-key key
derivation hash___.
They both re-key with `hash(encryption-session-ID ||
old_symmetric_cipher_key || requesting-peer-identity-public-key ||
== Identity-Addresses ==
The peers should display/log the identity-public-key as an
identity-address to the users, which is a base58-check encoded
ripemd160(sha256) hash. The purpose of this is for better visual
comparison (logs, accept-dialogs).
The base58check identity byte is 0x0F followed by an identity-address
version number (=0xFF01).
An identity address would look like
TfG4ScDgysrSpodWD4Re5UtXmcLbY5CiUHA and can be interpreted as a remote
peers fingerprint.
== Compatibility ==
This proposal is backward compatible. Non-supporting peers will ignore
the new AUTH* messages.
== Example of an auth interaction ==
Before authentication (once during peer setup or upgrade)

Requesting peer and responding peer create each an identity-keypair

(standard ECC priv/pubkey)

Requesting and responding peer share the identity-public-key over a

different channel (PGP mail, physical exchange, etc.)

Responding peer stores requesting peers identity-public-key in its

authorized-peers database (A)

Requesting peer stores responding peers identity-public-key in its

known-peers database together with its IP and port (B)

Encrypted channels must be established (according to BIP-151 [1])


Requesting peer sends an AUTHCHALLENGE message

[32 bytes, hash(encryption-session-ID || "i" || 

Responding peer does create the same hash `(encryption-session-ID ||

"i" || )` with its local

If the hash does not match, response with an AUTHREPLY message

containing 64bytes of zeros.

In case of a match, response with an AUTHREPLY message

[64 bytes normalized compact ECDSA signature (H)] (sig of the 
encryption-session-ID done with the identity-key)

Requesting peer does verify the signature with the


If the signature is invalid, requesting peer answers with an

AUTHREPLY message containing 32 random bytes

In case of a valid signature, requesting peer sends an AUTHPROPOSE

[32 bytes, hash(encryption-session-ID || "p" || 

Responding peer iterates over authorized-peers database (A), hashes

the identical data and looks for a match.

If the hash does not match, responding peer answer with an

AUTHCHALLENGE message containing 32 bytes of zeros.

In case of a match, responding peer sends an AUTHCHALLENGE message

with the hashed client public-key
[32 bytes, hash(encryption-session-ID || "r" || 

Requesting peer sends an AUTHREPLY message containing 64 bytes of

zeros if server failed to authenticate

Otherwise, response with signature in the AUTHREPLY message

[64 bytes normalized compact ECDSA signature (H)] (sig of the 
encryption-session-ID done with the identity-key)

Responding peer must verify the signature and can grant access to

restricted services.

Both peers re-key the encryption after BIP151 including the

requesting-peer-identity-public-key and responding-peer-identity-public-key
== Disad...[message truncated here by reddit bot]...
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

Blockchain scripting contest, second stage

This blockchain scripting contest is a way to raise awareness about the possibilities and powers of the scripting mechanism integrated in the bitcoin protocol.
Every stage will be about a non-standard transaction output (scriptPubKey) broadcast by me and funded with a given amount. Objective of the stage is to find an appropriate script (scriptSig) that will succesfully resolve the stacked scripts, as requested by the bitcoin protocol. The amount in the tx output is the award of the stage and can be claimed at will.
The difficulty of the stages will increase in each step.
Link to 1st stage and solution
2nd stage
Funding transaction/output: 948aeca2003bf0bdc4f0dc7d61615d05010da8bca744dd9cfa12fb57e2540a2d, n=0
Claimable amount: 5 mBTC !!remember to reserve at least 0.1mBTC for transaction fees!!
scriptPubKey to solve:
OP_DEPTH OP_1 OP_NUMEQUAL OP_IF 6e616d65206f66206e616b616b616d6f746f OP_DROP OP_RIPEMD160 OP_RIPEMD160 9c864b8bb110c05cb9c77381ad5d6868f0fd9f9f OP_EQUAL OP_ELSE OP_DUP OP_HASH160 897b934876ff50bfebe218e30382d7eaa6559a12 OP_EQUALVERIFY OP_CHECKSIG OP_ENDIF 
Difficulty level: medium
State: Unclaimed!
Recommended Toolchain:
Documentation: Transactions, Raw Transactions API, Scripts and OPcodes reference.
Have fun!
PS: Any amount sent to the address 1JHCn9wLLXHc4yfo968FrT259Um2hzeUpy will be used to fund the next stages.
submitted by tartare4562 to Bitcoin [link] [comments]

ripemd 160 - YouTube Public key to adress Публичный ключ переобразование в адрес

In the previous article, we looked at different methods to generate a private key.Whatever method you choose, you’ll end up with 32 bytes of data. Here’s the one ... Get bitcoin address from RIPEMD-160 hash in python - Skip to content. All gists Back to GitHub Sign in Sign up Sign in Sign up {{ message }} Instantly share code, notes, and snippets. anddam / Created Feb 14, 2014. Star 2 Fork 2 Star Code Revisions 1 Stars 2 Forks 2. Embed. What would you like to do? Embed Embed this gist in your ... I am trying to understand how the crypto algorithms RIPEMD and SHA256 work. The bitcoin method for computing PKHash is RIPEMD160(SHA256(PublicKey)). I am trying to first implement the RIPEMD of SH... It is used in the Bitcoin standard. It is a a strengthened version of the RIPEMD algorithm which produces a 128 bit hash digest while the RIPEMD-160 algorithm produces a 160-bit output. The compression function is made up of 80 stages made up of 5 blocks that run 16 times each. This pattern runs twice with the results being combined at the bottom using modulo 32 addition. Padding. The ... Online RIPEMD160 Hash Calculator. Algorithm. String to encode. Encode. Other algorithms calculators MD2 MD4 MD5 SHA1 SHA224 SHA256 SHA384 SHA512/224 SHA512/256 SHA512 SHA3-224 SHA3-256 SHA3-384 SHA3-512 RIPEMD128 RIPEMD160 RIPEMD256 RIPEMD320 WHIRLPOOL TIGER128,3 TIGER160,3 TIGER192,3 TIGER128,4 TIGER160,4 TIGER192,4 SNEFRU SNEFRU256 GOST GOST-CRYPTO ADLER32 CRC32 CRC32B FNV132 FNV1A32 FNV164 ...

[index] [21577] [6826] [49715] [26218] [4301] [37746] [25852] [39692] [18463] [32985]

ripemd 160 - YouTube

Публичный ключ: 04289C2118EF2BA52A90D048CC8063CB9C1C32970E659A583057D3B239C128AD8F6D43567BC1639A4EF64E03BA657155B6206323F9282F15A0FF7BD74A2877DB17 1 ... RIPEMD 160 hash algorithm The whole name of RIPEMD is RACE Integrity Primitives Evaluation Message Digest. RIPEMD a ...