Bitcoin Forum
May 13, 2024, 01:05:23 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1]
1  Bitcoin / Development & Technical Discussion / Improving the consensus-sensing mechanism for protocol upgrades on: November 12, 2014, 03:21:12 PM
When BIP-16 was adopted, there was a sort of informal vote. Miners were asked to embed their vote in the coinbase transactions of blocks they mined and to switch to the new rules once a majority supported it:

Quote
On February 1, 2012, the block-chain will be examined to determine the number of blocks supporting pay-to-script-hash for the previous 7 days. If 550 or more contain "/P2SH/" in their coinbase, then all blocks with timestamps after 15 Feb 2012, 00:00:00 GMT shall have their pay-to-script-hash transactions fully validated. Approximately 1,000 blocks are created in a week; 550 should, therefore, be approximately 55% of the network supporting the new feature.
BIP 0016

Users / owners / merchants didn't have a direct say. Indirectly they did get to vote with their feet and their transaction fees of course, but in order to avoid accidents it's good to have a mechanism that ensures you don't end up on the minority branch of a fork accidentally, while still influencing the outcome. I thought it might be useful to have a way for people who own or spend bitcoin to have a direct vote.

I'm thinking of something like embedding a vote (the hash of "I vote for/against BIP-XXX", perhaps with a hash of the BIP itself included in the string) in transactions using OP_RETURN. There are complications with this, and it probably not a good proposal as is, but I'd like to explore if we can think of improvements that would turn it into one.

Instead of requiring a majority (or supermajority) of coinbase-based votes in the last N blocks, you could require a double majority, i.e. a majority of coinbase-based votes as well as a majority of ordinary transaction-based votes.

To deal with ballot-stuffing, you could add up votes from the UTXO set at a pre-specified date, weighted by amount of BTC, perhaps limited to outputs belonging to transactions that were entered within the three months immediately preceding the cut-off date.

Complications include the hassle of doing this with coins in cold storage, privacy concerns, censorship concerns.
2  Bitcoin / Development & Technical Discussion / Private keys in RAM on: April 09, 2014, 09:43:01 AM
After the heartbleed scare I've been thinking if perhaps we shouldn't make an effort to store private keys more securely. This isn't a new issue of course, and there are lots of existing techniques and best practices I'm only dimly aware of, including things like PKCS #11 and HSMs. I know work is also being done on Bitcoin-specific hardware solutions like Trezor.

Maybe we all need to move to hardware-based solutions in the future, but maybe there is also room for software-only solutions. Right now most people don't use specialised crypto hardware, and I was wondering if it would help if signing operations were at least located in a separate process with an independent address space. There is a library called SoftHSM which is a software-only implementation of PKCS #11. I think it's supposed to be linked directly to the application, but maybe it can be used as a starting point.

So, what do you think? Would this be a useful near-term improvement, or an undesirable half solution that discourages people from using dedicated hardware, if we believe that's the real solution?
3  Bitcoin / Development & Technical Discussion / Re: TX replacement and nLockTime on: April 07, 2014, 02:28:07 PM
I don't understand how you could ever rely on a newer transaction overriding an older one unless unlocked transactions make it into the blockchain in a "passive mode".
4  Bitcoin / Development & Technical Discussion / Blockchain-based web of trust to replace X.509? on: June 11, 2013, 04:42:34 PM
In light of the recent revelations about the massive warrantless surveillance by the NSA, some people have speculated that the NSA may have direct access to the private keys of some root certificate authorities. If that is true, then they can perform a man-in-the-middle attack against everyone. Would a blockchain structure help provide a distributed alternative that cannot easily be compromised by the NSA?
5  Economy / Currency exchange / Exchange traffic plummeting across exchanges and currencies on: May 20, 2013, 11:08:34 AM
Does anyone here have an idea why this is happening? It seems to be more than just the Dwolla route to Mt Gox being closed, as it affects EUR too and happens on other exchanges as well. AUD and JPY seem to be less affected.
6  Bitcoin / Development & Technical Discussion / Market.h / .cpp on: May 05, 2013, 10:24:06 AM
I just had a quick look at the oldest known version of the Satoshi source code and noticed the presence of market.h and .cpp. Does anyone here know the story of what happened to these files? I could try to search SF, but maybe people here have interesting stories to tell about it. Was this intended to be something like SilkRoad? If so, does it lend credence to the Satoshi = Dread Pirate Roberts theory?
Pages: [1]
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!