Search content
Sort by
Showing 20 of 43 results by Paperweight
Re: Would you be willing to flip coin / roll dice 256 times for security of funds?
That's cool! Good work!
So you use the device to generate a private key and encrypt it with a password. You write the passworded key down (paper wallet) and store it safely as a backup in case you lose the device.
When you want to transact, you generate a signing request QR on your computer. The device scans it in and asks you for your password. It then generates a signature QR which you scan using your computer. Your computer adds it to the transaction and broadcasts it.
Er, wait, the device wipes its memory every time you use it, so you need to type in your passworded key and password every time. Sounds like a PITA that leads you to leaving your paper wallet lying around (printing a passworded key QR is nice but beyond the paranoia level of this device).
The device will have to have the unencrypted private key in memory at some point. How about the device stores the passworded key in volatile memory which gets wiped after a window of time, loses power, or you get the password wrong? It could possibly also be in a TPM of some sort that does the signing, inaccessible to the OS or memory to make it harder to dump from memory if the device is stolen within that window of time.
Note that normal RAM isn't truly volatile (https://citp.princeton.edu/our-work/memory/). You can freeze the device, kill its power, and then boot it from a memory card with a tiny live OS that dumps the raw memory that's still frozen in time from when it lost power.
The obvious attack is to steal the device, install a keylogger, and then put it back where you found it.
Maybe having read-only firmware and no USB or memory card ports would help for the above scenarios.
So you use the device to generate a private key and encrypt it with a password. You write the passworded key down (paper wallet) and store it safely as a backup in case you lose the device.
When you want to transact, you generate a signing request QR on your computer. The device scans it in and asks you for your password. It then generates a signature QR which you scan using your computer. Your computer adds it to the transaction and broadcasts it.
Er, wait, the device wipes its memory every time you use it, so you need to type in your passworded key and password every time. Sounds like a PITA that leads you to leaving your paper wallet lying around (printing a passworded key QR is nice but beyond the paranoia level of this device).
The device will have to have the unencrypted private key in memory at some point. How about the device stores the passworded key in volatile memory which gets wiped after a window of time, loses power, or you get the password wrong? It could possibly also be in a TPM of some sort that does the signing, inaccessible to the OS or memory to make it harder to dump from memory if the device is stolen within that window of time.
Note that normal RAM isn't truly volatile (https://citp.princeton.edu/our-work/memory/). You can freeze the device, kill its power, and then boot it from a memory card with a tiny live OS that dumps the raw memory that's still frozen in time from when it lost power.
The obvious attack is to steal the device, install a keylogger, and then put it back where you found it.
Maybe having read-only firmware and no USB or memory card ports would help for the above scenarios.Remember it's port 18444, and only works with nodes that are running regtest themselves. I think regtest has a higher minimum version requirement, e.g. always SegWit?
Re: BitTorrent client and bitcoin blockchain submission idea!
Yeah, baby! This is classic application for cryptocurrencies. It would even better if the original authors got the donations, so they at least get *something* from those pesky pirates. Imagine a decentralized iTunes.
As above posters have noted, BitTorrent Inc. is thrashing around this space with their BTT token and I haven't tried it but it's probably junk.
Problem: Scanning the whole blockchain for a magnet hash is inefficient. Furthermore, there's no guarantee that the Bitcoin address attached to it is the same as the torrent creator.
Solution: The Bitcoin donation address can simply be encoded in the torrent metadata itself, which is hashed into the magnet link by the torrent creator, thus ensuring that they are the ones who inserted the address. I propose simply adding a zero-length file to the torrent with the name "<currency code>:<address>".
Whaddya know!? Frostwire and qBittorrent already do this! https://blog.frostwire.com/2014/02/27/frostwire-integrates-bitcoin-donations-and-creative-commons-licensing-into-torrent-files/
There's also the weakness that the torrent is only hashed with SHA-1, but that's another discussion.
References:
https://www.bittorrent.com/token/btt/
https://en.wikipedia.org/wiki/Torrent_file
As above posters have noted, BitTorrent Inc. is thrashing around this space with their BTT token and I haven't tried it but it's probably junk.
Problem: Scanning the whole blockchain for a magnet hash is inefficient. Furthermore, there's no guarantee that the Bitcoin address attached to it is the same as the torrent creator.
Solution: The Bitcoin donation address can simply be encoded in the torrent metadata itself, which is hashed into the magnet link by the torrent creator, thus ensuring that they are the ones who inserted the address. I propose simply adding a zero-length file to the torrent with the name "<currency code>:<address>".
Code:
{
"announce": "http://tracker.site1.com/announce",
"info": {
"files": [
{"length": 111, "path": ["111.txt"]},
{"length": 222, "path": ["222.txt"]}
],
"name": "my-music",
"piece length": 262144,
"pieces": <binary SHA1 hashes>
},
"donations": {
"xbt": <bitcoin address>,
"xmr": <monero address>
}
}
"announce": "http://tracker.site1.com/announce",
"info": {
"files": [
{"length": 111, "path": ["111.txt"]},
{"length": 222, "path": ["222.txt"]}
],
"name": "my-music",
"piece length": 262144,
"pieces": <binary SHA1 hashes>
},
"donations": {
"xbt": <bitcoin address>,
"xmr": <monero address>
}
}
Whaddya know!? Frostwire and qBittorrent already do this! https://blog.frostwire.com/2014/02/27/frostwire-integrates-bitcoin-donations-and-creative-commons-licensing-into-torrent-files/
There's also the weakness that the torrent is only hashed with SHA-1, but that's another discussion.
References:
https://www.bittorrent.com/token/btt/
https://en.wikipedia.org/wiki/Torrent_file
I still don't understand about this sidechain, what is the convenience offered by sidechain? and does it really work any better than blockchain in general?
It's so altcoins can share hashrate, instead of being vulnerable to 51% attacks from big miners from other coins.
Re: How can I restart a dead altcoin and continue the development??
Negative nancies everywhere! https://i.kym-cdn.com/photos/images/original/001/715/717/e27.jpeg
It's been 5 months and nobody's answered his question.
Step 1 - Download their whitepaper and their website and node's source code.
Step 2 - Do a "find and replace" from their name to your name. Cite their whitepaper in your whitepaper and license.
Step 3 - Make new genesis block.
Step 4 - Compile and run node.
Step 5 - Launch website.
Step 6 - List it on an exchange and wait for the cash to start rolling in.
It's been 5 months and nobody's answered his question.
Step 1 - Download their whitepaper and their website and node's source code.
Step 2 - Do a "find and replace" from their name to your name. Cite their whitepaper in your whitepaper and license.
Step 3 - Make new genesis block.
Step 4 - Compile and run node.
Step 5 - Launch website.
Step 6 - List it on an exchange and wait for the cash to start rolling in.
Guys, guys! If you need to generate random passwords just use the goddamn command line.
From the Mac or Linux terminal:
From Windows Powershell:
And if you INSIST on doing it from a web browser, just copy-paste this into a text file and rename it random.html
From the Mac or Linux terminal:
Code:
LC_ALL=C tr -cd \!-~ < /dev/urandom | head -c 42
From Windows Powershell:
Code:
[Reflection.Assembly]::LoadWithPartialName("System.Web")
[System.Web.Security.Membership]::GeneratePassword(42, 0)
[System.Web.Security.Membership]::GeneratePassword(42, 0)
And if you INSIST on doing it from a web browser, just copy-paste this into a text file and rename it random.html
Code:
<script>
var bytes = new Uint8Array(420);
window.crypto.getRandomValues(bytes); // supposed to be cryptographically secure
document.write(
[...bytes]
.filter(x => 33 <= x && x <= 126) // filter out non-ascii character codes
.map(x => String.fromCharCode(x)) // map character codes to characters
.join('') // join characters into string
);
</script>
var bytes = new Uint8Array(420);
window.crypto.getRandomValues(bytes); // supposed to be cryptographically secure
document.write(
[...bytes]
.filter(x => 33 <= x && x <= 126) // filter out non-ascii character codes
.map(x => String.fromCharCode(x)) // map character codes to characters
.join('') // join characters into string
);
</script>
Re: Would you be willing to flip coin / roll dice 256 times for security of funds?
The question is moot because the Linux OS and firmware running on the Raspberry Pi can just keylog your private key anyway, or transparently use its own when it comes time to actually generating your public key, or choose its own nonce values when signing, or any number of things. You either trust it or you don't. And when you're known to trust it then you can become a target of whoever makes it. That's why Trezor makes their own hardware. https://wiki.trezor.io/Security
How do you input/output transactions with this device? How do you back up your keys?
I hate to be a downer though, so here's some comic relief https://dilbert.com/strip/2001-10-25
How do you input/output transactions with this device? How do you back up your keys?
I hate to be a downer though, so here's some comic relief https://dilbert.com/strip/2001-10-25
Don't use a password generator website. Thousands of Bitcoins have been stolen this way. Even if you use if offline, it is HIGHLY LIKELY to give you intentionally or unintentionally predictable output.
Don't use a super-strong random password without a physically secured unencrypted backup. Thousands of Bitcoins have been lost this way. You are HIGHLY LIKELY to forget any password that's strong enough to not be brute-forced.
DO focus on the basics of "security" = "something you have" + "something you know". Assume that, tonight, Russian hackers will whack you on the head, give you password amnesia, steal your airgapped computer, start grinding it with a supercomputer, and burn your house down with everything in it to hide the evidence.
Don't use a super-strong random password without a physically secured unencrypted backup. Thousands of Bitcoins have been lost this way. You are HIGHLY LIKELY to forget any password that's strong enough to not be brute-forced.
DO focus on the basics of "security" = "something you have" + "something you know". Assume that, tonight, Russian hackers will whack you on the head, give you password amnesia, steal your airgapped computer, start grinding it with a supercomputer, and burn your house down with everything in it to hide the evidence.
Re: Chain Archaeology revisited -- Any more known miners for sub 1000 blocks?
⭐ Merited by The Pharmacist (3)
I'm not a C++ expert, but according to the source code for Bitcoin v0.1.0, the nonce starts at 1 and then increments after every attempt (line 2297, main.cpp).
HOWEVER, contrary to the comments in that thread, it looks like the nonce gets reset to 1 EVERY time a new block is found or accepted, whether self-mined or from the network. That means the nonce slopes are mysterious because they don't start from 1 every time a block is found!
Maybe they were running a version older than 0.1.0, which is possible because the genesis block is from Jan 3, 2009 at 6:15:05 AM UTC. Or maybe the extra miners were custom mining clients (likely Satoshi) that didn't reset the nonce.
main.cpp lines 2183-2361 (file timestamped Jan 7, 2009, 9:00:00 AM UTC)
Reference: https://satoshi.nakamotoinstitute.org/code/
HOWEVER, contrary to the comments in that thread, it looks like the nonce gets reset to 1 EVERY time a new block is found or accepted, whether self-mined or from the network. That means the nonce slopes are mysterious because they don't start from 1 every time a block is found!
Maybe they were running a version older than 0.1.0, which is possible because the genesis block is from Jan 3, 2009 at 6:15:05 AM UTC. Or maybe the extra miners were custom mining clients (likely Satoshi) that didn't reset the nonce.
main.cpp lines 2183-2361 (file timestamped Jan 7, 2009, 9:00:00 AM UTC)
Code:
bool BitcoinMiner()
{
printf("BitcoinMiner started\n");
SetThreadPriority(GetCurrentThread(), THREAD_PRIORITY_LOWEST);
CKey key;
key.MakeNewKey();
CBigNum bnExtraNonce = 0;
while (fGenerateBitcoins)
{
Sleep(50);
CheckForShutdown(3);
while (vNodes.empty())
{
Sleep(1000);
CheckForShutdown(3);
}
unsigned int nTransactionsUpdatedLast = nTransactionsUpdated;
CBlockIndex* pindexPrev = pindexBest;
unsigned int nBits = GetNextWorkRequired(pindexPrev);
//
// Create coinbase tx
//
CTransaction txNew;
txNew.vin.resize(1);
txNew.vin[0].prevout.SetNull();
txNew.vin[0].scriptSig << nBits << ++bnExtraNonce;
txNew.vout.resize(1);
txNew.vout[0].scriptPubKey << key.GetPubKey() << OP_CHECKSIG;
//
// Create new block
//
auto_ptr<CBlock> pblock(new CBlock());
if (!pblock.get())
return false;
// Add our coinbase tx as first transaction
pblock->vtx.push_back(txNew);
// Collect the latest transactions into the block
int64 nFees = 0;
CRITICAL_BLOCK(cs_main)
CRITICAL_BLOCK(cs_mapTransactions)
{
CTxDB txdb("r");
map<uint256, CTxIndex> mapTestPool;
vector<char> vfAlreadyAdded(mapTransactions.size());
bool fFoundSomething = true;
unsigned int nBlockSize = 0;
while (fFoundSomething && nBlockSize < MAX_SIZE/2)
{
fFoundSomething = false;
unsigned int n = 0;
for (map<uint256, CTransaction>::iterator mi = mapTransactions.begin(); mi != mapTransactions.end(); ++mi, ++n)
{
if (vfAlreadyAdded[n])
continue;
CTransaction& tx = (*mi).second;
if (tx.IsCoinBase() || !tx.IsFinal())
continue;
// Transaction fee requirements, mainly only needed for flood control
// Under 10K (about 80 inputs) is free for first 100 transactions
// Base rate is 0.01 per KB
int64 nMinFee = tx.GetMinFee(pblock->vtx.size() < 100);
map<uint256, CTxIndex> mapTestPoolTmp(mapTestPool);
if (!tx.ConnectInputs(txdb, mapTestPoolTmp, CDiskTxPos(1,1,1), 0, nFees, false, true, nMinFee))
continue;
swap(mapTestPool, mapTestPoolTmp);
pblock->vtx.push_back(tx);
nBlockSize += ::GetSerializeSize(tx, SER_NETWORK);
vfAlreadyAdded[n] = true;
fFoundSomething = true;
}
}
}
pblock->nBits = nBits;
pblock->vtx[0].vout[0].nValue = pblock->GetBlockValue(nFees);
printf("\n\nRunning BitcoinMiner with %d transactions in block\n", pblock->vtx.size());
//
// Prebuild hash buffer
//
struct unnamed1
{
struct unnamed2
{
int nVersion;
uint256 hashPrevBlock;
uint256 hashMerkleRoot;
unsigned int nTime;
unsigned int nBits;
unsigned int nNonce;
}
block;
unsigned char pchPadding0[64];
uint256 hash1;
unsigned char pchPadding1[64];
}
tmp;
tmp.block.nVersion = pblock->nVersion;
tmp.block.hashPrevBlock = pblock->hashPrevBlock = (pindexPrev ? pindexPrev->GetBlockHash() : 0);
tmp.block.hashMerkleRoot = pblock->hashMerkleRoot = pblock->BuildMerkleTree();
tmp.block.nTime = pblock->nTime = max((pindexPrev ? pindexPrev->GetMedianTimePast()+1 : 0), GetAdjustedTime());
tmp.block.nBits = pblock->nBits = nBits;
tmp.block.nNonce = pblock->nNonce = 1;
unsigned int nBlocks0 = FormatHashBlocks(&tmp.block, sizeof(tmp.block));
unsigned int nBlocks1 = FormatHashBlocks(&tmp.hash1, sizeof(tmp.hash1));
//
// Search
//
unsigned int nStart = GetTime();
uint256 hashTarget = CBigNum().SetCompact(pblock->nBits).getuint256();
uint256 hash;
loop
{
BlockSHA256(&tmp.block, nBlocks0, &tmp.hash1);
BlockSHA256(&tmp.hash1, nBlocks1, &hash);
if (hash <= hashTarget)
{
pblock->nNonce = tmp.block.nNonce;
assert(hash == pblock->GetHash());
//// debug print
printf("BitcoinMiner:\n");
printf("proof-of-work found \n hash: %s \ntarget: %s\n", hash.GetHex().c_str(), hashTarget.GetHex().c_str());
pblock->print();
SetThreadPriority(GetCurrentThread(), THREAD_PRIORITY_NORMAL);
CRITICAL_BLOCK(cs_main)
{
// Save key
if (!AddKey(key))
return false;
key.MakeNewKey();
// Process this block the same as if we had received it from another node
if (!ProcessBlock(NULL, pblock.release()))
printf("ERROR in BitcoinMiner, ProcessBlock, block not accepted\n");
}
SetThreadPriority(GetCurrentThread(), THREAD_PRIORITY_LOWEST);
Sleep(500);
break;
}
// Update nTime every few seconds
if ((++tmp.block.nNonce & 0x3ffff) == 0)
{
CheckForShutdown(3);
if (tmp.block.nNonce == 0)
break;
if (pindexPrev != pindexBest)
break;
if (nTransactionsUpdated != nTransactionsUpdatedLast && GetTime() - nStart > 60)
break;
if (!fGenerateBitcoins)
break;
tmp.block.nTime = pblock->nTime = max(pindexPrev->GetMedianTimePast()+1, GetAdjustedTime());
}
}
}
return true;
}
{
printf("BitcoinMiner started\n");
SetThreadPriority(GetCurrentThread(), THREAD_PRIORITY_LOWEST);
CKey key;
key.MakeNewKey();
CBigNum bnExtraNonce = 0;
while (fGenerateBitcoins)
{
Sleep(50);
CheckForShutdown(3);
while (vNodes.empty())
{
Sleep(1000);
CheckForShutdown(3);
}
unsigned int nTransactionsUpdatedLast = nTransactionsUpdated;
CBlockIndex* pindexPrev = pindexBest;
unsigned int nBits = GetNextWorkRequired(pindexPrev);
//
// Create coinbase tx
//
CTransaction txNew;
txNew.vin.resize(1);
txNew.vin[0].prevout.SetNull();
txNew.vin[0].scriptSig << nBits << ++bnExtraNonce;
txNew.vout.resize(1);
txNew.vout[0].scriptPubKey << key.GetPubKey() << OP_CHECKSIG;
//
// Create new block
//
auto_ptr<CBlock> pblock(new CBlock());
if (!pblock.get())
return false;
// Add our coinbase tx as first transaction
pblock->vtx.push_back(txNew);
// Collect the latest transactions into the block
int64 nFees = 0;
CRITICAL_BLOCK(cs_main)
CRITICAL_BLOCK(cs_mapTransactions)
{
CTxDB txdb("r");
map<uint256, CTxIndex> mapTestPool;
vector<char> vfAlreadyAdded(mapTransactions.size());
bool fFoundSomething = true;
unsigned int nBlockSize = 0;
while (fFoundSomething && nBlockSize < MAX_SIZE/2)
{
fFoundSomething = false;
unsigned int n = 0;
for (map<uint256, CTransaction>::iterator mi = mapTransactions.begin(); mi != mapTransactions.end(); ++mi, ++n)
{
if (vfAlreadyAdded[n])
continue;
CTransaction& tx = (*mi).second;
if (tx.IsCoinBase() || !tx.IsFinal())
continue;
// Transaction fee requirements, mainly only needed for flood control
// Under 10K (about 80 inputs) is free for first 100 transactions
// Base rate is 0.01 per KB
int64 nMinFee = tx.GetMinFee(pblock->vtx.size() < 100);
map<uint256, CTxIndex> mapTestPoolTmp(mapTestPool);
if (!tx.ConnectInputs(txdb, mapTestPoolTmp, CDiskTxPos(1,1,1), 0, nFees, false, true, nMinFee))
continue;
swap(mapTestPool, mapTestPoolTmp);
pblock->vtx.push_back(tx);
nBlockSize += ::GetSerializeSize(tx, SER_NETWORK);
vfAlreadyAdded[n] = true;
fFoundSomething = true;
}
}
}
pblock->nBits = nBits;
pblock->vtx[0].vout[0].nValue = pblock->GetBlockValue(nFees);
printf("\n\nRunning BitcoinMiner with %d transactions in block\n", pblock->vtx.size());
//
// Prebuild hash buffer
//
struct unnamed1
{
struct unnamed2
{
int nVersion;
uint256 hashPrevBlock;
uint256 hashMerkleRoot;
unsigned int nTime;
unsigned int nBits;
unsigned int nNonce;
}
block;
unsigned char pchPadding0[64];
uint256 hash1;
unsigned char pchPadding1[64];
}
tmp;
tmp.block.nVersion = pblock->nVersion;
tmp.block.hashPrevBlock = pblock->hashPrevBlock = (pindexPrev ? pindexPrev->GetBlockHash() : 0);
tmp.block.hashMerkleRoot = pblock->hashMerkleRoot = pblock->BuildMerkleTree();
tmp.block.nTime = pblock->nTime = max((pindexPrev ? pindexPrev->GetMedianTimePast()+1 : 0), GetAdjustedTime());
tmp.block.nBits = pblock->nBits = nBits;
tmp.block.nNonce = pblock->nNonce = 1;
unsigned int nBlocks0 = FormatHashBlocks(&tmp.block, sizeof(tmp.block));
unsigned int nBlocks1 = FormatHashBlocks(&tmp.hash1, sizeof(tmp.hash1));
//
// Search
//
unsigned int nStart = GetTime();
uint256 hashTarget = CBigNum().SetCompact(pblock->nBits).getuint256();
uint256 hash;
loop
{
BlockSHA256(&tmp.block, nBlocks0, &tmp.hash1);
BlockSHA256(&tmp.hash1, nBlocks1, &hash);
if (hash <= hashTarget)
{
pblock->nNonce = tmp.block.nNonce;
assert(hash == pblock->GetHash());
//// debug print
printf("BitcoinMiner:\n");
printf("proof-of-work found \n hash: %s \ntarget: %s\n", hash.GetHex().c_str(), hashTarget.GetHex().c_str());
pblock->print();
SetThreadPriority(GetCurrentThread(), THREAD_PRIORITY_NORMAL);
CRITICAL_BLOCK(cs_main)
{
// Save key
if (!AddKey(key))
return false;
key.MakeNewKey();
// Process this block the same as if we had received it from another node
if (!ProcessBlock(NULL, pblock.release()))
printf("ERROR in BitcoinMiner, ProcessBlock, block not accepted\n");
}
SetThreadPriority(GetCurrentThread(), THREAD_PRIORITY_LOWEST);
Sleep(500);
break;
}
// Update nTime every few seconds
if ((++tmp.block.nNonce & 0x3ffff) == 0)
{
CheckForShutdown(3);
if (tmp.block.nNonce == 0)
break;
if (pindexPrev != pindexBest)
break;
if (nTransactionsUpdated != nTransactionsUpdatedLast && GetTime() - nStart > 60)
break;
if (!fGenerateBitcoins)
break;
tmp.block.nTime = pblock->nTime = max(pindexPrev->GetMedianTimePast()+1, GetAdjustedTime());
}
}
}
return true;
}
Reference: https://satoshi.nakamotoinstitute.org/code/
Re: [overview] Recover Bitcoin from any old storage format
Missing storage format: 32 bytes of raw binary.
Since random data is incompressible, it even remains unchanged if your wallet is in an (unencrypted) zip file.
If your wallet is on an old hard drive or USB stick, back up and scan a raw image of the ENTIRE DRIVE. Even if your wallet is encrypted or damaged, you might just find your private key in a chunk of an invisible cache or page file somewhere else on the disk!
As a last resort, I made a highly optimized tool to exhaustively scan a raw disk image for a binary private key, using a sliding window of 32 bytes. It still took *months* to scan a big hard drive, though.
To be sure, I recommend making a disk image using ddrescue with SystemRescueCd, then make a backup of that image, then scan the image.
Another missing storage format: ASN.1 DER.
Early versions of Bitcoin used OpenSSL and its related overengineered storage standards. It might be binary, as above, with various leading bytes, or it might be a base64 pem file (with newlines in the middle of it).
References:
https://github.com/dsharhon/bitcoinj-minimal/blob/master/core/ECKey.java#L66
https://en.wikipedia.org/wiki/ASN.1#Example_encoded_in_DER
https://www.hanselman.com/blog/DecodingAnSSHKeyFromPEMToBASE64ToHEXToASN1ToPrimeDecimalNumbers.aspx
Since random data is incompressible, it even remains unchanged if your wallet is in an (unencrypted) zip file.
If your wallet is on an old hard drive or USB stick, back up and scan a raw image of the ENTIRE DRIVE. Even if your wallet is encrypted or damaged, you might just find your private key in a chunk of an invisible cache or page file somewhere else on the disk!
As a last resort, I made a highly optimized tool to exhaustively scan a raw disk image for a binary private key, using a sliding window of 32 bytes. It still took *months* to scan a big hard drive, though.
To be sure, I recommend making a disk image using ddrescue with SystemRescueCd, then make a backup of that image, then scan the image.
Another missing storage format: ASN.1 DER.
Early versions of Bitcoin used OpenSSL and its related overengineered storage standards. It might be binary, as above, with various leading bytes, or it might be a base64 pem file (with newlines in the middle of it).
References:
https://github.com/dsharhon/bitcoinj-minimal/blob/master/core/ECKey.java#L66
https://en.wikipedia.org/wiki/ASN.1#Example_encoded_in_DER
https://www.hanselman.com/blog/DecodingAnSSHKeyFromPEMToBASE64ToHEXToASN1ToPrimeDecimalNumbers.aspx
⭐ Merited by The Pharmacist (3)
According to game theory, vested interests will strive to maintain the security of the network, whether it is a mining pool or a small miner, so the security of the two is equivalent.
Let's take this to the logical conclusion. Communism.No mining rewards at all. Purely deflationary currency. Transaction fees go to nobody. Hodlers are incentivized to mine blocks of transactions because it increases the scarcity value of their own hodlings.
However, there's a tragedy of the commons because your hodlings go up in scarcity whether you mine or not. There's nothing new under the sun. Perhaps this can be solved by purging any account that doesn't contribute enough signed mining shares.
You can make a password-encrypted keyfile 
with MyEtherWallet online, or offline with geth https://geth.ethereum.org/docs/interface/managing-your-accounts
For example, you'll get this kind of printable JSON-encoded plaintext keyfile:
That is a pretty future-proof way to do it. Be sure to do a test run to make sure you can actually decrypt it afterwards!
As an aside, I wonder if there is a way to encrypt a cold wallet with multiple layers of passwords, such that you can be alerted if the first layer is broken and used on a special delayed release contract, giving you a chance to recapture the coins within a certain time period with a backup account...
with MyEtherWallet online, or offline with geth https://geth.ethereum.org/docs/interface/managing-your-accountsFor example, you'll get this kind of printable JSON-encoded plaintext keyfile:
Code:
{
"version": 3,
"id": "4fa372ab-2035-4ede-a302-df4c270a105b",
"address": "fe5bcdeec9b48b63b43d58af8aa78adaad32975e",
"crypto": {
"ciphertext": "9dd28202137a2314ed1ac03569bf285eba31d7f608fb4c8c06fd33bf1b309a01",
"cipherparams": {
"iv": "7c2c4b08137b470b0e4ccc11721b2cf7"
},
"cipher": "aes-128-ctr",
"kdf": "scrypt",
"kdfparams": {
"dklen": 32,
"salt": "de8c8ee7aafceb79682c4ead2128885541c2f903ef048a3ee095770bb2cd6bb8",
"n": 131072,
"r": 8,
"p": 1
},
"mac": "9443d46fba7f19a2af2cfcd11068d0457a5636ec92468328fe4e93ed0f084116"
}
}
"version": 3,
"id": "4fa372ab-2035-4ede-a302-df4c270a105b",
"address": "fe5bcdeec9b48b63b43d58af8aa78adaad32975e",
"crypto": {
"ciphertext": "9dd28202137a2314ed1ac03569bf285eba31d7f608fb4c8c06fd33bf1b309a01",
"cipherparams": {
"iv": "7c2c4b08137b470b0e4ccc11721b2cf7"
},
"cipher": "aes-128-ctr",
"kdf": "scrypt",
"kdfparams": {
"dklen": 32,
"salt": "de8c8ee7aafceb79682c4ead2128885541c2f903ef048a3ee095770bb2cd6bb8",
"n": 131072,
"r": 8,
"p": 1
},
"mac": "9443d46fba7f19a2af2cfcd11068d0457a5636ec92468328fe4e93ed0f084116"
}
}
That is a pretty future-proof way to do it. Be sure to do a test run to make sure you can actually decrypt it afterwards!
As an aside, I wonder if there is a way to encrypt a cold wallet with multiple layers of passwords, such that you can be alerted if the first layer is broken and used on a special delayed release contract, giving you a chance to recapture the coins within a certain time period with a backup account...
What would a mainchain designed solely to secure sidechains look like?
Everyone who's written about sidechains complicates it by trying to peg a mainchain token with a sidechain token. I don't want a mainchain token or cross-chain transactions. I want crazy sidechains that try out speculative wild-west DAO ideas and fund themselves with their own free-floating fully-native currencies.
Picture a tiny mainchain consisting solely of bundled sidechain headers. The only mining rewards would be sidecoin coinbases. That way, sidechain full nodes would only need to host, in parallel, a light mainchain - without 300 GB of other networks' transactions, like Bitcoin. They would be fully compartmentalized and only need to pay via inflation for the value of the proof-of-work of their own timestamping.
There are a lot of ways to do this and I want you guys' input.
One idea I'm considering is for sidechain miners to form pools and hash their own sidechain headers with references to the same pool key and mainchain parent. Once their *combined* proof-of-work score is enough for a mainchain block, they'd bundle the headers and broadcast it. A sidechain node could weigh a sidechain block by simply looking up the combined score of the bundled mainchain block containing it.
-- Relevant prior research --
https://blockstream.com/sidechains.pdf
https://www.drivechain.info/
https://zmnscpxj.github.io/sidechain/driveproof/index.html
Everyone who's written about sidechains complicates it by trying to peg a mainchain token with a sidechain token. I don't want a mainchain token or cross-chain transactions. I want crazy sidechains that try out speculative wild-west DAO ideas and fund themselves with their own free-floating fully-native currencies.
Picture a tiny mainchain consisting solely of bundled sidechain headers. The only mining rewards would be sidecoin coinbases. That way, sidechain full nodes would only need to host, in parallel, a light mainchain - without 300 GB of other networks' transactions, like Bitcoin. They would be fully compartmentalized and only need to pay via inflation for the value of the proof-of-work of their own timestamping.
There are a lot of ways to do this and I want you guys' input.
One idea I'm considering is for sidechain miners to form pools and hash their own sidechain headers with references to the same pool key and mainchain parent. Once their *combined* proof-of-work score is enough for a mainchain block, they'd bundle the headers and broadcast it. A sidechain node could weigh a sidechain block by simply looking up the combined score of the bundled mainchain block containing it.
-- Relevant prior research --
https://blockstream.com/sidechains.pdf
https://www.drivechain.info/
https://zmnscpxj.github.io/sidechain/driveproof/index.html
Altcoins are highly susceptible to 51% attacks because they have a low hashrate, even with merged mining. But what if there was a compact parent chain with *no native token* that was used solely to pool hashrate among sidechains?
I researched this all day and could only find discussions about pegged sidechains with SPV. (Lets assume we *don't* want to peg, so each sidechain has its own native equity currency, let's ignore philosophizing about whether altcoins are good or not, let's ignore trying to come up with a new PoW scheme for each altcoin, and let's ignore the possibility of shifting external hashrate for 51% attacks, so that attacks can only occur from shifting hashrate between sidechains. Etc.)
For simplicity, consider a consortium of 10 altcoins that want to pool their hashrate, who all share this tiny parent chain in addition to their own. The parent chain block headers (there are no block bodies) are of a fixed size struct such as this:
The simplest way is for sidechain nodes to weigh their blocks with the parent chain's block id instead of their own. Mining pools would need to run a full node for each sidechain, but regular sidechain nodes would only need to run the parent chain + their own sidechain.
This way, as long as 51% of the hashrate is honest, they are securing all the sidechains (and reaping the block rewards for each) at the same time.
Another possibility is for the parent chain blocks to be weighed by the sum of the hashes of the sidechain block ids that they include.
I researched this all day and could only find discussions about pegged sidechains with SPV. (Lets assume we *don't* want to peg, so each sidechain has its own native equity currency, let's ignore philosophizing about whether altcoins are good or not, let's ignore trying to come up with a new PoW scheme for each altcoin, and let's ignore the possibility of shifting external hashrate for 51% attacks, so that attacks can only occur from shifting hashrate between sidechains. Etc.)
For simplicity, consider a consortium of 10 altcoins that want to pool their hashrate, who all share this tiny parent chain in addition to their own. The parent chain block headers (there are no block bodies) are of a fixed size struct such as this:
Code:
// pseudocode
pooled_block {
height: u32,
time: u32,
parent_pooled_block_id: u256,
sidechain_block_ids: {
sidechainA: u256,
sidechainB: u256,
...
}
}
weight = hash(pooled_block)
weight = pooled_block.sidechain_block_ids.map(hash).sum() // alternative
pooled_block {
height: u32,
time: u32,
parent_pooled_block_id: u256,
sidechain_block_ids: {
sidechainA: u256,
sidechainB: u256,
...
}
}
weight = hash(pooled_block)
weight = pooled_block.sidechain_block_ids.map(hash).sum() // alternative
The simplest way is for sidechain nodes to weigh their blocks with the parent chain's block id instead of their own. Mining pools would need to run a full node for each sidechain, but regular sidechain nodes would only need to run the parent chain + their own sidechain.
This way, as long as 51% of the hashrate is honest, they are securing all the sidechains (and reaping the block rewards for each) at the same time.
Another possibility is for the parent chain blocks to be weighed by the sum of the hashes of the sidechain block ids that they include.
As an aside, the FAQ at https://bitkeys.work/faq.php seems a bit...wrong and alarmist?
He's implying that you need 2^80 (~1e24) tries to get a 50% chance of "colliding with one of those keys" (using the birthday paradox). Which seems pretty bad given the current network hashrate of ~1e20 H/s.
But... I think you'd only be colliding with one of your other zillion collision attempts, not one of the relatively miniscule ~1e8 addresses actually used. Unless my math is wrong. *shrug*
(1eX = 1*10^X)
More info: https://download.wpsoftware.net/bitcoin-birthday.pdf
He's implying that you need 2^80 (~1e24) tries to get a 50% chance of "colliding with one of those keys" (using the birthday paradox). Which seems pretty bad given the current network hashrate of ~1e20 H/s.
But... I think you'd only be colliding with one of your other zillion collision attempts, not one of the relatively miniscule ~1e8 addresses actually used. Unless my math is wrong. *shrug*
(1eX = 1*10^X)
More info: https://download.wpsoftware.net/bitcoin-birthday.pdf
Hey guys, I have an image of a partially corrupted hard drive that might have a MultiBit wallet on it from May 2011. Does anyone know the wallet format that I should scan for?
It would be from version 0.1.x or 0.2.x, but I cant find any binaries of those online. I take it that it used a serialized format, but anything more specific would be very helpful. Magic bytes? Was it plaintext? JSON? XML?
Update: I traced it back to using version 0.1 or 0.2 of the bitcoinj library, which I found sort of a mirror of here:
https://github.com/bitcoin-labs/bitcoinj-minimal/blob/master/core/Wallet.java
It would be from version 0.1.x or 0.2.x, but I cant find any binaries of those online. I take it that it used a serialized format, but anything more specific would be very helpful. Magic bytes? Was it plaintext? JSON? XML?
Update: I traced it back to using version 0.1 or 0.2 of the bitcoinj library, which I found sort of a mirror of here:
https://github.com/bitcoin-labs/bitcoinj-minimal/blob/master/core/Wallet.java