Bitcoin Forum
July 04, 2024, 09:48:18 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 [25] 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 ... 135 »
481  Bitcoin / Bitcoin Discussion / Re: Mike Hearn, Foundation's Law & Policy Chair, is pushing blacklists right now on: November 15, 2013, 04:04:54 AM
Oh no please no more Ripple! Ew!



It's actually on topic, that Chris Larsen is also present at the hearing maybe why Hearn has to practice doublespeak.
482  Bitcoin / Bitcoin Discussion / Re: Mike Hearn, Foundation's Law & Policy Chair, is pushing blacklists right now on: November 15, 2013, 04:00:55 AM
Or maybe we should just use passive crime fighting? Law enforcement announces an address which is believed to be used to store illegal funds, then everyone participates in coin mixing can decide for himself if he is willing to mix his funds with that of a suspect, it can even be built into the clients, oh wait, law enforcement prefers to remain obscure, so forget about it....

There are a lot of technical solutions which could empower the community without dividing it.

This idea you present actually isn't all that bad. If individual users want to set their client to only deal with other trusted users that actually would be an excellent feature. No one wants to get scammed to find out that they cannot trust. The principle is that it should be voluntary.

If individual users want to set their client to only deal with other trusted users... then they can use Ripple, backed by Google Ventures, employer of Mike Hearn!

Or you could rather say: what Ripple implements is just some trivial features that can be done on the Bitcoin network easily.
483  Bitcoin / Bitcoin Discussion / Re: Mike Hearn, Foundation's Law & Policy Chair, is pushing blacklists right now on: November 15, 2013, 03:48:34 AM
Or maybe we should just use passive crime fighting? Law enforcement announces an address which is believed to be used to store illegal funds, then everyone participates in coin mixing can be notified and decide for himself if he is willing to mix his funds with that of a suspect, it can even be built into the clients to automatically receive notice from the government, oh wait, law enforcement prefers to remain obscure, so forget about it....
484  Bitcoin / Bitcoin Discussion / Re: I know this has been brought up before, but confirmation times are getting weird on: November 15, 2013, 03:29:12 AM
If you check the all-time graph, it used to reach 15-20 minutes.
485  Bitcoin / Bitcoin Discussion / Re: Mike Hearn, Foundation's Law & Policy Chair, is pushing blacklists right now on: November 15, 2013, 03:18:06 AM
Keep focused, please.

Discuss how redlisting coins will help fight crime, and specifically CyptoLock copycats.


Easy, criminals can remain uncaught because innocent people are willing to hide them among us, or just do not object to it. If everyone thinks someone is a scumbag deserving some punishment, they will all actively participate in spotting him, like if he tries to use Coinjoin everyone will refuse to mix with his coins, then he has no place to hide.

The law-enforcement could even be compelled to be more transparent, because they have to do so to get our help, rather than forcing it upon us.


This should be Hearn's original idea: https://bitcointalk.org/index.php?topic=157130.0

What he is trying to present to the politicians may be a cooked-up version.
486  Bitcoin / Bitcoin Discussion / Re: Mike Hearn, Foundation's Law & Policy Chair, is pushing blacklists right now on: November 15, 2013, 03:08:04 AM

Well, Mike's a very smart guy, and an expert in security, so I may not understand his proposal with precision, but I'm pretty sure the outrage on this thread is a result of people just flying off the handle for no good reason. To be very clear, he's calling it a red list specifically because it's not the same as a blacklist. He's not proposing auto-filtering out 'tainted' coins. Here's the short summary:

"Consider an output that is involved with some kind of crime, like a theft or extortion. A "redlist" is an automatically maintained list of outputs derived from that output, along with some description of why the coins are being tracked. When you receive funds that inherit the redlisting, your wallet client would highlight this in the user interface. Some basic information about why the coins are on the redlist would be presented. You can still spend or use these coins as normal, the highlight is only informational. To clear it, you can contact the operator of the list and say, hello, here I am, I am innocent and if anyone wants to follow up and talk to me, here's how. Then the outputs are unmarked from that point onwards. For instance, this process could be automated and also built into the wallet."

This is basically a reputation service. There could be many of them, though it's a network on top of a network, so I'd have to imagine the network effect is pretty huge in terms of winner-takes-all.


You have to make a lot of assumptions to conclude that this "redlist" won't behave exactly like a blacklist. Especially when government joins in on it by punishing people for accepting coins they "should have known" were used for illegal activity. What you'll end up with is an ecosystem where nobody accepts "red"listed coins as payment, even if the network will still let you move them around. If you are innocent, sure, you can contact the operator of the list, but the operator will have no obligation to assume you're innocent. You'll be expected to prove your innocence to the operator's satisfaction.


I'm not making any assumptions. I'm saying that it's a preliminary discussion where nobody knows if or what a workable solution would look like. Could be a total dead-end and very well may be, but no reason not to explore the idea to see if there's a way to make it work.

I would say "no way to make it work" is exactly how it would work, we can make all kinds of assumption about Hearn's morality, but I doubt he is silly enough to believe a government-style blacklist will be successful, he was also an active participator in Maxwell's Coinjoin post.
487  Bitcoin / Bitcoin Discussion / Re: Mike Hearn, Foundation's Law & Policy Chair, is pushing blacklists right now on: November 15, 2013, 03:02:38 AM
It's all just a bluff. Hearn is just going there testifying that he can serve bitcoin up on a platter for the sitting mob to control and manipulate... and they will believe it... and they'll finally feast on some of the lies they've been serving up forever... consider it a vision.

Finally someone with some ideas about how politics works, the geeks' ignorance about which on this forum is just frustrating...
488  Economy / Speculation / Re: Ripple competition on: November 15, 2013, 02:28:26 AM
Hmmm, so instead of work, sheer numbers matter right? Our botnet operating Russian friends will be very pleased I guess...
No, of course not. You actually have to convince human beings that public keys are controlled by organizations that cannot collude. And all that happens if they do is that the network does not reach consensus and those who betrayed this trust have done so provably with cryptographic signatures. So any trust in them can be removed and the problem solved and the attacker has to start over. Which is better -- an attacker just needs money and can double spend and then the system is broken or an attacker needs to build human trust and then can prevent the network from operating and then the attacker has to start over from scratch?


LOL, what human trust do I need to build? Just validating reasonable transactions from other gateways automatically and being trusted by my bots will make me a gateway that has a say in the "supermajority network consensus" after some time.




Quote
Quote
Quote
He will soon. If his trusted validators are disconnected from the majority, they will report this, and he will know the network is partitioned. (This isn't implemented on the live network yet, it is still being tested. It's needed to support trustless clients.)
That is to say when partitioning is not resolved, availability will be gone, so instant transaction is only available as long as most of the major trusted validators on the network are connected to each other, I am not sure if I can call it "reliable".
The same is true of Bitcoin. If you are not reliably connected to 51% of the hashing power, no number of confirmations is sufficient. The difference is, with Ripple it's possible to reliably tell if you are or are not connected.

There is a very big difference between partitioning between you, a user, and the rest of the network, and  the partitioning of the rest of the network, (especially the major miners), to maintain your connection is way easier than trying to make sure the whole network is well connected, in Bitcoin, only the former case matters, in Ripple, the latter case matters too, or even more, that's why I doubt the claim of "reliable instant transaction" very strongly. Besides, even if my Bitcoin node is completely isolated, it still costs much more to convince me, if I demand to see a sufficient number of confirmations, as long as I remember how many zeros I should expect to see in each newly mined block, a significant hashrate drop by more than 50% is also very detectable, and should make any sensible merchant suspicious. Ripple actually doesn't seem to fare much better on the detection of the former case either: if you don't keep record of every validator which has a long history of honest validations from time to time(kindly enlighten me if you have some better algorithms), you can't detect if the partitioning takes place because the supermajority you are seeing could just be "phantom validators" operated by a botnet, while with Bitcoin, all you need to know is a number: the hashrate.
489  Local / 中文 (Chinese) / Re: BTC大塞车,LTC获得战略性机遇! on: November 15, 2013, 12:32:23 AM
至少会有一个山寨币存活,不然有些人如何把非法BTC收益以完全合理的理由洗出去。
490  Bitcoin / Bitcoin Discussion / Re: Mike Hearn, Foundation's Law & Policy Chair, is pushing blacklists right now on: November 14, 2013, 04:10:44 PM
I have some clues about what his idea maybe like, but I will refrain from saying anything specific for the moment, I want to see how things evolve.
491  Bitcoin / Bitcoin Discussion / Re: Wiping all copies of bitcoin blockchain VS bank's database on: November 14, 2013, 03:25:58 PM
Yes.
You know this how?
What stops the first person coming online from doing a 51%?

That's not how 51% attack works, you need to have a main blockchain you don't work on first to pull off a 51% attack.
492  Bitcoin / Bitcoin Discussion / Re: BTC Guild last block was 2013-11-14 10:13:40 (over three hours ago)? on: November 14, 2013, 03:22:36 PM
Randomness is a bitch, try to make it look even then it's not randomness anymore.
493  Bitcoin / Development & Technical Discussion / Re: CoinJoin: Bitcoin privacy for the real world on: November 14, 2013, 10:52:04 AM
I am thinking if we should conduct some field tests: get some people to use Coinjoin, and publish their transactions, others will employ every method they can come up with to try to determine which address has sent to which.
494  Economy / Speculation / Re: Ripple competition on: November 14, 2013, 09:00:12 AM

Quote
A Ripple merchant would not have such good luck...
This is automatic with Ripple. If you don't see validations from a supermajority, you know you are partitioned. There's nothing special you need to do -- it's built in.




Hmmm, so instead of work, sheer numbers matter right? Our botnet operating Russian friends will be very pleased I guess...



Quote
He will soon. If his trusted validators are disconnected from the majority, they will report this, and he will know the network is partitioned. (This isn't implemented on the live network yet, it is still being tested. It's needed to support trustless clients.)

That is to say when partitioning is not resolved, availability will be gone, so instant transaction is only available as long as most of the major trusted validators on the network are connected to each other, I am not sure if I can call it "reliable".

495  Economy / Speculation / Re: Ripple competition on: November 14, 2013, 08:53:14 AM
So, what is sacrificed in Ripple then: Consistency, Availability or Partition tolerance?
Partition tolerance, of course, the same as Bitcoin.

Imagine what would happen when some gateways losing communication(unverifiably) to some others...........
Imagine what happens when some mining pools lose communication, unverifiably, to some others. You might have six confirmations but on the other side of the partition a conflicting transaction has eight confirmations.

Ripple would be much more vulnerable to this than Bitcoin would because you would need a partition that separates well-connected mining pools for many minutes to cause a problem for Bitcoin. Because of this, Ripple actually needs to detect and deal with partitioning. Which it does, of course.


No problem at all, as long as the merchants are well connected and see all the blockchains, they can decide if their transaction is in the longest chain , and when to release the goods.

A Ripple merchant would not have such good luck if his trusted validators are disconnected from a bunch he doesn't trust....
496  Economy / Speculation / Re: Ripple competition on: November 14, 2013, 08:34:40 AM
Imagine what would happen when some gateways losing communication(unverifiably) to some others...........

Still don't see the answer.

I fixed my post.
497  Economy / Speculation / Re: Ripple competition on: November 14, 2013, 08:30:14 AM
Does Ripple offer instant reliable transactions?
That was the primary design goal of the "continuous ledger close" algorithm that Ripple uses.
https://ripple.com/wiki/Continuous_Ledger_Close
The goal is to provide you a cryptographically-signed receipt for a hash that provably includes confirmation of your transaction from a supermajority of the validators you have chosen to use.

Which in non-tech terms means, "yes".   Grin

So, what is sacrificed in Ripple then: Consistency, Availability or Partition tolerance?

Imagine what would happen when some gateways losing communication(unverifiably) to some others...........

Or may be they just think centralization is a better idea

Quote from: Ripple Wiki
If everyone chooses a completely disparate sets of validators the network will be unlikely to reach consensus that a particular version of the ledger is the one true and accurate ledger. But, in practice, people's UNL lists will overlap. This overlap causes the honest validators to come to the same consensus
498  Bitcoin / Bitcoin Discussion / Re: Bitcoin at the US Senate on: November 14, 2013, 07:46:05 AM
From the Forbes article (http://www.forbes.com/sites/kashmirhill/2013/11/13/sanitizing-bitcoin-coin-validation/):

Quote
In the short term, they talk about a limited database that keeps track only of registered identities and their activities with participating companies, but it’s obvious that their ambitions are grander and that a longer term prospect is to take advantage of the transparency of the Bitcoin system to keep track of which Bitcoin is tainted by associations with black markets. Waters says that the development of that aspect will depend on “community feedback".

This is the kind of disaster we're trying to warn you about. How long will it be before pressure is brought to bear on core developers to make coin tainting part of the core software?
In a global network, who gets to decide which coins are tainted?

Please do not cooperate with this, it will be the end of Bitcoin.

Possessing money and transferring money should never have been made a crime. That act was the beginning of limitless government power over free speech and free enterprise.

Good thing we have CoinJoin, DarkWallet, and some future wallet integration to look forward to. Oh, and other bitcoin-using countries that don't give a crap about this.
I fervently hope you're right. The CoinJoin idea won't be helpful in the true nightmare scenario (which is pretty much described in the article): only greenlisted addresses can be used to buy goods and services in the USA (and in this scenario, also the EU, Russia, China and everywhere there's a decent sized economy). At this point Bitcoin would just die out as it would be offering little or nothing of interest (the greenlisting functioning as the third party, which collects fees etc, and who knows how long 'limited supply' would last). If people still saw the value in a blockchain they would just make government controlled ones.

On balance, my crystal ball says that outcome is very unlikely. But that's what the powers that be are going to be pressing for. The international part of the argument is the only thing keeping me optimistic. But think of it this way: such actions will not only dramatically suppress the growth of the Bitcoin economy, but also make all of us trying to keep using it feel like criminals.

You are saying that they can manage to get everyone selling something online licensed?

Then their next step could be shutting down the internet.
499  Bitcoin / Development & Technical Discussion / Re: CoinJoin: Bitcoin privacy for the real world on: November 14, 2013, 07:29:13 AM
I am thinking that if all the inputs and outputs are of the same size, there is no need for the server to know the mapping?
That's fine for a theoretical exercise, but in the real world you're going to have a wallet with outputs of random sizes.

Then you're going to need to spend them on a real purchase, also of a random size.

For the protocol to be usable there's got to be a way to deal with that.

But it would work for drug dealers trying to cash out, right?
500  Bitcoin / Development & Technical Discussion / Re: CoinJoin: Bitcoin privacy for the real world on: November 14, 2013, 07:03:25 AM
Does the protocol have any way for participants to negotiate on output size restrictions?

Either make all the outputs the exact same size, or maybe restrict them to something like integer (positive and negative) powers of two?

I am thinking that if all the inputs and outputs are of the same size, there is no need for the server to know the mapping?
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 [25] 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 ... 135 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!