Topic: Whitelist Requests (Want out of here?) - page 144. (Read 474339 times)

I request to be whitelisted because I need to participate in the bitmarket.eu-Forum.
I got some btc`s "frozen" there and it is horrible not to be able to participate in the
ongoing discussion.
Thank you very much!

Hey, I'd like to post on the Marketplace>Goods>Digital Goods forum as our offers could be fairly interesting for the btc community

Thanks!

hi,

I would like to request to be whitelisted to participate in Auction section for asset liquidation, which will end by January 28th. Please consider my request. Thanks

Very interesting. Certainly anything which improves the performance of working with the blockchain would be greatly appreciated. Will this also help with the time to start the app (when the chain is already caught up), or is that entirely dominated by IO?

Hello, I want to include some input on coinabul.com and on a couple other topics, but can't post till I meet the requirements. I'd really appreciate it if I was whitelisted, thank you.

Hi

The annoying huge real time to build up the blkindex.dat with the bitcoin-client is the trigger why I finally wrote this posting.
Sadly nowhere is explained neither which exact structure blkindex.dat has, nor
why we need this Berkley-DB-B-tree structure at all and it is extremly slow in
rebuild/updating in our case of bitcoin client.
Indeed I needed more than 23 h to build it from scratch with my 2 GHz Athlon-64 and 4 GB Ram. :-( and almost always the real time is spent by wait-for IO, not
CPU or network-band with limited if you want to catch up to the current blockchain.
Looking at the new bitcoin-client 0.7.99 test-release it looks still similar
slow, see benchmarks at [https://bitcointalk.org/index.php?topic=129861.0].
Thus I totaly agree in "We need to stabilize 0.8 as quickly as is reasonably possible, because people are beginning to avoid 0.7.x due to slowness, choosing instead less secure but faster bitcoin clients." stated by jgarzik in this thread.

I wonder why we need all this overhead-full and version-depending DB-stuff for
using/manipulating the blockchain in the bitcoin client. :-/

Here is an alternative for "blkindex.dat":

Hold the blockchain-indexing data always in memory and organize, it as follows:
Let there be TA-many transactions and DEP-many deposits (response-scripts/out-channels) in all the (valid) blocks in the blockchain.

On 2012-12-27 11:45 UTC we had #blocks= 213849, #TA =  10388275, #DEP = 24173524

The needed data structure consists of 2 tables and 1 heap:

1) A hashtable: we have TA many transactions and this number is steadily growing.
It is not decisive but I choose a hashtable which can store up to 2^26 many
 entries (so current fill-factor is < 1/6). Each transaction gets a 4 byte index, e.g.
made up of the lowest 4 bytes of a transaction-hash (or made by xoring the 32 bytes into 4
bytes) anded with 2^26-1 , ==> this is a 2^28 byte sized table, which each entry is either 0 or
indexs a further table, called transaction table for simplicity.

2) The transaction table has #TA*(32+2+8) bytes = #TA*42 bytes.
   Each entry of this transaction table holds ITS 256 bit doubled SHA-hashed hash = 32 bytes (back-check to the hashtable for index-collision-detection), a 2 byte counter (could be also 4 byte) for number of deposits and an 8-byte pointer into a heap for a specific transaction of a block of the blockchain.

3) the heap of deposit addresses and deposit values has size #DEP*(2*8+8) bytes
   Here the explicit value in Satoshis, the address of the script, and the
   address of the redeemed script is stored (null address if the deposit is
  still availible).
  The value of the deposits are pure luxury and could be saved. This value could
  also be goten from the address of the script decreased by 8. But I liked to
  store this value explicitly (in 8 bytes) and not looked it up each time in the
  blockchain.

The size of these 3 structures sum up to about 1285 Mbytes compared to 1481 Mbytes of the current blkindex.dat. The heap and the transaction table grows simply
by appending new data if new blocks are mined and published.
Searching for a transaction given by its 256-bit hashindex happens in constant time (depends only on the fill-factor of the hashtable) -- in contrast any B-tree needs log_2(#TA). Adding a new transaction with its deposits is of course proportional to the number of deposits involved.

Thus the real time needed to access a deposit is constant. There are the rare
events when we want to delete a orphan block and thus removing transactions with their deposits from our data structure. In this case, the needed real time is
at most proportional to the age of the orphan block respectively number of blocks in the part of the forked chain measured in number of deposits containing in the end part of the forked chain.
The average real-time behavior should be at least as fast as the old
"blkindex.dat"-logic, but probably much faster because we need no log_2-searching factor from the B-trees involved.

I implemented this logic/data structure already as part of a blockchain parser
and a total build up of this new "block-index structure" needed 242 sec real
time and 71 sec CPU-time - most time was spend in reading the blockchain from
disc. BTW: I did not optimize the source-code, already the 2nd program version
needs only these 4 minutes. I recall: Compared to more than 23 hours real time of the
bitcoin-client 0.7.1 needed to rebuild the blkindex.dat via "-loadblock" options. :-(

So the only draw back I currently see is a need of 1.28 GB Ram compared to at most 1/5-th (or less?) Ram in the bitcoin-client + 1.5 GB of blkindex.dat disc-space.
Omitting the Satoshi value of each deposit in the data structure and using only
a 2^25 sized hashtable (currently means a factor of 3.23 of total to used entries)
would result in 0.96 (0.13+0.44+0.39) GB Ram. Of course this data structure could be stored also on disk to avoid rebuilding each time the client starts.

The win is a real-time factor decrease of 350 -- and in absolute units from
many, many hours to a few minutes when building up the index data from scratch
in a bitcoin-client or whatever.  :-)

I like to hear your thoughts/critics.

BTW: If this is not too much nonsense perhaps a member could make a pointer to this posting in the thread/topic "Experimental pre-0.8 builds for testing" in the "Development & Technical Discussion"-board which is forbidden for newbies like me.

Thanks,
smtp

Also saw a post on Reddit linking to the 10btc give-away and looking to post there.  I've got 5-10 posts over there, I've been reading about bitcoins for a month or so (purchased 14 btc at the first of the year from coinbase).  I've transferred my coins to a paperwallet which is probably above average.

I'll probably read some other posts here and stay logged in for a while anyway if the whitelist isn't granted (but this is #1 )

As you should!



(cue the low, evil sounding laugh)

lol, i feel coined!

I don't mind waiting another 3 hours.


I need to get another post in anyway so I'll talk about bitcoin for a bit to prove i'm not just here to coin people.


If you're a casual person in the US, you should be using Coinbase. Your funds are way more secure with them (potential 2 factor authentication, over 80% of funds stored offsite) than having them stole from your computer.

A real prolem with bitcoin is how totally unsecure holding coins on your hard drive is. Your computer could crash and the coins are easily stolen. Bad combination. Not to mention how absurdly slow it is downloading the blockchain. Forget it.

Blockchain.info is good if you want to play satoshi dice. But for some reason I just don't trust it. I've heard some bad rumors about people manipulating it. The software itself works great and is convenient but I don't trust their security. For a newb with under 50 BTC, blockchain.info is fine.

Hi,

I'm a long time reader of BitcoinTalk, and I recently saw the posting to win a 10BTC and felt it was a good enough reason go ahead and join the discussion community. I am a web designer/developer looking to learn more about the Bitcoin movement, and I already have my own wallet and a modest amount of Bitcoins!

Hi

I am an a Bitcoin researcher and fascinated by cryptocurrencies and their sociopolitical effects. I request whitelisting because I'm neither a "noob" nor a spammer.

I am especially interested in Bitcoin startups and decentralized virtual companies.

I think in particular there is a need for a centralized bitcoin dash-board, giving a market price weighted across all exchanges: raw cost in terms of mining and electricity versus capex.

Someone needs be tracking that arbitrage.

My 2c....

Hello, I would like to be able to contact flatfly to have a try at his little quiz ( https://bitcointalksearch.org/topic/m.1463107 , and in case I'm not allowed to link: Project Development > [BOUNTY 0.256 BTC] 2^256 Deep Space Vagabond ASCII Screensaver > #96). Either being able to post there or sending him a PM would do. Thanks!

great thank you

Hi, Would appreciate a leg up to full access. No trollster here, looking for some expert opinions on custom hardware, seem to have laid my hands on a big Virtex7 board, need opinions on potential performance etc.etc.etc.

Just did a trade with Beezm .Thanks!.

kinda forgot what I was going to say... I just noticed the dates on the earlyiest replies... You guys have been around since the beginning! Kudos for what I'm sure was  a great help to this community. Lots of sites (and people) are jumping on the bandwagon... which I guess is good for btc. As for me, I was at least exposed to it early but unfortunately did not seize the moment.  Nowadays I immerse myself into the world of bitcoin, picking up little things here and there that has to be usefull info to share with the community. Please take me off this so I may share with everyone who is enjoying our world. I promise to contribute, promote, protect and of coarse respect this site and all members. Thank you for your time.

Seems easier to make 5 posts than explain anything in here.

Whitelist request to reply to this post:

https://bitcointalksearch.org/topic/5-btc-competition-labview-app-to-get-address-from-private-key-137197

with a solution.  Long time lurker, never needed to post before.

Thanks for your consideration.

Matt

Ok, quite difficult to check what you say is true, but you can now answer to that thread. Btw, welcome!