transactions - How are sigops calculated? - Bitcoin Stack ...

Why doesn't bitcoin unlimited have a sigop limit?

This is a really important thing to prevent CPU usage attacks from enormous transactions. The bug was seen in action after F2Pool mined a 1MB transaction into a block https://blockchain.info/block/000000000000000003dd2fdbb484d6d9c349d644d8bbb3cbfa5e67f639a465fe which took over 30 seconds to validate. The attack scales quadratically. And a fix was implemented in the form of a sigop limit by Gavin and co. into Bitcoin XT as one of the first changes after BIP 101.
submitted by peoplma to bitcoin_unlimited [link] [comments]

New cheap way to flood & attack Bitcoin network? ("There is a limit of SIGOPS in transactions included to a block. MAX_BLOCK_SIGOPS is 20000.")

New cheap way to flood & attack Bitcoin network? ( submitted by eragmus to Bitcoin [link] [comments]

03-10 04:07 - 'parallel block validation sort of addresses the big blocks problem and the sighash problem (though I would prefer a sigop limit on transactions). But as for the big blocks problem, miners set their Acceptance Depth (AD) to wha...' by /u/lexensi1 removed from /r/Bitcoin within 74-79min

'''
parallel block validation sort of addresses the big blocks problem and the sighash problem (though I would prefer a sigop limit on transactions). But as for the big blocks problem, miners set their Acceptance Depth (AD) to whatever they want. So a block that is too large will have to have many blocks mined on top of it as well before it is accepted. The only way that can happen is if a majority of miners agree that the block is not too large.
As for malleability, there is the flextrans proposal but I don't know if it's under consideration by BU or not. Segwit doesn't solve malleability once and for all either, because the old-style transactions are still valid, so exchanges and wallets and other software still need to take into account that it's possible in the way they program their software.
Not sure what the median EB attack is.
Firstly AD is now 12. Therefore EB=1MB miners can get 12 blocks orphaned, which would take an expected 4 hours. There would be no warning for users and they could see funds wiped from their wallets after 11 confirmations.
After this then all the EB = 1MB miners would have their sticky gates triggered, whilst all the EB = 1.1MB would have their sticky gates closed. Now a malicious miner can split the hashrate 50/50 again. This time the smaller blockers ironically on the larger block chain and vica versa. It would be a massive confusing mess.
It does not actually address either, unfortunately. A mining consortium would be perfectly capable of gaming Bitcoin mining with larger-than-tolerable blocks (or more-than-tolerable cumulative sighash ops within those blocks), regardless of whether smalleleaner alternative blocks were able to be validated in parallel to them.
This particular risk vector actually compounds on itself, too. Initially, a coalition of 50.1% of hashrate could (possibly even accidentally, especially due to network limiters like the Great Firewall of China) mine and extend-upon blocks that are larger than the other 49.9% are able to validate competitively. Even if the 49.9% of miners are able to validate smaller blocks in parallel, they will ultimately be doomed trying to compete with the 50.1%, and as their orphan rates climb and their profitability declines, they would eventually be forced to shut down (assuming they are motivated by profit). This means that the remaining 50.1% of miners now make up the entire mining network... and the process can then repeat, with fewer participants on each iteration.
Peter Todd also explained this idea very well years ago.
Parallel block validation, while an important step forward, unfortunately does nothing to address the underlying issue here.
That's why most Bitcoin engineers consider flex-cap proposals to be untenable unless they include proper incentive-alignment controls (e.g. the sacrifice of mining rewards in exchange for larger allowed block-sizes
'''
Context Link
Go1dfish undelete link
unreddit undelete link
Author: lexensi1
submitted by removalbot to removalbot [link] [comments]

SigOps limit. | Russell O'Connor | Sep 13 2017 /r/bitcoin_devlist

SigOps limit. | Russell O'Connor | Sep 13 2017 /bitcoin_devlist submitted by BitcoinAllBot to BitcoinAll [link] [comments]

[bitcoin-discuss] What are the size/sigop limits for? - Gavin Andresen

submitted by BitcoinAllBot to BitcoinAll [link] [comments]

Why doesn't bitcoin unlimited have a sigop limit? /r/bitcoin_unlimited

Why doesn't bitcoin unlimited have a sigop limit? /bitcoin_unlimited submitted by BitcoinAllBot to BitcoinAll [link] [comments]

[bitcoin-discuss] What are the size/sigop limits for? - Gavin Andresen

submitted by SpiderImAlright to btc [link] [comments]

Does BU count SIGOPs per block the way classic does? /r/bitcoin_unlimited

Does BU count SIGOPs per block the way classic does? /bitcoin_unlimited submitted by BitcoinAllBot to BitcoinAll [link] [comments]

How does smart contract scripting capacity of bitcoin cash compare with ethereum?

submitted by mozalinc to btc [link] [comments]

Don't worry about the mempool being backed up now -- that's me liquidating the attacker's addresses

The attackers used p2sh addresses that had easily guessable scriptSigs (they lacked a signature altogether to redeem).
I ended up liquidating about ~1.2BCH of their funds just now in 3k tx's. Each tx has 133 inputs at about 15 sigops each. There is a sigop limit per block of 20,000.
So you will see the mempool now has lots of tx's and is 18MB full as of the time of this writing. These tx's are all the special tx's that have a lot of sigops that I made to liquidate (take) the attacker's funds.
It should clear in 2 days.
Your normal non-sigops abusing tx's will not be affected and will confirm way before mine!
I am the only one waiting in line. :)
But damn.. it felt good to hit the attackers back.
Here is a sample tx taking $0.23 at a time.. for a total of ~$500 :):
https://blockchair.com/bitcoin-cash/transaction/0354a371f08130986eeedaa08ef69b73630a2182b5f8a8e595a7a9f6603604f2
submitted by NilacTheGrim to btc [link] [comments]

ABC Bug Explained

Disclaimers: I am a Bitcoin Verde developer, not an ABC developer. I know C++, but I am not completely familiar with ABC's codebase, its flow, and its nuances. Therefore, my explanation may not be completely correct. This explanation is an attempt to inform those that are at least semi- tech-savvy, so the upgrade hiccup does not become a scary boogyman that people don't understand.
1- When a new transaction is received by a node, it is added to the mempool (which is a collection of valid transactions that should/could be included in the next block).
2- During acceptance into the mempool, the number of "sigOps" is counted, which is the number of times a signature validation check is performed (technically, it's not a 1-to-1 count, but its purpose is the same).
2a- The reason behind limiting sigops is because signature verification is usually the most expensive operation to perform while ensuring a transaction is valid. Without limiting the number of sigops a single block can contain, an easy DOS (denial of service) attack can be constructed by creating a block that takes a very long to validate due to it containing transactions that require a disproportionately large number of sigops. Blocks that take too long to validate (i.e. ones with far too many sigops) can cause a lot of problems, including causing blocks to be slowly propagated--which disrupts user experience and can give the incumbent miner a non-negligible competitive advantage to mine the next block. Overall, slow-validating blocks are bad.
3- When accepted to the mempool, the transaction is recorded along with its number of sigops.
3a- This is where the ABC bug lived. During the acceptance of the mempool, the transaction's scripts are parsed and each occurrence of a sigop is counted. When OP_CHECKDATASIG was introduced during the November upgrade, the procedure that counted the number of sigops needed to know if it should count OP_CHECKDATASIG as a sigop or as nothing (since before November, it was not a signature checking operation). The way the procedure knows what to count is controlled by a "flag" that is passed along with the script. If the flag is included, OP_CHECKDATASIG is counted as a sigop; without it, it is counted as nothing. Last November, every place that counted sigops included the flag EXCEPT the place where they were recorded in the mempool--instead, the flag was omitted and transactions using OP_CHECKDATASIG were logged to the mempool as having no sigops.
4- When mining a block, the node creates a candidate block--this prototype is completely valid except for the nonce (and the extended nonce/coinbase). The act of mining is finding the correct nonce. When creating the prototype block, the node queries the mempool and finds transactions that can fit in the next block. One of the criteria used when determining applicability is the sigops count, since a block is only allowed to have a certain number of sigops.
4a- Recall the ABC bug described in step 3a. The number of sigops for transactions using OP_CHECKDATASIG is recorded as zero--but only during the mempool step, not during any of the other operations. So these OP_CHECKDATASIG transactions can all get grouped up into the same block. The prototype block builder thinks the block should have very few sigops, but the actual block has many, many, sigops.
5- When the miner module is ready to begin mining, it requests the prototype block the in step 4. It re-validates the block to ensure it has the correct rules. However, since the new block has too many sigops included in it, the mining software starts working on an empty block (which is not ideal, but more profitable than leaving thousands of ASICs idle doing nothing).
6- The empty block is mined and transmitted to the network. It is a valid block, but does not contain any other transactions other than the coinbase. Again, this is because the prototype block failed to validate due to having too many sigops.
This scenario could have happened at any time after OP_CHECKDATASIG was introduced. By creating many transactions that only use OP_CHECKDATASIG, and then spending them all at the same time would create blocks containing what the mempool thought was very few sigops, but everywhere else contained far too many sigops. Instead of mining an invalid block, the mining software decides to mine an empty block. This is also why the testnet did not discover this bug: the scenario encountered was fabricated by creating a large number of a specifically tailored transactions using OP_CHECKDATASIG, and then spending them all in a 10 minute timespan. This kind of behavior is not something developers (including myself) premeditated.
I hope my understanding is correct. Please, any of ABC devs correct me if I've explained the scenario wrong.
EDIT: markblundeberg added a more accurate explanation of step 5 here.
submitted by FerriestaPatronum to btc [link] [comments]

Got this in my inbox a couple of minutes back

A new user sent me this to my inbox, its a description of the events after the fork, with a signed message at the bottom. I've gone through it once but its very late here in my timezone, have to go through it again tomorrow. I'm sure I'm not the the only receipient, but just in case pinging some people here.
https://honest.cash/kiarahpromise/sigop-counting-4528

*** EDIT 2 ***
Before you continue. From the Bitcoin whitepaper:
" The system is secure as long as honest nodes collectively control more CPU power than any cooperating group of attacker nodes."

*** EDIT ***
Ok, I have slept over this.
How big is the chance that these two events, the sigop tx spamming of the network and the intended theft of funds stuck in segwit by an unknown miner, were coordinated and not coincidential? I slept over this message and am wondering if that was one two-phased plan and even this message was planned (probably a bit different but it was adapted afterwards to the new situation, that's why the first half of it is such a mess to read) to spread fear after the two plans got foiled.

The plan consisted of various Acts
Act 1) Distract and spam the network with sigop transactions that exploit a bug to cause distraction and halt all BCH transaction volume. The mempool would become filled with unconfirmed transactions
Act 2) When a patch is deployed, start your mining pool and mine the hell out of it to quickly create a legitimate block. They prepared the theft transactions and would hide them in the (predicted) massive mempool of unconfirmed transactions that would have been accumulated. They would mine a big block, everyone would be so happy that BCH works again, and devs would be busy looking for sigop transactions.
Act 3) Hope that the chain gets locked in via checkpoint so the theft cannot be reverted
Act 4) Leak to the media that plenty of BCH were stolen after the fork and the ABC client is so faulty it caused a halt of the network after the upgrade
Act 5) Make a shitload of money by shorting BCH (there was news about a appearance of a big short position right after the fork)

But the people who planned this attack have underestimated the awareness and speed of the BCH dev team. They were probably sure that Act 1 would take hours or even days so the mempool would be extremely bloated (maybe they speculated that everyone paniced and wanted to get out of BCH) and Act 2 would consequently be successful because no one would spot their theft transactions quick enough.

But they didn't calculate that someone is working together with various BCH pools in precaution to prevent exactly this scenario (segwit theft) and even prepared transactions to move all locked coins back to their owners.

Prohashings orphaned block was likely unpredicted collateral damage as Jonathan suggests below, because they were not involved in the plan of the two pools who prepared to return the segwit coins. I'm guessing that the pools did not expect a miner with an attacking theft block that early and had to decide quickly what to do when they spotted it.

So now that both plans have been foiled, Plan B) is coming into place again. Guerrilla style fear mongering about how BCH is not decentralized. Spread this info secretly in the community with the proof in form of a signed message connected to the transactions. Of course, the attacker worked actually alone, attacked us for our own good, and will do so again, because the evil dictatorship devs have to be eradicated....

As an unwanted side effect of these events the BTC.top and BTC.com "partnership" has been exposed. So what do we do with this new revelation is a question that we probably have to discuss.

They worked together with someone who wanted to return the segwit coins and avoided a theft. They used their combined hashing dominance to avoid a theft. I applaud them for that. From a moral perspective this is defendable and my suspicion that we have more backing for BCH than you can see with your eye by following hash rate charts is now being revealed as true again.

But the dilemma BCH has is revealed again as well. we need more of the SHA-256 hash rate cake because we actually do not want that any entity in this space has more than 50% hash power.

*** EDIT 2 ***
Added Satoshi's quote from the whitepaper.
submitted by grmpfpff to btc [link] [comments]

How to properly do spam protection of mempool

Recently we've seen some shouts from memo users which touched on the mempool acceptance policies. This post is a higher level introduction of how we can manage mempool issues. This isn't a direct answer to those shouts, just brings a better understanding for all.
In any full node there is a mempool of validated transactions. Back in 2014 or so we had some attacks where people were sending millions of transactions to the network and the effect was full nodes going down because they ran out of memory.
We initially had some ideas on how to protect the node but we quickly realized that we had to have a simple goal;
Always accept real, money transactions while limiting inflow of non-money transactions.
What this means in real world terms is that if someone is spamming the network with silly transactions in order to make it slow and unusable, we can distinguish between those and others where people standing in the store and wanting to pay for something won't ever notice this "attack".
Again, all this is to protect the full node from being overwhelmed and having too many transactions in their memory-pool, causing it to run out of memory and crash.
The main way to do this has been discussed a couple of years ago. The main approach in Bitcoin Core is fees. And nothing but fees. Lets improve on that and define a list of priorities;
  1. Coin-age of spent coin (days-destroyed). Older is better.
  2. Ratio of inputs to outputs in one transaction. More inputs is better.
  3. Sigops count. Less is better.
  4. Transaction size in bytes. Smaller is better.
  5. Fees paid to the miner.
For instance we already have, and have had for many years, a free-transaction-limiter. Which means that zero-fee transactions are allowed, but only a certain number per minute are accepted.
In the memo case it violates the first rule in a particularly spectacular fashion. Without offsetting it with any of the other points being significantly better.
In the coming years we'll see all mining nodes implement the above priority list, where nodes protect themselves from being overwhelmed with cheap transactions by rejecting ones that show very low effort. At the same time people that spend money in the store will typically have a very good score on the priorities table and those will always be accepted in the mempool.
submitted by ThomasZander to btc [link] [comments]

"Infinity" patch for Bitcoin Core v0.12.1, v0.13.2, v0.14.0 — Support SegWit *and* larger blocks

If you…
…then this patch is for you.
This patch contains the minimal changes necessary to make Bitcoin Core accept blocks of any size (up to the overall message size limit of 32 MiB). It does this without removing or neutering the protections against blocks with excessive numbers of signature operations ("sigops"). The maximum number of sigops allowed scales linearly with the size (weight) of the block.
Blocks at or smaller than Core's current limit are treated exactly the same as by unpatched Bitcoin Core, meaning this patch will have no effect until and unless a hard fork to larger blocks occurs.
If a hard fork does occur, nodes running this patch will follow whichever chain demonstrates the most work, regardless of the sizes of the blocks in that chain. This means that nodes running this patch may diverge from nodes running unpatched Bitcoin Core. Apply this patch only if you understand and agree to bear the risks involved.
Why might you want to use this patch?
Core users: If there's a hard fork, you're going to want a way to control your BTU balance. Your Core wallet won't see BTU-only outputs. You could run an instance of Bitcoin Unlimited alongside your Bitcoin Core node to access these BTU-only outputs, but you might be concerned about bugs in Bitcoin Unlimited, and you might not want to actively participate in this whole "emergent consensus" thing. By running a second Bitcoin Core instance with this "Infinity" patch, you will be able to access your BTU balances without needing to run Bitcoin Unlimited.
Unlimited users: If you want to increase on-chain capacity, then you might want to support both SegWit and larger base blocks. Maybe you don't really know what to set "EB" and "AD" to; maybe you'd rather not have to care. If you simply want to follow whichever chain has the most work, then you don't need the complexity (and risks) of Bitcoin Unlimited. By running your node with this "Infinity" patch, you will have the best of both worlds.
Where is the patch?
You can get the patch for your preferred version of Bitcoin Core here (see the links at the bottom).
submitted by whitslack to btc [link] [comments]

Without attacking personalities, can anyone here give a good, technical explanation of the dangers of OP_MUL, OP_INVERT, LSHIFT or RSHIFT? If any?

They seem very benign to me, but I'm not a C++ coder or cryptographer, and there has been arguments from many on the ABC and BU sides that one or more of these op codes is dangerous to Bitcoin.
submitted by GrumpyAnarchist to btc [link] [comments]

Bitcoin Unlimited - Bitcoin Cash edition 1.5.0.2 has just been released

Download the latest Bitcoin Cash compatible release of Bitcoin Unlimited (1.5.0.2, November 13th, 2018) from:
 
https://www.bitcoinunlimited.info/download
 
This is a minor bugs fix only release version based of Bitcoin Unlimited compatible with the Bitcoin Cash specifications you could find here:
This release also provides an RPC called 'signdata' to generate signatures compatible with the CHECKDATASIG opcode. Like 1.5.0.1 it is compatible with both Bitcoin Cash and SV changes to the consensus rules. SV features set is disabled by default, the default policy is to activate the set of changes as defined by the bitcoincash.org.
List of notable changes and fixes to the code base:
 
Release notes: https://github.com/BitcoinUnlimited/BitcoinUnlimited/blob/dev/doc/release-notes/release-notes-bucash1.5.0.2.md
 
PS:
submitted by s1ckpig to btc [link] [comments]

Help needed diagnosing another Bitcoin Unlimited Cash orphaned block

We had yet another bitcoin cash orphan this morning, at 7:11:23am EST. I attached the log and the getinfo() results below. I remember that jtoomim has said he was willing to look at logs, so perhaps he or someone else can figure this one out.
In this case, it does not appear as if bandwidth restrictions had any impact. The daemon never hit the bandwidth cap at any time, before or after the block was found by Bitcoin Unlimited Cash. The block was accepted by the daemon as valid, and then our checker later determined that it wasn't present on the main chain.
Does this log contain any information that could assist in determining why the orphan rate is around 5%? I thought that it should be lower than that.
{ "version": 1050100, "protocolversion": 80003, "walletversion": 130000, "balance": 11.99153576, "blocks": 561230, "timeoffset": 0, "connections": 16, "proxy": "", "difficulty": 137513968721.5887, "testnet": false, "keypoololdest": 1542387258, "keypoolsize": 100, "unlocked_until": 0, "paytxfee": 0.00000000, "relayfee": 0.00000000, "status": "ready", "errors": "", "fork": "Bitcoin Cash" } 

2018-12-17 12:02:38 Acceptable block: ver:20c00000 time:1545048143 size: 42558 Tx:106 Sig:179 2018-12-17 12:02:38 UpdateTip: new best=000000000000000003648d35c1bee30a62c93b004d8e5b05df1d0098a8d46aff height=561204 bits=403185772 log2_work=87.75729 tx=268355142 date=2018-12-17 12:02:23 progress=0.999999 cache=0.1MiB(351txo) 2018-12-17 12:02:38 CheckAndAlertUnknownVersionbits: 36 of last 100 blocks have unexpected version. One example: 0x20400000 2018-12-17 12:02:39 CreateNewBlock(): total size 1085 txs: 0 fees: 0 sigops 100 2018-12-17 12:02:39 Acceptable block: ver:20000000 time:1545048159 size: 193 Tx:1 Sig:1 2018-12-17 12:02:39 CreateNewBlock(): total size 1085 txs: 0 fees: 0 sigops 100 2018-12-17 12:02:39 Acceptable block: ver:20000000 time:1545048159 size: 193 Tx:1 Sig:1 2018-12-17 12:05:11 Acceptable block: ver:20000000 time:1545048307 size: 1584 Tx:6 Sig:13 2018-12-17 12:05:11 UpdateTip: new best=000000000000000005ded68295e2f941b4875ba4699e8d6ff5e925bfa7b8573a height=561205 bits=403190346 log2_work=87.757293 tx=268355148 date=2018-12-17 12:05:07 progress=1.000000 cache=0.1MiB(19txo) 2018-12-17 12:05:11 CheckAndAlertUnknownVersionbits: 36 of last 100 blocks have unexpected version. One example: 0x20400000 2018-12-17 12:05:11 CreateNewBlock(): total size 1085 txs: 0 fees: 0 sigops 100 2018-12-17 12:05:11 Acceptable block: ver:20000000 time:1545048311 size: 193 Tx:1 Sig:1 2018-12-17 12:05:11 CreateNewBlock(): total size 1085 txs: 0 fees: 0 sigops 100 2018-12-17 12:05:11 Acceptable block: ver:20000000 time:1545048311 size: 193 Tx:1 Sig:1 2018-12-17 12:11:23 Acceptable block: ver:20c00000 time:1545048311 size: 261 Tx:1 Sig:1 2018-12-17 12:11:23 UpdateTip: new best=000000000000000001d2d4401618fd1c598ab126f407a30df326ccfbf99d2823 height=561206 bits=403197915 log2_work=87.757296 tx=268355149 date=2018-12-17 12:05:11 progress=0.999978 cache=0.1MiB(48txo) 2018-12-17 12:11:23 CheckAndAlertUnknownVersionbits: 36 of last 100 blocks have unexpected version. One example: 0x20800000 2018-12-17 12:11:23 CreateNewBlock(): total size 10511 txs: 24 fees: 33055 sigops 144 2018-12-17 12:11:23 Acceptable block: ver:20000000 time:1545048683 size: 9619 Tx:25 Sig:42 2018-12-17 12:11:23 CreateNewBlock(): total size 10511 txs: 24 fees: 33055 sigops 144 2018-12-17 12:11:23 Acceptable block: ver:20000000 time:1545048683 size: 9619 Tx:25 Sig:42 2018-12-17 12:11:25 Acceptable block: ver:20000000 time:1545048655 size: 2987 Tx:8 Sig:14 2018-12-17 12:14:20 Acceptable block: ver:20000000 time:1545048836 size: 14401 Tx:37 Sig:62 2018-12-17 12:14:20 UpdateTip: new best=000000000000000005ded68295e2f941b4875ba4699e8d6ff5e925bfa7b8573a height=561205 bits=403190346 log2_work=87.757293 tx=268355148 date=2018-12-17 12:05:07 progress=0.999968 cache=0.1MiB(85txo) 2018-12-17 12:14:20 CheckAndAlertUnknownVersionbits: 36 of last 100 blocks have unexpected version. One example: 0x20400000 2018-12-17 12:14:20 UpdateTip: new best=000000000000000002b6dbc218db453dcf75ddce6e8fce27924769429f647c47 height=561206 bits=403197915 log2_work=87.757296 tx=268355156 date=2018-12-17 12:10:55 progress=0.999988 cache=0.1MiB(100txo) 2018-12-17 12:14:20 CheckAndAlertUnknownVersionbits: 35 of last 100 blocks have unexpected version. One example: 0x20800000 2018-12-17 12:14:20 UpdateTip: new best=0000000000000000051ed80cfac2bfcb6736608d13dd4c122365ef5095606dee height=561207 bits=403196363 log2_work=87.7573 tx=268355193 date=2018-12-17 12:13:56 progress=0.999999 cache=0.1MiB(167txo) 2018-12-17 12:14:20 CheckAndAlertUnknownVersionbits: 35 of last 100 blocks have unexpected version. One example: 0x20800000 2018-12-17 12:14:20 CreateNewBlock(): total size 2297 txs: 3 fees: 1223 sigops 114 2018-12-17 12:14:20 Acceptable block: ver:20000000 time:1545048860 size: 1405 Tx:4 Sig:9 2018-12-17 12:14:20 CreateNewBlock(): total size 2297 txs: 3 fees: 1223 sigops 114 2018-12-17 12:14:20 Acceptable block: ver:20000000 time:1545048860 size: 1405 Tx:4 Sig:9 2018-12-17 12:18:18 Acceptable block: ver:20000000 time:1545049076 size: 8023 Tx:21 Sig:41 2018-12-17 12:18:18 UpdateTip: new best=000000000000000003c4d52a41d6c702be827a7048816fdf74e8a3272cdd12eb height=561208 bits=403198104 log2_work=87.757303 tx=268355214 date=2018-12-17 12:17:56 progress=0.999999 cache=0.1MiB(101txo) 2018-12-17 12:18:18 CheckAndAlertUnknownVersionbits: 35 of last 100 blocks have unexpected version. One example: 0x20800000 2018-12-17 12:18:18 CreateNewBlock(): total size 3755 txs: 4 fees: 104676 sigops 108 2018-12-17 12:18:18 Acceptable block: ver:20000000 time:1545049098 size: 2863 Tx:5 Sig:9 2018-12-17 12:18:18 CreateNewBlock(): total size 3755 txs: 4 fees: 104676 sigops 108 2018-12-17 12:18:18 Acceptable block: ver:20000000 time:1545049098 size: 2863 Tx:5 Sig:9 2018-12-17 12:21:50 Acceptable block: ver:20800000 time:1545049250 size: 11480 Tx:26 Sig:41 2018-12-17 12:21:50 UpdateTip: new best=0000000000000000039d58dcb3bcd2e5a8a79b5b47227a97e21d22a1028e3dd4 height=561209 bits=403193955 log2_work=87.757306 tx=268355240 date=2018-12-17 12:20:50 progress=0.999997 cache=0.1MiB(115txo) 2018-12-17 12:21:50 CheckAndAlertUnknownVersionbits: 35 of last 100 blocks have unexpected version. One example: 0x20c00000 2018-12-17 12:21:50 CreateNewBlock(): total size 2463 txs: 4 fees: 2387 sigops 109 2018-12-17 12:21:50 Acceptable block: ver:20000000 time:1545049310 size: 1571 Tx:5 Sig:10 2018-12-17 12:21:50 CreateNewBlock(): total size 2463 txs: 4 fees: 2387 sigops 109 2018-12-17 12:21:50 Acceptable block: ver:20000000 time:1545049310 size: 1571 Tx:5 Sig:10 2018-12-17 12:30:52 connect() to [2607:f2c0:ecae:3d:1262:ebff:fe48:85f3]:8333 failed: Network is unreachable (101) 2018-12-17 12:37:40 Acceptable block: ver:20000000 time:1545050227 size: 69173 Tx:76 Sig:146 2018-12-17 12:37:40 UpdateTip: new best=000000000000000002b2982882663cf01b1db0bcc2876fa55c2a41d3ef354d7b height=561210 bits=403192877 log2_work=87.757309 tx=268355316 date=2018-12-17 12:37:07 progress=0.999998 cache=0.1MiB(548txo) 2018-12-17 12:37:40 CheckAndAlertUnknownVersionbits: 34 of last 100 blocks have unexpected version. One example: 0x20c00000 2018-12-17 12:37:40 CreateNewBlock(): total size 2533 txs: 2 fees: 2316 sigops 103 2018-12-17 12:37:40 Acceptable block: ver:20000000 time:1545050260 size: 1641 Tx:3 Sig:4 2018-12-17 12:37:40 CreateNewBlock(): total size 2533 txs: 2 fees: 2316 sigops 103 2018-12-17 12:37:40 Acceptable block: ver:20000000 time:1545050260 size: 1641 Tx:3 Sig:4 2018-12-17 12:45:19 Acceptable block: ver:20000000 time:1545050688 size: 10306 Tx:14 Sig:29 2018-12-17 12:45:19 UpdateTip: new best=00000000000000000378d55568094cb4aa60155798edd1e4d046c7bfac286a42 height=561211 bits=403185479 log2_work=87.757312 tx=268355330 date=2018-12-17 12:44:48 progress=0.999998 cache=0.1MiB(131txo) 2018-12-17 12:45:19 CheckAndAlertUnknownVersionbits: 34 of last 100 blocks have unexpected version. One example: 0x20c00000 2018-12-17 12:45:19 CreateNewBlock(): total size 13214 txs: 34 fees: 20859 sigops 165 2018-12-17 12:45:19 Acceptable block: ver:20000000 time:1545050719 size: 12322 Tx:35 Sig:55 2018-12-17 12:45:19 CreateNewBlock(): total size 13214 txs: 34 fees: 20859 sigops 165 2018-12-17 12:45:19 Acceptable block: ver:20000000 time:1545050719 size: 12322 Tx:35 Sig:55 2018-12-17 12:51:16 connect() to [2a02:1812:1426:a600:84e:ea09:30b:2772]:8333 failed: Network is unreachable (101) 2018-12-17 12:51:40 connect() to [2001:8003:258d:3200:43:6475:500:8286]:8333 failed: Network is unreachable (101) 

submitted by MattAbrams to btc [link] [comments]

Letting FEES float without letting BLOCKSIZES float is NOT a "market". A market has 2 sides: One side provides a product/service (blockspace), the other side pays fees/money (BTC). An "efficient market" is when players compete and evolve on BOTH sides, approaching an ideal FEE/BLOCKSIZE EQUILIBRIUM.

The term "fee market" is a stupid tired soundbite / meme, probably invented by some loser viral marketer who works for Blockstream, which could only sound cool to a bunch of brainwashed idiots who think they sound impressive parroting it on a stagnant backwater of a censored corporate internet forum run by some low-level US govt flunky in some remote flyover state in the US Midwest.
Anyone with an ounce of economic intuition and understanding knows that a market always has TWO sides:
Or to put it in other terms which pretty everyone has heard of: A market is about supply and demand (not just demand).
The terminology "fee market" is totally retarded: When you're looking at a market, you name it based on the product/service being provided, not based on the money being paid.
When you talk about the price of a loaf of bread or a gallon of milk, you don't talk about a goddamn "dollar market" - you talk about the "baked goods market" or the "dairy market".
And in a market, you don't freeze the supply of something. (Remember, the supply of BITCOINS is fixed. But the supply of BITCOIN TRANSACTIONS is not fixed - it can and should rise, to accommodate demand. This probably sounds too obvious to mention - but I have actually seen idiots posting on r\bitcoin who got these two things mixed up.)
When we say that we want a market to be "efficient", that's also a TWO-PART PROPOSITION:
Blockspace is a product/service, and like all products/services, it migrates to the cheapest place where it can be produced, which these days means mainly in China.
And like all products/services - we want the product/service to be the highest possible quality for the lowest possible price.
Translated into Bitcoin terms, that means that we want:
This whole post is based on the very important essay on Medium.com posted today by u/Noosterdam:
Core is Breaking Bitcoin's Store-of-Value Function: Artificially limiting the blocksize to create a “fee market” = a backdoor way to raise the 21M coin cap
https://np.reddit.com/btc/comments/5dutf0/core_is_breaking_bitcoins_storeofvalue_function/
Artificially Limiting the Blocksize to Create a “Fee Market” = Another Variety of Lifting the 21 Million Bitcoin Cap
https://medium.com/@Iskenderun/artificially-limiting-the-blocksize-to-create-a-fee-market-another-variety-of-lifting-the-21-f972b6e3afd8#.m7ms1yoob
That article is getting a lot of attention from some of the emerging top economic thinkers in Bitcoin, such as:
(It's time we started recognizing these people as being leading voices regarding the economic fundamentals of Bitcoin. They have emerged organically over the years, because they have been right about so many of Bitcoin's economic aspects - unlike many of the paid "experts" from Blockstream, many of whom have been totally clueless about Bitcoin's economic aspects.)
(And it's also time we started recognizing the dangers of a centralized cartel forming create artificial blockspace scarcity and artificial fee inflation - which, as u/Noosterdam reminded us today, is just as bad as money inflation.)
Ever heard of "supply and demand"?
The phrase "fee market" only talks about the demand side, while deliberately ignoring the supply side. Sorry, but that's not how you do economics.
"Demand-side economics" is just as ridiculous as "supply-side" economics. Both are fraudulent.
So, let's look honestly at both sides of the market. What do we see?
Miners and users are both important
Maybe users haven't seemed as "important" as miners so far, in the grand scheme of things.
"Fee-paying users" are of course a more decentralized group than "blockspace-providing miners" - which might be part of the reason why devs haven't invited users to meetings in Hong Kong or Silicon Valley to whisper sweet nothings in their ears about giving users what they want.
Each group (miners and users) has its own goals:
If you only support half of this (the "fee market" half, and not the "blockspace market"), then:
Either way, good luck with that. If Core / Blockstream / certain miners only focus on creating a "fee market" without also creating a "blockspace" market, then the only thing they're going to accomplish in the long run is turning Bitcoin into a shitcoin - because some other coin without artificial blockspacer scarcity quickly come along and efficiently use the bandwidth and disk space and memory and processing cycles and electricity available, and overtake Bitcoin. (This could be an alt-coin - or it could be an upgrade to Bitcoin, such as Bitcoin Unlimited.)
Bitcoin's value depends on two factors
The value proposition of Bitcoin is based on TWO aspects:
The price of a bitcoin is something we want to keep HIGH - to avoid DILUTING our wealth. This incentivizes us to keep the Bitcoin supply FIXED (21M).
The price of a Bitcoin transaction is something we want to keep LOW - to avoid ERODING our wealth (miners sucking up our BTC via high fees). This incentivizes us to keep Bitcoin fees LOW.
Don't let the miners unilaterally sneak artificial fee inflation into Bitcoin by artificially limiting the blocksize!
Seriously, it's time to throw the discredited, fraudulent phrase "fee market" into the dustbin of history - and use something that actually paints the correct economic picture, like "fee/blocksize equilibrium".
submitted by ydtm to btc [link] [comments]

Until there is a real, working, live release of lightning network, it is irresponsible to tout it as a solution

Furthermore, once it is out, it will have to pass the test of time, -- the same kind of test of time Bitcoin had to pass when it was released (at least a year or two to ensure its viable and working without major hiccups/crashes/other downfalls such as subject to extreme regulation(which I think is virtually inevitable especially if it grew to any significant size, or if it's peer-to-peer that that data would have to be stored via a blockchain.. lol, not doing anything to solve data-storage bloat which core members so adamantly are trying to limit (i.e.: lukejr wanting 300kb blocks).
segwit relies on lightning network for scaling, but we don't even know if it's practical (which I don't think it is), yet they are trying to give the cart before the horse. Imo it's like testing if a new type of bitcoin would be successful, having to go through all same growth cycles as bitcoin to become viable.
Also correct me if I'm wrong, if we do segwit, and it turns out lightning network is ineffective and we need to scale blocks the "old fashioned way of increasing the blocksize," then rather than a simple increase of 1mb->2mb increasing block size only 1mb, if we do this increase with segwit, it will cost us up to 4x as much per megabyte.
Is my understanding of this correct? If so this is a major setback for scaling when Bitcoin needs to grow to 4mb, and 8mb. (as potentially 4x more space is needed, creating more data storage requirements and subject to more spam vulnerability (ironically the same thing that lukejr and others are trying to avoid).
Edit: I'm unsure how much segwit will increase the average transaction size, but it's clear to me that it will increase average transaction size, since it would add more data/instructions within the Bitcoin blocks.
submitted by TommyEconomics to btc [link] [comments]

Roger Ver explains: Why he supports Bitcoin Unlimited and bigger blocks

submitted by BitcoinXio to btc [link] [comments]

Blockstream CTO and core dev Greg Maxwell caught lying YET AGAIN with "(only) Segwit resolves QH. It cannot be fixed by changes to implementations"

Another "lying with the truth" comment from Greg here:
https://www.reddit.com/btc/comments/6lu4vc/craig_wright_says_there_already_is_a_malleability/djx25c4/
Note that he doesn't literally say "Segwit is the only way to fix QH", but strongly implies it with this:
Segwit resolves it by making the hashing more like H(H(tx_with_signatures_removed)||0)... so the inner hash can be cached and then the hashing only grows like O(N). So it cannot just be fixed by changes to implementations, it's inherent in the format.
As Tom Zander points out, QH is actually already been fixed for years: https://www.reddit.com/btc/comments/6m45t2/reminder_why_do_we_need_segwit_spoiler_we_dont/
And there are multiple ways to fix it as Dr. Wright spoke about.
Greg makes it sound like Segwit is the only software implementation that can deal with it, when the word implementation is ambigious here. He is only right in a very narrow sense of the word implementation... not in the sense that he conveys and tries to fool people with. But he words it very carefully, like a master politician.
Bottom line: Don't expect Greg to be fully honest about Bitcoin, at least until we've forked away from his perverted vision of Bitcoin as a settlement network.
submitted by jonald_fyookball to btc [link] [comments]

So what's the prediction now

As far as I can see : 0.13.1 with SegWit will be released soon. 95% will not be reached. Segwit won't be activated unless ViaBTC and others(?) can keep +5% network hashpower
Let's assume SegWit gets blocked for months/years, what's the plan on either side ?
Also, is 95% hardcoded in 0.13.1 ? Any chance 0.13.1 will be released with a lower limit ?
Is blocking SegWit a political stance or because of a genuine technological concern ? I was under the impression SegWit is OK, but on-chain scaling with bigger blocks should also be implemented, preferably before SegWit. Now I read more and more SegWit isn't OK, because it introduces 'banking like' hubs ....
I know, lots of questions, but can someone enlighten me and others.
Edit : 'banking like' hubs is a concern about LN ... what's the concern exactly about SegWit ?
submitted by xpiqu to btc [link] [comments]

21 Secure Network Provenance 26 Detecting and Surviving Data Races using Complementary Schedules Bitcoin Cash Development video meeting #15 - October 24, 2019 Keynote SIGOS Conferences BITCOIN muestra signos de VIDA - Bit2Me Crypto News - 25 ...

Today, at precisely 9 a.m. ET on May 15, 2020, the Bitcoin Cash network completed another upgrade adding new features to the blockchain. number of sigops allowed in blocks sizelimit : No : Number : number of bytes allowed in blocks transactions : Should : Array of Objects : Objects containing information for Bitcoin transactions (excluding coinbase) version : Yes : Number : always 1 or 2 (at least for bitcoin) - clients MUST understand the implications of the version they use (eg, comply with BIP 0034 for version 2) coinbaseaux ... Bitcoin Cash brings sound money to the world. Merchants and users are empowered with low fees and reliable confirmations. The future shines brightly with unrestricted growth, global adoption, permissionless innovation, and decentralized development. Bitcoin transactions are identified by a 64-digit hexadecimal hash called a transaction identifier (txid) which is based on both the coins being spent and on who will be able to spend the results of the transaction. Unfortunately, the way the txid is calculated allows anyone to make small modifications to the transaction that will not change its meaning, but will change the txid. This is ... Now we get into the real fun: signature operations (or “sigops”). Bitcoin Script has very little functionality. As a result, it is cheap to evaluate. Signature verification is by far the most ...

[index] [20243] [10806] [46685] [33881] [35929] [15399] [35721] [7866] [36448] [15531]

21 Secure Network Provenance

http://sigops.org/sosp/sosp11/current/index.html#26-veeraraghavan 💓 Bitcoin muestra signos de vida: - Después de empezar la semana con una caída de casi 5%, ayer el precio presentó un movimiento importante al alza subiendo ... ¿Que es el dinero de Internet? ¿Es BitCoin el dinero del futuro? Conoce con este vídeo en Lengua De Signos Española la famosa moneda BitCoin, su seguridad y ... http://sigops.org/sosp/sosp11/current/index.html#21-zhou The tenth Bitcoin Cash Development video meeting for 2019 took place on May 30 at 15:00 UTC. Participants: Amaury Sechet, - Bitcoin ABC Jason B. Cox, - Bitcoin ABC Antony Zegers - Bitcoin ABC Mark ...

#