Bitcoin Forum
May 11, 2024, 10:34:43 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 »
1  Economy / Exchanges / Re: BITCUREX.COM - new official thread on: October 17, 2016, 12:11:35 PM
It seems like most discussions about Bitcurex's disappearance is taking place in Polish on:

https://forum.bitcoin.pl/viewtopic.php?f=16&t=19856&p=272893&hilit=bitcurex#p272893

I'm trying to follow it using Google Translate...

From what I can tell they say it is can't be accepted by the police yet (the terms say something about 3 days downtime before responding to an issue).

The offices in Lodz are closed.

It is looking very bad.

2  Local / Anfänger und Hilfe / Bitcoin-tolerating German banks? on: June 29, 2015, 09:13:16 PM
Apologies for writing in English! I don't speak German, but my question is related to Germany...

My Swedish bank, SEB, has asked me to stop making transfers to Bitcoin exchanges, so I need to find an alternative bank that I can use for EUR transfers. Preferably one with an English language internet bank.

According to Kraken.com, Fidor bank and Deutche bank are OK regarding bitcoin. Does anyone disagree?

How is DKB? I understand that they have a DKB-Cash account that I may be able to open over the Internet.

Thanks, and again, apologies for writing in English.
3  Economy / Service Discussion / Re: Bitstamp Login Problems on: November 12, 2014, 10:26:57 PM
I'm having this problem too, since about an hour ago.

I'm a verified customer. Could it be a bug related to locking out unverified customers?

I hate getting nervous about glitches like this when there's a lot of money involved.
4  Economy / Exchanges / Re: MtGox withdrawal delays [Gathering] on: January 07, 2014, 03:06:26 PM
Another data point:

I made a 1k€ SEPA transfer from MtGox on November 26, and I received it on December 27.

5  Economy / Exchanges / Re: MtGox withdrawal delays [Gathering] on: December 03, 2013, 07:47:01 PM
I had a 1k€ SEPA transfer made from MtGox on November 5 arrived in my account on December 2.

Less than a month; better than expected!
6  Bitcoin / Wallet software / Re: libbitcoin on: June 03, 2013, 08:09:15 PM
I personally believe that disk space is not a big deal (current unmodified chain is 15 Gb). I'm more worried about fetch speed (not writes) and scalability.
I'm thinking about building a device for secure Bitcoin storage based on the Raspberry Pi. It doesn't have to be very fast, but if I want to support a full blockchain for a number of years into the future, the storage would get prohibitive (already is). That's why I'm interested in a pruned blockchain.

I'd much rather use (and possibly contribute to) an existing library than writing my own stuff.

SQL is too slow for blockchains.

Could you elaborate on that? What are the operations that require high speed of database access? I am considering using sqlite for a pruned blockchain, do you think that would not work?

Could I write my own implementation of blockchain which automatically pruned itself without rebuilding, and stored the database (blockchain, transactions, addresses maybe) in its own database? Would it create problems for the rest of libbitcoin?

Quote from: genjix link=topic=30646.msg2360452#msg2360452
Yeah you can do that if you rebuild the database.
That means creating a new database (see examples/initchain.cpp), then importing the old blocks into the new one.
Sounds expensive.

I wish there were a bit more comments in the code to explain the concepts, like slices, what the chain keeper, chain organizer do, etc.

Quote from: genjix link=topic=30646.msg2360452#msg2360452
There is a method to delete from the blockchain directly, but I haven't exposed that. It's used for blockchain reorgs. You can use that same code, but make sure you stop the blockchain object before modifying the database. You can then reopen it after:

Code:
leveldb_blockchain* chain = new leveldb_blockchain(pool);
chain->start(dbpath, blockchain_started);
// ... do stuff
// stop/join threadpools using the blockchain.
chain->stop();
delete chain;
// open database, delete whatever you want.
leveldb_blockchain* chain = new leveldb_blockchain(pool);
chain->start(dbpath, blockchain_started);
// continue from where you left off...

something like that.

see the method called "end_slice"

https://github.com/spesmilo/libbitcoin/blob/master/src/blockchain/leveldb/leveldb_chain_keeper.cpp

It's deleting a bunch of blocks from the end of the blockchain.
Thanks for the pointers.

Why does the database need to be deleted and then opened in order to delete data from it?

Quote from: genjix link=topic=30646.msg2360452#msg2360452

Also `bool leveldb_chain_keeper::clear_transaction_data(leveldb_transaction_batch& batch, const transaction_type& remove_tx)' (same file) might interest you too. It's deleting specific transactions from the database.

Where can I find a description of what's in the database? I'm used to SQL databases with tables, but I understand leveldb only stores key-value pairs? What objects are in the database? Is there for instance a way to find unspent transactions?
7  Bitcoin / Wallet software / Re: libbitcoin on: June 03, 2013, 03:10:19 PM
I'm thinking about making a Bitcoin client that deletes blocks from its blockchain database if they are say more than about 6 blocks deeper than the latest block AND all of its transactions have been spent. I figure this way I can still validate new blocks, ensure that transactions to my addresses are valid, and save lots of disk space.

Can I do this with libbitcoin, but without modifying its source? How hard would it be?

In your initial posts of this thread, you mention MySQL, but I see no trace of MySQL in the latest source I downloaded from Github, just leveldb and bdb. What's up with that?

You also mention the blockchain database as 'append only', does that apply that I can't delete from it?

Thanks for any tips!
8  Economy / Trading Discussion / Re: Bad News. A guy with 2FA in Mt has been stolen for $7000+ on: June 02, 2013, 05:11:23 PM
There is no unbreakable authentication method, but the problem with most methods is that they aren't fool-proof.

There are several ways to attack 2FA:

  • Break the algorithm. Google Authenticator uses SHA-HMAC, so that's not the case here.
  • The attacker discovered some exploit in Mt.Gox's server. Unless stories about hacked accounts start to pile up, that's also not the case.
  • The phone was compromised. If the phone has access to the Mt.Gox password (e.g., it's stored in a password manager), malware or somebody with physical access to the phone could obtain both the password and the secret key.
  • The device that was used to generate the secret key was compromised at the moment. Since you have to log into Mt.Gox to generate your secret key, it suffices to have a malware infection on that computer.

Actually I read about an interesting fifth way just the other day.

Because there's something like a 30 second window that the GA code is valid, someone stealing the code with something like a keylogger could re-use the code to do whatever he wants if he's fast enough after getting the code.
9  Bitcoin / Development & Technical Discussion / Can I find the block of a transaction without the entire blockchain? on: June 01, 2013, 09:54:17 PM
If I want to verify a transaction by checking the validity of an input transaction, is there a way of finding the block containing the transaction, without having indexed the entire blockchain?
10  Bitcoin / Wallet software / Re: libbitcoin on: June 01, 2013, 09:22:10 PM
When I run the fullnode example, I get the following error:

Quote
~/src/bitcoin/libbitcoin/examples$ ./fullnode
terminate called after throwing an instance of 'boost::interprocess::interprocess_exception'
  what():  No such file or directory
Aborted
Ok, after some stepping, I realized I needed to create a 'database' directory in the same directory as the 'fullnode' application for a leveldb database.

Can't say the error message was very illuminating.

I'll continue exploring.

I'm now getting errors like:

Quote
ERROR: Error storing memory pool transaction 5c4c562af2d4667db80f7832138acaf66e2cfa41bbbb3f2ee07b86f80069a98d: Object does not exist

Is this because the blockchain isn't populated?
11  Bitcoin / Wallet software / Re: libbitcoin on: June 01, 2013, 08:03:00 PM
Hello,

I downloaded and built libbitcoin from github. I'm on an Ubuntu 12.10 machine.

When I run the fullnode example, I get the following error:

Quote
~/src/bitcoin/libbitcoin/examples$ ./fullnode
terminate called after throwing an instance of 'boost::interprocess::interprocess_exception'
  what():  No such file or directory
Aborted

The backtrace doesn't say much:
Quote
(gdb) bt
#0  0xb7fdd424 in __kernel_vsyscall ()
#1  0xb6e9d1df in __GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#2  0xb6ea0825 in __GI_abort () at abort.c:91
#3  0xb70838ad in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/i386-linux-gnu/libstdc++.so.6
#4  0xb70814f3 in ?? () from /usr/lib/i386-linux-gnu/libstdc++.so.6
#5  0xb708152f in std::terminate() () from /usr/lib/i386-linux-gnu/libstdc++.so.6
#6  0xb70dd5ac in ?? () from /usr/lib/i386-linux-gnu/libstdc++.so.6
#7  0xb746ed4c in start_thread (arg=0xb48b5b40) at pthread_create.c:308
#8  0xb6f5ddde in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130

Is this a libboost issue? gcc version? Something else?

Thanks for any help!
12  Bitcoin / Project Development / Re: Ideas for a thin client for a hardware wallet on: May 31, 2013, 08:14:57 PM
>full node
>no blocks
pick one

Why?

Is it not possible to join the P2P network without having all blocks? Just to be able to listen to blocks and inject transactions without needing a separate server.

I'm just trying to understand this without having to code a test program.


Can you do it? Sure.  Can you do it securely?  Probably not.  The ugly part is it likely will work for some time until a dedicated attacker tries to exploit your paper thin security and then when it fails it (and given enough time it will), it will fail hard and cost either you or someone who relied on your a massive amount of funds.

Don't get me wrong. I'm interested in designing a secure solution, and that's why I'm bringing it up for discussion. I want to learn.

Without at least the blockheaders your node has no way of knowing what other nodes are telling you is truthful.
How do the blockheaders help?
 How long do you think it would take a single GPU computer to generate 6 (or 60) blocks of fake history at difficulty 1?  If all your node does is ask for 6 most recent blocks ... ok here are 6 blocks I made for you and see your massive payment of 500 BTC is there, so please send me the gold/wire transfer/computer hardware I asked for.  Only later do you find out that you were fed a false history.  Yes I have 500 BTC but in the "real" blockchain I sent them to myself not you.  A double spent that you could not only not prevent, you couldn't even see that it had occurred.

Thanks for the input, I get your point.

However, surely I could verify that a block was generated with a valid difficulty? If I have the latest generated block, and am given a subsequent block referencing the previous block, there must be a formula for verifying that the new block was calculated with a valid difficulty?

For an attacker to generate say six 'fake' blocks with a valid difficulty and the first one referring to the previous truly valid block must be reasonably difficult (similar to actually 'mining' those blocks)?

But wait you say I connect to 8 independent nodes?  Do you?  If there is enough incentive to steal don't you think a botnet for example could produce tens of thousands of "independent" nodes and poison the pool of potential nodes around you.  Now currently there is very limited value in an attacker doing that as each full node (in in the case of electrum the electrum server is doing the full node validation) implicitly does NOT TRUST anything any nodes tells it and validates every block, every transactions, every output back to the genesis block if necessary.  So a "poisened node" strategy has very little utility. 

But against a "naive node" well that is a different story.  Let the false history games begin.

Thanks for the input.



13  Bitcoin / Project Development / Re: Ideas for a thin client for a hardware wallet on: May 30, 2013, 10:09:04 PM
>full node
>no blocks
pick one

Why?

Is it not possible to join the P2P network without having all blocks? Just to be able to listen to blocks and inject transactions without needing a separate server.

I'm just trying to understand this without having to code a test program.
14  Bitcoin / Project Development / Re: Ideas for a thin client for a hardware wallet on: May 30, 2013, 09:51:37 PM
The things you described to be fetched from the network dictates the need of a server. An online entity that is providing you with specific information regarding specific addresses and block headers. Unless you are a full node (Mining or not), You are using a client server arch. Calling it not one does not magically make it so.

I was intending to pretend to be a full node on the P2P network, thereby not requiring a server.
15  Bitcoin / Project Development / Re: Ideas for a thin client for a hardware wallet on: May 30, 2013, 09:50:17 PM
see: multibit, bitcoinj, bitcoin for android

The Thin Client Security wiki page says that header-only clients "... downloads a complete copy of the headers for all blocks in the entire blockchain": Why is this neccessary?
16  Bitcoin / Project Development / Re: Ideas for a thin client for a hardware wallet on: May 30, 2013, 09:25:23 PM
Welcome to the scene.
Thank you.

You just described electrum client. Now go read about it and try it out.

My impression was that Electrum uses a server, whereas the system I described doesn't need one.

Electrum's Wiki page describes it as a "client-server protocol".
17  Bitcoin / Project Development / Ideas for a thin client for a hardware wallet on: May 30, 2013, 09:08:44 PM
I'm new to Bitcoin, and I'd like to bounce some ideas for a thin client for Bitcoin hardware wallets. I may have misunderstood some fundementals.

I'm considering hardware devices, which would hold addresses and private keys. They would be used to securely store the private keys, and have an Ethernet connection for communicating with the P2P bitcoin network.

The wallet should be able to display the balances of the addresses, and spend bitcoins for the addresses. It has no ambition to verify transactions from other nodes on the network.

I'm thinking the client won't need to store much blockchain information except unspent inputs for its' own addresses. It might track the last six verified blocks in the block-chain and assume that that means that there is no fork. If the keypairs are generated on the device, it will know that there are no transactions in the blockchain for the addresses before they were created.

It will listen for 'deposits' to its address, update the balance, and remember the unspent outputs in order to be able to refer to them in output transactions.

I'm thinking this will let me make a thin client without needing a separate server.

Did I miss something? Is it immoral ;-) to connect to the Bitcoin network without validating third party transactions? Any other think-o's?

Thanks!
18  Bitcoin / Hardware / Re: [Announcement] Block Erupter USB Ready to Hash Everywhere in the World on: May 30, 2013, 07:59:23 PM
Will it pay off?

Looking at the graphs at BitcoinDifficulty.com, it looks like difficulty has increased quite linearly by 8 000 000 in the past 3 months, that's about 1.3 million in each 2 week period.

At 336 MH/s, we would do about 406 TH (Tera-hashes) per 2 weeks.

Here's a table of how much we would make if we started today:

WeeksDifficultyBTC/2wCumulative BTC
212 153 411 0,195 0.195
414 820 077 0,160 0.354
616 153 410 0,146 0.501
817 486 743 0,135 0.636
...
4844 153 403 0,054 2.239
5045 486 736 0,052 2.291
5246 820 069 0,051 2.342

So, sure, after a year we'd have covered the cost, barely. If we'd start mining in a month rather than now, we'd just about covered the cost in one year. At that point we'd be making about 50 mBTC per two week, with the amout decreasing by about 3 mBTC per month.

In this model I have not subtracted the cost of electricity, which I believe for me would be about 1 mBTC per 2 weeks.

Might be a fun thing to give mining a try, but it doesn't look like a gold mine to me.

Apologies if this calculation has already been made, I didn't trawl the entire thread.
19  Bitcoin / Legal / Re: Fincen Requirements? on: May 30, 2013, 06:58:55 PM
Ok, you may be right regarding the FinCen rules.

However, I still maintain that there is no issuer according to the California rules you quoted.

I expect it is possible that you may have to register with FinCen, but not with the state of California as an MSB or money transmitter?
20  Bitcoin / Legal / Re: Fincen Requirements? on: May 30, 2013, 06:47:09 PM
Didn't FinCEN say that miners who sell their bitcoin need to be registered as MSB's?

edit:

Yes, here:
#3 If a miner exchanges their mined bitcoin for real money they MUST register with FinCEN.

https://bitcoinfoundation.org/blog/?p=152

According to the top reply in this thread on StackExchange, it's not so clear:

http://bitcoin.stackexchange.com/questions/8486/do-usa-based-miners-need-to-register-with-fincen
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!