Bitcoin Forum
May 02, 2024, 03:20:36 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 [58] 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 »
1141  Bitcoin / Development & Technical Discussion / Re: KISS pruning for the blockchain on: March 27, 2013, 01:05:06 PM
a very simple (KISS)
It is KISS as "Keep it slow and stupid". For homewhork please estimate the size of your proposed "S block" and the time it will take to transmit and verify it.
1142  Bitcoin / Bitcoin Discussion / Re: Data source url change (ticker, depth, history) on: March 27, 2013, 12:51:31 PM
But who will be kind to come answer my question?  Huh
The answer is that they are trying to provide support for the FIX protocol http://en.wikipedia.org/wiki/Financial_Information_eXchange .
Please learn it or be left it the dustbin. There is no way forward that continues to use the old RPC polling paradigm.

Yep, see the top of the thread. The APIs will stay the same at launch. We will probably layer on FIX support for CoinLab customers.
1143  Bitcoin / Development & Technical Discussion / Re: Creating an "official" protocol specification for the Bitcoin internet currency on: March 27, 2013, 03:41:37 AM
Oh well, I've tried. I've really tried to point that each coin has at least two sides, and that includes Bitcoin.

Time will show what had really mattered: exact standards, network effects, first mover advantage, human capital and other presumed highfalutin concepts.

Or just this:
Bitcoin Pizza Index = $801,896.65 .... 

http://www.ounce.me
1144  Bitcoin / Development & Technical Discussion / Re: Creating an "official" protocol specification for the Bitcoin internet currency on: March 27, 2013, 01:50:48 AM
this is about defining a standard not a brand name (do people use the internet because of its brand name? what a load of bs)
If "bs" stands for "bullshit" then you have a gc above your head, where "gc" stands for "glass ceiling". There isn't anything wrong with being focused on technological aspects of development.

But completely ignoring the finacial and game-theoretic aspects of development is a serious disadvantage in career advancement.

Yes, people do use and invest in Bitcoin because of the brand name and the brand mystique that was built around it. Just look at their reactions to any alternate cryptocurrency that is nearly identical from the technical point of view.
1145  Bitcoin / Development & Technical Discussion / Re: Creating an "official" protocol specification for the Bitcoin internet currency on: March 27, 2013, 01:39:07 AM
An interesting idea occurred to me... what if you could embed a hash of the protocol spec itself along in each block to be accepted by the network? This would mean that the definitions themselves could be set in stone.
For more detailed elaboration of this idea please see the first link in my signature.
1146  Bitcoin / Development & Technical Discussion / Re: Creating an "official" protocol specification for the Bitcoin internet currency on: March 27, 2013, 01:35:02 AM
For this reason, I think it would make sense to begin work (and it will be a lot of work!) on developing a working document, or some kind of mutually agreed upon standard that goes into greater depth than satoshi's paper on defining the nuts and bolts of what exactly Bitcoin is.
There isn't anything wrong with what you are proposing, aside from one thing: your proposal is completely skewed into the technical realm and into the total ignorance of marketing and game theoretic issues.

I'm an engineer by training, but I understand the language of business managers and marketing people. Unfortunately they rarely read this section of the forum, therefore you will normally not get the broad feedback that you desire.

What you are proposing is producing something akin to:
Code:
#define HASH(x) sha256(x)
#define P2PPORT 8333
#define RPCPORT 8332
Nothing wrong with the above. But because it is open source somebody will soon transfer it to
Code:
#if defined(BITCOIN)
#define HASH(x) sha256(x)
#define P2PPORT 8333
#define RPCPORT 8332
#elif defined(LITECOIN)
#define HASH(x) scrypt(x)
#define P2PPORT 9333
#define RPCPORT 9332
#elif defined(IXCOIN)
/* ... */
#elif defined(I0COIN)
/* ... */
#endif
In other words, you've magnamiously forfeited the advantage you had over the competition and commoditized your core product.

Maybe for the moment think of BTC as KFC (Kentucky Fried Coin) and your intention to publish a detailed information about the formula for the Colonel Sanders' secret seasoning and the process of how he arrived at it. You will immediately spawn numerous competitors peddling their version of Fried Chicken Coin.

If you don't like the above analogy then maybe think of how you would like to differentiate your Coca-Cola Coin from Pepsi-Cola Coin and RC-Cola Coin and whole slew of other immitators.

As an engineer you were probably trained to think that your goal is to minimize the number of defects in your software. Try for the moment to think like a CEO and maximize the stock price of your enterprise.

Do you see the problem now?
1147  Bitcoin / Bitcoin Technical Support / Re: Encrypted wallet.dat, lost password, any solutions? on: March 23, 2013, 07:14:30 PM
Hi 2112,

Does it mean that it is possible that if I created a wallet password in a PC which crashed, now in a new PC maybe Bitcoin-qt does not accept the password?

If this is the case, and I don't know the encoding of regedit.exe, what can I do to be sure that I test all the encoding possibilities in the ubuntu's terminal?

Thanks in advanced
Anything is possible, especially in the presence of bugs or various typing-utilities/spelling-checkers/etc. Blind typing into the bitcoin-qt window is a classic failure mode for that, e.g. for Germans: Kongressstraße vs. Kongreßstraße.

For KGB agents the example would be: Microsoft vs. Miсrosoft. (For non-KGB-agents: the second "c" is actually a cyrillic "s".)

Edit: Oh, and guys, please don't race into registering the homo-glyph accounts for the Bitcoin luminaries. Registering as "Gavin-non-break-space-Andresen" is not that funny.

Edit2: Fixed the external link.
1148  Bitcoin / Development & Technical Discussion / Re: A bitcoin UDP P2P protocol extension on: March 23, 2013, 07:01:48 PM
Can you point exact point I made mistake?
Sure. Network router load is calculated using two quantities: bps and pps; bits per second and packets per second. In addition you need to account for the round-trip latency of the peer-to-peer links.
Every full note will receive every block and every transaction exactly once - be it p2p, or multicast. Difference only comes from inv messages.
This is only asymptotically true. In fact it is completely false for a "well-connected miner". Lets assume the default maximum of 150 connections. After discovering a new block it will push 150 "Hurray!" messages. It will get 150 "Gimme!" messages from his peers, and will send 150 copies of the new block. And I'm discounting PSH+ACK packets that may be required (Hi Mr.Nagle!, if you are reading this; I guess not: Last Active: 2012-09-05, 14:06:16).

So this is minimum of 450 IP packets and 1 additional round-trip with TCP/IP flooding vs. 1 packet and 0 delay with UDP/IP multicast. I'm not going to even bother counting the bps load required, just the pps load savings are tremendous.
 
It will be true if multicasting was reliable/censorship-resistant. Any miner should run well-connected
node to help network.
I suggest that we leave the issues of cooperation vs. competition of Bitcoin users to an another occasion.

I'm not going to launch into an impromptu networking lecture. Anyone really interested with "why UDP?" and "why multicast?" and "how to make them reliable?" can search the ample documentation and deployment experience of financial extranets, e.g. NASDAQ.
1149  Bitcoin / Development & Technical Discussion / Re: A bitcoin UDP P2P protocol extension on: March 23, 2013, 05:37:59 PM
Tremendous? Hardly.
Let's see, how much can we save on inv messages.
We connected to, for example, 20 peers, current transaction rate is 60000 tx/day.
inv message is <100 bytes including TCP/IP overhead.
So, overall it's maximum 114 MB/day. Do not think it's too much for a full node.
Bandwidth is cheap today (~2$ per TB), so why bother?
Bloom filter makes inv spam non-issue (and can't be applied to broacast/multicast).
Invstigation into network topology and means to reduce
I think you've made a mistake in your calculations.

At the source of a transaction or a block none of the peers heard about it. So all the peers will ask the full transaction or the full block. Only at the later stages of the network flood the redundancy of p2p starts approaching the efficiency of multicast. The first stage is most crucial both in the cumulative sum of bandwith and the cumulative sum of bandwith*latency product, especially for the well-connected peers, for which number of connections is significantly greater than the default 8.

This is especially important for blocks, because multicasting of new blocks will reduce the probability of creating orphans.

In addition to facilitating IP broad-/multi-/any-cast the UDP is the first step to facilitating the transmission of the Bitcoin protocol over non-IP media, e.g. raw radio protocols.

Last but not least, learning about network multicasting and bandwidth sharing will probably help dispel other misconceptions prevalent amongst Bitcoin developers, epecially related to sharing of the blockchain storage. C.f. gmaxwell's defense of storing blockchain in a raw stdio/iostream file:
In this case, because the blockchain is inherently read only an append only stream is a fantastic, highly robust, extremely durable, and perfectly efficient data store for it.
1150  Bitcoin / Development & Technical Discussion / Re: A bitcoin UDP P2P protocol extension on: March 23, 2013, 04:28:46 PM
I just don't see how addition of UDP can help to solve any problems - current of future.
Supporting UDP is the first step required to support IP broadcast, multicast and anycast. This would realize tremendous savings of bandwidth. The current p2p network emulates broadcast in an extremely inefficient way with TCP/IP flooding, just because majority of the current ISPs don't have any way to properly route IP multicast traffic.

 
1151  Other / Politics & Society / Re: US plan calls for more scanning of private Web traffic, email on: March 22, 2013, 05:31:37 AM
It is for our own good.
Seriously, are you working for a defense contractor?

Quote
The U.S. government is expanding a cybersecurity program that scans Internet traffic headed into and out of defense contractors to include far more of the country's private, civilian-run infrastructure.
Quote
The official said the government had no plans to roll out any such form of government-guided close examination of Internet traffic into the communications companies serving the general public.

Some time ago we've sold some of our software to a middle-size US defense contractor. Our software has an internal self-test for trojaned DNS servers. Our front-line technician troubleshooted this and it turned out that the defense contractor was using OpenDNS.com configured for the "home network/children protection". This caused the intranet traffic inside the defense contractor to flow outside of the secure internal networks to the web-censorship servers run by OpenDNS.com in Europe. What a nice breach of security that was! Some of our US tech support personell got free security clearance renewals out of it.

If they're looking for spies, wouldn't it be best if the information reported back to them was SPECIFIC? (Who, What, Where, Why, When)
More likely they are looking for idiots and incompetents in the IT departments of the defense contractors. I did a cursory look at the list of enterprise clients of OpenDNS. This time I didn't see any obvious defense contractors. At the time of the above incident there was at least one defense contractor different than the our one.
1152  Alternate cryptocurrencies / Altcoin Discussion / Re: LTC FPGA's almost finished! on: March 22, 2013, 02:26:07 AM
Are you certain that every cell of memory is used each time?
Even if not, how long do the 1024 32-bit words have to stay valid until the next call to scrypt() overwrites all of them?
I honestly don't know.  Huh
Well, I have to admire your forthrightness here.

When doing 1 kilohash per second a completely new scrypt() is executed every 1ms, which overwrites all of the previous data.

The maximum refresh period for most of DRAM chips is on the order of 64ms.

For the homework solve the following problems:

1) how is the natural scrypt() refresh period affected by pipelining the implementation?
2) how is the natural scrypt() refresh period affected by reading the memory by a wider units than the 32-bit words native to scrypt()?

If you solve the above without cheating you can upgrade yourself from "internet engineer".  Wink
1153  Alternate cryptocurrencies / Altcoin Discussion / Re: LTC FPGA's almost finished! on: March 22, 2013, 12:11:18 AM
Are you certain that every cell of memory is used each time?
Even if not, how long do the 1024 32-bit words have to stay valid until the next call to scrypt() overwrites all of them?
1154  Alternate cryptocurrencies / Altcoin Discussion / Re: LTC FPGA's almost finished! on: March 21, 2013, 11:46:40 PM
You are right, it should work without refreshing. The question then is what is greater: The amount of invalid shares due to memory errors from non-deterministic refresh or the overhead from the refreshing circuitry?
I don't get it. Are you kidding? What memory errors? scrypt(1024,1,1) provides perfect memory refresh for free, unless you somehow slowed it down, e.g. by a breakpoint in debugging.
1155  Bitcoin / Bitcoin Technical Support / Re: Encrypted wallet.dat, lost password, any solutions? on: March 21, 2013, 10:33:23 PM
Thank you for your help, 2112.

However, if I am honest I do only have a faint idea of how to accomplish what you describe. Does the bitcoin client use different encodings on different platforms? The wallet was encriptded on a German Windows 7 installation; for running Revalins script I now use a German Ubuntu 12.04.

Do you have a concrete strategy how I could get Revalins script running using all characters on my keyboard?

Thank you
Well, you had a good idea to see if you can crack the known short password with umlauts.

1) I currently don't have access to any other machine except my single laptop, I really can't help you with details. In particular I'm almost illiterate in German.
2) verify if the "Language for non-Unicode programs" in Control Panel is still "German (Germany)".
3) using regedit.exe verify the settings in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\CodePage\ACP. It should probably be 1252 which means the Windows-1252 encoding was used for non-internationalized programs like Satoshi's client. Also note the OEMCP value from the same page. Ostensibly OEMCP is used only for DOS compatibility mode, but some programs use it because of bugs.
4) If you encrypted your wallet using bitcoin-Qt then verify that you can decrypt it from the command line by using bitcoind.
5) Make sure that the step 4) works for all umlauts you may have used, both lower-case and upper-case.
6) configure Ubuntu's terminal program to use Windows-1252 or if you access it from Windows via ssh configure your ssh client to use that encoding
7) rerun the test decryption of the known-password wallet on Ubuntu's command line.
8) verify that your Ruby program is using the correct encodings for umlauts
9) run the Ruby crack program

While I'm almost illiterate in German I'm very familiar with the computer-specific problems encountered by German-speaking people, especially in multi-language places like Switzerland. Because of the QWERTY vs. QWERTZ vs. AZERTY keyboard layout issue, when you were entering your password sight-unseen you may have entered some other characters because of accidental switching of the keyboard layouts. Have you actually verified in the Language Bar that you were using the correct layout while typing your password?
1156  Alternate cryptocurrencies / Altcoin Discussion / Re: LTC FPGA's almost finished! on: March 21, 2013, 09:26:58 PM
External DRAM, needs to dedicate FPGA resources for refreshing circuitry but memory is a lot cheaper and there might be spare logic blocks anyway (so that what I did bet on)
Why would you even enable refresh for the scrypt(1024,1,1) scratchpad? What is the probability that given memory cell in the scratchpad RAM will not be accessed within its maximum refresh period?
1157  Bitcoin / Bitcoin Discussion / Re: Storing BTC/LTC long term in safe deposit box on: March 21, 2013, 06:30:00 PM
When you say software and dependencies can you be more specific?
You'll need to preserve the software you used to create and manipulate your Bitcoin stash. Do not assume that it will not change. It will change and none of the current developers have the resources to properly test their current versions for backward compatibility with all previous versions of itself.

"Dependencies" means all the software required to build the software above. Edited to add: For exampe: if you used Armory on Ubuntu 12.04 then you need to save all the Ubuntu 12.04 plus the source code to the exact version of python, swig, Qt-toolkit and whatever else is being used to rebuild Armory.

I cannot be more specific, because I don't know the answer myself. You'll need to either learn this yourself or pay somebody to do the research for you. You can either do it now cheaply or later much more expensively.
1158  Bitcoin / Bitcoin Discussion / Re: Storing BTC/LTC long term in safe deposit box on: March 21, 2013, 05:55:50 PM
And put the hardware needed to use those things (i.e. a laptop) in the vault as well, along with complete instructions on how to redeem the stuff for fiat.
Hardware isn't really required. It is a commodity and easily virtualized or emulated. Store all the software required to access your wallet, including all the dependencies.

Also, of the generally available optical media DVD-RAM are the longest lasting and have the lowest failure rates.
1159  Bitcoin / Development & Technical Discussion / Re: Hacking Bitcoin on: March 21, 2013, 05:15:33 PM
... and drive away users, and make the value of Bitcoin nosedive.  Enjoy your increased-but-worth-less block reward?
Do you really think that making something more pricey will drive away users? There is a delicate balance between being too cheap and too expensive.

On this board you can probably review the marketing and pricing of the NEFT vodka.

The good, well documented case of marketing to upscale users is how Vulcan database became really popular after rebranding it to dBase II and rising the price several times.
1160  Bitcoin / Hardware / Re: The latest Avalon announcement in China(Translated). Batch #3 and more. on: March 21, 2013, 01:17:11 AM
88BTC 3 modules no psu
OK, so "doubly prosperous" number comes up again. Couple of months ago we used to speculate that the Avalon will have 88 chips.

https://bitcointalk.org/index.php?topic=120184.msg1402667#msg1402667

http://en.wikipedia.org/wiki/Numbers_in_Chinese_culture#Eight

This is probably going to be a very firm price then.

Which reminded me of Telly Savalas in Capricorn One:

http://www.youtube.com/watch?v=v8jJxKTFXPc

It is only 1'44", well worth watching.

EG: Mr Albaine, how much do you charge to dust a field?
TS: $25.
EG: I'd like to hire your plane.
TS: That'll be a $100.
EG: You said you charged $25?
TS: $25 to dust a field, but you ain't got no field because you ain't no farmer, which means you ain't poor and I think you're a pervert!
EG: Okay, $100.
TS: $125.
EG: What?
TS: Because you said yes to a $100 too quick, which means you can afford a $125.
Pages: « 1 ... 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 [58] 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!