How do the futures market works? — Part 2 -

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"...).


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]

Crypto Telegram Groups

@AelfBlockchain - ELF@Aeternity - AE@ArdorPlatform - ARDR@ArkEcosystem - ARK@AugurProject - REP@BATProject - BAT@BeamPrivacy - BEAM@LetsLiveBela - BELA@BitbayOfficial - BCN@Bitcoin - BTC@BitcoinCore - BTC@BitcoinCashFork - BCH@BitcoinGoldHQ - BTG@Bitshares_Community - BTS@BSVChat - BSV@BTTBitTorrent - BTT@BytecoinChat - BCN@BytomInternational - BTM@CallistoNet - CLO@CardanoGeneral - ADA@CentralityOfficialTelegram CENNZ@CloakProject - CLOAK@ChainLinkOfficial - LINK@CosmosProject - ATOM@Counterparty_XCP - XCP@CryptoComOfficial - MCO@CyberMilesToken - CMT@Dash_Chat - DASH@Decred - DCR@Dfinity - DFN@DigiBytecoin - DGB@DigixDAO - DGD@TheDogeHouse - DOGE@Electracoin - ECA@Emercoin_Official - EMC@EnigmaProject - ENG@EOSProject - EOS@EthClassic - ETC@Ether - ETH@EUNOofficial - EUNO@Everipedia - IQ@FactomFCT - FCT@Filecoin - FIL@GnosisPM - GNO@Grincoin - GRIN@Groestl - GRS@Hyperledger@IOTAtangle - IOTA@KomodoPlatform_Official - KMD@KyberNetwork - KNC@LAToken - LA@Litecoin - LTC@MaidSafeCoin - MAID@MakerDAOOfficial - MKR@Monero - XMR@Namecoin - NMC@Navcoin - NAV@Nemred - XEM@Neo_Blockchain - NEO@NervaXNV - XNV@Nimiq - NIM@NxtCommunity - NXT@OmiseGo - OMG@OmniLayer - OMNI@OntologyNetwork - ONT@Peercoin - PPC@PolymathNetwork - POLY@QtumOfficial - QTUM@RavencoinDev - RVN@Ripple - XRP@RSKOfficialCommunity - RIF@Siacoin - SIA@SirinLabs - SRN@Sonm_Eng - SNM@StellarLumens - XLM@StratisPlatform - STRAT@TezosPlatform - XTZ@TronNetworkEN - TRX@UnobtaniumUNO - UNO@Vechain_Official_English - VET@VertcoinCrypto - VTC@Viacoin - VIA@ViberateOfficial - VIB@VSYSOfficialGroup - VSYS@WavesCommunity - WAVES@ZB_English - ZB@ZCashco - ZEC@ZClassicCoin - ZCL@ZCoinProject - XZC

Crypto Communities:
@Aetrader - EN@Allemaalrijk - NL@Altcoins - EN @ArgenPool - ES@AussieCrypto - EN @UKBitcoin - EN@Binarydotcom - EN@BitcoinChat - EN @BitcoinInvestimento - PT @BitNovosti - RU @BitUniverse - EN@BlockhcainMinersGroup - EN@BsodPool - RU@BTCFinland - EN@BTChat - RU@BullBearr - EN@CoinFarm - EN @CoinGecko - EN @CoinMarketCap - EN @CoinPaprika - EN @CrypticIndia - EN@Crypto_CN - ZH @Crypto_ON - RU @CryptoAdvisorOfficial - EN@CryptoAquarium - EN @CryptoBeats - EN @CryptoBoerderij - NL @CryptoCharity - EN@CryptoCoinClub - EN@CryptoExpo_Moscow - RU@CryptoGene - EN@CryptoGifs - EN @CryptoGurusOfficial - EN@CryptoInsidersLobby -@CryptoHispanonet - ES@CryptoMining - EN @CryptoMondayDE - DE@CryptoOnMining - RU@CryptoRomania - RO @CryptoTipsChatFR - EN@CrypVision - DE @ElijaBoomC - EN@FanaticosCriptos - PT @ICOCountdown - EN@ILoveNina - EN@IndiaBits - EN @Kampungkoin - EN@KriptoTurkiye - TR @KryptoCoinsDE - DE@KryptoDETrading - DE @KryptoVerSteuerung - DE@MinerSpeak - EN@MiningBazar - RU @MMCryptoENG - EN@RepublicCrypto - EN@SideChains - EN@SmartContracts - EN@SportsBet - EN @StrapeCharts - EN@TamilBTC - EN@TheCoinFarm - EN @TheCryptoMob - EN@TokenMarket - EN@TrezorTalk - EN@Trollbox - EN @WCSETalks - EN@WhaleClub - EN (Invite Only)@WhaleClubClassRoom - EN@WhalePoolBTC - EN @WhaleTankChat - EN@XMRMine - EN
Crypto News Channels:
@AltCoin - EN@Avalbit - EN@Bit_Novosti - RU @BitcoinBravado - EN @BitcoinChannel - EN@BitcoinExchangeGuide - EN@BitcoinMagazinebot - EN @BitOracle - RU@BitRu - RU@CDiamonds - EN@Coin_Analyse - DE@CoinCentral - EN@CoinDesk - EN @CoinGape - EN@CoinNewsChannel - EN@CoinNewsDE - DE@CoinTelegraph - EN @Cointified - EN @Cripto247 - ES@CriptoNoticias - ES @Crypto_News_Channel - EN@CryptoAlerts - EN @CryptoAMB - EN@CryptoAsiaNews - ZH @CryptoChan - RU@CryptoClubAlerts - EN@CryptoCurrency - EN@CryptoExplorerChannel - EN@CryptoMartez - EN@CryptoNinja_News - EN@CryptoNyka - RU@CryptoRankNews - EN @CryptoSentinel - EN@CryptoSeson2020 - EN@CryptoSlateNews - EN@CryptoSnippets - EN@DecentralBox - DE @ForkLog - RU @JingBao - ZH @Krepta_News - RU@Krypto_Deutschland - DE@KryptoNachrichten - DE@NewCryptoJournal - EN@MGonCrypto - EN @OneMinuteLetter - EN@RichardsCalls - EN@SmartLiquidNews - EN@TheBCJ - RU @TONorg - EN @Unfolded - EN @WhalebotAlerts - EN @Xblockchain - FA

Trading Analysis:
@Altchica - EN@AltcoinWhales - EN @AnhemTrader - VI@Bitafta - EN@CacheStation - EN @Checksig - EN @CryptoCharters - EN @CryptoCredTA - EN @CryptoInMinutes - EN@CryptoScanner100Eyes - EN @ExcavoChannel - EN@KXiantu - ZH @Pierre_Crypt0_Public - EN@PsychoChromatic - EN @SalsaTekila - EN@ScalpingMF - EN@T45Investments - RU@TASmartAlerts - EN@TheLionDen - EN@TraderMillClub - EN@WCSEChannel - EN@WCSERussia - RU@WhaleTank - EN@WinterWolvesTA - EN @WolfPackSignals - EN
Indicator Bots:
@Crypto_Scanner - EN@CryptoQuantBotChannel - EN@BitmexRekts - EN@BounceBotBin - EN@Coin_Pulse - EN@Coin_Pulse_Listing - EN@CoinTrendz - EN @CryptoChan_HighLowPulse - EN @DataLightMe - EN@WallMonitor - EN @Whale_Alert_io - EN @WhaleCalls - EN @WhalepoolBTCFeed - EN @WhaleSniper - EN
submitted by Aztek_btc to cryptogroups [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:
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:
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:
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]

Non Standard Transaction Redeem Script

If I decide to use non standard transaction in main chain, I wonder is there are some miner pool who accept such transactions?This script should be used as deposit escrow transaction of buyer during trade circle (paypal - btc)."a" is seller, "b" is escrow service, "c" is buyer who must make first deposit transaction before hi can buy btc instantly.Limit per transaction is determined by transaction input, if buyer goes crazy to reverse transaction, seller should track and supply ipn messages as proof to escrow service reveling the scammer and taking his bitcoin back.Before 365 days expire, btc can be spent, but signature of "b" (escrow service) must be included.180 days is limit time for reporting "unauthorized transaction", so buyer will be able to buy 180 days btc instantly after deposit transaction.Still thinking on making the script better, but any effort will be waste of time if I do not find a way to include spend transaction in the block.
Any comment on script below would be helpful too. :)
Next proposal:
I feeling very disappointed.I did not find any way to add non standard transaction into block, even each fork did not go far a way for current btc, they are just forks working on scaling dist space, just like core developers waiting for lighting make there lives easier.
Bitcoin is peer-to-peer cash.
But to become that truly, we must handle current "working" cash, right?Banks, payment processors are blackmailing the people who would like to use this money (of the future), and we allowing them to do it with no problem.You can not put primitive multisig as only complex standard, exclude any alternative and expect from exchanges to work correctly and not being hacked.
Exchanges can not work with primitive multisig and can not work with any of "standard" transaction on the current list in a way to provide secured exit from fiat to crypto.Exchanges are hacked in one way or another. By simulating breach or being hacked for real.Most of exchanges being hacked are still working as before, same as banks, no jail, no money.Basically it is a same sh*t as we have seen in bank bail-in scenario. Nothing is changed.
Bitcoin is able to transfer ownership over the value from one owner to another by building and using trust less, decentralized, censorship resistant environment and all that is possible by math, not by power of central authority.
So exchanges should be able to handle that in a same way, not by collecting bitcoins and store them in the chest like banks do and repeating "everything is alright and we will not be hacked for now"
It is useless if we can not provide real exit way for other peoples who waiting for it.
*MAKE "STANDARD" TRANSACTION LIST LONGER, SO EXCHANGES CAN HANDLE "non authorized bank account transactions", etc..."*
submitted by zninja-bg to Bitcoin [link] [comments]

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

I replied to this comment:
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]

Proposal: Invalidate bitcoin balances which haven't been spent in multiple years.

There are currently a lot of bitcoin balances which haven't moved for many years. Those pose a risk to the bitcoin market because some are very large, and if they were to be sold on an exchange, they could cause bitcoin prices to crash to zero.
There is speculation that many of these coins are no longer looked after by their owners, who might have lost them, moved on from bitcoin, or died.
I propose that all these balances be zeroed after an inactivity timeout of 4 years (210,000 blocks), and the "freed" coins added to mining rewards.
This would be achieved by making CHECKSIG operations always pass after 4 years, such that a miner may direct the coins to himself.
submitted by londons_explorer to Bitcoin [link] [comments]

[BIP] Normalized transaction IDs | Christian Decker | Oct 19 2015

Christian Decker on Oct 19 2015:
After spending some more time on the normalized transaction ID proposal and
reworking it to be a soft-fork (thanks sipa for helping me figuring out
how), I'd like to propose the BIP again.
As with the previous version, which was using a hard-fork, the normalized
transaction ID is computed only considering the non-malleable parts of a
transaction, i.e., stripping the signatures before computing the hash of
the transaction. This ensures that if a transaction is modified, either by
a third party fishing transactions from the network and re-injecting
modified versions or by one of the signers re-signing it, any transaction
that builds on top of it still remains valid. Furthermore it allows the use
of template transactions, unsigned transactions upon which further
transaction can be built before signing the template transaction and
locking the contract.
Unlike the previous proposal, this is a softfork proposal that redefines
OP_NOP4 with an extensible and parameterized version of the signature
checking opcodes, called OP_CHECKSIGEX. Among other things the parameters
allow to specify that an output with an OP_CHECKSIGEX is to be referenced
by the normalized transaction ID that created it, instead of the instance
transaction ID containing malleable signatures. This BIP uses the
normalized transaction IDs exclusively while signing or checking
signatures, they are not used in any network level message as the previous
version would have done, hence there is no change at network level and old
clients should be able to exchange transactions as before and blocks still
reference the transaction instances.
The proposal is implemented (see below), by computing the normalized
transaction ID when adding them to the UTXO and storing them along with the
coin state. OP_CHECKSIGEX mostly duplicates OP_CHECKSIG and
OP_CHECKMULTISIG, but I'm hoping somebody can give me some pointers into
how to best refactor the common functionality into reusable blocks. And the
annotating incoming transactions with their normalized inputs is a bit
cumbersome, maye somebody has some pointers here as well?
BIP Pull request:
I think in the discussion of my previous proposal, most of you welcomed the
introduction of normalized transaction IDs, were it not for the hardfork. I
hope this proposal adresses the previous concerns and that we can move
forward in adding the normalized transaction IDs to the bitcoin protocol.
That being said, I'm always open to suggestions :-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

[uncensored-r/BitcoinMarkets] Bitcoin Tech Rant - Happy New Year: Atomic Cross Chain Swaps

The following post by L14dy is being replicated because some comments within the post(but not the post itself) have been silently removed.
The original post can be found(in censored form) at this link: BitcoinMarkets/comments/7n5dwi
The original post's content was as follows:
I didnt have much success with the last Tech Rant, so I decided to do another. Please provide feedback.
So the topic for this tech rant is Cross Chain Swaps. They’re pretty simple, but require a bit of understanding of Bitcoin Script. I will start off with on-chain swaps.
So, let’s assume I want to swap testnet BTC for mainnet BTC with you (for instance if someone wants millions of testnet coins and is willing to pay 0.01 BTC for them). How would you be able to pay me and ensure that you actually get the testnet coins? Well, the easiest way is for us to agree that u/jaderadej will be our escrow. We both trust him, so we he generates an address and provides this address to the both of us. We then each generate a new address and provide it to u/jaderadej. At this point we both send our coins to the address he generated. One tx on testnet and the other on mainnet. As soon as u/jaderadej receives the coins from both of us, he does the swap (minus his “fee”). If I send coins but you dont, then he sends them back to me. If you send coins but I dont, then he sends them back to you.
Now, this works fine as long as we both trust u/jaderadej, and we do, but what if the only person willing to do it is u/pineconecandle. Well, I dont trust u/pineconecandle ;), so why would I do this deal? I wouldn’t. Hence, we need to do it without a third party. And this is possible in Bitcoin.
The first thing you need to understand is how OP_IF works. Basically OP_IF allows you to create a conditional branch of your PubKey Script. The second thing you need to udnerstand is how OP_CLTV works: OP_CLTV stands for Check Lock-Time Verify. It is an OP_Code that accepts an integer as input, which is either interpreted as a unix timestamp or as a block number (there is a convention on when the integer is interpreted as which, you can google it if you care). So now we can create a PubKey Script on a UTXO that has one PubKeyScript branch OP_IF OP_CLTV {Script1} OP_ELSE {Script2}
Ok, so enough with the preliminaries. On to the actual protocol.
I have testnet coins and you want to buy them. So what you do is you generate a random byte string (some random sequence of bits with enough entropy to ensure I cant brute force it before the lock-time we agree upon is up. If you use a cryptographically strong random number generator that will be fine. You generate this random number and hash it, i.e. OP_SHA256 or OP_RIPEMD160, whichever of the two is fine. Usually you would SHA.
I generate an address and provide you with the hash of my public key.
You then also generate a new address and send both the hash and the new hash of the public key to me. You now spend you 0.01 BTC to an output with a PubKey Script like the one above where Script 1 is just a normal P2PKH for your new address and Script 2 is a simple pre-image check combined with a P2PKH for my address, i.e. first hash the first element in the SigScript, compare that it matches the commitment value for the hash and finally check the standard P2PKH Script, i.e. soemthing like
Now, eventually I will see this transaction show up on the mainnet blockchain. Since you are the one looking to buy from me, you pony up the cash. Now, if I change my mind and walk away your coins are not gone. Once the lock-time is up, you can just use you knowledge of the private key to your address to create a SigScript that satisfies Script 1 above. So far no trust needed... you will NOT lose your coins.
Ok, but I want to sell my testnet coins, so I decide to Pony up the testnet coins. I spend them to an output with the same PubKeyScript, only that I reverse the roles of our public key hashes AND more importantly, I cut the lock-time in half. Since you have the hash, I want to make sure I get my coins back before you can take your BTC back, otherwise you could take both.
So now I spend to that and you see it show up on the testnet blockchain. If you decide to walk away, thats fine. I can just get my testnet coins back in half the time you can. Again, no trust needed. Why? Well, even though you know the secret random number, since you dont control the private key associated to my address, you wont be able to satisfy the pubKey Script to take your BTC back and you cant take my testnet coins without revealing the secret random number in the SigScript of the spending transaction. Since all SigScripts are public information, you cant spend my testnet coins if you want to keep the random number secret.
Let’s assume we went through all this hassle to actually do the deal. So, now you spend the testnet coins to a new address that you control (P2PKH) by revealing the random number and providing a SigScript for the address you control in the OP_ELSE branch of the PubKeyScript.
As soon as you do that, I see the random number, and I can now spend your 0.01 BTC to an address I control using the Secret Random Number You revealed to me, along with the SigScript for the P2PKH of the address I control.
And voila. We just exchanges testnet BTC for mainnet BTC in a trustless fashion with no trusted third party using some pretty simple Cryptographic primitives. Done deal.
Now, notice a few things:
  1. You need to wait a bunch of confs before this can be done, because you want to avoid double spending of your counterparty (whom you do not trust)
  2. Tetsnet is kinda a stupid example, because its pretty easy to reorg the chain. I just didn’t wanna mention another coin.
  3. In Lightning this can be done instantly. No need to wait for confs and no need to wait too long for lock-times to expire. Basically it is achieved by routing the payment to yourself on the Lightning Network. You can also combine on-chain swaps with off-chain swaps. Pretty cool stuff. This is basically how decentralized exchanges would work on Lightning.
Ok, done. Hope you like it!
submitted by censorship_notifier to noncensored_bitcoin [link] [comments]

The ultimate back-up plan: Your private key, stored in the block chain, encrypted

[edit: It is the ultimate back-up, but it doesn't mean it is the safest. I'm too tired to figure that out. I'm just explaining how to store a private key in the block chain, in case it is useful or can be made useful.]
I had that idea if someone is interested, though I guess people won't like it. It's a bit wild. We encrypt the key and put it in the block chain with a trick.
I'm not saying everyone should do this, but it could be useful to know it can be done.
If you trust encryption and your password more than back-ups or a third-party, then it could be nice. I'm no encryption expert but it should be strong enough.
"Instead of taking 1.3 quadrillion years, our magical cracking supercomputer would only need 328 trillion years."
If it's flawed or gets cracked after a billion years, I decline all responsibility. But you can be sneaky about it. I propose a sneaky trick at the end. It's a bit rough on the edges and crazy but I'll put it out there. If people like it, there are always ways to streamline.
Anyway, you can't memorize the key as you can memorize a password. It's true you can put it on paper; then lose the paper. You can encrypt it and keep it on hard drive, then lose the hard drive. Or on a service, and lose the service. The block chain though, is going to stay around as long as you need the key. So I suggest this whole alternative.
You can still put the information on paper if you want. But now, just your memory is enough. Just the password.
The drawback is the infinitesimal odd of someone finding out and spending a lot of years and resources on brute-forcing. I'm not sure what would be the odds of success. Just make it so decades of computing resource cost more than what's inside.
Now I'll explain how to do it from A to Z, for the few interested.
Plan: 0) Vanity 1) Get the key 2) Encrypt the key 3) Put the key in the block chain 4) Retrieval 5) Conclusion
0) Optional: Vanity I recommend a vanity address (choosing the first part of the address). So if worst comes to worst, you find it from memory in the block chain. And also, it's kinda neato. How-to: first, download VanityGen, direct/wiki. Extract it, then Open a console window at the location with shift-right click in the folder, if you have vista/7/8. Then type "vanitygen 1something" in it. It has to start with 1. If it's too long it'll take a lot of time. Ctrl-C to cancel if it's too long. Faster with GPU: oclvanitygen -D 0:0 1something (maybe broken atm) When you have the key, type "importprivkey mykey" in Help->Debug->Console of bitcoin-qt, to add it. Result of this optional step: A beautiful address which can be retrieved from memory if needed (after it has been seen in the block chain with a transaction)
1) Get the key - Download open source Pywallet: direct/profile - Extract somewhere. Shift-right click in the folder and "open a console window" - In the console, type: pywallet --dumpwallet dump.txt If your wallet is encrypted, then add --passphrase=PASSPHRASE Now you find the key in dump.txt. (note: it reads the wallet at C:\Users\x\Bitcoin) Result of this step: the private key; it looks like 51 characters starting with the number 5. (To delete dump.txt, you can use a software so it can't be recovered from HDD, like Recuva it seems)
2) Encrypt the key - Choose an algorithm. Personally, I pick AES-256. - Download a trustworthy program to encrypt text with the algorithm. Here are two with GUI I found. It's open source but I didn't check it, so it's not 100% safe: They're both jar files. Maybe you can click them. Personally I have to go in the console; I'm so tired of that coffee cup. "C:\Program Files (x86)\Java\jre7\bin\java.exe" -jar ImmediateCrypt.jar. It gave me an error though. Not the other. Maybe someone can suggest better. - Choose a good password. It's all about the password (and the software). AES is weak with weak password. And crazy strong with a good password. This is not like websites with protection against brute-force. People can brute-force fully if they find out. I like psycho-pass method which is about a pattern on the keyboard instead of semantics. Side Info: Or a passphrase if you want. Here is a nice table with password entropy: Below 64 bits of entropy, it's too unsafe, it's too weak. We need 128 bits or above, as far as I know. That is 25 random alphanumeric. If you're feeling paranoid, 256 bits. You can check entropy of password roughly here: Remember it is not like websites. There is no "Forgot password?" button. Memorize it permanently; and maybe write it down in your favorite book just in case, I don't know. Result of this step: the encrypted key. It doesn't matter what it looks like as long as it takes you back to the key when you click "Decrypt". (on a different software, preferably)
3) Put the key in the block chain It works by sending some minimum amount to fake addresses, with data encoded in the addresses. Can't try this part because I don't have bitcoins. :[ Only a wallet! If some liked the guide particularly: 1thxd4KJLhBMcfCYaVKYMA8Atv3Dfx9hb :3 I'll follow the method of this great article: (the blog is remarkable!) - We're supposed to split the encrypted key in chunks of 20 characters. Then convert from ASCII to hex. Last chunk we fill with extra zeros. I wrote a little javascript to do it all automatically! If you don't like it, find a software, or do it manually. Not tested much but seems to work for my test. I'll say how to know if it worked. Copy that: encrypted='';har=(encrypted.split ('').map(function(c){return c.charCodeAt(0).toString(16); }));ek="";har.forEach(function(c){ek+=c;});while(ek.length%40!=0)ek+='0';iEK=0;ek2='';while(ek.length>0){ek2+=ek.substr(iEK,iEK+40) + "\n";if(ek.length>=40)ek=ek.substr(40,ek.length-40);else ek='';};ek2;
Check eventual comments to know if it's a hack/broken mess.
I don't do much Javascript, or much anything. Paste the whole thing in the javascript console. To open the console: Chrome, Ctrl-Shift-J. Firefox, Ctrl-Shift-K. IE9, F12. Put your encrypted key between the '' right at the beginning, then enter.
This should display rows of 40-characters chunks of the encrypted key in hex format (numbers, and a to f). I have 6 chunks but it depends on encryption. It should give twice as much characters as the input except for last zeros, and follow this conversion table from Char to Hx column. If it doesn't, call the police. Or use some Ascii to Hex service.
Now we take these chunks one by one and use to convert to BTC addresses.
Send spare money to each one (the strict minimum is suspect and it'd get found easily) in the right order (wait for 1 or 2 confirmations each time to be sure).
And we're done! The information is safe and cozy, in the block chain. Not safe from brute-forcing, but safe from ourselves; and that's safer, isn't it?
4) Retrieval
Alright, how do we go back from the addresses to the encrypted key? I can't try it myself, but apparently, according to the article: 1) Get the transaction ID on, by going to the wallet's profile 2) Go to 3) There will be something like that: "out":[ { "value":"25.08603421", "scriptPubKey":"OP_DUP OP_HASH160 27a1f12771de5cc3b73941664b2537c15316be43 OP_EQUALVERIFY OP_CHECKSIG" } ]
And you need to translate the "27a1f12771de5cc3b73941664b2537c15316be43" part from hex to Unicode. The result should be the chunk of encrypted key, written in hex again. You put all the parts together in order, remove extra zeros. Then use a program to go back from hex bytes to ASCII. Maybe someone can do it or I'll put the javascript one of these days if people are interested; I don't think they'll be. Usually I'm serious and extensive but you can't imagine how tired I am these days, of everything. Anyway, you put that ASCII in the AES program with your password, you click Decrypt.
Then you have your private key.
If you do this, don't lose other back-ups until you have successfully retrieved the key, to know it works.
5) Conclusion I understand that there's a small chance that someone figures the transactions are data, reassembles the parts, has massive luck and breaks the crazy strong encryption with supercomputers and botnets in less than decades, or aliens hack your bitcoins with quantum computers, ect... But I don't know, that seems very unlikely to me; more unlikely than losing personal back-ups or third-parties being untrustworthy.
More importantly, it gives peace of mind of not having to manage back-up stuff. You can format your hard drive and burn your house down if you want without worrying about losing stuff; well, except the house. And maybe the wife. Or you go to prison 20 years, and it'll still be there. If some of you want to go to prison. I know of one.
Here's a complicated idea for the extra-extra-paranoid: You send just one letter by one letter of the encrypted key, into dozens of fake addresses, to which you send bitcoins you got from an exchange and not from the main wallet, and only you know the correct addresses/order with the data, because of a pattern in the other letters. For example, the 2nd letter of the 1st data part is the 1st letter of your password when it's hashed. The 3rd letter of the 2nd data part is the 2nd letter of your hashed password. Ect... And it's not true for the other parts. So you know the order, but not someone without the password. It can go like this for many parts, then maybe if you run out of letters you send through a different wallet. All other characters are misleading except the 1st one, or last one, being the key character. And you also send money to other fake wallets which are purely misleading. Even if a flaw in AES was found and it could be broken instantly, an attacker would have to find the correct combination even before the strong encryption brute-forcing, he can't even know if he has the right combination, and that can be a big number of combinations. You can do the math. It's exponential stuff, I think. That's something I just thought of quickly, and I don't know much about any of that. Someone can find better. (Maybe, or maybe not, there's something about the encryption output which makes it so we can find the order back without password, then we'd need some kind of trick to obfuscate the position or nature of key characters but I won't spend any more time on something likely to be wrong/uninteresting).
tl;dr: "It works by sending some minimum amount to fake addresses, with data encoded in the addresses. "
Point is, once we know we can store data in the block chain, there are plenty of ways to make it so we're never locked out from the main address.
Well, if you can remember the password.
I hope this was useful to someone!
submitted by yemethzi to Bitcoin [link] [comments]

Top Three Bitcoin ($BTC) Exchanges! Bitcoin spot exchanges SEE 49.3% DECREASE IN VOLUME  Bitcoin LOSING INVESTORS  I check out NIMIQ HOW TO BUY BITCOINS? THE BEST EXCHANGE & MARKETPLACE. What's the Best Bitcoin Exchange!? ep 13: How is bitcoin

The signature can only be used for transactions containing exactly that specific transaction-hash referenced in the input. And the scriptPubKey is typically the same for all outputs to a same bitcoin address (dup hash160 "bitcoin-address" equalverify checksig) – Bjarne Magnussen Oct 2 '15 at 19:55 scriptPubKey: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG scriptSig: <sig> <pubKey> A Bitcoin address is only a hash, so the sender can't provide a full public key in scriptPubKey. When redeeming coins that have been sent to a Bitcoin address, the recipient provides both the signature and the public key. You’ve thought about it, now it’s time. Create a Wallet. Sign up for the Exchange. Buy Bitcoin in minutes. The algorithm for digital signatures used in Bitcoin is Elliptic Curve Digital Signature Algorithm, or ECDSA, based on the mathematics of elliptical curves for coupling private and public keys, which uses the script functions OP_CHECKSIG, OP_CHECKSIGVERIFY, OP_CHECKMULTISIG, and OP_CHECKMULTISIGVERIFY. $500 Daily wagering contest, 7-day streak bonus, 30% Rakeback for VIP users. Try out Dice and HiLo games. Diversify your gameplay with unique extra options, fully customizable to allow putting your best strategies into work!

[index] [4739] [31240] [1340] [27837] [10261] [24990] [15718] [10297] [2388] [17517]

Top Three Bitcoin ($BTC) Exchanges!

NASDAQ BITCOIN EXCHANGE WALL STREET ABOUT TO OWN MORE BITCOIN THAN SATOSHI Time RUNNING OUT! - Duration: 8:48. Mr_Kristof 5,008 views. 8:48. If you are interested in buying Bitcoins (BTC), but you don't understand anything about how to get started or you are tired of losing time with dozens of websites when you just want one Exchange ... 24/7 Live Bitcoin Algo Trading on Deribit Exchange (DeriBot) Bitcoin Trading Robots 251 watching Live now I Tried Creating A $100,000 Shopify Dropshipping Business In 7 Days *LIVE* - Duration: 40:17. ep 13: How is bitcoin "locked" to an address - OP_CHECKSIG, locking scripts, signatures, UTXO chain Matt Thomas. ... Diffie-Hellman Key Exchange (full version) - Duration: 8:38. What is the best exchange to buy Bitcoin at? This can be a difficult question, especially for people new to Bitcoin. In the video I go over the most popular exchanges, (USA), and give pros and ...

Flag Counter