BofAML's David Woo recently published a "fair value" for bitcoin which included, "Bottom-line: maximum market capitalization for Bitcoin’s as a store of value = $5bn".  This was based on an assumption that Bitcoin will likely not compete meaningfully with gold as a store of value, because it's so volatile and new.

But I wonder how important gold's current volatility is to its owners.  I've been operating under the assumption that gold's modern role in the economy has largely been a hedge against the tail risk of systemic failure of the financial system, and that this is because it's been safe to assume that in a post-fiat world, gold would be remonetized.  Ben Bernanke stated this in response to Ron Paul asking him whether he thought gold was money, and it seems kind of obviously correct to me.  But if gold were to become remonetized, then its volatility would presumably be significantly less than it is currently.

It seems to me that the existence of Bitcoin brings into serious question the assumption that gold would be king in a post-fiat world, and that bitcoin's current relative volatility is rather meaningless for this question.  This would mean that if you're holding gold as a hedge, then you also need to diversify into bitcoin to "hedge your hedge".  I have no idea what percentage, but can it really be assumed to be zero, as Woo implicitly assumed in his analysis?  Even a single percent would introduce massive error in Woo's analysis.

What's up with all the Mastercoin spam in this subforum?  Can you guys try to be a bit more respectful of the other projects and not start a new thread for every single subtopic?  I just counted 19 so far.  I understand you're trying to grow your "mindshare", but it's becoming annoying to even visit here.

[Transaction naming protocol]

Transaction naming protocol
I'd like to propose an extension to the identity protocol that would give a secure unique mapping from your MPK (master public key) to a short, pronounceable, memorable name.  It's simply an encoding of a transactions coordinates in the blockchain into a list of phonemes.  For example (code below), in block 264192:

tx              name
1               ~dus
2               ~mirlep
50             ~harbyr-salmev
8000         ~larryt-norbel
1000000   ~nisneb-neb-rondef

(Last two don't exist in the blockchain, but if they did, these would be their names.)

Motivation:
A very convenient key fingerprint to help with key verification.

For those weird enough to make these their commonly used name (hopefully not in meatspace), key verification is automatic.  These names are sufficiently dissimilar that problems associated with using strings as identities don't exist (I want to do some measurements still).  Using them this way leverages our monkey brain's natural ability to conceptualize social networks and reputation using memorable names.  Of course all of this assumes the monkeys can communicate over multiple independent channels so that a single operator can't replace all the names that are passed around with ones whose keys he holds.

The intention is for certain groups of weirdos to avoid needing a PKI.

Draft proposed standard:
(I'll do a nice job of writing this up if there's any interest, or after I receive some feedback.  Should it go on the wiki?)

Basic rules:
- Transactions take 100 blocks to mature to ensure their blockchain coordinates are unmalleable.
- Names expire after 262144 blocks (~5 years) because it's a good idea to periodically retire keys.
- Names are recycled after 524288 blocks (~10 years) because dead names must be freed up for future use.  Notice the 5 year safety window between name expiry and reuse.
- 8 bit names created every 2048 blocks (~once every 2 weeks) as the first transaction after the coinbase.
- 16 bit names created every 8 blocks as the second transaction after the coinbase.
- 24 bit names associated with the first 32 transactions after the coinbase (but are trumped by the shorter names).
- 32 bit names associated with the first 8192 transactions after the 32nd.
- 40 bit names associated with the first 2097152 transactions after the 8224th.
- The shorter names might create a kind of valuable "blockchain real estate" that miners could earn extra revenue from.
- Different phoneme sets (and alphabets) can simultaneously be used as long as they respect backwards-compatibility to avoid collisions.
- I used phonemes from Urbit:

    Onset phonemes:
      doz mar bin wan sam lit sig hid fid lis sog dir wac sab wis sib
      rig sol dop mod fog lid hop dar dor lor hod fol rin tog sil mir
      hol pas lac rov liv dal sat lib tab han tic pid tor bol fos dot
      los dil for pil ram tir win tad bic dif roc wid bis das mid lop
      ril nar dap mol san loc nov sit nid tip sic rop wit nat pan min
      rit pod mot tam tol sav pos nap nop som fin fon ban por wor sip
      ron nor bot wic soc wat dol mag pic dav bid bal tim tas mal lig
      siv tag pad sal div dac tan sid fab tar mon ran nis wol mis pal
      las dis map rab tob rol lat lon nod nav fig nom nib pag sop ral
      bil had doc rid moc pac rav rip fal tod til tin hap mic fan pat
      tac lab mog sim son pin lom ric tap fir has bos bat poc hac tid
      hav sap lin dib hos dab bit bar rac par lod dos bor toc hil mac
      tom dig fil fas mit hob har mig hin rad mas hal rag lag fad top
      mop hab nil nos mil fop fam dat nol din hat nac ris fot rib hoc
      nim lar fit wal rap sar nal mos lan don dan lad dov riv bac pol
      lap tal pit nam bon ros ton fod pon sov noc sor lav mat mip fap

    Coda phonemes:
      zod nec bud wes sev per sut let ful pen syt dur wep ser wyl sun
      ryp syx dyr nup heb peg lup dep dys put lug hec ryt tyv syd nex
      lun mep lut sep pes del sul ped tem led tul met wen byn hex feb
      pyl dul het mev rut tyl wyd tep bes dex sef wyc bur der nep pur
      rys reb den nut sub pet rul syn reg tyd sup sem wyn rec meg net
      sec mul nym tev web sum mut nyx rex teb fus hep ben mus wyx sym
      sel ruc dec wex syr wet dyl myn mes det bet bel tux tug myr pel
      syp ter meb set dut deg tex sur fel tud nux rux ren wyt nub med
      lyt dus neb rum tyn seg lyx pun res red fun rev ref mec ted rus
      bex leb dux ryn num pyx ryg ryx fep tyr tus tyc leg nem fer mer
      ten lus nus syl tec mex pub rym tuc fyl lep deb ber mug hut tun
      byl sud pem dev lur def bus bep run mel pex dyt byt typ lev myl
      wed duc fur fex nul luc len ner lex rup ned lec ryd lyd fen wel
      nyd hus rel rud nes hes fet des ret dun ler nyr seb hul ryl lud
      rem lys fyn wer ryc sug nys nyl lyn dyn dem lux fed sed bec mun
      lyr tes mud nyt byr sen weg fyr mur tel rep teg pec nel nev fes
      
In more detail (Rough draft!  Please chime in with any advice!):

Code:

import sys
import binascii
import hashlib

# (un)hexlify to/from unicode, needed for Python3
unhexlify = binascii.unhexlify
hexlify = binascii.hexlify
if sys.version > '3':
    unhexlify = lambda h: binascii.unhexlify(h.encode('utf8'))
    hexlify = lambda b: binascii.hexlify(b).decode('utf8')

class Swizzler(object):
    ''' Balanced Feistel network.  Operates on bit strings of even length.  Key expansion and round function based on SHA256. '''
    def __init__(self, key=None, rounds=20):
        key = unhexlify(''.zfill(64)) if key is None else key
        K = [hashlib.sha256(key).digest()]
        for i in xrange(rounds):
            K.append(hashlib.sha256((K[-1])).digest())
        self._K = K
        self.r = rounds

    def _F(self, i, x, m):
        x = self._K[i] + unhexlify(hex(x)[2:].zfill(512))
        x = int(hashlib.sha256(x).hexdigest(), 16)
        return int(x & m)

    def E(self, b):
        assert len(b) & 1 == 0
        n = len(b)/2
        m = (1 << n) - 1
        x = int(b, 2)
        R = x & m
        L = x >> n
        for i in xrange(self.r):
            tmp = R
            R = self._F(i, R, m) ^ L
            L = tmp
        return bin((R << n) + L)[2:].zfill(2*n)
         
    def D(self, b):
        assert len(b) & 1 == 0
        n = len(b)/2
        m = (1 << n) - 1
        x = int(b, 2)
        L = x & m
        R = x >> n
        for i in reversed(xrange(self.r)):
            tmp = L
            L = self._F(i, L, m) ^ R
            R = tmp
        return bin((L << n) + R)[2:].zfill(2*n)

class BlockchainNamespace(object):
    ''' Martian namespace for transactions in the Bitcoin blockchain. '''
    def __init__(self):
        self.swizzler = Swizzler()
        self.sis = ['doz', 'mar', 'bin', 'wan', 'sam', 'lit', 'sig', 'hid', 'fid', 'lis', 'sog', 'dir', 'wac', 'sab', 'wis', 'sib', 'rig', 'sol', 'dop', 'mod', 'fog', 'lid', 'hop', 'dar', 'dor', 'lor', 'hod', 'fol', 'rin', 'tog', 'sil', 'mir', 'hol', 'pas', 'lac', 'rov', 'liv', 'dal', 'sat', 'lib', 'tab', 'han', 'tic', 'pid', 'tor', 'bol', 'fos', 'dot', 'los', 'dil', 'for', 'pil', 'ram', 'tir', 'win', 'tad', 'bic', 'dif', 'roc', 'wid', 'bis', 'das', 'mid', 'lop', 'ril', 'nar', 'dap', 'mol', 'san', 'loc', 'nov', 'sit', 'nid', 'tip', 'sic', 'rop', 'wit', 'nat', 'pan', 'min', 'rit', 'pod', 'mot', 'tam', 'tol', 'sav', 'pos', 'nap', 'nop', 'som', 'fin', 'fon', 'ban', 'por', 'wor', 'sip', 'ron', 'nor', 'bot', 'wic', 'soc', 'wat', 'dol', 'mag', 'pic', 'dav', 'bid', 'bal', 'tim', 'tas', 'mal', 'lig', 'siv', 'tag', 'pad', 'sal', 'div', 'dac', 'tan', 'sid', 'fab', 'tar', 'mon', 'ran', 'nis', 'wol', 'mis', 'pal', 'las', 'dis', 'map', 'rab', 'tob', 'rol', 'lat', 'lon', 'nod', 'nav', 'fig', 'nom', 'nib', 'pag', 'sop', 'ral', 'bil', 'had', 'doc', 'rid', 'moc', 'pac', 'rav', 'rip', 'fal', 'tod', 'til', 'tin', 'hap', 'mic', 'fan', 'pat', 'tac', 'lab', 'mog', 'sim', 'son', 'pin', 'lom', 'ric', 'tap', 'fir', 'has', 'bos', 'bat', 'poc', 'hac', 'tid', 'hav', 'sap', 'lin', 'dib', 'hos', 'dab', 'bit', 'bar', 'rac', 'par', 'lod', 'dos', 'bor', 'toc', 'hil', 'mac', 'tom', 'dig', 'fil', 'fas', 'mit', 'hob', 'har', 'mig', 'hin', 'rad', 'mas', 'hal', 'rag', 'lag', 'fad', 'top', 'mop', 'hab', 'nil', 'nos', 'mil', 'fop', 'fam', 'dat', 'nol', 'din', 'hat', 'nac', 'ris', 'fot', 'rib', 'hoc', 'nim', 'lar', 'fit', 'wal', 'rap', 'sar', 'nal', 'mos', 'lan', 'don', 'dan', 'lad', 'dov', 'riv', 'bac', 'pol', 'lap', 'tal', 'pit', 'nam', 'bon', 'ros', 'ton', 'fod', 'pon', 'sov', 'noc', 'sor', 'lav', 'mat', 'mip', 'fap']
        self.dex = ['zod', 'nec', 'bud', 'wes', 'sev', 'per', 'sut', 'let', 'ful', 'pen', 'syt', 'dur', 'wep', 'ser', 'wyl', 'sun', 'ryp', 'syx', 'dyr', 'nup', 'heb', 'peg', 'lup', 'dep', 'dys', 'put', 'lug', 'hec', 'ryt', 'tyv', 'syd', 'nex', 'lun', 'mep', 'lut', 'sep', 'pes', 'del', 'sul', 'ped', 'tem', 'led', 'tul', 'met', 'wen', 'byn', 'hex', 'feb', 'pyl', 'dul', 'het', 'mev', 'rut', 'tyl', 'wyd', 'tep', 'bes', 'dex', 'sef', 'wyc', 'bur', 'der', 'nep', 'pur', 'rys', 'reb', 'den', 'nut', 'sub', 'pet', 'rul', 'syn', 'reg', 'tyd', 'sup', 'sem', 'wyn', 'rec', 'meg', 'net', 'sec', 'mul', 'nym', 'tev', 'web', 'sum', 'mut', 'nyx', 'rex', 'teb', 'fus', 'hep', 'ben', 'mus', 'wyx', 'sym', 'sel', 'ruc', 'dec', 'wex', 'syr', 'wet', 'dyl', 'myn', 'mes', 'det', 'bet', 'bel', 'tux', 'tug', 'myr', 'pel', 'syp', 'ter', 'meb', 'set', 'dut', 'deg', 'tex', 'sur', 'fel', 'tud', 'nux', 'rux', 'ren', 'wyt', 'nub', 'med', 'lyt', 'dus', 'neb', 'rum', 'tyn', 'seg', 'lyx', 'pun', 'res', 'red', 'fun', 'rev', 'ref', 'mec', 'ted', 'rus', 'bex', 'leb', 'dux', 'ryn', 'num', 'pyx', 'ryg', 'ryx', 'fep', 'tyr', 'tus', 'tyc', 'leg', 'nem', 'fer', 'mer', 'ten', 'lus', 'nus', 'syl', 'tec', 'mex', 'pub', 'rym', 'tuc', 'fyl', 'lep', 'deb', 'ber', 'mug', 'hut', 'tun', 'byl', 'sud', 'pem', 'dev', 'lur', 'def', 'bus', 'bep', 'run', 'mel', 'pex', 'dyt', 'byt', 'typ', 'lev', 'myl', 'wed', 'duc', 'fur', 'fex', 'nul', 'luc', 'len', 'ner', 'lex', 'rup', 'ned', 'lec', 'ryd', 'lyd', 'fen', 'wel', 'nyd', 'hus', 'rel', 'rud', 'nes', 'hes', 'fet', 'des', 'ret', 'dun', 'ler', 'nyr', 'seb', 'hul', 'ryl', 'lud', 'rem', 'lys', 'fyn', 'wer', 'ryc', 'sug', 'nys', 'nyl', 'lyn', 'dyn', 'dem', 'lux', 'fed', 'sed', 'bec', 'mun', 'lyr', 'tes', 'mud', 'nyt', 'byr', 'sen', 'weg', 'fyr', 'mur', 'tel', 'rep', 'teg', 'pec', 'nel', 'nev', 'fes']
        self.sis_index = {self.sis[i]:i for i in range(len(self.sis))}        
        self.dex_index = {self.dex[i]:i for i in range(len(self.dex))} 
        
    def coords_to_vint16(self, tx_height, block_height, block_count):
        if block_count < block_height + 100:
            raise Exception("Transaction hasn't matured yet!")
        # Names expire after 262144 blocks (~5 years).
        if (block_count - block_height) >> 18 > 0:
            raise Exception("Transaction's name has expired!")
        if tx_height <= 0 or tx_height > 2097152:
            raise Exception('Transaction out of range!')   
        h = block_height
        t = tx_height
        # 8 bit names created every 2048 blocks (~once every 2 weeks).
        if h & 2047 == 0 and t == 1:
            # Names are recycled after 524288 blocks (~10 years).
            b = bin((h & 524287) >> 11)[2:].zfill(8)
        # 16 bit names created every 8 blocks.
        elif h & 7 == 0 and t == 2:
            b = bin((h & 524287) >> 3)[2:].zfill(16)  
        # 24 bit names created 32/block.
        elif (t-1) >> 5 == 0:
            b = bin(((t-1) << 19) + (h & 524287))[2:].zfill(24)
        # 32 bit names created 8192/block.
        elif (t-33) >> 13 == 0:
            b = bin(((t-33) << 19) + (h & 524287))[2:].zfill(32)
        # 40 bit names created 2097152/block.
        elif (t-8225) >> 21 == 0:
            b = bin(((t-8225) << 19) + (h & 524287))[2:].zfill(40)
        else:
            raise Exception
        # Randomized 1-1 mapping to minimize similarities between consecutive names.
        b = self.swizzler.E(b)
        return [int(b[8*i:8*(i+1)], 2) for i in range(len(b)/8)]
        
    def vint16_to_coords(self, vint16, block_count):
        b = ''.join([bin(n)[2:].zfill(8) for n in vint16])
        b = self.swizzler.D(b)
        n = int(b, 2)
        if len(b) == 8:
            t = 1
            h = n << 11
        elif len(b) == 16:
            t = 2
            h = n << 3
        elif len(b) == 24:
            t = (n >> 19) + 1
            h = n & 524287
        elif len(b) == 32:
            t = (n >> 19) + 33
            h = n & 524287
        elif len(b) == 40:
            t = (n >> 19) + 8225
            h = n & 524287
        assert block_count >= h + 100
        while (block_count - h) / 524288 > 0:
            h += 524288
        return (t, h)

    def encode(self, tx_height, block_height, block_count):
        v = self.coords_to_vint16(tx_height, block_height, block_count)
        name = []
        for i in range(0,len(v)-1,2):
            name.append(self.sis[v[i]] + self.dex[v[i+1]])
        if len(v) & 1 == 1:
            name.insert(abs(len(v)/2-1), self.dex[v[-1]])
        return '~' + '-'.join(name)

    def decode(self, name, block_count):
        v = []
        end = None
        for w in name.lstrip('~').split('-'):
            if len(w) == 3:
                end = w
            else:
                v.append(self.sis_index[w[:3]])
                v.append(self.dex_index[w[3:]])
        if end:
            v.append(self.dex_index[end])
        return self.vint16_to_coords(v, block_count)

[Symbiotic Zerocoin alt-chain:]

The Zerocoin people are going to release a library in a couple days that any Bitcoin protocol-based currency can implement.  The problem with Bitcoin implementing it directly is that it's very cumbersome - transactions are large and verifying them is CPU intensive.  The result would be that Bitcoin would have a much harder time staying decentralized while it scales up.  However, alt-coins will undoubtedly implement it, and compete with Bitcoin for market share.  In anticipation of this, I'd like to describe a way that a Zerocoin alt-chain could be implemented that would reinforce Bitcoin, rather than destabilize it, as well as the incentives that the existence of Zerocoin alt-chains creates for Bitcoin miners.

Symbiotic Zerocoin alt-chain:

Zerocoin could be implemented on an alt-chain that's merge-mined on the Bitcoin blockchain, where new currency units are allowed to be created (perhaps at a limited rate) by anyone who has provably destroyed an equivalent number of bitcoins (using OP_RETURN), and mining the Zerocoin chain is incentivized by transaction fees and the value that a strong symbiotic Zerocoin chain would add to Bitcoin.  The market would determine the amount of bitcoins that move over to the Zerocoin chain; if the value of a zerocoin rises much beyond that of a bitcoin, then people would tend to turn bitcoins into zerocoins and profit off of the difference.

By functioning symbiotically, the bitcoin unit of account would be reinforced instead of destabilized - the Zerocoin chain would act like "a rising tide that lifts all boats" instead of only its own at the expense of bitcoiners'.  Zerocoin mining revenues would go toward strengthening the combined mining network.  Users wouldn't have to speculate on how many of their bitcoins they need to trade for zerocoins, and at what price, in order to retain their purchasing power.  If Zerocoin turns out to have seriously damaging bugs or scalability issues, then conservative users that keep their long-term value parked on the Bitcoin chain won't have to worry about going down with the ship.  This would also set a nice precedent that new coins can be adopted without threatening the stability of their predecessors.

Incentives faced by Bitcoin miners:

If the demand for a Zerocoin chain is large, then Bitcoin miners collectively have an equally large incentive to provide one in order to avoid losing market share, and they are in a position to provide by far the most secure one.  They could mine an alt-chain that competes with Bitcoin, but I hope they see that the correct collective strategy (https://en.wikipedia.org/wiki/Nash_equilibrium) is to mine a symbiotic one like I described above, and only that one.  By mining a competing one, a miner might earn more immediate inflation revenues (though profitability will in any case be driven down to a minimum in the long run due to stiff mining competition), but they would do so by reducing the utility of Bitcoin as a store of value, and thus cryptocurrencies in general: if the flagship one can't preserve this functionality in the face of new innovations, then people will recognize that likely none of them will be able to.  In turn they would detract from the future value of their own hardware.

To get a sense of the incentive of a miner to preserve the store of value function, consider that a single person storing $100,000 in value for a year contributes to the overall valuation of the currency during that time as much as a thousand people that casually use it for transactions and only keep on average $100 stored in it at any given time.  It thus strikes me as potentially important enough of an issue in some cases for miners to actively discourage the merged-mining of alt-chains that detract from Bitcoin's store of value functionality, by refusing to build on blocks that do this, and by merged-mining symbiotic alternatives.

It's well known that if mempools are well-synchronized, then only a few bytes per tx hash (the txid) are required to uniquely identify txs in mempools during the propagation of new blocks.  This has the potential to significantly lower orphan rates and bandwidth requirements of miners, and keep the anonymous mining of large blocks feasible.

I've heard some devs describe the problem of synchronizing mempools as the same one that Bitcoin itself solves - namely, agreeing upon a single consistent transaction ordering - and so a solution isn't theoretically possible.  I can see this would be true if mempools didn't permit conflicting spends and transaction orderings; is this the case?

If mempools are designed to accommodate potentially conflicting spends and transaction orderings, then they can be inclusive to all potentially valid transaction sets waiting to be included in blocks, making the synchronization problem simple.  The only potential problem then would be spam, which could be dealt with by nodes requiring periodic proof of work for persistent mempool inclusion - something miners would be producing anyway, and would have ample incentive to widely distribute.  Furthermore, because having transactions downloaded and verified in advance of receiving them in new blocks lightens the load on a node, it's in one's interest to make sure they've got the txs miners are working into future blocks.  It's also in their interest to kick nodes that don't maintain good synchronization in order to lower overall orphan rates for the good of the network - less wasted hashing power means more secure transactions for all, including them.

Essentially the mempool would encode a set of directed acyclic graphs, each of which describe valid tx orderings, and upon receiving the txids in a new block, a node would check whether the DAG they describe is in the aforementioned set.

I'm admittedly not familiar with how the mempool is currently designed, but the above characterization of the synchronization problem suggested to me that this might be the way to think about a solution.

[tldr; If the mining network relies on specialized rather than generalized hardware, then there is a "nuclear option" available to deal with and deter >50% attacks.]

I recently heard Dan Kaminsky mention in his recent article: http://www.wired.com/opinion/2013/05/lets-cut-through-the-bitcoin-hype/ that a mining algorithm friendly to general purpose hardware is superior because it is more inclusive to "the masses", as it wouldn't require specialized hardware to participate, and thus mining would be that much more decentralized.  I doubt this is much of an advantage though, as most people would have to buy high end general purpose hardware specifically to mine anyway in order to remain competitive and profitable, and the barrier to entry for running specialized hardware (ASICs) will soon be just as low.

Furthermore, having a mining algorithm require specialized hardware appears to be a great strength.  E.g. suppose an attacker amasses >50% of total hashing power.  Then the network could (as a last resort) swap out the mining algorithm, and render all of his equipment useless for attacking the new system and for resale. With general purpose equipment, he could keep attacking the new mining algorithm, or resell his equipment to recoup some of his costs.  While the honest miners would lose all of their investment (this should be considered an inherent risk of being in the mining business), they still collectively lose less than the attacker.  As long as there remains sufficient profit motive to mine - i.e. BTC remains valuable - then ASICs for the new algorithm should be quickly forthcoming to the market while CPUs/GPUs pick up the slack, and any attacker wishing to continue this attack will quickly go bankrupt as he's up against the capital stock of the whole world.

The damage the attacker does - e.g. the drop in BTC value - can be mitigated if such a response is understood by all to always be potentially necessary, and perfectly within the realm of manageability (it seems to me to be, unless I'm missing something).  "Fire drills" might even be done in advance, which would undoubtedly inspire confidence.

tldr; If the mining network relies on specialized rather than generalized hardware, then there is a "nuclear option" available to deal with and deter >50% attacks.

I made a simple model to help explore how people might interact with the Bitcoin blockchain in the future.  It assumes that the number of users grows via a logistic function (common for population growth and diffusion of innovation modeling).  For example:



And with log scaling:



It lets you set a desired number of blockchain transactions per month users should have access to on average, and gives you the block size limit required to achieve this.  It compares this with the block size limit that grows at the same expected rate as bandwidth.  For example:



This "natural" block size limit results in some number of blockchain transactions per month users will have access to on average:



Here's the MATLAB/Octave code if you want to play around with the parameters:

Code:

n = 2;      % Target average number of txs per user per month.
P0 = 500E3; % Number of users today.
K = 2E9;    % Expected number of users after full diffusion.
a = 0.5;    % Current (exponential) annual growth rate of users.
b = 0.2;    % Expected annual bandwidth growth rate.
s = 1000;  % Average tx size in bytes.

t = 0:0.1:40;
% Number of users after t years assuming logistic growth function.
P = K*P0*(1+a).^t ./ (K + P0*((1+a).^t - 1));  
% Target block size limit in MB.
B = n/(30*144)*s*P/1E6;
% Block size limit in MB assuming exponential growth alongside bandwidth.
Bnat = (1+b).^t;
% Average number of txs per user per month assuming exponential growth of
% block size limit alongside bandwidth.
nnat = 30*144*1E6*Bnat/s./P;

figure(1);
plot(t, P);
xlabel('Years from now')
ylabel('Expected number of users')

figure(2);
semilogy(t, P);
xlabel('Years from now')
ylabel('Expected number of users')

figure(3);
semilogy(t, B, t, Bnat);
legend([num2str(n), ' txs per user per month target'], 'Natural', 'Location','southeast');
xlabel('Years from now')
ylabel('Block size (MB)')

figure(4);
plot(t, nnat);
xlabel('Years from now')
title('Natural average number of txs per user per month')

Edit: My 2 cents on the block size limit is that we shouldn't be targeting bandwidth growth rate, but user growth rate, and the algorithm should follow a logistic function.  Then we try to deal externally with whatever centralization might result from larger blocks, which are at least bounded in size going forward.

Also added the average tx size explicitly into the code.

The idea is kind of simple, so apologies if it's already been proposed.

The UTXO set size can be controlled by weighting fees with the following function:

W(tx) = sum(w(txinval)) / sum(w(txoutval))

w(v) = 1 if v > v0
     w0 if v < v0

where v0 defines what is considered a "small" valued txout, and w0 is the extra weight given to small valued txins and txouts.

With v0 = 0 the sums reduce to number of txins and txouts.  But a finite v0 means outputs that cost more to spend than they are worth can be discouraged from being created.  For exotic uses of small valued outputs like colored coins, this essentially sets an extra fee for creating them, but not much extra for simply transfering them.  Recombining small txouts gives a fee "bonus".

For example, consider the tx where one small valued txout is created, and the rest of a single normal valued txin is sent as a fee to miners.  Then W(tx) = 1/w0, meaning a fee of w0 times more is required to be accepted on par with this tx, had the txout been of normal value.  This adds an extra cost to expand the UTXO set into practically unbounded territory.

Another example: one txin of normal value spent to fees, and a small valued txin spent to a single small valued output.  Then W(tx) = 1 + 1/w0 (~= 1 for large w0), i.e. not much extra fee is required because the UTXO set is not being expanded.

Finally consider the example of adding a small valued txin to a normal one, and spending this to a single normal valued txout.  Then W = 1 + w0, meaning the usual fee to spend a single normal valued txin to a single normal valued txout is attenuated by a factor of 1/(1 + w0) (~= 1/w0 for large w0) as a bonus for contracting the UTXO set size.

v0 should be set somewhere on the order of the minimum tx fee, and w0 will need to be adjusted by miners to whatever (minimum) value is required to prevent abuse of the UTXO set.

I posted the following bit in a comment in one of the many recent block size limit threads, but it's really a separate topic.

It also strikes me as unlikely that a block size limit would actually achieve an optimal amount of hashing power.  Even in the case where most users have been driven off the blockchain - and some off of Bitcoin entirely - why should it?  Why shouldn't we just expect Ripple-like trust networks to form between the Chaum banks, and blockchain clearing to happen infrequently enough so as to provide an inconsequential amount of fees to miners?  What if no matter what kind of fake scarcity is built into the blockchain, transaction fees are driven somewhere around the marginal transaction fee of all possible alternatives?

This assumption is at the a crux of the argument to keep a block size limit, and everyone seems to have just assumed it is correct, or at least left it unchallenged (sorry if I missed something).

It's been talked about here before that when invalid blocks exist in the longest chain, honest nodes could broadcast short error messages to SPV clients with enough information for them to be able to prove that the block is indeed invalid, and thus be able to reject it.  Unfortunately, one of the most important error messages - that a miner has cheated on his fee reward - requires that the SPV client download the entire block in order to prove it's invalid.  This would become expensive for a smartphone at high transaction rates.

It would also open SPV clients up to attack, since the error message is cheap to broadcast, but expensive to investigate.  Mike Hearn suggested that to mitigate this, these error messages should only be investigated at branching points in the block chain, since presumably there would be some honest miners out there branching off.  The block size limit will also limit the damage an attacker could do to SPV clients.  But if this limit is to eventually be lifted, the hard fork required affords us the opportunity to solve this problem altogether.

This can be done by changing the Merkle tree of transactions slightly.  Instead of taking leaf node value = hash(tx) and branch node value = hash(child 1 value || child 2 value), we would have leaf node value = hash(tx || tx fee) and branch node value = hash(child 1 value || child 2 value || tx fee of child 1 + tx fee of child 2).  Working up the tree recursively, the tx fee value of the root node will be the total fee rewarded to the miner.  An incorrect fee value must then result in an invalid branch in the Merkle tree, which could then be relayed unobtrusively in an error message to an SPV client.

Would it be something that would make it into any hard fork that raises the block size limit?  Other than this one, I can't think of any other block error messages that require the download of more than two Merkle branches to investigate.  Are there any I'm missing?

I keep getting this error when trying to update on Ubuntu 12.04:

Code:

GPG error: http://ppa.launchpad.net precise Release: The following signatures were invalid: BADSIG D46F45428842CE5E Launchpad PPA for Bitcoin

Any help is much appreciated!

I'm wondering:

• Is there a plan yet for when we start bumping up against the block size limit?
• Is it going to be held where it is, pushing fees up and txs to occur off the blockchain on, e.g. Open Transactions servers, as gmaxwell suggested here: https://bitcointalk.org/index.php?PHPSESSID=c5c394d3434101e2874d5cadff6221a6&topic=80435.msg898723#msg89872?
• Or will it be raised somewhat after some scalability optimizations are implemented?
• If so, how high can be raised while still allowing the average PC to run a full node?
• Do the developers all agree for the sake of decentralization to keep this a priority, enforced with a block size limit?
• If so, why are people spending so much time developing lightweight bitcoin clients instead of working on, e.g. OT, if average people are going to be priced out of blockchain txs anyway?

Thanks for any clarification!

Are there any cases where it might be acceptable?

Whole thread is tl;dr = increase confidence that cryptocurrencies in general are a safe store of value that you don't have to babysit by rolling out your new ones, and protocol-breaking updated ones with a peg to BTC, as this strengthens the common currency unit, and solves your initial distribution and valuation problems quickly, and in an economically non-disruptive way.  Do it profitably and in a low-trust way via the "distributed central bank" described here, or come up with a way that the peg can be maintained in a truly trust-free way.


Say a group of people want to create a Bitcoin fork that they think will rival Bitcoin.  This rivalry would normally force people to choose which currency to hold on to, and would create winners and losers.  In order to avoid such a disruption, they could start a whole new blockchain, use Mike Hearn's merged mining, and create a temporary central bank that starts out with the initial distribution of forkcoins, equal to the current supply of bitcoins.

It would then trade bitcoins one-to-one for forkcoins, maintaining a peg.  It can do its trades in a trust-free way via this: https://bitcointalk.org/index.php?topic=22581.msg286054#msg286054, and it could use CHECKMULTISIG to spread the trust in it over many people, in multiple jurisdictions.  Of course it would want to dissolve eventually, so it might state in the beginning that it will begin gradually lowering its bitcoin/forkcoin exchange rate to zero after a given time.  Afterward, it would fulfil a promise to destroy any bitcoins and forkcoins remaining in its possession, so as not to cause any market distortions by releasing them into the market.  Notice that the total bitcoin + forkcoin circulated money supply still grows at the rate that bitcoins alone would have, absent Forkcoin.  They have a symbiotic, rather than rivalrous relationship.

They could even make a business model out of this by charging a fee for issuing or redeeming.

This method could also be used for necessary or experimental protocol updates that break backward compatibility.

tl;dr = Open-Transactions' digital cash, Bitcoin's transaction scripts, and Webcoin's key management scheme can be combined in various ways to solve all the trust issues plaguing the Bitcoin economy, without compromising convenience.

Over-reliance on trust within the Bitcoin economy has obviously failed horribly.  I believe it’s largely unnecessary, so I’m starting this thread to try to converge on some better standards that bitcoiners could reasonably expect from their service providers.

I'll start with a few ideas mostly borrowed from elsewhere: