I like this strategy a lot, but the performance of read queries suffer if they span partitions, correct?
The issue I'm facing is a very large table, that is both write and read heavy, and the reads do not fall into a specific range of values for any particular column, so I don't think partitioning is an option.
2. Deriving the private key(s) from the public key(s)
3. Creating and broadcasting its own transaction using the stolen keypairs before the original transaction confirms (presumably with a higher fee to win the confirmation race).
Please correct me if I'm wrong.
EDIT: correction: every transaction completely spends any selected UTXO of an associated keypair, not all of the "source keypairs' funds". Thus the attack vector also includes being able to steal from any keypair that has ever made a transaction and also has UTXOs.
Slightly off-topic, but I wish more OSS projects and maintainers would advertise cryptocurrency donation addresses. It's probably the easiest way for end users to donate.
A solution I've used is to limit the number of table rows displayed to fit vertically within the browser viewport. This way the horizontal scrollbar at the bottom of the table is always visible without having to scroll vertically.
This does require:
0. Pagination.
1. Each table row must have the same height.
2. Use of javascript to calculate the max number of rows that will fit vertically in the viewport (and don't forget to include the height of the table header and pagination buttons in the calculation).
3. Send ajax request with row limit to server to retrieve and render the data.
The catch is that you must use Cloudflare's nameservers [0]:
6.1 Nameservers. Registrant agrees to use Cloudflare’s nameservers. REGISTRANT ACKNOWLEDGES AND AGREES THAT IT MAY NOT CHANGE THE NAMESERVERS ON THE REGISTRAR SERVICES, AND THAT IT MUST TRANSFER TO A THIRD PARTY REGISTRAR IF IT WISHES TO CHANGE NAMESERVERS.
I was able to solve DNS issues with my domains at Porkbun by:
1. Log in to Porkbun account, go to "Domain Management".
2. Click "DNS" link under affected domain.
3. Click the "Yes, please update my domain" button in the red box at the top, screenshot:
You might take a look at wee.domains [0] - it's a big table of short available domains from the most popular TLDs. It has pricing from a variety of registrars too.
No I don't think so. Thanks for pointing that out.
IIRC, I eventually removed nosnippet because it caused google to not display microdata in SERP (see the "$25.99 to $99.80" in the above screenshot) that were desirable for my traffic. I instead replaced nosnippet with:
```
<meta name="robots" content="noarchive">
```
And this seemed to have the same effect as nosnippet, but with the added benefit of my microdata still being displayed in SERP.
The issue I'm facing is a very large table, that is both write and read heavy, and the reads do not fall into a specific range of values for any particular column, so I don't think partitioning is an option.