Bitcoin Forum
June 30, 2022, 07:48:37 AM *
News: Latest Bitcoin Core release: 23.0 [Torrent]
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 3 4 5 6 »
1  Bitcoin / Development & Technical Discussion / Re: Patching The Bitcoin Client To Make It More Anonymous on: July 15, 2011, 12:10:54 AM
I'd like it be be in the main client, but I'd like it to be called "privacy mode", as opposed to "advanced view", for its educational effect. 

For further educational effect, privacy mode could enable informational warnings that let you know which addresses/identites are being linked during a transaction.

If address labels have multiple entries: identity, one to distinguish same-identity addresses, and an "Is Reused?" checkbox for send addresses that you know or expect get reused with multiple people, then the messages generated can be much more personalized and succinct, and will hit home better.

Imagine if when you tried to send some bitcoins you got a warning like this:


This transaction will reveal to


That you own 957 BTC minus the 2 you're currently sending to them, and that you received 955.5 of them from RichMistress on June 2, 2011 at 11:38 AM (for extra effect, assume her identity is public knowledge because you know she reuses addresses with multiple people Wink), and 1.5 from address 1B... on May 1, 2011 at 4:56 PM.


That you're sending 2 BTC to address 1M... right now, and that you received 1.5 from address 1B... on May 1, 2011 at 4:56 PM.


That you're sending 2 BTC to address 1M... right now, and that you received 955.5 BTC from RichMistress on July 12, 2011 at 11:38 AM.

If this is too revealing, then use the Send To Address tab to manually select the addresses to send from.

Or maybe replace ShadyDude with Wikileaks' public address, and RichMistress with BusinessIPatronize (who happens to reuse the same address and needed to send you a refund one time, and who is now being subpoenaed by the Stasi into identifying you as the owner of the address the sent the refund to in order to prove you donated to Wikileaks).

Clearly address reuse is really bad for privacy, and the consequences are not internalized to the address re-users, so I think new address requests (and labeling) should be automated for all clients, not just privacy-conscious ones.

Sorry if this is obvious or flawed - I'm new to this stuff - but here's an idea for how to do this:

This can be done by having a contacts list, and a single master public key from each of their contacts, from which they can deterministically derive as many addresses as they want.  These addresses can't be associated by outsiders as long as the master public key is kept secret.  See this post by Stefan and the one below by gmaxwell about choosing a sequence of serial numbers for how it might be implemented: .

Of course lost master private keys will be a problem, but this can be mitigated by users having (untrusted) storage servers that serve the master public keys to their contacts (the same one that syncs your everyday-use wallet between devices?).  This way they can be easily changed at any time, all at once, and in one place, if necessary, and the contacts will always check that they're up to date.

Hopefully privacy mode would also turn on Tor as well.

Considering the "Bitcoin is anonymous" spin in the media, I really think we're going to have a lot of people unwittingly find themselves in a lot of trouble with criminals, spouses, friends, governments, etc. if they can't easily learn how Bitcoin is working for them in practice.  Somebody said here that users aren't stupid, but the client is making them stupid, and I completely agree.
2  Bitcoin / Development & Technical Discussion / Re: Deterministic wallets on: July 14, 2011, 04:34:53 AM
I wanted to share some thoughts about how Webcoin is going to handle DWs. I'll use the same symbols as TierNolan.

First of all, I don't see the need for a seed. Since the seed has to be stored with the private key anyway, you might as well regard it as part of the private key.

Next, the master private key should have a full 256-bits of entropy. So we use a random number 0 < a < 2256. Yes, it's a pain to type. In practice you'd normally use more convenient ways to transfer DWs, such as USB sticks, QR codes, etc.

(However, if your house just burnt down and you lost every backup but the printed hardcopy at your safety deposit box, I don't think having to type a very long password is going to concern you too much.)

Here is an example of a 256-bit number using base58 encoding:


In reality we'll also add a checksum and a version byte, similar to a Bitcoin address.

In our version, there is no seed, so we've been working with v(t, n) instead of v(n, t, s).

t ... type is included only for future use. Currently it is a zero-length string, i.e. it is omitted.
n ... serial is a 64 bit unsigned integer (LE).

So a new keypair b, B is generated as:

b = a + SHA256(A t n)
B = A + SHA256(A t n)*G

A is an ECPoint encoded using standard non-compressed form (0x04 x y)

To generate a new public key for the wallet, you need to know A, t and the next serial number to use.
To spend the coins on any of the addresses, you need to know a, t and the serial number.

During normal use, we assume that we have access to a metadata storage system. The metadata storage is retrievable using an access key SHA256(A "access"). It's contents are unencrypted, symmetrically encrypted or asymmetrically encrypted depending on the application. For example, a merchant server whose only job is generating addresses would encrypt metadata for those transactions using a public key and the wallet would retrieve it using the corresponding private key. That way, if the merchant server is compromised, privacy for previous transactions is still guaranteed.

If the metadata is lost for any reason, the user can use a recovery tool to get their coins back. The recovery tool needs a full database of unspent outputs in the block chain and will simply generate public keys using sequential serial numbers using the method above. Whenever it finds coins it will add an entry to a new metadata array.

Note: Using t will make coin recovery more difficult, because the recovery tool will have to a) know all values for t and b) separately scan them all. That's why we're more interested in keeping t an empty string for all normal use cases and using the metadata to synchronize what the next available serial number is.

The maximum number of addresses for one wallet is 264 or 18,446,744,073,709,551,616 (for each t).

As long as a and s are protected, the user can never be unable to spend his coins and as long as a is kept secret, nobody else can spend his coins.

Correct. I want to add one more: As long as the master public key A is secret, nobody can break the privacy of the other addresses.

Am I correct in thinking that if you keep A a secret between you and a friend, and agree to use some agreed upon sequence of serial numbers (could this just be trivial and the same for everyone?), that they could have access to an infinite number of your public keys that can't be associated by an outsider?  Edit: lol I think you just said this in the last sentence.

If so, then it seems like it could enable people to interface in the client with a contacts list instead of ugly addresses, but without having to reuse them or manually request new ones all the time.

I guess one major problem would be losing the master private key, and having people continue to send to addresses derived from the associated public key.

This could be mitigated by having your contact instead for each transaction get the master public key from an (untrusted) online storage server who stores it encrypted to your private key and your contact's public key, and check that it hasn't changed.  That way if you lose your wallet, you can stop everyone from sending to it in one step by deleting the master public keys from your storage server, and restart it again by uploading new ones for each of your contacts, without having to notify them, since their client can just start the agreed upon serial number sequence anew if they notice that the master public key has been changed.

Edit: Damn, I read your post two days ago, and forgot to re-read it before responding.  I apologize for basically restating what you did.
3  Bitcoin / Development & Technical Discussion / Re: Patching The Bitcoin Client To Make It More Anonymous on: July 14, 2011, 02:03:55 AM
Can this get into the main release as an "advanced" option selection?
Was just about to say the same thing.
4  Bitcoin / Development & Technical Discussion / Re: Proof of stake instead of proof of work on: July 13, 2011, 11:08:16 PM
Edit: I think my questions were answered in this post

My curiosity won't stop nagging, so here's some bounties
5  Bitcoin / Development & Technical Discussion / Re: Proof of stake instead of proof of work on: July 12, 2011, 04:21:10 AM
By the way, if you're interested in delegated voting, I wrote a paper on using it in a democracy some time ago:

I think delegating voting is a great idea. I'm less convinced that it would work for replacing hashing in the block chain, but it might.

Some more problems for you to consider:

  • If I control a key with 10 delegators, then I spend that key to 10 new keys, what happens to the delegations? Does it make sense for a key to have fan-out (ie 1 key to delegate to 10 other keys)? Do you split the value evenly or not?
  • How do you efficiently detect and resolve delegation loops? ie, key A delegates to B, B delegates to C and C then delegates to A? You have to do this efficiently because otherwise setting up new delegations is a way to DoS the system. Note that detecting cycles in a large graph is slow, Tarjans algorithm is O(number of edges). If each key in the system takes part then every new address in the system potentially makes setting up new delegations harder. As the number of keys in the system grows without bound over time, that could be an issue
  • Keys are owned by end users who may or may not know/care about the inner workings of their currency. How do you get new users to delegate appropriately?

It should be possible to run a parallel block chain based on proof-by-stake, but using the same transactions. It could be done with an adapted Bitcoin software. Once such a chain was up and running you could compare the results vs the existing chain.

I don't have the time/energy to do this myself.
Thanks for the link!

Please forgive all the parentheses in the following...

The first two problems you listed I think can be avoided by treating votes just like bitcoins, but having "election cycles" to compensate for their irretractablility.  For every election cycle (measured by some fixed number of blocks that is limited by the cost and time of running an election), every bitcoin address (or a uniquely determined address, so that bitcoin-containing private keys don't have to be network facing) is issued an equal number of "votecoins".  (Can actual blockchain-recorded transactions be avoided for this issuance?  Can it be done by an understanding that spends from the determined votecoin address up to the amount contained in the determining bitcoin address at the start of the election cycle are allowed during the the election cycle?)  During the rest of the election period, the network will accept votecoin transactions only for those issued during the current election cycle, until the end when some fixed number of addresses containing the most votecoins are elected to be the "representatives" during the next election cycle.

I'm not sure how resource intensive this search for the top votecoin containing addresses would be.

Perhaps voter participation could be incentivized using some portion of the transaction fees and newly issued bitcoins.  I'm reluctant to propose schemes to do this, though, since all the ones that I can think of don't really produce the right incentives, and also create perverse ones.  The larger bitcoin holders obviously have an interest in delegating their votes, but hopefully a really simple UX (vote delegation needs to be automated every election cycle according to user inputted delegates and weightings) and some peer pressure/annoying requests from the client/P. Diddy would be enough to motivate the rest.  Then again, maybe it won't matter if a bunch of the bitcoin-poor don't care enough to vote.

Notice that the public nature of the votecoin transaction history would help keep the delegates honest/effective.

Also note that storage requirements shouldn't be an issue since votecoin transactions from old election cycles don't need to be held on to.

Miners still seem to be necessary to keep time and bundle transactions, but the hashing power/reward they require could possibly be minimized the elected representatives' ability to regulate/make recommendations in the block selection process.

And if all the representatives are really doing is making recommendations to miners, then wouldn't only the miners have to be checking their signatures, usually?  This could allow for a much greater diversity of representatives, since the miners are already geared to accommodate higher overhead than clients.  I figure the only time the clients would need to check the signatures of the representatives is if the miners wanted to ignore the representatives en masse, creating a longer fork, and the clients wanted to ignore this longer fork.  But this might become too likely an attack vector if a significant amount of the overall hashing power of the miners is made obsolete by this system.

And if it's just recommendations, then would any of this require a separate blockchain/breaking change to the protocol?  Can the votecoin rules (their periodic creation and finite trading period) be accommodated somehow into the existing protocol?

Edit: From Mike, "There is a method of batch verifying ECDSA  signatures that's much faster than normal. It might change the economics of what you want to do: "
6  Bitcoin / Development & Technical Discussion / Re: Proof of stake instead of proof of work on: July 11, 2011, 06:54:28 PM
If there are relatively few delegates then what you have is effectively similar to todays payment networks, in which a few big players with pre-established trust relationships come to a consensus on who owns what between themselves. You'd have invented an open source SWIFT.
It sounds like it could scale to more than just a few.  And the voting power might flow much more easily away from corrupted players than with SWIFT due to the almost zero barriers to retracting votes, and to enter into the market to supplant the established delegates.  Remember, with delegated voting you don't necessarily give your vote directly to who will eventually cast it - you can just pass it on to someone you trust, hopefully solving the problem of rational ignorance/apathy.  That or the bad guys will just buy up all the votes Tongue  Or maybe the good guys will?

I guess the relevant question is if this would do a good enough job of decentralizing the "voting power" and making it accountable?  If so, the benefits listed above (that have survived) seem pretty significant.  It might at least be a good approach to smaller blockchains that don't expect to attract enough outside computing power to keep them secure.

But there are workable proposals for breaking that power and restoring Bitcoin to many thousands of voters again instead of just a few. They haven't been implemented but that's because talk is cheap, whereas working C++ isn't.
That is good to hear!  I understand that proposals from people who obviously aren't qualified to program the shit they propose, not to mention that most of what they propose is indeed shit, probably gets pretty annoying.

By the way, I'm not trying to pour cold water on your idea.
Not at all!  I quite appreciate your thoughtful responses!
7  Bitcoin / Development & Technical Discussion / Re: Proof of stake instead of proof of work on: July 11, 2011, 09:55:56 AM
If there are relatively few delegates, and if they could each store their votes in single addresses, this could save a significant amount overhead for the network as a whole during voting/checking.

I suppose stakeholders by definition have an incentive to delegate their votes in such a way as to minimize the overhead in the network, but could this alone lead to some stable equilibrium?

Maybe you could also cull some necessary amount of the least influential addresses in the vote in order to help to reduce overhead to a workable amount?

I'm not sure if there's a transaction signing scheme to deal with retracted votes though, so I don't know if such a delegated voting scheme can even work.
8  Bitcoin / Development & Technical Discussion / Re: Proof of stake instead of proof of work on: July 11, 2011, 07:50:58 AM
This is the obvious way to do consensus, that doesn't work because of the massive amount of bandwidth needed to have a vote for every bitcoin address in existence.  Keep in mind everyone needs to do this checking too.  The entire point, and clever part, of bitcoin, is the idea that one can trade bandwidth/digital signatures for CPU-intensive "hash signatures" that are very small and easy to verify.

In other words, if you asked someone to design a system like bitcoin before bitcoin came out, what you propose is what most would have said...
Haha, I thought it felt a bit too obvious.  Well at least I have a greater, more justified, appreciation for Bitcoin now.

This whole thing actually came from thinking of a way to solve the checkpoint problem Ben Laurie wrote about.  If votes don't need to occur very often, then would the bandwidth/checking cost be such a big deal?  Is his issue even really a problem?
9  Bitcoin / Development & Technical Discussion / Re: Proof of stake instead of proof of work on: July 11, 2011, 07:13:11 AM
Another thought: Currently there's a problem with very large transfers, since guarding them against double-spending can take days (at least) of confirmations. Paying transaction fees won't help because it can only get it in a block faster, it can't significantly affect block generation rate afterwards.

With the new system (work/stake hybrid approach), senders of large amounts can include a signature fee in addition to the regular miner fee, which goes proportionally to stakeholders who sign the block in which the transaction appears. This will incentivize stakeholders to sign, making the transaction secure without having to wait for more confirmations.
I think a hybrid approach would only allow stakeholders to sign whole blocks that have already been found.  And then miners could defer authority to the stakeholders when they do, and work forward from that block.  This would decrease the confirmation time to 10 minutes on average.  And it would remove the need for checkpoints, making Ben Laurie a happier camper.
10  Bitcoin / Development & Technical Discussion / Re: Proof of stake instead of proof of work on: July 11, 2011, 05:22:35 AM
This change is significant enough to warrant a new genesis block rather than forking the current chain.
I think a fork is more appropriate, since it incentivises the existing userbase to participate and avoids alienating them, and it solves the initial distribution problem, allowing for a very diverse voting group from the start.  I see Bitcoin as having made some progress at solving the social problems (bootstrapping a new currency) just as much as it has solved the technical ones.  No need to throw this progress away IMHO.

I think this will work best together, rather than instead of, hash-based mining. Blocks are confirmed with hashing as normal; this is enough for casual double-spend attempts. When a block is old enough, stakeholders can sign it. If a major attacker tries to build an alternative branch, clients will reject it because it
We already have this in the form of checkpoints in the client software.  You don't need voting for it, because there is no ambiguity or controversy about the identity of the block hundreds of steps ago.    Better to have a check performed by _everyone_ than just people that happen to have a lot of bitcoin already.
But Ben Laurie would be much happier Wink
11  Bitcoin / Development & Technical Discussion / Re: Proof of stake instead of proof of work on: July 11, 2011, 04:52:44 AM
Its not a good idea. It would make Bitcoins follow an unfair distribution. By proving you have stake, which means, many bitcoins, you would simply be proving that you're rich and then the system would be only rewarding the already wealthy to validate transactions, and there would be little incentive to add computer power to the network, which is what the 50 btc block awards are designed for, to be a reward and a stimulus to add robustness and block validation to the network. It would create a rich-get-richer scenario, and bitcoin distribution is already following a power law.
This alternative wouldn't need computing power - that's the point.

Furthermore, if you want more influence in the current system, all you have to do is buy yourself more computing resources.  Morally not much different than buying yourself more bitcoins AFAICT.

Lastly, if the bitcoin-rich (as opposed to the computing power-rich) started "voting" themselves more new bitcoins than the allowed amount, then people would lose confidence in the currency, and the bitcoin-rich would no longer be rich in any meaningful sense.  They have more incentive to maintain the currency's value than the current miners do, it seems.
12  Bitcoin / Development & Technical Discussion / Re: Proof of stake instead of proof of work on: July 11, 2011, 04:40:13 AM
The idea has a huge amount of merit, not necessarily for Bitcoins.

Suppose I start a company and decide to issue its shares as a block chain.  Instead of miners getting 50 shares each, the block chain would be programmed where I just issue all the shares up front to the proper shareholders, etc.  The block chain is used as a means to buy and sell the shares on the peer-to-peer stock market (which doesn't exist yet).  Miners maybe get transaction fees.

In such a case, proof-of-stake voting might be fantastic.

But I don't see what relevance it would have to Bitcoins as they are now known.
Company shares sounds like a great application, too.  The proof-of-stake alternative seems like it could be a good way to prevent unwarranted outside influence from messing with smaller scale public ledgers like they can with proof-of-work.

This unwarranted outside influence also seems to be why alternative Bitcoin implementations don't seem feasible now - you need enough miners to be on board to secure the network against outside attackers, whereas attackers can only come from within using the proof-of-stake alternative.  All it needs is a sufficiently diverse userbase.

This is relevant to Bitcoin as an alternative means of forming consensus on the valid transaction history, or the public ledger at least.  But all it would necessarily borrow from Bitcoin is the public ledger contained in the block chain, in order to co-opt its userbase.
13  Bitcoin / Development & Technical Discussion / Proof of stake instead of proof of work on: July 11, 2011, 04:12:45 AM
I've got an idea, and I'm wondering if it's been discussed/ripped apart here yet:

I'm wondering if as bitcoins become more widely distributed, whether a transition from a proof of work based system to a proof of stake one might happen.  What I mean by proof of stake is that instead of your "vote" on the accepted transaction history being weighted by the share of computing resources you bring to the network, it's weighted by the number of bitcoins you can prove you own, using your private keys.

For those that don't want to be actively verifying transactions, and so that not all private keys need to be facing the network, votes could be delegated to other addresses via some kind of nonstandard Bitcoin transaction.  In this way, voting power would accumulate with trusted delegates instead of miners.  New bitcoins and transaction fees could be randomly and periodically distributed to delgates, weighted by the number of votes they've accumulated, thereby incentivising diversity of the delegates and direct voters.

If the implementation could be done, it proved to maintain at least a similar level of privacy and trustworthiness, and it only minimally complicated the UX, I'm thinking that a proof of stake based fork could out-compete a proof of work one due to much lower transaction fees, since its network wouldn't need to support the cost of the miners' computing resources.  (Note that the vote delegation scheme has bandwith/storage overhead that would offset these savings by some amount which would hopefully be relatively small.)

Some other potential improvements this system could offer:
  • Possibly quicker, more definite confirmation of transactions, depending on how it can be implemented.
  • The "voting power" may be more trustworty, since it would accumulate in a bottom-up fashion via a network of trust, instead of in the somewhat arbitrary way it accumulates now.  (Note the potential problem of vote-buying here.)
  • It would remove the physical point of failure of bitcoin mining equipment, which can be confiscated or made illegal to run.
  • It could be used to provide stakeholders a means of making their voices heard (via the delegated voting system it establishes) when it comes to proposals for software updates and protocol changes.

Anyway, I just wanted to throw the idea out here to see if there are any obvious reasons why it couldn't be implemented, and to hopefully spark a discussion amongst those better qualified than me.

14  Bitcoin / Development & Technical Discussion / Wikileaks fixed spend time retractability suggestion on: June 22, 2011, 09:12:35 PM
Wikileaks recently tweeted a reply ( to a news article spreading FUD about Bitcoin.  In it they suggested Bitcoin "be augmented with a sub currency that has fixed time spend retractability if it is to be successful as a safe storage (as well as exchange) currency for the average person".

I was thinking the purposes of this could be accomplished by the client putting a fixed time delay on sends.  Of course, the user could always have the option to force transactions immediately.

If the recipient needs proof that the sender indeed has the necessary funds to send in the meantime, a message could be signed using the private key associated with an address containing them.

This would also provide some protection against "fat finger trades".

Am I understanding their concerns correctly?  Does this address them, effectively?

Edit: I guess part of their concern is theft.  Hopefully this can just be sufficiently mitigated by better security features in the client.
15  Bitcoin / Bitcoin Discussion / Re: SHA-256 (fixed: maybe) hacked, man gets away with 7 blocks in 10 minutes on: June 22, 2011, 12:27:16 PM
I ran some quick numbers. If I'm correctly understanding the distribution, once the first block was found, the chance of finding the next 6 blocks in that time window was something like 0.0000002. However, this possibility has existed every time a block has been found. The chance of this streak happening at least once in 132000 or so blocks is greater than 99.7%. In fact, there is a very high chance that his has happened more than once. If I find the time, I could do an analysis of the whole block chain to see if this has happened before.

Is there an easy way to extract block timestamps from the chain?
If you evaluated the cdf of a gamma distribution with parameters 7 and 1/10min at 10min to get 0.0000002, and 1 - the pdf of the binomial distribution with parameters 132000 and 0.0000002 evaluated at 0 to get 99.7%, then I think it's correct.  I'm too lazy to calculate it, though.

16  Bitcoin / Bitcoin Discussion / Re: EFF donations and the Bitcoin Faucet on: June 22, 2011, 11:38:08 AM
I personally like the idea of a trust fund for Bitcoin held by some of the developers / elders with the purpose of legal defense for Bitcoin. We could probably work out some kind of trust instrument which ensures it would only be used for purposes in the spirit of the EFF's work. It may well be that the EFF qualifies for the money some day but it shall not be held explicitly for them (due to the reasons mentioned).

Of course, Gavin would have to take the trouble to set this up but I think such a fund might come in very handy for the Bitcoin community and would probably be the closest thing to the original intentions of the donors.

I'm sure such a fund held by reputable members would receive even further donations!
I'm also fine with my donation going to this.
17  Bitcoin / Bitcoin Discussion / Re: EFF donations and the Bitcoin Faucet on: June 22, 2011, 08:47:34 AM
I can pledge 0.5 BTC for the refund thing if I end up getting my donation back.
18  Bitcoin / Bitcoin Discussion / Re: Decentralized Exchange Service on: June 21, 2011, 07:32:30 PM
A federation of servers you don't have to trust is good enough.
19  Bitcoin / Bitcoin Discussion / Re: What's the most important next step for a better functioning bitcoin economy? on: June 21, 2011, 06:10:01 PM

If Bitcoin makes you giddy, then this should too.

It provides the technical groundwork for an entire financial industry done right.
20  Bitcoin / Bitcoin Discussion / Re: EFF donations and the Bitcoin Faucet on: June 21, 2011, 01:00:19 AM
or, return to the donors accounts.

How?  Fill out a form if you donated and tell them how much?
And sign it with the private key associated with the address you donated from.  I think there's a patch that allows you to do this.

Allow this for a certain period of time before sending everything to the faucet.
Pages: [1] 2 3 4 5 6 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!