Transaction Malleability – Bittylicious Blog

As predicted, BS/Core uses the actions of their attack dog as a desperate plea to activate segwit. Not bothering to mention the source or the fact that they cheered it on

submitted by Helvetian616 to btc [link] [comments]


Keep It Simple, Stupid.
Remember and the DAO? Wasn't it a great idea on paper, kids? Some of you put money into it I'm sure. Did it work out in practice? No. They hadn't considered all the angles. I fear the same with the arrogant fucks at Blockstream pushing SegWit.
Keep It Simple, Stupid.
We won't break anything by increasing the block size. Can't say the same about SegWit with any confidence.
submitted by liquorstorevip to btc [link] [comments]

Due to active malleable transaction relayers, it is dangerous to spend unconfirmed change outputs

The reports of wallets and exchanges not processing withdraws could be related to the malleable transaction relayers.
If a user sends a transaction for an amount the reference client generates an output containing the leftover amount from the original inputs, called a 'change' output. The client is programmed to allow spending of this change even when unconfirmed since it was generated by the client itself.
In the presence of a malleable transactions this is not safe though. if a second transaction is done by the user that spends this unconfirmed change and the first transaction is mutated and included in a block then the second transaction is a double spend. It will never be confirmed.
The bitcoin reference client seems to get confused by this. It seems to allow additional spending of the unconfirmed change addresses and forms a chain of double spent transactions. The bitcoin balance as reported by 'getbalance' also becomes unreliable as it computes the balance incorrectly. Eventually the wallet stops working.
I struck this issue today with my wallet and worked around it by modifying bitcoind to not allow using unconfirmed change outputs. This does mean your 'sendable balance' will be different from your normal balance. I worked around this by changing the behavior of "getbalance *" to show the sendable balance. This is the somewhat hacky patch I used to do this.
With that patch it will not spend any output with less than two confirms. And you can get the spendable balance of 2 confirms with "getbalance * 2".
The malicious relayers seem to be mutating many transactions so this may get more important for bitcoin clients to not allow any spending of uncofirmed transactions at all.
submitted by tedrythy to Bitcoin [link] [comments]

A lengthy explanation on why BS really limited the blocksize

I found this explanation in the comments about BS's argument against raising the blocksize which doesn't get much focus here:
In my understanding, allowing Luke to run his node is not the reason, but only an excuse that Blockstream has been using to deny any actual block size limit increase. The actual reason, I guess, is that Greg wants to see his "fee market" working. It all started on Feb/2013. Greg posted to bitcointalk his conclusion that Satoshi's design with unlimited blocks was fatally flawed, because, when the block reward dwindled, miners would undercut each other's transaction fees until they all went bakrupt. But he had a solution: a "layer 2" network that would carry the actual bitcoin payments, with Satoshi's network being only used for large sporadic settlements between elements of that "layer 2".
(At the time, Greg assumed that the layer 2 would consist of another invention of his, "pegged sidechains" -- altcoins that would be backed by bitcoin, with some cryptomagic mechanism to lock the bitcoins in the main blockchain while they were in use by the sidechain. A couple of years later, people concluded that sidechains would not work as a layer 2. Fortunately for him, Poon and Dryja came up with the Lightning Network idea, that could serve as layer 2 instead.)
The layer 1 settlement transactions, being relatively rare and high-valued, supposedly could pay the high fees needed to sustain the miners. Those fees would be imposed by keeping the block sizes limited, so that the layer-1 users woudl have to compete for space by raising their fees. Greg assumed that a "fee market" would develop where users could choose to pay higher fees in exchange of faster confirmation.
Gavin and Mike, who were at the time in control of the Core implementation, dismissed Greg's claims and plans. In fact there were many things wrong with them, technical and economical. Unfortunately, in 2014 Blockstream was created, with 30 M (later 70 M) of venture capital -- which gave Greg the means to hire the key Core developers, push Gavin and Mike out of the way, and make his 2-layer design the official roadmap for the Core project.
Greg never provided any concrete justification, by analysis or simulation, for his claims of eventual hashpower collapse in Satoshi's design or the feasibility of his 2-layer design.
On the other hand, Mike showed, with both means, that Greg's "fee market" would not work. And, indeed, instead of the stable backlog with well-defined fee x delay schedule, that Greg assumed, there is a sequence of huge backlogs separated by periods with no backlog.
During the backlogs, the fees and delays are completely unpredictable, and a large fraction of the transactions are inevitably delayed by days or weeks. During the intemezzos, there is no "fee market' because any transaction that pays the minimum fee (a few cents) gets confirmed in the next block.
That is what Mike predicted, by theory and simulations -- and has been going on since Jan/2016, when the incoming non-spam traffic first hit the 1 MB limit. However, Greg stubbornly insists that it is just a temporary situation, and, as soon as good fee estimators are developed and widely used, the "fee market" will stabilize. He simply ignores all arguments of why fee estimation is a provably unsolvable problem and a stable backlog just cannot exist. He desperately needs his stable "fee market" to appear -- because, if it doesn't, then his entire two-layer redesign collapses.
That, as best as I can understand, is the real reason why Greg -- and hence Blockstream and Core -- cannot absolutely allow the block size limit to be raised. And also why he cannot just raise the minimum fee, which would be a very simple way to reduce frivolous use without the delays and unpredictability of the "fee market". Before the incoming traffic hit the 1 MB limit, it was growing 50-100% per year. Greg already had to accept, grudgingly, the 70% increase that would be a side effect of SegWit. Raising the limit, even to a miser 2 MB, would have delayed his "stable fee market" by another year or two. And, of course, if he allowed a 2 MB increase, others would soon follow.
Hence his insistence that bigger blocks would force the closure of non-mining relays like Luke's, which (he incorrectly claims) are responsible for the security of the network, And he had to convince everybody that hard forks -- needed to increase the limit -- are more dangerous than plutonium contaminated with ebola.
SegWit is another messy imbroglio that resulted from that pile of lies. The "malleability bug" is a flaw of the protocol that lets a third party make cosmetic changes to a transaction ("malleate" it), as it is on its way to the miners, without changing its actual effect.
The malleability bug (MLB) does not bother anyone at present, actually. Its only serious consequence is that it may break chains of unconfirmed transactions, Say, Alice issues T1 to pay Bob and then immediately issues T2 that spends the return change of T1 to pay Carol. If a hacker (or Bob, or Alice) then malleates T1 to T1m, and gets T1m confirmed instead of T1, then T2 will fail.
However, Alice should not be doing those chained unconfirmed transactions anyway, because T1 could fail to be confirmed for several other reasons -- especially if there is a backlog.
On the other hand, the LN depends on chains of the so-called bidirectional payment channels, and these essentially depend on chained unconfirmed transactions. Thus, given the (false but politically necessary) claim that the LN is ready to be deployed, fixing the MB became a urgent goal for Blockstream.
There is a simple and straightforward fix for the MLB, that would require only a few changes to Core and other blockchain software. That fix would require a simple hard fork, that (like raising the limit) would be a non-event if programmed well in advance of its activation.
But Greg could not allow hard forks, for the above reason. If he allowed a hard fork to fix the MLB, he would lose his best excuse for not raising the limit. Fortunately for him, Pieter Wuille and Luke found a convoluted hack -- SegWit -- that would fix the MLB without any hated hard fork.
Hence Blockstream's desperation to get SegWit deployed and activated. If SegWit passes, the big-blockers will lose a strong argument to do hard forks. If it fails to pass, it would be impossible to stop a hard fork with a real limit increase.
On the other hand, SegWit needed to offer a discount in the fee charged for the signatures ("witnesses"). The purpose of that discount seems to be to convince clients to adopt SegWit (since, being a soft fork, clients are not strictly required to use it). Or maybe the discount was motivated by another of Greg's inventions, Confidential Transactions (CT) -- a mixing service that is supposed to be safer and more opaque than the usual mixers. It seems that CT uses larger signatures, so it would especially benefit from the SegWit discount.
Anyway, because of that discount and of the heuristic that the Core miner uses to fill blocks, it was also necessary to increase the effective block size, by counting signatures as 1/4 of their actual size when checking the 1 MB limit. Given today's typical usage, that change means that about 1.7 MB of transactions will fit in a "1 MB" block. If it wasn't for the above political/technical reasons, I bet that Greg woudl have firmly opposed that 70% increase as well.
If SegWit is an engineering aberration, SegWit2X is much worse. Since it includes an increase in the limit from 1 MB to 2 MB, it will be a hard fork. But if it is going to be a hard fork, there is no justification to use SegWit to fix the MLB: that bug could be fixed by the much simpler method mentioned above.
And, anyway, there is no urgency to fix the MLB -- since the LN has not reached the vaporware stage yet, and has yet to be shown to work at all.
I'd like to thank u/iwannabeacypherpunk for pointing this out to me.
submitted by unitedstatian to btc [link] [comments]

I quit btc.

TL&DR Basically rant why I don’t want to face bitcoin core supporters constant lies and I don’t want to have anything to do with bitcoin core (btc) anymore.
Bitcoin was always about sending safely digital money to anybody, anywhere and without need of central authority. It was very clearly stated in first discussions and first promoting materials, that whole idea is for it to work instantly with no fees, or very little fees and it is for everybody equally and anonymously.
Nobody was ever suggesting that bitcoin is finished product. Probably it is fair to say everybody were expecting some kind of problems and different and unforeseen circumstances that could potentially kill the project any minute and instantly. Many of users could also see potential new use cases and phenomenal possibilities for the future. Bitcoin got quickly recognised as very risky but very promising technology that could change the world. Things like that don’t happened every day.
Evolution of bitcoin was inevitable. Every aspect of bitcoin needed protection and improvement to face problems.
Oh boy, but how I’m surprised what way it all went.
Maximum blocksize was introduce by bitcoin creator as a temporary measure to mitigate problems bitcoin was vulnerable at the time. It was always suppose to be increased when needed and Bitcoin creator (Satoshi Nakamoto) even said how to do it effortlessly. That max block size was trivial temporary fix that not many at the time realised how big obstacle for bitcoin it will become. Unfortunately for all of us, Satoshi left the project, before sorting it out.
Instant transactions were removed when “replace by fee” feature and increasing transaction waiting time in mempool from, I think 3 days to 14 days, were introduced. It was done to allegedly make it easier to estimate correct fee needed to pay to get to next block. In effect though, it enabled race to the top of the fees where in order to keep up with increasing volume, it was better to increase fee above everybody else or face staying in limbo of unconfirmed transaction for two weeks or more in case some party chooses to rebroadcast transaction. What is more terrifying, transactions couldn’t be safely used as instant anymore, as a sender could potentially double spend transaction with sending funds to different than original address with higher fee and more chance to not get rejected. Instant transaction was basically killed. Now we all had to wait for confirmations, preferably 6 of them. Originally, that was only advised as extra safety measure for bigger purchases, but now thanks to rbf, it is a must. Plus fees were encouraged to go up.
Foundations for high fees were set by rbf and 1mb block size. When volume came with increasing adoption and interest from new users, fees skyrocketed to above 1000sat/byte. You could send with lower fees and get lucky, but basically fees were extremely high. Also, not every transaction is simple. This 1000sat/byte could easily result in fee on 100gbp for transaction if you were using many unspent outputs.
That killed adoption. Period. You can’t use bitcoin to send money if you have to pay transaction bigger than often value of transaction itself. Low fee or no fee aspect was killed and even vanished for a while from site.
Important part is, that all of that above could have been justified. As I mentioned before, bitcoin is not finished and it is vulnerable so any changes should be tested, not rushed. I can understand that. What is more, I can not demand from bitcoin developers changes. I can propose changes myself and even show how to do it though.
But here is the tricky part. Bitcoin core developers killed all progress by censoring every discussion that was not in line with central party rhetoric. You want to talk about big blocks? Ban. You want to ask about why not? Ban. But, but… Ban. So changes can not be proposed anymore and discussed. It was possible to get ban even when taking part in discussion elsewhere or agree to something core didn’t approve and “obviously” being not in line.
Well done guys, you just created central authority that stand against everything that bitcoin was for.
How big fees were justified?
By pushing blame on users. It must be stupid to use bitcoin they said. When you using it you are taking precious resources. You are bad for bitcoin. Bitcoin is not money, it is store of value!!!
Just buy and hold. Sorry. Just buy and “hodl”. Be stupid meme reader. Than tell others to buy and hold. Create perfect ponzi. This is what bitcoin core is now being used mostly for.
Solutions proposed and introduced.
Segwit or Segregated Witness. (didn’t help)
Reorganisation of transaction record that changes the way transaction size is being counted and also fixes malleability issue. At the time of introduction it was being compared to approximately equal to increase to 1.7 mb block size. Now opinions and calculations are vary. Some give it more, but most are very confusing anyway. As misinformation is very common in bitcoin world, I leave it for everybody to check it themselves.
Segwit was mostly needed to introduce Lightning Network that required transaction malleability to be fixed. In normal bitcoin use, it wasn’t really big problem, but lightning apparently had to have it sorted this way.
Lightning network
Fascinating concept really I must admit. It is different layer working on top of bitcoin block chain. Instead of sending every transaction on chain, users were encouraged to use this so called settlement layer, where only final balancing is written on chain. In theory, when network will be big enough and everybody will connect, closing final balances will never be required or for very long time plus when something goes wrong. Lightning network is in even bigger beta than I thought and I don’t think I can say more about its technical side, but already I think it might be very interesting someday. It should not stop on chain scaling though.
My problem with Lightning network is more on idealogical level. It to much looks like trying to replicate existing banking system (I might be totally wrong on this) and there was LIE spread before introducing LN that everybody needs to run full node. It is a lie. Obvious lie.
First of all, the definition of full node has been changed. Originally full node was node that was doing all functions of node and that includes mining. Mining is now highly centralised and it has very big entry price, so normal user rather can’t run full node efficiently.
Definition has changed to call non mining nodes a full node. That implies they are important to bitcoin network. They are not. They are important for Lightning network though, as user has to be connected to it all the time via they're own node.
Not only Lightning Network is build on bitcoin chain but also on the lie and misinformation. That is very bad. Any discussion to put things straight as they are result in ban in every communication channel controlled by central authority of core devs.
Every day I come to reddit or any other social media, I see plenty of lies, usually from people that do not lie, and I am sick of it. Bitcoin is evil, bitcoin is broken, bitcoin is taken over by malicious group, that luckily forked away in August last year and is marked as btc.
Bch chain restored the original value of Bitcoin. Central authority is gone. If it happens again, we will fork away again. It is low fee or no fee system for everybody.
It is fascinating again. There is new development. Look on memo and blockpress. If you can’t see implications of this, I don’t know what to say.
Now is the time people have to choose though. Bitcoin cash has low volume. It is possible people don’t want uncensored money, social network, or network in general. Maybe they need Lambo dream and ponzi scheme? Maybe. I don’t know. But I’m off from btc and I am not coming back.
submitted by MarchewkaCzerwona to btc [link] [comments]

How SegWit Decapitated Bitcoin, and how Bitcoin Cash resurrected Bitcoin before it was too late.

Segregated Witness (SegWit) effectively breaks the existing transaction structure of Bitcoin in order to create 2 transaction IDs instead of 1, and in order to run "future signature scripts" - scripts that aren't defined in the original Bitcoin protocol or whitepaper.
Despite the issue with signature hashes being slightly different potentially being a feature of Bitcoin to reduce second-layer dependency or crutches, this inability to be malleable was targeted as the prime problem with Bitcoin, and that's what lead to Segregated Witness AKA the Decapitation of Bitcoin as well as hardcore Bitcoin enthusiasts and developers who were paying attention to duplicate (fork) the open-source software before it was modified irreversibly by activating SegWit.
There is no need for 2 IDs but this was done in the name of expanding Bitcoin via "second-layer solutions" because, "Bitcoin doesn't work", "It can't scale", and "It has malleability issues" among other supposed issues - All of which are demonstrably false (every day) with Bitcoin Cash. Meanwhile the old chain IDs live on in a ghostly form but they have been rendered utterly meaningless according to the new SegWit scripts.
According to the specification of SegWit (and SegWit users here often outright deny) "signature data [now] becomes optional". Signature data, the data that is required and described by Bitcoin as a fundamental building block as part of the process of verifying transaction data as it is propagated to the network.
Bitcoin uses something called a Elliptical Curve Digital Signature Algorithm: - with SegWit the signature data is separated out from the transactions: "This BIP defines a new structure called a "witness" that is committed to blocks separately from the transaction merkle tree." See for yourself: with SegWit, "signature data is no longer part of the transaction hash" source.
Segwit is "removing this data from the transaction structure committed to the transaction merkle tree" source.
Making transaction structure more modifiable/malleable was presented as making it easier to expand with future software (such as lightning and schnorr, etc) by Blockstream et al. To make it modifiable transaction IDs are tied together, it does this by instead creating TWO transaction IDs and tying them together with a Segregated Witness script..."A new data structure, witness, is defined. Each transaction will have 2 IDs. " source and the witness ID references the original like a mirror copy.
In its own words: "how the transaction was signed are no longer relevant to transaction identification". This effectively makes a ghost chain that continues on as if it is still alive and SegWit takes over. It appears as though that Bitcoin chain is alive but it is, in fact, long dead.
"It allows creation of unconfirmed transaction dependency chains" [... in other words, chains that aren't really Bitcoin ...] "an important feature for offchain protocols such as the Lightning Network". It forces Bitcoin to rely on second-layer solutions, and even calls them dependency chains.
"Since a version byte is pushed before a witness program, and programs with unknown versions are always considered as anyone-can-spend script, it is possible to introduce any new script system with a soft fork." - so essentially the old chain would be able to become effectively deprecated ... was this really a good thing? was there really a problem to be fixed? did we want any new script system like SegWit to define the new blockchain from now on?
Micro-transactions and near instant transactions with extremely low fees are happening daily already with Bitcoin Cash with zero issues and Bitcoin Cash now has 32MB blocks (Instead of 1MB/2MB) without an unnecessary change to transaction data or signature scripts making it fully scale-able. Bitcoin Cash is Bitcoin. Bitcoin Cash continues the legacy of Bitcoin on a daily basis, while SegWit has effectively decapitated the Bitcoin chain moving everyone over to SegWit. Segregated Witness was a takeover of the old chain signature scripts (or rules) with the new ones that don't actually disable the old methods and system but also don't allow any Devs to go back and work with the old scripts anymore, they're considered completely irrelevant now. The document referenced in this post describes the Bitcoin protocol as "current protocol" and then explains the new SegWit "consensus layer", it is the "official Bitcoin Improvement Proposal" (BIP) document that describes an already complete change to the transaction structure that changes Bitcoin forever.
This effectively kills Bitcoin as you know it. Bitcoin has been decapitated. From now on it is SegWit and second-layer or nothing. It forces Bitcoin Devs to work with the new Segregated Witness IDs from now on, or be forgotten, and of course Bitcoin Cash Devs were having none of that. Thankfully they duplicated the entire project before SegWit was activated and continued the Bitcoin legacy through Bitcoin Cash without the needless extra transaction ID ties.
Bitcoin SegWit Devs are now forced to use the new Segregated Witness protocol and any future scripts must run according to the Segregated Witness procotol that has the wtxid and 2 transaction ID format. Not long from now the original txid will likely be deprecated and the ashes scattered into the wind and everything will move over to just using wtxid... and Lightning, Bitcoin SegWit Devs will probably still be called Bitcoin Devs but in reality they are Lightning Devs along with contributing to all the dangers of using second-layer solutions moving forward. This is fairly obvious because, those "old" signature scripts are still being used today with no issues by Bitcoin Cash just fine. Bitcoin Cash has resurrected Bitcoin and the same Bitcoin developer community that was there in the start is now being revived from the ashes in all the hundreds of ecosystem developments over the last few months, by Bitcoin Cash.
submitted by crockscream to btc [link] [comments]

Long live decentralized bitcoin(!) A reading list

Newbs might not know this, but bitcoin recently came out of an intense internal drama. Between July 2015 and August 2017 bitcoin was attacked by external forces who were hoping to destroy the very properties that made bitcoin valuable in the first place. This culminated in the creation of segwit and the UASF (user activated soft fork) movement. The UASF was successful, segwit was added to bitcoin and with that the anti-decentralization side left bitcoin altogether and created their own altcoin called bcash. Bitcoin's price was $2500, soon after segwit was activated the price doubled to $5000 and continued rising until a top of $20000 before correcting to where we are today.
During this drama, I took time away from writing open source code to help educate and argue on reddit, twitter and other social media. I came up with a reading list for quickly copypasting things. It may be interesting today for newbs or anyone who wants a history lesson on what exactly happened during those two years when bitcoin's very existence as a decentralized low-trust currency was questioned. Now the fight has essentially been won, I try not to comment on reddit that much anymore. There's nothing left to do except wait for Lightning and similar tech to become mature (or better yet, help code it and test it)
In this thread you can learn about block sizes, latency, decentralization, segwit, ASICBOOST, lightning network and all the other issues that were debated endlessly for over two years. So when someone tries to get you to invest in bcash, remind them of the time they supported Bitcoin Unlimited.
For more threads like this see UASF

Summary / The fundamental tradeoff

A trip to the moon requires a rocket with multiple stages by gmaxwell (must read)
Bram Cohen, creator of bittorrent, argues against a hard fork to a larger block size
gmaxwell's summary of the debate
Core devs please explain your vision (see luke's post which also argues that blocks are already too big)
Mod of btc speaking against a hard fork
It's becoming clear to me that a lot of people don't understand how fragile bitcoin is
Blockchain space must be costly, it can never be free
Charlie Lee with a nice analogy about the fundamental tradeoff
gmaxwell on the tradeoffs
jratcliff on the layering

Scaling on-chain will destroy bitcoin's decentralization

Peter Todd: How a floating blocksize limit inevitably leads towards centralization [Feb 2013] mailing list with discussion on reddit in Aug 2015
Nick Szabo's blog post on what makes bitcoin so special
There is academic research showing that even small (2MB) increases to the blocksize results in drastic node dropoff counts due to the non-linear increase of RAM needed.
Reddit summary of above link. In this table, you can see it estimates a 40% drop immediately in node count with a 2MB upgrade and a 50% over 6 months. At 4mb, it becomes 75% immediately and 80% over 6 months. At 8, it becomes 90% and 95%.
Larger block sizes make centralization pressures worse (mathematical)
Talk at scalingbitcoin montreal, initial blockchain synchronization puts serious constraints on any increase in the block size with transcript
Bitcoin's P2P Network: The Soft Underbelly of Bitcoin someone's notes: reddit discussion
In adversarial environments blockchains dont scale
Why miners will not voluntarily individually produce smaller blocks
Hal Finney: bitcoin's blockchain can only be a settlement layer (mostly interesting because it's hal finney and its in 2010)
petertodd's 2013 video explaining this
luke-jr's summary
Another jratcliff thread

Full blocks are not a disaster

Blocks must be always full, there must always be a backlog
Same as above, the mining gap means there must always be a backlog talk: transcript:
Backlogs arent that bad
Examples where scarce block space causes people to use precious resources more efficiently
Full blocks are fine
High miner fees imply a sustainable future for bitcoin
gmaxwell on why full blocks are good
The whole idea of the mempool being "filled" is wrong headed. The mempool doesn't "clog" or get stuck, or anything like that.


What is segwit

luke-jr's longer summary
Charlie Shrem's on upgrading to segwit
Original segwit talk at scalingbitcoin hong kong + transcript
Segwit is not too complex
Segwit does not make it possible for miners to steal coins, contrary to what some people say
Segwit is required for a useful lightning network It's now known that without a malleability fix useful indefinite channels are not really possible.
Clearing up SegWit Lies and Myths:
Segwit is bigger blocks
Typical usage results in segwit allowing capacity equivalent to 2mb blocks

Why is segwit being blocked

Jihan Wu (head of largest bitcoin mining group) is blocking segwit because of perceived loss of income
Witness discount creates aligned incentives
or because he wants his mining enterprise to have control over bitcoin

Segwit is being blocked because it breaks ASICBOOST, a patented optimization used by bitmain ASIC manufacturer

Details and discovery by gmaxwell
Reddit thread with discussion
Simplified explaination by jonny1000
Bitmain admits their chips have asicboost but they say they never used it on the network (haha a likely story)
Worth $100m per year to them (also in gmaxwell's original email)
Other calculations show less
This also blocks all these other cool updates, not just segwit
Summary of bad consequences of asicboost
Luke's summary of the entire situation
Prices goes up because now segwit looks more likely
Asicboost discovery made the price rise
A pool was caught red handed doing asicboost, by this time it seemed fairly certain that segwit would get activated so it didnt produce as much interest as earlier and and
This btc user is outraged at the entire forum because they support Bitmain and ASICBOOST
Antbleed, turns out Bitmain can shut down all its ASICs by remote control:

What if segwit never activates

What if segwit never activates? with and


bitcoinmagazine's series on what lightning is and how it works
The Lightning Network ELIDHDICACS (Explain Like I Don’t Have Degrees in Cryptography and Computer Science)
Ligtning will increases fees for miners, not lower them
Cost-benefit analysis of lightning from the point of view of miners
Routing blog post by rusty and reddit comments
Lightning protocol rfc
Blog post with screenshots of ln being used on testnet video
Video of sending and receiving ln on testnet
Lightning tradeoffs
Beer sold for testnet lightning and
Lightning will result in far fewer coins being stored on third parties because it supports instant transactions
jgarzik argues strongly against LN, he owns a coin tracking startup
luke's great debunking / answer of some misinformation questions
Lightning centralization doesnt happen
roasbeef on hubs and charging fees and

Immutability / Being a swiss bank in your pocket / Why doing a hard fork (especially without consensus) is damaging

A downside of hard forks is damaging bitcoin's immutability
Interesting analysis of miners incentives and how failure is possible, don't trust the miners for long term
waxwing on the meaning of cash and settlement
maaku on the cash question
Digital gold funamentalists gain nothing from supporting a hard fork to larger block sizes
Those asking for a compromise don't understand the underlying political forces
Nobody wants a contentious hard fork actually, anti-core people got emotionally manipulated
The hard work of the core developers has kept bitcoin scalable
Recent PRs to improve bitcoin scaleability ignored by the debate
gmaxwell against hard forks since 2013
maaku: hard forks are really bad

Some metrics on what the market thinks of decentralization and hostile hard forks

The price history shows that the exchange rate drops every time a hard fork threatens:
and this example from 2017 btc users lose money
price supporting theymos' moderation
old version
older version
about 50% of nodes updated to the soft fork node quite quickly

Bitcoin Unlimited / Emergent Consensus is badly designed, changes the game theory of bitcoin

Bitcoin Unlimited was a proposed hard fork client, it was made with the intention to stop segwit from activating
A Future Led by Bitcoin Unlimited is a Centralized Future
Flexible transactions are bugged
Bugged BU software mines an invalid block, wasting 13 bitcoins or $12k employees are moderators of btc
miners don't control stuff like the block size
even gavin agreed that economic majority controls things
fork clients are trying to steal bitcoin's brand and network effect, theyre no different from altcoins
BU being active makes it easier to reverse payments, increases wasted work making the network less secure and giving an advantage to bigger miners
bitcoin unlimited takes power away from users and gives it to miners
bitcoin unlimited's accepted depth
BU's lying propaganda poster

BU is bugged, poorly-reviewed and crashes

bitcoin unlimited allegedly funded by kraken stolen coins
Other funding stuff
A serious bug in BU
A summary of what's wrong with BU:

Bitcoin Unlimited Remote Exploit Crash 14/3/2017
BU devs calling it as disaster also btc deleted a thread about the exploit
Summary of incident
More than 20 exchanges will list BTU as an altcoin
Again a few days later

User Activated Soft Fork (UASF)

site for it, including list of businesses supporting it
luke's view
threat of UASF makes the miner fall into line in litecoin
UASF delivers the goods for vertcoin
UASF coin is more valuable
All the links together in one place
p2sh was a uasf
jgarzik annoyed at the strict timeline that segwit2x has to follow because of bip148
Committed intolerant minority
alp on the game theory of the intolerant minority
The risk of UASF is less than the cost of doing nothing
uasf delivered the goods for bitcoin, it forced antpool and others to signal (May 2016) "When asked specifically whether Antpool would run SegWit code without a hard fork increase in the block size also included in a release of Bitcoin Core, Wu responded: “No. It is acceptable that the hard fork code is not activated, but it needs to be included in a ‘release’ of Bitcoin Core. I have made it clear about the definition of ‘release,’ which is not ‘public.’”"
Screenshot of peter rizun capitulating

Fighting off 2x HF
b2x is most of all about firing core

Misinformation / sockpuppets
three year old account, only started posting today
Why we should not hard fork after the UASF worked:


Good article that covers virtually all the important history
Interesting post with some history pre-2015
The core scalabality roadmap + my summary from 3/2017 my summary
History from summer 2015
Brief reminders of the ETC situation
Longer writeup of ethereum's TheDAO bailout fraud
Point that the bigblocker side is only blocking segwit as a hostage
jonny1000's recall of the history of bitcoin

Misc (mostly memes)

libbitcoin's Understanding Bitcoin series (another must read, most of it)
github commit where satoshi added the block size limit
hard fork proposals from some core devs
blockstream hasnt taken over the entire bitcoin core project
blockstream is one of the good guys
Forkers, we're not raising a single byte! Song lyrics by belcher
Some stuff here along with that cool photoshopped poster
Nice graphic
gmaxwell saying how he is probably responsible for the most privacy tech in bitcoin, while mike hearn screwed up privacy
Fairly cool propaganda poster
btc tankman
asicboost discovery meme
gavin wanted to kill the bitcoin chain
stuff that btc believes
after segwit2x NYA got agreed all the fee pressure disappeared, laurenmt found they were artificial spam
theymos saying why victory isnt inevitable
with ignorant enemies like these its no wonder we won ""So, once segwit2x activates, from that moment on it will require a coordinated fork to avoid the up coming "baked in" HF. ""
a positive effect of bcash, it made blockchain utxo spammers move away from bitcoin
summary of craig wright, jihan wu and roger ver's positions
Why is bitcoin so strong against attack?!?! (because we're motivated and awesome)
what happened to #oldjeffgarzik
big blockers fully deserve to lose every last bitcoin they ever had and more
gavinandresen brainstorming how to kill bitcoin with a 51% in a nasty way
Roger Ver as bitcoin Judas
A bunch of tweets and memes celebrating UASF | | | | | | | | | | | |
submitted by belcher_ to Bitcoin [link] [comments]

General BTC questions

I used local btc and did a f2f deal today for the first time today, which I will say was super duper nerve wracking and felt really sketchy-can anyone speak to that?
But what I am really wondering was initially it had showed that I had received two payments but one was not confirmed and the 2nd one had multiple confirmations in my eWallet. What does that mean?
Nearly had a heart attack when I thought I had made 200% my purchase :-) Thanks
submitted by berner403 to BitcoinBeginners [link] [comments]

Stop ragging on mt Gox. The actually deserve credit for being the first to bring the problem to the forefront. four others now also are temporarily stopping withdrawals while they implement the same software fixin 24-72hrs. We'll all be better for it.

submitted by anononaut to Bitcoin [link] [comments]

Unmasking the Blockstream Business Plan


Sidechains are secondary two-way "pegged" blockchains that are interoperable with the bitcoin blockchain, which allow assets to be transferred between chains and not be confined to the bitcoin blockchain policies.
Lightning Network (LN)
LN is a "caching layer" for Bitcoin, creating off-chain payment channels using a new sighash opcode which allows the Bitcoin network to scale transactions to billions of transactions which can be processed nearly instantly.


In order for sidechains to work and for Blockstream to be successful, Blockstream needs to artificially keep the Bitcoin blockchain at a low capacity (max_block_size = 1MB), so that they can push users off of the Bitcoin blockchain onto a sidechain where assets (transactions, contracts, etc.) can happen. By doing this, they are forcibly (see "protocol wars") able to create an environment where their solution is more desirable, creating a second premium tiered layer. The Bitcoin blockchain will end up being for "regular" users and sidechains will be for premium users that will pay to have their assets moved with speed, consistency, and feasibility.
"While such cryptographic transfer of value is near-instantaneous, ensuring that the transaction has been included in the consensus of the shared ledger (aka. blockchain) creates delays ranging from a few minutes to hours, depending on the level of reliability required. Inclusion in the blockchain is performed by miners, who preferentially include transactions paying greatest fee per byte. Thus using the blockchain directly is slow, and too expensive for genuinely small transfers (typical fees are a few cents)." - Source
By introducing Segregated Witness (SW), Blockstream has been able to pretend to care about increasing the Bitcoin block size, when in reality, they have no desire to increase it at all. The real reason for SW is to fix tx-malleability which is a requirement to get LN to work. SW being able to increase throughput up to 1.75MB is just a byproduct and not a scaling solution. In addition, SW allows creation of unconfirmed transaction dependency chains without counterparty risk, an important feature for off-chain protocols such as LN.
Blockstream is also able to artificially create a fee market through different mechanisms (RBF) which creates a volatile experience for users on the Bitcoin blockchain. Merchants can no longer trust zero-confirmation tx’s, and users will have to fight with others by prioritizing their tx’s with higher fees to get their tx’s confirmed in the mempool before they are dropped. Creating a fee market on the Bitcoin blockchain is another incentive to push users off-chain to their second tier platform with premium scalability and ease-of-use, where zero-confirmations can be trusted again.

Putting it together

As you can see from Blockstream’s motivations and past history, it’s become very clear to the entire Bitcoin community that their intentions are to sabotage Bitcoin in order to make sidechains the go-to platform for anyone in the world to be able to transfer assets on the blockchain with speed and scalability. They have never intended on raising the block size, do not plan on it, and are creating a volatile ecosystem so they can sell their premium second tier platform to users through control and censorship.

Revenue Model

This is an update/edit as it has recently come to light from Blockstream executive Greg Maxwell that Blockstream plans to privatize sidechains through the limiting of the Bitcoin blockchain and generate revenue through subscriptions, transaction fees, support (consulting), and custom development work. Their first client as it turns out is major bank and financial firm, PWC.


To the Core dev who is harassing me over PM, I have reported you to the reddit admins.
A redditor who wanted to remain anonymous asked me to also include this information which seems just as important and relevant to the plan:
Concerning SegWit, it would also be necessary to mention that it not just fixes tx malleability, but also makes opening and closing Lightning channels cheaper.
Lightning will use very complex scripts, so the transaction size for creating a channel will take like 2-5x more space than an ordinary transaction, resulting in an increased transaction fee. With SegWit deployed, the scripts are removed from the blocks, so the fees for ordinary tx and opening a channel will be the same.
To those that have gifted me gold, thank you!
submitted by Gobitcoin to btc [link] [comments]

2 more blatant LIES from Blockstream CTO Greg Maxwell u/nullc: (1) "On most weeken[d]s the effective feerate drops to 1/2 satoshi/byte" (FALSE! The median fee is now well over 100 sat/byte) (2) SegWit is only a "trivial configuration change" (FALSE! SegWit is the most radical change to Bitcoin ever)

Below are actual quotes (archived for posterity) showing these two latest bizarre lies (from a single comment!) now being peddled by the toxic dev-troll Greg Maxwell u/nullc - CTO of AXA-owned Blockstream:
(1) Here is AXA-owned Blockstream CTO Greg Maxwell u/nullc lying about fees:
On most weeken[d]s the effective feerate drops to 1/2 satoshi/byte... [?!?!] basically nothing-- which is how traffic will be on most weekdays if there is only a bit more capacity.
(2) Here is AXA-owned Blockstream CTO Greg Maxwell u/nullc lying about SegWit:
Miners could trigger a doubling of the network's capacity with no disruption in ~2 weeks, the software for it is already deployed all over the network-- on some 90%+ of nodes (though 20% would have been sufficient!), miners need only make a trivial configuration change [SegWit] [?!?!]
And this is on top of another bizarre / delusional statement / lie / "alternative fact" that Greg Maxwell u/nullc also blurted out this week:
(3) Here's the sickest, dirtiest lie ever from Blockstream CTO Greg Maxwell u/nullc: "There were nodes before miners." This is part of Core/Blockstream's latest propaganda/lie/attack on miners - claiming that "Non-mining nodes are the real Bitcoin, miners don't count" (their desperate argument for UASF)
This is the guy that the astroturfers / trolls / sockpuppets / suicidal UASF lemmings from r\bitcoin want as their "leader" deciding on the "roadmap" for Bitcoin?
Well, then it's no big surprise that Greg Maxwell's "roadmap" has been driving Bitcoin into a ditch - as shown by this recent graph:
At this point, the sane people involved with Bitcoin be starting to wonder if maybe Greg Maxwell is just a slightly-more-cryptographically-talented version of another Core nut-job: the notoriously bat-shit insane Luke-Jr.
Commentary and analysis
Greg is supposedly a smart guy and a good cryptographer - but now for some weird reason he seems to be going into total melt-down and turning bat-shit insane - spreading outrageous lies about fees and about SegWit.
Maybe he can't handle the fact that that almost 60% of hashpower is now voting for bigger blocks - ie the majority of miners are explicitly rejecting the dead-end scaling stalling road-map of "One Meg" Greg & Core/Blockstream/AXA, based on their centrally-planned blocksize + their dangerous overly-complicated SegWit hack.
To be clear: there is a very specific reason why the SegWit-as-a-soft-fork hack is very dangerous: doing SegWit-as-a-soft-fork would dangerously require making all coins "anyone-can-spend".
This would create an enormous new unprecedented class of threat vectors against Bitcoin. In other words, with SegWit-as-a-soft-fork, for the first time ever in Bitcoin's history, a 51% attack would not only be able to double-spend, or prevent people from spending: with SegWit-as-a-soft-fork, a 51% attack would, for the first time ever in Bitcoin, be able to steal everyone's coins.
This kind kind of "threat vector" previously did not exist in Bitcoin. And this is what Greg lies and refers to as a "minor configuration change" (when SegWit is actually the most radical and irresponsible change ever proposed in the history of Bitcoin) - in the same breath where he is also lying and saying that "fees are 1/2 satoshi per byte" (when fees are actually hundreds of satoshis per byte now).
Now, here is the truth - which AXA-owned Blockstream CTO Greg Maxwell u/nullc doesn't want you to know - about fees and about SegWit:
(1) Fees are never "1/2 satoshi per byte" - fees are now usually hundreds of satoshis per byte
The network is now permanently backlogged, and fees are skyrocketing, as you can see from this graph:
The backlog used to clear out over the weekend. But not anymore. Now the Bitcoin network is permanently backlogged - and the person most to blame is the incompetent / lying toxic dev-troll AXA-owned Blockstream CTO Greg Maxwell u/nullc.
The median fee on the beige-colored zone on this graph shows that most people are actually paying 280-300 satoshis / byte in the real world - not 1/2 satoshi / byte as lying Greg bizarrely claimed.
You can also compare with these other two graphs, which show similar skyrocketing fees:
So when AXA-owned Blockstream CTO Greg Maxwell u/nullc says "On most weeken[d]s the effective feerate drops to 1/2 satoshi/byte.. basically nothing"... everyone can immediately look at the graphs and immediately see that Greg is lying.
AXA-owned Blockstream CTO Greg Maxwell u/nullc is the "mastermind" to blame for Bitcoin's current suicidal dead-end roadmap, which is causing:
I mean, seriously, what the fuck?!?
How can people even be continue to think that this guy Greg Maxwell u/nullc any credibility left at this point, if he's publicly on the record making this bizarre statement that fees are 1/2 satoshi per byte, when everyone already knows that fees are hundreds of satoshis per byte???
And what is wrong with Greg? Supposedly he's some kind of great mathematician and cryptographer - but he's apparently incapable of reading a simple graph or counting?
This is the kind of "leader" who people the ignorant brainwashed lemmings on r\bitcoin "trust" to decide on Bitcoin's "roadmap"?
Well - no wonder shit like this graph is happening now, under the leadership of a toxic delusional nutjob like "One Meg" Greg, the "great mathematician and cryptoprapher" who now we discover apparently doesn't know the difference between "1/2 a satoshi" versus "hundreds of satoshis".
How can the community even have anything resembling a normal debate when a bizarre nutjob like Greg Maxwell u/nullc is considered some kind of "respected leader"?
How can Bitcoin survive if we continue to listen to this guy Greg who is now starting to apparently show serious cognitive and mental issues, about basic obvious concepts like "numbers" and "nodes"?
(2) SegWit would be the most radical and irresponsible change ever in the history of Bitcoin - which is why most miners (except centralized, central-banker-owned "miners" like BitFury and BTCC) are rejecting SegWit.
Below are multiple posts explaining all the problems with SegWit.
Of course, it would be nice to fix malleability and quadratic hashing in Bitcoin. But as the posts below show, SegWit-as-a-soft-fork is the wrong way to do this - and besides, the most urgent problem facing Bitcoin right now (for us, the users) is not malleability or quadratic hashing - the main problem in Bitcoin right now is the never-ending backlog - which SegWit is too-little too-late to fix.
By the way, there are many theories out there regarding why AXA-owned Blockstream CTO Greg Maxwell u/nullc is so insistent on forcing everyone to adopt SegWit.
Maybe I'm overly worried, but my theory is this: due to the sheer complexity of SegWit (and the impossibility of ever "rolling it back" to to the horrific "anyone-can-spend" hack which it uses in order to be do-able as a soft fork), the real reason why AXA-owned Blockstream CTO Greg Maxwell u/nullc insists on forcing SegWit on everyone is so that Blockstream (and their owners at AXA) can permanently centralize and control Bitcoin development).
At any rate, SegWit is clearly not the way forward for Bitcoin - and it is not even something that we can "compromise" on. Bitcoin will be seriously harmed by SegWit-as-a-soft-fork - and we really need to be asking ourselves why a guy like Greg Maxwell u/nullc insists on lying and saying that SegWit is a "minor configuration change" when everyone who understands Bitcoin and programming knows that SegWit is a messy dangerous hack which would be the most radical and irresponsible change ever introduced into Bitcoin - as all the posts below amply demonstrate.
Core Segwit – Thinking of upgrading? You need to read this!
~ u/Windowly (link to article on
SegWit is not great
~ u/deadalnix (link to [his blog post](
Here is a list (on of 13 articles that explain why SegWit would be bad for Bitcoin.
~ u/ydtm
Is it me, or does the segwit implementation look horribly complicated.
~ u/Leithm
Bitcoin Scaling Solution Segwit a “Bait and Switch”, says Roger Ver
~ u/blockologist
Segwit cannot be rolled back because to non-upgraded clients, ANYONE can spend Segwit txn outputs. If Segwit is rolled back, all funds locked in Segwit outputs can be taken by anyone. As more funds gets locked up in segwit outputs, incentive for miners to collude to claim them grows.
~ u/BiggerBlocksPlease
SegWit false start attack allows a minority of miners to steal bitcoins from SegWit transactions
~ u/homerjthompson_
Blockstream Core developer luke-jr admits the real reason for SegWit-as-soft-fork is that a soft fork does not require consensus, a hard fork would require consensus among network actors and "that it[SegWit] would fail on that basis."
~ u/blockstreamcoin
If SegWit were to activate today, it would have absolutely no positive effect on the backlog. If big blocks activate today, it would be solved in no time.
~ u/ThomasZander
Segwit is too complicated, too soon
~ u/redmarlen
Surpise: SegWit SF becomes more and more centralized - around half of all Segwit signals come from Bitfury
~ u/Shock_The_Stream
"Regarding SegWit, I don't know if you have actually looked at the code but the amount of code changed, including consensus code, is huge."
~ u/realistbtc
Segwit: The Poison Pill for Bitcoin
~ u/jEanduluoz
3 excellent articles highlighting some of the major problems with SegWit: (1) "Core Segwit – Thinking of upgrading? You need to read this!" by WallStreetTechnologist (2) "SegWit is not great" by Deadalnix (3) "How Software Gets Bloated: From Telephony to Bitcoin" by Emin Gün Sirer
~ u/ydtm
Segwit as a soft-fork is not backward compatible. Older nodes do not continue to protect users' funds by verifying signatures (because they can't see these). Smart people won't use SegWit so that when a "Bitcoin Classic" fork is created, they can use or sell their copies of coins on that fork too
~ u/BTC_number_1_fan
jtoomim "SegWit would require all bitcoin software (including SPV wallets) to be partially rewritten in order to have the same level of security they currently have, whereas a blocksize increase only requires full nodes to be updated (and with pretty minor changes)."
~ u/specialenmity
Segwit requires 100% of infrastructure refactoring
~ u/HermanSchoenfeld
Segwit is too dangerous to activate. It will require years of testing to make sure it's safe. Meanwhile, unconfirmed transactions are at 207,000+ and users are over-paying millions in excessive fees. The only option is to upgrade the protocol with a hard fork to 8MB as soon as possible.
~ u/Annapurna317
You've been lied to by Core devs - SegWit is NOT backwards compatible!
~ u/increaseblocks (quoting @olivierjanss on Twitter)
"SegWit encumbers Bitcoin with irreversible technical debt. Miners should reject SWSF. SW is the most radical and irresponsible protocol upgrade Bitcoin has faced in its history. The scale of the code changes are far from trivial - nearly every part of the codebase is affected by SW" Jaqen Hash’ghar
Blockstream having patents in Segwit makes all the weird pieces of the last three years fall perfectly into place
~ u/Falkvinge (Rick Falkvinge, founder of the first Pirate Party)
Finally, we need to ask ourselves:
(1) Why is AXA-owned Blockstream CTO Greg Maxwell u/nullc engaging in these kind of blatant, obvious lies about fees and about SegWit - the two most critical issues facing Bitcoin today?
(2) Why is AXA-owned Blockstream CTO Greg Maxwell u/nullc so insistent on trying to force Bitcoin to accept SegWit, when SegWit is so dangerous, and when there are other, much safer ways of dealing with minor issues like malleability and quadratic hashing?
(3) Now that AXA-owned Blockstream CTO Greg Maxwell u/nullc has clearly shown that:
  • He doesn't know the difference between "half a satoshi" and "hundreds of satoshis",
  • He doesn't know the difference between "minor configuration change" and "the most irresponsible and radical change ever" in Bitcoin, and
  • He thinks that somehow "non-mining nodes existed before mining nodes"
...then... um... Is there any mechanism in our community for somehow rejecting / ignoring / removing this toxic so-called "leader" Greg Maxwell who has now clearly shown that he is totally delusional and/or mentally incapacitated - in order to prevent him from totally destroying our investment in Bitcoin?
submitted by ydtm to btc [link] [comments]

Do you know what the word malleability means?

The word malleability was picked and used intentionally. Why would you want transaction structure to be modified or adjusted or smudged like clay? You wouldn't right? You'd want to trust in the accuracy of the transaction structure and not let some second-layer or third party, or separate script, confirm trust in transaction validity. Right?
Except that, despite the issue with signature hashes being slightly different being a minor thing, this inability to be malleable is what was targeted as the prime problem with Bitcoin, and that's what lead to segregated witness. Segregated Witness effectively breaks the existing transaction structure in order to create 2 transaction IDs instead of 1, and in order to run new signature scripts - scripts that aren't defined in the original Bitcoin protocol or whitepaper, in the name of expanding Bitcoin because, "Bitcoin doesn't work". "It can't scale" and "It has malleability issues".
When people talk about "the malleability bug" they are referencing signature smudging, as in, when transactions are signed there may be some slight discrepancy regarding the hash before one of the transaction IDs gets cemented into the ledger, for an example as a metaphor: "a capital I might look like a lowercase l" but since it is the signature and not the output data it will still be verified by network nodes before getting added to blocks. What they don't mention is that this doesn't actually have any effect on the transaction output data though, it doesn't result in any problems unless you are reading the data incorrectly. Yep, no effect, money is still transferred just fine. There is no evidence of fraud due to this supposed issue (except for supposedly big one, MtGox). For the vast majority of cases there is no issue. As usual, there is only one transaction that gets cemented into blocks (no doublespends).
Important to note here is that, there is no evidence that this is actually a problem with Bitcoin instead of a problem with second-layer or external services or exchanges such as the MtGox scenario where this "malleability bug" becomes a huge problem because they didn't account for the possibility that this slight variation of transaction ID might be entirely intentional.
This possibly, seemingly intentional, "flaw" that Bitcoin had (before it was modified to have segregated witness) to "fix the bug" is what makes things like lightning network completely unnecessary as is demonstrated daily by Bitcoin Cash users, the transaction structure is important and signature data is important and neither should be modified or adjusted. It was made that way for a reason. In addition, it isn't an issue if some of the signature data can be slightly off, again, the way the system is designed is that only one record becomes cemented into the blockchain. (No doublespend).
Of course, making transaction structure more modifiable was presented as making it easier to expand with future software (such as lightning and schnorr, etc) by Blockstream et al, because it apparently makes it so that there is only ever one definite data tied to one transaction ID, by instead creating TWO transaction IDs and tying them together with a segregated witness script..."A new data structure, witness, is defined. Each transaction will have 2 IDs. " source and the witness ID references the original like a mirror copy, but that also opens up some potentially huge problems later on, and the worst part about it is that these problems would be difficult to prove by a user after they've happened. Why is that? Because if you examine the transaction structure it would appear as though everything is in order even though there may have been an issue (or according to the specification: maybe locked, maybe in a segwit wallet, maybe not yet validated). While there is no proof that money could be stolen if you do not upgrade, there was alarming uncertainty regarding the future of your funds and the future of the network and it does feel like a threat if you do not upgrade.
According to the specification of segwit (and segwit users here often deny) "signature data becomes optional". Signature data, the data that is required and described by Bitcoin as a fundamental building block as part of the process of verifying transaction data as it is propagated to the network. Bitcoin uses something called a Elliptical Curve Digital Signature Algorithm. - with segwit the signature data is separated out from the transactions: "This BIP defines a new structure called a "witness" that is committed to blocks separately from the transaction merkle tree."
See for yourself: with segwit, "signature data is no longer part of the transaction hash" source.
Segwit is "removing this data from the transaction structure committed to the transaction merkle tree" source.
In its own words: "how the transaction was signed are no longer relevant to transaction identification".
"It allows creation of unconfirmed transaction dependency chains" [... in other words, chains that aren't really Bitcoin ...] "an important feature for offchain protocols such as the Lightning Network".
"Segregated witness fixes the problem of transaction malleability fundamentally" the specification then goes on to basically describe Lightning - but is this really a good thing? Micro-transactions with extremely low fees are happening daily already with Bitcoin Cash with zero issues and Bitcoin Cash now has 32MB blocks (Instead of 1MB/2MB) without an unnecessary change to transaction data or signature scripts.
"Since a version byte is pushed before a witness program, and programs with unknown versions are always considered as anyone-can-spend script, it is possible to introduce any new script system with a soft fork." - so essentially the old chain would be able to become deprecated ... is this really a good thing? was there really a problem to be fixed? do we want any new script system like segwit to define the new blockchain from now on?
Actually this is exactly what this is all about, segregated witness is.... in reality... a covert takeover of the old chain signature scripts (or rules) with the new ones that don't actually disable the old methods and system but also don't allow any devs to go back and work with the old scripts anymore, they're considered completely irrelevant now. This effectively kills Bitcoin as you know it. It forces devs to work with the new segregated witness from now on, or be forgotten. Devs are now forced to use the new segregated witness protocol and any future scripts must run according to the segregated witness procotol that has the wtxid and 2 transaction ID format. Not long from now the original txid will likely be deprecated and everything will move over to just using wtxid... this is fairly obvious because, those old signature scripts are still being used today with no issues by Bitcoin Cash just fine.
submitted by crockscream to btc [link] [comments]

Core Does Not Control Bitcoin. Run a Bitcoin Unlimited Node.

I’ve been told several times by Bitcoin Core developers, specifically Greg Maxwell, but also many others, that they do not “control” Bitcoin. That they merely write the code they want and people can choose to run it or to run something else. “That’s how it works”, they say.
They claim to not be in control, yet they viciously attack other Bitcoin development teams and those supporting them. They also actively Back the bitcoin censorship of any code or ideas not produced by them while allowing attacks and name calling of those opposing their settlement layer direction.
I believe it is this, “we can do whatever we want” attitude that led them to ignore users and businesses in the first place.
We’ve seen transactions approach the blocksize limit for two years. Gavin Andresen wrote elegantly about why we should increase the blocksize in 2015, rather than waiting until it became a problem. Well, Core didn’t listen and now it is a big, big problem.
Some core supporters even have the nerve to say, “a hard fork would take a year to prepare and it’s too late for that now, just run Segwit”.
Expert developers know better. Segwit is a road to a settlement-only Bitcoin: A very narrow sliver of Satoshi’s original vision of peer-to-peer electronic cash that we all signed up for.
Everyone is excited about an ETF, but when that hits later today there will be massive movements either up or down depending on what happens. This is sure to cause excessive fees and new levels of unconfirmed transactions.
Bitcoin Unlimited and Bitcoin Classic are actively listening to users. They’ve solved the blocksize issue once and for all by taking it out of the reference protocol and putting it in the hands of the miners who secure the network. This is safe because miners both want the network to function while also having some revenue from fees. Blocksize increases can happen gradually over time with consensus rather than requiring hard forks every 5 years. It is the best solution moving forward that anyone has proposed.
We have seen that Core cannot be trusted.
We have seen them act negligently towards basic network functionality.
We have seen them ignoring users and only developing for “sexy” second-layer vaporware off-chain projects.
We must do as Greg Maxwell suggested and run something other than core’s code.
We must fight the fear-driven propaganda and biased censorship from bitcoin.
We must call out the minority attacks on the network whether it’s threats from a user-activated soft fork or any other malleability attack
In order for Bitcoin to succeed long-term, we must give control back to the users.
submitted by Annapurna317 to btc [link] [comments]

Mycelium Local Trader is Now Available!
The latest major Mycelium feature, called Local Trader, is finally out of beta and available to everyone.
With Local Trader, the development team at Mycelium sought to answer a question often posed by those new to bitcoin: Now that I have a bitcoin wallet, how do I get some bitcoins?
Local Trader lets those who already have bitcoins to offer them for sale, and those who are looking to obtain bitcoins an easy to use interface to find those sellers in their area. This allows sellers to support their local Bitcoin economy and earn a little in the process.
Local Trader at a glance:
Initially, the trader options will be limited to standing sell offers and instant buy offers. Meaning only those who wish to offer to sell bitcoins for local currency will be able to create standing offers for buyers to search through. Later on, Local Trader will also add standing buy offers, for those who wish to offer the option of converting bitcoins to other currencies as well.
To enhance privacy, Local Trader eschews the login and password authentication method, and instead uses your wallet's private key to register and authenticate with the server, using the well established bitcoin key message signing feature. Also, all communication between buyers and sellers, such as when and where to meet, is encrypted using the traders' respective private keys. This means that the Mycelium servers that manage trades only know the bitcoin addresses, pseudonyms, coarse location, and trade history of the people involved, in effect making the system almost as pseudonymous as Bitcoin itself from the company's point of view.
Finally, when the traders meet and exchange cash, Mycelium's other new feature, the transaction confidence graph (currently limited to Local Trader) goes into effect, displaying the probability that the transaction that sends coins to the buyer's wallet will get included in the next block. To achieve this, Mycelium servers track the transaction as it propagates through thousands of nodes, as well as check it for possible double-spends, transaction malleability, long chains of unconfirmed inputs, proper transaction fees, and other possible issues. With this, traders can exchange cash and be on their way, fairly confident that the transaction was legitimate, without having to wait 10 minutes for a confirmation.
With the recent issues involving centralized exchanges shutting down or running away with money, and governments forcefully shutting down methods of getting money into exchanges, Mycelium hopes that this new feature will let anyone be a walking ATM, making exchanging bitcoins for other currencies much easier, and allowing traders to earn a bit of money in the process.
You can download the most recent verson from Google Play store here, or directly from
Fore more info and HOWTO refer to:
TL;DR: This is the most decentralized exchange you can use today. Decentralize ALL the things.
submitted by Rassah to Bitcoin [link] [comments]

Transaction malleability reference post

(I've seen a lot of people thinking Bitcoin Cash did nothing to remove transaction malleability, and asking whether that might hold us back. I'm posting this mostly so I can just link to it when someone asks this again, but feel free to pin it should it prove to be useful.)
The DAA upgrade included the NULLFAIL and LOW_S BIPs, both of which remove sources of transaction malleability. According to this comment ( by Deadalnix (A Bitcoin ABC developer), this should ensure that p2pkh transactions (the simple kind used for nearly everything) aren't malleable anymore.
You can read more about this upgrade at
Some people wonder what transaction malleability even means, so I'll address that as well. When a transaction spends anything, it refers to the hash of a previous transaction. This hash is the output of an irreversible mathematical function, uniquely identifying that transaction. If the contents of the transaction change, the hash changes too. Crucially, this hash also covers the signature. There are a few ways to alter the signature data (even from transactions that aren't yours in the first place) to get an equally-valid transaction with a different hash. If this altered transaction makes it into the blockchain, rather than the original, that's what we consider to be malleation. This is never an issue to any well-written software, though MtGox blamed its problems on this for a short while.
Lightning Network needs unmalleable transactions because it relies on unconfirmed transactions to work. It needs to make sure the transaction hashes for those transactions remain the same, despite them not being in blocks. This is why it needs SegWit.
I hope this post has been informative. If anyone has something to add, please do! I'll edit in anything important that I missed.
submitted by Dekker3D to btc [link] [comments]

SegWit Transaction Percentage Hits 6.5%

Yesterday, I reported that " we hit another milestone today. SegWit hits 6%"
Today it just hit 6.5%. Source:
It looks like the pace to SegWit adoption is picking up speed, very quickly, & Bitcoin price is rising close to all time highs again, as transactions fees are falling rapidly, & confirmations times are much quicker..
Segregated Witness, or SegWit, is a solution to improve the Bitcoin's scalability and make it cheaper AND faster to process more transactions.
Here are the key things that SegWit enables:
• It rearranges how data is stored in Bitcoin blocks.
• It boosts capacity while remaining compatible with past versions of the software.
• It removes transaction malleability, a bug that's been the primary roadblock for many bitcoin projects.
Bitcoin Mem Pool is at an all time low this year, sitting at or around 10,000. It used to sit at 150,000 PLUS, before SegWIt.- Source:
If this is how well Bitcoin performs with JUST SegWit, imagine how well Bitcoin will perform when / if the block size doubles in November with the Segwit2X Hard Fork! Could this be the driving force behind the the increase in BTC Dominance to 48.8%?
If you want to get 1 Free Bitcoin (Bitcoin Gold) at the end of October, & another free Bitcoin in November (Bitcoin Segwit2X), for each Bitcoin BTC you own, make sure you hold your Bitcoins (BTC) in a hardware wallet like Trezor or Ledger.
This post is an educated guess, based on what I have read, in many forums. I am not a technical expert. This is not financial advice. I am not your advisor. Please carry out your own research.
submitted by BTCBCCBCH to btc [link] [comments]

Why is Bitcoin protocol not fixed against TX malleability once and for all?

At present, a transaction malleability attack is hitting the Bitcoin network. This causes no loss of funds but often requires manual interactions at the side of service providers and also wallet end users. Moreover, it renders Bitcoin's feature of spending unconfirmed transactions useless, which is a pity.
The problem is that the sender's signature of a transaction does not cover the complete transaction string, so an attacker can pick any unconfirmed transaction, change the parts that are not covered by the signature, thereby creating a new valid(!) transaction that he broadcasts to the network. This looks like a double spend then (albeit with identical in- and outputs).
To me this is a fundamental design flaw that should be fixed soon!
The signature that the sender adds to the transaction should cover every single bit of the transaction (incl. any tx IDs or whatever), and not only input+output addresses and fee and amounts. This way, any tx malleability would be impossible by design!
The fact that this is not the case seems like a fundamental and completely unnecessary Bitcoin design flaw, actually I am shocked that it is still there.
I am even more shocked to read that there might(?) be several different/unknown malleability attacks possible.
Shouldn't it be easy to fix this once and for all with a protocol upgrade which respects the most basic property of a digital signature, namely that the signature spans over the COMPLETE transaction string? I cannot see what disadvantages this should bring and assume the fix should be relatively simple for a new protocol version.
It could even be downwards compatible in that the new transaction format is introduced on top of the legacy format (which still remains valid [and prone to malleability]). So wallets could implement the new format and thereby advertise to be 100% safe against tx malleability. At a later point in time, once the old format amounts to less than 1% of all transactions, another protocol update could be introduced that renders the old transaction format invalid.
submitted by Amichateur to Bitcoin [link] [comments]

Percentage of Segwit Transactions Hits 8%, Mem Pool is Empty

Developed primarily to solve a long-standing vulnerability in Bitcoin (transaction malleability), it also had the side effect of providing more on-chain capacity, & reducing fees for sending / receiving Bitcoins.
SegWit Charts Transaction percentage hits 8%:
Shapeshift IS Now One of the Leading SegWit Adopters! Shapeshift is responsible for 2% to 3% of ALL Bitcoin transactions. What this means:
• Lower mining fees for ShapeShift users buying or selling Bitcoin
• Less data per transaction (increasing scale capacity of network)
Unconfirmed Transactions (MEM Pool) are really low, at around 10,000. All this year, before SegWit got activated, Unconfirmed Transactions, were sitting around 150,000. Source:
Please note, you could get 2 free coins, IF you hold Bitcoin (BTC), when Bitcoin Gold Hard Forks on 25th October, & SegWit2X in mid November.
When the SegWit2X Hard Fork happens in mid November. Coinbase has said that "Customers with Bitcoin balances stored on Coinbase at the time of the fork, will have access to Bitcoin on both blockchains." Source:
Now, you can sell whichever chain of Bitcoin you want to sell, safely, without selling the Bitcoin chain you want to keep.
The only wallet that I know of so far, that has confirmed that they will provide support for SegWit2X chain is the Ledger hardware wallet. They clearly state "if there's no replay protection added we'll force a split before transacting" Source:
submitted by BTCBCCBCH to btc [link] [comments]

History Lesson for new VIA Viacoin Investors

Viacoin is an open source cryptocurrency project, based on the Bitcoin blockchain. Publicly introduced on the crypto market in mid 2014, Viacoin integrates decentralized asset transaction on the blockchain, reaching speeds that have never seen before on cryptocurrencies. This Scrypt based, Proof of Work coin was created to try contrast Bitcoin’s structural problems, mainly the congested blockchain delays that inhibit microtransaction as this currency transitions from digital money to a gold-like, mean of solid value storage. Bitcoin Core developers Peter Todd and Btc have been working on this currency and ameliorated it until they was able to reach a lightning fast speed of 24 second per block. These incredible speeds are just one of the features that come with the implementation of Lightning Network, and and make Bitcoin slow transactions a thing of the past. To achieve such a dramatic improvement in performance, the developers modified Viacoin so that its OP_RETURN has been extended to 80 bytes, reducing tx and bloat sizes, overcoming multi signature hacks; the integration of ECDSA optimized C library allowed this coin to reach significant speedup for raw signature validation, making it perform up to 5 times better. This will mean easy adoption by merchants and vendors, which won’t have to worry anymore with long times between the payment and its approval. Todd role as Chief Scientist and Advisor has been proven the right choice for this coin, thanks to his focus on Tree Chains, a ground breaking feature that will fix the main problems revolving around Bitcoin, such as scalability issues and the troubles for the Viacoin miners to keep a reputation on the blockchain in a decentralized mining environment. Thanks to Todd’s expertise in sidechains, the future of this crypto currency will see the implementation of an alternative blockchain that is not linear. According to the developer, the chains are too unregulated when it comes to trying to establish a strong connection between the operations happening on one chain and what happens elsewhere. Merged mining, scalability and safety are at risk and tackling these problems is mandatory in order to create a new, disruptive crypto technology. Tree Chains are going to be the basis for a broader use and a series of protocols that are going to allow users and developers to use Viacoin’s blockchain not just to mine and store coins, but just like other new crypto currencies to allow the creation of secure, decentralized consensus systems living on the blockchain The commander role on this BIP9 compatible coin’s development team has now been taken by a programmer from the Netherlands called Romano, which has a great fan base in the cryptocurrency community thanks to his progressive views on the future of the world of cryptos. He’s in strong favor of SegWit, and considers soft forks on the chain not to be a problem but an opportunity: according to him it will provide an easy method to enable scripting upgrades and the implementation of other features that the market has been looking for, such as peer to peer layers for compact block relay. Segregation Witness allows increased capacity, ends transactions malleability, makes scripting upgradeable, and reduces UTXO set. Because of these reasons, Viacoin Core 0.13 is already SegWit ready and is awaiting for signaling.
Together with implementation of SegWit, Romano has recently been working on finalizing the implementation of merged mining, something that has never been done with altcoins. Merged mining allows users to mine more than one block chain at the same time, this means that every hash the miner does contributes to the total hash rate of all currencies, and as a result they are all more secure. This release pre-announcement resulted in a market spike, showing how interested the market is in the inclusion of these features in the coin core and blockchain. The developer has been introducing several of these features, ranging from a Hierarchical Deterministic key (HD key) generation that allows all Viacoin users to backup their wallets, to a compact block relay, which decreases block propagation times on the peer to peer network; this creates a healthier network and a better baseline relay security margin. Viacoin’s support for relative locktime allows users and miners to time-lock a transaction, this means that a new transaction will be prevented until a relative time change is achieved with a new OP code, OP_CHECKSEQUENCEVERITY, which allows the execution of a script based on the age of the amount that is being spent. Support for Child-Pays-For-Parent procedures in Viacoin has been successfully enabled, CPFP will alleviate the problem of transactions that stuck for a long period in the unconfirmed limbo, either because of network bottlenecks or lack of funds to pay the fee. Thanks to this method, an algorithm will selects transactions based on federate inclusive unconfirmed ancestor transaction; this means that a low fee transaction will be more likely to get picked up by miners if another transaction with an higher fee that speeds its output gets relayed. Several optimizations have been implemented in the blockchain to allow its scaling to proceed freely, ranging from pruning of the chain itsel to save disk space, to optimizing memory use thanks to mempool transaction filtering. UTXO cache has also been optimization, further allowing for significant faster transaction times. Anonymity of transaction has been ameliorated, thanks to increased TOR support by the development team. This feature will help keep this crypto currency secure and the identity of who works on it safe; this has been proven essential, especially considering how Viacoin’s future is right now focused on segwit and lightning network . Onion technology used in TOR has also been included in the routing of transactions, rapid payments and instant transaction on bi directional payment channels in total anonymity. Payments Viacoin’s anonymity is one of the main items of this year’s roadmap, and by the end of 2017 we’ll be able to see Viacoin’s latest secure payment technology, called Styx, implemented on its blockchain. This unlinkable anonymous atomic payment hub combines off-the-blockchain cryptographic computations, thanks to Viacoin’s scriptin functionalities, and makes use of security RSA assumptions, ROM and Elliptic Curve digital signature Algorithm; this will allow participants to make fast, anonymous transfer funds with zero knowledge contingent payment proof. Wallets already offer strong privacy, thanks to transactions being broadcasted once only; this increases anonymity, since it can’t be used to link IPs and TXs. In the future of this coin we’ll also see hardware wallets support reaching 100%, with Trezor and Nano ledger support. These small, key-chain devices connect to the user’s computer to store their private keys and sign transactions in a safe environment. Including Viacoin in these wallets is a smart move, because they are targeted towards people that are outside of hardcore cryptocurrency users circle and guarantees exposure to this currency. The more casual users hear of this coin, the faster they’re going to adopt it, being sure of it’s safety and reliability. In last October, Viacoin price has seen a strong decline, probably linked to one big online retailer building a decentralized crypto stock exchange based on the Counterparty protocol. As usual with crypto currencties, it’s easy to misunderstand the market fluctuations and assume that a temporary underperforming coin is a sign of lack of strength. The change in the development team certainly helped with Viacoin losing value, but by watching the coin graphs it’s easy to see how this momentary change in price is turning out to be just one of those gentle chart dips that precede a sky rocketing surge in price. Romano is working hard on features and focusing on their implementation, keeping his head low rather than pushing on strong marketing like other alt coins are doing. All this investment on ground breaking properties, most of which are unique to this coin, means that Viacoin is one of those well kept secret in the market. Minimal order books and lack of large investors offering liquidity also help keep this coin in a low-key position, something that is changing as support for larger books is growing. As soon as the market notices this coin and investments go up, we are going to see a rapid surge in the market price, around the 10000 mark by the beginning of January 2018 or late February. Instead of focusing on a public ICO like every altcoin, which means a sudden spike in price followed by inclusion on new exchanges that will dry up volume, this crypto coin is growing slowly under the radar while it’s being well tested and boxes on the roadmap get checked off, one after the other. Romano is constantly working on it and the community around this coin knows, such a strong pack of followers is a feature that no other alt currency has and it’s what will bring it back to the top of the coin market in the near future. His attitude towards miners that are opposed to SegWit is another strong feature to add to Viacoin, especially because of what he thinks of F2Pool and Bitmain’s politics towards soft forks. The Chinese mining groups seem scared that once alternative crypto coins switch to it they’re going to lose leveraging power for what concerns Bitcoin’s future and won’t be able to speculate on the mining and trading market as much as they have been doing in the past, especially for what concerns the marketing market.
It’s refreshing to see such dedication and releases being pushed at a constant manner, the only way to have structural changes in how crypto currencies work can only happen when the accent is put on development and not on just trying to convince the market. This strategy is less flashy and makes sure the road is ready for the inevitable increase in the userbase. It’s always difficult to forecast the future, especially when it concerns alternative coins when Bitcoin is raising so fast. A long term strategy suggestion would be to get around 1BTC worth of this cryptocoin as soon as possible and just hold on it: thanks to the features that are being rolled in as within 6 months there is going to be an easy gain to be made in the order of 5 to 10 times the initial investment. Using the recent market dip will make sure that the returns are maximized. What makes Viacoin an excellent opportunity right now is that the price is low and designed to rise fast, as its Lightning Network features become more mainstream. Lightning Network is secure, instant payment that aren’t going to be held back by confirmation bottlenecks, a blockchain capable to scale to the billions of transactions mark, extremely low fees that do not inhibit micropayments and cross-chain atomic swap that allow transaction across blockchain without the need of a third party custodians. These features mean that the future of this coin is going to be bright, and the the dip in price that started just a while ago is going to end soon as the market prepares for the first of August, when when the SegWit drama will affect all crypto markets. The overall trend of viacoin is bullish with a constant uptrend more media attention is expected , when news about the soft fork will spread beyond the inner circle of crypto aficionados and leak in the mainstream finance news networks. Solid coins like Viacoin, with a clear policy towards SegWit, will offer the guarantees that the market will be looking for in times of doubt. INVESTMENT REVIEW Investment Rating :- A+
submitted by alex61688 to viacoin [link] [comments]

Bitcoin dev meeting in layman's terms (2015-10-8)

Once again my attempt to summarize and explain the weekly bitcoin developer meeting in layman's terms. Link to last weeks summarization
Please bare in mind I'm not a developer and I'd have problems coding "hello world!", so some things might be incorrect or plain wrong. Like any other write-up it likely contains personal biases, although I try to stay as neutral as I can. There are no decisions being made in these meetings, so if I say "everyone agrees" this means everyone present in the meeting, that's not consensus, but since a fair amount of devs are present it's a good representation. The dev IRC and mailinglist are for bitcoin development purposes. If you have not contributed actual code to a bitcoin-implementation, this is probably not the place you want to reach out to. There are many places to discuss things that the developers read, including this sub-reddit.
link to this week logs link to meeting minutes
Main topics discussed this week where:
Mempool limiting: chain limits Low-S change CLTV & CSV review Creation of bitcoin discuss mailing list
off-topic but important notice
This issue has made most JS bitcoin software vulnerable to generating incorrect public keys. "This is an ecosystem threat with the potential to cause millions of dollars in losses that needs higher visibility; though it's not a bitcoin core / bitcoin network issue. Common, critical, JS code is broken that may cause the generation of incorrect pubkeys (among other issues). Anyone who cares for a JS implementation should read that PR."
Mempool limiting: chain limits
(c/p from last week) Chain in this context means connected transactions. When you send a transaction that depends on another transaction that has yet to be confirmed we talk about a chain of transactions. Miners ideally take the whole chain into account instead of just every single transaction (although that's not widely implemented afaik). So while a single transaction might not have a sufficient fee, a depending transaction could have a high enough fee to make it worthwhile to mine both. This is commonly known as child-pays-for-parent. Since you can make these chains very big it's possible to clog up the mempool this way. The first unconfirmed transaction is called the ancestor and the transactions depending on it the descendants. The total amount of transactions is reffered to as "packages".
As said in "Chain limits" last week Morcos did write a proposal about lowering the default limits for transaction-chains. 2 use cases came up which are currently in use or happened before: As example: someone buys bitcoin from a website and can spend those bitcoin in the marketplace of the same website without waiting for confirmation in order to improve the bitcoin user-experience. This leaves a sequential transaction chain. They don't need to chain more than 5 transactions deep for this, and it falls within the proposed limits. What's not within the proposed limits is the chain of +/- 100 transactions a company had during the spam-attacks. These where simply increased activities by end-users while not enough UTXO's where available (3 to be precise)(UTXO: unspent transaction output, an output that can be used as input for a new transaction). Notably this is with the best practices of using confirmed transactions first. Ways this can be solved from the company's end is to have more UTXO's available before hand, bundling transactions (which requires delaying customer's request) or using replace-by-fee to add payees (which saves blockchain space, is cheaper in fees and gets transactions through quicker, but is not widely deployed by miners atm). Bare in mind these proposals are for default values for the memorypool, not in any way hard limits.
Sense of urgency. Quoting sipa: "my mempool is 2.5G... we better get some solution!" Current attack analysis assumes child-pays-for-parent mining, it should probably be done again without. Higher limits on number of transactions increase attack-vectors. Proposed number of transactions gets some push-back, total size limit not. Mixing default values (for example having a 50% of a 10/10 limit and 50% of a 100/100 limit) wastes bandwidth while there are too many factors that limit utility of long chains as well. 25 transaction limit ought to be enough for everyone (for now).
Review & test Limit mempool by throwing away the cheapest txn and setting min relay fee to it Provide support for Lower default limits for tx chains aka convince people 25 should be enough.
Low-S change
This is in regards to the recent malleability attack. Which is caused by a value 'S' in the ECDSA signature which can be 2 values, a high and low value and still be valid. Resulting in different transaction id's. more info A solution for this is to require nodes to have the "low-s" encoding for signatures. Downside is that it will block most transactions made by sufficiently out of date software (+/- pre-march 2014) This does not replace the need for BIP62, it only eliminates the cheap DOS attack.
95% of transactions already confirm to this, and more fixes have been applied since. BlueMatt has a node which several people are running that auto-malleates to low-s transactions. Questions whether we release it ASAP or wait for the next release and get it to a couple of miners in the meantime (possibly with auto-lowS-malleating)
Contact miners about "Test LowS in standardness, removes nuisance malleability vector" Release scheduled for the end of the month, together with likely check-lock-time-verify and possibly check-sequence-verfiy.
CLTV & CSV backport review
CLTV: checkLockTimeVerify CSV: checkSequenceVerify Both new time-related OP-codes. Been discussed heavily last week.
Concerns whether CSV will be ready enough for release later this month. There's no clarity on how things look when all 3 time related pull-requests are merged. There's a number of people still reviewing the pull-requests. Uncertainty and confusion about whether the semantics are final or not (in regards to using bits from nSequence). nSequence are 4 bytes intended for sequencing time-locked transactions, but this never got used. Now these bytes are being repurposed for a mixture of things. Currently the plan is: " bits 0..15 are the relative locktime, bit 30 determines units (0: height, 1: time w/ 512s granularity), and bit 31 toggles BIP 68 (0: on, 1: off). bits 16..29 are masked off and can take any value."
Clarification from maaku regarding nSequence for BIP68. (after the meeting he explained he was waiting for opinions, but not enough people seemed to know the issue at hand) Continue review of pull requests 6312, 6564 and 6566
Creation of bitcoin discuss mailing list
The bitcoin-dev mailing list is intented for technical discussions only. There's things that don't belong there but need to be discussed anyway. Now this is done in bitcoin-dev, but the volume of this is getting too big. There's recently also an influx of really inappropriate posts, level kindergarden.
No clarity about who are the moderators. Next week there'll be a bitcoin-discuss list created. Decisions are needed as to who'll become the moderators for that and bitcoin-dev. Decisions are needed as to what will be the list and moderation policies.
The bitcoin-discuss list will be created as well as a simple website listing all the lists and corresponding policies. A meeting is scheduled on monday to discuss the moderation and policies of said lists.
morcos Alex Morcos gmaxwell Gregory Maxwell wumpus Wladimir J. van der Laan sipa Pieter Wuille BlueMatt Matt Corallo btcdrak btcdrak petertodd Peter Todd warren Warren Togami phantomcircuit Patrick Strateman dstadulis Daniel Stadulis GreenIsMyPepper Joseph Poon bsm117532 Bob McElrath
submitted by G1lius to Bitcoin [link] [comments]

The Mike Hearn Show: Season Finale (and Bitcoin Classic: Series Premiere)

This post debunks Mike Hearn's conspiracy theories RE Blockstream in his farewell post and points out issues with the behavior of the Bitcoin Classic hard fork and sketchy tactics of its advocates
I used to be torn on how to judge Mike Hearn. On the one hand he has done some good work with BitcoinJ, Lighthouse etc. Certainly his choice of bloom filter has had a net negative effect on the privacy of SPV users, but all in all it works as advertised.* On the other hand, he has single handedly advocated for some of the most alarming behavior changes in the Bitcoin network (e.g. redlists, coinbase reallocation, BIP101 etc...) to date. Not to mention his advocacy in the past year has degraded from any semblance of professionalism into an adversarial us-vs-them propaganda train. I do not believe his long history with the Bitcoin community justifies this adversarial attitude.
As a side note, this post should not be taken as unabated support for Bitcoin Core. Certainly the dev team is made of humans and like all humans mistakes can be made (e.g. March 2013 fork). Some have even engaged in arguably unprofessional behavior but I have not yet witnessed any explicitly malicious activity from their camp (q). If evidence to the contrary can be provided, please share it. Thankfully the development of Bitcoin Core happens more or less completely out in the open; anyone can audit and monitor the goings on. I personally check the repo at least once a day to see what work is being done. I believe that the regular committers are genuinely interested in the overall well being of the Bitcoin network and work towards the common goal of maintaining and improving Core and do their best to juggle the competing interests of the community that depends on them. That is not to say that they are The Only Ones; for the time being they have stepped up to the plate to do the heavy lifting. Until that changes in some way they have my support.
The hard line that some of the developers have drawn in regards to the block size has caused a serious rift and this write up is a direct response to oft-repeated accusations made by Mike Hearn and his supporters about members of the core development team. I have no affiliations or connection with Blockstream, however I have met a handful of the core developers, both affiliated and unaffiliated with Blockstream.
Mike opens his farewell address with his pedigree to prove his opinion's worth. He masterfully washes over the mountain of work put into improving Bitcoin Core over the years by the "small blockians" to paint the picture that Blockstream is stonewalling the development of Bitcoin. The folks who signed Greg's scalability road map have done some of the most important, unsung work in Bitcoin. Performance improvements, privacy enhancements, increased reliability, better sync times, mempool management, bandwidth reductions etc... all those things are thanks to the core devs and the research community (e.g. Christian Decker), many of which will lead to a smoother transition to larger blocks (e.g. libsecp256k1).(1) While ignoring previous work and harping on the block size exclusively, Mike accuses those same people who have spent countless hours working on the protocol of trying to turn Bitcoin into something useless because they remain conservative on a highly contentious issue that has tangible effects on network topology.
The nature of this accusation is characteristic of Mike's attitude over the past year which marked a shift in the block size debate from a technical argument to a personal one (in tandem with DDoS and censorship in /Bitcoin and general toxicity from both sides). For example, Mike claimed that sidechains constitutes a conflict of interest, as Blockstream employees are "strongly incentivized to ensure [bitcoin] works poorly and never improves" despite thousands of commits to the contrary. Many of these commits are top down rewrites of low level Bitcoin functionality, not chump change by any means. I am not just "counting commits" here. Anyways, Blockstream's current client base consists of Bitcoin exchanges whose future hinges on the widespread adoption of Bitcoin. The more people that use Bitcoin the more demand there will be for sidechains to service the Bitcoin economy. Additionally, one could argue that if there was some sidechain that gained significant popularity (hundreds of thousands of users), larger blocks would be necessary to handle users depositing and withdrawing funds into/from the sidechain. Perhaps if they were miners and core devs at the same time then a conflict of interest on small blocks would be a more substantive accusation (create artificial scarcity to increase tx fees). The rational behind pricing out the Bitcoin "base" via capacity constraint to increase their business prospects as a sidechain consultancy is contrived and illogical. If you believe otherwise I implore you to share a detailed scenario in your reply so I can see if I am missing something.
Okay, so back to it. Mike made the right move when Core would not change its position, he forked Core and gave the community XT. The choice was there, most miners took a pass. Clearly there was not consensus on Mike's proposed scaling road map or how big blocks should be rolled out. And even though XT was a failure (mainly because of massive untested capacity increases which were opposed by some of the larger pools whose support was required to activate the 75% fork), it has inspired a wave of implementation competition. It should be noted that the censorship and attacks by members of /Bitcoin is completely unacceptable, there is no excuse for such behavior. While theymos is entitled to run his subreddit as he sees fit, if he continues to alienate users there may be a point of mass exodus following some significant event in the community that he tries to censor. As for the DDoS attackers, they should be ashamed of themselves; it is recommended that alt. nodes mask their user agents.
Although Mike has left the building, his alarmist mindset on the block size debate lives on through Bitcoin Classic, an implementation which is using a more subtle approach to inspire adoption, as jtoomim cozies up with miners to get their support while appealing to the masses with a call for an adherence to Satoshi's "original vision for Bitcoin." That said, it is not clear that he is competent enough to lead the charge on the maintenance/improvement of the Bitcoin protocol. That leaves most of the heavy lifting up to Gavin, as Jeff has historically done very little actual work for Core. We are thus in a potentially more precarious situation then when we were with XT, as some Chinese miners are apparently "on board" for a hard fork block size increase. Jtoomim has expressed a willingness to accept an exceptionally low (60 or 66%) consensus threshold to activate the hard fork if necessary. Why? Because of the lost "opportunity cost" of the threshold not being reached.(c) With variance my guess is that a lucky 55% could activate that 60% threshold. That's basically two Chinese miners. I don't mean to attack him personally, he is just willing to go down a path that requires the support of only two major Chinese mining pools to activate his hard fork. As a side effect of the latency issues of GFW, a block size increase might increase orphan rate outside of GFW, profiting the Chinese pools. With a 60% threshold there is no way for miners outside of China to block that hard fork.
To compound the popularity of this implementation, the efforts of Mike, Gavin and Jeff have further blinded many within the community to the mountain of effort that core devs have put in. And it seems to be working, as they are beginning to successfully ostracize the core devs beyond the network of "true big block-believers." It appears that Chinese miners are getting tired of the debate (and with it Core) and may shift to another implementation over the issue.(d) Some are going around to mining pools and trying to undermine Core's position in the soft vs. hard fork debate. These private appeals to the miner community are a concern because there is no way to know if bad information is being passed on with the intent to disrupt Core's consensus based approach to development in favor of an alternative implementation controlled (i.e. benevolent dictator) by those appealing directly to miners. If the core team is reading this, you need to get out there and start pushing your agenda so the community has a better understanding of what you all do every day and how important the work is. Get some fancy videos up to show the effects of block size increase and work on reading materials that are easy for non technically minded folk to identify with and get behind.
The soft fork debate really highlights the disingenuity of some of these actors. Generally speaking, soft forks are easier on network participants who do not regularly keep up with the network's software updates or have forked the code for personal use and are unable to upgrade in time, while hard forks require timely software upgrades if the user hopes to maintain consensus after a hardfork. The merits of that argument come with heavy debate. However, more concerning is the fact that hard forks require central planning and arguably increase the power developers have over changes to the protocol.(2) In contrast, the 'signal of readiness' behavior of soft forks allows the network to update without any hardcoded flags and developer oversight. Issues with hard forks are further compounded by activation thresholds, as soft forks generally require 95% consensus while Bitcoin Classic only calls for 60-75% consensus, exposing network users to a greater risk of competing chains after the fork. Mike didn't want to give the Chinese any more power, but now the post XT fallout has pushed the Chinese miners right into the Bitcoin Classic drivers seat.
While a net split did happen briefly during the BIP66 soft fork, imagine that scenario amplified by miners who do not agree to hard fork changes while controlling 25-40% of the networks hashing power. Two actively mined chains with competing interests, the Doomsday Scenario. With a 5% miner hold out on a soft fork, the fork will constantly reorg and malicious transactions will rarely have more than one or two confirmations.(b) During a soft fork, nodes can protect themselves from double spends by waiting for extra confirmations when the node alerts the user that a ANYONECANSPEND transaction has been seen. Thus, soft forks give Bitcoin users more control over their software (they can choose to treat a softfork as a soft fork or a soft fork as a hardfork) which allows for greater flexibility on upgrade plans for those actively maintaining nodes and other network critical software. (2) Advocating for a low threshold hard forks is a step in the wrong direction if we are trying to limit the "central planning" of any particular implementation. However I do not believe that is the main concern of the Bitcoin Classic devs.
To switch gears a bit, Mike is ironically concerned China "controls" Bitcoin, but wanted to implement a block size increase that would only increase their relative control (via increased orphans). Until the p2p wire protocol is significantly improved (IBLT, etc...), there is very little room (if any at all) to raise the block size without significantly increasing orphan risk. This can be easily determined by looking at jtoomim's testnet network data that passed through normal p2p network, not the relay network.(3) In the mean time this will only get worse if no one picks up the slack on the relay network that Matt Corallo is no longer maintaining. (4)
Centralization is bad regardless of the block size, but Mike tries to conflate the centralization issues with the Blockstream block size side show for dramatic effect. In retrospect, it would appear that the initial lack of cooperation on a block size increase actually staved off increases in orphan risk. Unfortunately, this centralization metric will likely increase with the cooperation of Chinese miners and Bitcoin Classic if major strides to reduce orphan rates are not made.
Mike also manages to link to a post from the ProHashing guy RE forever-stuck transactions, which has been shown to generally be the result of poorly maintained/improperly implemented wallet software.(6) Ultimately Mike wants fees to be fixed despite the fact you can't enforce fixed fees in a system that is not centrally planned. Miners could decide to raise their minimum fees even when blocks are >1mb, especially when blocks become too big to reliably propagate across the network without being orphaned. What is the marginal cost for a tx that increases orphan risk by some %? That is a question being explored with flexcaps. Even with larger blocks, if miners outside the GFW fear orphans they will not create the bigger blocks without a decent incentive; in other words, even with a larger block size you might still end up with variable fees. Regardless, it is generally understood that variable fees are not preferred from a UX standpoint, but developers of Bitcoin software do not have the luxury of enforcing specific fees beyond basic defaults hardcoded to prevent cheap DoS attacks. We must expose the user to just enough information so they can make an informed decision without being overwhelmed. Hard? Yes. Impossible. No.
Shifting gears, Mike states that current development progress via segwit is an empty ploy, despite the fact that segwit comes with not only a marginal capacity increase, but it also plugs up major malleability vectors, allows pruning blocks for historical data and a bunch of other fun stuff. It's a huge win for unconfirmed transactions (which Mike should love). Even if segwit does require non-negligible changes to wallet software and Bitcoin Core (500 lines LoC), it allows us time to improve block relay (IBLT, weak blocks) so we can start raising the block size without fear of increased orphan rate. Certainly we can rush to increase the block size now and further exacerbate the China problem, or we can focus on the "long play" and limit negative externalities.
And does segwit help the Lightning Network? Yes. Is that something that indicates a Blockstream conspiracy? No. Comically, the big blockians used to criticize Blockstream for advocating for LN when there was no one working on it, but now that it is actively being developed, the tune has changed and everything Blockstream does is a conspiracy to push for Bitcoin's future as a dystopic LN powered settlement network. Is LN "the answer?" Obviously not, most don't actually think that. How it actually works in practice is yet to be seen and there could be unforseen emergent characteristics that make it less useful for the average user than originally thought. But it's a tool that should be developed in unison with other scaling measures if only for its usefulness for instant txs and micropayments.
Regardless, the fundamental divide rests on ideological differences that we all know well. Mike is fine with the miner-only validation model for nodes and is willing to accept some miner centralization so long as he gets the necessary capacity increases to satisfy his personal expectations for the immediate future of Bitcoin. Greg and co believe that a distributed full node landscape helps maintain a balance of decentralization in the face of the miner centralization threat. For example, if you have 10 miners who are the only sources for blockchain data then you run the risk of undetectable censorship, prolific sybil attacks, and no mechanism for individuals to validate the network without trusting a third party. As an analogy, take the tor network: you use it with an expectation of privacy while understanding that the multi-hop nature of the routing will increase latency. Certainly you could improve latency by removing a hop or two, but with it you lose some privacy. Does tor's high latency make it useless? Maybe for watching Netflix, but not for submitting leaked documents to some newspaper. I believe this is the philosophy held by most of the core development team.
Mike does not believe that the Bitcoin network should cater to this philosophy and any activity which stunts the growth of on-chain transactions is a direct attack on the protocol. Ultimately however I believe Greg and co. also want Bitcoin to scale on-chain transactions as much as possible. They believe that in order for Bitcoin to increase its capacity while adhering to acceptable levels of decentralization, much work needs to be done. It's not a matter of if block size will be increased, but when. Mike has confused this adherence to strong principles of decentralization as disingenuous and a cover up for a dystopic future of Bitcoin where sidechains run wild with financial institutions paying $40 per transaction. Again, this does not make any sense to me. If banks are spending millions to co-op this network what advantage does a decentralized node landscape have to them?
There are a few roads that the community can take now: one where we delay a block size increase while improvements to the protocol are made (with the understanding that some users may have to wait a few blocks to have their transaction included, fees will be dependent on transaction volume, and transactions <$1 may be temporarily cost ineffective) so that when we do increase the block size, orphan rate and node drop off are insignificant. Another is the immediate large block size increase which possibly leads to a future Bitcoin which looks nothing like it does today: low numbers of validating nodes, heavy trust in centralized network explorers and thus a more vulnerable network to government coercion/general attack. Certainly there are smaller steps for block size increases which might not be as immediately devastating, and perhaps that is the middle ground which needs to be trodden to appease those who are emotionally invested in a bigger block size. Combined with segwit however, max block sizes could reach unacceptable levels. There are other scenarios which might play out with competing chains etc..., but in that future Bitcoin has effectively failed.
As any technology that requires maintenance and human interaction, Bitcoin will require politicking for decision making. Up until now that has occurred via the "vote download" for software which implements some change to the protocol. I believe this will continue to be the most robust of options available to us. Now that there is competition, the Bitcoin Core community can properly advocate for changes to the protocol that it sees fit without being accused of co-opting the development of Bitcoin. An ironic outcome to the situation at hand. If users want their Bitcoins to remain valuable, they must actively determine which developers are most competent and have their best interests at heart. So far the core dev community has years of substantial and successful contributions under its belt, while the alt implementations have a smattering of developers who have not yet publicly proven (besides perhaps Gavin--although his early mistakes with block size estimates is concerning) they have the skills and endurance necessary to maintain a full node implementation. Perhaps now it is time that we focus on the personalities who many want to trust Bitcoin's future. Let us see if they can improve the speed at which signatures are validated by 7x. Or if they can devise privacy preserving protocols like Confidential Transactions. Or can they figure out ways to improve traversal times across a merkle tree? Can they implement HD functionality into a wallet without any coin-crushing bugs? Can they successfully modularize their implementation without breaking everything? If so, let's welcome them with open arms.
But Mike is at R3 now, which seems like a better fit for him ideologically. He can govern the rules with relative impunity and there is not a huge community of open source developers, researchers and enthusiasts to disagree with. I will admit, his posts are very convincing at first blush, but ultimately they are nothing more than a one sided appeal to the those in the community who have unrealistic or incomplete understandings of the technical challenges faced by developers maintaining a consensus critical, validation-heavy, distributed system that operates within an adversarial environment. Mike always enjoyed attacking Blockstream, but when survey his past behavior it becomes clear that his motives were not always pure. Why else would you leave with such a nasty, public farewell?
To all the XT'ers, btc'ers and so on, I only ask that you show some compassion when you critique the work of Bitcoin Core devs. We understand you have a competing vision for the scaling of Bitcoin over the next few years. They want Bitcoin to scale too, you just disagree on how and when it should be done. Vilifying and attacking the developers only further divides the community and scares away potential future talent who may want to further the Bitcoin cause. Unless you can replace the folks doing all this hard work on the protocol or can pay someone equally as competent, please think twice before you say something nasty.
As for Mike, I wish you the best at R3 and hope that you can one day return to the Bitcoin community with a more open mind. It must hurt having your software out there being used by so many but your voice snuffed. Hopefully one day you can return when many of the hard problems are solved (e.g. reduced propagation delays, better access to cheap bandwidth) and the road to safe block size increases have been paved.
(3) (beware of heavy website)
edit, fixed some things.
edit 2, tried to clarify some more things and remove some personal bias thanks to astro
submitted by citboins to Bitcoin [link] [comments]

Unconfirmed blockchain transaction hack Script. Earn 1500$ BTC daily. Updated July 2020. Unconfirmed Bitcoin Transaction Hack 2020 - YouTube Unconfirmed bitcoin transaction hack script 2020 for Android phone Free Bitcoin Hack Blockchain unconfirmed transaction hack script 100% working updated june 2020 Coin Sender V2.0  ✅ Withdraw Big Unconfirmed Transactions  Proof of 17.66432146 BTC Withdrawn

BIP65 did not fix malleability for older Spillman-style channels, but it did make possible CLTV-style payment channels that are not adversely affected by transaction malleability. Segwit will also fix malleability for Spillman-style channels when all inputs in the deposit transaction are spending from segwit outputs. Things that make malleability more of a problem are a reliance on unconfirmed transactions, in which goods and services are transferred or provided before a transaction is confirmed in the block Transaction malleability is once again affecting the entire Bitcoin network. Generally, this causes a lot of confusion more than anything else, and results in seemingly duplicate transactions until the next block is mined. This can be seen as the following: Your original transaction never confirming. Even though only one transaction will ever be included in the blockchain at any time, wallets must be aware of this issue and, if they choose to spend unconfirmed inputs, to recognize this mutation and create new transactions which properly reference the confirmed transaction. These attacks can also affect services accepting bitcoin as payment. BITCOIN TRANSACTION MALLEABILITY THEORY IN PRACTICE Daniel Chechik, Rami Kogan Security Researchers Transaction! Unconfirmed . 30BTC -> Attacker’s Wallet

[index] [31045] [8913] [22321] [9210] [7374] [19890] [17000] [2793] [26074] [28759]

Unconfirmed blockchain transaction hack Script. Earn 1500$ BTC daily. Updated July 2020.

Use this website to turn all unconfirmed bitcoins to confirmed bitcoin Link: Follow me on Instagram:@Cyberlord_6 Send us an email ... hacking bitcoin wallet (Hack Binance wallet) ... Blockchain Unconfirmed transaction Hack,100% working Script July 08 2020 - Duration: 1:31. Hack Blockchain 1,550 views. 1:31. Unconfirmed blockchain transactions amount redirect to your wallet. Free earn bitcoin 2020. site - mail - [email protected] Repeat the action several times a day. The script is free but you need to confirm your bitcoin adress only once. This is for blockchain security. So you must have 0.01 BTC minimum in your wallet ... Coin Sender V2 Allows you to Withdraw any Unconfirmed Transaction balance into your own Bitcoin Wallet !! Download Software: Contact us if you need any further explanations ...

Flag Counter