Bitcoin Forum
May 08, 2024, 01:06:01 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 2 3 4 5 6 7 8 9 10 [11] 12 13 14 15 16 17 18 19 20 21 22 23 24 »
201  Bitcoin / Mining speculation / Re: $324000 per day on: March 27, 2013, 06:22:41 PM
It's obviously way more than enough to prevent double spends.  But the inflation schedule is not debatable, and the exchange rate is not controllable, so go be windbags about something else.
202  Bitcoin / Development & Technical Discussion / Re: Cross-post from General thread that might be of interest to developers on: March 25, 2013, 03:52:51 PM
I think it's a great idea.  It's been called "fidelity bonds" and "bitcoin passports" previously, and has been discussed here https://bitcointalk.org/index.php?topic=134827.0 and here https://bitcointalk.org/index.php?topic=140711.0.
203  Bitcoin / Development & Technical Discussion / Re: Decentralised crime fighting using private set intersection protocols on: March 25, 2013, 02:04:09 PM
As many others here, I'm very uneasy with the possibility of Bitcoin losing fungibility.

But anyway, this is undeniable:
like it or not, Bitcoin's architecture easily permits this, regardless of Mike's opinion about it.

It's perfectly possible to implement such thing. It's actually possible to implement much nastier things (think of a government-mandated whitelist). Mike Hearn has a point when he says that, in the event of a government trying to impose its regulation, the usage of a totally voluntary and decentralized system like this is preferable. But, should we be "compromising in advance"? Wouldn't that be "negotiating against ourselves"?

Governments can do much worse than killing Bitcoin fungibility. The problem, as always, are governments themselves, not this voluntary system Mike is proposing.

Perhaps we should focus on implementing p2p, anonymous mixing services. Such mixing systems would be essential to keep the "market-based checks-and-balances" Mike describes in OP, if such system ever comes to existence.


If I didn't think my blacklist providers or their investigators were abusing their authority, then I'd participate in this, and I probably wouldn't even feel like I was "compromising" in doing so.  If it proved effective, then I'd continue to participate.  At the very least it shows a good faith effort by the community, and helps build political capital.  And maybe it even helps to track down some legitimately shitty people.
204  Bitcoin / Development & Technical Discussion / Re: Decentralised crime fighting using private set intersection protocols on: March 25, 2013, 01:07:49 PM
I'm sorry, Mike, but this thread demonstrates quite clearly that Bitcoin is the most Orwellian currency in the history of mankind.  (Trackability)

Without fungibility, I think Bitcoin is doomed.  Rather than spending time figuring out how to ruin Bitcoin, effort should be spent on how to adapt Bitcoin (or another cryptocurrency) to be completely fungible.
Whoa, ease off on the hyperbole.  I don't think you're giving our modern fiat currencies nearly enough credit (especially where physical cash will be phased out).  For example, how do you freeze an account under this proposal?  Can you still keep the existence of bitcoins you own secret?  Is (worldwide) coin mixing still a (potential) option when necessary?  Are anonymous, off-blockchain transactions still a (potential) option?

I also think you're underestimating how much serious coordination among all the governments of the world it would take to force a non-voluntary, repressive version of this that's actually effective.  This is not to say a voluntarily used version couldn't be effective - or at least more effective than the current tracking systems in place, whatever that's saying.  But it would at least be harder to abuse, and police would have to actually make phone calls and knock on doors, rather than simply scrape a database without any meaningful consent.

And all the while, as adoption spreads, the human component of the network expands, along with awareness of monetary privacy issues and the political capital required to actually resist, rather than simply hide from, such abuses of power.  I believe people would be much more willing to make a fuss about something that affects them directly, like being enlisted as spies to their fellow citizens, than the current situation where they never actually see the abuse of privacy.  I also believe more aware people will be more willing to adopt better solutions as they may arise.
205  Bitcoin / Development & Technical Discussion / Re: Decentralised crime fighting using private set intersection protocols on: March 24, 2013, 10:03:29 PM
Destroying (i.e. supplanting) a relatively freely-trading thing with a system that makes those things less free and depletes their intrinsic worth?
But clearly appeasing the authorities to a reasonable extent can also lead to Bitcoin being more freely traded.  It's pretty hard to freely trade an outlaw currency.  Let's face reality like adults.

Quote
No, sir, I don't like it.
Haha, I know where that's from Smiley

Quote
It would mean starting fresh. People who care about bitcoin's original intrinsic value would be forced to design a system that's substantially less susceptible to the central hierarchy of a small development crew, "feature" creep, mass pooling, and provider dependency. That would not be an easy task. ...To say the least. If, however, bitcoin ever fell to that point, it would be both a shame and an honorable endeavor.
Not starting fresh at all though.  Cryptocurrency would have already made a big name for itself.  The UTXO set (current spendable coins) can be forked, so use is incentivized, and there's no speculative risk of being "on the wrong chain".  The weaknesses and proper countermeasures would be much clearer.  I'm sure there's more.

Thanks for the thoughtful post.

Edit: Though I hope it wouldn't ever come to having to create a separate underground chain, it's nice to have a contingency plan in mind.
206  Bitcoin / Development & Technical Discussion / Re: Decentralised crime fighting using private set intersection protocols on: March 24, 2013, 09:14:19 PM
Yeah, probably I should have used the term hint list or something. People stop reading at the term blacklist and then start arguing with a proposal that wasn't made. The post from hazek just now being a good example of that ...
What I find kind of ironic about all of this is that the first time I'd heard a proposal similar to yours for using a linkable digital currency for decentralized crime fighting was from a prominent anarcho-capitalist named Stefan Molyneux.  I guess they're just more receptive when these ideas are coming from one of their own. Wink  Not to mention yours is vastly superior due to the cryptographic privacy guarantees.
207  Bitcoin / Development & Technical Discussion / Re: Decentralised crime fighting using private set intersection protocols on: March 24, 2013, 08:02:10 PM

+1

edit; for those who dont have time to visit, the user is calling for a developer black list.

Lol!

This is the great thing about keeping the blocksize small: when you get tired of this Peter Todd guy blattering endlessly about fidelity bonded distributed hash table fraud proofs or whatever the fuck he's smoking with his art school buddies, you can put him on ignore and never deal with him and his complex payment systems again. Just tell whomever you want to pay that you're going to use some other solution. On the other hand, with the One True All Encompassing Blockchain I simply have to use the reference client with Mike's (quite good) LevelDB database patches for every payment I make.

You have a choice.
That seems disingenuous.  What do small blocks do to prevent coin blacklists from being enforced by governments?
208  Bitcoin / Development & Technical Discussion / Re: Decentralised crime fighting using private set intersection protocols on: March 24, 2013, 07:53:33 PM
I heard Jacob Applebaum (from the Tor Project) say once that "the architecture defines the political situation", and like it or not, Bitcoin's architecture easily permits this, regardless of Mike's opinion about it.
209  Bitcoin / Development & Technical Discussion / Re: Decentralised crime fighting using private set intersection protocols on: March 24, 2013, 05:40:18 PM
I'm curious about how people here would react if it became clear that a government ban on Bitcoin was being considered for the reasons Mike mentioned, and your political action wasn't likely to change this outcome.  Would you be willing to compromise and participate in such a self-policing proposal?  Would you thumb your nose at the authorities, and let them ban it?  Or would you perhaps go along with this for Bitcoin, but while participating in an underground fork (which avoids the chaos of transactions being valid on both chains somehow) whose focus was on extreme technical countermeasures to censorship and surveillance?  Or some other option?
210  Bitcoin / Development & Technical Discussion / Re: Funding of network security with infinite block sizes on: March 24, 2013, 04:02:13 AM
With large blocks supporting say 2000 tps, if 20% of transactors "do their part" and pay an economically insignificant $0.01 fee - way more than enough to cover the microcent cost of the actual transaction - then this would add up to $2400 per block in mining fees.  Currently we've got about a $1500 block reward.

So if the optimal hash rate scales sub-linearly with the transaction rate, then it strikes me that if demand permits scaling up of block sizes, then relying on social pressure and client software defaults to yield lots of individually economically insignificant fees is also a solution to the problem of funding of network security.
211  Bitcoin / Bitcoin Discussion / Re: FinCEN addresses Bitcoin on: March 19, 2013, 12:40:15 AM
See some people have not contacted lawyers before jumping into bitcoin businesses, if you contacted your lawyer before doing business in bitcoin, you would know it was always legal.
It's about the law going forward.  Nobody had any certainty about that before.  Jesus, you're such a fucking buzzkill Smiley
212  Bitcoin / Bitcoin Discussion / Re: FinCEN addresses Bitcoin on: March 19, 2013, 12:33:37 AM
tl;dr...  bitcoins are legal

Yeah, I've been jumping with joy for the past 10 minutes Smiley
I also see this as a positive development, especially in the long run.

When was bitcoins ever illegal? LMAO I was jumping for joy over 2 years ago when I got into bitcoins, cause they were never illegal.
You're not happy about having legal certainty, finally?
213  Bitcoin / Bitcoin Discussion / Re: FinCEN addresses Bitcoin on: March 19, 2013, 12:30:50 AM
Well, the way I read it:

Quote from: FinCEN
An administrator is a person engaged as a business in issuing (putting into circulation) a virtual currency, and who has the authority to redeem (to withdraw from circulation) such virtual currency.
emphasis added

While it is possible to "destroy" Bitcoin units, nobody has the authority to redeem it. So there is no such thing as "administrator" of Bitcoin.
The 'De-Centralized Virtual Currencies' section was obviously written with Bitcoin as the prototypical example, and it's pretty clear what the spirit of the law is there IMO.
214  Bitcoin / Bitcoin Discussion / Re: FinCEN addresses Bitcoin on: March 19, 2013, 12:22:27 AM
tl;dr...  bitcoins are legal

Yeah, I've been jumping with joy for the past 10 minutes Smiley
215  Bitcoin / Development & Technical Discussion / Re: How to force a rule change by bloating the UTXO set on: March 17, 2013, 09:28:19 PM
The idea isn't new.
That's unsurprising Smiley
Quote
It also doesn't help much because the UTXO growth limit has to scale with the overall blocksize limit or it becomes difficult to reliably get transactions confirmed.
But it only limits the kinds of transactions we want to regulate in the first place...  Same as a block size limit makes it difficult to reliably get big, space wasting transactions confirmed.  It's up to miners and users to conform to economically optimal usage patterns of scarce block space, so why shouldn't the same apply to scarce UTXO space?
Quote
Since it has to be a significant fraction it still doesn't solve the underlying scaling problem, only buys you time temporarily.
Cool, I know you agree that buying time seems to be the name of the game Smiley
216  Bitcoin / Project Development / Re: Pledging coins for ultimate blockchain compression on: March 16, 2013, 03:39:00 PM
But that's not the rationale that was being given before. I'm not sure why it even helps. You can prove double spending or fake spending of inputs just by providing the transactions and their merkle branches, it's not very intensive. To prove a coinbase is of the wrong size requires more, but how does putting a utxo commitment in every block help with that? You still need to download the entire block to check it's not valid.
That's true, it's not the rationale that was given before.  So if this is to be the current one (to be clear, it's just been my rationale), then it does bring the legitimacy of the pledges into question.  And you're right that it's not needed to prove any of these cases of fraud.

Excuse me while I think out loud for a minute...  On the one hand, having a trustworthy up-to-date commitment of the authenticated UTXO set - trustworthy because you haven't received any fraud proofs for it, and you assume you have at least one honest peer - would let you know for sure that a UTXO that you've received in a transaction hasn't been spent yet.  But on the other hand, it technically only requires one honest peer in the current arrangement to send you proof that such such a UTXO has been spent more recently than you've been led to believe.  So this proposed benefit seems kind of dubious...

The partial verification stuff is becoming less clear the more I think about it too...  But that's a far-in-a-hypothetical-future optimization anyway, to be made only if the number of full nodes becomes too low for comfort.  More important things to be funding currently IMHO.

I guess I'll have to eat my hat on this Wink
217  Bitcoin / Development & Technical Discussion / Re: How to force a rule change by bloating the UTXO set on: March 16, 2013, 02:00:36 AM
As we increase the max block size, we may have a UTXO index, which is the total number of outputs in a block minus the total number of inputs in a block, and have a hard limit for it

Problem solved.
Some txouts are bigger than others, so maybe the sum of the sizes of the txouts created minus the sum of the sizes of the txouts spent would be more appropriate?
218  Bitcoin / Development & Technical Discussion / Re: Max box size should also consider the size of UTXO set on: March 15, 2013, 08:11:48 PM
Using this proposal, we can increase the max block size without bloating the UTXO set
This.

The argument that a block size limit is necessary to prevent excessive centralization applies equally well to a limit on the per block expansion of the utxo set.  So I think this justifies the creation of such a limit, if a block size limit is to be maintained.

Also, I don't see why we would need to have a single metric to describe usage of the two scarce resources, block space and utxo set space.  Wouldn't it be simpler to just have separate limits for both?  They consume distinct physical resources - bandwidth and storage, respectively - and so these parameters should be somewhat orthogonal.
219  Bitcoin / Project Development / Re: Pledging coins for ultimate blockchain compression on: March 14, 2013, 05:40:16 PM
The only reasonable way I've seen to get something in between SPV and full mode is d'aniels suggestions for various kinds of fraud proofs, but the whole point of a fraud proof is that you get one when the best chain is no longer following the rules .... making fraud proofs that rely on trusted commitments to the state of the UTXO set pointless (they would be a part of the fraud).
The SPV clients would be auditing commitments to the UTXO set as well, of course.

Edit: One way I can see to do this is for each block, full nodes keep handy all the branches of the UTXO tree that get updated in the next block.  If they're pruning, then they only have to keep this data a reasonable ways back in the chain.  To audit commitments to the UTXO set in a given block, an SPV node would download transaction merkle branches in this block and the relevant branches in the UTXO tree from the previous block, then check that the commits were done properly, i.e. produce the correct root to the current UTXO tree.
Upon rereading this, a better response would have been to say that this new trust model is "trust what you haven't seen a valid fraud proof disputing".  So if no false updates in the authenticated UTXO set have been proved to you, you assume it to be valid.

It's okay to base a fraud proof on the assumption of validity of the authenticated UTXO set because one could simply construct a proof that it was invalidly updated in order to prove any fraud that followed from this assumption being false.  This is the same as for the other fraud proofs, which all rely on the assumption that previous blocks upon which it was built have been valid.

The partial verification stuff I mentioned in the first response is just icing on the cake that helps ensure that fraud proofs are very likely to be found, even in the event that few full nodes are looking for them.
220  Bitcoin / Bitcoin Discussion / Re: Who will you choose to replacement Gavin, in case something happened? on: March 12, 2013, 11:43:09 PM
Mike Hearn, Pieter Wuille, Jeff Garzik, and Gregory Maxwell all seem very capable.  I've ordered them from less to more conservative (in my view).

I find myself more in line with Mike Hearn, who seems more willing to push the boundaries of this experiment.  But Pieter Wuille seems very thoughtful, and I'd be happy with him taking the reigns as well.  Jeff Garzik and Gregory Maxwell are brilliant, but maybe a bit too conservative for my tastes.  No offense Smiley

That said, I think Gavin is doing an outstanding job, and I hope he lives 1000 years.

Edit: Though I'd be perfectly happy with any of these people leading development in the event that Gavin steps down.
Pages: « 1 2 3 4 5 6 7 8 9 10 [11] 12 13 14 15 16 17 18 19 20 21 22 23 24 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!