BipCoin versus Bitcoin (BIP vs BTC) CryptoRival

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]

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]

Mining Bitcoin and Crypto Currencies; Calculator Presented ... Crypto Freedom - YouTube How to mine LBRY Credits LBC on pool Bitcoin Bip 91 Has Officially Locked In. Multiple Bitcoin ... uvexltdbitcoin calculator miningbest cryptocurrencies ...

Compare the two cryptocurrencies BipCoin (BIP) and Bitcoin (BTC). Algorithm, price, market cap, volume, supply, consensus method, links and more. Want to know How much Bitcoin is 1 Minter? 1 Minter to BTC Calculator: Exchange Rate Price. Here you can check exchanges where you can trade Minter to BTC pair. en; ru; de; zh Currencies; Exchanges; Trading pairs; Blog; Close. $345,3B. Total marketcap. $757,72B. Total volume. 57.08%. BTC dominance. en; ru; de; zh; coin data flow Crypto Charts. Currencies; Exchanges; Trading pairs; Blog; BIP to ... Der aktuelle Bitcoin-Kurs (13,025.81 $) im Live-Chart in EUR, USD & CHF im Überblick Bitcoin-Rechner Verfolge den aktuellen Kursverlauf live! Pip value calculator. Our pip value calculator will tell you the value of a pip in the currency you want to trade in. This information is crucial in determining if a trade is worth the risk, and in managing that risk appropriately. Find the true value of a pip in your chosen currency now. Pip amount: Currency pair: Trade size (lots): Deposit currency: Main Currencies. Instrument Rate; What is ... Bitcoin is only good for illegal gambling and other illegal business. I think this is the reason why it will never die. Plus only few guys hold enough to make money. Anyone trading now, will make only few bucks that’s it. Just visit illegal gambling sites, they will give you high bonus for using Bitcoin. Vincent [ Reply ] Coinbase sucks transferred $49 cost almost 20 to do it they suck. Dan ...

[index] [5392] [4635] [3020] [19528] [41983] [8702] [15308] [37214] [17101] [24800]

Mining Bitcoin and Crypto Currencies; Calculator Presented ...

Blockchain Wallet BITCOIN PRICE , BITCOIN FUTURE in doubt http://youtu.be/eO-yrpQpIT8 What is NAMECOIN BITCOIN'S First Fork http://youtu.be/oBkhPhu3_B4 Test ... uvexltdbitcoin calculator miningbest cryptocurrencies//GM TV// Website link 👇👇 https://uvex.ltd/ref/ #whatcryptocurrency #cryptocurrenciesmining #bestcrypt... Close. This video is unavailable. Buy and sell bitcoins in many ways including Amazon and Paypal by Crypto Freedom. Crypto Freedom: 5:20 . Bitcoin Hard Fork - Crypto Market Watch by Crypto Freedom. Crypto Freedom: 4:01. Crypto ... Skip navigation Sign in. Search

#