Bitcoin Forum
June 26, 2022, 05:52:02 PM *
News: Latest Bitcoin Core release: 23.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 »
1  Bitcoin / Development & Technical Discussion / Re: NSA and ECC on: October 02, 2013, 07:09:20 PM
Our group is prime and has no sub groups so any point should work as G.

This brings up something that I have been wondering about:

If any point will work equally well for G why not use an "easy" point or an "obvious" point?

x = 0 or x = 1 or x = 2n all come to mind.

Anyone have any idea why G is not a more "obvious" starting point?

Well, the point must lie on the curve, so it must satisfy   y2 = x3 + 7 (mod p).

So x=0, means y2=7, which has no solution for an integer y, so there is no point on the curve with x coordinate 0.
Same for x=1,2,3,4,... I think you can go on for a while before finding a solution that way.

I think there is no "obvious" solution, so one starts with a "random" value for x and incrementing this until x3+7 has an integer square root.

I saw some posts of people generating their own curves incorporating hex-art and/or hashes of "copyright notes" into the value + a counter.
It really should not be different, the only thing is everybody needs to use the same G otherwise the key pairs (public/private key) don't match.
2  Bitcoin / Development & Technical Discussion / Re: BTC violates GAAP, result a mess. on: June 10, 2013, 10:47:05 PM
Bitcoin solution: When M and P make the deal, M gives P a bitcoin address A. P pays the necessary bitcoins to this address A.
DONE. No further information is needed, as this bitcoin address is unique (only used once, exactly for the reason of P buying T).

Yes, fine.
Difficult and strange enough, but might work in this very simple example
THOUGH any legal caveats, exceptions, conditions, reservations cannot be articulated by the sender (P). 

Commercially we have quite a lot of additional legal and practical problems with the (useless*) workaround of changing addresses.

Example:
If customer P has to pay -due to different contracts- more than one bill for things like T1,T2..Tx he has to get from M more than one address A,B,C,D... to be used for his 10 or 20 payments. Might be a bit difficult for a normal customer to use for each invoice another address, esp. if he does not want to pay a special bill. If P on the other hand wants to pay the sum of all bills by ONE transfer problems arise on both sides.

Our merchant M might have hundreds or thousands different customers daily. So he has to produce and transmit hundreds, thousands special addresses to his customers.... Even with perfectly integrated QR-Codes this is not just fun.

In normal life we register the bank accounts of all our customers/merchants just once in our accounting system.
Bank accounts of merchants are printed on each letter/invoice.

With current BTC you have to change thousands of these entries ("addresses") daily.
Even for the same customer buying several things in different contracts.

Result is an error-prone MESS with daily thousand probabilities of errors.
Imagine that a customer/merchant might use in any case the wrong address.
How can that be repaired?

All this hide-and-seek behind different addresses only to avoid a simple field reason of payment !?

LvM, I have to agree with kjj, this is so completely wrong.

In your system, there is indeed one "destination address" for each merchant (in fact not completely true, most merchants do have more then one bank account),  and that is exactly why you NEED TO ADD a "reason of payment", otherwise the poor merchant can't know who paid for what. And exactly for each customer (hundreds or thousand each day as you say), there has to be some kind of additional data attached (in our country, big companies use the "structured message", but it could also be for instance the invoice number), which is not choosen by the customer, but by the merchants (otherwise the merchant again can't automate the receiving payments as he has no clue how a customer will indicate/format his "reason of payment").
So where is the difference between that "structured message" and a bitcoin address associated with one purchase/invoice/whatever ? The customer needs to enter additional information (the reason of payment or the bitcoin address) in both scenario's.

You also say that whole thing with different bitcoin addresses is not hiding anything. So please, can you indicate how many bitcoins I have ? Or how many MTGox has ? I don't think so.

3  Bitcoin / Development & Technical Discussion / Re: BTC violates GAAP, result a mess. on: June 09, 2013, 10:34:01 PM

Thats the main problem.
Your "addresses" in my view are accounts with just one turnover only.
The question is: why only one?
To hide transfers and balances this way cannot be very successful, since all public.

But in this case an (encrypted) field "reason of tx" is definitely necessary for commercial usage.
A merchant and his computers not able to know WHO payed him for WHAT cannot use BTC.

Again you stick to the classic way of bank accounts, and only accepting this strict convention.

Let me try to rephrase:

The "problem" we face is: person P buys a thing "T" from merchant M, and P initiates the payment to M.
Now M needs to know that P paid for T when the payment arrives.

Traditional solution: M has a known bank account B, P can transfer the money to this account B. But because everybody else buying from M pays to this same account, M needs additional data. As the bank account of P is not known to M, something like a "reason of tx" field is necessary to relay the information "I'm P buying T".

Bitcoin solution: When M and P make the deal, M gives P a bitcoin address A. P pays the necessary bitcoins to this address A.
DONE. No further information is needed, as this bitcoin address is unique (only used once, exactly for the reason of P buying T).
An elegant solution that covers your problem of "merchant needs to be able to know WHO payed for WHAT", and at the same time keeping some privacy (nobody can link address A to M, except P).

4  Bitcoin / Development & Technical Discussion / Re: BTC violates GAAP, result a mess. on: June 01, 2013, 10:58:34 PM
At first glance you cannot really believe it, BUT:
BTC indeed tries to simulate CASH for CASHLESS transactions.
Result is a mess at the lowest level.

Bitcoiners relentlessly struggle to simulate CASH of pure and genuine CASHLESS transactions, not hesitating a second to ask themselves, why this not at all understandable or even realizable intent should make ANY sense at all.

...

Instead of adding/substracting transferred amounts quite simply to/from the balance of the accounts involved...
they insinuate indeed, that they cannot but "destroy" all the money in the paying account and indeed create "new" BTC for payers and receivers assigning the "change" even to new so called "outputs". Armory does its best and provides the option to assign these "changings" to the "first input" address (whatever this exactly might be).

Obviously this "cash/change" idea also has nothing todo with technicalities like hashes, signatures, encryption, P2P db/network....
There is just NO explanation, why these confusing, time and space consuming pseudo-cash simulations exist at all.

Going to try to explain you once more with several SIMPLE ARGUMENTS why bitcoin has some of these properties you cannot seem or willing to understand.

As I already pointed out to you in another thread, the main idea behind bitcoin is that is it decentralized (= no central authority decides what is correct) and there is no trust between the nodes (a node not sticking to the rules cannot bring the system down). And this in comparison to the normal centralized banking system.

You don't seem to have a problem with what you call the technicalities of hashes, signatures and the block chain: this is indeed the first part of the bitcoin solution to the decentralized/no trust problem. It solves the problems related to deciding what is correct (= blockchain), and the prove you actually hold some coins (the signatures & hashes).

So now we come to the part where you don't understand why:
  • transactions are made up the way they are ("destroying" coins, "create" new coins and the "change" thingy);
  • there is no simple balance with adding/subtracting;
  • there is no "reason of payment" or "comment" field with each transaction;
  • bitcoin "struggles to simulate cash".

Let me start with the last point: bitcoin does not struggle to simulate cash, but it is rather the opposite: because of the solution Satoshi developed to the second part of the problems related to the decentralized/no trust problem (see below), bitcoins behave more or less like cash we know today. I think Satoshi made only the analogy to cash to help to understand this totally new form of "money".

So now the "other" problems that need to be solved when doing something decentralized with no trust.

First of all, all transactions are publicly know to everybody.
In analogy to your bank account: LvM, do you want everybody in the world to know the exact balance of your bank account, and each and every detail of every transaction you do ?
I don't think so. So that is why there is no "reason of payment" field, and there are no "accounts". Instead, there are bitcoin "addresses" that hold an amount of bitcoins.

Secondly, concurrent transactions can occur.
This is why in bitcoin there isn't a "simple" balance.
A simple example used in many programming tutorials on concurrency involves keeping track of a balance. And these examples show it is very easy to get improper balances when doing concurrent updates. In fact, you need to "lock" the balance before you start the transaction: after you get a lock on the balance, you can read it, update it and release the lock again.
Translated to bitcoin and the block chain: something is considered "correct" and "safe" when at least X blocks (X about 6) have passed since including the transaction into a block, what would mean you can only do 1 transaction every hour (on average 10 minutes between blocks). Balances are clearly not suitable.
Instead, bitcoin uses another kind of transactions: Starting point: X coins are transferred to an address A. When you want to transfer Y (Y<=X) coins from A to B, there is a transaction:
  • that moves all X coins (because a partial move would mean you introduce balances which are not practical, see above)
  • that sends Y coins to address B
  • if Y<X, the rest (the so-called "change") is sent to another address owned by A. It can be the same as the original address, but because everything is publicly available, it is normally a new or another address owned by A, so that it is not immediately clear to everybody what is change and what is the actual payment.
This transaction scheme allows for much more concurrency (somebody can own several bitcoin addresses and/or a bitcoin address can have multiple unspent "coins"), and allows easy verification of "double spending attempts" (an output is either used/spent or unused/available).

Because of this implementation, there is some analogy with "cash": If you need to pay 30 euro and you have a 50 euro bill, you spent the 50 euro bill and get a 20 euro bill as "change".

5  Bitcoin / Development & Technical Discussion / Re: Exact binary map of database blockchain?! on: May 12, 2013, 09:28:33 PM
@LvM: Like others have said before in this thread, you fail to see what Bitcoin really is, because you keep thinking in your own environment of bank accounts.
What Bitcoin tries to resolve is something completely different !

Let me try to explain the basics:

Centralized versus decentralized:

If a person A has a bank account with bank B and wants to send some money to person C that has a account at bank D, then this is what happens in your world LvM:
person A gives bank B (and only bank B) the authority to "send" the money to bank D. This involves central authorities (bank B and D) that have to be trusted: bank D trusts bank B (that the transaction is legit, that they are not double spending money or creating money out of thin air), and person C trusts bank D that he can get cash from his account that was credited.

I suppose you can understand the above (and probably better then I do).

Now LvM, ask you the following question: what happens if there are in the above scenario NO BANKS involved AND A and C don't trust each other (as they are strangers) ?
To put it in other words: person A wants to send some money to person C. (And afterwards, person C should be able to spend this money to another person E)

This is exactly the problem that bitcoin solves !

We have two problems:
 1. C will only accept the money if A can prove he "owns" the coins: that is why the transaction is signed cryptographically by A to prove he owned the coins. And with the transaction, all coins are transferred to an address "owned" by C (that is, only C can sign the spending, as he is the only one that knows how to), and "the change" to another (or the same) address "owned" by A.
Due to the crypto-magic, C does not have to trust A: he can easily verify (and everyone else looking at the transaction) that the signature is correct, and the signature is nearly impossible to compute by anyone else then A.

 2. A malicious user A could try to send his coins not only to person C, but at the same time send them to X (here is your impossible double-spending). Both C and X can verify the signature, which will be correct. But which of those transactions is the right one ? The solution that bitcoin offers here is the "proof-of-work" blockchain: the transaction that is recorded in the "best" blockchain will be recognized by everyone as the correct one. Nobody needs to trust anyone, no bank needs to authorize something. NICE, ISN'T IT ! The company you work for is not necessary anymore Smiley

So here you have it:
I want to spend Y coins I received (from mining or from others) to person Z: I make a transaction and send it to the network. After a while, it will be included in a block, and after some more time, it will be "buried" deep enough in a chain of blocks so that it becomes nearly impossible to change it: now everyone in the network will happily accept that person Z owns Y coins.
6  Bitcoin / Hardware wallets / Re: [BOUNTY] 1BTC for hardware wallet name on: November 13, 2012, 10:30:25 PM
bStick    (b from bitcoin, Stick from USB stick; could also be Bitcoin Secure Transaction Initiator and Coin Keeper, or something similar)

UBiStick  (both .com and .org available)



7  Bitcoin / Development & Technical Discussion / Re: Questions about Satoshi client on: October 19, 2012, 08:26:39 PM

You missunderstood my question. By default client I mean one with GUI but without any additional settings. What I want to know is
what's the difference running GUI client without and one with server=1, in terms of usefulness for other nodes. In other words, do I
help network more if I run client as server, but I don't solo mine with it, or via some other miner software.

Also, what's the difference when running client with just server=1 and with all this commands:

server=1
rpcuser=username
rpcpassword=password
rpcallowip=127.0.0.1

?
As others indicated already above: if you add the server=1 setting, you enable the JSON-RPC interface on the client. This means that you can not only interactively (as a human user) use the client via the GUI, but that you can write some program that can communicate with the bitcoin client using this RPC interface (basically send a command to do something and/or to receive a response).
As this is potentially dangerous (you can send bitcoins with it), you can - and should - restrict access by using the rpcuser, rpcpassword and rpcallowip settings.

In terms of usefullness to other bitcoin nodes: there is no benefit at all, as other nodes only use the standard bitcoin protocol to send/receive messages from each other.

So again, don't enable the server=1 if you don't need programmatic access to your bitcoin client.
 
8  Bitcoin / Development & Technical Discussion / Re: Refreshed the scalability wiki page on: October 17, 2012, 08:37:37 PM

"As of October 2012 (block 203258) there have been 7,979,231 transactions, however the size of the unspent output set is less than 100MiB"

You need to back this up, because from what I recall estimates were between 70-80% of the current block chain's size, which, even today, is definitely not 100MB.

You probably recall the correct percentages (70-80%) but that's the percentage of spent outputs, which could be forgotten.

I can confirm the following around block 202287 (using my BiRD client which only keeps track of unspent transactions):
  • 2443854 unspent transaction outputs, which is about 30% of all transactions (see 7.9M txs at block 203258)
  • the MySQL database containing all the necessary data to be able to spent those outputs, i.e. creating a valid (unsigned) tx, is about 316Mb in size when converted to an uncompressed CSV dump (simple text file)
  • compressing this CSV file yields only 110Mb of data.

You can download the client and some CSV's here.
9  Bitcoin / Development & Technical Discussion / Re: About proposed double-spend alerts in "Two Bitcoins at the Price of One" on: October 16, 2012, 09:48:06 PM
Sergio:

Is a new type of message necessary?

How about just making the transaction relay rules:

1) If the transaction has inputs that conflict with one already in the best blockchain, drop it.
2) If the transaction has inputs that conflict with another transaction in the memory pool, and it is the first such conflicting transaction, check the new transaction's signatures and if they're OK mark the memory pool transaction as "saw a double spend". Then relay the conflicting transaction (but don't otherwise remember it).

Rule (1) is to prevent an attacker from taking a bunch of her old, already-in-the-blockchain outputs and trying to generate a "double spend alert storm" by sending bogus double-spend attempts for them.

Rule (2) is to limit the amount of network traffic / signature checks an attacker can create to be twice what they can generate today (attackers can, and do, try to flood the network with transactions, but transaction fees and the free transaction relay policy keeps them in check).

The GUI/RPC should definitely show attempted-double-spend memory pool (0-conf) transactions as "BEWARE".

I think those rules will flood the network with the double-spend attempt, alerting merchants/users that something odd is happening. Without making it possible for an attacker to get the network flooded with gazillions of double-spend alert messages.



+1 !!

For my BiRD client, I've tried analyzing different ways to detect double spending in the following scenario:  "bad" customer at brick-and-mortar store uses a POS to pay for goods. POS communicates with BiRD (to get unspent txs, make & sign a tx), BiRD talks to 1 or more normal full bitcoin nodes to relay the new tx. "bad" customer sends at the same time (using his smartphone or whatever, connected to other nodes) the same coins to another address he owns. Store accepts 0 confirmations.

With the current implementation of dropping double-spend txs, and with only 1 connection to the Bitcoin network, the double-spend attempt is NEVER seen by my BiRD client, which is bad. So it would require something along the lines: send tx out on 1 node, listen on other nodes if they all signal this same tx (or instead the conflicting one).

Then I read this paper too on the "timing attack": Double-Spending Attacks on Fast Payments in Bitcoin, which further seems to complicate things (you'll need to connect to many nodes to get some chance of seeing conflicting txs).

BUT if Gavin's rule 2 from above is slightly modified like this:

2a) If the transaction has inputs that conflict with another transaction in the memory pool, and it is the first such conflicting transaction, check the new transaction's signatures and if they're OK mark the memory pool transaction as "saw a double spend". Relay the conflicting transaction as usual and remember it as long as the memory pool transaction.
2b) If the transaction has inputs that conflict with another transaction in the memory pool, and it is NOT the first such conflicting transaction, drop it. (This can be easily checked as the first conflicting tx is remembered)

THEN the "isolation" of a victim node (as shown in the paper) is no longer possible, even when it is listening to only 1 (trusted) node.

So at least the timing attack is no longer useful: a merchant can wait for example 10 seconds before accepting the tx. If in that time no other conflicting tx is seen, most nodes will have merchant's tx.

10  Bitcoin / Bitcoin Technical Support / Re: Hacked and can not recover on: September 24, 2012, 08:46:37 PM

Quote
If you had to tell two different people to send coins to you, you would not want to give them both the same address.

All they would see would be each other's address and that they had more or less paid the same guy at the same time. They would have to verify it with me, what was going on, unless the guys knew each other's addresses and could connect the address personally to the "other" guy.

Consider this for a moment: the blockchain is publicly available to everyone, so every transaction done is publicly visible (that is how it can work decentralized).
So if you decide to use only one bitcoin address for all your transactions, once somebody knows your address (like the people that are paying you some coins), that somebody can see all your transactions. It's like making public your whole bank account !

For that reason, you should give different people different bitcoin addresses, unless you want your private transactions known to the whole world.

Of course, you are free to reuse any "old" address. The client keeps track of all your addresses (that's the wallet.dat file). Just beware of the consequences.

Thilo
11  Bitcoin / Wallet software / Re: [ANNOUNCE]The BiRD on: September 12, 2012, 08:29:41 PM
So is this pitched towards existing developers of bitcoin apps/sites? What's your personal goal for the service?

I started developing this client about a year ago when the official client was version 0.3.24 something.
The reason being simple: after a few tries, I couldn't get to compile it on Windows, and I need(ed) some extra features which weren't available at that time:
  • easy access to any balance, not just those bitcoin addresses of the client wallet;
  • "raw" transaction interface.

Why do I need those features ?
Well, I'm working on a smart card that is able to sign bitcoin transactions with a setup similar to this: smartcard <-> GUI client <-> BiRD <-> Bitcoin Network
So that's my personal goal. In fact, the project is nearly ready for its first release (but I don't like vapourware, so I did not announce anything yet).
In short, the GUI client does the following:
  • talks to the smartcard to get its bitcoin addresses
  • asks via BiRD the open transactions
  • shows these to the user in a friendly manner
  • lets the user build a new transaction
  • asks the smart card to sign it
  • broadcasts via BiRD the transaction into the Bitcoin network

But I think many kind of applications (websites, even smartphone apps) can benefit from BiRD (being a much easier interface to the block chain), so I decided to make it open-source and available to everyone (it's EUPL).
12  Bitcoin / Wallet software / Re: [ANNOUNCE]The BiRD on: August 26, 2012, 07:13:27 AM
so it is a rpc client? or does it use p2p commands?
It uses the bitcoin p2p protocol: setting up a connection using TCP 8333, sending version/verack messages and getting data using getblocks and so on.
(just like an original Satoshi client)

if it ONLY stores the unspent ouputs, how does it react to chain reorganisations?
The standard data flow (no chain reorganisation) is as follows:
  • New blocks are downloaded first (and pre-processed = extracting info from txs) into "Chain___" tables (block and transaction data) and there is an attempt to determine their block height. This is indicated on screen by the "Count:  xxx / yyy blocks" which means: received xxx blocks from yyy in total.
  • Any block more then 10 blocks deep in the chain gets pruned: tx outputs of each transaction (the new unspent outputs) are added to the "TxOutAvailable" table, tx inputs of each transaction cause their corresponding output deleted from the "TxOutAvailable". If that succeeds, the block is deleted from the chain list (the point of no return so to say)
    Status is indicated by "Pruned up to block: zzz", which will be always at least 10 less then "xxx"

If a chain reorganisation happens, the received block does not append to the end of the block chain but some blocks (mostly 1 or 2) deeper down the chain.
As BiRD maintains a chain list (and full block data) of the latest 10 blocks as explained above, it can remove the obsolete (orphaned) blocks and accept the new block instead.
Only if a chain reorganisation should occur more then 10 blocks deep, BiRD will not be able to cope that, but then there is probably something bigger going on (as in attack of the block chain).
13  Bitcoin / Wallet software / [ANNOUNCE]The BiRD on: August 25, 2012, 10:05:57 PM
Announcing The BiRD, short for "Bitcoin Relational Database".

It is an alternative "medium-weight" Bitcoin client for Windows with the following main features:
  • Talks the native bitcoin protocol: connects to the normal Bitcoin network;
  • Maintains a pruned version of the blockchain: Mbytes instead of Gbytes of data because only "unspent" transactions are kept;
  • Stores data into a relational database (MySQL): abstraction of the blockchain into easy SQL queries to retrieve balances and transaction details;
  • Medium weight: storing ALL unspent transactions (in comparison to a 'light' node which would only store transactions of a specific wallet);
  • Open-source: C++ source files can be found at github and can be compiled using the free MS Visual Studio C++ Express.

Goal:
To provide an alternative, medium-weight client to developers of new Bitcoin applications with a simple interface based on a MySQL database.
Nevertheless, up-to-date data including unconfirmed transactions are available (to counteract any double spend attempts).

History:
First release v0.1.0 alfa

Current weak(er) points:
  • Connects to only 1 full Bitcoin client, so you have to trust that client;

More information can be found at the website UBiCard.org, including download of the compiled version and snapshots of the database at different block heights.
It will be part of a larger project including a smart card (for storing the private keys and sign transactions) and a GUI client managing the wallets, cards and payments.

Any feedback/questions is much appreciated.

Thilo von Braun
14  Bitcoin / Development & Technical Discussion / Re: Proposal: A Second Chain for Scalability on: May 25, 2012, 07:38:14 PM
Here is what I propose:

  • In this manner, over time old transaction blocks can be forgotten since the most recent balance block plus the most recent transaction blocks are all that are needed to verify transactions. To keep the integrity of the network, of course, more history should be saved, but we probablly don't need more than a few thousand balance blocks while still being very secure.

Do you think this scheme could work? I'm not even remotely an expert on this stuff, so forgive any glaring errors. Thanks!


If you want to be able to verify transactions from "most recent balance block + transactions since this balance block", this "balance block" does not only need to record the balance of each bitcoin address, but in fact (the full details of) each "non-spent" transaction.
Some data around block height 181185: there are 659574 bitcoin addresses with a non-zero balance, and 1591739 "non-spent" transactions. This is at least 391 Mb of data you need to include in the balance block (at least 258 bytes per transaction), if my math is correct. Or at least a 1 hour download on a decent DSL line (not taking into account other nodes will want to get the data too).

So this can reduce storage space requirements (Mbytes instead of GBytes) and transaction lookup times, but network load will be higher (peers need also to relay the second chain).
At the current transaction volume (1100 transactions/h = 400 kb/h or 9.6Mb a day), it is definitely not a good solution: 1 balance block a day = 400 Mb a day (390Mb for that 1 block + 9.6Mb of new transactions), or an increase of 40 times the network load !
15  Bitcoin / Bitcoin Discussion / Re: What can really be done about server hacking on: May 14, 2012, 09:27:13 PM
I also don't see the point why on earth people are putting a wallet file or running a bitcoind on a hosted server.  Huh

Instead, put the bitcoind with its wallet on a simple PC/server behind a firewall (at home/office, right where you can keep an eye on it) only letting traffic in from the server IP on a particular (non-standard) port where bitcoind listens.
Let the hosted server send its RPC's to the "off-line" bitcoind.
No easy wallet.dat to be copied if the hosted server gets cracked (that is what supposedly happened).

Instead the cracker needs to gather all the info how to contact that offline bitcoind, compile a client, upload it to the server, and only after that the cracker could send some bogus RPC's to "steal" some bitcoins.
Probably some simple countermeasures can be taken against that too: some special sequence for the RPC's or whatever (if you need to send X.Y bitcoins, sequence could be: ask block header X, send X.Y bitcoins, ask block header Y), so that an simple attempt to spend some bitcoins from the main wallet address can be easily detected (the normal server code would never make a false sequence) and that cuts off the offline bitcoind from the Internet until the problem has been investigated (fail2ban style for example).

If you put together a site in just a few days, of course if can't be much more then some copy & paste of standard blocks...
16  Bitcoin / Development & Technical Discussion / Re: Is blockexplorer's total bitcoins in existance accurate? on: September 26, 2011, 07:35:37 PM
According to my database (it only stores bitcoins in txouts not spent, that takes only 1.86 seconds to get the result), I get 727699999899998 satoshi's available after 145542 blocks, which means there are 100.00100002 "lost".
2x 50 coins are "lost" due to duplicate transactions in generation, which my database didn't like at first (because it has a unique tx hash index).
Didn't know up to know if the others where rounding errors on my side, but it seems the 2 satoshi's are indeed from block 124724.
So that's only 0.001 bitcoin not yet accounted for... Huh
17  Bitcoin / Bitcoin Discussion / Re: Bitcoins biggest flaw on: September 04, 2011, 01:16:46 PM

I am more concerned with the amount of inter-nodes traffic.

To put it simply - when the number of users is big the block size itself will be too big to be useful.

A block needs to hold 10 minutes of _all_ transactions or the system starts lagging and transaction times will soar to infinity.

Let's assume each user does at least 1 transaction per day. There are 144 blocks per day.
A million users * let's say 100 bytes per transaction / 144 = almost 1 MB per each block = 6 Mb / hour constant incoming traffic to every client.

I love the cryptocurrency idea, but I don't see any ways of implementing it on the scale of PayPal or VISA.


I take your example again of 1 million transactions a day. It doesn't matter how many users send how many, just the total number of transactions per day counts towards the traffic a full client needs to receive to keep up with the block chain.
Let's take 300 bytes per transaction, then we get 300 Mbytes/day of data.

That is 12.5 Mb/hour or 3.5 kb/sec (or about 28kbps), that is about 1/3 of a high quality VOIP connection. Don't see any problems there related to bandwidth !
When we extrapolate on a yearly basis, then we get about 100 Gb/year. Doesn't look much either to store that.

If you add the retransmissions to other nodes: let's assume you're connected to 20 other nodes. Then about 50% of the nodes will already have the data you just received, so you need to transmit about 10x. So now you'll need about 300 kbps. This won't kill the Internet  Tongue

So in this regard, the bitcoin protocol has no real "flaw".
18  Bitcoin / Bitcoin Discussion / Re: Patent Issues? on: September 03, 2011, 11:46:29 AM
And what if part of the Bitcoin system is implemented on some smartcard or similar device ?
I think there are several patents out there describing payment/transaction signing/crypto systems using a smartcard.

Who would need to take a license : the manufacturer, the programmer and/or the issuer of the cards ?
Or can they be ignored ?
19  Other / Beginners & Help / Re: My best attempt to secure my wallet: FAIL! Help Wanted on: August 25, 2011, 09:14:34 PM
There is indeed a simple explanation.
Let me try to explain in as simple terms as possible (without going in a lot of technical details).

First of all there are two separate "files" on a bitcoin system: you've got the block-chain and you have a wallet.

The "block-chain" records all transactions of everybody and it is updated every time your bitcoin client receives a new block.

The "wallet" is your personal file and contains two important things: the private keys of all your bitcoin addresses (so you can prove to the network you "own" that bitcoin address and nobody else should be able to do transaction on your behalf) and a list of transactions related to those bitcoin addresses.

Your "wallet" file is checked each time a new block arrives: if the new block contains transactions to any of your bitcoin addresses, those transactions get "copied" to your wallet. This is to prevent that each time you want to use one of your bitcoin addresses, the whole block-chain must be scanned to get your balance.

Now, the "normal way of using bitcoin":
1. You generate an address (it gets inserted in your wallet)
2. You sent or receive some coins to that address
3. As soon as those transactions are received by your client, you'll see the balance change (with 0 confirmations)
4. As new blocks arrive, you get more and more confirmations.

You don't have to be on-line during phase 2, because when you get your client on-line again, it'll continue downloading the block-chain/transactions where it last left, and "nothing will get lost".

Now in your case, you don't follow these scheme at all: on that "different computer" you have a client running that doesn't know (yet) your new address, so in phase 3 when the client receives those transactions/blocks, it just records them in the block-chain and doesn't update any wallet (not the current wallet as it doesn't contain your bitcoin address, nor your wallet on the pen drive). Then you copy your "secure" wallet to that client. Nothing will happen, as the block-chain end is already way passed the block that contains the transactions of your "secure" bitcoin address.

In fact, now the optimization of not scanning the entire block-chain each time you want to see the balance of your bitcoin addresses, is playing against you.
But don't despair, a few versions ago, a new command was introduced just for this case: the "-rescan" option when you start your bitcoin client. It will rescan the whole block-chain (and it will now find the "lost" transactions of your "secure" wallet)

Hey guys, thanks a lot for the quick response. Is that something I should type somewhere?? Sorry for the non-existent tech skills (Treat me as I'm 2)   Embarrassed
(I will look into moving to linux Kimasa, thanks for the heads up)

If you don't know how to open a command prompt in Windows 7, you can use the following to get the rescan option to work:
Go into the start menu and find the Bitcoin program (Start -> All Programs -> Bitcoin -> Bitcoin).
Instead of clicking it normally, use the right mouse button and from the pop-up menu, select "Properties".
You should see in "Target" something like "C:\Program Files\Bitcoin\Bitcoin.exe". Inside the quotes, add the ' -rescan' text (without the single quotes, and pay attention to the space, so that it reads at the end:  bitcoin.exe -rescan"

If that works fine, remove the " -rescan" again, otherwise each time you'll start bitcoin, it'll do a rescan.

Hope this helps.
20  Bitcoin / Development & Technical Discussion / Re: Any way to know about a blockchain reorganization? on: July 10, 2011, 08:37:23 PM
If the block chain gets changed, is there any way to notify about it?  Reason being, I have a database being written to based off of every new block that arrives, so if one of the older blocks changes, I'd like to know about it.

The "older blocks" won't actually change. When a block chain forks, and you happen to be on the false part of it when one of the forks becomes the "longest", all your blocks from the fork up are simply no longer valid (and all transactions contained in it).

You don't get a direct notification of it, but you can "easily" know when there is/was a fork, because the new block you receive will NOT reference the latest block you have in your database.
In fact, there are 2 possibilities (current block height in your database is N):
  • The new block has a previous hash that you already have in your database (most probably references block N-1, the start of a fork). You can either choose to ignore this new block (as you already have a block chain that is longer or same length), OR you can drop all blocks up to the previous hash of the new block and append this new block as usual.
  • The new block has a previous hash "PH" that doesn't correspond to any of your current block hashes. This means there is/was a fork and your part of the bitcoin network did not get one or more blocks of the other branch. You will have to ask with a "getblock" message the block X with this hash "PH" and check if the previous hash in this block X is a hash you know of. If so, you can reconstruct this branch (and like in the first possibility decide what branch to keep), if not you'll have to do a "getblock" again (and loop until you get a known hash).
Pages: [1] 2 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!