BDB is _only_ used for the wallet. It is not used for peers.dat, for fee_estimates, for indexes, etc.

Different BDB major versions are effectively different systems; very few projects are using the 6.x or likely to begin using it because oracle changed the licensing. 4.x also still recieves bug fixes and Its quite difficult for there to be security bugs in software which is not exposed to the outside world. (Bitcoin can, in fact, also be used with later versions of BDB, but it's somewhat untested-- and the file formats are not backwards compatible, so we don't recommend it).

It sends to peers concurrently; the relay network gateway is local and turns most blocks into 2 or fewer packets.

Because the QT part is now statically linked.

Because the size of a block is limited, the approriate stratey (ignoring transaction dependencies) for miners to use is to order transactions by fees per byte and select in that order.

This is what Bitcoin Core already does.

I responded to this here: https://www.reddit.com/r/Bitcoin/comments/3f1y35/q_is_there_a_deterministic_privatepublic_keypair/ctkj4ff

But this is not currently compatible with Bitcoin (and due to the high verification costs for BLS signatures I dunno if I'd rank it pretty highly).


This isn't compatible with the question's requirement "can publish its master public key".

This would be a massive pratical loss of security for most users.

With the current configuration, entry of the password is authorization to send funds. You can't send funds accidentally. No misclicks or fooling around, or someone telling you to press something over the internet can result in you sending funds without realizing it.  If someone grabs your computer out of your hands or uses it while you've stepped away they will not have access to your funds.

The keys (or their equivilents) are not kept in memory; so if your wallet is encrypted and your system compromised while you're aware of it, you can rescue things by copying off the wallet and NOT entering the key after the compromise. (I've spoken to two people who mentioned being rescued by this, in fact.)

You are not forced to enter the keys at every startup (further exposing them to key loggers or people seeing you typing them). And you are not discouraged from entering in a strong password because you must type it frequently.

Meanwhile, there are two costs:  One has basically no marginal cost:  someone who compromises your computer (or steals it-- if you're not using disk encryption--) can tell what addresses are yours; but they can already tell this from your debug.log, swap file, browser cache, and 1001 other small places that data about your activities on your computer are left around.

The second is that backups aren't private and probably should be encrypted or stored on an encrypted disk.  This could be addressed by seperately completely encrypting backups. ::shrugs::

The comparison to a back isn't really a good parallel. Any computer in the world can connect to your bank website.  Access to your wallet metadata is gated by physical possession of the wallet file, which one normally can't get without access to your computer or your backups and if someone has access to that you've already substantially lost your privacy.

As an aside, BIP39 is a poor design which was explicitly disowned by one of its original authors. It should not be used as a reference for useful behavior.

This is potentially misleading, as may sound to some like you're saying keys resulting from getnewaddress after encryption were also exposed but this isnt the case. Only keys from before the encryption were previously exposed, for the obvious reason.

The protection provided by an encrypted wallet is pretty thin: If a theif person has access to your computer they can add a key logger or the like and then the encryption will not protect you.

Many people forget their keys; especially when they set them before they have any coins at all-- and thus nothing to protect.

Though its hard to collect data, from what I've seen I believe that already passphrase loss events are much more common than wallet thefts prevented by (or preventable by) encryption. Further optimizing for key loss over theft doesn't seem wise to me.

There is, in fact, an argument that as a whole wallet encryption is an anti-feature: that it causes much more loss than it prevents.  The destinction is that loss from forgetting keys (though it's well established that this happens constantly with users) leaves the user feeling like it's their fault and that they were in control; while wallet theft leaves most users (who've not yet really taken responsibility for their system security) feeling like the software is at fault; and so it's socially useful because it leaves people worrying about something they feel like they can control.   I don't know that I buy the argument, ultimately as software authors we're responsible to provide software the best looks out for the users interest. In this case there is a real tradeoff and no magic answer.

Electrum makes the user write down a randomly generated recovery code and re-enter it; and it does a fair amount of work in the UI to prevent the user from just copy/pasting it. It's a good approach, though it's hard to tell how effective it is because one element of failure modes where the user feels they are at fault is that they tend to not report them.

We have the block relay network protocol already. It avoids repetition of data for anyone who wants to use it (each already known transaction is replaced with a two byte reference. A 1MB block takes about 4000 bytes at relay time when all the transactions were well broadcast in advance.

Gavin's own comments was that IBLT probably doesn't not make sense with blocks under "hundreds of megabytes":
09:49 < gavinandresen> morcos: e.g. the IBLT work really doesn’t make any sense until blocks are in the hundreds of megabytes size range.
Given my expirence with an attempted implementation of the earlier block network coding proposal, I wouldn't be shocked to find there was no size at which using set reconciliation over the whole block was a win for normal connectivity and normal CPU speeds (as opposed to things like sattelite connectivity) though we won't know for sure until its implemented.  

Regardless, the data still has to be sent a first time-- which is why in terms of overall capacity (rather than latency) the greatest improvement available from fancier relay is a doubling of capacity from eliminating double transmission-- and this is the case with both IBLT and the relay network protocol. The relay network protocol reduces some bad incentives in mining (e.g. mining without validating or mining empty blocks for faster relay) but it not a silver bullet, nor is IBLT. (Though it does have the advantage of being simple, already existing, avoids some bad incentives against including censored transactions, and likely being much faster than IBLT for current block sizes: Already the relay network protocol is CPU bottlenecked with much of its delay just computing the hashtree (even with a fancy AVX sha256 implementation in the client)).  (At least for large block reed solomon codes, it appears even highly optimized implementations cannot run faster than a few megabits per second on current CPUs... the fountain code like IBLTs should be somewhat faster, but it's unclear how much, especially when operating at near their recovery limit--- the IBLT also requires a CreateNewBlock in the reciever which is currently slower than the whole block-relay-network-process...)

Lightning network and sidechains are not magical things, they're orthorgonal and not alternatives to relay improvements. But since you bring them up: They're both at a _futher_ level of development than IBLT at the moment; though given the orthogonality it's irrelevant except to note how misdirected your argument is...

The explicitly stated goal right in the BIP62 document was a reduction in dependence on OpenSSL for consensus; which the truth and nearly the whole truth all that was missing was that the concern was less theoretical than presented.  But yes, the unstated privately known consensus vulnerability was a driving force for clearing up that ugly corner with BIP66 immediately rather than mopping it up as a side effect of BIP62. Especially due to fact that BIP62's progress has been slow-- and had grown over complicated. The fact that BIP66 accomplished one of the necessary steps will make BIP62 or its logical successor easier to move forward.

If you note from the timeline that BIP62 had already been revised to accomplish a BIP66 like goal prior to us knowing about that specific vulnerability:  We were aware of the risk class in principle before having specific knoweldge with enough concern that we thought it was worth closing off.  Knowing that it was _actually_ exposed had only an impact on timing and sequencing; and only after it was clear that BIP62 was not rapidly converging (unfortunately, in spite of much progress on BIP62 we continued to find problems with it).

It's sad, there is a vastly superior-- simpler, more comprehensive, and with secondary benefits like enabling more degrees between full and SPV-- malleability 'fix' in elements alpha but I don't have any way to get it into Bitcoin, BIP62 is disappointing by comparison (brillant ideas welcome).

This message is technically incohearent-- there is no such thing as a a "commit key", and "op_return spend" doesn't destroy information if there were; achieving what you suggest simply requires people stop upgrading (which is also part of the reason that we do not use automatic 'push' upgrades)----  but I certantly get the _intent_. and it's one I've forelorely expressed multiple time myself, going back years:

That it would be philosophically ideal and achieve the highest security properites if the system were completely involatile, defined by it's own mechnical construction, and any change to it would simply be a different system which people could voluntarily move to by their own free choice. Through this the system would be immune to whilm, political control, or subterfuge in a much stronger sense.

Sadly, that result currently appears to be pratically be beyond the scope of human engineering abilities-- or at least beyond the efforts expended on any software system I'm aware of thus far.

A particular point that I couldn't disclose the time cypherdoc initially made the argument was that the software the network was running at that moment was vulnerable: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009697.html

We've had a pipeline of newly discovered non-public vulnerabilties in the Bitcoin protocol running almost all the time since 2012.  I don't have a great answer to that hard questions, but sadly burying our heads in the sand cannot work-- it would just result in a regular series of potentially devistating "emergency" changes, rather than a orderly, planned, resolution.

CGMiner is GPLed software. Antminer was obligated to distribute the complete cooresponding source to their modifications under the same license. If they failed to do so then antminer would be in violation of the license.

I see nothing wrong with whats being requested here.

This is the argument for TXO commitments.  But it's a storage vs bandwidth tradeoff, instead of storing a (say) 64 byte UTXO entry you need a 2.5KB proof when its spent. It takes some pretty tortued assumptions about storage vs bandwidth costs to make this win unless you assume a very low probablity of being spent and only use the proofs for accurately predicted low probablity of spend transactions.

This would greatly reduce the scope of functionality introducable in future soft-forks.  E.g. CT like private values could no longer deployed, soft-fork increases in coin precision, etc.

aztecminer, I'm afraid you might be failing these excercises: https://www.youtube.com/watch?v=YtLEWVu815o

Hi Tonych, it's always good to have more crypto posts here.

This is normally called a single show signature.

If you search the #bitcoin-wizards logs for that term you'll see some instances of this proposal-- you might find it informative.

As you'll probably see in the logs, I disagree with the claims of this approach preventing doublespends. The result of it, at best, is similar to RBF scorched earth, which many people don't consider to be an improvement.

I also disagree with the claim that it in any way addresses nothing-at-stake; in particular it's already common for schemes to suggest that duplicate signatures void coins (which can be done just by system rules without a single show signature) and yet those schemes also do not solve the nothing at stake problem: you cannot punish someone who has left the system and they can produce their conflicting signatures long after leaving it.

There are some pratical concerns as well.  For example, now ephemeral data k must be securely stored and if lost result in loss of the key.  Signing devices must be carefully stateful and avoid repeated signatures.  If the user pays inadequate fees, they'll have no mechenism to revise their transaction to update them-- as even a completely benign double spend (e.g. one that pays the same destination) would result in key loss.

Less importantly, miners also have free pass to ignore the effects of this scheme and there is a simple non-trustless but private protocol possible to allow someone to have a third party privately mine their transactions. (You put up a 25 BTC bond with the miner, and give them the transaction hash you want them to mine, with a promise that you'll instantly give them the full transaction if they present you with a winning block or else forefeit your bond).

Stealth addresses are linearly related, and the relation is known to the paying party. So if I use the stealth address method to create two one show public keys for you and you sign with both of them, I can derrive your private key. I am not aware of a mechenism to securely generate 'stealth address' pubkeys for single show signature without bilinear groups. If not for this a single round trip schnorr treshold signature would be possible.  [I hope this point makes it clear how tricky working with an intentionally fragile cryptosystem is, as someone could have followed the suggestion in the original post without realizing that they were giving away their private keys.]

This is an inconsiderate bump of a very old thread.


Bitcoin Core has had the ability to set the wallet file name with -wallet= for years. There is no need to rename files, and hasn't been a reason to do so for longer than your account here has existed.  You cannot change the path because if you split the BDB recovery logs and wallet file itself onto seperate media you will end up with irreparabile data corruption if there is an unclean power off with (un)reasonable probablity.

50% is still much better than very low change you have on a late broadcast; I believe one of the revised selfish mining attack papers presented something similar to your suggestion (the original one was just busted).


I've thought before to use a similar rerandomization metric but include some sigmoid function of time so that the randomization is decreasingly likely to reorder the blocks the farther apart they are... but I was unable to find something that I felt I could analyize.

No, the earliest received block. If the header's time were used there is trivial attack where you relay the header as fast as possible and withhold the block.

On the facts the above desciption doesn't describe behavior in the network at the moment-- e.g. backlog isn't there, and substantial amounts of the funds that went into the DOS attack paid for outputs, not fees.

The scheme you describe is scale-free; I see you clarified in later messages that you think the "solution" is dyanmic controls rather than a removal of limit but the bold increase blocksize response in your initial is quite confusing-- more than half your text is spent spinning hyperbole, it would have been much more useful to spend that text on describing what you're actually talking about.

Perhaps most importantly, it does not make a case that the attacker produces increased income relative to his hashpower.  Consider:

Lets imagine your mine with half hashpower. Lets imagine that a block can contain 6000 transactions.  Attacker has 1/2 hashpower.  Offered load is 4000 tx/block.

Attacker crafts 2000/tx block at 1coin/tx fee level. Making the rest match him (plus episilon, which we'll disregard).

His average cost for spam is 1000 coin/block (2000 * 1-rate).
His average income is 2000 coin/block (4000 * rate).  (He doesn't get income from his spam, he saves its cost however; see prior line)
His net income is 1000 coins/block, on average.

Now consider the consolidation of other miners:
Their average cost for spam is 0.
Their average income is 3000 coin/block (6000 * (1-rate)).
Their net income is 3000 coin/block.

Both groups have 50% hashrate, so the non-attacking miner has a fee income of three times greater the attacking miner per unit hashrate!

Normalized for hashrate thats 2000 vs 6000.

----
Lets instead imagine that there is also a backlog of fees episilon beflow the attackers floor, and he mines those instead of his own and that doing this doesn't somehow eliminate the floor effect:

Attacker average cost for spam is 1000 coin/block (2000*1-rate)
Attacker income is 3000 coin/block (6000 * rate)
Attacker net income is slightly under 2000 coins/block, on average.

Honest miners cost for spam 0.
Honest miners income is 3000 coins/block (6000*(1-rate))
Their net income is 3000 coins/block.

Again doesn't work.

----
We can work this for any other size, say  and attacker with 40%:

Attacker cost for spam is 1200 coin/block (2000*(1-rate))
Attacker income is 1600 coin/block (4000*rate)
Attacker net income is 400 coin/block

Honest miners cost for spam is 0 coin/block
Honest miner income is 3600 coin/block (6000*(1-rate))
Honest miner net income is 3600 coin/block.

Normalized for rate, thats 1000 vs 6000.

---

Finally, we already know that the system is not incentive compatible when a single party (or collaborating conspiracy) has more than 1/3rd of the hashrate: http://arxiv.org/abs/1311.0243   (The results below 1/3rd require information asymetry advantages which are handwavy, but at 1/3rd or beyond no such asymetry is required)-- though such attacks are highly conspicious.


Exactly, like anyone they can generate transactions to drive up fees; large miner hashpower gets a discount on fees; but they still lose funds; and everyone else shares the income.

Great news!