Bumping this thread with a blog post we wrote. It details some of the risks associated with dynamic/additive/rbf batching, folks in this thread might find it interesting.

https://blog.cardcoins.co/rbf-batching-at-cardcoins-diving-into-the-mempool-s-dark-reorg-forest

Bump.

Hey Bitcointalk!

If you're interested in Bitcoin Core, we have some pretty exciting news. Last year we announced year-long funding for an excellent contributor to the project, Hennadii Stepanov (aka hebasto). Today we are announcing a renewal of that funding, and we wrote a blog post which details some of the excellent work he has done over the last year. After Marco Falke, hebasto had the most commits for the year, and also produced a jaw-dropping number of reviews.

You can find the blog post here: https://blog.cardcoins.co/a-year-in-review-hennadii-stepanovs-contributions-to-bitcoin-core

And feel free to engage with us on Twitter as well: https://twitter.com/CardCoinsCo/status/1366378529210978304

If you have any questions about our motivations, Bitcoin Core, or hebasto's work, feel free to ask! This is one of our favorite aspects of Bitcoin, and it brings us great pleasure to share our excitement with you.

Right, we sell you Bitcoin in exchange for Visa/Mastercard/Amex gift cards.

2 @ .08

We do the reverse. You give us Visa/Mastercard/Amex gift cards and we send you Bitcoin.

We were confused by the various overlap between the sections, can you cite the rule we are violating? Appreciate the help!

Oh interesting okay thank you! We consider the Visa/Mastercard/Amex gift cards "currency," but we can settle for "digital goods!"

If you have any questions at all, feel free to ask here. We've been around for almost two years and have an impeccable track record. We're huge fans of Bitcointalk and hope to work with some of you in the future.

We're always looking to add more locations. We are working on getting full coverage in the U.S. first and then will consider adding additional countries.

As mentioned our price is dynamic, expect it to come down 

Hi there!

We are a Wyoming based entity and are federally registered Money Service Business with the U.S. Treasury. You can find our registration by looking us up on the FinCEN website: https://www.fincen.gov/msb-registrant-search

And yes that's right, we don't have accounts, however we track a user's volume limit by their phone number. Once your phone number exceeds a certain volume limit in a week, we verify certain information about your identity, which in some cases requires a government-issued ID.

As you have pointed out, our service does require an element of trust. Do note that we only preauthorize the funds on your card until we have verified that you have properly submitted all of the documentation we require. If you fail to complete our requirements we void the preauthorization and return the funds to your card. This voiding process can take a few days depending on the card issuer.

We have been around for almost 2 years now, so a cursory google search will lend credence to our trustworthiness. I hope that answers your questions. 

Bump.

We're always working on interesting new products and features, introducing closed loop gift cards is definitely something on our radar! Thankfully the distribution of open and closed loop gift cards is nearly identical. Pretty much every big box retailer, pharmacy, supermarket, gas station etc. that sells closed loop also has open loop.

Will keep this thread in mind in the event we introduce the closed loop stuff!

I see no one has discovered the easter egg. Hint: it's in the How To blog post!

Winner takes all.

In perfect circumstances block validation is quite fast, that's correct!

There are adversarial cases where block validation can take quite a bit longer then the block you have presented here. In fact, one of the most significant improvements that segwit introduced was designed to partially address this exact issue, as the signature hashing algorithm was O(n^2). Now it is O(n): https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki#motivation

While segwit addresses one of these complexities, there are still others (albeit much less vicious): https://bitslog.com/2017/04/17/new-quadratic-delays-in-bitcoin-scripts/

Even if you don't assume the block is intentionally adversarial, there are lots of other factors which can effect validation time, including how much of the UTXO set the validator has cached, and how much of the block's content is in that cache. The libraries and hardware they use is also an important factor. Sipa has a great stackexchange post which details some of this stuff here, he suggests blocks can take multiple seconds to validate: https://bitcoin.stackexchange.com/questions/50349/how-long-does-block-validation-take/50407#50407

You might be interested in the concept of Weak Blocks which is a "pre-consensus" process by which miners propagate blocks with PoW below the target difficulty with the general assumption the composition of that block will remain the same in the event that miner satisfies the PoW. It increases bandwidth but would allow for validation to be front-loaded. It would be trust-full and not consensus enforced, presumably. There is a lot of skepticism of this idea, for various reasons related to incentives etc.


Appears both of those blocks were found immediately (within a second) after the block that preceded them.

Compact Blocks (BIP 152), a standardized form of Greg's efficient block relay, a modified version of which is used in the FIBRE network, is mainly designed to reduce the amount of bandwidth required to propagate blocks. It does have the side effect of lowering latency during propagation when High Bandwidth mode is enabled, but ultimately validation of the block is still required: https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki#pre-validation-relay-and-consistency-considerations

FIBRE of course improves propagation speeds even above HB mode of Compact Blocks. Extremely careful selection of relay points, no validation and forward error correction.

But yes stale rates are very significantly down. This has less to do with validation speeds and more to do with improvements in propagation techniques. Once upon a time everyone pooled up in btcguild, GHASH etc. to deal with this exact problem.

In terms of actually building a block template as quickly as possible, one thing that has improved the speed by which miners can do this is a tighter relationship between CreateNewBlock and the current state of the mempool. This doesn't help you validate the inbound block any faster, but does help you build the next block with greater efficiency: https://github.com/bitcoin/bitcoin/pull/6898

Do folks in this thread have an interest in the Gift Card -> Bitcoin side of the transaction? I see the list here is composed of Bitcoin -> Gift Card providers.

Our service (https://cardcoins.co) does just that. We accept Visa/Mastercard/Amex gift cards and exchange them for Bitcoin

Empty blocks can mean a lot of things, many of them mentioned in the thread here.

Right now the block subsidy significantly outweighs the fees in a block. If miners feel that the additional weight in the block may cause them to lose a block race, they may choose to put very few or no transactions in a block. Over time you imagine this will be untenable as fees becomes a more significant proportion of miner income. The unfortunate side effect of that new paradigm is that if there is not a significant backlog of transactions in the mempool, miners may attempt to "fee snipe" transactions from the tip and re-mine the top most transactions instead of pushing the chain forward. There are some partial mitigations to this in Bitcoin Core by tweaking a transaction's locktime to the current block height so miners are incentivized to push the chain forward to capture fees from these types of transactions.

When it comes to validating a block, depending on the composition of transactions, it can take upwards of a few seconds (even more in some pathological/adversarial scenarios) to complete. Given the miner income ratio right now, it makes sense to mine an empty block before you have fully validated the tip because you can't be sure exactly what block template you can construct without possibly making it invalid (unless the block only includes transactions from the miner or their direct associates in some out-of-band transaction confirmation deal). This has sometimes been called header-first/validation-less or SPV mining, because the miners have only validated the proof of work, not any of the transactions.

There is also Spy mining, where competing pools connect to one another and monitor for discovered blocks. When one of a pool's clients find a block, it immediately publishes the header of that block to all the other clients so it can begin mining right away. In this case if you are a competing pool and hear about this block you will not know its composition, so you have no choice but to tell your clients to mine an empty block on top of it.

The obvious danger with the above strategies is that you are building on an invalid block. While this is exceedingly rare, it can and has happened. Here is a historical example: https://bitcoin.stackexchange.com/questions/38437/what-is-spv-mining-and-how-did-it-inadvertently-cause-the-fork-after-bip66-wa

Another phenomena that may cause near-empty blocks but is largely irrelevant now is covert-ASICBOOST, where miners attempt to compose transactions in the block in a certain way that allows them to increase their efficiency by causing collisions in the midstate of the first chunk of the block header when it is being hashed. In effect they can re-use some of the proof of work. It was already mentioned in the thread, but segwit significantly undermined the covert-ASICBOOST strategy by adding an additional merkle root in the coinbase transaction for witness txids, so the strategy of reordering transactions become more computationally difficult.

I saw a mention of selfish mining in the thread, but to clarify: there are a few different strategies for selfish mining, but the most common one is to withhold a single block that you have mined and wait for a competing pool to discover a block, then force a block race. It is not a common strategy to wait for the selfish pool to mine multiple blocks and then broadcast the chain. That would be highly detectable by the network. As is, we very rarely see "stale" blocks that have lost block races today. When it comes to races, you want your block to propagate as quickly as possible so you will want to be extremely well connected to the rest of the network and also for the block to be as small as possible so it propagates quickly. 

Of course there is also the possibility that there are no transactions in the mempool, although that is fairly rare these days. There are even transactions that have been evicted from the mempool that may be stored by some miners in the event that there are no other transactions to mine.

Good question! When we say we don't have accounts, we mean just that--our system does not require registration of an email address or setting of a password to get started. In fact those concepts do not exist in our system at all! You just click start an order, receive a 4 digit code and your on your way. There is nowhere to sign in, all the user needs is their Order ID to find their submission: https://cardcoins.co/order/ORDERID

We are however a registered MSB with FinCEN so we do need to track your volume limits, which we do internally in our database with the user's phone number. This allows us to ask for additional information when we need it, but not every time. While you may attempt to bypass our limits, we do monitor for suspicious activity and will take action according to our compliance program and procedures if discovered.