What was petertodd's thing about providing your own proofs and utxos- did that help with blockchain scalability? Probabilistic payments + payment channelsĬentralization ("migrate to postgresql, deprecate p2p network") Payment channels, lightning network, hub-and-spoke stuff Proof-of-treachery (single centralized node, but lots of fraud proofs flying around) Switching everything over to p2sh (smaller) Utxo scaling with p2sh to make multisig smaller (done) Libsecp256k1 performance, optimization, etc. My braindump of scalability-relevant proposals: put every previous blockheaders in a merkle tree to get a skip list and get compact spv proofs (proposed in the sidechain whitepaper, but amiller said it's broken), skip list stuff in the sidechains whitepaper, you could drop the sequence number from transactions but we want to use that so no,ġ2:16 distributed hash table lookup for headers (single slide saying "DHT")ġ2:19 bloom filter stuff for spv clients to look up individual utxos,ġ2:21 coin selection / knapsack problem is np-complete probably not much improvements since satoshi's version (might have been same version)ġ2:25 memalloc scalability prolly counts.ġ2:25 bluematt iblt protocol scalability stuffġ2:25 (was large reduction in bandwidth- like 90%) (live set, archival set), non-lightning payment channelsġ2:02 nonmining block signing is technically a scalability proposal (private chain signing stuff)ġ2:15 utxo set + zero-knowledge proof / snark of the entire blockchain history (asymptotically less verification time, unknown size, proof would take forever to create), merklerize the entire blockchain or do the same thing as the compact spv proofs- embed the header. read all satoshi nakamoto posts to bitcointalkġ2:00 treechains, sidechains, bloomtables, libsecp256k1, bdb -> leveldb, block database is maybe leveldb now, utxo scaling with p2sh to make multisig smaller, schnorr signature stuff, tree signatures, not ring signature stuff because it makes scalability worse, borromean ring signature stuff for confidential transactions, spv itself is scalability related, lightning network, atomic cross-chain swap stuff, centralized proposals and off-chain stuff, look at gmaxwell's hardfork wish list, look at gmaxwell's altcoin wishlist, merkelized abstract syntax trees (script executing happens in the merkle tree, satisfying a script only needs to reveal the merkle branch (both scalability and privacy)) ((tree sigs are a special case), drop the OP_RETURN data proposals, drop old utxos (petertodd has a thing about recovering old dropped utxos with some proofs) (you keep your own utxos) bitcointalk deep dive of technical subforum: only 185 pages of threads, get thread list in a single. bitcointalk shallow dive: all threads started by above list of people You, sipa, petertodd, adam3us, maaku, socrates1024, killerstorm, tiernolan, jgarzik, etotheip, jl2012, gavinandresen, mike hearn, satoshi nakamoto (none? wtf), wumpus, jtimon, nanotube, bytecoin what's the performance of libsecp256k1? how many bitcoin transactions per second can be signed by libsecp256k1? openssl? etc. how many bitcoin transactions per second can be created outside of the network? Bryan's list of max block size proposals that was sent to the bitcoin-dev mailing list
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |