|
I use m*disc and paper. And by "paper", I mean QR codes, barcodes and text (in OCR-A font) laser printed onto high quality (but not special/archival) office paper.
Toner is basically just tiny little balls of soot and plastic and the fuser melts the plastic so that it flows into the paper fibers. About as close to permanent as you can get for a few cents.
|
|
|
|
If D has the three signatures, the multisig address, and the three addresses (or pubkeys) that match the address, he can tell which one of them is invalid, and he can tell if the multisig address matches the pubkeys or not.
Appreciated. Yes, this is pretty much what I expected must be true. I just wasn't sure how. I am not using the reference client, but pybitcointools (and pinging bci and electrum). Before I go any further, I realise there is something very basic I don't understand. Is it the case that each input has a separate signature? It seems that way from looking at the wiki. So does that mean I will be looking at 3N actual signatures, for N inputs? Previously I had only tried ultra-simple cases with 1 input. I appreciate there might also be an approach where you just throw the sigs at the transaction and see if it works, but as you say this could require several tries and feels very ugly. Still, if it works, I'm not complaining. I'm not 100% sure what you are saying here. Let me back up and use more accurate terms. A transaction has one or more inputs. Most transaction inputs have exactly one scriptSig.* A normal transaction scriptSig has one signature. A P2SH multisig transaction can have several. A signature (normal or P2SH multisig) has exactly one associated public key, which has exactly one associated address.** If you have a P2SH multisig address that requires X-of-Y signatures, and it has received N transactions, and you want to spend them all, that transaction will have between N*X and N*Y signatures. (In your example, this would be a minimum of 2N and a maximum of 3N.) As a side note, I just now realized that you were talking about transaction signatures in your first post, not message signatures. When signing a transaction with P2SH multisig, the pubkeys, their order, and the parameters (how many signatures out of how many possible) are all revealed. I suppose those could be stripped out if someone wanted to pass around just the bare signature. For small numbers of signatures (like in 2-of-3), they could be reconstructed. Note that D would have a valid transaction that he could broadcast if 2 of them are valid. I'm not positive about the previous two sentences, and I'm not wholly awake yet, so don't rely on them being right * P2SH is included in "most", we aren't going to worry about nonstandard multisig here.** Signature verification is done with the public key as a number, not with the pubkey packed representation of that number, while the address is derived from the packed form. This means that there are actually two possible addresses that could have signed the message, but we'll ignore the compressed one for now. |
|
|
|
The funny thing is he is just selling USB flash drives .... I can buy them anywhere, and cheaper.
Great sales line though: "It is durable with no moving parts".
Yes, we get that with USB drives. Its not like any of them ever spun round, not even the ones he claims pack in after 2 years (which they don't)
Flash memory leaks current and self-discharges over time. Two years in a drawer should be plenty of time to lose at least a few cells in a typical flash drive. USB drives also tend to suffer random bricking events. If you haven't seen either of these failures, you don't have enough flash drives. This thing gets linked up in just about every thread on key storage and cold wallets. But, I haven't seen anything from SanDisk on how they overcome the self-discharge problem inherent in flash memory. I haven't exactly gone looking for it, but you'd think they'd mention something in their marketing literature. |
|
|
|
It's been a while since I've used p2pool but I believe the payout system is PPLNS (Pay per last N shares). I don't think decentralized CPPSRBP is currently possible because there'd have to be some way to manage a pool wallet for when there's a surplus from a block reward/pay from it when needed and doing this in a decentralized manner would be very difficult.
The advantage of p2pool is decentralization/not trusting a centralized pool operator and helping the Bitcoin network by running a 24/7 full node. I'd recommend not using p2pool with a small hashrate because your payouts will be tiny and cost a lot to spend in terms of transaction fees.
do p2pool payouts unavoidably incur transaction fees? I don't understand enough about it to know for myself. If I am directly getting the mined coins that shouldn't happen right? A fee to me implies that someone is paying me a tiny amount. Thanks for your response btw. I'll probably stay on eligius, even though I do greatly want to help the network health. Ghash and guild should have 5% between them. Not over half. He means when you spend them later. The payments to you are indeed generation transactions and have no fees. Current payout for a single active share is something like 0.0045 BTC. A spend of 1 BTC using them will be like 50kb or something, and will need some fees. |
|
|
|
|
A P2SH multisig address is the hash of a structure containing multiple pubkeys. A P2SH address can't be used directly for signing, but the pubkeys involved can be.
In the reference client, you must provide an address when checking the signature. The call returns only true or false. There is a trivial patch to allow the function to return the address used in signing. Another trivial patch could return the pubkey directly.
In the OP scenario, the pubkeys are known, so the attacker can tell which of the signatures is invalid.
In general:
If D is using the reference client, and has only the multisig address and the three signatures, he can tell nothing at all.
With the same information, but different software, D can tell that at "least one signature is invalid or the multisig is not 2-of-3". He does this by pulling the pubkey from each signature, then trying all 6 possible orderings to see if any of them match the multisig address he has. (This is true of more than just 2-of-3, but the permutations get obnoxious.)
If D has the three signatures, the multisig address, and the three addresses (or pubkeys) that match the address, he can tell which one of them is invalid, and he can tell if the multisig address matches the pubkeys or not.
|
|
|
|
It would be almost trivial to implement— just bundle it, if nothing else. But I suspect the ship has already sailed for this.
Speaking of bundles, p2pcoin (in my sig) is a complete bitcoin/namecoin/p2pool system. I think it may be too fat for a bootable CD with the latest release, but you can put it on a USB stick, or serve it with PXE. You can configure it locally if you have storage, or serve configuration to a farm with DNS and HTTP. It uses bfgminer, so it should handle most miners, and can be configured to fall back to other local p2pcoin nodes, or to public pools. Oh, and if you have enough RAM, you can run the whole thing (including bitcoind and namecoind) entirely out of tmpfs, which is crazy fast. |
|
|
|
If your enterprise can't at least match the global growth rate, perhaps the world would be better off without you doing it, leaving that capital available to those who can.
And if their are idle resource and people then your argument falls apart because idle resource simply decay (both human and machine) and produce ZERO returns, any positive return is better then that. The history of interest rates clearly shows that interest dose not ONLY reflect an average of growth rates or even the average return on investment activity (which is what you meant to say). If the growth is happening elsewhere, perhaps the capital owner should consider scrapping the equipment and recycling it into a more productive industry. (Note that this is a restatement of my previous post. Recycling equipment is an example of "leaving that capital available to those who can [at least match the global growth rate]".) Just as an aside, in the situation where capital is idle and literally rotting in place, where is the growth coming from that is causing deflation? You do remember that when the money supply is fixed, deflation comes from the growth of wealth (which includes capital), right? And that growth isn't delivered by angels or storks, but by the application of capital. In that situation, growth would be low, and thus deflation would be low. People would have an incentive to lend at low rates during those times. I really do wish that you had paid more attention in high school chemistry class so that you could see dynamic equilibrium as a thing of beauty. It must be hell seeing the world through your eyes as the struggle between various external ghosts and spirits. |
|
|
|
In a sense yes, bankers and entrepreneurs are together doing all investments and my earlier comments on opportunity cost show that it doesn't matter WHO is providing the money, the interest rate gives the same incentive to DO or not do the investment if it is with borrowed money or your own money because the interest rate is for EVERYONE in an economy including the entrepreneur, it is as they say the most important price in the whole economy.
Your whole description of inflation and deflation in terms of 'pay in advance' vs 'pay after' is missing the point. Every possible investment activity involves turning liquid money into illiquid goods and then back into (hopefully) more money MANY MANY times in the course of a year, ideally as fast as you possibly can. The distinction of starting with your own money from savings or with loaned money is irreverent. What matters is your internal rate of return vs your interest rate. You must exceed interest rates to be considered 'a good investment' even if your self capitalized.
If your enterprise can't at least match the global growth rate, perhaps the world would be better off without you doing it, leaving that capital available to those who can. |
|
|
|
IRC was removed completely in 0.8.2.
The last of code was removed then, but it had been disabled since 0.6.0. What height is your 0.4 node at? Straggling 0.7 nodes got stuck again last week. 278114 which is current as I'm writing. Interestingly, this node has never been stuck like that. About a month after the great forking, I cranked up the locks and objects in DB_CONFIG as a precaution, but I have no idea why it didn't get stuck in the first place. I also have a 0.7.1 node that got stuck for the first time last week. Fortunately, it exists for the sole purpose of maintaining a set of old school 2GB block and index files for distribution, so it was easy enough to back it out to the last snapshot. I have vague plans to replace that node with a script to repack blocks from the new small block files (I don't have much use for the old indexes any more), but unless it starts crashing on a regular basis, I probably won't get around to it any time soon. Can someone tell me how exactly our nodes find each other since irc was removed? We don't get added to dns do we?
Read the link I posted. |
|
|
|
|
Ugh. Do we really need to start a brand new thread on this every few months?
At this point, is there even a slight chance of someone making a meaningful addition to the discussion that can be found in all of the many, many other threads on this topic?
|
|
|
|
I lack an understanding of how a lock time is specified.
So it locks certain keys, but everyone else can spend? If that's the case, then a complimentary function would have the desired effect. Bitcoin school please!
I'm trying to think of a secure way I could run into you on randomly in the forest, where there is no wifi, recall I owe you 5 bucks, and pay you because I happen to have a paper wallet printer on me. So I make a keypair, and say "here ya go. The coins are allocated to the priv key printed here, which is not so private anymore, so good think I locked it out for everyone on the planet except you. Have a nice day" I'm probably missing something though.
All transactions already have the property of being "locked out for everyone on the planet except you" where "you" is the holder of the private key. Addresses don't have balances, and can't be locked. The locktime field specifies the earliest time (or block number) that a transaction itself can be valid*. The locking action actually comes from sending to an address that you don't have the key to, the locktime unlocks them later. (Please see my long post earlier in this thread to see how it works.) In your example, you would be better off just printing a signed transaction to one of their addresses. If they don't have an address on them, you'd need to print out both a new private key, and a transaction that spends one of your coins to the address of the private key. * And just to be clear because this is dev/tech, it must be paired with a non-maximum sequence number to work. |
|
|
|
The next logical question is whether Lost Bitcoins are recoverable using quantum cryptography.
...
I haven't found a direct answer to the question so far.
Seriously? Despite the rumors, the search box here on the site is not used to send messages to Santa. It searches the site, and if you had used it to search for "quantum", you'd find many of the dozens of posts that do answer this question directly. |
|
|
|
If the Singularity follows Moore's Law and becomes exponentially intelligent in a relatively short period of time, when do you suppose it will acquire enough processing capacity to recreate the lost bitcoins?
No. Please do some research instead of asking why not. |
|
|
|
Wow, thanks! but that is WAY over my head. I'd better go watch the Khan Academy videos. . .
People will come up with pretty tools to make it easier as we go. But for now, the guts are certainly here and do work. This really can be done by hand though, if you have an urgent need to do it. Decoding a transaction in hex by hand is pretty easy. Just follow the docs and remember that each byte is 2 chars, and that you are counting in hex (in my example below, the pkscript length 19 is in hex and means 16+9=25). And double check everything before you send anything.
01000000 - version
01 - vin count
2084ba9f2f0f98bb - prevout hash
1cf0320ee1c486b5
9b6b79e243de7596
d3e44fa087b597aa
01000000 - prevout index
00 - signature script length
ffffffff - sequence
01 - vout count
00e1f50500000000 - value
19 - pkscript length
76a91428f60d621b - pkscript
5d07b9c2820c11cc
c6d41146b53a3e88
ac
00000000 - locktime
|
|
|
|
* As far as I know, there is no easy way to do this step. If people are serious about doing this, I'll see about adding a getpublickey RPC command.
There are so very many reasons for this, beyond just this application. Turns out I don't need to write getpublickey. validateaddress already does it. |
|
|
|
|
The answer seems to be "no".
|
|
|
|
First, grab a new address. Have them grab two new addresses. Have them give you one of their new addresses, and the public key* to the other. Use "bitcoind createmultisig 2 <yourpubkey> <theirpubkey>" to create a P2SH address that requires both keys. Create a raw transaction to this address. Don't broadcast it yet. (At this point, the raw transaction that you are holding irreversibly transfers coins from your control to a multisig address that requires both of you to redeem.) Create a raw transaction that redeems this unbroadcast transaction and spends it all** to their other address. The eight zeros at the end are the lock time, in hex. Edit them. Less than 500,000,000 is interpreted as a block number, greater than or equal is interpreted as a unix timestamp. Don't forget to convert to hex. Locktime is ignored when all inputs are already final, so you need to find the sequence numbers of the inputs. For this, you need to parse the transaction a bit, but this is easy to do by hand. They are eight Fs at the end of each input. Change at least one of them (to anything else). Now decode your raw transaction to make sure you edited it right. Verify that "locktime" is what you want, and that at least one vin sequence number is less than 4294967295. Use signrawtransaction to add your own signature.*** Send it to them to sign. Have them return the now fully signed transaction so that you can decode it again to make sure it is complete. (This new transaction transaction can, when the lock expires, spend the funds held by the multisig without your help.) Now use sendrawtransaction to broadcast the first transaction, and give the locked transaction to the gift recipient. The final state is that the gifted bitcoins are now in a transaction that you can only spend by getting them to sign a new transaction, but they now hold a transaction that you've already signed that will allow them to spend it to their own wallet. You can also do this all yourself, and provide them with the WIF of the two keys generated for them, along with the final signed transaction. If you delete all traces of the privkeys and WIFs, you end up in the same place. There are also variations you could do, like having them sign (or signing yourself if you are going that way) a second locked transaction that will allow you to recover the gift if not used. * As far as I know, there is no easy way to do this step. If people are serious about doing this, I'll see about adding a getpublickey RPC command. Use validateaddress (see below).** Try really hard to guess how much of a fee you'll need in the future. Too low and it might never confirm. Too high and you might be giving away a lot of money.*** You can change the order here. If you provide the redeemscript from the P2SH address created earlier, they can do the initial signing.Edit 2013-12-30 16:20 - changed first footnote. Thanks sipa. |
|
|
|
Meh. I think I found the source of opposition to wallet encryption: Armory paper backups are explicitly unencrypted. The vast majority of people using the paper backups is because they forgot their wallet password.
I'm just using this as an illustration because I read it recently. There are also countless threads around from people using the satoshi client asking how to recover their encrypted wallets with forgotten keys. The reason we aren't spending much time on fixing the problems with the current wallet is that we don't intend to keep our current wallet for very much longer. |
|
|
|
CURR=`bitcoind getinfo | grep blocks | cut -d ':' -f 2 | cut -d ',' -f 1`
for a in `seq 0 2016 $CURR` ; do
HASH=`bitcoind getblockhash $a`
TS=`bitcoind getblock $HASH | grep time | cut -d ':' -f 2 | cut -d ',' -f 1`
DIFF=`bitcoind getblock $HASH | grep difficulty | cut -d ':' -f 2 | cut -d ',' -f 1`
echo $a $TS $DIFF
done
0 1231006505 1.00000000
2016 1233063531 1.00000000
4032 1234466190 1.00000000
6048 1235966513 1.00000000
8064 1237508786 1.00000000
10080 1239055463 1.00000000
12096 1240599098 1.00000000
14112 1242098425 1.00000000
16128 1243737085 1.00000000
18144 1246051973 1.00000000
20160 1248481816 1.00000000
22176 1252069298 1.00000000
24192 1254454028 1.00000000
26208 1257002900 1.00000000
28224 1259358667 1.00000000
30240 1261130161 1.00000000
32256 1262153464 1.18289953
34272 1263250117 1.30506213
36288 1264424879 1.34422497
38304 1265319794 1.81864854
40320 1266191579 2.52773822
42336 1267000864 3.78117925
44352 1268010873 4.53108175
46368 1269212064 4.56516291
48384 1270120042 6.08547691
50400 1271061586 7.81979699
52416 1271886772 11.46431581
54432 1272966376 12.84918315
56448 1274278435 11.84622815
58464 1275141448 16.61907875
60480 1276298786 17.38148816
62496 1277382446 19.40479633
64512 1278381464 23.50125722
66528 1279008237 45.38582234
68544 1279297779 181.54328936
70560 1280198558 244.21322309
72576 1281037595 352.16120907
74592 1281870671 511.77353426
76608 1282864403 623.38695987
78624 1283922289 712.88486455
80640 1284861847 917.83074130
82656 1285703908 1318.67005015
84672 1286861705 1378.02816504
86688 1287637995 2149.02181495
88704 1288479527 3091.73689041
90720 1289305768 4536.35372328
92736 1290105874 6866.89864897
94752 1291135075 8078.19525793
96768 1291933202 12251.99976037
98784 1292956443 14484.16236123
100800 1294031411 16307.42093852
102816 1295101567 18437.64439217
104832 1296116171 22012.38133799
106848 1297140800 25997.87992881
108864 1298006152 36459.88692508
110880 1298800760 55589.51812687
112896 1299684355 76192.61934751
114912 1301020785 68977.78463021
116928 1302034197 82345.64411297
118944 1303112976 92347.59095209
120960 1304131980 109670.13329248
122976 1304975844 157416.40184365
124992 1305756287 244112.48777434
127008 1306435316 434877.04552763
129024 1307363105 567269.53016242
131040 1308145774 876954.49351354
133056 1308915923 1379192.28822808
135072 1309984546 1563027.99611622
137088 1311103389 1690895.80305239
139104 1312186279 1888786.70535305
141120 1313451894 1805700.83619367
143136 1314681303 1777774.48200146
145152 1315906316 1755425.32032870
147168 1317163624 1689334.40459710
149184 1318556675 1468195.42722083
151200 1320032534 1203461.92637997
153216 1321253770 1192497.75008948
155232 1322576420 1090715.68005127
157248 1323718955 1155038.33396364
159264 1324925005 1159929.49722438
161280 1326047176 1250757.73927466
163296 1327204504 1307728.36060407
165312 1328351561 1379647.43921429
167328 1329564255 1376302.26788638
169344 1330676736 1496978.59502557
171360 1331885394 1498294.36281651
173376 1332999707 1626553.48132894
175392 1334246689 1577913.48567673
177408 1335512370 1508589.67206029
179424 1336565313 1733207.51384839
181440 1337883029 1591074.96184731
183456 1339099525 1583177.84744401
185472 1340208964 1726566.55919348
187488 1341401841 1751454.53534068
189504 1342537166 1866391.30500321
191520 1343647577 2036671.08869332
193536 1344772855 2190865.97010286
195552 1345859199 2440642.60691596
197568 1346955037 2694047.95295501
199584 1348092851 2864140.50781097
201600 1349226660 3054627.52694864
203616 1350428168 3072321.73202076
205632 1351556195 3304356.39299034
207648 1352743186 3368767.14053294
209664 1353928229 3438908.96015914
211680 1355162613 3370181.79927784
213696 1356530740 2979636.61693807
215712 1357641634 3249549.58448721
217728 1358966487 2968775.33207507
219744 1360063146 3275464.58656562
221760 1361148470 3651011.63069321
223776 1362159764 4367876.00084220
225792 1363249946 4847647.15206561
227808 1364126425 6695826.28259625
229824 1365183643 7672999.92016414
231840 1366218134 8974296.01488785
233856 1367296471 10076292.88341872
235872 1368386123 11187257.46136079
237888 1369499746 12153411.70977583
239904 1370442318 15605632.68128593
241920 1371418654 19339258.27238668
243936 1372515725 21335329.11398300
245952 1373502163 26162875.68256990
247968 1374515827 31256960.72776893
249984 1375527115 37392766.13647456
252000 1376417490 50810339.04827648
254016 1377353319 65750060.14908481
256032 1378268460 86933017.77119441
258048 1379202248 112628548.66634709
260064 1380118146 148819199.80509263
262080 1381070552 189281249.28103292
264096 1381925788 267731249.48242110
266112 1382754272 390928787.63808584
268128 1383681123 510929738.01615179
270144 1384699499 609482679.88835454
272160 1385742648 707408283.05149662
274176 1386684686 908350862.43702197
276192 1387617112 1180923195.25802612
|
|
|
|
|
Show Posts
