BIP 0016 - Bitcoin Wiki

Let's be 100% clear on the fact that miners never voted on rule changes. ISM and BIP9 gave them the ability to activate, it got abused. [SegWit] could have just been released w/flag dates, like BIP16 or BIP30, but out of courtesy thought would be better to let miners signal /r/Bitcoin

Let's be 100% clear on the fact that miners never voted on rule changes. ISM and BIP9 gave them the ability to activate, it got abused. [SegWit] could have just been released w/flag dates, like BIP16 or BIP30, but out of courtesy thought would be better to let miners signal /Bitcoin submitted by BitcoinAllBot to BitcoinAll [link] [comments]

More fun with OP_HODL (CheckLockTimeVerify)

Last week I wrote a post with a script to create a HODL address. A HODL address is a UTXO that cannot be spent until a certain epoch time or blocktime. It can be used to secure funds in a will or trust that has a designated maturity date. Or you may have some other reason to lock the funds, the point is that the UTXO can be physically verified to be funded, and under an unbreakable timelock.
I've liked the feature but have been frustrated that there is limited HW and SW wallet support for it presently. My previous post walked through how to make a segwit HODL UTXO, this post will detail how to make a BIP16 legacy P2SH HODL UTXO.
Similar to last week, I wrote a bitcoinlib script to do it, but this week I also went through the steps to do it on the CoinBin wallet. CoinBin is a JavaScript wallet that can (and should) be run locally. CoinBin, or raw python (bitcoinlib) are the only ways I currently know of to spend a HODL address.
Here's the basic rundown to create and fund your UTXO with CoinBin
  1. Use either Electrum or Bitcoin Core to collect a Bitcoin public and private key.
  2. Run the CoinBin app either locally (best option) or through the live site
  3. Choose New -> Time Locked Address
  4. Enter the public key (from #1) and either a block height or timestamp for your lock
  5. Hit Submit and record the address and redeem script
  6. Ensure you have accurately recorded everything in step #1 and step #5
  7. Send funds to the address recorded in step 5 as you normally would.
Here's the basic rundown on how to spend your UTXO with CoinBin
  1. Use either Electrum or Bitcoin Core to collect an address to spend your UTXO to
  2. Run the CoinBin app either locally (best option) or through the live site
  3. Choose New -> Transaction
  4. Enter the Redeem Script you copied in the creation process (step #5), then Load
  5. After a few minutes it should automatically load your UTXO into the form
  6. Enter the address you want to spend your UTXO to and adjust the output amount for fees
  7. Hit the question mark next to Transaction Fee for the calculator
  8. Hit Submit when satisfied and record the unsigned transaction data
  9. Select Sign on the top nav bar to begin the signing operation
  10. Enter your private key from the creation process (step #1) and the unsigned TXN
  11. Select Submit to produce the signed TXN
  12. Broadcast the signed TXN with either Electrum or Bitcoin Core
Note, if you try to broadcast before the UTXO's timelock expires, you will get a terse not final error in either Electrum or Core.
For Extra Credit, CoinBin can also be run against Testnet, but to do so you have to unhide the settings element, manually code the TXN input script and manually code the TXN nLockTime to sync with your HODL address.
Here are a Testnet and Mainnet HODL spend TXN I created in CoinBin * Mainnet: txid ea6a1...79d53 * Testnet: txid a8110...adc93
submitted by brianddk to Bitcoin [link] [comments]

Attention, benevolent BCH miners: A BCH segwit-recovery service is sorely needed!

These BCH are now recoverable; please read the update at the end of the post!

 
 

Background

In the short while since segwit activated on the BTC network and segwit addresses even-more-recently became the default for receiving BTC in the Trezor wallet - and perhaps other wallets too (soon?) - people have started accidentally sending their BCH to BTC-segwit addresses.
 
Due to the fact(s) that...
a) the BCH network supports P2SH (i.e. addresses starting with 3), but not segwit
... and ...
b) the sending wallets thus have no way of knowing that P2SH-wrapped segwit addresses really are "hiding" a segwit redeemscript
... people are losing access to their BCH, there's currently no way to prevent this, and it will continue happening.
 

Examples

(These are just the ones that I've noticed, but I'm sure there are many more that go straight to the various wallet service providers' support teams instead of via Reddit.)
 
To add insult to injury, the unlucky BCH owners are routinely told that there's no way to recover the coins (including by myself at the start) due to BCH not supporting segwit. And while that's currently true, it is ultimately only a half-truth.
After all, segwit opponents have often said that the satoshis in segwit addresses would be "anyone-can-spend" if the miners didn't enforce the segwit rules (i.e. ensuring that there's a proper witness/signature in the "segregated" part of the txs).
And on the BCH network the segwit rules aren't being enforced!
 

A Partial Solution

So I did some digging (e.g. in the segwit documentation and P2SH specification, BIP16) and came to the conclusion, which I'm sure that many have before me, that in order to spend money sent to a P2SH-wrapped segwit address, you only need to know the public key of the address (or more precisely: the RIPEMD160 hash of the SHA256 hash of a the public key).
Yes, a hash derived from the public key, not the private key.
Luckily, the 3-addresses don't by themselves reveal this public key hash, or anyone could've made "signed" txs from these "BCH-segwit" addresses - and someone probably already would have.
 

More Problems

So, given that it's relatively easy (for a technically inclined person, anyway) to get the public key corresponding to an address from their BIP39 mnemonic (aka wallet recovery seed), why aren't people re-claiming their BCH from these addresses?
Well, the "signature" that's needed isn't really a digital signature in the normal sense. Regular cryptocurrency transactions include a digital signature that doesn't reveal the private key that was used to make the signature in question. What's needed to "sign" for BCH-segwit addresses, however, is just literally including the public key hash that was mentioned above instead of a proper digital signature.
This means that anyone who sees such a transaction can just extract the public key hash from it - and then go on to create a conflicting transaction, using the same public key hash, that sends the same money elsewhere (to themselves, I would presume).
Technically, the second transaction would be a double-spend of the original and, as with all double-spends, it's the miners that would be the final arbiters of which transaction gets recorded in the block chain.
Additionally, a malicious miner could just create their own version of the transaction, either overtly redirecting the money to themselves, or covertly by changing the transaction to have no monetary outputs (i.e. all the money would go to the miner as "fee").
But the problems don't stop there. These segwit-spending transactions would be non-standard and as such wouldn't be relayed to the miners in the first place, nor would it be mined by miners even if it reached them (provided that the nodes and miners run with the default policy of ignoring non-standard txs, that is).
 

Suggested Solution

What we need is one or more trustworthy (yes, trust would unfortunately be required) miners to step up and make a BCH Segwit-Recovery Service for this particular purpose, in a somewhat similar way that they provided acceleration services for the BTC network (example1 and example2).
 
So... Does anyone know if a) miners are already working on this or b) know how to get in touch with them about this?
Or are there any benevolent miners here, that would like to:
 
/btc users, feel free to notify any miner contacts you may have - let's make this happen!
 
 

Update 1 (2017-09-11)

I made a proof-of-concept frontend to "show" what I'm envisioning such a service would look like for the end users (obviously it's ugly and needs to include javascript for key/hash/address validation, etc., but it should get the intention across), here:
https://btctroubadour.github.io/bch-recovery.html

Update 2 (2017-11-21)

It looks like some greyhat/vigilante, working with an unknown miner, was able to unilaterally claim some of the BCH that were "stuck" in BTC-segwit addresses (namely, the ones for which the public keys were revealed by the owners spending BTC from the same addresses), as explained in this post and comments: https://np.reddit.com/Bitcoin/comments/7eixcu/recovering_bch_sent_to_segwit_addresses/
For those that are affected by this, it means you no longer control your BCH (they were "stolen" by the greyhat), but he seems to be offering to give them back if you agree to letting him keep 30 % for his service (or "service", however you look at it). Either way, and given the alternative (100 % loss), you should certainly check if you're affected and decide how you want to proceed. As if that wasn't enough to deal with, there seems to be a ~2 week deadline, until "December 5th, 2017 at 23:59:59 UTC", after which it seems he's decided he's entitled to keep your money. :(

Update 3 (2017-11-28)

It looks like the greyhat has turned white! He's now offering to give back, for free, any and all BCH that were transferred to him (yes, 100 %!). Read his new update post and check if you were affected by this transfer.

Update 4 (2017-12-05)

Benevolent BCH miner finally found! The good people at btc.com have announced an automated BCH-segwit-recovery service, just as I outlined in my original post. Thanks a lot to Stellaluna19 for bringing it to my attention.
Here are links to btc.com's Twitter announcement as well as the recovery service itself:
https://twitter.com/btccom_official/status/933682190424199169
https://bch.btc.com/docs/help/bch_segwit_recovery
(Note that SatoshiLabs/Trezor developer, and well-known whitehat, -johoe have suggested some improvements to secure the process outlined by btc.com. You can read his suggestions in the last paragraph of this post - or in this one.)
submitted by btctroubadour to btc [link] [comments]

I am signaling UASF-SegWit-BIP148 with my node

Read up on how to do it here: http://www.uasf.co
submitted by burstup to Bitcoin [link] [comments]

Segwit was intentionally designed in a wasteful way - a simple example

Segwit is designed in an intentionally wasteful way to 'prove' afterwards that on-chain scaling is infeasible; its only real goal was to fix malleability, needed to force everyone to use centralized layer-2 solutions, with minimum scaling as a way to sell it. With a 4MB blocksize a ~40x scaling was possible, but segwit gives only about 1.7x. A full analysis would result in a full length article, so for now just one simple example of an intentional waste, from Segwit's BIP:
"[P2WSH's] scriptPubKey occupies 34 bytes, as opposed to 23 bytes of BIP16 P2SH. The increased size improves security against possible collision attacks, as 280 work is not infeasible anymore"
That sounds sensible - but why only P2WSH? Because finding collisions for P2(W)PKH requires ECC multiplication, and 280 ECC multiplications are infeasible - a method of key stretching. Ok, but... the same could apply to PW2SH! Just treat the SHA256 of a script as a private key, generate the public key and hash that. So either P2(W)PKH addresses are insecure and also need 256 bit hashes, or Segwit is intentionally wasting 11 bytes (per p2wsh output) for no reason! There's no performance argument: sending 11 bytes across the world is going to take orders of magnitude more time than one ecc multiplication; even loading these 11 bytes from ssd takes more time, then there's increase in required storage. (3 bytes are also waste but that's a separate issue)
Why intentional - because it's almost impossible to not realize all these things during designs. In the context of the total hostility to any real scaling and recent pow change threats there's no reason for any benefit of the doubt. These details are indeed hard to notice by others though - sort of like underhanded C contest.
Edit: Why does collision resistance matter for p2pkh? (condensed/expanded from comments) Every p2pkh address can be a multisignature address - there's no way to know, it would look exactly as any other address. Both n-of-n and m-of-n are possible - see this paper for the latter.
It has major advantages over explicit multisig: transactions are much smaller, their multisig nature is hidden and there's no limit to a number of keys. It's very likely it's already being used.
Example for 2-of-2:
  1. Alice has a public key Pa and signs a message with that public key using that public key: X = Pa sig = (X)signed_with(Pa) she sends X and signature to Bob
  2. Bob verifies Alice's signature, adds his public key Pb to Pa and signs the result, using Pb to sign: X = Pa+Pb sig = (X)signed_with(Pb)
  3. Bob sends the resulting key - X - with a signature and Pb to Alice. Alice verifies Bob's signature and that X = Pa+Pb, and if its ok, a valid 2-of-2 p2pkh address is considered to be generated.
To sign a transaction, they either engage in a multiparty computation (requires special software), or, depending on the circumstances, it may be ok for one party to just give his/her private key to the other - allowing arbitrary spending by that party.
The collision resistance part comes in generating X = Pa+Pb by Bob. Without the signature requirement, Bob could instead use a key - Pb_evil - allowing him to spend without Alice's approval:
Pb_evil = Pb2 - Pa //Bob knows Pb2, doesn't know Pa X = Pa+Pb_evil X = Pa + Pb2 - Pa = Pb2 // Alice's key canceled out! 
However, he can't sign any message with Pb_evil, because he doesn't know the private key for the -Pa part. Address is a hash of a resulting public key, so if Bob could generate a hash collision, that is: hash(Pa+Pb) == hash(Pa+Pb_evil) == hash(Pa+Pb2-Pa) == hash(Pb2) he could both sign a message to Alice with Pb AND spend the funds entirely on his own with Pb2.
submitted by coinsinspace to btc [link] [comments]

ELI5: Why is Peter Todd important and why do some people dislike him?

Same question as that one about Amir Taaki a few months ago: https://www.reddit.com/Bitcoin/comments/2wm3h7/eli5_why_is_amir_taaki_important_and_why_do_some/
submitted by amykinson to Bitcoin [link] [comments]

User Activated Soft Fork Split Protection | James Hilliard | Jun 07 2017

James Hilliard on Jun 07 2017:
Due to the proposed calendar(https://segwit2x.github.io/) for the
SegWit2x agreement being too slow to activate SegWit mandatory
signalling ahead of BIP148 using BIP91 I would like to propose another
option that miners can use to prevent a chain split ahead of the Aug
1st BIP148 activation date.
The splitprotection soft fork is essentially BIP91 but using BIP8
instead of BIP9 with a lower activation threshold and immediate
mandatory signalling lock-in. This allows for a majority of miners to
activate mandatory SegWit signalling and prevent a potential chain
split ahead of BIP148 activation.
This BIP allows for miners to respond to market forces quickly ahead
of BIP148 activation by signalling for splitprotection. Any miners
already running BIP148 should be encouraged to use splitprotection.
BIP: splitprotection
Layer: Consensus (soft fork)
Title: User Activated Soft Fork Split Protection
Author: James Hilliard
Comments-Summary: No comments yet.
Comments-URI:
Status: Draft
Type: Standards Track
Created: 2017-05-22
License: BSD-3-Clause
 CC0-1.0 
==Abstract==
This document specifies a coordination mechanism for a simple majority
of miners to prevent a chain split ahead of BIP148 activation.
==Definitions==
"existing segwit deployment" refer to the BIP9 "segwit" deployment
using bit 1, between November 15th 2016 and November 15th 2017 to
activate BIP141, BIP143 and BIP147.
==Motivation==
The biggest risk of BIP148 is an extended chain split, this BIP
provides a way for a simple majority of miners to eliminate that risk.
This BIP provides a way for a simple majority of miners to coordinate
activation of the existing segwit deployment with less than 95%
hashpower before BIP148 activation. Due to time constraints unless
immediately deployed BIP91 will likely not be able to enforce
mandatory signalling of segwit before the Aug 1st activation of
BIP148. This BIP provides a method for rapid miner activation of
SegWit mandatory signalling ahead of the BIP148 activation date. Since
the primary goal of this BIP is to reduce the chance of an extended
chain split as much as possible we activate using a simple miner
majority of 65% over a 504 block interval rather than a higher
percentage. This BIP also allows miners to signal their intention to
run BIP148 in order to prevent a chain split.
==Specification==
While this BIP is active, all blocks must set the nVersion header top
3 bits to 001 together with bit field (1<<1) (according to the
existing segwit deployment). Blocks that do not signal as required
will be rejected.
==Deployment==
This BIP will be deployed by "version bits" with a 65%(this can be
adjusted if desired) activation threshold BIP9 with the name
"splitprotecion" and using bit 2.
This BIP starts immediately and is a BIP8 style soft fork since
mandatory signalling will start on midnight August 1st 2017 (epoch
time 1501545600) regardless of whether or not this BIP has reached its
own signalling threshold. This BIP will cease to be active when segwit
is locked-in.
=== Reference implementation ===
// Check if Segregated Witness is Locked In
bool IsWitnessLockedIn(const CBlockIndex* pindexPrev, const
Consensus::Params& params)
{
LOCK(cs_main); return (VersionBitsState(pindexPrev, params, 
Consensus::DEPLOYMENT_SEGWIT, versionbitscache) ==
THRESHOLD_LOCKED_IN);
}
// SPLITPROTECTION mandatory segwit signalling.
if ( VersionBitsState(pindex->pprev, chainparams.GetConsensus(),
Consensus::DEPLOYMENT_SPLITPROTECTION, versionbitscache) ==
THRESHOLD_LOCKED_IN &&
 !IsWitnessLockedIn(pindex->pprev, chainparams.GetConsensus()) && 
// Segwit is not locked in
 !IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus()) ) // 
and is not active.
{
bool fVersionBits = (pindex->nVersion & VERSIONBITS_TOP_MASK) == 
VERSIONBITS_TOP_BITS;
bool fSegbit = (pindex->nVersion & 
VersionBitsMask(chainparams.GetConsensus(),
Consensus::DEPLOYMENT_SEGWIT)) != 0;
if (!(fVersionBits && fSegbit)) { return state.DoS(0, error("ConnectBlock(): relayed block must 
signal for segwit, please upgrade"), REJECT_INVALID, "bad-no-segwit");
} 
}
// BIP148 mandatory segwit signalling.
int64_t nMedianTimePast = pindex->GetMedianTimePast();
if ( (nMedianTimePast >= 1501545600) && // Tue 01 Aug 2017 00:00:00 UTC
 (nMedianTimePast <= 1510704000) && // Wed 15 Nov 2017 00:00:00 UTC (!IsWitnessLockedIn(pindex->pprev, chainparams.GetConsensus()) && 
// Segwit is not locked in
 !IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus())) ) 
// and is not active.
{
bool fVersionBits = (pindex->nVersion & VERSIONBITS_TOP_MASK) == 
VERSIONBITS_TOP_BITS;
bool fSegbit = (pindex->nVersion & 
VersionBitsMask(chainparams.GetConsensus(),
Consensus::DEPLOYMENT_SEGWIT)) != 0;
if (!(fVersionBits && fSegbit)) { return state.DoS(0, error("ConnectBlock(): relayed block must 
signal for segwit, please upgrade"), REJECT_INVALID, "bad-no-segwit");
} 
}
https://github.com/bitcoin/bitcoin/compare/0.14...jameshilliard:splitprotection-v0.14.1
==Backwards Compatibility==
This deployment is compatible with the existing "segwit" bit 1
deployment scheduled between midnight November 15th, 2016 and midnight
November 15th, 2017. This deployment is also compatible with the
existing BIP148 deployment. This BIP is compatible with BIP91 only if
BIP91 activates before it and before BIP148. Miners will need to
upgrade their nodes to support splitprotection otherwise they may
build on top of an invalid block. While this bip is active users
should either upgrade to splitprotection or wait for additional
confirmations when accepting payments.
==Rationale==
Historically we have used IsSuperMajority() to activate soft forks
such as BIP66 which has a mandatory signalling requirement for miners
once activated, this ensures that miners are aware of new rules being
enforced. This technique can be leveraged to lower the signalling
threshold of a soft fork while it is in the process of being deployed
in a backwards compatible way. We also use a BIP8 style timeout to
ensure that this BIP is compatible with BIP148 and that BIP148
compatible mandatory signalling activates regardless of miner
signalling levels.
By orphaning non-signalling blocks during the BIP9 bit 1 "segwit"
deployment, this BIP can cause the existing "segwit" deployment to
activate without needing to release a new deployment. As we approach
BIP148 activation it may be desirable for a majority of miners to have
a method that will ensure that there is no chain split.
==References==
*[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013714.html
Mailing list discussion]
*[https://github.com/bitcoin/bitcoin/blob/v0.6.0/src/main.cpp#L1281-L1283
P2SH flag day activation]
*[[bip-0009.mediawiki|BIP9 Version bits with timeout and delay]]
*[[bip-0016.mediawiki|BIP16 Pay to Script Hash]]
*[[bip-0091.mediawiki|BIP91 Reduced threshold Segwit MASF]]
*[[bip-0141.mediawiki|BIP141 Segregated Witness (Consensus layer)]]
*[[bip-0143.mediawiki|BIP143 Transaction Signature Verification for
Version 0 Witness Program]]
*[[bip-0147.mediawiki|BIP147 Dealing with dummy stack element malleability]]
*[[bip-0148.mediawiki|BIP148 Mandatory activation of segwit deployment]]
*[[bip-0149.mediawiki|BIP149 Segregated Witness (second deployment)]]
*[https://bitcoincore.org/en/2016/01/26/segwit-benefits/ Segwit benefits]
==Copyright==
This document is dual licensed as BSD 3-clause, and Creative Commons
CC0 1.0 Universal.
original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014508.html
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

Help! Deposited LTC to BTC address

Hey guys, I accidently sent 20 LTC from poloniex to BTC address on Bitmex. I contacted support and I have no idea what to do. This is the respond i got:
"You sent Litecoin to Bitcoin P2SH (Pay To Script Hash) address 3BMEX225BF6GsY5QJZhfpWSX5QKvFQh9Pc.
Here is the script:
534104123d40317a215f352c84326aa92b05bcdccaa58497a79fa1665df823ceeba0e74c63967804f2ae1f60f3784a55b99d972b4761da336ed8c2792c6bdbfd92c9c64104220936c3245597b1513a9a7fe96d96facf1a840ee21432a1b73c2cf42c1810284dd730f21ded9d818b84402863a2b5cd1afe3a3d13719d524482592fb23c88a3410472225d3abc8665cf01f703a270ee65be5421c6a495ce34830061eb0690ec27dfd1194e27b6b0b659418d9f91baec18923078aac18dc19699aae82583561fefe54104a24db5c0e8ed34da1fd3b6f9f797244981b928a8750c8f11f9252041daad7b2d95309074fed791af77dc85abdd8bb2774ed8d53379d28cd49f251b9c08cab7fc54ae
If you construct a valid Litecoin transaction that spends tx 82b7e19a7a5fd20012fbf0ed6c5b766d7e7ca5f39d90a6b116b68f45a0e5c8d2 and you provide it to us in hex format then we can try and get the partners to sign it and then give it back to you for broadcasting. I have no idea if Litecoin even supports BIP16 and you will have to work out how to do this yourself."
Anyone can help me with this? I will give u 1/2 of the recovered LTC which is 10LTC.
Address: 3BMEX225BF6GsY5QJZhfpWSX5QKvFQh9Pc
Txid: 82b7e19a7a5fd20012fbf0ed6c5b766d7e7ca5f39d90a6b116b68f45a0e5c8d2
Amount: 20.42562894 LTC
submitted by gero90 to litecoin [link] [comments]

Reduced signalling threshold activation of existing segwit deployment | James Hilliard | May 22 2017

James Hilliard on May 22 2017:
I would like to propose an implementation that accomplishes the first
part of the Barry Silbert proposal independently from the second:
"Activate Segregated Witness at an 80% threshold, signaling at bit 4"
in a way that
The goal here is to minimize chain split risk and network disruption
while maximizing backwards compatibility and still providing for rapid
activation of segwit at the 80% threshold using bit 4.
By activating segwit immediately and separately from any HF we can
scale quickly without risking a rushed combined segwit+HF that would
almost certainly cause widespread issues.
Draft proposal:
https://github.com/jameshilliard/bips/blob/bip-segsignal/bip-segsignal.mediawiki
Proposal text:
BIP: segsignal
Layer: Consensus (soft fork)
Title: Reduced signalling threshold activation of existing segwit deployment
Author: James Hilliard
Status: Draft
Type: Standards Track
Created: 2017-05-22
License: BSD-3-Clause
 CC0-1.0 
==Abstract==
This document specifies a method to activate the existing BIP9 segwit
deployment with a majority hashpower less than 95%.
==Definitions==
"existing segwit deployment" refer to the BIP9 "segwit" deployment
using bit 1, between November 15th 2016 and November 15th 2017 to
activate BIP141, BIP143 and BIP147.
==Motivation==
Segwit increases the blocksize, fixes transaction malleability, and
makes scripting easier to upgrade as well as bringing many other
[https://bitcoincore.org/en/2016/01/26/segwit-benefits/ benefits].
This BIP provides a way for a simple majority of miners to coordinate
activation of the existing segwit deployment with less than 95%
hashpower. For a number of reasons a complete redeployment of segwit
is difficulty to do until the existing deployment expires. This is due
to 0.13.1+ having many segwit related features active already,
including all the P2P components, the new network service flag, the
witness-tx and block messages, compact blocks v2 and preferential
peering. A redeployment of segwit will need to redefine all these
things and doing so before expiry would greatly complicate testing.
==Specification==
While this BIP is active, all blocks must set the nVersion header top
3 bits to 001 together with bit field (1<<1) (according to the
existing segwit deployment). Blocks that do not signal as required
will be rejected.
==Deployment==
This BIP will be deployed by a "version bits" with an 80%(this can be
adjusted if desired) activation threshold BIP9 with the name
"segsignal" and using bit 4.
This BIP will have a start time of midnight June 1st, 2017 (epoch time
1496275200) and timeout on midnight November 15th 2017 (epoch time
1510704000). This BIP will cease to be active when segwit is
locked-in.
=== Reference implementation ===
// Check if Segregated Witness is Locked In
bool IsWitnessLockedIn(const CBlockIndex* pindexPrev, const
Consensus::Params& params)
{
LOCK(cs_main); return (VersionBitsState(pindexPrev, params, 
Consensus::DEPLOYMENT_SEGWIT, versionbitscache) ==
THRESHOLD_LOCKED_IN);
}
// SEGSIGNAL mandatory segwit signalling.
if ( VersionBitsState(pindex->pprev, chainparams.GetConsensus(),
Consensus::DEPLOYMENT_SEGSIGNAL, versionbitscache) == THRESHOLD_ACTIVE
&&
 !IsWitnessLockedIn(pindex->pprev, chainparams.GetConsensus()) && 
// Segwit is not locked in
 !IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus()) ) // 
and is not active.
{
bool fVersionBits = (pindex->nVersion & VERSIONBITS_TOP_MASK) == 
VERSIONBITS_TOP_BITS;
bool fSegbit = (pindex->nVersion & 
VersionBitsMask(chainparams.GetConsensus(),
Consensus::DEPLOYMENT_SEGWIT)) != 0;
if (!(fVersionBits && fSegbit)) { return state.DoS(0, error("ConnectBlock(): relayed block must 
signal for segwit, please upgrade"), REJECT_INVALID, "bad-no-segwit");
} 
}
https://github.com/bitcoin/bitcoin/compare/0.14...jameshilliard:segsignal-v0.14.1
==Backwards Compatibility==
This deployment is compatible with the existing "segwit" bit 1
deployment scheduled between midnight November 15th, 2016 and midnight
November 15th, 2017. Miners will need to upgrade their nodes to
support segsignal otherwise they may build on top of an invalid block.
While this bip is active users should either upgrade to segsignal or
wait for additional confirmations when accepting payments.
==Rationale==
Historically we have used IsSuperMajority() to activate soft forks
such as BIP66 which has a mandatory signalling requirement for miners
once activated, this ensures that miners are aware of new rules being
enforced. This technique can be leveraged to lower the signalling
threshold of a soft fork while it is in the process of being deployed
in a backwards compatible way.
By orphaning non-signalling blocks during the BIP9 bit 1 "segwit"
deployment, this BIP can cause the existing "segwit" deployment to
activate without needing to release a new deployment.
==References==
*[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013714.html
Mailing list discussion]
*[https://github.com/bitcoin/bitcoin/blob/v0.6.0/src/main.cpp#L1281-L1283
P2SH flag day activation]
*[[bip-0009.mediawiki|BIP9 Version bits with timeout and delay]]
*[[bip-0016.mediawiki|BIP16 Pay to Script Hash]]
*[[bip-0141.mediawiki|BIP141 Segregated Witness (Consensus layer)]]
*[[bip-0143.mediawiki|BIP143 Transaction Signature Verification for
Version 0 Witness Program]]
*[[bip-0147.mediawiki|BIP147 Dealing with dummy stack element malleability]]
*[[bip-0148.mediawiki|BIP148 Mandatory activation of segwit deployment]]
*[[bip-0149.mediawiki|BIP149 Segregated Witness (second deployment)]]
*[https://bitcoincore.org/en/2016/01/26/segwit-benefits/ Segwit benefits]
==Copyright==
This document is dual licensed as BSD 3-clause, and Creative Commons
CC0 1.0 Universal.
original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014380.html
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

Extension block proposal by Jeffrey et al | Luke Dashjr | Apr 04 2017

Luke Dashjr on Apr 04 2017:
Recently there has been some discussion of an apparent work-in-progress
extension block proposal by Christopher Jeffrey, Joseph Poon, Fedor Indutny,
and Steven Pair. Since this hasn't been formally posted on the ML yet, perhaps
it is still in pre-draft stages and not quite ready for review, but in light
of public interest, I think it is appropriate to open it to discussion, and
toward this end, I have reviewed the current revision.
For reference, the WIP proposal itself is here:
https://github.com/tothemoon-org/extension-blocks 
==Overall analysis & comparison==
This is a relatively complicated proposal, creating a lot of additional
technical debt and complexity in comparison to both BIP 141 and hardforks. It
offers no actual benefits beyond BIP 141 or hardforks, so seems irrational to
consider at face value. In fact, it fits much better the inaccurate criticisms
made by segwit detractors against BIP 141.
That being said, this proposal is very interesting in construction and is for
the most part technically sound. While ill-fit to merely making blocks larger,
it may be an ideal fit for fundamentally different block designs such as
Rootstock and MimbleWimble in absence of decentralised non-integrated
sidechains (extension blocks are fundamentally sidechains tied into Bitcoin
directly).
==Fundamental problem==
Extension blocks are a risk of creating two classes of "full nodes": those
which verify the full block (and are therefore truly full nodes), and those
which only verify the "base" block. However, because the extension is
consensus-critical, the latter are in fact not full nodes at all, and are left
insecure like pseudo-SPV (not even real SPV) nodes. This technical nature is
of course true of a softfork as well, but softforks are intentionally designed
such that all nodes are capable of trivially upgrading, and there is no
expectation for anyone to run with pre-softfork rules.
In general, hardforks can provide the same benefits of an extension block, but
without the false expectation and pointless complexity.
==Other problems & questions==
These outpoints may not be spent inside the mempool (they must be redeemed
from the next resolution txid in reality).
This breaks the ability to spend unconfirmed funds in the same block (as is
required for CPFP).
The extension block's transaction count is not cryptographically committed-to
anywhere. (This is an outstanding bug in Bitcoin today, but impractical to
exploit in practice; however, exploiting it in an extension block may not be
as impractical, and it should be fixed given the opportunity.)
The merkle root is to be calculated as a merkle tree with all extension
block txids and wtxids as the leaves.
This needs to elaborate how the merkle tree is constructed. Are all the txids
followed by all the wtxids (tx hashes)? Are they alternated? Are txid and
wtxid trees built independently and merged at the tip?
Output script code aside from witness programs, p2pkh or p2sh is considered
invalid in extension blocks.
Why? This prevents extblock users from sending to bare multisig or other
various possible destinations. (While static address forms do not exist for
other types, they can all be used by the payment protocol.)
Additionally, this forbids datacarrier (OP_RETURN), and forces spam to create
unprovably-unspendable UTXOs. Is that intentional?
The maximum extension size should be intentionally high.
This has the same "attacks can do more damage than ordinary benefit" issue as
BIP141, but even more extreme since it is planned to be used for future size
increases.
Witness key hash v0 shall be worth 1 point, multiplied by a factor of 8.
What is a "point"? What does it mean multiplied by a factor of 8? Why not just
say "8 points"?
Witness script hash v0 shall be worth the number of accurately counted
sigops in the redeem script, multiplied by a factor of 8.
Please define "accurately counted" here. Is this using BIP16 static counting,
or accurately counting sigops during execution?
To reduce the chance of having redeem scripts which simply allow for garbage
data in the witness vector, every 73 bytes in the serialized witness vector is
worth 1 additional point.
Is the size rounded up or down? If down, 72-byte scripts will carry 0
points...)
==Trivial & process==
BIPs must be in MediaWiki format, not Markdown. They should be submitted for
discussion to the bitcoin-dev mailing list, not social media and news.
Layer: Consensus (soft-fork)
Extension blocks are more of a hard-fork IMO.
License: Public Domain
BIPs may not be "public domain" due to non-recognition in some jurisdictions.
Can you agree on one or more of these?
https://github.com/bitcoin/bips/blob/mastebip-0002.mediawiki#Recommended_licenses

Abstract

This specification defines a method of increasing bitcoin transaction
throughput without altering any existing consensus rules.
This is inaccurate. Even softforks alter consensus rules.

Motivation

Bitcoin retargetting ensures that the time in between mined blocks will be
roughly 10 minutes. It is not possible to change this rule. There has been
great debate regarding other ways of increasing transaction throughput, with
no proposed consensus-layer solutions that have proven themselves to be
particularly safe.
Block time seems entirely unrelated to this spec. Motivation is unclear.
Extension blocks leverage several features of BIP141, BIP143, and BIP144 for
transaction opt-in, serialization, verification, and network services, and as
such, extension block activation entails BIP141 activation.
As stated in the next paragraph, the rules in BIP 141 are fundamentally
incompatible with this one, so saying BIP 141 is activated is confusingly
incorrect.
This specification should be considered an extension and modification to
these BIPs. Extension blocks are not compatible with BIP141 in its current
form, and will require a few minor additional rules.
Extension blocks should be compatible with BIP 141, there doesn’t appear to be
any justification for not making them compatible.
This specification prescribes a way of fooling non-upgraded nodes into
believing the existing UTXO set is still behaving as they would expect.
The UTXO set behaves fundamentally different to old nodes with this proposal,
albeit in a mostly compatible manner.
Note that canonical blocks containing entering outputs MUST contain an
extension block commitment (all zeroes if nothing is present in the extension
block).
Please explain why in Rationale.
Coinbase outputs MUST NOT contain witness programs, as they cannot be
sweeped by the resolution transaction due to previously existing consensus
rules.
Seems like an annoying technical debt. I wonder if it can be avoided.
The genesis resolution transaction MAY also include a 1-100 byte pushdata in
the first input script, allowing the miner of the genesis resolution to add a
special message. The pushdata MUST be castable to a true boolean.
Why? Unlike the coinbase, this seems to create additional technical debt with
no apparent purpose. Better to just have a consensus rule every input must be
null.
The resolution transaction's version MUST be set to the uint32 max (`232 -
1`).
Transaction versions are signed, so I assume this is actually simply -1.
(While signed transaction versions seemed silly to me, using it for special
cases like this actually makes sense.)

Exiting the extension block

Should specify that spending such an exit must use the resolution txid, not
the extblock's txid.
On the policy layer, transaction fees may be calculated by transaction cost
as well as additional size/legacy-sigops added to the canonical block due to
entering or exiting outputs.
BIPs should not specify policy at all. Perhaps prefix "For the avoidance of
doubt:" to be clear that miners may perform any fee logic they like.
Transactions within the extended transaction vector MAY include a witness
vector using BIP141 transaction serialization.
Since extblock transactions are all required to be segwit, why wouldn't this
be mandatory?
consensus rule.
Note this makes adoption slower: wallets cannot use the extblock until the
economy has updated to support segwit-native addresses.
To reduce the chance of having redeem scripts which simply allow for garbage
data in the witness vector, every 73 bytes in the serialized witness vector is
worth 1 additional point.
Please explain why 73 bytes in Rationale.
This leaves room for 7 future soft-fork upgrades to relax DoS limits.
How so? Please explain.
A consensus dust threshold is now enforced within the extension block.
Why?
If the second highest transaction version bit (30th bit) is set to to 1
within an extension block transaction, an extra 700-bytes is reserved on the
transaction space used up in the block.
Why wouldn't users set this on all transactions?
default_witness_commitment has been renamed to
default_extension_commitment and includes the extension block commitment
script.
default_witness_commitment was never part of the GBT spec. At least describe
what this new key is.
Should be just extblk if backward compatibility is supported (and !extblk
when not).
The "deactivation" deployment'...[message truncated here by reddit bot]...
original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/013981.html
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

Flag day activation of segwit | shaolinfry | Mar 12 2017

shaolinfry on Mar 12 2017:
I recently posted about so called "user activated soft forks" and received a lot of feedback. Much of this was how such methodologies could be applied to segwit which appears to have fallen under the miner veto category I explained in my original proposal, where there is apparently a lot of support for the proposal from the economy, but a few mining pools are vetoing the activation.
It turns out Bitcoin already used flag day activation for P2SH[1], a soft fork which is remarkably similar to segwit. The disadvantage of a UASF for segwit is there is an existing deployment. A UASF would require another wide upgrade cycle (from what I can see, around 80% of existing nodes have upgraded from pre-witness, to NODE_WITNESS capability[2][3]. While absolute node count is meaningless, the uprgrade trend from version to version seems significant.
Also it is quite clear a substantial portion of the ecosystem industry has put in time and resources into segwit adoption, in the form of upgrading wallet code, updating libraries and various other integration work that requires significant time and money. Further more, others have built systems that rely on segwit, having put significant engineering resources into developing systems that require segwit - such as several lightning network system. This is much more significant social proof than running a node.
The delayed activation of segwit is also holding back a raft protocol of innovations such as MAST, Covenants, Schnorr signature schemes and signature aggregation and other script innovations of which, much of the development work is already done.
A better option would be to release code that causes the existing segwit deployment to activate without requiring a completely new deployment nor subject to hash power veto. This could be achieved if the economic majority agree to run code that rejects non-signalling segwit blocks. Then from the perspective of all existing witness nodes, miners trigger the BIP9 activation. Such a rule could come into effect 4-6 weeks before the BIP9 timeout. If a large part of the economic majority publicly say that they will adopt this new client, miners will have to signal bip9 segwit activation in order for their blocks to be valid.
I have drafted a BIP proposal so the community may discuss https://gist.github.com/shaolinfry/743157b0b1ee14e1ddc95031f1057e4c (full text below).
References:
Proposal text:
BIP: bip-segwit-flagday Title: Flag day activation for segwit deployment Author: Shaolin Fry Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-???? Status: Draft Type: Informational Created: 2017-03-12 License: BSD-3-Clause CC0-1.0 ==Abstract== This document specifies a BIP16 like soft fork flag day activation of the segregated witness BIP9 deployment known as "segwit". ==Definitions== "existing segwit deployment" refer to the BIP9 "segwit" deployment using bit 1, between November 15th 2016 and November 15th 2017 to activate BIP141, BIP143 and BIP147. ==Motivation== Cause the mandatory activation of the existing segwit deployment before the end of midnight November 15th 2017. ==Specification== All times are specified according to median past time. This BIP will be activate between midnight October 1st 2017 (epoch time 1538352000) and midnight November 15th 2017 (epoch time 1510704000) if the existing segwit deployment is not activated before epoch time 1538352000. This BIP will cease to be active when the existing segwit deployment activates. While this BIP is active, all blocks must set the nVersion header top 3 bits to 001 together with bit field (1<<1) (according to the existing segwit deployment). Blocks that do not signal as required will be rejected. === Reference implementation === // mandatory segwit activation between Oct 1st 2017 and Nov 15th 2017 inclusive if (pindex->GetMedianTimePast() >= 1538352000 && pindex->GetMedianTimePast() <= 1510704000 && !IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus())) { if (!((pindex->nVersion & VERSIONBITS_TOP_MASK) == VERSIONBITS_TOP_BITS) && (pindex->nVersion & VersionBitsMask(params, Consensus::DEPLOYMENT_SEGWIT)) != 0) { return state.DoS(2, error("ConnectBlock(): relayed block must signal for segwit, please upgrade"), REJECT_INVALID, "bad-no-segwit"); } } ==Backwards Compatibility== This deployment is compatible with the existing "segwit" bit 1 deployment scheduled between midnight November 15th, 2016 and midnight November 15th, 2017. ==Rationale== Historically, the P2SH soft fork (BIP16) was activated using a predetermined flag day where nodes began enforcing the new rules. P2SH was successfully activated with relatively few issues By orphaning non-signalling blocks during the last month of the BIP9 bit 1 "segwit" deployment, this BIP can cause the existing "segwit" deployment to activate without needing to release a new deployment. ==References== [https://github.com/bitcoin/bitcoin/blob/v0.6.0/src/main.cpp#L1281-L1283 P2SH flag day activation]. ==Copyright== This document is placed in the public domain.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170312/6e8cc65a/attachment-0001.html
original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013714.html
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

My understanding of the "scaling" debate (rbtc exclusive post)

Mild trigger warning:
The maximum page-size of a distributed ledger has an inverse relationship to it's performance. Larger pages = more capacity + worse performance. Simply increasing the blocksize and chanting "Moore's law" is so unfathomably far down on any halfway reputable software engineer's *scalability tool-set*, that to some it might appear as though we would never see a blocksize increase. 
Severe tribalism, greed and toxic discourse has polarized Bitcoin into "small blockers" and "big blockers". The undeniable truth however is that an overwhelming majority of Bitcoiners (probably far beyond >90%) are big blockers. People are just disagreeing on when... not on if.
Trolls capitalized on this divide and started politicizing poor social media relations and code quality. Encouraging hordes of software illiterateWe are all illiterate with regards to most things we don't specialize in users to fight over asinine issues such as "Flextrans vs Segwit".
The entire blocksize debate is a mirror image of BIP16 vs BIP17 (only on a much much grander scale) to which Gavin had the following to say
All of the BIP 16/17 stuff is mostly engineers arguing over whether it is better to use a nail, a screw, or glue to put two pieces of wood together. Any of the solutions would work, and ordinary users wouldn't notice any difference; you'll still (eventually) get spiffy, more secure wallets.
Cliffnotes:
Literally no one cares today... Not even people who were around back when this was an issue. I am saddened by all the shit stirrers propagating the same polarizing bullshit day after day after day. I am confident that in another 5 years the current debate will be forgotten and we will be expending insane amounts of effort on another asinine issue.
Much like with the Linux desktop... we'll be waiting for the "Year of Bitcoin" for much longer... unless we somehow manage to pull on the same side of the rope.
submitted by lpqtr to btc [link] [comments]

Segregated Witness features wish list | jl2012 at xbt.hk | Dec 10 2015

jl2012 at xbt.hk on Dec 10 2015:
It seems the current consensus is to implement Segregated Witness. SW
opens many new possibilities but we need a balance between new features
and deployment time frame. I'm listing by my priority:
1-2 are about scalability and have highest priority
  1. Witness size limit: with SW we should allow a bigger overall block
size. It seems 2MB is considered to be safe for many people. However,
the exact size and growth of block size should be determined based on
testing and reasonable projection.
  1. Deployment time frame: I prefer as soon as possible, even if none of
the following new features are implemented. This is not only a technical
issue but also a response to the community which has been waiting for a
scaling solution for years
3-6 promote safety and reduce level of trust (higher priority)
  1. SIGHASH_WITHINPUTVALUE [1]: there are many SIGHASH proposals but this
one has the highest priority as it makes offline signing much easier.
  1. Sum of fee, sigopcount, size etc as part of the witness hash tree:
for compact proof of violations in these parameters. I prefer to have
this feature in SWv1. Otherwise, that would become an ugly softfork in
SWv2 as we need to maintain one more hash tree
  1. Height and position of an input as part of witness will allow compact
proof of non-existing UTXO. We need this eventually. If it is not done
in SWv1, we could softfork it nicely in SWv2. I prefer this earlier as
this is the last puzzle for compact fraud proof.
  1. BIP62 and OP_IF malleability fix [2] as standardness rules:
involuntary malleability may still be a problem in the relay network and
may make the relay less efficient (need more research)
7-15 are new features and long-term goals (lower priority)
  1. Enable OP_CAT etc:
OP_CAT will allow tree signatures described by [3]. Even without Schnorr
signature, m-of-n multisig will become more efficient if m < n.
OP_SUBSTOP_LEFT/OP_RIGHT will allow people to shorten a payment
address, while sacrificing security.
I'm not sure how those disabled bitwise logic codes could be useful
Multiplication and division may still considered to be risky and not
very useful?
  1. Schnorr signature: for very efficient multisig [3] but could be
introduced later.
  1. Per-input lock-time and relative lock-time: define lock-time and
relative lock-time in witness, and signed by user. BIP68 is not a very
ideal solution due to limited lock time length and resolution
  1. OP_PUSHLOCKTIME and OP_PUSHRELATIVELOCKTIME: push the lock-time and
relative lock-time to stack. Will allow more flexibility than OP_CLTV
and OP_CSV
  1. OP_RETURNTURE which allows softfork of any new OP codes [4]. It is
not really necessary with the version byte design but with OP_RETURNTURE
we don't need to pump the version byte too frequently.
  1. OP_EVAL (BIP12), which enables Merkleized Abstract Syntax Trees
(MAST) with OP_CAT [5]. This will also obsolete BIP16. Further
restrictions should be made to make it safe [6]:
a) We may allow at most one OP_EVAL in the scriptPubKey
b) Not allow any OP_EVAL in the serialized script, nor anywhere else in
the witness (therefore not Turing-complete)
c) In order to maintain the ability to statically analyze scripts, the
serialized script must be the last push of the witness (or script
fails), and OP_EVAL must be the last OP code in the scriptPubKey
  1. Combo OP codes for more compact scripts, for example:
OP_MERKLEHASH160, if executed, is equivalent to OP_SWAP OP_IF OP_SWAP
OP_ENDIF OP_CAT OP_HASH160 [3]. Allowing more compact tree-signature and
MAST scripts.
OP_DUPTOALTSTACK, OP_DUPFROMALTSTACK: copy to / from alt stack without
removing the item
  1. UTXO commitment: good but not in near future
  2. Starting as a softfork, moving to a hardfork? SW Softfork is a quick
but dirty solution. I believe a hardfork is unavoidable in the future,
as the 1MB limit has to be increased someday. If we could plan it ahead,
we could have a much cleaner SW hardfork in the future, with codes
pre-announced for 2 years.
[1] https://bitcointalk.org/index.php?topic=181734.0
[2]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-Novembe011679.html
[3] https://blockstream.com/2015/08/24/treesignatures/
[4] https://bitcointalk.org/index.php?topic=1106586.0
[5]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-Septembe010977.html
[6] https://bitcointalk.org/index.php?topic=58579.msg690093#msg690093
original: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-Decembe011935.html
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

Merged Mining is temporarily disabled. Info Inside

I'll get straight to the point. This recent bad luck has been draining the buffer pretty hard. I'm not sure if it is just normal 'Bad' luck, or if it's a problem with the Bip16 patches. Mainly the vinced mm patch.
A month ago, when the voting for Bip16 was going on, I was working with Gavin, testing his patches, but they where throwing errors on some solved shares.
I've been watching the logs live for the past week, and haven't seen any errors but still not exactly sure If I trust the patches. I've decided to temporarily disable Merged Mining (So no Namecoin mining) to run against the latest bitcoind. Your nmc balance will still be there, payouts will still work.
After the outage last month, I've convinced our host to give us 2 months rent free. This is a small burden off the server costs but won't last forever. If you can spare a few bitcoin, any little bit helps, it would be most appreciated.
As Always Thanks, RR
submitted by RedditorRex to mtred [link] [comments]

Revisiting the UASF with Juan Galt ~ Open Source Everything Minter BIP- Как купить и продать / Как делегировать и получать BIP / Часть 2 Is Bitcoin Going To Fork? Protect Your Bitcoin! How to buy BIP with BTC (bitcoin) via bip.dev (a trusted exchanger) - Minter Bip Late night show with Satoshi Nakamoto

Bitcoin imposes a maximum-number-of-signature-operations per block to prevent denial-of-service attacks on miners. If there was no limit, a rogue miner might broadcast a block that required hundreds of thousands of ECDSA signature operations to validate, and it might be able to get a head start computing the next block while the rest of the network worked to validate the current one. There is ... Run 0.6 Bitcoin-Qt GUI on one of the test wallets from above. Result: balance and transactions displayed correctly Gavin Andresen Run BIP-16-capable backport Bitcoin 0.3.19 through 0.5.1 on testnet and main net. Send coins using GUI, RCP sendtoaddress, and RCP sendmany commands Result: coins sent in all cases Gavin Andresen (tested 0.3.19, 0.3.24 and 0.5.1) Run BIP-16-capable Bitcoin 0.6.0 on ... Bitcoin's reference implementation currently relies on OpenSSL for signature validation, which means it is implicitly defining Bitcoin's block validity rules. Unfortunately, OpenSSL is not designed for consensus-critical behaviour (it does not guarantee bug-for-bug compatibility between versions), and thus changes to it can - and have - affected Bitcoin software. Taproot, the highly-anticipated protocol upgrade designed to add smart contract flexibility and more transactional privacy to Bitcoin, has officially merged into Bitcoin Core. The implementation now merged into Bitcoin’s code includes the Schnorr and Taproot consensus rules proposed in BIPs 340 , 341 and 342 , authored by Core contributors Pieter Wuille, Jonas Nick, Anthony Towns and Tim ... Bitcoin Improvement Proposal (BIP) is a design document for introducing features or information to Bitcoin. The BIP should provide a concise technical specification of the attribute and a rationale for the feature. This is the standard way of communicating ideas since Bitcoin has no formal structure.

[index] [45350] [44499] [49965] [3138] [22669] [12974] [26457] [40630] [19496] [24317]

Revisiting the UASF with Juan Galt ~ Open Source Everything

UASF stands for User Activated Soft Fork. It’s a mechanism where the activation time of a soft fork occurs on a specified date enforced by full nodes, a concept sometimes referred to as the ... #Minter #BIP #минтер Как купить/продать Minter BIP - как делегировать и получать BIP Купить BIP Minter ... In the past, a UASF was successfully carried out to activate the P2SH soft fork (BIP16). The UASF concept was combined with SegWit activation in the BIP148 proposal which can be found here: github ... [bitcoin] Go to the source and read it from Satoshi Nakamoto's paper - Duration: 11:21. Satoshi Pollen Recommended for you. 11:21. Bitcoin Q&A: Who is Satoshi Nakamoto? - Duration: 4:16. ... Публичный ключ для делегирования Bip Minter - Mpa70d12c096cb459e7c191be0dffb1a7dbe4a9587bfa7174c654959e5e9da7203 Telegram группа ...

#