CHECKSIG

Fun with OP_HODL (CheckLockTimeVerify)

Finally got around to messing around with python-bitcoinlib, and I'm very impressed. Great work by Peter Todd. I went ahead and cooked up a sample based off of the ones provided to test OP_HODL. This is bitcoin contract that can lock funds in a UTXO until a specified time has arrived.
This script will lock funds in a UTXO until "10/13/2020 @ 6:55am (UTC)". Though realistically you really need to wait about an hour past your expiry time since the nLockTime logic uses that average of the last 11 blocks as a clock, not the last block.
Here's a breakdown:
First look at the witness program on the spending txn.

If we add the deserialize the witnessScript this is what we get:
< OP_CHECKLOCKTIMEVERIFY OP_DROP OP_CHECKSIG>
Looking at the 2nd output of the funding txn, you should see the ScriptPubKey is simply OP_0 to signal segwit and the hash of the witness script.
OP_0
And of course, our nLockTime in our spending TXN matches our expiry, and our sequence in our spending txn is encoded to allow nLockTime processing.
One thing that was interesting with nLockTime txns is that they are completely invalid before they "ripen". You can't even store them in your wallet. You just have to wait to broadcast until the right time transpires. Broadcasting early will fail with a non-final error.
The CoinBin wallet is the only one I know of that allows you to create OP_HODL addresses, but I'm not certain they provide a way to spend them.
submitted by brianddk to Bitcoin [link] [comments]

Help with raw BCH transaction - Coinbase Multisig

Been trying to recover an old Coinbase BCH multisig wallet from back in the day and am running into errors after signing the transaction.

I followed this process to get the keys and auth script. http://blog.nerdbank.net/2017/08/how-to-sell-your-coinbase-multi-sig.html?m=1

Now that blockdozer.com is no longer up and running, these kinds of tools don't work like the original Coinb.in method - https://www.reddit.com/btc/comments/6bsc5m/used_the_coinbase_multisig_vault_recovery_tool/
https://bitcoin.stackexchange.com/questions/64493/restore-block-io-multisig-wallet-in-electrum

My last attempt was to use cryptoapis.io on postman to publish the transaction.

When I decode my transaction I get this:
{
"payload": {
"txid": "c210d81d7421df8c29fef9d51ed4762c7c435e37e4e1f0d03da98d7a0ff53707",
"hash": "c210d81d7421df8c29fef9d51ed4762c7c435e37e4e1f0d03da98d7a0ff53707",
"size": 404,
"version": 1,
"locktime": 0,
"vin": [
{
"txid": "3f9c05b991e2da6a45447ad794d4a3ce83ecea4616d6865de51d823e44f6640f",
"sequence": 4294967293,
"vout": 0,
"scriptSig": {
"asm": "0 304402202c751ad9af37e4ac396e4c0517db3155996f4444912f9029c0aca48d7ebcbab102201a0b5abc1dd11377481c04f94bb61607bec3238e8efb85968fbafedf55160d09[ALL] 304502210084c5bab07dd33be1f080ff39994e42139902871d7cedbbd8aa9d1cf4b02d301f02204b275afd22b4ce3b4b60de4204aad2082ecd0bd37e1ac3c2d97dc23fc0d8d681[ALL] 5221038e0a77486457bb154806aa9696f9c09e6160961cf45978e24b3077a457c89b0a410456d2147c0ac68657840bedbc80de83ae2f3f29efb6bec8123ac5c54428e0c88f8c8c2a27fb2c32c9788e70595fc742fba6adc4dab15e8ab4a1a5d89e16025f5b4104c8b2bbb7147082f993f19a8d9641968903c9ad0be35c7e535dc307840a6af470d40eeada1ab8cffc661816423423e1cd1c867704fd436b3ebf25a330ca7eb10d53ae",
"hex": "0047304402202c751ad9af37e4ac396e4c0517db3155996f4444912f9029c0aca48d7ebcbab102201a0b5abc1dd11377481c04f94bb61607bec3238e8efb85968fbafedf55160d090148304502210084c5bab07dd33be1f080ff39994e42139902871d7cedbbd8aa9d1cf4b02d301f02204b275afd22b4ce3b4b60de4204aad2082ecd0bd37e1ac3c2d97dc23fc0d8d681014ca95221038e0a77486457bb154806aa9696f9c09e6160961cf45978e24b3077a457c89b0a410456d2147c0ac68657840bedbc80de83ae2f3f29efb6bec8123ac5c54428e0c88f8c8c2a27fb2c32c9788e70595fc742fba6adc4dab15e8ab4a1a5d89e16025f5b4104c8b2bbb7147082f993f19a8d9641968903c9ad0be35c7e535dc307840a6af470d40eeada1ab8cffc661816423423e1cd1c867704fd436b3ebf25a330ca7eb10d53ae"
}
}
],
"vout": [
{
"value": "0.21192121",
"n": 0,
"scriptPubKey": {
"asm": "OP_DUP OP_HASH160 e6a79df19f5b69c87231e65005b3b39396368fa0 OP_EQUALVERIFY OP_CHECKSIG",
"hex": "76a914e6a79df19f5b69c87231e65005b3b39396368fa088ac",
"reqSigs": 1,
"type": "pubkeyhash",
"addresses": [
"bitcoincash:qrn20803nadknjrjx8n9qpdnkwfevd505qpqsq8r8w"
]
}
}
]
}
}

But when I try to send the transaction I get this error:

{
"meta": {
"error": {
"code": 4003,
"message": "Cannot send transaction: mandatory-script-verify-flag-failed (Signature must use SIGHASH_FORKID) (code 16)"
}
}
}

I wasn't able to find much info on this error message. Any help getting this sorted out would be appreciated
submitted by Majestic-Pear-1100 to btc [link] [comments]

Technical: The `SIGHASH_NOINPUT` Debate! Chaperones and output tagging and signature replay oh my!

Bitcoin price isn't moving oh no!!! You know WHAT ELSE isn't moving?? SIGHASH_NOINPUT that's what!!!
Now as you should already know, Decker-Russell-Osuntokun ("eltoo") just ain't possible without SIGHASH_NOINPUT of some kind or other. And Decker-Russell-Osuntokun removes the toxic waste problem (i.e. old backups of your Poon-Dryja LN channels are actively dangerous and could lose your funds if you recover from them, or worse, your most hated enemy could acquire copies of your old state and make you lose funds). Decker-Russell-Osuntokun also allows multiparticipant offchain cryptocurrency update systems, without the drawback of a large unilateral close timeout that Decker-Wattenhofer does, making this construction better for use at the channel factory layer.
Now cdecker already wrote a some code implementing SIGHASH_NOINPUT before, which would make it work in current pre-SegWit P2PKH, P2SH, as well as SegWit v0 P2WPKH and P2WSH. He also made and published BIP 118.
But as is usual for Bitcoin Core development, this triggered debate, and thus many counterproposals were made and so on. Suffice it to say that the simple BIP 118 looks like it won't be coming into Bitcoin Core anytime soon (or possibly at all).
First things first: This link contains all that you need to know, but hey, maybe you'll find my take more amusing.
So let's start with the main issue.

Signature Replay Attack

The above is the Signature Replay Attack, and the reason why SIGHASH_NOINPUT has triggered debate as to whether it is safe at all and whether we can add enough stuff to it to ever make it safe.
Now of course you could point to SIGHASH_NONE which is even worse because all it does is say "I am authorizing the spend of this particular coin of this particular value protected by my key" without any further restrictions like which outputs it goes to. But then SIGHASH_NONE is intended to be used to sacrifice your money to the miners, for example if it's a dust attack trying to get you to spend, so you broadcast a SIGHASH_NONE signature and some enterprising miner will go get a bunch of such SIGHASH_NONE signatures and gather up the dust in a transaction that pays to nobody and gets all the funds as fees. And besides; even if we already have something you could do stupid things with, it's not a justification for adding more things you could do stupid things with.
So yes, SIGHASH_NOINPUT makes Bitcoin more powerful. Now, Bitcoin is a strong believer in "Principle of Least Power". So adding more power to Bitcoin via SIGHASH_NOINPUT is a violation of Principle of Least Power, at least to those arguing to add even more limits to SIGHASH_NOINPUT.
I believe nullc is one of those who strongly urges for adding more limits to SIGHASH_NOINPUT, because it distracts him from taking pictures of his autonomous non-human neighbor, a rather handsome gray fox, but also because it could be used as the excuse for the next MtGox, where a large exchange inadvertently pays to SIGHASH_NOINPUT-using addresses and becomes liable/loses track of their funds when signature replay happens.

Output Tagging

Making SIGHASH_NOINPUT safer by not allowing normal addresses use it.
Basically, we have 32 different SegWit versions. The current SegWit addresses are v0, the next version (v1) is likely to be the Schnorr+Taproot+MAST thing.
What output tagging proposes is to limit SegWit version ranges from 0->15 in the bech32 address scheme (instead of 0->31 it currently has). Versions 16 to 31 are then not valid bech32 SegWit addresses and exchanges shouldn't pay to it.
Then, we allow the use of SIGHASH_NOINPUT only for version 16. Version 16 might very well be Schnorr+Taproot+MAST, with a side serving of SIGHASH_NOINPUT.
This is basically output tagging. SIGHASH_NOINPUT can only be used if the output is tagged (by paying to version 16 SegWit) to allow it, and addresses do not allow outputs to be tagged as such, removing the potential liability of large custodial services like exchanges.
Now, Decker-Russell-Osuntokun channels have two options:
The tradeoffs in this case are:
The latter tradeoff is probably what would be taken (because we're willing to pay for privacy) if Bitcoin Core decides in favor of tagged outputs.
Another issue here is --- oops, P2SH-Segwit wrapped addresses. P2SH can be used to wrap any SegWit payment script, including payments to any SegWit version, including v16. So now you can sneak in a SIGHASH_NOINPUT-enabled SegWit v16 inside an ordinary P2SH that wraps a SegWit payment. One easy way to close this is just to disallow P2SH-SegWit from being valid if it's spending to SegWit version >= 16.

Chaperone Signatures

Closing the Signature Replay Attack by adding a chaperone.
Now we can observe that the Signature Replay Attack is possible because only one signature is needed, and that signature allows any coin of appropriate value to be spent.
Adding a chaperone signature simply means requiring that the SCRIPT involved have at least two OP_CHECKSIG operations. If one signature is SIGHASH_NOINPUT, then at least one other signature (the chaperone) validated by the SCRIPT should be SIGHASH_ALL.
This is not so onerous for Decker-Russell-Osuntokun. Both sides can use a MuSig of their keys, to be used for the SIGHASH_NOINPUT signature (so requires both of them to agree on a particular update), then use a shared ECDH key, to be used for the SIGHASH_ALL signature (allows either of them to publish the unilateral close once the update has been agreed upon).
Of course, the simplest thing to do would be for a BOLT spec to say "just use this spec-defined private key k so we can sidestep the Chaperone Signatures thing". That removes the need to coordinate to define a shared ECDH key during channel establishment: just use the spec-indicated key, which is shared to all LN implementations.
But now look at what we've done! We've subverted the supposed solution of Chaperone Signatures, making them effectively not there, because it's just much easier for everyone to use a standard private key for the chaperone signature than to derive a separate new keypair for the Chaperone.
So chaperone signatures aren't much better than just doing SIGHASH_NOINPUT by itself, and you might as well just use SIGHASH_NOINPUT without adding chaperones.
I believe ajtowns is the primary proponent of this proposal.

Toys for the Big Boys

The Signature Replay Attack is Not A Problem (TM).
This position is most strongly held by RustyReddit I believe (he's the Rusty Russell in the Decker-Russell-Osuntokun). As I understand it, he is more willing to not see SIGHASH_NOINPUT enabled, than to have it enabled but with restrictions like Output Tagging or Chaperone Signatures.
Basically, the idea is: don't use SIGHASH_NOINPUT for normal wallets, in much the same way you don't use SIGHASH_NONE for normal wallets. If you want to do address reuse, don't use wallet software made by luke-jr that specifically screws with your ability to do address reuse.
SIGHASH_NOINPUT is a flag for use by responsible, mutually-consenting adults who want to settle down some satoshis and form a channel together. It is not something that immature youngsters should be playing around with, not until they find a channel counterparty that will treat this responsibility properly. And if those immature youngsters playing with their SIGHASH_NOINPUT flags get into trouble and, you know, lose their funds (as fooling around with SIGHASH_NOINPUT is wont to do), well, they need counseling and advice ("not your keys not your coins", "hodl", "SIGHASH_NOINPUT is not a toy, but something special, reserved for those willing to take on the responsibility of making channels according to the words of Decker-Russell-Osuntokun"...).

Conclusion

Dunno yet. It's still being debated! So yeah. SIGHASH_NOINPUT isn't moving, just like Bitcoin's price!!! YAAAAAAAAAAAAAAAAAAA.
submitted by almkglor to Bitcoin [link] [comments]

Upcoming Updates to Bitcoin Consensus

Price and Libra posts are shit boring, so let's focus on a technical topic for a change.
Let me start by presenting a few of the upcoming Bitcoin consensus changes.
(as these are consensus changes and not P2P changes it does not include erlay or dandelion)
Let's hope the community strongly supports these upcoming updates!

Schnorr

The sexy new signing algo.

Advantages

Disadvantages

MuSig

A provably-secure way for a group of n participants to form an aggregate pubkey and signature. Creating their group pubkey does not require their coordination other than getting individual pubkeys from each participant, but creating their signature does require all participants to be online near-simultaneously.

Advantages

Disadvantages

Taproot

Hiding a Bitcoin SCRIPT inside a pubkey, letting you sign with the pubkey without revealing the SCRIPT, or reveal the SCRIPT without signing with the pubkey.

Advantages

Disadvantages

MAST

Encode each possible branch of a Bitcoin contract separately, and only require revelation of the exact branch taken, without revealing any of the other branches. One of the Taproot script versions will be used to denote a MAST construction. If the contract has only one branch then MAST does not add more overhead.

Advantages

Disadvantages

submitted by almkglor to Bitcoin [link] [comments]

PSA: Guide on how to recover your lost Segwit coins using Electron Cash

How to get your recovered SegWit funds using Electron Cash

Background

Thousands of BCH on thousands of coins that were accidentally send to Segwit 3xxx addresses were recovered by BTC.TOP in block 582705.
This was a wonderful service to the community. This had to be done quickly as the coins were anyone can spend and needed to be sent somewhere. This all had to be done before thieves could get their dirty paws on them.
So.. How were they recovered? Did BTC.TOP just take the coins for themselves? NO: They were not taken by BTC.TOP. This would be wrong (morally), and would open them up to liability and other shenanigans (legally).
Instead --BTC.TOP acted quickly and did the legally responsible thing with minimal liability. They were sent on to the intended destination address of the SegWit transaction (if translated to BCH normal address).
This means BTC.TOP did not steal your coins and/or does not have custody of your funds!
But this does mean you now need to figure out how to get the private key associated with where they were sent -- in order to unlock the funds. (Which will be covered below).
Discussions on why this was the most responsible thing to do and why it was done this way are available upon request. Or you can search this subreddit to get to them.

Ok, so BTC.TOP doesn't have them -- who does?

You do (if they were sent to you)! Or -- the person / address they were sent to does!

HUH?

The Segwit transactions have a bad/crazy/messed-up format which contains an output (destination) which contains a hash of a public key inside. So they "sort of" contain a regular bitcoin address inside of them, with other Segwit garbage around them. This hash was decoded and translated to a regular BCH address, and the funds were sent there.
Again: The funds were forwarded on to a regular BCH address where they are safe. They are now guarded by a private key -- where they were not before (before they were "anyone can spend"). It can be argued this is the only reasonable thing to have done with them (legally and morally) -- continue to send them to their intended destination. This standard, if it's good enough for the US Post Office and Federal Mail, is good enough here. It's better than them being stolen.

Ok, I get it... they are on a regular BCH address now. The address of the destination of the Tx, is it?

Yes. So now a regular BCH private key (rather than anyone can spend) is needed to spend them further. Thus the Segwit destination address you sent them to initially was effectively translated to a BCH regular address. It's as if you posted a parcel with the wrong ZIP code on it -- but the USPS was nice enough to figure that out and send it to where you intended it to go.

Why do it this way and not return to sender?

Because of the ambiguity present-- it's not entirely clear which sender to return them to. There is too much ambiguity there, and would have led to many inputs not being recovered in a proper manner. More discussion on this is available upon request.

Purpose of this guide

This document explains how to:
Complications to watch out for:

Step 1: Checking where your coins went

To verify if this recovery touched one of your lost coins: look for the transaction that spent your coins and open it on bch.btc.com explorer.

Normal aka "P2PKH"

Let’s take this one for example.
Observe the input says:
P2SH 160014d376cf1baff9eeed943d58551d53c48377adb98c 
And the output says:
P2PKH OP_DUP OP_HASH160 d376cf1baff9eeed943d58551d53c48377adb98c OP_EQUALVERIFY OP_CHECKSIG 
Notice a pattern?
The fact that these two highlighted hexadecimal strings are the same means that the funds were forwarded to the identical public key, and can be spent by the private key (corresponding to that public key) if it is imported into a Bitcoin Cash wallet.

Multisig aka "P2SH"

If the input starts with “P2SH 220020…”, as in this example, then your segwit address is a script -- probably a multisignature. While the input says “P2SH 22002019aa2610492ee2c18605597136294596d4f0f9bc6ce0974ed3a975d65da4ca1e”, the output says “P2SH OP_HASH160 21bdc73fb15b3bb7bd1be365e92447dc2a44e662 OP_EQUAL”. These two strings actually correspond to the same script, but they are different in content and length due to segwit’s design. However, you just need to RIPEMD160 hash the first string and compare to the second -- you can check this by entering the input string (after the 220020 part) into this website’s Binary Hash field and checking the resulting RIPEMD160 hash. The resulting hash is 21bdc73fb15b3bb7bd1be365e92447dc2a44e662, which corresponds to the output hex above, and this means the coins were forwarded to the same spending script but in "non-segwit form". You will need to re-assemble the same multi-signature setup and enough private keys on a Bitcoin Cash wallet. (Sorry for the succinct explanation here. Ask in the comments for more details perhaps.)

No match -- what?!

If the string does not match (identically in the Normal case above, or after properly hashing in the Multisig case above), then your coins were sent elsewhere, possibly even taken by an anonymous miner. :'(

Step 2: How To Do the Recovery

Recover "Normal" address transactions (P2PKH above)

This is for recoveries where the input string started with “160014”.
Option 1 (BIP39 seed):
Option 2 (single key):
Option 3 (xprv -- many keys):
Code:
mkey = "yprvAJ48Yvx71CKa6a6P8Sk78nkSF7iqqaRob1FN7Jxsqm3L52K8XmZ7EtEzPzTUWXAaHNfN4DFAuP4cdM38yrE6j3YifV8i954hyD5rhPyUNVP" from electroncash.bitcoin import DecodeBase58Check, EncodeBase58Check EncodeBase58Check(b'\x04\x88\xad\xe4'+DecodeBase58Check(mkey)[4:]) 
Option 4 (hardware wallet):

How to Recover Multisignature wallets (P2WSH-in-P2SH in segwit parlance)

This is for recoveries where the input string started with "220020.
Please read the above instructions for how to import single keys. You will need to do similar but taking care to reproduce the same set of multisignature keys as you had in the BTC wallet. Note that Electron Cash does not support single-key multisignature, so you need to use the BIP39 / xprv approach.
If you don’t observe the correct address in Electron Cash, then check the list of public keys by right clicking on an address, and compare it to the list seen in your BTC wallet. Also ensure that the number of required signers is identical.
submitted by NilacTheGrim to btc [link] [comments]

A reminder why CryptoNote protocol was created...

CryptoNote v 2.0 Nicolas van Saberhagen October 17, 2013
1 Introduction
“Bitcoin” [1] has been a successful implementation of the concept of p2p electronic cash. Both professionals and the general public have come to appreciate the convenient combination of public transactions and proof-of-work as a trust model. Today, the user base of electronic cash is growing at a steady pace; customers are attracted to low fees and the anonymity provided by electronic cash and merchants value its predicted and decentralized emission. Bitcoin has effectively proved that electronic cash can be as simple as paper money and as convenient as credit cards.
Unfortunately, Bitcoin suffers from several deficiencies. For example, the system’s distributed nature is inflexible, preventing the implementation of new features until almost all of the net- work users update their clients. Some critical flaws that cannot be fixed rapidly deter Bitcoin’s widespread propagation. In such inflexible models, it is more efficient to roll-out a new project rather than perpetually fix the original project.
In this paper, we study and propose solutions to the main deficiencies of Bitcoin. We believe that a system taking into account the solutions we propose will lead to a healthy competition among different electronic cash systems. We also propose our own electronic cash, “CryptoNote”, a name emphasizing the next breakthrough in electronic cash.
2 Bitcoin drawbacks and some possible solutions
2.1 Traceability of transactions
Privacy and anonymity are the most important aspects of electronic cash. Peer-to-peer payments seek to be concealed from third party’s view, a distinct difference when compared with traditional banking. In particular, T. Okamoto and K. Ohta described six criteria of ideal electronic cash, which included “privacy: relationship between the user and his purchases must be untraceable by anyone” [30]. From their description, we derived two properties which a fully anonymous electronic cash model must satisfy in order to comply with the requirements outlined by Okamoto and Ohta:
Untraceability: for each incoming transaction all possible senders are equiprobable.
Unlinkability: for any two outgoing transactions it is impossible to prove they were sent to the same person.
Unfortunately, Bitcoin does not satisfy the untraceability requirement. Since all the trans- actions that take place between the network’s participants are public, any transaction can be unambiguously traced to a unique origin and final recipient. Even if two participants exchange funds in an indirect way, a properly engineered path-finding method will reveal the origin and final recipient.
It is also suspected that Bitcoin does not satisfy the second property. Some researchers stated ([33, 35, 29, 31]) that a careful blockchain analysis may reveal a connection between the users of the Bitcoin network and their transactions. Although a number of methods are disputed [25], it is suspected that a lot of hidden personal information can be extracted from the public database.
Bitcoin’s failure to satisfy the two properties outlined above leads us to conclude that it is not an anonymous but a pseudo-anonymous electronic cash system. Users were quick to develop solutions to circumvent this shortcoming. Two direct solutions were “laundering services” [2] and the development of distributed methods [3, 4]. Both solutions are based on the idea of mixing several public transactions and sending them through some intermediary address; which in turn suffers the drawback of requiring a trusted third party. Recently, a more creative scheme was proposed by I. Miers et al. [28]: “Zerocoin”. Zerocoin utilizes a cryptographic one-way accumulators and zero-knoweldge proofs which permit users to “convert” bitcoins to zerocoins and spend them using anonymous proof of ownership instead of explicit public-key based digital signatures. However, such knowledge proofs have a constant but inconvenient size - about 30kb (based on today’s Bitcoin limits), which makes the proposal impractical. Authors admit that the protocol is unlikely to ever be accepted by the majority of Bitcoin users [5].
2.2 The proof-of-work function
Bitcoin creator Satoshi Nakamoto described the majority decision making algorithm as “one- CPU-one-vote” and used a CPU-bound pricing function (double SHA-256) for his proof-of-work scheme. Since users vote for the single history of transactions order [1], the reasonableness and consistency of this process are critical conditions for the whole system.
The security of this model suffers from two drawbacks. First, it requires 51% of the network’s mining power to be under the control of honest users. Secondly, the system’s progress (bug fixes, security fixes, etc...) require the overwhelming majority of users to support and agree to the changes (this occurs when the users update their wallet software) [6].Finally this same voting mechanism is also used for collective polls about implementation of some features [7].
This permits us to conjecture the properties that must be satisfied by the proof-of-work pricing function. Such function must not enable a network participant to have a significant advantage over another participant; it requires a parity between common hardware and high cost of custom devices. From recent examples [8], we can see that the SHA-256 function used in the Bitcoin architecture does not posses this property as mining becomes more efficient on GPUs and ASIC devices when compared to high-end CPUs.
Therefore, Bitcoin creates favourable conditions for a large gap between the voting power of participants as it violates the “one-CPU-one-vote” principle since GPU and ASIC owners posses a much larger voting power when compared with CPU owners. It is a classical example of the Pareto principle where 20% of a system’s participants control more than 80% of the votes.
One could argue that such inequality is not relevant to the network’s security since it is not the small number of participants controlling the majority of the votes but the honesty of these participants that matters. However, such argument is somewhat flawed since it is rather the possibility of cheap specialized hardware appearing rather than the participants’ honesty which poses a threat. To demonstrate this, let us take the following example. Suppose a malevolent individual gains significant mining power by creating his own mining farm through the cheap hardware described previously. Suppose that the global hashrate decreases significantly, even for a moment, he can now use his mining power to fork the chain and double-spend. As we shall see later in this article, it is not unlikely for the previously described event to take place.
2.3 Irregular emission
Bitcoin has a predetermined emission rate: each solved block produces a fixed amount of coins. Approximately every four years this reward is halved. The original intention was to create a limited smooth emission with exponential decay, but in fact we have a piecewise linear emission function whose breakpoints may cause problems to the Bitcoin infrastructure.
When the breakpoint occurs, miners start to receive only half of the value of their previous reward. The absolute difference between 12.5 and 6.25 BTC (projected for the year 2020) may seem tolerable. However, when examining the 50 to 25 BTC drop that took place on November 28 2012, felt inappropriate for a significant number of members of the mining community. Figure 1 shows a dramatic decrease in the network’s hashrate in the end of November, exactly when the halving took place. This event could have been the perfect moment for the malevolent individual described in the proof-of-work function section to carry-out a double spending attack [36]. Fig. 1. Bitcoin hashrate chart (source: http://bitcoin.sipa.be)
2.4 Hardcoded constants
Bitcoin has many hard-coded limits, where some are natural elements of the original design (e.g. block frequency, maximum amount of money supply, number of confirmations) whereas other seem to be artificial constraints. It is not so much the limits, as the inability of quickly changing them if necessary that causes the main drawbacks. Unfortunately, it is hard to predict when the constants may need to be changed and replacing them may lead to terrible consequences.
A good example of a hardcoded limit change leading to disastrous consequences is the block size limit set to 250kb1. This limit was sufficient to hold about 10000 standard transactions. In early 2013, this limit had almost been reached and an agreement was reached to increase the limit. The change was implemented in wallet version 0.8 and ended with a 24-blocks chain split and a successful double-spend attack [9]. While the bug was not in the Bitcoin protocol, but rather in the database engine it could have been easily caught by a simple stress test if there was no artificially introduced block size limit.
Constants also act as a form of centralization point. Despite the peer-to-peer nature of Bitcoin, an overwhelming majority of nodes use the official reference client [10] developed by a small group of people. This group makes the decision to implement changes to the protocol and most people accept these changes irrespective of their “correctness”. Some decisions caused heated discussions and even calls for boycott [11], which indicates that the community and the developers may disagree on some important points. It therefore seems logical to have a protocol with user-configurable and self-adjusting variables as a possible way to avoid these problems.
2.5 Bulky scripts
The scripting system in Bitcoin is a heavy and complex feature. It potentially allows one to create sophisticated transactions [12], but some of its features are disabled due to security concerns and some have never even been used [13]. The script (including both senders’ and receivers’ parts) for the most popular transaction in Bitcoin looks like this: OP DUP OP HASH160 OP EQUALVERIFY OP CHECKSIG. The script is 164 bytes long whereas its only purpose is to check if the receiver possess the secret key required to verify his signature.
Read the rest of the white paper here: https://cryptonote.org/whitepaper.pdf
submitted by xmrhaelan to CryptoCurrency [link] [comments]

This is how we will recover coins sent to the wrong address or an unowned address

Don't worry, I'm NOT advocating that transactions should be reversible.
Many of us have accidentally sent coins to the wrong address or an unowned address, resulting in those coins being permanently unrecoverable and unspendable. I haven't made this mistake (yet), but damn it makes me nervous when I send larger transactions.
Unfortunately, we'll never be able to revert those past mistakes, but with a small change to the bitcoin protocol, we can make it so that we can recover the coins when we make this sort of mistake in the future.
Please let me know your thoughts about my solution below, and if something like this is already in the works.

The solution, conceptually

If everybody knew everyone else's public keys, we could prevent these permanent mistakes with multisig scripts. The change I'm proposing will make it so we can prevent the mistakes without knowing each other's public keys, but I'll explain it in terms of multisig, because the solution is conceptually the same, and easier to explain:
Instead of sending coins directly to a recipient address, send your coins to a 1-of-2 multisig account, shared by both you and the recipient.
This means that effectively, the transaction is "cancellable", but only until the recipient sends the coins to his own account. At that point the coins are irreversibly his.
The downside of this is that when receiving a payment, you must explicitly accept it before the coins are truly yours -- you should not consider the coins as yours until you do this. The upside is that it guarantees that coins are never lost at inactive addresses.

Problems that this solves

  1. Sending to an unowned address (base58Check almost always protects against this)
  2. Sending to an address that was owned, but the private keys were lost and nobody has control of the address anymore
  3. Sending to the wrong (but owned) address, unless the unintended recipient is quick to claim the coins
  4. Sending your coins to the wrong address on an exchange (i.e. an address for a forked blockchain)

Implementation and technical details

We can accomplish the above without knowledge of each others' public keys, if we use a custom pubkey script. Nodes only accept transactions with standard pubkey scripts, so we'd need to define a new standard script.
The typical P2PKH script looks like this:
scriptPubKey: OP_DUP OP_HASH160 OP_DUP  OP_EQUALVERIFY OP_CHECKSIG scriptSig:   
The new standard script I'm proposing is this:
scriptPubKey: OP_DUP OP_HASH160 OP_DUP  OP_EQUAL OP_SWAP  OP_EQUAL OP_ADD OP_VERIFY OP_CHECKSIG ( would be your address, and  would be the recipient's address) scriptSig:   
This script allows the coins to be spent by either the owner of or .
I call this new transaction type Pay To Either Public Key Hash (P2EPKH), or colloquially, "fuck-up protection".
Of course, wallets would have to be able to recognize the new transaction type, and offer controls to claim coins from incoming P2EPKH transactions or to cancel unclaimed P2EPKH transactions.

Feedback, please.

What do you all think? Is this generally a decent idea? Has this idea been floated around before? Is there another solution for this issue in the works? If this is a good idea, how do I get the attention of the devs?
submitted by ransoing to btc [link] [comments]

As part of my ongoing effort to develop stupid shit for Garlicoin, I present you: W-addresses!

“Wait, what?!” I hear you asking? Well…(buckle up, this is another one of my technical posts that goes on, and on…)
For some time now, I have been using native SegWit (Pay-to-Witness-Public-Key-Hash, P2WPKH) transactions for myself. Mostly because they have a 75% fee subsidy on signature data (which comes out on ~50% fee subsidy on the entire transaction, depending on the type of transaction) and I am dutch after all ;-)
It turns out that Garlicoin Core kind of supports them and kind of does not. If you manually register the transaction redeem script to your wallet (using the addwitnessaddress command) it will start recognizing them on the blockchain but gets kind of confused on how to deal with them, so it registers them all as ‘change’ transactions. Still, this means you can receive coins using these types of transactions and pay with them in all ways you can with regular Garlicoins, except your transactions are cheaper.
However, sending coins using native SegWit is quite a hassle. You can basically only do it by creating your own raw transactions (createrawtransaction, edit it to make it native SegWit, fundrawtransaction, signrawtransaction, sendrawtransaction). On top of this, any change address the wallet creates are still legacy/normal Garlicoin addresses, so you will end up with a bunch of unspent transaction outputs (UTXOs) for which you have to pay full fee anyway. I decided we (I) could do better than this.
But first a few steps back. What is this native SegWit anyway and weren’t people already using SegWit? Wasn’t there a user that just after mainnet launched accidentally made a SegWit transaction? So what the hell am I talking about?
To understand this, you will need to know a few things about what SegWit is and how Bitcoin Garlicoin transactions work in general. Note that this bit gets really technical, so if you are not interested, you might want to skip ahead. A lot.
First thing to understand is that addresses are not really a thing if you look at the blockchain. While nodes and explorers will interpret parts of a transaction as addresses, in reality addresses are just an abstraction around Bitcoin Script and an easy way send coins instead of asking people “hey, can you send some coins to the network in such a way that only the private key that corresponds to public key XYZ can unlock them?”. Let’s look at an example: say I ask you to send coins to my address GR1Vcgj2r6EjGQJHHGkAUr1XnidA19MrxC. What ends up happening is that you send coins out a transaction where you say that the coin are locked in the blockchain and can only be unlocked by successfully executing the following script:
OP_DUP OP_HASH160 4e9856671c3abb2f03b7d80b9238e8f5ecd9f050 OP_EQUALVERIFY OP_CHECKSIG
Now, without getting too technical, this means something like this:
As you can see, the address actually represents a well-known piece of script. This start making sense if you look at the decoded address:
26 4E9856671C3ABB2F03B7D80B9238E8F5ECD9F050 F8F1F945
The first byte (0x26, or 38) is the version byte. This tells the clients how the interpret the rest of the script. In our case 38 means Pay-to-Public-Key-Hash (P2PKH), or in other words the script mentioned above. The part after that is just the SHA1 hash of the public key and the final 4 bytes are a checksum to verify you did not make a typo when entering the address.
Enter SegWit. What SegWit exactly is depends on who you are talking to, however it mostly is a different transaction format/protocol. The main change of SegWit is that signature data is not longer included in the transaction (fixing transaction malleability). Instead transaction data is sent separate from the transaction itself and outside of the (main) blocks.
This is not really that much of an issue, except for the fact that people wanted to enable SegWit as a soft-fork instead of a hard-fork. This means that somehow unupgraded nodes needed a way to deal with these new transaction types without being able to verify them.
The solution turned out to be to make use of an implementation detail of Bitcoin Script: if a piece of script executes without any errors, the last bit of data determines whether the transaction is valid (non-zero) or invalid (zero). This is what they used to implement SegWit.
So what does this look like? Well, you might be surprised how simple a P2WPKH (the SegWit way of doing a P2PKH transaction) script looks:
00 4e9856671c3abb2f03b7d80b9238e8f5ecd9f050
Yes. That’s it.
The first byte is the Witness program version byte. I.e. it tells you how the other data should be interpreted (very similar to how addresses work). Then there is the hash of the public key. As you can see, SegWit does not actually use Bitcoin Script. Mostly because it needs old nodes to ‘just accept’ its transactions. However interestingly enough, while the transaction format changed, the transaction data is pretty much the same:
This means that these kind of SegWit transactions need a new way of addressing them. Now, you might think that this is where the ‘3’ addresses on Bitcoin or the ‘M’ addresses on Garlicoin come in. However, that is not the case.
These addresses are what are called Pay-to-Script-Hash (P2SH) addresses. There scrypt is like this:
OP_HASH160 35521b9e015240942ad6b0735c6e7365354b0794 OP_EQUAL
Huh? Yeah, these are a very special type of transactions, that kind of go back to the “hey, can you send some coins to the network in such a way that only the private key that corresponds to public key XYZ can unlock them?” issue.
These transactions are a way to have arbitrary smart contracts (within the limits of Bitcoin Script) to determine whether a transaction output can be spend or not without the sender of the coins having to deal with your scripts. Basically they use a hash of the “real” script, which whoever owns the coins has to provide when they want to spend them, as well as the specific inputs required for a script. This functionality is for example used in multi-signature (MultiSig) wallets, without requiring someone sending money to these wallets having to deal with random bits of information like how many signatures are required, how many private keys belong to the wallet, etc.
This same method is used for so called P2SH-wrapped SegWit transactions (or P2SH-P2WPKH). Consider our earlier SegWit transaction output script:
00 4e9856671c3abb2f03b7d80b9238e8f5ecd9f050
Or 00144e9856671c3abb2f03b7d80b9238e8f5ecd9f050 in low-level hex. The P2SH script for this would be:
OP_HASH160 a059c8385124aa273dd3feaf52f4d94d42f01796 OP_EQUAL
Which would give us address MNX1uHyAQMXsGiGt5wACiyMUgjHn1qk1Kw. This is what is now widely known and used as SegWit. But this is P2SH-wrapper SegWit, not native or "real" SegWit. Native would be using the data-only SegWit script directly.
The reason for using the P2SH variant is mostly about compatibility. While SegWit nodes understand these newer transactions, they were never officially assigned a way to convert them to addresses. Hence, they will show up in blockchain explorers as Unparsed address [0] or something similar. Then there is also the whole thing about old nodes and relaying non-standard transactions, but I will skip that bit for now.
Bitcoin is using/going to use new BECH32 addresses for native SegWit transactions, which looks completely different from the old Base-58 encoded addresses. However, right now, especially on Garlicoin, you cannot really use them and have to use the P2SH variant. But why not use these new cool transaction types without having to deal with all that useless and complex P2SH wrapping, right? Right? …
Well, I went ahead and gave them their (unofficial) address space.
So last thursday I made some changes to Garlicoin Core, to make dealing with these native SegWit transaction a lot easier. In short, the changes consist of:
  • Assigning address version byte 73 to them, in other words addresses starting with a ‘W’ (for ‘witness’).
  • Allowing the use of ‘W’ addresses when sending coins.
  • Make the wallet automatically recognize the SegWit transaction type for any newly generated address.
  • Add the getwitnessaddress command, which decodes a version 38 ‘G’ address and re-encodes the same data as a version 73 ‘W’ address (unfortunately it is not as simple as just changing the first letter). Note that this can be any address, not just your own. (That said, you should not send SegWit transactions to people not expecting them, always use the address given to you.)
  • Added the usewitnesschangeaddress configuration setting, to automatically use the cheaper SegWit transaction outputs for transaction change outputs.
  • (Since using the 'W' address only changes the way coins are sent to you and the private key used for both transaction types is the same:) When receiving coins they show all up under the original ‘G’ address, whether a SegWit or legacy/normal transaction type was used. The idea behind this is that both are actually the same "physical" (?) address, just to the way to coins to it differs. Address book entries are also merged and default to the ‘G’ address type.
Anyway, I don’t expect people to actually use this or it getting merged into mainline or anything. I actually mostly made this for myself, but thought I should share anyway. I guess it was also a nice opportunity to talk a bit about transactions and SegWit. :-)
Btw, I also changed my pool to allow mining to ‘W’ addresses, to make coin consolidation cheaper (due to the SegWit fee subsidy). Right now this is only for instant payout though (as I would have to update the wallet node the pool is using for daily payout, which I haven’t done yet).
Also note that you can actually mine to a ‘W’ address (and therefore use cheaper transactions) even if you are running the official, non-patched version of Garlicoin Core, however:
  • You need to manually convert your ‘G’ address to a ‘W’ address.
  • You need to run the addwitnessaddress command (Help -> Debug Window -> Console) to make the wallet recognize SegWit transactions (you can ignore the ‘M’ address it produces).
  • The wallet might get a bit confused as it does not really understand how it got the coins. This is mostly notable in the ‘Coin Control’ window if you have it enabled. Apart from that everything should still work though.
submitted by nuc1e4r5n4k3 to garlicoin [link] [comments]

The Problems with Segregated Witness

MORE: https://medium.com/the-publius-letters/segregated-witness-a-fork-too-far-87d6e57a4179
... 3. The Problems with Segregated Witness
While it is true that Segregated Witness offers some improvements to the Bitcoin network, we shall now examine why these benefits are not nearly enough to outweigh the dangers of deploying SW as a soft fork.
3.1 SW creates a financial incentive for bloating witness data
SW allows for a theoretical maximum block size limit of ~4 MB. However, this is only true if the entire block was occupied with transactions of a very small ‘base size’ (e.g. P2WPKH with 1 input, 1 output). In practice, based on the average transaction size today and the types of transactions made, the block size limit is expected to have a maximum limit of ~1.7 MB post-SW (Figure 10; assuming all transactions are using SW unspent outputs — a big assumption).
However, the 4 MB theoretical limit creates a key problem. Miners and full node operators need to ensure that their systems can handle the 4 MB limit, even though at best they will only be able to support ~40% of that transaction capacity. Why? Because there exists a financial incentive for malicious actors to design transactions with a small base size but large and complex witness data. This is exacerbated by the fact that witness scripts (i.e. P2SH-P2WSH or P2SH-P2WSH) will have higher script size limits that normal P2SH redeem scripts (i.e., from 520 bytes to 3,600 bytes [policy] or 10,000 bytes [consensus]). These potential problems only worsen as the block size limit is raised in the future, for example a 2 MB maximum base size creates an 8 MB adversarial case. This problem hinders scalability and makes future capacity increases more difficult.
3.2 SW fails to sufficiently address the problems it intends to solve
If SW is activated by soft fork, Bitcoin will effectively have two classes of UTXOs (non-SW vs SW UTXOs), each with different security and economic properties. Linear signature hashing and malleability fixes will only be available to the SW UTXO. Most seriously, there are no enforceable constraints to the growth of the non-SW UTXO. This means that the network (even upgraded nodes) are still vulnerable to transaction malleability and quadratic signature hashing from non-SW outputs that existed before or created after the soft fork.
The lack of enforceability that comes with a soft fork leaves Bitcoin users and developers vulnerable to precisely the type of attacks SW is designed to prevent. While spending non-SW outputs will be comparatively more expensive than SW outputs, this remains a relatively weak disincentive for a motivated attacker.
It is also unclear what proportion of the total number of the legacy UTXO will migrate to SW outputs. Long-term holders of Bitcoin, such as Satoshi Nakamoto (presumed to be in possession of ~1 million Bitcoin), may keep their coins in non-SW outputs (although it would be a significant vote of confidence in SW by Nakamoto if they were to migrate!). This makes future soft or hard forks to Bitcoin more difficult as multiple classes of UTXOs must now be supported to prevent coins from being burned or stolen.
One key concern is that the coexistence of two UTXO types may tempt developers and miners in the future to destroy the non-SW UTXO. Some may view this as an unfounded concern, but the only reason that this is worth mentioning in this article are the comments made by influential individuals associated with Bitcoin Core: Greg Maxwell has postulated that “abandoned UTXO should be forgotten and become unspendable,” and Theymos has claimed “the very-rough consensus is that old coins should be destroyed before they are stolen to prevent disastrous monetary inflation.”
As the security properties of SW outputs are marginally better than non-SW outputs, it may serve as a sufficient rationalization for this type of punitive action.
The existence of two UTXO types with different security and economic properties also deteriorates Bitcoin’s fungibility. Miners and fully validating nodes may decide not to relay, or include in blocks, transactions that spend to one type or the other. While on one hand this is a positive step towards enforceability (i.e. soft enforceability), it is detrimental to unsophisticated Bitcoin users who have funds in old or non-upgraded wallets. Furthermore, it is completely reasonable for projects such as the lightning network to reject forming bidirectional payment channels (i.e. a multisignature P2SH address) using non-SW P2SH outputs due to the possibility of malleability. Fundamentally this means that the face-value of Bitcoin will not be economically treated the same way depending on the type of output it comes from.
It is widely understood in software development that measures which rely on the assumption of users changing their behavior to adopt better security practices are fundamentally doomed to fail; more so when the unpatched vulnerabilities are permitted to persist and grow. An example familiar to most readers would be the introduction and subsequent snail’s pace uptake of HTTPS.
3.3 SW places complex requirements on developers to comply while failing to guarantee any benefits
SW as a soft fork brings with it a mountain of irreversible technical debt, with multiple opportunities for developers to permanently cause the loss of user funds. For example, the creation of P2SH-P2WPKH or P2SH-P2WSH addresses requires the strict use of compressed pubkeys, otherwise funds can be irrevocably lost. Similarly, the use of OP_IF, OP_NOTIF, OP_CHECKSIG, and OP_CHECKMULTISIG must be carefully handled for SW transactions in order to prevent the loss of funds. It is all but certain that some future developers will cause user loss of funds due to an incomplete understanding of the intricacies of SW transaction formats.
In terms of priorities, SW is not a solution to any of the major support ticket issues that are received daily by Bitcoin businesses such as BitPay, Coinbase, Blockchain.info, etc. The activation of SW will not increase the transaction capacity of Bitcoin overnight, but only incrementally as a greater percentage of transactions spend to SW outputs. Moreover, the growing demand for on-chain transactions may very well exceed the one-off capacity increase as demonstrated by the increasing frequency of transaction backlogs.
In contrast to a basic block size increase (BBSI) from a coordinated hard fork, many wallets and SPV clients will immediately benefit from new capacity increases without the need to rewrite their own software as they must do with SW.. With a BBSI, unlike SW, there are no transaction format or signature changes required on the part of Bitcoin-using applications.
Based on previous experience with soft forks in Bitcoin, upgrades tend to roll-out within the ecosystem over some time. At the time of this writing, only 28 out of the 78 business and projects (36%) who have publicly committed to the upgrade are SW-compatible. Any capacity increase that Bitcoin businesses and users of the network desire to ease on-chain fee pressure will unlikely be felt for some time, assuming that transaction volume remains unchanged and does not continue growing. The unpredictability of this capacity increase and the growth of the non-SW UTXO are particularly troubling for Bitcoin businesses from the perspectives of user-growth and security, respectively. Conversely, a BBSI delivers an immediate and predictable capacity increase.
The voluntary nature of SW upgrades is subject to the first-mover game theory problem. With a risky upgrade that moves transaction signatures to a new witness field that is hidden to some nodes, the incentive for the rational actor is to let others take that risk first, while the rational actor sits back, waits, and watches to see if people lose funds or have problems. Moreover, the voluntary SW upgrade also suffers from the free-rider game theory problem. If others upgrade and move their data to the witness field, one can benefit even without upgrading or using SW transactions themselves. These factors further contribute to the unpredictable changes to Bitcoin’s transaction capacity and fees if SW is adopted via a soft fork.
3.4 Economic distortions and price fixing
Segregated Witness as a soft fork alters the economic incentives that regulate access to Bitcoin’s one fundamental good: block-size space. Firstly, it subsidises signature data in large/complex P2WSH transactions (i.e., at ¼ of the cost of transaction/UTXO data). However, the signatures are more expensive to validate than the UTXO, which makes this unjustifiable in terms of computational cost. The discount itself appears to have been determined arbitrarily and not for any scientific or data-backed reasoning.
Secondly, the centralized and top-down planning of one of Bitcoin’s primary economic resources, block space, further disintermediates various market forces from operating without friction. SW as a soft fork is designed to preserve the 1 MB capacity limit for on-chain transactions, which will purposely drive on-chain fees up for all users of Bitcoin. Rising transaction fees, euphemistically called a ‘fee market’, is anything but a market when one side — i.e. supply — is fixed by central economic planners (the developers) who do not pay the costs for Bitcoin’s capacity (the miners). Economic history has long taught us the results of non-market intervention in the supply of goods and services: the costs are externalised to consumers. The adoption of SW as a soft fork creates a bad precedent for further protocol changes that affirm this type of economic planning.
3.5 Soft fork risks
In this section we levy criticisms of soft forks more broadly when they affect the protocol and economic properties of Bitcoin to the extent that SW does. In this case, a soft fork reduces the security of full nodes without the consent of the node operator. The SW soft fork forces node operators either to upgrade, or to unconditionally accept the loss of security by being downgraded to a SPV node.
Non-upgraded nodes further weaken the general security of Bitcoin as a whole through the reduction of the number of fully validating nodes on the network. This is because non-upgraded nodes will only perform the initial check to see if the redeem script hash matches the pubkey script hash of the unspent output. This redeem script may contain an invalid witness program, for P2WSH transactions, that the non-upgraded node doesn’t know how to verify. This node will then blindly relay the invalid transaction across the network.
SW as a soft fork is the opposite of anti-fragile. Even if the community wants the change (i.e., an increase in transaction capacity), soft-forking to achieve these changes means that the miners become the key target of lobbying (and they already are). Soft forks are risky in this context because it becomes relatively easy to change things, which may be desirable if the feature is both minor and widely beneficial. However, it is bad in this case because the users of Bitcoin (i.e. everyone else but the miners) are not given the opportunity to consent or opt-out, despite being affected the most by such a sweeping change. This can be likened to a popular head of state who bends the rules of jurisprudence to bypass slow legal processes to “get things done.” The dangerous precedent of taking legal shortcuts is not of concern the masses until a new, less popular leader takes hold of the reigns, and by then it is too late to reverse. In contrast, activating SW via a hard fork ensures that the entire community, not just the miners, decide on changes made to the protocol. Users who unequivocally disagree with a change being made are given the clear option not to adopt the change — not so with a soft fork.
3.6 Once activated, SW cannot be undone and must remain in Bitcoin codebase forever.
If any critical bugs resulting from SW are discovered down the road, bugs serious enough to contemplate rolling it back, then anyone will be able to spend native SW outputs, leading to a catastrophic loss of funds. ...
...
Conclusion
Segregated Witness is the most radical and irresponsible protocol upgrade Bitcoin has faced in its eight year history. The push for the SW soft fork puts Bitcoin miners in a difficult and unfair position to the extent that they are pressured into enforcing a complicated and contentious change to the Bitcoin protocol, without community consensus or an honest discussion weighing the benefits against the costs. The scale of the code changes are far from trivial — nearly every part of the codebase is affected by SW.
While increasing the transaction capacity of Bitcoin has already been significantly delayed, SW represents an unprofessional and ineffective solution to both transaction malleability and scaling. As a soft fork, SW introduces more technical debt to the protocol and fundamentally fails to achieve its design purpose. As a hard fork, combined with real on-chain scaling, SW can effectively mitigate transaction malleability and quadratic signature hashing. Each of these issues are too important for the future of Bitcoin to gamble on SW as a soft fork and the permanent baggage that comes with it.
As much as the authors of this article desire transaction capacity increases, it is far better to work towards a clean technical solution to malleability and scaling than to further encumber the Bitcoin protocol with permanent technical debt. ...
MORE: https://medium.com/the-publius-letters/segregated-witness-a-fork-too-far-87d6e57a4179
submitted by german_bitcoiner to btc [link] [comments]

Please Protect Consumers by Using Stealth Addressing

It's recently been brought to attention that various companies have been heavy handed in their restrictions of how one may spend their purchased coins. I'm writing this up so that people can have a basic understanding of stealth addressing and how it works. If you'd like more details on the cryptography behind stealth addresses, please refer yourself to 13.4.3 of Wiley's Understanding Bitcoin: Cryptography, Engineering and Economics.
A stealth address looks like this: vJmwY32eS5VDC2C4GaZyXt7i4iCjzSMZ1XSd6KbkA7QbGE492akT2eZZMjCwWDqKRSYhnSA8Bgp78KeAYFVCi8ke5mELdoYMBNep7L
When you send funds to a stealth address, you create a data containing (OP_RETURN) output and a normal output to a one-time use Bitcoin address. The latter output contains the money you actually wish to send, while the former output contains some data which looks, to observers of the blockchain, like a bunch of indecipherable garbage.
Here's an example:
Tx hash 6ea5c6f1a97f382f87523d13ef9f2ef17b828607107efdbba42a80b8a6555356 https://blockchain.info/tx/6ea5c6f1a97f382f87523d13ef9f2ef17b828607107efdbba42a80b8a6555356
So, when you send money from Bob to Alice using a stealth address, what's basically going on from a privacy perspective?
To everyone else observing, it's impossible to tell that Alice was sent money. The only thing that they can tell is that Bob sent money to a stealth output, and that's if Bob himself didn't receive his funds as the result of stealth output and his address is somehow already known.
Using stealth addresses, it will be impossible for someone to tell where your money is being sent. The only thing obviously visible is the amount sent. In the future, a Bitcoin sidechain, such as that proposed by andytoshi and gmaxwell, may have mandatory stealth addressing as found in altcoins such as Monero; however, the technology is currently available for use in Bitcoin using simple OP_RETURN scripts.
There is a downside to this technology: to receive coins, you need to scan every incoming Bitcoin transaction to see if it might have an output belonging to you. However, I'm sure if you care about the privacy of your customers and their ability to be able to send funds to you in the future, the benefits more than outweigh the costs!
Current software/clients supporting stealth transactions include:
Hopefully, more soon!
Additional, for free references if you don't want have access to the Wiley book:
https://wiki.unsystem.net/en/index.php/DarkWallet/Stealth
http://sx.dyne.org/stealth.html
submitted by therealtacotime to Bitcoin [link] [comments]

Cannot retrieve BCH from Bread Wallet

Trying to help a friend get this out, every time I try to send it via Bread the app crashes, on 2 different devices.
https://imgur.com/a/qb3u1
Tried this:
https://steemit.com/breadwallet/@patrickda/tutorial-receive-your-bitcoin-cash-from-a-breadwallet-with-bip39-tool-and-electroncash-wallet
and this:
https://checksig.org/how-to-split-your-bcc-bch-from-your-btc-xbt-using-electrum-cash-cb91ca4a5961
Nothing works. How can these fools at Bread claim to have a feature but all it ever does is crash the app?
submitted by supremejabar to Bitcoincash [link] [comments]

Defining bitcoin for lawyers

Hi guys,
I am in the process of writing a few legal articles on bitcoin, and I am looking to try and define what "bitcoin" itself is. The audience of this definition is non-technical, legal academics and practitioners.
I have prepared two definitions, the first a short "what do you have when you have a bitcoin" definition, and the second being a slightly more technical definition. I am wondering if you guys could check whether the definitions that I am proposing are not incorrect?
[edit: for the abundance of clarity - what I am trying to define is lowercase bitcoin - i.e. the unit, not Bitcoin, the system. What is important is what I actually "own" when I have a bitcoin]
Simple definition
  1. A bitcoin is a pairing of a locked unit in a ledger (the block chain) and the credentials required to transfer it (a signature that is a function of the holder’s public and private key, and the specified unit in the ledger)
  2. Upon registration of the transfer in the block chain, the credentials used by the transferor become ineffective, and the transferee’s credentials are replaced as the controlling credentials of the unit.
Do you think the contents of the brackets is necessary to make the definition clear, without scaring non-techies?
More technical definition
  1. A bitcoin is the pairing of a locked unit in the ledger (as recorded on the block chain), and the username (the public key/wallet address) and password (the private key) that enable a user to transfer it.
  2. If the putative owner of the bitcoin, who holds the correct credentials, transfers the bitcoin to another user, the destination wallet address, the quantum of the transfer as well as a signature are broadcasted. This signature is a (the op_checksig) “proof of ownership” of the unit in the ledger (a hash that is a function of the public key, private key and specific unit in the public ledger).
  3. This is verified by the bitcoin algorithm.
  4. Upon successful transfer (being written into the blockchain by the miners), the signature that was used by the transferor becomes ineffective, and the transferee’s credentials become the required credentials for a future transfer of the same unit.
I am also working on turning a description of the processes of bitcoin transactions into BPMN diagrams, and would love to know more about those as well!
I'd be grateful for any comments!
submitted by oatsandsugar to Bitcoin [link] [comments]

Fee larger than transaction

Today I wanted to send out the bitcoins that were accumulating on one of my wallets. I was receiving there micropaymants for web ads. Unfortunately I'm not able to send any of it out (a 0.05 in total, not much but still ~50 bucks). I'm using armory and it calculated the fee of over a 1BTC for it (like 20 times greater that the transaction amount!!!). I tried to decrease the transaction but no matter what I do I end up network rejecting my transaction. All the incoming transaction are for 0.0001 or slightly more. The rejected transactions are not very huge, the average looks like thsi:
Transaction: TxHash: 025c0ffe015a8e6a35a9e7bc9018e786194ef0e3a055c7507a38f840f5938902 (BE) Version: 1 nInputs: 3 nOutputs: 2 LockTime: 0 Inputs: PyTxIn: PrevTxHash: f405598c0580cea546c73a9ed5e52347f3a07a3cb4d8b01b50a647f7438458a9 (BE) TxOutIndex: 31 Script: (4830450220019b4a6a32918f3bf72b8e67ec55cb6cd3aa97fc30dc3c8794c2be) Sender: 1AsPzC53491jKTvwrUEZnvF6cgtXDWD8mX Seq: 4294967295 PyTxIn: PrevTxHash: 86ea39dc35303a47b57689acaa8f96274ff5cc2412bc5e4c254c15ce6bfa1321 (BE) TxOutIndex: 29 Script: (483045022100b29a0b29202e19f2dc651b3ec842a8b72a3d39c3f41d14ee9445) Sender: 1AsPzC53491jKTvwrUEZnvF6cgtXDWD8mX Seq: 4294967295 PyTxIn: PrevTxHash: dd9da02bbb566681162f9956f6c2d6e47d2d0428098a2c0aba9ba4cb25ddc91e (BE) TxOutIndex: 74 Script: (483045022100aab39ac4adba537d9d441b7f92f11b66554ff2573ba3871a2285) Sender: 1AsPzC53491jKTvwrUEZnvF6cgtXDWD8mX Seq: 4294967295 Outputs: TxOut: Value: 8780 (8.78e-05) Script: OP_DUP OP_HASH160 (1Dcu2y3eefKRVkJY7JSJeaouRyEnBYaWJt) OP_EQUALVERIFY OP_CHECKSIG TxOut: Value: 53270 (0.0005327) Script: OP_DUP OP_HASH160 (1N7afkxPv9b4CRaTwecqwHisRH7yMUPQvF) OP_EQUALVERIFY OP_CHECKSIG
Does it mean that the bitcoin if fubar? is there any way to actually make any use of such dust bitcoin wallets at all?
submitted by emsiak to Bitcoin [link] [comments]

Unconfirmed Bitcoin Problem

I posted this on another forum and was referred here to try to get a hold of a Bitcoin Developer to help solve my problem. IMO, there is a bug in the blockchain. Either the blockchain is reporting transactions to me that never existed, or I have unconfirmed transactions in my ledger that need to be confirmed and are not confirming. The transactions are from 2013 and 2014 when I first started mining.
I am running the latest version of Bitcoin Core, and have fully synced through the blockchain.
Background: Years ago I mined a little bit of BTC, and forgot about it. With the prices going astronomical I wanted to open my old wallet up and sell some. I opened it in Bitcoin Core and I can see a bunch of transactions, but they're all unconfirmed and my balance is reporting zero.
Address: 1BWCNpA3MGYHS3sbbVpGW7jY1Ean1Y3sX4
One of many transaction id's:
Status: 0/unconfirmed, not in memory pool Date: 1/23/2014 22:01 Credit: 0.10630472 BTC Net amount: +0.10630472 BTC Transaction ID: c16587ae806c2392635a20843a78f8f6a1275c6990a797f8266e3b9d8a29bd1e Transaction total size: 225 bytes Output index: 0
When I try to rebroadcast the raw transaction I get this...
Missing parents for c16587ae806c2392635a20843a78f8f6a1275c6990a797f8266e3b9d8a29bd1e while inserting: [c677f8172824b4bb761f0ce51e23235f4a6613c62e74e847936f95440fae6b6c]
If I decode it I get this...
{ "lock_time":0, "size":225, "inputs":[ { "prev_out":{ "index":0, "hash":"c677f8172824b4bb761f0ce51e23235f4a6613c62e74e847936f95440fae6b6c" }, "script":"47304402204f1602b609027990a8e17355bdb9d967882aed3ac85e06c9311d33a3228ba9d90220097941a24457d36508f8d17e94400184c849f44c48296aab09e4deb9d23e4e2f012103db4cc04dac3ee0cb4ab0afc108eb1f398ab659be127240a672b1abe139f84b60" } ], "version":1, "vin_sz":1, "hash":"c16587ae806c2392635a20843a78f8f6a1275c6990a797f8266e3b9d8a29bd1e", "vout_sz":2, "out":[ { "script_string":"OP_DUP OP_HASH160 7336d1277adaf305dddde5cedc686bb1e4988bda OP_EQUALVERIFY OP_CHECKSIG", "address":"1BWCNpA3MGYHS3sbbVpGW7jY1Ean1Y3sX4", "value":10630472, "script":"76a9147336d1277adaf305dddde5cedc686bb1e4988bda88ac" }, { "script_string":"OP_DUP OP_HASH160 95a28eec6c32896699df4ca36c880d7e42e504c5 OP_EQUALVERIFY OP_CHECKSIG", "address":"1EeCRLCksdBRJ7SUkAAFKk1TssVv62hoTQ", "value":89379528, "script":"76a91495a28eec6c32896699df4ca36c880d7e42e504c588ac" } ] }
Does this offer any more clues?
This is the raw transaction in Hex...
01000000016c6bae0f44956f9347e8742ec613664a5f23231ee50c1f76bbb4242817f877c6000000006a47304402204f1602b609027990a8e17355bdb9d967882aed3ac85e06c9311d33a3228ba9d90220097941a24457d36508f8d17e94400184c849f44c48296aab09e4deb9d23e4e2f012103db4cc04dac3ee0cb4ab0afc108eb1f398ab659be127240a672b1abe139f84b60ffffffff024835a200000000001976a9147336d1277adaf305dddde5cedc686bb1e4988bda88acc8d25305000000001976a91495a28eec6c32896699df4ca36c880d7e42e504c588ac00000000
I really need help ASAP so I can sell some coins. How do I resolve this issue, or at the bare minimum how do we correct the blockchain so this issue doesn't affect others? Any help is appreciated!
submitted by AmericasLastHope to Bitcoin [link] [comments]

Make 0-conf double spend infeasable by fixing the r value ahead of time, thereby putting the coins up for grabs when a second transaction is signed

I'm proposing a new kind of transaction that would make double spending 0-conf transactions uneconomical, and thus reducing the risk of double spending for the recipient.
Theory
Creating an ECDSA signature involves choosing a random number k. From this number, a value r is derived that is revealed as part of the signature. Quoting from Wikipedia:
As the standard notes, it is crucial to select different k for different signatures, otherwise the equation in step 6 can be solved for d_A, the private key
This is how a while back, coins were stolen from blockchain.info wallets because a bug in their random number generation caused the same k to be used, revealing the private key.
But we can use this to our advantage to discourage double spending. What if embedded in the unspent output is already determined what r value must be used to sign the transaction that spends those coins? That means that signing 2 different transactions that both spend the same output means revealing the private key and putting the coins up for grabs by anyone (effectively the next miner to mine a block).
This does not guarantee the recipient of a 0-conf transaction will receive their coins but it does make double spending uneconomical as the attacker would not get the coins back for themselves. This should reduce the risk of double spending for the recipient.
Implementation
We could introduce a new operation to the Bitcoin scripting language, similar to OP_CHECKSIG, but with one more input: the r value. When a transaction is created that spends such an output, the specified r must be used in the signature or the transaction is invalid.
One problem is that r must be determine by the recipient of the output while the output is created by the sender. I see 3 potential solutions for this:
  1. Use a P2SH address that has the r value embedded. The problem with this is that each output spent to this address would have to use the same r. So it is crucial that coins are spent to this address no more than once.
  2. When accepting coins, specify the r together with the address that you want to receive the coins to. For example by using the payment protocol BIP 70.
  3. When planning to do a 0-conf transaction, the sender should first move their coins into a new output that fixes the value of r in advance.
To me (2) seems the most promising.
Note: I'm no crypto expert so it would be great if someone could verify and confirm that this would work.
submitted by dskloet to btc [link] [comments]

Qtum - Quantum Chain Design Document

Serialization: Qtum Foundation Design Document

Foreword
In this series of articles, the Qtum Quantum Chain Foundation will make public its early design documents for the first time, hoping to help the community understand the design intent of Qtum and the implementation details of key technologies. The article will be based on the original design draft in order to restore the designer's original ideas. Follow-up Qtum project team will be further collation and interpretation, to help readers understand more technical details, so stay tuned.
The topics that may be included in this series include
* Qtum account abstraction layer AAL
* Qtum distributed autonomous protocol DGP
* Qtum wallet (qt, mobile wallet, etc.) and browser
* Add RPC call
* Mutual interest consensus mechanism MPoS
* Add opcode
* Integration of EVM and Qtum blockchain
* Qtum x86 virtual machine
* Others...
The Qtum quantum chain public number will be updated from time to time around the above topics to restore the history of the Qtum project and key technologies from scratch.
Qtum original design document summary -- Qtum new OPCODE
As we all know, Qtum uses the same UTXO model as Bitcoin. The original UTXO script was not compatible with the EVM account model, so Qtum added three OP_CREATE, OP_CALL, and OP_SPEND opcodes to the UTXO transaction script for the purpose of providing operational support for conversions between UTXO and EVM account models. The original names of the three opcodes are OP_EXEC(OP_CREATE), OP_EXEC_ASSIGN(OP_CALL) and OP_TXHASH(OP_SPEND), respectively.
The following is an excerpt of representative original documents for interested readers.
OP_CREATE (or OP_EXEC**)**
OP_CREATE (or OP_EXEC) is used to create a smart contract. The original design files (with Chinese translation) related to this opcode by the Qtum development team are as follows (ps: QTUM <#> or QTUMCORE<#> in the document numbering internal design documents. ):
QTUMCORE-3:Add EVM and OP_CREATE for contract execution Description:After this story, the EVM should be integrated and a very basic contract should be capable of being executed. There will be a new opcode, OP_CREATE (formerly OP_EXEC), which takes 4 arguments, in push order: 1. VM version (currently 1 is EVM) 2. Gas price (not yet used, anything is valid) 3. Gas limit (not yet used, assume very high limit) 4. bytecodeFor now it is OK that this script format be forced and mandatory for OP_CREATE transactions on the blockchain. (ie, only "standard" allowed on the blockchain) When OP_CREATE is encountered, it should execute the EVM and persist the contract to a database (triedb) Note: Make sure to follow policy for external code (commit vanilla unmodified code first, and then change it as needed) Make the EVM test suite functional as well (someone else can setup continuous integration changes for it though) 
The above document describes the functions required by OP_CREATE and the parameters used.

OP_CALL (or OP_EXEC_ASSIGN)

OP_CALL is used for contract execution and is one of the most commonly used opcodes. There are many descriptions in the original design document.
QTUM6: Implement calling environment info in EVM for OP_EXEC_ASSIGN 
Description: Solidity expects certain information to be pushed onto the stack as part of it's ABI. So, when data is sent into the contract using OP_EXEC_ASSIGN we need to make sure to provide this data. This data includes the Solidity "function selector" as well as ensuring the opcodes CALLER and ORIGIN function properly. This looks to be fairly easy, it should just be transferring some data from the Bitcoin stack to the EVM stack, and setting some fields for the origin info. However, this story should be split into multiple tasks and re-evaluated if it isn't easy. See also: https://github.com/ethereum/wiki/wiki/Ethereum-Contract-ABI For populating the CALLER and ORIGIN value, the following should be done: OP_EXEC_ASSIGN should take 2 extra arguments, SENDER and SENDER_SIGNATURE. Sender should be a public key. Sender Signature is the signature of all the vins for the current transaction, signed of course using the SENDER value.On the EVM side, CALLER's value will be a public key hash, ie, a hash of the SENDER public key. This public key hash should be compatible with Bitcoin's public key hash for it's standard version 1 addresses. IF the given SENDER_SIGNATURE does not match successfully, then the transaction should be considered invalid. If the SENDER public key is 0, then SENDER_SIGNATURE must also be 0, and the given CALLER opcode etc should just return 0.
The above document describes the OP_EXEC_ASSIGN calling environment information that needs to be implemented in the EVM.
QTUM8: Implement OP_EXEC_ASSIGN for sending money to contracts 
Description: A new opcode should be added, OP_EXEC_ASSIGN. This opcode should take these arguments in push order: # version number (VM version to use, currently just 1)

gas price (can be ignored for now)

gas refund script (can be ignored for now)

data (The data to hand to the smart contract. This will include things like the Solidity ABI Function Selector and other data that will later be available using the CALLERDATA EVM opcode) # smart contract address (txid + vout number)

It should return two values right now, 0 and 0. These are for spendable and out of gas, respectively. Making them spendable and dealing with out of gas will be in a future storyFor this story, the EVM contract does not actually need to be executed. This opcode should only be a placeholder so that the accounting system can determine how much money a contract has control of
The above document describes the OP_EXEC_ASSIGN implementation details.
QTUM15: Execute the relevant contract during OP_EXEC_ASSIGN 
Description: After this story is complete, when OP_EXEC_ASSIGN is reached, it should actually execute the contract whose address was given to it, passing the relevant data from the bitcoin script stack with it. Other data such as the caller and sender can be left for a later story. Making the CALLER, ORIGIN etc opcodes work properly will be fixed with a later story
The above document describes OP_EXEC_ASSIGN how the script runs the relevant contract code.
QTUM40: Allow contracts to send money to pubkeyhash addresses Description: We need to allow contracts to send money back to pubkeyhash addresses, so that people can withdraw their coins from contracts when allowed, etc. This should work similar to how version 0 contract sends work. Instead of using an OP_EXEC_ASSIGN vout though, we need to instead use a standard pubkeyhash script. So, upon spending to a pubkeyhash, the following transaction should be placed on the blockchain: vin: [standard contract OP_EXEC_ASSIGN inputs] ... vout: OP_DUP OP_HASH160 [pubKeyHash] OP_EQUALVERIFY OP_CHECKSIG change output - version 0 OP_EXEC_ASSIGN back to spending contract These outputs should be directly spendable in the wallet with no changes to the wallet code itself 
The above document describes how to allow contracts to send QTUM to pubkeyhash addresses.
QTUMCORE-10:Add ability for contracts to call other deployed contracts Description:Contracts should be capable of calling other contracts using a new opcode, OP_CALL. Arguments in push order:version (32 bit integer) gas price (64 bit integer) gas limit (64 bit integer) contract address (160 bits) data (any length) OP_CALL should ways return false for now. OP_CALL only results in contract execution when used in a vout; Similar to OP_CREATE, it uses the special rule to process the script during vout processing (rather than when spent as is normal in Bitcoin). Contract execution should only be triggered when the transaction script is in this standard format and has no extra opcodes. If OP_CALL is created that uses an invalid contract address, then no contract execution should take place. The transaction should still be valid in the blockchain however. If money was sent with OP_CALL, then that money (minus the gas fees) should result in a refund transaction to send the funds back to vin[0]'s vout script. The "sender" exposed to EVM should be the pubkeyhash spent by vin[0]. If the vout spent by vin[0] is not a pubkeyhash, then the sender should be 0.Funds can be sent to the contract using an OP_CALL vout. These funds will be handled by the account abstraciton layer in a different story, to expose this to the EVM. Multiple OP_CALLS can be used in a single transaction. However, before contract execution, the gas price and gas limit of each OP_CALL vout should be checked to ensure that the transaction provides enough transaction fees to cover the gas. Additionally, this should be verified even when the contract is not executed, such as when it is accepted in the mempool. 
The above document describes how the contract calls other contracts via OP_CALL.

OP_SPEND (or OP_TXHASH, OP_EXEC_SPEND)

OP_SPEND is used for the cost of the contract balance. Because the contract address is a special address, in order to ensure consensus, the UTXO needs to be specially processed. Therefore, there are more descriptions of the OP_SPEND operation code in the original design document.
QTUM20: Create OP_EXEC_SPEND transaction when a contract spends money 
Description: When a CALL opcode or similar to used from an EVM contract to send another contract money, this should be shown on the blockchain as a new transaction. When a money transfer is done in the contract, the miner should add a new transaction exactly after the currently processing transaction in the block. This transaction should spend an input owned by the contract by using EXEC_SPEND in it's redeemScript. For the purposes of this story, assume change is not something to be worried about and consume as many inputs are needed. Properly picking effecient coins and sending back money to the originating contract will come in a later story. Edge cases to watch for: The transaction for sending money to the contract must come directly after the executing transaction. The outputs should use a version-0 OP_EXEC_ASSIGN vout, so that if the transaction were received out of context, it would still mean to not execute the contract.
The above document describes the timing of creating a OP_SPEND transaction.
QTUM21: Create consensus-critical change and coin-picking algorithm for OP_EXEC_SPEND transactions Description: Building on #20, now a consensus-critical algorithm must be made that picks the most optimal outputs belonging to the contract, and spends them, and also makes a change output that returns the "change" from the transaction back to the contract. All outputs in this case should be using a version-0 OP_EXEC_ASSIGN, to avoid running into the limitation that prevents more than one (version 1) OP_EXEC_ASSIGN transaction from being in a single transaction. The transaction should have as many vins as needed, and exactly 2 vouts. The first vout to go to the target contract, and the second vout to send change back to the source contract. 
QTUM22: Disallow more than one EVM execution per transaction
Description: In order to avoid significant edge cases, for now, disallow more than one EVM execution to take place in a single transaction. This includes both deployment and fund assignment vouts. Instead, such things should be split into multiple transactions If two EVM executions are encountered, the transaction should be treated as completely invalid and not suitable for broadcast nor putting into a block
QTUM23: Add "version 0" OP_EXEC_ASSIGN, which does not execute EVM Description: To counteract problems from #22, we should allow OP_EXEC_ASSIGN to be used to fund a contract without the contract actually being executed. This will be used later for "change" outputs to (multiple) contracts. If the version number passed in for OP_EXEC_ASSIGN is 0, then the contract is not executed. Also, this is only valid if the data provided to OP_EXEC_ASSIGN is just a single byte "0". Multiple version-0 OP_EXEC_ASSIGN vouts should be valid in a transaction, or 1 non-version-0 OP_EXEC_ASSIGN (or an OP_EXEC deployment) and multiple version-0 OP_EXEC_ASSIGN vouts. This will be used for all money spending that is sent from a contract to another contract
The above three documents describe that if the consensus-associated coin-picking algorithm guarantees that the OP_SPEND opcode does not cause a consensus error, the correctness of the change is ensured. At the same time, it describes the situation where the contract does not need to be run and how it is handled.
QTUM34: Disallow OP_EXEC and OP_EXEC_ASSIGN from coinbase transactions Description: Because of problems with coinbase maturity and potential side effects from ordering of gas-refund scripts, it should not be legal for coinbase outputs to be anything which results in EVM execution or directly changing EVM account balances. This includes version 0 OP_EXEC_ASSIGN outputs. 
The above document stipulates that coinbase transactions should not include contract-related scripts.

Other related documents

In addition, there are some documents describing the infrastructure needed for the new operation code.
QTUMCORE-51:Formalize the version field for OP_CREATE and OP_CALL Description:In order to sustain future extensions to the protocol, we need to set some rules for how we will later upgrade and add new VMs by changing the "version" argument to OP_CREATE and OP_CALL. We need a definitive VM version format beyond our current "just increment when doing upgrades". This would allow us to more easily plan upgrades and soft-forks. Proposed fields: 
  1. VM Format (can be increased from 0 to extend this format in the future): 2 bits2. Root VM - The actual VM to use, such as EVM, Lua, JVM, etc: 6 bits
  2. VM Version - The version of the Root VM to use (for upgrading the root VM with backwards compatibility) - 8 bits
  3. Flag options - For flags to the VM execution and AAL: 16 bits Total: 32 bits (4 bytes). Size is important since it will be in every EXEC transaction Flag option bits that control contract creation: (only apply to OP_CREATE) • 0 (reserve) Fixed gas schedule - if true, then this contract chooses to opt-out of allowing different gas schedules. Using OP_CALL with a gas schedule other than the one specified in it's creation will result in an immediate exception and result in an out of gas refund condition • 1 (reserve) Enable contract admin interface (reserve only, this will be implemented later. Will allow contracts to control for themselves what VM versions and such they allow, and allows the values to be changed over the lifecycle of the contract) • 2 (reserve) Disallow version 0 funding - If true, this contract is not capable of receiving money through version 0 OP_CALL, other than as required for the account abstraction layer. • bits 3-15 available for future extensions Flag options that control contract calls: (only apply to OP_CALL) • (none yet) Flag options that control both contract calls and creation: • (none yet) These flags will be implemented in a later story Note that the version field now MUST be a 4 byte push. A standard EVM contract would now use the version number (in hex) "01 00 00 00" Consensus behavior: VM Format must be 0 to be valid in a block Root VM can be any value. 1 is EVM, 0 is no-exec. All other values result in no-exec (allowed, but the no execution, for easier soft-forks later) VM Version can be any value (soft-fork compatibility). If a new version is used than 0 (0 is initial release version), then it will execute using version 0 and ignore the value Flag options can be any value (soft-fork compatibility). (inactive flag fields are ignored) Standard mempool behavior: VM Format must be 0Root VM must be 0 or 1VM Version must be 0Flag options - all valid fields can be set. All fields that are not assigned must be set to 0Defaults for EVM: VM Format: 0Root VM: 1VM Version: 0Flags: 0
The above documents formally identified OP_CREATE and OP_CALL needed version information, paving the way for subsequent multi-virtual machine support for Qtum.
QTUMCORE-52:Contract Admin Interface Description:(note, this isn't a goal for mainnet, though it would be a nice feature to include) It should be possible to manage the lifecycle of a contract internally within the contract itself. Such variables and configuration values that might need to be changed over the course of a contract's lifecycle: • Allowable gas schedules 
• Allowable VM versions (ie, if a future VM version breaks this contract, don't allow it to be used, as well as deprecating past VM versions from being used to interact with this contract) • Creation flags (the version flags in OP_CREATE) All of these variables must be able to be controlled within the contract itself, using decentralized code. For instance, in a DAO scenario, it might be something that participants can vote on within the contract, and then the contract triggers the code that changes these parameters. In addition, a contract should be capable of detecting it's own settings throughout it's execution as well as when it is initially created. I propose implementing this interface as a special pre-compiled contract. For a contract ot interact with it, it would call it using the Solidity ABI like any other contract. Proposed ABI for the contract: • bytes[2048] GasSchedule(int n) • int GasScheduleCount() • int AddGasSchedule(bytes[2048] • bytes[32] AllowedVMVersions() • void SetAllowedVMVersions(bytes[32]) Alternative implementations: There could be a specific Solidity function which is called in order to validate that the contract should allow itself to be called in a particular manner: pragma solidity 0.4.0; contract BlockHashTest {function BlockHashTest() { }function ValidateGasSchedule(bytes32 addr) public returns (bool) {if(addr=="123454") { return true; //allow contract to run }return false; //do not allow contract to run}function ValidateVMVersion(byte version) public returns (bool){if(version >= 2 && version < 10) { return true; //allow to run on versions 2-9. Say for example 1 had a vulnerability in it, and 10 broke the contract }return false; } } In this way a contract is responsible for managing it's own state. The basic way it would work is that when a you use OP_CALL to call a contract, it would first execute these two functions (and their execution would be included in gas costs). If either function returns false, then it immediately triggers an out of gas condition and cancels execution. It's slightly complicated to manage the "ValidateVMVersion" callback however, because we must decide which VM version to use. A bad one could cause this function itself to misbeha`ve.```````
pragma solidity 0.4.0; contract BlockHashTest {function BlockHashTest() { }function ValidateGasSchedule(bytes32 addr) public returns (bool) {if(addr=="123454") { return true; //allow contract to run }return false; //do not allow contract to run}function ValidateVMVersion(byte version) public returns (bool){if(version >= 2 && version < 10) { return true; //allow to run on versions 2-9. Say for example 1 had a vulnerability in it, and 10 broke the contract }return false; }
} 
The above document describes the management interface of the contract, and yes the contract can manage its own status.
QTUMCORE-53:Add opt-out flags to contracts for version 0 sends Description:Some contracts may wish to opt-out of certain features in Qtum that are not present in Ethereum. This way more Ethereum contracts can be ported to Qtum without worrying about new features in the Qtum blockchain Two flag options should be added to the Version field, which only have an effect in OP_CREATE for creating the contract: 2. (1st bit) Disallow "version 0" OP_CALLs to this contract outside of the AAL. (DisallowVersion0)  If this is enabled, then an OP_CALL using "root VM 0" (which causes no execution) is not allowed to be sent to this contract. If money is attempted to be sent to this contract using "version 0" OP_CALL, then it will result in an out of gas exception and the funds should be refunded. Version 0 payments made internally within the Account Abstraction Layer should not be affected by this flag. Along with these new consensus rules, there should also be some standard mempool checks: 
  1. If an OP_CALL tx uses a different gas schedule than the contract creation, and the disallow dynamic gas flag is set, then the transaction should be rejected from the mempool as a non-standard transaction (version 0 payments should not be allowed as standard transactions in the mempool anyway)
The above document describes how to get better EVM compatibility by ignoring certain Qtum specific features in order to port Ethereum contract code. This makes smart contracts in the Ethereum ecosystem more easily compatible with Qtum.

summary

The Qtum original design document presented above describes Qtu's increased opcode associated with the contract run, laying the groundwork for subsequent Qtum's EVM VMs that are compatible with the account model on top of the UTXO model, and also making the account abstraction layer AAL possible. The subsequent Qtum project team will further interpret the key documents. If you have any questions, readers can post comments in the comments area or contact the Qtum project team .
The Qtum quantum chain public number will be updated from time to time around the above topics to restore the history of the Qtum project and key technologies from scratch .
Please note that based on Patrick Dai's translation request, the content in this material is translated to English and published on Reddit.
OP's Qtum Address: QMmYAMEFgvPJGwK9nrwqYw1DHhBkiuEi78
submitted by szhman to Qtum [link] [comments]

Example of censorship on /r/bitcoin : proving FUDers wrong is punished by censoring out the truth

I replied to this comment: https://np.reddit.com/Bitcoin/comments/6z6kzj/apparently_people_are_losing_their_bch_by_sending/
This applies if you have bcash and send it by mistake to a Bitcoin SegWit address, like to an exchange, which is a reasonable mistake since bcash chose to use the same exact address format to be maximum assholes, and can reasonably start to happen more and more as exchanges and wallets switch to SegWit to save on fees. If the person generating that Bitcoin address made a SegWit address, that means that the output script requires SegWit be activated before it is safe to use that address. This is why Bitcoin Core did not allow SegWit address generation to happen before SegWit activated. Since SegWit never activated on bcash it is not safe to use there and the coins will probably be lost, the incentive there is to just steal the coins, and the lead developer says that the miners should do that. Another good reason to stick to Bitcoin, it has responsible development processes that actually care about preventing people from losing money by accident.
With this (this is deleted or shadow-banned):
DAFUQ did you just wrote??? It is completely opposite + there is 2-way replay protection implemented on BCH fork, so it is not in danger of reply attacks and also coins on other side of the fork are safe
Also another guy replied including technical detail, and was also censored (also not visible as reply):
Any ordinary transaction on one chain is invalid on the other, and vice-versa, because they changed the OP_CHECKSIG semantics to prevent exacly this sort of thing.
There is FUD campaign going on there without even being shy of censoring out PURE FACTS
submitted by halloweenlv to btc [link] [comments]

SCRY.INFO underlying double chain technology sharing

SCRY.INFO underlying double chain technology sharing
1.Background
In SCRY project, double chain structure is applied in clients. As for signature algorithm, we selected BIP143. In segregated witness, VERSION 0 applied BIP143 signature verification to increase efficiency, but BIP143S algorithm is not applied to general transactions. We have optimized general transaction signature and verification, apply BIP143 signature and verification to increase the efficiency.
1.1Signature algorithm
Bitcoin applied ECDSA (Elliptic Curve Digital Signature Algorithm) as digital signature algorithm. There are 3 use cases of digital signature algorithm in Bitcoin: 1. Signature can verify the owner of private key, the owner of money transferring in that transaction. 2. The proxy verification cannot be denied, that is the transaction cannot be denied. 3. The signature cannot be falsified, that is transaction (or details of transaction) cannot be adjusted by anyone after signature.
There are two parts of digital signature: one is using private key( signature key) to sign the hash of message(transaction), the other one is to allow everyone can verify the signature by provided public key and information.
  • Signature algorithm
The signature algorithm of Bitcoin is as following:
Sig = Fsig( Fhash(m), dA )
Explanation:
dA is private key signature
m is transaction (or part of transaction)
Fhash is hash function
Fsig is signature algorithm
Sig is result signature
There are 2 functions in the whole signature: Fhash and Fsig。
  • Fhash function
Fhash function is to generate Hash of transaction, first serialize the transaction, based on serialized binary data use SHA256 to calculate the transaction Hash. The general transaction (single input and single output) process is as following:
Transaction serialization:
1.nVersion Transaction version
2.InputCount Input count
3.Prevouts Serialize the input UTXO
4.OutputCount Output count
5.outpoint Serialize the output UTXO
6.nLocktime Locked period of transaction
7.Hash Twice SHA256 calculation based on the data above
  • Fsig function
Fsig function signature algorithm is based on ECDSA. There will be a K value every encryption. Based on this K value, the algorithm will generate a temporary public/private key (K,Q), select X axis of public key Q to get a value R, the formula is as following:
S=K-1 *(Hash(m) + dA *R) mod p
Explanation:
K is temporary private key
R is x axis of temporary public key
dA is signature private key
m is transaction data
p is the main sequence of elliptical curve
The function will generate a value S.
In elliptical curve every encryption will generate a K value. Reuse same K value will cause private key exposed, K value should be seriously secured. Bitcoin use FRC6979 TO ensure certainty, use SHA256 to ensure the security of K value. The simple formula is as following:
K =SHA256(dA+HASH(m))
Explanation,
dA is private key,
m is message.
Final signature will be generated with the combination of ( R and S)
  • Signature verification
Verification process is applying signature to generate inverse function, the formula is as following:
P=S-1 *Hash(m)*G +S-1*R*Qa
Explanation:
R and S are signature value
Qa is user(signer)’s public key
m is signed transaction data
G is generator point of elliptical curve
We can see from this formula, based on information (transaction or part of Hash value), public key and signature of signer(R and S value), calculate the P value, the value will be one point on elliptical curve. If the X axis equals R, then the signature is valid.
1.2

Bip143 brief introduction

There are 4 ECDSA (Elliptic Curve Digital Signature Algorithm) signature verification code(sigops):CHECKSIG, CHECKSIGVERIFY, CHECKMULTISIG, CHECKMULTISIGVERIFY. One transaction abstract will be SHA256 encryption twice.There are at least 2 disadvantages in Bitcoin original digital signature digest algorithm:
●Hash used for data verification is consistent with transaction bytes. The computation of signature verification is based on O(N2) time complexity, time for verification is too long, BIP143 optimizes digest algorithm by importing some “intermediate state” which can be duplicate, make the time complexity of signature verification turn into O(n).
●The other disadvantages of original signature: There are no Bitcoin amounts included in signature when having the transaction, it is not a disadvantage for nodes, but for offline transaction signature devices (cold wallet), since the importing amount is not available, causing that the exact amount and transaction fees cannot be calculated. BIP143 has included the amount in every transaction in the signature.
BIP143 defines a new kind of task digest algorithm, the standard is as following:
Transaction serialization
https://preview.redd.it/2b6c5q2mk7b11.png?width=783&format=png&auto=webp&s=eb952782464942b6930bbd2632fbcd0fbaaf5023
1,4,7,9,10 in the list is the same as original SIGHASH algorithm, original SIGHASH type meaning stay the same. The following contains are changed:
  • Serialization method
  • All SIGHASH commit amount for signature
  • FindAndDelete signature is not suitable for scripteCode;
  • AfterOP_CODESEPARATOR(S),OP_CODESEPARATOR will not delete scriptCode( lastOP_CODESEPARATOR will be deleted after every script);
  • SINGLE does not commit input index.When ANYONECANPAY has no setting,the meaning will not be changed,hashPrevouts and outpoint are implicit committed in input index. When SINGLE use ANYONECANPAY, signed input and output will exist in pairs, but have no limitation to index.
2.BIP143 Signature
In go language, we use btcsuite database to finish signature, btcsuite database is an integrated Bitcoin database, it can generate all nodes program of Bitcoin, but we just use btcsuite database public key/private key API, SHA API and sign RFC6979 signature API. In order to avoid redundancy, the following codes have no adjustments to codes.
2.1
Transaction HASH generation
Transaction information hash generation, every input in transaction will generate a hash value, if there are multi-input in the transaction, then a hash array will be generated, every hash in the array will be consistent with input in transaction.
https://preview.redd.it/n0x5bo9cl7b11.png?width=629&format=png&auto=webp&s=63f4951e5ca7d0cffc6e8905f5d4b33354aa6ecc
Like two transaction input in the image above, every transaction will generate a hash, the transaction above will generate two hash.
  • Fhash function
CalcSignatureHash(script []byte, hashType SigHashType, tx *EMsgTx, idx int)
Explanation:
Script,pubscript is input utxo unlocked script
HashType,signature method or signature type
Tx,details of transaction
Idx,Number of transaction, that is to calculate which transaction hash
The following is Fhash code
https://preview.redd.it/e8xx974gl7b11.png?width=506&format=png&auto=webp&s=9a4f419069bea2e76b8d5b7205a31e06692f3f67
For the situation that multi UTXO input in one transaction, for every input, you can deploy it as examples above, then generate a hash array. Before hash generation, you need to clear “SigantureScript”in other inputs, only leave the “SigantureScript” in this input,That is “ScriptSig”field.
https://preview.redd.it/0omhp2ahl7b11.png?width=462&format=png&auto=webp&s=4cee9b0e4fe10185a39d68bde1032ac4e4dbb9ad
The amount for every UTXO is different. You need to pay attention to the 6th step, what you need to input is the amount for every transaction
Multi-input function generation
func txHash(tx msgtx) ( *[][]byte)
Code details
https://preview.redd.it/rlnxv3lil7b11.png?width=581&format=png&auto=webp&s=804adbee92a9bb9811a4ffc395601ebf191fd664
Repeat deploy Fhash function(CalcSignatureHash)then you can generate a hash array.
2.2Sign with HASH
A hash array is generated in the methods above, for every input with a unique hash in the data, we use signRFC6979 signature function to sign the hash, here we deploy functions in btcsuite database directly.
signRFC6979(PrivateKey, hash)
Through this function, we can generate SigantureScript,add this value to every input SigantureScript field in the transaction.
2.3Multisig
Briefly, multi-sig technology is the question that one UTXO should be signed with how many private keys. There is one condition in script, N public keys are recorded in script, at least M public keys must provide signature to unlock the asset. That is also called M-N method, N is the amount of private keys, M is the signature amount needed for verification
The following is how to realize a 2-2 multisig based on P2SH(Pay-to-Script-Hash) script with go language.
2-2 codes of script function generation:
https://preview.redd.it/7dq7cv9kl7b11.png?width=582&format=png&auto=webp&s=108c6278d656e5fa6b51b5876d5a0f7a1231f933
The function above generated script in the following
2 2 OP_C HECKMULTISIG
Signature function
1. Based on transaction TX,it includes input array []TxIn,generate transaction HASH array,this process is the same as process in general transaction above, deploy the digest function of general transaction above.
func txHash(tx msgtx) ( *[][]byte)
this function generated a hash array, that is every transaction input is consistent with one hash value.
2. Use first public key in redeem script, sign with consistent private key. The process is as general transaction.
signRFC6979(PrivateKey, hash)
After signature, the signature array SignatureScriptArr1 with every single input is generated. Based on this signature value in the array, you can update every input TxIn "SigantureScript" field in transaction TX.
3.Based on updated TX deploy txHash function again, generate new hash array.
func txHash(tx msgtx) ( *[][]byte)
4. Use second public key in redeem script, the consistent private key is used for signature. Use the updated TX in the process above, generate every input hash and sign it.
signRFC6979(PrivateKey, hash)
//Combine the signature generated by first key, signature generated by secondkey and redeem script.
etxscript.EncodeSigScript(&(TX.TxIn[i].SignatureScript),&SigHash2, pkScript)
There are N transactions, so repeat it N times.
The final data is as following:
https://preview.redd.it/78aabhqll7b11.png?width=558&format=png&auto=webp&s=453f7129b2cf3c648b68c2369a4622963087d0c8
References
https://en.wikipedia.org/wiki/Digital_signature*
https://github.com/bitcoin/bips/blob/mastebip-0143.mediawiki
《OReilly.Mastering.Bitcoin.2nd.Edition》
http://www.8btc.com/rfc6979
submitted by StephenCuuuurry to SCRYDDD [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:
https://github.com/OpenAssets/open-assets-protocol/blob/mastespecification.mediawiki
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:
https://github.com/OpenAssets/open-assets-protocol/blob/masteaddress-format.mediawiki
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
==Abstract==
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.
==Motivation==
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
infrastructure.
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
characteristics:
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:

18E14A7B6A307F426A94F8114701E7C8E774E7F9A47E2C2035DB29A206321725.

He calculates the corresponding address:

16UwLL9Risc3QfPqBUvKofHmBQ7wMtjvM.

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

address: OP_DUP OP_HASH160
010966776006953D5567439E5E39F86A0D273BEE OP_EQUALVERIFY
OP_CHECKSIG.

The script is hashed: 36e0ea8e93eaa0285d641305f4c81e563aa570a2

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

using version byte 23:
ALn3aK1fSuG27N96UGYB1kUYUpGKRhBuBC.
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
[https://en.bitcoin.it/wiki/Protocol_specification#Variable_length_integer
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
[http://en.wikipedia.org/wiki/LEB128 LEB128-encoded] unsigned integers
representing the asset quantity of every output in order (excluding
the marker output). || Variable
|-
! Metadata length || The
[https://en.bitcoin.it/wiki/Protocol_specification#Variable_length_integer
var-integer] encoded length of the metadata field. || 1-9
bytes
|-
! 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 [http://en.wikipedia.org/wiki/LEB128 LEB128] encoding (also
used in [https://developers.google.com/protocol-buffers/docs/encoding#varints
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
units.
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.
====Example====
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]...
original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-May/012741.html
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

Time to worry about 80-bit collision attacks or not? | Gavin Andresen | Jan 07 2016

Gavin Andresen on Jan 07 2016:
I'm hoisting this from some private feedback I sent on the segregated
witness BIP:
I said:
"I'd also use RIPEMD160(SHA256()) as the hash function and save the 12
bytes-- a successful preimage attack against that ain't gonna happen before
we're all dead. I'm probably being dense, but I just don't see how a
collision attack is relevant here."
Pieter responded:
"The problem case is where someone in a contract setup shows you a script,
which you accept as being a payment to yourself. An attacker could use a
collision attack to construct scripts with identical hashes, only one of
which does have the property you want, and steal coins.
So you really want collision security, and I don't think 80 bits is
something we should encourage for that. Normal pubkey hashes don't have
that problem, as they can't be constructed to pay to you."
... but I'm unconvinced:
"But it is trivial for contract wallets to protect against collision
attacks-- if you give me a script that is "gavin_pubkey CHECKSIG
arbitrary_data OP_DROP" with "I promise I'm not trying to rip you off, just
ignore that arbitrary data" a wallet can just refuse. Even more likely, a
contract wallet won't even recognize that as a pay-to-gavin transaction.
I suppose it could be looking for some form of "gavin_pubkey
somebody_else_pubkey CHECKMULTISIG ... with the attacker using
somebody_else_pubkey to force the collision, but, again, trivial contract
protocol tweaks ("send along a proof you have the private key corresponding
to the public key" or "everybody pre-commits pubkeys they'll use at
protocol start") would protect against that.
Adding an extra 12 bytes to every segwit to prevent an attack that takes
280 computation and 280 storage, is unlikely to be a problem in practice,
and is trivial to protect against is the wrong tradeoff to make."
20 bytes instead of 32 bytes is a savings of almost 40%, which is
significant.
The general question I'd like to raise on this list is:
Should we be worried, today, about collision attacks against RIPEMD160 (our
160-bit hash)?
Mounting a successful brute-force collision attack would require at least
O(280) CPU, which is kinda-sorta feasible (Pieter pointed out that Bitcoin
POW has computed more SHA256 hashes than that). But it also requires
O(280) storage, which is utterly infeasible (there is something on the
order of 235 bytes of storage in the entire world). Even assuming
doubling every single year (faster than Moore's Law), we're four decades
away from an attacker with THE ENTIRE WORLD's storage capacity being able
to mount a collision attack.
References:
https://en.wikipedia.org/wiki/Collision_attack
https://vsatglobalseriesblog.wordpress.com/2013/06/21/in-2013-the-amount-of-data-generated-worldwide-will-reach-four-zettabytes/

Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160107/09860830/attachment.html
original: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/012198.html
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

[BIP Proposal] Standard address format for timelocked funds | ZmnSCPxj | Jul 08 2017

ZmnSCPxj on Jul 08 2017:
BIP: ?
Title: Standard address format for timelocked funds
Author: ZmnSCPxj
Comments-Summary: ?
Comments-URI: ?
Status: ?
Type: ?
Created: 2017-07-01
License: CC0-1.0
== Abstract ==
OP_CHECKLOCKTIMEVERIFY provides a method of
locking funds until a particular time arrives.
One potential use of this opcode is for a user to precommit
himself or herself to not spend funds until a particular
date, i.e. to hold the funds until a later date.
This proposal adds a format for specifying addresses that
precommit to timelocked funds, as well as specifying a
redemption code to redeem funds after the timelock has
passed.
This allows ordinary non-technical users to make use of
OP_CHECKLOCKTIMEVERIFY easily.
== Copyright ==
This BIP is released under CC0-1.0.
== Specification ==
This proposal provides formats for specifying an
address that locks funds until a specified date,
and a redemption code that allows the funds to be
swept on or after the specified date.
At minimum, wallet software supporting this BIP must
be capable of sweeping the redemption code on or after
the specified date.
In addition, the wallet software should support sending
funds to the timelocked address specified here.
Finally, wallet software may provide a command to create
a pair of timelocked address and redemption code.
Addresses and redemption codes are encoded using
[https://github.com/bitcoin/bips/blob/mastebip-0173.mediawiki#Bech32
Bech32 encoding].
=== Timelocked Address Format ===
The human-readable part of the address is composed of:

The four characters hodl.

A date, in YYYYMMDD form. For example,

the date August 1, 2017 is encoded as 20170801.

A network code, either tb for testnet,

or bc for Bitcoin mainnet.
The data part of the address is composed of:

A version quintet (5 bits), which must be 0 for this

BIP.

A public key hash, 32 quintets (160 bits). As is

usual for Bitcoin, this is big-endian.
This is to be interpreted as follows:

The given date is the first day that the funds in

the given address may be redeemed.

The funds are owned by whoever controls the private

key corresponding to the public key hash given.
=== Redemption Code ===
The human-readable part of the redemption code is
composed of:

The four characters hedl.

A date, in YYYYMMDD form.

A network code, either tb for testnet,

or bc for Bitcoin mainnet.
The data part of the address is composed of:

A version quintet (5 bits), which must be 0 for this

BIP.

A private key, 52 quintets (260 bits). This is the

256-bit private key, prepended with 4 0
bits, in big-endian order.
This is to be interpreted as follows:

The given date is the first day that the funds in

the given address may be redeemed.

The private key unlocks the funds.

=== Lock Time Computation ===
Given a particular lock date YYYYMMDD, the
actual lock time is computed as follows:

The day before the lock date is taken. For example,

if the lock date is 20180101 or
January 1, 2018, we take the date December 31, 2017.

We take the time 1000h (10:00 AM, or 10 in the morning)

of the date from the above step.
This lock time is then translated to a
Unix epoch time, as per POSIX.1-2001 (which removes the
buggy day February 29, 2100 in previous POSIX revisions).
The translation should use, at minimum, unsigned 32-bit
numbers to represent the Unix epoch time.
The Unix epoch time shall then be interpreted as an
nLockTime value, as per standard Bitcoin.
Whether it is possible to represent dates past 2038
will depend on whether standard Bitcoin can represent
nLockTime values to represent dates past
2038.
Since nLockTime is an unsigned 32-bit
value, it should be possible to represent dates until
06:28:15 UTC+0 2106-02-07.
Future versions of Bitcoin should be able to support
nLockTime larger than unsigned 32-bit,
in order to allow even later dates.
The reason for using an earlier lock time than the
specified date is given in the Rationale section of
this BIP.
=== Payment to a Timelocked Address ===
An ordinary P2SH payment is used to provide funds to a
timelocked address.
The script below is used as the redeemScript
for the P2SH payment:
OP_CHECKLOCKTIMEVERIFY OP_DROP
OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG
Once the redeemScript is derived, the hash is
determined, and an ordinary P2SH output with the below
scriptPubKey used:
OP_HASH160 OP_EQUAL
In case of SegWit deployment, SegWit-compatible wallets
should be able to use P2SH, P2WSH, or P2SH-P2WSH, as per
the output they would normally use in that situation.
Obviously, a timelocked address has an equivalent
Bitcoin 3 (P2SH) address.
A simple service or software that translates from a
public timelocked address to a P2SH address can be
created that makes timelocking (but not redemption)
backwards compatible with wallets that do not support
this BIP.
This proposal recommends that wallets supporting payment
to P2PKH, P2SH, P2WPKH, and P2WSH Bitcoin addresses should
reuse the same interface for paying to such addresses as
paying into timelocked addresses of this proposal.
=== Redemption of a Timelocked Redemption Code ===
To sweep a timelocked redemption code after the timelock,
one must provide the given redeemScript as
part of the scriptSig, of all unspent
outputs that pay to the given redeemScript
hash.
When sweeping a timelocked redemption code, first the
wallet must extract the private key from the redemption
code, then derive the public key, the public key hash,
the redeemScript, and finally the
redeemScript hash.
Then, the wallet must find all unspent outputs that pay
to the redeemScript hash via P2SH (and, in the
case of SegWit deployment, via P2SH-P2WSH and P2WSH).
For each such output, the wallet then generates a
transaction input with the below scriptSig, as
per usual P2SH redemptions:
The wallet then outputs to an address it can control.
As the Script involved uses OP_CHECKLOCKTIMEVERIFY,
the nSequence must be 0 and the
nLockTime must be equal to the computed
lock time.
This implies that the transaction cannot be transmitted
(and the funds cannot be sweeped)
until after the given lock time.
The above procedure is roughly identical to sweeping an
ordinary, exported private key.
This proposal recommends that wallets supporting a sweep
function should reuse the same interface for sweeping
individual private keys (wallet import format) for sweeping
timelocked redemption codes.
== Motivation ==
A key motivation for this BIP is to allow easy use of
OP_CHECKLOCKTIMEVERIFY by end-users.
The below are expected use cases of this proposal:

A user wants to purchase an amount of Bitcoin,

and subsequently wait for an amount of time before
cashing out.
The user fears that he or she may have "weak hands",
i.e. sell unfavorably on a temporary dip, and thus
commits the coins into a timelocked fund that can
only be opened after a specific date.

A user wants to gift an amount of Bitcoins to

an infant or minor, and wants the fund to not be spent
on ill-advised purchases until the infant or minor
reaches the age of maturity.

A user may wish to prepare some kind of monthly subsidy

or allowance to another user, and prepares a series of
timelocked addresses, redeemable at some set date on
each month, and provides the private redemption codes to
the beneficiary.

A user may fear duress or ransom for a particular

future time horizon, and voluntarily impose a lock time
during which a majority of their funds cannot be spent.
== Rationale ==
While in principle, this proposal may be implemented as a
separate service or software, we should consider the long
time horizons that may be desired by users.
A user using a particular software to timelock a fund may
have concerns, for example, of specifying a timelock
18 years in the future for a gift or inheritance to a
newborn infant.
The software or service may no longer exist after 18 years,
unless the user himself or herself takes over maintenance
of that software or service.
By having a single standard for timelocked funds that is
shared and common among multiple implementations of Bitcoin
wallets, the user has some assurance that the redemption code
for the funds is still useable after 18 years.
Further, a publicly-accessible standard specifying how the
funds can be redeemed will allow technically-capable users
or beneficiaries to create software that can redeem the
timelocked fund.
This proposal provides a timelock at the granularity of a
day.
The expectation is that users will have long time
durations of months or years, so that the ability to
specify exact times, which would require specifying the
timezone, is unneeded.
The actual timeout used is 1000h of the day before the
human-readable date, so that timezones of UTC+14 will
definitely be able to redeem the money starting at
0000h of the human-readable date, local time (UTC+14).
Given the expectation that users will use long time
durations, the fact that timezones of UTC-12 will
actually be able to redeem the funds on 2200h UTC-12
time two days before can be considered an acceptable
error.
The human-readable date is formatted according to
[https://www.iso.org/iso-8601-date-and-time-format.html
ISO standard dates], with the dashes removed.
Dashes may prevent double-click selection, making
usability of these addresses less desirable.
The bc or tb is after the
date since the date is composed of digits and the bech32
separator itself is the digit 1. One
simply needs to compare hedlbc202111211...
and hedl20211121bc1....
A version quintet is added in case of a...[message truncated here by reddit bot]...
original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014714.html
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

Coinbase - How to Find your Bitcoin wallet address - YouTube How to find your Bitcoin wallet address on Luno.com - YouTube Blockchain - Use cases MultiSignature Wallets a brief intro How To Check Any Bitcoin Wallet Balance And Bitcoin ... How to Trace a Bitcoin Transaction using a Bitcoin ...

With the extension you can check Bitcoin address balance by just typing: "btc {space} bitcoin_address" in browser's address bar. BitRef can also handle all bitcoin: links in your browser. Click here to activate it. Stuck transaction? Use our free Bitcoin transaction accelerator to push it. Use our Bitcoin Fee Estimator to find the best fee for your next transaction. 1 Bitcoin Price: 12988.66 ... Cold Wallet: an intermediate staging area for funds to be transferred from the frozen wallet to the client. Funds in the cold wallet may be spent by CheckSig with a multisig Discover the protocol. Solutions for. Institutional Investors. High Net Worth Individuals. Partners. Why Bitcoin. Digital and scriptural, it only exists as validated transaction. Bitcoin is an Asset, not a liability, and a ... Our bitcoin wallet address checker allows you to quickly see the amount held for any bitcoin address and its recent transactions. Simply enter the address you would like to check, we then look up an updated version of the blockchain. In this check we find out the amount held in the wallet, the time of the most recent transaction, the transaction amount and the number of transactions carried ... CHECKSIG. General; Technical; Financial; Português ; Follow Following. Bitcoin Technical Analysis #1 (8/15/2017) Bitcoin Technical Analysis #1 (8/15/2017) The second article of a series of articles where I analyse the Bitcoin weekly, daily and hourly charts. Felipe Zavan. Aug 29, 2017. A Technical Analysis checklist. A Technical Analysis checklist. This is a checklist of things you should ... CHECKSIG. General; Technical; Financial; Português; The split. How to split your Bitcoin Cash (BCC/BCH) from your BTC/XBT using Electron Cash. Felipe Zavan . Follow. Aug 2, 2017 · 3 min read. So you want your BCC/BCH/Whatever (I’ll refer to it as BCH throughout the rest of the post) airdrop. That’s okay, everybody loves free monies. I’ll tell you the way I and some friends did it and ...

[index] [18867] [45565] [13796] [10281] [36431] [41711] [5204] [19031] [33194] [23923]

Coinbase - How to Find your Bitcoin wallet address - YouTube

To Buy the book "BITCOIN BASICS: LOGIC AND MAGIC OF DIGITAL GOLD" click on the link :: https://amzn.to/2KiEj9S For Bitcoin and Cryptocurrency news follow our... Brian shows how to import a paper wallet he got from https://getcryptocrate.com/ and explains why private keys matter and why you should think twice about ho... How to use Specter. Why use Specter Wallet for hodling your Bitcoins? *Use your own node. *All your favorite hardware wallets supported *Single sig *Multisig... If you want to someone to send you money to your Bitcoin account, Give them this address. you may donate to our network via Bitcoin as well :) Bitcoin addres... The Crypto Dad shows you how to trace a Bitcoin transaction. Important software used is: Electrum bitcoin wallet: https://electrum.org/#home The Blockchain e...

#