|
Что-то как-то не очень верится..
|
|
|
|
|
Если четко все делать, то будет и прибыльно
|
|
|
|
|
не в рефках счастье... хотя
|
|
|
|
|
У биткоина все шансы расти и дальше
|
|
|
|
|
rEo4QLZfpgV7Npa5WDBUyjmm9A7Ua3FavE
|
|
|
|
|
What would you like to buy for Bitcoins?
|
|
|
|
|
Would anyone be interested in buying home made dried apple/banana/strawberry/pineapple chips for Bitcoin?
I went to a Bitcoin meeting last night, and one of the hot discussion topics was what real world goods could you buy for Bitcoin. This idea hit me as I was making some dried fruit for camping trip this weekend.
I can't promise fancy logos or professional grocery store looking packaging, but if someone is interested I will make some and mail them to you for Bitcoin.
|
|
|
|
|
I was thinking about how Bitcoin's model of tracking ownership and mining could be applied to other electronic assets. One thing I came up with is unique addresses. A unique address could be a string such as "bob", "alsdkfjds", or "BigCompany". Once ownership of an address is established in the block chain the address could be used for a number of things where a unique human understandable name is desired .... replacement for DNS, IP, e-mail, or reputation tracking to name a few. Having a secure ownership database of addresses without a central authority sounds like a nice idea to me. I really don't like that I have to put in all my personal information when I buy a DNS name register for an IP address. Is anyone working on a project like this?
|
|
|
|
|
I thought more about my proposition, and transaction fees throw a wrench in the plan.
I came up with a new idea, though. Currently, the each block includes a list of transactions like this:
trans1, fee, from accts/amts, to accts/amts
trans2, fee, from accts/amts, to accts/amts
... etc
Wouldn't it be nice if the block chain looks like this:
from acct1, amt
from acct2, amt
from acct3, amt
to acct4, amt
to acct5, amt
to acct6, amt
fee
fee
fee
Not sure how to do this without trusting the systems generating the block chain, though. Group coordination while trusting no one is hard work!
|
|
|
|
|
It seems crazy to me that the client even lets you choose how a fee by selecting a global variable paytxfee. Nobody wants to pay a greater fee than they have to. Rather than setting a global fee parameter I suggest the following:
1. On a transaction by transaction basis the client will calculate the minimum fee possible and report it to the user before the user confirms the transaction.
2. If the transaction includes recently spent coins that may cause the transaction to be postponed using the minimum fee the client should advise the user of this and provide them with alternatives to paying the minimum fee to make the transaction occur earlier.
|
|
|
|
|
Gavin, "Go read some academic literature to find out" sounds much more promising than "I can easily see through that technique by doing X", thanks.
ByteCoin, your technique is interesting. It's more efficient with addresses than what I came up with, and it can limit tracking of transactions to/from publicly published bitcoin addresses. However, the parties to the transaction have at least some ability to link the other's future transactions(see the example below).
1. Sender sends 100 BTC to receiver through the transfer address.
2. Receiver moves the 100 BTC from the transfer address to a new address they control(address1).
3. Receiver makes a payment to 3rd-party address with "change" going to a new address(address2) receiver controls.
4. Sender can see the transaction but they have to guess which address belongs to receiver. They don't know who 3rd-party is, either.
5. Sender makes a second payment to receiver via transfer address.
6. Receiver moves the second payment to address3.
7. Receiver makes a payment to 4th-party using address2 and address3 with the "change" going to address4.
8. Sender can now link address2 to receiver.
So far it seems to me that the best way to limit block chain tracking without using a third party "proxy" is to split a transaction into smaller "network standard size" chunks that get sent to multiple addresses.
|
|
|
|
|
Also, assume a large number of transactions are done this way on the network.
|
|
|
|
|
Also, assume addresses are only used once and the parties forget the addresses they previously created for themselves.
|
|
|
|
|
Recipe for Bitcoin limiting trackability
- Fred has 10 BTC addresses with 1 BTC each
- He wants to buy a widget from Sally for 2 BTC.
- Fred creates a transaction where the 10 BTC from his account are sent to
10 different BTC addresses.
- 2 of those addresses are generated by Sally
- 8 of those addresses are generated by Fred
- Fred and Sally can now create new bitcoin addresses,
one address for each coin, and send their coins to the new addresses.
- The laundering transactions can be sent at random time
- The amount of coins laundered in each laundering transaction can
either be random or at amounts common to other transaction on the network
- Neith Fred or Sally would be able to know if the coins were being spent
or just laundered
Anyone see any holes in this strategy? I'm thinking about implementing it as an interface on top of the Bitcoin client.
Thanks!
|
|
|
|
As an experiment I'm offering consulting/hosting services in exchange for Bitcoin. If you're interested drop me a line: rootcmd.com. |
|
|
|
|
Show Posts
