Bitcoin Forum
December 10, 2016, 04:41:34 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 [5] 6 »  All
  Print  
Author Topic: Anonymity  (Read 52195 times)
Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526


View Profile
February 11, 2011, 02:26:01 PM
 #81

What exactly would you blind sign?

The Chaum system assumed a central authority. It was big on privacy but low on decentralization. I don't see any obvious ways to use blind signing in BitCoin to improve privacy, but maybe somebody else does.
1481388094
Hero Member
*
Offline Offline

Posts: 1481388094

View Profile Personal Message (Offline)

Ignore
1481388094
Reply with quote  #2

1481388094
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
marcus_of_augustus
Legendary
*
Offline Offline

Activity: 2100



View Profile
February 11, 2011, 03:14:36 PM
 #82

Quote
It was big on privacy but low on decentralization.

I don't see how the two are mutually exclusive as you seem to be implying and someone was saying further back up.

Are you saying there is logical reason that if you decentralize you preclude privacy? Couldn't the central authority in Chaum's scheme be replaced with the network itself?

Nefario
Hero Member
*****
Offline Offline

Activity: 602


GLBSE Support support@glbse.com


View Profile WWW
February 11, 2011, 03:16:49 PM
 #83

Not bad.

As far as anonymous internet connections go, prepaid phones aren't a bad choice either.  They're cheap, nearly impossible to tie to the user, and can be destroyed when finished.  Again, they can be bought in densely crowded shopping malls or walmarts.

Dont forget to use an anonymous method to pay for the VPS foreverdamaged.  Perhaps a prepaid credit card also bought from a crowded location would do the trick.

By the way, I like to imagine that this user is in China and is trying to buy a book about freedom Wink

Just. to let you know, you cant buy a mobile phone sim card in China without your national I.D. so all phone numbers, even mobiles are tied to identity.

PGP key id at pgp.mit.edu 0xA68F4B7C

To get help and support for GLBSE please email support@glbse.com
ribuck
Donator
Legendary
*
Offline Offline

Activity: 826


View Profile
February 11, 2011, 03:26:46 PM
 #84

Just. to let you know, you cant buy a mobile phone sim card in China without your national I.D. so all phone numbers, even mobiles are tied to identity.
It's the same in Australia, South Africa, Spain, and many other countries, and going that way in the UK soon too.

Bring on Mesh Networking! No SIM needed.
Nefario
Hero Member
*****
Offline Offline

Activity: 602


GLBSE Support support@glbse.com


View Profile WWW
February 11, 2011, 03:57:01 PM
 #85

Just. to let you know, you cant buy a mobile phone sim card in China without your national I.D. so all phone numbers, even mobiles are tied to identity.
It's the same in Australia, South Africa, Spain, and many other countries, and going that way in the UK soon too.

Bring on Mesh Networking! No SIM needed.

have fun carrying your router in your pocket  Tongue

PGP key id at pgp.mit.edu 0xA68F4B7C

To get help and support for GLBSE please email support@glbse.com
ribuck
Donator
Legendary
*
Offline Offline

Activity: 826


View Profile
February 11, 2011, 05:07:00 PM
 #86

have fun carrying your router in your pocket  Tongue
My N900 phone has a full Linux stack, so no problem.

Actually, there is a problem. Today Nokia announced that they're abandoning open source for Windows Mobile 7.
ShadowOfHarbringer
Legendary
*
Offline Offline

Activity: 1470


Bringing Legendary Har® to you since 1952


View Profile
February 11, 2011, 06:42:38 PM
 #87

Actually, there is a problem. Today Nokia announced that they're abandoning open source for Windows Mobile 7.

Really ? WOW, what a misfire...

WM7 will soon be a dying platform, before it even took off...

Open Source RLZ, apparently

ribuck
Donator
Legendary
*
Offline Offline

Activity: 826


View Profile
February 11, 2011, 10:58:23 PM
 #88

Really ? WOW, what a misfire...
Yep, really. Two former giants battling to see who can make themselves irrelevant fastest.

A damn shame about Nokia. Nokia's N900 phone is a real Linux box with unrestricted root access, an X Terminal "out of the box", and even a control key on the keyboard. And it runs bitcoind very nicely. They apparently have one more Linux phone in the pipeline, then that's the end.
Anonymous
Guest

February 12, 2011, 11:38:37 PM
 #89

Maybe we need to make our own phone.   Smiley
gohan
Jr. Member
*
Offline Offline

Activity: 52


View Profile
February 13, 2011, 11:15:37 PM
 #90

Couldn't the central authority in Chaum's scheme be replaced with the network itself?

I was toying with the same idea just before I read your post, but couldn't figure out a robust way to replace the need for a secret, which seems to be the sole reason for a trusted authority. I'm just speculating, but, the first thing that springs to mind is to require blind signatures of (and verification by) a certain number of nodes, but this is very weak compared to the very idea that makes bitcoin great. It could be used to create a decentralized banking authority, which might not be a bad way to create a complementary anonymous/untraceable currency indexed to bitcoin, but not an extension to the bitcoin network, IMHO. Has there been any research about this?
marcus_of_augustus
Legendary
*
Offline Offline

Activity: 2100



View Profile
February 14, 2011, 02:52:27 AM
 #91


If David Chaum would work for bitcoins maybe we could entice him or one of the Digicashers to figure out the details of a blind singing scheme for the transactions?
If implementable as a separate layer, it could even be an option in the client, "Anonymous" or "Identified" transaction.

I figure the early adopters generating that first year when difficulty was at 1 are sitting on some BTC 1.5 million, (tongue firmly in cheek), it would greatly increase BTC value if they could be guaranteed anonymous transactions.

If not, I'm thinking the next bitcoin clone, fork, child, etc will have blind signing transactions or a subnet dealing in a crypto-currency indexed to BTC as you say.

grondilu
Legendary
*
Offline Offline

Activity: 1134


View Profile
February 14, 2011, 03:00:20 AM
 #92


Well, maybe Nokia abandonning open source will revive the openmoko initiative.
marcus_of_augustus
Legendary
*
Offline Offline

Activity: 2100



View Profile
February 14, 2011, 03:05:33 AM
 #93


Which part of the topic says, "let's discuss smartphones here" to you guys exactly?

marcus_of_augustus
Legendary
*
Offline Offline

Activity: 2100



View Profile
February 14, 2011, 04:07:17 AM
 #94


Here's the original '82 paper of Chaum's on blind signing.

Here, the elector, carbon-ink envelope analogy is described differently by Chaum than that in general circulation, i.e. on wikipedia, which misses the nested envelope part of the scheme.

There is an outer envelope layer that is return addressed and inside that is the carbon-inked envelope that contains the voting paper that can then be 'blind signed' by the trustee and returned anonymously to the voter in a new envelope ...

http://www.hit.bme.hu/~buttyan/courses/BMEVIHIM219/2009/Chaum.BlindSigForPayment.1982.PDF

Although, still difficult to see the logic of how it could be implemented on a bitcoin P2P transaction let alone the crypto-mechanics of it ...

grondilu
Legendary
*
Offline Offline

Activity: 1134


View Profile
February 14, 2011, 04:13:05 AM
 #95

Although, still difficult to see the logic of how it could be implemented on a bitcoin P2P transaction let alone the crypto-mechanics of it ...

I suspect it is possible.  But we need someone with a big brain, or someone who has enough time to think about it thoroughly.


marcus_of_augustus
Legendary
*
Offline Offline

Activity: 2100



View Profile
February 14, 2011, 04:27:06 AM
 #96

Okay, in the second to last paragraph of Chaum's paper there is a small section "Elaborations"

He clearly states that it could be extended to a decentralised model where there are multiple clearing agents, i.e. signing authorities, so on that basis it can be done.

Seems wrong then to say that decentralisation precludes anonymity, red herring rule-of-thumb (rot).

I'll see if I can come up with a schema that fits easily into the bitcoin transaction model for comment. Would be based around the block-generating node blind signing the transactions in essence.


fellowtraveler
Sr. Member
****
Offline Offline

Activity: 440


View Profile
February 14, 2011, 05:59:57 AM
 #97

Quote
He clearly states that it could be extended to a decentralised model where there are multiple clearing agents, i.e. signing authorities, so on that basis it can be done.

Seems wrong then to say that decentralisation precludes anonymity, red herring rule-of-thumb (rot).

If you would like to play with an actual implementation of Chaumian blinding,
then I recommend you check out my digital cash library, Open Transactions:  
https://github.com/FellowTraveler/Open-Transactions/wiki

Some scoff at blinded digital cash, since it involves withdrawing cash from a "server" and that means "client/server" which means it's not fully p2p distributed and instead is a "centralized solution"--and therefore politically uncool.

Let's keep in mind that blinded tokens are what provide the untraceability. No "signing authority"? No untraceability.

Let's also keep in mind that, as Chaum said, it's possible to run MULTIPLE SERVERS. (The various diagrams for Open Transactions depict this.)

Open Transactions also makes it possible to distribute funds across multiple servers, and to distribute currencies across multiple issuers (through basket currencies.)

If anyone really has a problem with running a server somewhere, let's also keep in mind that I2P and Tor are specifically designed to allow "HIDDEN SERVERS" to exist within the network, untraceable in their actual location yet still processing services online. Presumably any future anonymous networks will also feature this important functionality. Thus, it can be said that any hidden service (including Open Transactions, for example) is made possible by the p2p, distributed nature of the anonymous network on which it runs.

The publicly-auditable nature of Bitcoin means that, by its very nature, it cannot be untraceable. Software such as Open Transactions must be employed as a layer above, in order to add the functionality of untraceable cash, as well as the ability to use other instruments like markets, payment plans, cashier's cheques, etc.

I find it interesting how blinded token software such as Open Transactions complements Bitcoin (providing an untraceable layer), while Bitcoin provides a publicly-auditable and fully-distributed backing for the currency. (A backing which, unlike gold, cannot be confiscated from some central storage location.)

In fact, combined with some next-generation anonymous network, all three pieces conveniently solve the problems of the others!

I'll explain:

Bitcoin is fully distributed and decentralized, but it's not anonymous or untraceable, and in fact it's publicly auditable.
Open Transactions provides untraceability and anonymity, but you have to have somewhere to store the gold.
Bitcoin solves the problem of storing the gold (through its distributed nature), but it has no intrinsic value (it's more similar to dollars than to gold, in the sense of intrinsic value, due to its fiat nature.)
An anonymous network can hide your web activities, including your Bitcoin messages to each other and your communications with an Open Transactions server. But unfortunately, there are problems of resource allocation on an anonymous network. (Because you normally can't pay for something anonymously...)
...Unless you have digital cash. Therefore Open Transactions can be used to solve problems of resource allocation on anonymous networks, meanwhile the anonymous network is what makes it possible to safely hide an Open Transactions server.
Furthermore, the anonymous network also provides REAL value to Bitcoin (besides just "proof of work") since now the Bitcoins are redeemable in network resources. Thus it solves the problem of intrinsic value in the Bitcoin.
No issuer can ever lie about any currency in circulation, since the backing funds are publicly auditable.

co-founder, Monetas
creator, Open-Transactions
Nefario
Hero Member
*****
Offline Offline

Activity: 602


GLBSE Support support@glbse.com


View Profile WWW
February 14, 2011, 07:43:12 AM
 #98

Quote
He clearly states that it could be extended to a decentralised model where there are multiple clearing agents, i.e. signing authorities, so on that basis it can be done.

Seems wrong then to say that decentralisation precludes anonymity, red herring rule-of-thumb (rot).

If you would like to play with an actual implementation of Chaumian blinding,
then I recommend you check out my digital cash library, Open Transactions:  
https://github.com/FellowTraveler/Open-Transactions/wiki

Some scoff at blinded digital cash, since it involves withdrawing cash from a "server" and that means "client/server" which means it's not fully p2p distributed and instead is a "centralized solution"--and therefore politically uncool.

Let's keep in mind that blinded tokens are what provide the untraceability. No "signing authority"? No untraceability.

Let's also keep in mind that, as Chaum said, it's possible to run MULTIPLE SERVERS. (The various diagrams for Open Transactions depict this.)

Open Transactions also makes it possible to distribute funds across multiple servers, and to distribute currencies across multiple issuers (through basket currencies.)

If anyone really has a problem with running a server somewhere, let's also keep in mind that I2P and Tor are specifically designed to allow "HIDDEN SERVERS" to exist within the network, untraceable in their actual location yet still processing services online. Presumably any future anonymous networks will also feature this important functionality. Thus, it can be said that any hidden service (including Open Transactions, for example) is made possible by the p2p, distributed nature of the anonymous network on which it runs.

The publicly-auditable nature of Bitcoin means that, by its very nature, it cannot be untraceable. Software such as Open Transactions must be employed as a layer above, in order to add the functionality of untraceable cash, as well as the ability to use other instruments like markets, payment plans, cashier's cheques, etc.

I find it interesting how blinded token software such as Open Transactions complements Bitcoin (providing an untraceable layer), while Bitcoin provides a publicly-auditable and fully-distributed backing for the currency. (A backing which, unlike gold, cannot be confiscated from some central storage location.)

In fact, combined with some next-generation anonymous network, all three pieces conveniently solve the problems of the others!

I'll explain:

Bitcoin is fully distributed and decentralized, but it's not anonymous or untraceable, and in fact it's publicly auditable.
Open Transactions provides untraceability and anonymity, but you have to have somewhere to store the gold.
Bitcoin solves the problem of storing the gold (through its distributed nature), but it has no intrinsic value (it's more similar to dollars than to gold, in the sense of intrinsic value, due to its fiat nature.)
An anonymous network can hide your web activities, including your Bitcoin messages to each other and your communications with an Open Transactions server. But unfortunately, there are problems of resource allocation on an anonymous network. (Because you normally can't pay for something anonymously...)
...Unless you have digital cash. Therefore Open Transactions can be used to solve problems of resource allocation on anonymous networks, meanwhile the anonymous network is what makes it possible to safely hide an Open Transactions server.
Furthermore, the anonymous network also provides REAL value to Bitcoin (besides just "proof of work") since now the Bitcoins are redeemable in network resources. Thus it solves the problem of intrinsic value in the Bitcoin.
No issuer can ever lie about any currency in circulation, since the backing funds are publicly auditable.


Make you library easier to use and give us a code based use case, OT is like Google Wave, maybe it's revolutionary if people knew what the hell it was.

PGP key id at pgp.mit.edu 0xA68F4B7C

To get help and support for GLBSE please email support@glbse.com
fellowtraveler
Sr. Member
****
Offline Offline

Activity: 440


View Profile
February 14, 2011, 12:13:30 PM
 #99

Make you library easier to use and give us a code based use case, OT is like Google Wave, maybe it's revolutionary if people knew what the hell it was.

The actual use cases are very simple:  Issue currency, create account, write cheque, deposit cheque, withdraw cash, deposit cash, etc. These are actually not confusing for you at all. In fact, you intuitively understand these concepts from normal, everyday banking. For users of any OT client, the concepts are all intuitive and easy for them to understand as a result of this direct analogy with all of the financial instruments. The only difference is that OT allows you to create new currency types (while obviously normal banks mainly deal in a single currency type with their everyday customers, like dollars or euros.)

Which API calls are used for each Use Case? Exact instructions are here:
https://github.com/FellowTraveler/Open-Transactions/wiki/Use-Cases

To see the notes for each individual API call, look here:
https://github.com/FellowTraveler/Open-Transactions/wiki/API

The "Use-Cases" file describes exactly which API calls to use for each Use Case, and the API file gives the exact details on using each call.

That's pretty exact as far as instructions go -- and of course if you have any questions, I will be very responsive to anyone using the OT API.

In fact, Nefario, you contacted me recently regarding a build issue you had, and I wrote you back (on Github and posted here.) It had turned out that my instructions were wrong for installing OpenSSL 1.0.0c on Linux--they were actually installing 0.9.8--so I fixed my instructions accordingly, and also wrote you back. (http://bitcointalk.org/index.php?topic=2598.msg41445#msg41445)

The updated installation instructions are here:
https://github.com/FellowTraveler/Open-Transactions/wiki/Install

My conclusion was that, due to my instructions having been wrong, you probably never had actually installed the right version of OpenSSL. (I never found out for sure because I didn't hear back from you -- but I'm sure I can help you get the software building on your system, if there are still any problems.)

There is also an OT client called Tempest that contains sample code for most of the OT API in Perl:
https://github.com/dspearson/tempest

(You asked for a code-based use case. Tempest implements most of the use cases.)

The Tempest author may also be contacted via email (as well as myself) to satisfy any questions you might have about using the API. He will be also be releasing a new version of Tempest sometime in the next month or so.

I hope this is helpful and clears up any confusion. OT of course is new software so this process is necessary where I provide support to early experimenters. This helps me refine the docs, the software, etc to continually make things easier for you to use it.

By the way, below is the current list of Use Cases available on OT. Please feel free to ask me for any clarifications, since this helps me to update my own FAQ and other documentation for the future benefit of others. In fact your last contact to me already resulted in a fix to my install doc.

USE CASES
-- (Client software starts up.) Initialize the library and load the wallet.
-- Display for the user:
    Server Contracts,
    Nyms (key pairs),
    Asset Accounts,
    and Asset Types (asset contracts).
-- Change the wallet’s local display label for any:
    server contract,
    asset type (asset contract),
    asset account,
    or nym.
-- Import a server contract (or asset contract) into the wallet.
-- Create a new Pseudonym (public/private key pair).
-- Register a public key (a “Nym”) at an OT server.
-- Issue a new Asset Type.
   (Uploads an asset contract which creates an issuer account.)
-- Retrieve any Currency Contract (by ID).
-- Create a new Asset Account (by asset type ID).
-- Write a cheque (or invoice)
-- Send a Message to another user
   (via the server, encrypted to the recipient’s public key and placed in his inbox.)
-- Deposit a cheque
-- Withdraw cash  ************
-- Deposit cash
-- Withdraw Voucher (like a cashier's cheque.)
-- Account-to-Account Transfer (received via inbox)
-- Create a new Basket Currency
-- Exchange Digital Assets in and out of Baskets (from your Asset Accounts)
-- Process your Inbox (Receipts and pending transfers)
-- Set up a Payment Plan
-- Issue a Market Offer


co-founder, Monetas
creator, Open-Transactions
Nefario
Hero Member
*****
Offline Offline

Activity: 602


GLBSE Support support@glbse.com


View Profile WWW
February 14, 2011, 01:18:00 PM
 #100

FellowTraveller, yes you did reply but i'd moved on by that point.

Getting ruby to link with the latest version of openssl, getting the ruby headers for your library, figuring out how it works, figuring out how the server works, figuring out how to use it etc. Too many variables to calculate the time it would take me to get what I wanted.

I'll admit I'm not a great developer, having greater difficulty getting other peoples stuff to work I tend to just go and build my own. And on top of this Im slow getting things done(progrramming things) and dont have much time, I'll be starting back work after the spring break next week and will have even less time.

Building it myself I have an idea of how long it will take, I dont need all the functionality of OT. I understand the basic concepts well, and think OT's a great idea, but it's not the easiest to use.

I'm at the point where Ive almost finished my first version of the server, the client needs a proper interface but thats it. a bitof testing, some bugs fixed, and its ready to start.

When I've got my first version done I'll re-investigate OT again, and be determined to get it to build and see whether I should go for that or continue using my own system.

To be clear Im building a stock market using ricardian contracts and bitcoin as the only currency, everything is priced in bitcoin. On top of that it will also be used to manage share ownership, that is for "companies" that issue share on this market they can put forward motions and people can vote on those motions with the shares they own. It will also have share dividend payment functionality.

I havn't gotten around to implementing the voting or dividend payments yet as other things come first but it would be relatively trivial. The system doesn't use it's own http server it uses ruby sinatra, which has a lot of flexibility and can hsve better http sesrvers put in front of it.

My contrracts are stored in a db, alng with everything else instead of on the file system.

I understand my own terrible code very well, and know what all the options are, I don't write cpp, and I dont know all the options in your system(theres a lot, its a big complex system). and other users on this forum have had a look at your system, and they've also found it hard to use, I know grondilu has also gone and made his own system, I don't know if that is because of the difficulty of using OT or if thats just because he wants to do it himself.

Right now, if you want me to use OT you're going to have to join me in my project and kind of hold my hand a little, maybe even do this with me jointly, for that I'd happily give you 1/2 of the ideas/businesses profit if it makes any.

If you want to arrange for a chat on IRC I'd be happy to do so, I've got plenty of questions about the way OT works.

PGP key id at pgp.mit.edu 0xA68F4B7C

To get help and support for GLBSE please email support@glbse.com
Pages: « 1 2 3 4 [5] 6 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!