|
I was not very much convinced by my proposal for a system to transfer assets with the bitcoin network, so here is an other idea.
The asset is defined somewhere on cyberspace, with a full textual description. In this text there is a bitcoin address where coupons/dividends/whatever are to be paid.
In order to transfer this asset, the owner basically just have to change the bitcoin address it is assigned to.
I'll use again the idea of coding information into the amounts.
So basically we need to code a bitcoin address into transactions amount.
Let's take the following address as an example :
1Hy9dexzNzjvQYkYy6zKRVZMU8k2j5vuPt
We turn it into hex :
$ openssl dgst -rmd160 <<<1Hy9dexzNzjvQYkYy6zKRVZMU8k2j5vuPt
a370e25093b51a83e13864ff880afd5b95ff2615
Split it into 4-characters-long parts :
$ H=a370e25093b51a83e13864ff880afd5b95ff2615
$ while echo ${H::4}; [[ -n "${H#????}" ]]; do H=${H#????}; done
a370
e250
93b5
1a83
e138
64ff
880a
fd5b
95ff
2615
Turn them into sequentially ordered amounts :
$ n=10
$ for i in a370 e250 93b5 1a83 e138 64ff 880a fd5b 95ff 2615
do echo $((n++*10**6+0x$i))
done
10041840
11057936
12037813
13006787
14057656
15025855
16034826
17064859
18038399
19009749
we compute their sum (we could have done that during the previous step but it is simpler to present it like this for you)
$ echo $((10041840+11057936+12037813+13006787+14057656+15025855+16034826+17064859+18038399+19009749))
145375720
We send this sum from an account called "treasury" to the address :
$ bitcoind sendfrom treasury 1Hy9dexzNzjvQYkYy6zKRVZMU8k2j5vuPt 1.45375720
We set an account for it :
$ bitcoind setaccount 1Hy9dexzNzjvQYkYy6zKRVZMU8k2j5vuPt testaccount
And finally we send the 10 amounts from the testaccount back to the treasury :
$ addr=$(bitcoind getaccountaddress treasury)
$ bitcoind sendfrom testaccount $addr 0.10041840
$ bitcoind sendfrom testaccount $addr 0.11057936
$ bitcoind sendfrom testaccount $addr 0.12037813
$ bitcoind sendfrom testaccount $addr 0.13006787
$ bitcoind sendfrom testaccount $addr 0.14057656
$ bitcoind sendfrom testaccount $addr 0.15025855
$ bitcoind sendfrom testaccount $addr 0.16034826
$ bitcoind sendfrom testaccount $addr 0.17064859
$ bitcoind sendfrom testaccount $addr 0.18038399
$ bitcoind sendfrom testaccount $addr 0.19009749
Finally all we have to do is to write a programm that inspects the block chain in order to trace the full transaction log of the asset.
|
|
|
|
A simpler and better (but still not entirely secure) way to check ownership is to ask her to send 3.14159264 bitcoins *from* that address back to that address in a single transaction (That's possible, right?).
True. Sending *from* the address is good too. Also, the method doesn't have to be secure, since anyway it is not really very usefull to prove to someone taht you own some money. Alice could prove Bob she owns enough money, but at the end the moment of truth occurs during the real transaction from Alice to Bob. It's easy to prove you own any amount of money. Bacically you could even borrow it during a short period of time. Big money owners could also sell this kind of proof to people (selling the "proof", not the money). What I mean is that proving you own some money is actualy quite useless in commercial relations anyway. But if people really want to do it, they can do so with a relative security within the current bitoin implemenation. |
|
|
|
I've just realised that proving you own a particular address is actually not very difficult, even with the current bitcoin client. Say Alice wants to prove Bob that she owns the bitcoin addres $addr All she has to do is to send a certain amount of bitcoin to this address. This amount has to be high enough to convince Bob that it wasn't lost, and it has to have some entropy (so that it can be used to prove that it comes from Alice). So Alice tells Bob : A: ok, give me a high enough amount, with a few decimal numbers. B: hum, let's say pi : 3.14159264 A: wait a sec... (Alice runs "bitcoind sendtoaddress $addr 3.14159264") A: here you go, check out the following transaction : http://bitcoinexplorer.com/q/transaction/... B: fine, I guess you wouldn't accept to lose 3.14159264 bitcoins just to fool me. So I beleive you own this address. |
|
|
|
|
I agree with gene when he says it should not be a bitcoin feature. I was wrong to ask for an other subcommand of the bitcoind command.
But could someone please work on a completely separate application that would read the wallet and use private ECDSA keys to sign documents ?
|
|
|
|
I am one see in these devices an ideal tool for assassination?
I'm not sure about assassination, because you need facial recognition, plus a very long operating range in order to find your target. But once you give those machines a good battery (maybe a fuel cell or something), then have it carry a gun and I fear for soldiers on battlefiled. |
|
|
|
2.31
kiba leads at 2.31 BTC |
|
|
|
|
Gosh I've just noticed that this thread has gone long.
I haven't read everything, but I'd like to explain why I wanted this feature.
I am writing a CGI script for my private stockholdings brokerage system.
To that end, instead of using passwords, I wanted to use private keys. So naturally I was planning to use GnuPG. But during writing, I realised at some point the owner should send a bitcoin address where to receive dividends. It seemed to me that I was using two keys pairs (a GnuPG one, and a ECDSA one), in order to identify the same person. Since only ECDSA is really necessary (dividends have to go somewhere in the end), I realised that it might be better to identify owner with this pair. It would also be better for confidentiallity (since most GnuPG keys use real names).
|
|
|
|
We should be mindful that with features come code. Code which must be written, debugged, maintained... and code which may potentially be exploited. The slimmer bitcoin remains, the better.
Well, I guess you're right. |
|
|
|
This violates the "one job and do it well" philosophy. There already exist established standards for cryptographic signatures.
Ok then someone tells me how I can : - extract an ECDSA private key from a wallet file ; - use this key to sign data ; - verify data signed this way ; |
|
|
|
Actually it would be even nicer if we could treat our wallet.dat file as a generic keystore, importing and exporting keys.
This would allow merging and splitting of wallets as well, besides signatures as suggested above.
+1 |
|
|
|
Setting a specified minimum amount (e.g., 1 BTC) would give a disincentive for submitting too many votes.
e.g.
Those supporting plan A send to [bitcoin address A]
Those supporting plan B send to [bitcoin address B]
Personnaly I'd be ok with that but I'm pretty sure most people won't. Ploutocracy hasn't been moraly accepted since ancient greece. |
|
|
|
I'd like to be able to use one of my wallet keys to sign an ASCII text. syntax of the command would be : $ bitcoind signwithaddress BITCOIN_ADRESS < somefile > somefile.asc
$ bitcoind verifysignature < somefile.asc
correct signature done on DATE by address BITCOIN_ADRESS
Message was :
....
somefile.asc could be written in a form such as : ---- BEGIN ECDSA SIGNED MESSAGE ---- ... ---- END ECDSA SIGNED MESSAGE ---- Or something like that. |
|
|
|
Sadly, the only industries I can think of that readily desire bitcoin's inherent properties are the very industries that governments like to control or keep off the radar: Why would you want anything else ? If you ignore moral aspects, then those activities fullfill what you were claiming for. I don't use gold as an ornementation personnaly, and yet I own gold because I know some people love gold jewelery. |
|
|
|
So you have hexcopters, with some ability to charge itself and some ability to carry pizza....
Hopefully, a hexcopter won't get into an accident and kill someone.
Hmm, you could have a whole infrastructure. Mobile bot that carry batteries, charging station, and so on.
Imagine how cool that would be : you're walking in the street, minding your own business, suddenly a pizza delivering robot accidentaly drops its payload. And here you go : you got nice ready-to-eat pizzas falling from the sky !  |
|
|
|
Nice. The important feature here is perching on a vertical surface, for it can allow the quadricopter to charge its battery. Indeed all you have to do is to place an induction loop on this very area. Verticality is important for it can dramatically reduce real estate price for the recharger building (One can use the main wall of a high tower). Those stuffs will be in cities delivering pizzas soon  ! |
|
|
|
Woow... Indeed we have a winner. This device has impressive stability, speed and acceleration. All it needs now is a performant battery and a way to recharge it without human intervention. Then you put some guns on it and we're in Terminator... |
|
|
|
2.26
kiba leads at 2.26 BTC |
|
|
|
The github issues system has a simple voting system; lets use it!
Problem with a vote is that it brings bureaucraty in the system. Peole will have to register to github, remember to participate to the votes, check on regular basis for new votes, and so on. I don't like that. Democracy doesn't fit cyberspace well, imo. I very much prefer anarchy. |
|
|
|
|
Ok but in order to mine don't you need a full VHDL implementation of the miner code ?
Because if you must communicate between your PC and your FPGA, this might slow it down quite a lot.
Also I don't understand : have you just done simulations or have you tried on the actual device ?
|
|
|
|
|
Show Posts
