I can't find any source for this but spammy webpages and the CME quotes page has recently updated quotes.  I think this is false.

I had a chance to go look back at those transactions and ... it turns out that the amount wright paid was his tax id.  So it was obviously a transparent attempt to get his tax ID to show up on block explorers for the target address.

Progress here is waiting on the deployment of 0.21.0 which is delayed, I think because it was discovered at the 11th hour that some P2P protocol update caused all existing BTCD software to instant-disconnect due to it erroneously hanging up on unexpected messages.

After 0.21.0 is out and stable then a 0.21.1 could be done with taproot activation.

Well, if this software has already solved the complexity then the complexity would be a non-issue.

The main support issue would be that customers would lose their keys to their wallets and then contact support to try to recover them.

Do you think it might be possible to run an intentionally and explicitly hobbled instance of this that can't send funds outside the system for acting as a "gift card wallet"?

It can be pretty useful for a merchant to allow users to keep a balance and even transfer balance between customers... but in some jurisdictions having funds leave the system creates additional regulatory issues... and isn't really needed for the purpose.

I've looked into setting up a chaum token system for this application before.  Pay bitcoin in, get tokens that can be moved among users, or eventually turned into purchases of goods/services.  One reason to use chaum tokens for this application is so that the merchant doesn't unnecessarily learn the exact linkage between the customer's Bitcoin transaction history and their name and physical address (needed for shipping goods) in order to reduce the risks from hacks/thefts.

It would be nice if some existing software could be deployed off-label for this application.

I've done this.  You need an appraiser. E.g. https://cryptoappraisers.com/  (like ... maybe you can get away without one, but that seems ill advised.)

You can do it somewhat more efficiently if you're going to make many donations to do a large amount at once to a Donor Advised fund, e.g. Fidelity Chartable and then make further donations out of the trust-- because then you just have a single bitcoin donation.

It's also advantageous to make a larger amount of donations in the same tax year because you can't write off the donation while using the (now pretty large) standard deduction-- so it's better to donate all at once in one year, don't use the standard deduction in that year, and then in other years continue to use the standard deduction.

Many (most?) users are currently CPU bottlenecked on validation, so any additional CPU will slow down their sync.  Changing the speed of the compression just changes the point at which the tradeoff moves.

[Aside, Lz4 doesn't do that much on transactions]

I hope I didn't make it sound like I think it shouldn't be done.  I think it should be done, and probably supported over P2P too-- as a negotiable feature.  Local usage could easily be optional, I expect most non-pruned users would want it on to save space unless their node is stored on a 10TB spinning disk and they don't care about the usage or they're on a small arm device and the extra cpu would be brutal while peers are syncing from them.

It's just not trade-off free, and AFAIK no one working on core is interested in working on it.

The blockstream satellite node software contains a compressor that shrinks transactions by about 20% operating a transaction at a time.  (More could have been achieved by working multiple txn at a time, but at a great increase in software complexity and some loss of functionality).

It exploits all the redundancies described by pooya87 above and quite a few additional ones. E.g. it knows how to reconstruct the hash in the redeemscript for P2SH embedded segwit, it knows how to convert 65 byte pubkeys to and from 32 byte pubkeys, etc.  I think, though my memory is kinda fuzzy, it exploits reused scriptpubkeys/redeemscripts within a transaction.

Though your network needs to be fairly slow or your CPU extremely fast before its worth the CPU cost (for satellite it's an obvious win).

Technically thats not entirely true, due to things like pubkey and address reuse and common syntax elements, state of the art generic compressors do get some compression when working on one or several whole blocks at a time.  But not anywhere near as much compression as a data aware compressor can achieve. The two can be combined, of course.  But having to work one or more blocks at a time gets in the way of random access to data and potentially creates DOS vulnerabilities (e.g. from peers forcing you to decompress groups of blocks only to access one block in the group).

It's more efficient to use this stuff if you negotiated with peers sending the compressed form over the wire.  If all your peers were doing that, you could just keep the compressed form in memory and on disk and not have to decompress except for validation.

AFAIK no one is working on taking this work upstream, which is sad-- a 20% reduction in disk space would be nice, and post erlay this would also end up being nearly a 20% reduction in network bandwidth if used for transaction/block relay.

If it were just done for storage probably the best thing would be store every block using it,  and just keep a small cache of uncompressed blocks in memory for serving requests for recent blocks.  Any kind of rewriting of block data on disk is complicated due to the need to be able to recover from crashes.

Yes, though the fact that some use their own custom crypto libraries due to altcoin support and it may take them a little while to get around to writing it.

It's easy to find the s spellings and bloody as in intensifier in the writing of Americans, especially easy if they intentionally adopting a different style.  I wouldn't read too much into stuff like this.

Huh!  I had no idea that was at the conference, I would have found it pretty interesting I had been and would have mentioned it in the coinjoin post!

However, my work in that space substantially pre-dates the conference e.g. https://bitcointalk.org/index.php?topic=139581.0  which included demonstrating it on the network,  as well as describing how to cryptographically blind the participants from each other.  And even those posts were posted as late as they were because I had to wait until the software had the necessary functionality.  I believe public discussion of this kind of approach to improve privacy goes back to mid 2011.

The purpose of the coinjoin thread was just to popularize an existing concept,  driven by the reasoning that because it hadn't been given a catchy name no one was thinking much about it.

Thanks to everyone for taking the time to participate in the interviews and the contest, I found many of them interesting and I'm glad people enjoyed mine.

The address on my profile works fine: bc1q6qwd6l8nm9uad53c7jtl3ermds5cxwfnfevap6

Cheers!

In the US you can easily move millions of dollars into and out of bank accounts without it being a big deal. At least for just a couple million it doesn't usually generate any remarks from bank staff-- or if they say anything they just assume you're buying an expensive home or selling a business.

Blocks are not blockheaders.

Limited peers can serve all headers, but they only serve the latest 288 blocks from their tip.

https://github.com/bitcoin/bips/blob/master/bip-0159.mediawiki


If something is accepting connections but has a service flag of 0 it's probably some weird spything.  If it makes a connection to you with a service flag of zero it may be a SPV wallet, but its more likely a spynode pretending to be a spv wallet (as there are more spynodes than p2p spv wallets).

Did they never make good on these plans?

The only use for a 'privacy score' is introducing privacy concepts to someone who knows nothing about them and won't have as easy a time learning from reading a list by itself.

There is also potential for abuse.

For example after a prominent wallet added mechanism to improve privacy-- when it spends from one of a reused output it it tries to spend all of them-- one of these explorer sites changed to start reporting all those transactions as 0 privacy.  Were they just incompetent?  Trying to trash that particular wallet?  Trying intentionally to encourage users to use less private software?  No way to know.

Obviously anyone plugging their own addresses/transactions into these things are trashing their privacy.  Highlighting transaction properties can be useful for educating people, giving a score -- less so,   encouraging people to search their own transactions and/or addresses is just a bad move.

gibberish thread. I wonder what scam its peddling on the backend?

Alas, that page is about binary field multiplication, arithmetic in GF(2^n) rather than in GF(P).  Binary field arithmetic has special structure that make logic implementations especially efficient (and public key cryptography especially weak. ) and isn't what is needed here.

Oy. don't use 'converters'. Their efficiency will be poor and as you note they don't handle much power (unless they're expensive).

In the US we use 120/240v power.  Power hungry appliances like electric ranges and dryers use 240v.   Find/install a 240v plug to run your miners.

All my computers are run on 240v-- the PSUs are more efficient that way.