I added "DONTFUKGOHERE" in the link so it is useless.
Gives an SSL warning, and I just happen to be logged out.
C'mon, this is completely safe. 109.201.133.65 is just the current IPv4 address for the bitcointalk.org. The browser store the authentication cookie indexed by the string value of the "website" portion of the URL. The warning was propably that "109.201.133.65" != "bitcointalk.org". You can safely log in to https://109.201.133.65/ with the same credentials as to the https://bitcointalk.org/ after verifying that the certificate is indeed for "bitcointalk.org". Same browsers are/were so paranoid that would force another session when the URL would be https://bitcointalk.org:443/ , where 443 is the default HTTPS port. I think that as far as browsers go only Internet Explorer (maybe some older versions, like IE6) had a cookie and/or authentication credentials storage indexed by the server certificates, not by the URL strings. Several HTTP/HTTPS libraries have this functionality built-in. |
|
|
|
|
Is it difficult to add the same to the stylesheet that governs the "Show the last posts of this person" page? Thanks.
|
|
|
|
Too early for all that. What you propose makes sense, but you are simply ahead of your time. People need to grow into the concepts involved and as of now your ideas aren't yet ripe.
It's too early to make sense? I don't understand. You seem to not understand enough of both Bitcoin technology itself and the social framework which shapes it. (i) you've made a mention of "altcoin"s without mentioning "alt-Bitcoin"s. Bitcoin as a mathematical system creates a class of isomorphic cryptocurrencies. There is between 2 160 and 2 256 (the exact number is immaterial, it is a large number comparable to the number of atoms in the whole planet) of them, each of those systems self-limited to 21*10 6 units. Although all those iso-Bitcoin cryptocurrencies are mathematically equivalent, the regular Bitcoin supporters will claim that only the coin anchored at 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f is a true-Bitcoin, all others being false-Bitcoins. This is mathematically false, but socially true. The prime socially-differentiating factor is that the ...8ce26f iso-Bitcoin makes different people rich than all other iso-Bitcoins that can be started in the future with a different anchor and different people getting rich while mining them. This has nothing to do with the "altcoin"s that are not isomorphic to the Bitcoin system and discussed on the "alternate currency" subforum. (ii) you seem to belong in the minority that takes the Bitcoin ideals on the face value, whereas the majority of Bitcoin supporters are there in hope of increasing their wealth in the legacy currencies or just for the opportunity to kill some bankers. To make a simple analogy with the historical events: you are one of the rare persons who took "Liberté, égalité, fraternité" at the face value, whereas bulk of the French Revolutionaries was there because it gave them opportunity to kill priests and expropriate anyone they didn't liked. In summary I think you seem to consider Bitcoin like any other technical invention that needs to be optimized and popularized. It is mostly true, but far from being true in the deeper details and in the social context. While I admire your proposal I'm going to put it next to the books about the adventures of Pollyanna. |
|
|
|
|
Too early for all that. What you propose makes sense, but you are simply ahead of your time. People need to grow into the concepts involved and as of now your ideas aren't yet ripe.
|
|
|
|
|
tysat, I thank you very much.
|
|
|
|
The thread is you begging for BTC pretty much. There's no point to keeping it around, if we do everyone else will post them too.
The amateur anthropologist in me is completely mesmerized: is there a new way of begging for Bitcoins? Maybe one of the moderators with the access to the trashcan subforum could copy-paste the orginal plea? Just give it what Gawker Media blogs called "disemvowelment": delete all the English language vowels. I beg you: please do that for science, just this one time, in a separate post in this thread, so that bitcoinator will not be able to reemvowel it. |
|
|
|
This thread just got referenced in another piece of misinformation regarding the internals of Bitcoin. I used to think that the big-endian vs. little-endian is something that confuses only undergraduates. But apparently many more people continue to get confused by the strange byte ordering in the Bitcoin code: it is neither big-endian nor little-endian. It was most likely defined accidentally to use the internal representation of the OpenSSL library that used hand-written assembly for speed on the 32-bit Intel architecture. I used to recommend MacOSX as bi-endian platform that is easiest to work with. But Snow Leopard is the version that officially supports bi-endianness and the hardware to run it is getting hard to come by. I'm going to post a short demonstration program that is probably a quickest way to convince the wondering programmer that Bitcoin protocol is neither big-endian nor little-endian. To compile use the following command on Mac OSX 10.[56]: gcc -arch i386 -arch ppc mojibake.c -o mojibake Source: #include <stdio.h>
union mojibake {
unsigned char b[32],
b1[32][1],b2[16][2],b4[8][4],
b8[4][8],b16[2][16],b32[1][32];
unsigned short h[16];
unsigned int w[8];
unsigned long long d[4];
} x;
#if defined(__LITTLE_ENDIAN__) || defined(_MSC_VER)
#define E(N,j) (N-1-(j))
#elif defined(__BIG_ENDIAN__)
#define E(N,j) (j)
#else
#error not tested under this compiler
#endif
#define NL putchar('\n')
#define P(N) \
for (i = 0; i < 32/N; ++i) { \
printf("%*c",N,' '); \
for (j = 0; j < N; ++j) \
printf("%02x",x.b##N[i][E(N,j)]); \
} \
NL,NL
int main(int ac,char **av)
{
int i,j;
if (ac < 2)
ugh: return printf("usage: %s <c>\n"
"where: <c> is l or b or m\n"
" for l)ittle endian\n"
" or b)ig endian\n"
" or m)ojibake endian\n",av[0]);
switch (av[1][0]) {
case 'l': case 'L':
for (i = 0; i < sizeof x; ++i)
x.b[i] = i;
break;
case 'b': case 'B':
for (i = 0; i < sizeof x; ++i)
x.b[(sizeof x - 1) - i] = i;
break;
case 'm': case 'M':
for (i = 0; i < sizeof x; ++i)
x.b4[7-i/4][i%4] = i;
break;
default:
goto ugh;
}
for (i = 0; i < sizeof x; ++i)
printf("%1c%02x",' ',x.b[i]);
NL,NL;
for (i = 0; i < sizeof x/sizeof(short); ++i)
printf("%2c%04x",' ',x.h[i]);
NL,NL;
for (i = 0; i < sizeof x/sizeof(int); ++i)
printf("%4c%08x",' ',x.w[i]);
NL,NL;
for (i = 0; i < sizeof x/sizeof(long long); ++i)
printf("%8c%016llx",' ',x.d[i]);
NL,NL;
/*
P(2);
P(4);
*/
P(8);
P(16);
P(32);
return 0;
}
Output in the little-endian mode: $ arch -i386 ./mojibake l
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
0100 0302 0504 0706 0908 0b0a 0d0c 0f0e 1110 1312 1514 1716 1918 1b1a 1d1c 1f1e
03020100 07060504 0b0a0908 0f0e0d0c 13121110 17161514 1b1a1918 1f1e1d1c
0706050403020100 0f0e0d0c0b0a0908 1716151413121110 1f1e1d1c1b1a1918
0706050403020100 0f0e0d0c0b0a0908 1716151413121110 1f1e1d1c1b1a1918
0f0e0d0c0b0a09080706050403020100 1f1e1d1c1b1a19181716151413121110
1f1e1d1c1b1a191817161514131211100f0e0d0c0b0a09080706050403020100
$ arch -i386 ./mojibake b
1f 1e 1d 1c 1b 1a 19 18 17 16 15 14 13 12 11 10 0f 0e 0d 0c 0b 0a 09 08 07 06 05 04 03 02 01 00
1e1f 1c1d 1a1b 1819 1617 1415 1213 1011 0e0f 0c0d 0a0b 0809 0607 0405 0203 0001
1c1d1e1f 18191a1b 14151617 10111213 0c0d0e0f 08090a0b 04050607 00010203
18191a1b1c1d1e1f 1011121314151617 08090a0b0c0d0e0f 0001020304050607
18191a1b1c1d1e1f 1011121314151617 08090a0b0c0d0e0f 0001020304050607
101112131415161718191a1b1c1d1e1f 000102030405060708090a0b0c0d0e0f
000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f
$ arch -i386 ./mojibake m
1c 1d 1e 1f 18 19 1a 1b 14 15 16 17 10 11 12 13 0c 0d 0e 0f 08 09 0a 0b 04 05 06 07 00 01 02 03
1d1c 1f1e 1918 1b1a 1514 1716 1110 1312 0d0c 0f0e 0908 0b0a 0504 0706 0100 0302
1f1e1d1c 1b1a1918 17161514 13121110 0f0e0d0c 0b0a0908 07060504 03020100
1b1a19181f1e1d1c 1312111017161514 0b0a09080f0e0d0c 0302010007060504
1b1a19181f1e1d1c 1312111017161514 0b0a09080f0e0d0c 0302010007060504
13121110171615141b1a19181f1e1d1c 03020100070605040b0a09080f0e0d0c
03020100070605040b0a09080f0e0d0c13121110171615141b1a19181f1e1d1c
Output in the big-endian mode: $ arch -ppc ./mojibake l
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
0001 0203 0405 0607 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f
00010203 04050607 08090a0b 0c0d0e0f 10111213 14151617 18191a1b 1c1d1e1f
0001020304050607 08090a0b0c0d0e0f 1011121314151617 18191a1b1c1d1e1f
0001020304050607 08090a0b0c0d0e0f 1011121314151617 18191a1b1c1d1e1f
000102030405060708090a0b0c0d0e0f 101112131415161718191a1b1c1d1e1f
000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f
$ arch -ppc ./mojibake b
1f 1e 1d 1c 1b 1a 19 18 17 16 15 14 13 12 11 10 0f 0e 0d 0c 0b 0a 09 08 07 06 05 04 03 02 01 00
1f1e 1d1c 1b1a 1918 1716 1514 1312 1110 0f0e 0d0c 0b0a 0908 0706 0504 0302 0100
1f1e1d1c 1b1a1918 17161514 13121110 0f0e0d0c 0b0a0908 07060504 03020100
1f1e1d1c1b1a1918 1716151413121110 0f0e0d0c0b0a0908 0706050403020100
1f1e1d1c1b1a1918 1716151413121110 0f0e0d0c0b0a0908 0706050403020100
1f1e1d1c1b1a19181716151413121110 0f0e0d0c0b0a09080706050403020100
1f1e1d1c1b1a191817161514131211100f0e0d0c0b0a09080706050403020100
$ arch -ppc ./mojibake m
1c 1d 1e 1f 18 19 1a 1b 14 15 16 17 10 11 12 13 0c 0d 0e 0f 08 09 0a 0b 04 05 06 07 00 01 02 03
1c1d 1e1f 1819 1a1b 1415 1617 1011 1213 0c0d 0e0f 0809 0a0b 0405 0607 0001 0203
1c1d1e1f 18191a1b 14151617 10111213 0c0d0e0f 08090a0b 04050607 00010203
1c1d1e1f18191a1b 1415161710111213 0c0d0e0f08090a0b 0405060700010203
1c1d1e1f18191a1b 1415161710111213 0c0d0e0f08090a0b 0405060700010203
1c1d1e1f18191a1b1415161710111213 0c0d0e0f08090a0b0405060700010203
1c1d1e1f18191a1b14151617101112130c0d0e0f08090a0b0405060700010203
It is probably easiest to compare the last two code inserts either side-by-side or using a visual diff utility. |
|
|
|
heh, nothing is free. This proposal would add additional round-trips with associated latency, slowing block validation and block propagation.
As such, miners could lose their 25 BTC due to orphaning, if their block is slowed.
Actually you are wrong. The average block propagation latency would improve, both in case of honest miners and secretive miners. Firstly, let me explain honest/secretive miner distinction. Honest miner broadcasts all the transactions that he's going to put in the block ahead of time. Then when he wins the block he sends all the transactions once again just to comply with the classic/inefficient block propagation protocol, wasting up to 50% of overall bandwidth. On the other hand secretive miner tries to play games to disadvantage other miners and raise their orphan rate. He omits broadcasting private transactions separately and when he wins the block he sends those private transactions for the first time. It saves his bandwidth, but disadvantages the competing miners because they see the transactions late and have to spend time to verify them. So for the network of mostly honest miners there simply isn't any additional round trips and the win is 100% clear. Sending just the block header and the Merkle tree is a no-brainer. To understand why even the secretive miners case is a net win for the global network is somewhat more complicated. Firstly, the "round-trips" should be singular: only one additional round trip is required to ask for the private transactions of the uncooperative miner. Secondly, you'll have to understand how the bandwidth is getting sold nowadays. It is very rare to actually linearly limit the bandwith sold to eg. 1ms per bit for 1 Megabit per second. Nearly every modern IP transport uses some sort of statistical limiter/multiplexer. When you buy e.g. 10Mbits per second your effective bandwidth may be 1Gigabit per second for the first, say 4kilobytes and the statistical multiplexer/limiter will throttle your remaining kilobytes to maintain the long-term average. When asked some ISPs will plainly state the setting for e.g. "fair-queue" command in Cisco IOS. Most ISPs will however consider those setting a trade secret; and frequently they change them according to the time-of-day, day-of-the-week or even to quell the packet storms after "network events". The interested reader can either read up about the above: e.g. it is called PowerBoost with the DOCSIS cable modems. Anyone with two machines, two GPS receivers to NTP-sync the time on them and a copy of Wireshark can verify what I wrote above running their own experiments and as a side effect reverse-engineer the setting used by their ISP. To quickly summarize the above two paragraphs: the latency to send e.g. first 4kB of 1MB block is much less than 4/1000 of the latency of the whole block. I understand that implementing the changes suggested by piotr_n isn't trivial. But if implemented they will give at least two benefits to the global Bitcoin network: 1) information theoretic benefit of saving the bandwith, reducing the block propagation latency and thus reducing the orphan rate 2) motivate more miners to be honest about broadcasting transactions. This will probably have further domino-effect of improving overall game-theorethic strength of the Bitcoin network and may allow in the future to detect some attacks which we even haven't thought through. In summary I wanted to stress that I enjoyed this brief, but honest exchange of technical arguments with you. Thanks. |
|
|
|
You're just confused, sorry. You have to download all data in every block to run a full node. This is fundamental. You can't reduce bandwidth usage by downloading parts of each block from different peers. This might reduce the upload bandwidth on their side, but it doesn't reduce the download bandwidth on your side. If you're talking about hosting blocks on Cloudfare then you're talking about download bandwidth. So your proposed change wouldn't impact anything.
The above is just another example how Mike Hearn spreads misinformation about Bitcoin protocol. For normal operation of the Bitcoin network the majority of the "block" has already been previously transferred as a separate "transactions". The obvious optimization of the bandwidth usage is for the clients to inspect the Merkle tree and ask the peer only for the transactions that weren't previously broadcast. This gives close to 50% bandwidth savings for free. I'm writing this to underline the fact that whenver you read something written by Mike Hearn you have to double check and verify for yourself the 3 broad possibilities: 1) he was correct; 2) he was incorrect because he didn't understand the question or doesn't understand the underlying tehnology; 3) he was incorrect intentionally to disparage other developers and spread misinformation. Thankfully for now he still doesn't belong to the core development team. |
|
|
|
I originally wrote this post couple of days ago in response to another humorous/pithy comment. However the original comment got deleted before I finished editing it and it made almost no sense afterwards. It appears that this thread is now approaching its end and I decided to post re-edited version of it to put it in a permanent public record. The original Greenspun's tenth rule of programming states: Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.
I propose a modified version of it pertaining to Bitcoin and other blockchain-based cryptocurrencies: Any sufficiently complete attempt at implementing Bitcoin will contain an ad hoc, informally-specified, bug-ridden, slow implementation of half of MUMPS.
I'm trying to suggest that MUMPS should be used to implement Bitcoin. I'm just observing that there will be tremendous amount of work expended to re-invent and re-implement one key feature of MUMPS: larger-than-core sparse hierarchical tree storage with all the expected ACID properties. For those who are interested why the technology from circa 1975 outperforms all previous attempts at blockchain storage (both full and pruned) I have the following links: It is a shame that I don't know of any open-source software that is compatible with the MIT license and other requirements specific to Bitcoin. |
|
|
|
The problems have todo with the fact, that Satoshi Nakamoto as cryptologist forgot to implement the basics of normal bookkeeping.
He ignored the fact, that his blockchain is logically nothing else than a normal bank and should work like that, of course.
His main factual interest ("prevent double-spending") would be -since logically impossible- no special problem at all.
Today I had an opportunity to open the first edition of Bruce Schneier's "Applied Cryptography" from 1994. The second paragraph of the "Digital Cash" chapter explains double-spends in his rare style that is both highly entertaining and highly educational. Since we now have year 2013 this marks nearly two decades of you being out of touch with the progress in your claimed field of expertise. Happily, there is a complicated protocol that allows for authentic but untraceable messages. Lobbyist Alice can transfer digital "cash" to Senator Bob so that newspaper reporter Eve does not know the identity of Alice. Bob can then deposit that electronic money into his bank account, even though the bank has no idea who Alice is. But if Alice tries to bribe two different Congresspersons with the same piece of digital cash, which is easy to try with a bit copy program, she will be detected by the bank. And if Bob tries to deposit the same piece of digital cash into two different accounts, he will be detected--but Alice will remain anonymous.
|
|
|
|
@LvM I presume that you are German and because you title yourself PROFESSIONAL you hold a Dipl.Ing. certificate or some such. As a holder of such certificate you have some ethical obligations, e.g. a) do not consult outside of your area of expertise b) continuously educate yourself on the progress in your area. You failed on both counts. Germany has a long history of an effective regulation, most famously the German Beer Purity Law from 1516. Violations of that law were punished by burning all the tools used to brew and/or sell beer in a negligent way. The repeated offenders were publicly whipped at a pillory. Here you are getting off easy: nobody's going to burn your computers and you will be subject just to the some ridicule, not a corporal punishment. If you need inspiration on how to fuse the Bitcoin technology with the traditional banking and finance technology take an example from grau and his bitsofproof. https://bitcointalk.org/index.php?topic=122013.msg1350149#msg1350149Edit: corrected the spelling of Dipl.Ing. (Diplom-Ingenieur, German equivalent of Master of Science) |
|
|
|
Oh Lordy! Those are the best unintentionally funny posts in a long time. I just quote them for the future reference, when I have to retell the story of "professional code monkey contra Bitcoin". Not just plain, garden-variety, cowboy code monkey a PROFESSIONAL code monkey. When "Who moved my cheese?" was published and became an instant hit I keept saying that the book is so exagerrated that it becomes an unintentional comedy. Now I know that this book was not an exagerration. I'm going to quote the signature too, because it makes the whole story even funnier: @etotheipiBe sure, any halfway experienced developer having to communicate with other Computers/datas first of all studies the BASICS, often called "protocols". This was one of the first things I did, of course - weeks ago. Spent hours and days searching usable, complete and reliable infos, starting with Satoshis paper (in this respect totally unusable). I really couldn't and can't believe it. I am working with databases since decades, first programming them myself (yes!), then using half a dozen of all the very similar DBMS (dBase, SQL, MySQL, BdB ...). The basics are logically always the same: Headers, records, fields, indexfiles. If variable field lens are used, we need delimiters or len specifiers for them. Any encryption, hashes, Endianness, compression... are next to be explained. I normally have no problem with all that. Normal electronic banking belongs to the easiest things I do. Since databases never are loaded into memory they normally are not splitted as in BTC with its numerous blkxxx.dat + revxxx.dat This and much more I would like to understand. Seearching for infos about BTC I found a mess of superficial, inconstistent mixtures of this and that, advertising and promotion mixed with technical infos, even "Messages" and DB-structures -although complete different things- mixed together, nothing fully explained. Why James, Bitrick, etotheipi tried to provide what I am searching for? Thats why I asked my silly questions. Where eg. is the date/time of transfers ? The "lock_time" is a different thing, mostly zero. The block creation time might be interesting for miners or other internals, not for applications. Just because you mentioned it above, lets take another example: Above you write about "BlockHeader(80)" whereas in the https://en.bitcoin.it/wiki/Protocol_specificationthe field sizes of Block Headers are 81. You know it yourself: One byte difference on this level is enough to crash a complete app. Satoshi Nakamoto, naming himself the "founder" of BTC might be an expert in cryptology. This might explain that all what he writes in his basic article "Bitcoin: A Peer-to-Peer Electronic Cash System"http://bitcoin.org/bitcoin.pdfhas NOTHING todo with basic knowledge of money and bookkeeping. His main factual problem is his so called "prevent double-spending". Normally "a trusted third party [bank] is required to prevent double-spending" he tells us. Sorry. Never heard that "double-spending" i.e. spending the same money (or other things) twice is possible at all. In case of real coins (and all other things) each child knows that, I hope. In case of cashless payments its exactly the same since each payment reduces my disposable fund. Where no money, there no payment.Controlling that by software designed to manage whichever currency is normally the easiest thing at all. Security and privacy are very important, but totally different questions. They have as in all other cases (cars, gold or potatoes) logically nothing todo with the things protected. But Satoshi Nakamoto sees that quite different, stylizing prevent of "double-spending" of BTC to the main task BTC has to care for. Talking about Bitcoins in its title the central topic BTC is mentioned in his paper not even ONCE. Instead he only speaks about important but secondary problems, about hashes, keys, "proof-of-work" etc. But first comes the basic logic, then security and encryption - everywhere. This might explain that even the basic logic of BTC is at least for me not understandable at all. Perhaps he didn't understand it himself.  Nakamoto/BTC vs. bookkeeping As I wrote Bitcoins are money.
The basic logic of money transfers from A to B normally belongs to the easiest things in the world.
Technical things like encryption or the structure of involved databases change nothing in the very, very simple logic of money transfers.
In short:
A minus for the payer is a plus for the receiver.
At least time and reason of transfers are always added normally.
All is collected and balanced in the accounts of payers/receivers.
Easiest bookkeeping.
Some of these things either do not exist in BTC or simply are somehow hidden.
Where e.g. is the field for the transaction date/time?
I assume that there IS one, since Armory restored by the blockchain date and time of my transactions.
Lost after a restore were my manual "Comments" of transactions only.
BTC does indeed not have a field for the reason of transfers.
Other things like the strange "changings" not to mention....
Sorry, but even after reading quite a lot I am far away to understand that.
Satoshi Nakamoto writes: Abstract. A purely peer-to-peer version of electronic cash would allow online payments to be sent directly from one party to another without going through a financial institution. Digital signatures provide part of the solution, but the main benefits are lost if a trusted third party is still required to prevent double-spending. We propose a solution to the double-spending problem using a peer-to-peer network. The network timestamps transactions by hashing them into an ongoing chain of hash-based proof-of-work, forming a record that cannot be changed without redoing the proof-of-work. The longest chain not only serves as proof of the sequence of events witnessed, but proof that it came from the largest pool of CPU power. As long as a majority of CPU power is controlled by nodes that are not cooperating to attack the network, they'll generate the longest chain and outpace attackers. The network itself requires minimal structure. Messages are broadcast on a best effort basis, and nodes can leave and rejoin the network at will, accepting the longest proof-of-work chain as proof of what happened while they were gone. ... In this paper, we propose a solution to the double-spending problem using a peer-to-peer distributed timestamp server to generate computational proof of the chronological order of transactions. The system is secure as long as honest(??) nodes collectively control more CPU power than any cooperating group of attacker nodes. 9. Combining and Splitting Value (unbelievable!!)) Although it would be possible to handle coins individually (  ), it would be unwieldy to make a SEPARATE TRANSACTION FOR EVERY CENT( ) IN A TRANSFER. To allow value to be split and combined,( ) transactions contain multiple inputs and outputs. Normally there will be either a single input from a larger previous transaction or multiple inputs combining smaller amounts, and at most two outputs: one for the payment, and one returning the change, if any, back to the sender. ? (unbelievable!!) 12. ConclusionWe have proposed a system for electronic transactions without relying on trust. [cmnt: misleading! we rely on trust. Trusted "party" is just like a bank the public blockchain!!] We started with the usual framework of coins made from digital signatures, which provides strong control of ownership, but is incomplete without a way to prevent double-spending. To solve this, we proposed a peer-to-peer network using proof-of-work to record a public history of transactions that quickly becomes computationally impractical for an attacker to change if honest( ?) nodes control a majority of CPU power. The network is robust in its unstructured simplicity. Nodes work all at once with little coordination. They do not need to be identified, since messages are not routed to any particular place and only need to be delivered on a best effort basis. Nodes can leave and rejoin the network at will, accepting the proof-of-work chain as proof of what happened while they were gone. They vote with their CPU power, expressing their acceptance of valid blocks by working on extending them and rejecting invalid blocks by refusing to work on them. Any needed rules and incentives can be enforced with this consensus mechanism. ======================== It might be a sacred cow, but I can't help it: The basic logic of BTC as explained by Nakamoto himself, is wrong.This does not mean, BTC is not usable at all. But most complications have nothing todo with encryption or the public peer-to-peer database/network. These are secondary technical questions, used except the public database in all "normal" electronic banking. The problems have todo with the fact, that Satoshi Nakamoto as cryptologist forgot to implement the basics of normal bookkeeping. He ignored the fact, that his blockchain is logically nothing else than a normal bank and should work like that, of course. His main factual interest ("prevent double-spending") would be -since logically impossible- no special problem at all. |
|
|
|
high intelligence and being adept with any sort of technology have always been valuable skill sets.
The problem probably starts with needlessly putting the equivalence between the two clauses of the above sentence: high inteligence and high aptitude in the CS or EE fields. But anyone who had a closer experience with the CS/EE education/training/testing will know that the field is full of way-below-average-intelligence people who can compensate with extraordinary memorization skills or simple extraodinary perseverance in trial&error development. Because the feedback from the computers is completely free of emotions the dull-but-persistent will naturally gravitate towards workplaces where the nearly entire workflow is performed alone with no human interactions and the only material consumed is the workers time and a little electricity. And this board is full of the people from the above paragraph: painstakingly working alone trying all possible combinations and publishing only when the success was achieved. To an outside observer it may look like extraordinary inteligence and/or productivity, but the reality is completely different. Again anyone with closer personal experience with CS/EE project development knows and recognizes the bitter, aggresive and humourless burnouts that are casualties of some such projects. It is a kind of occupational hazard, sort of like ADHD for traders. |
|
|
|
I just wanted to inject an example of a rare IT person (I wouldn't call him geek) who understands the divide-and-impera concept. His comments are in the Alternate cryptocurrentcies subforum in the "A proposed fair premine idea": The banking system is where it is because of the greed, because they want more that they can need. But the banking system is using a "centralized greed", but in crypto world is a P2P greed, envy and hypocrisy. The ones that have a lot of coin X (this is including BITCOIN) will defend that coin no matter how broken or flawed it is, the ones that are late will hate them and will try to bring the coin down or to clone it for a quick profit.
At this pace, the crypto coins will remain a geek only thing, where the guys that where early on the bitcoin can afford big rigs to take down new coins, and the late guys will clone some coins to make a quick profit.
Unless we don't get our shit together and don't acknowledge that:
1. we need incremental coins
2. the developers need to be payed in some way for their work, like the miners are now.
You think that a good programmer will quite his job to donate his time just so you can mine and make a profit?
In a way, the Bitcoin is a nearly perfect example of how to execute a divide-and-impera strategy: draw a bandwagon with 21000000 seats and make the early jumpers-on fight the late jumpers-on. Then watch the commotion safely from the distance. |
|
|
|
This recurring and overblown worry about lost coins has me wondering of the source.
I'm presuming this has little to do with truly protecting bitcoin, but instead is all about getting a foot in the door with some method of demurrage (call it reclaiming of "lost" coins or whatever). Get that implmented and then a protocol change for currency inflation or some type of taxation is just an incremental step further.
I understand your concern above, but my thinking is more skewed to applying the Hanlon's razor: a combination of two phenomenons: a) intense misinformation about Bitcoin's properties both amongst its supporters and its detractors; b) influx of extremely literally-minded people who have difficulty with abstract or transcendental thinking; makes people worry that the bean-counting professions will either run out of beans to count or bean-counting will be supplanted by e.g. pea-counting. I don't see any cunning or even any long-term planning: it is just a pre-conditioned response to an unfamiliar stymuli. |
|
|
|
|
I'm going to meekly oppose this. Please don't go deeper into mixing the trade with the talk. Please let this forum stay the "talk" forum, an information exchange. Spin off the trade to Bitcointrade.biz or whatever and have as many authentication factors as you can stand.
I know it is hopeless, but I'm going to ask for the return of the plain http:// acccess to this forum, I'd really miss accessing it through the Opera's proxy servers on the low-bandwidth connections.
|
|
|
|
I'm afraid it's not quite that simple... So, assuming that the BTC-based economy will eventually flourish, can you imaging the ripple effect an act of trashing a single bitcoin could have on that economy? You have an imagination of some sort techno-taliban: like if dynamiting the Buddha statues would damage buddism. |
|
|
|
Please don't change anything. Bitcointalk.org is nearly perfect as is. The steady supply of the "less intelligent" is how the "more intelligent" can continuously take profits in the capital markets. I think Soros Shorts summed this up perfectly, I'm quoting him so in the future I can easier find that tidbit of knowledge. And if you're one of the lucky few who make money on them, don't expect me to admire your investing wisdom, any more than I'd admire the number-picking brilliance of a lottery winner.
I disagree. Being able to correctly read the general emotion of the investing "herd" is a far, far more valuable skill than being able to do fundamental and qualitative analysis of an investment. I am an engineer by training, and it took me way too long to discover this. |
|
|
|
You can't change it to what it currently is?
It is not the same as leaving it unchanged. The key streetching parameter is recomputed afresh with each passphrase change, and this may be undesirable. I simply tried to send more coins that the wallet contains in total: I would safely get an error message stating the above after the successfull decryption. I haven't tried the most recent code, I'm still running the older versions, the code may have changed. |
|
|
|
|
Show Posts
