Bitcoin Forum
June 18, 2024, 03:12:36 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 [142] 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 ... 269 »
2821  Local / Biete / Re: 1 BTC für den Namen für ein Eis Cafes on: March 09, 2013, 07:46:38 PM
YOLO - You only lick once!

Die Gletscherspalte
2822  Bitcoin / Bitcoin Discussion / Re: Newly Discovered Flaw, Could KILL Bitcoin! on: March 09, 2013, 02:17:53 PM
Also if you are worried about performance problems, I would bet that by then the ALU in your watch can do native 1024-bit int arithmetic operations.
How much are you willing to bet and whom are you allowing to escrow this? I'd go with up to 10 BTC against this statement, if it is formulated properly. Your move!
2823  Bitcoin / Project Development / Re: [BETA]Bitfinex - Meta-Exchange and margin trading on: March 09, 2013, 01:37:37 PM
Well, after 8 days of lending (I added another 35 BTC to the mix) I can only say that I'm less than thrilled about the amount one actually gets out of it...

After one day of nearly constantly lending out nearly all funds (resulting in a day payment of 0.0182 BTC or ~12.08% APR on 55 BTC) I earned still just as much (0.01813450 BTC) as with 25 shares of https://bitfunder.com/asset/JAH, which are currently worth less than 10 BTC. Had I bought mining shares instead of lending (and keep in mind that lending means 0 interest if nobody takes my offer - yesterday was the first day that my offers were mostly lent out, on the other days so far I earned only a tenth of that amount per day), I'd have earned at least 5 times as much, consistently (JAH has ~70% APR at current difficulty + prices). The downside of course is that it might be problematic to sell shares in such an illiquid market as Bitfunder and also that shares probably loose value as time progresses and dividends are paid.

Also the average loan rate of BTC is now down to 3.5% - WTF?!

Edit:
Also the use of round() for balances is not very nice, for example:
Balance according to history: ฿55.0252
฿55.02 currently lent out
Lendable balance: ฿0.01
Trying to make a ฿0.01 loan offer fails because of insufficient funds.
Trying to partially fill a ~฿178 loan demand fails.

Also why do I only get interest in bulk at the end of the day (at ~1 AM GMT+1) and not after a position has been processed?
2824  Bitcoin / Bitcoin Discussion / Re: Newly Discovered Flaw, Could KILL Bitcoin! on: March 09, 2013, 10:54:50 AM
This requires a hard fork, if you create more than 3 additional digits (smallest unit is 1/100th of a nBTC) you overflow an 64bit int and once this is necessary, I guess there are a LOT of other problems first.

Currently there is also a hard cap of 1 million bytes/block. There are ideas to change that, but as it currently stands these are the rules every block on the network must follow to be valid. Of course in the future BTC could be divided down to 100 decimal places, blocks could be 100GB per block etc. - all these things are (maybe?) desirable or wouldn't change the main idea behind bitcoin a lot, but still currently and without a widely accepted hard fork they are out of question.
2825  Bitcoin / Development & Technical Discussion / Re: [ANN] Fast blockchain C++ parser w/ source code on: March 09, 2013, 10:41:42 AM
To deal with crappy retarded GPU drivers and UI in Linux? Roll Eyes No thanks, sir...
The manufacturers make the drivers, blame them.
Ok, let's blame AMDand nVidia! Evil you! You really should support Linux better!
Great to have done this, I guess that changes now everything...

I am also a Linux user and I never got my head down, knuckled down and tried to find a way around the problem - I simply installed a Windows VM or native machine and ran the program in it's intended OS. Please refrain from generalizing, I bet if you wrote this statement in a Linux heavy forum replacing Windows with Ubuntu and Linux with Gentoo it would also be in line there... especially taking into consideration that this software is said to only support 64 bit Ubuntu.

Anyways, there IS already the possibility to compile and run this software under Windows and as soon as I manage to compile it, I'll maybe even share the binary (for a hefty fee perhaps to cover my time). If this doesn't work, well - having a result in 3 minutes instead of one vs. having no result at all would still be an improvement, right?
2826  Bitcoin / Bitcoin Discussion / Re: Newly Discovered Flaw, Could KILL Bitcoin! on: March 09, 2013, 10:18:42 AM
In recent times mrbigg has started to troll hard with half-true information, similar to a user which name was a certain greek deity who carried the world on his shoulders...

If unprunable dust output becomes a problem, there IS incentive to include "collecting" transaction in the network - you have a big transaction input, but can prune each of these from your list. Once storing your list is more expensive than block space, you include these transactions. If it isn't, it's also not a problem to store them.

Also, there is a hard cap of 21 million times 10^8 Satoshis. You can do the maths how big the maximum set of pruned unspent outputs can get and this isn't even a VERY scary number (Facebook soon will store more data than that). This is the absolute maximum EVER that can be reached, no matter the block size, no matter how many people attack BTC.

By the way, I'm also pissed that SD is using several gigabytes(!) of my HDD space on my full node and only paying miners for including these (I personally believe there should be full nodes not only run by miners or at a loss) but instead of spreading information that I bend a bit to sound informed or plausible, I'd rather release a "no-SD" patch and maybe even binaries for pools to use. There STILL is no real bitcoin client that is tailored towards miners and their needs, most clients are written for end users (=transaction generators, not transaction confirmers).

Also this issue is not new at all, since day 1 SD has been under attack by people for creating 1 Satoshi bitdust. They didn't care back then and they won't change their operations now that they risk their business. Even the "let's track SD earnings" thread in the dev forum was also partly created to also see how much they bloat the block chain.

All you do with this thread is creating a Streisand effect - every publicity is good publicity...
2827  Bitcoin / Development & Technical Discussion / Re: Fee policy proposal: charge for outputs, not inputs on: March 09, 2013, 12:47:06 AM
Transactions with lots of inputs are actually good to have, as these lead to better pruning.
2828  Other / Meta / Re: Change [btc] to comply with ISO standard on: March 08, 2013, 02:32:15 PM
1) There is no ISO standard for Bitcoin.
2) If you want to use any potential standard, you can also use the proposed IANA currency registry, then you could write BTCX or just BTC.
3) I'd rather have this symbol being a "proper" B + stripes (which is anyways already a Thai Bhat symbol) than this bolded, weird monstrosity, no matter how you generate it in BB-code
2829  Economy / Economics / Re: The 2040 problem on: March 08, 2013, 02:25:23 PM
No, old topics can be still relevant and closing down everything only leads to re-iteration of the same issues over and over again.

The few necroed threads can be closed manually by mods as well...
2830  Bitcoin / Bitcoin Discussion / Re: A new name for mining on: March 08, 2013, 01:06:04 PM
Currently there's still more than 10% inflation per year because of _mining_. Once this number falls below 1% or so, you might want to call it something else, but at the moment the main income of miners is creating NEW coins, not auditing transactions.
2831  Bitcoin / Development & Technical Discussion / Re: Proposal: general move to bitcent/mBTC on: March 08, 2013, 01:02:37 PM
What if 1 Bitcent (0.01 BTC) becomes worth too much to be useful, similar to the current 1 BTC? It already only allows increments of ~40 US-Cents, so you already again need some digits after the decimal seperator (1 USD = ~2.5 Bitcent)...

mBTC are small enough currently to be able to ignore sub-mBTC amounts, µBTC will stay that way for even longer (and can have the "Nintendo points" advantage of currently being able to have payments end in 2-3 zeros, so in the near future you always own a certain number of hundreds or thousands of units).

Oh, and taking Finland prices as baseline + argument for pricing in BTC won't help a lot I fear - 20 EUR cents pay for nearly half an hour of parking here in central Europe for example and even in Finland if you had to round everything to the nearest 40 cents instead of 5 cents I guess you'd have quite an uproar (in Finnish proportions of course... Wink )
2832  Bitcoin / Development & Technical Discussion / Re: [ANN] Fast blockchain C++ parser w/ source code on: March 08, 2013, 12:21:44 PM
To deal with crappy retarded GPU drivers and UI in Linux? Roll Eyes No thanks, sir...

Anyways, in theory it should(TM) be possible already to compile + run this parser for Windows. It's not znort987's resposibility to actually provide the means to do so, especially since he doesn't want to do it. It would be nice of him if somebody manages to actually come up with a solution how to do it, to integrate some minor patches (as far as I see it from the code, the blockchain location is hardcoded for example - having a setting for Windows or even Linux users there might be nice) and the actual way to do it, but even that is not his job at all (and you simply could just fork his project after all).

The code is public domain and uses OpenSource libraries. Either invest the time to compile that stuff yourself or pay somebody to do it for you. If mmap implementations on Windows are really that slow, you can also improve them, since this project is built on OpenSource software. Again, either by yourself or somebody you pay to do that.
2833  Bitcoin / Project Development / Re: ASIC for ECDSA verifying ? on: March 08, 2013, 10:56:55 AM
I guess an FPGA solution would be the first step... Wink
2834  Bitcoin / Development & Technical Discussion / Re: BIP Warning! Developers want to eliminate free transactions and fork Bitcoin on: March 07, 2013, 04:37:47 PM
Catching attention with such a title is NOT nice at all and however good your idea might be that you actually want to present, people will immediately look down on it because nobody likes to be fooled.

Also: Please state exactly how many satoshis is the minimum fee per kB for the centuries to come and why.
2835  Bitcoin / Development & Technical Discussion / Re: Inflation-proofing via fraud notices on: March 07, 2013, 04:34:17 PM
What can you do with that money though? If you control all connections of a SPV client you can feed him spoofed data (but you still have to mine the blocks, something that will not give you any benefit on the main chain), so far so bad. Now you can in one block create a million coins in a faked coinbase transaction, then in the next block send it to the client (which might ask for it's origin, and you just claim "coinbase"). What now? As soon as the client gets out of your "bubble" and sees the real chain, it will be much longer or you'd be anyways better off 51%ing the main net.

Generating a handful of headers in some reasonable time frame (if it takes much longer than 2-3 hours for 6 blocks your user might get suspicious) is not easy and you still need a quite high hash rate.

Since SPV clients anyways need to trust full clients, ensuring a good (whatever that means) selection of several full clients connected should be one of the more important points in that area.

I don't understand who would send out these challenges when let's say EvilMiner has taken over all connections my light client has to the Bitcoin network, but I'm unaware of that. He then proceeds to generate a fork of the block chain I have and builds a fake block that grants me 1 million coins from a transaction (not coinbase otherwise he'd need to build 100 more blocks). Then he extends that fork by spitting out 2 more blocks on top of that, claims my million coins have now been delivered an I should better pay up on Paypal. I grow suspicious and send out a challenge for that transaction to the network. Since EvilMiner _is_ my network (otherwise I'd already have learned of the 8 legit blocks that were mined in the meantime) he does not relay that request, but does what exactly?!
2836  Economy / Trading Discussion / Re: Why I Prefer to Trade BTC/USD at BitFloor instead of MtGox on: March 07, 2013, 01:55:40 PM
How are new users affected from their hack fiasco? If I'm a new user, are my funds getting frozen too?
2837  Economy / Trading Discussion / Re: Mt.Gox trading fees: is a revision due? on: March 07, 2013, 01:51:57 PM
One of the reasons MtGox cited in the past for it's relative high fees was to allow competition into the market. If they went to the lowest fee they can manage, their market share would go even higher. Currently you can just use a different exchange (or even a meta-exchange like bitfinex) to get less fees.
2838  Bitcoin / Development & Technical Discussion / Re: Inflation-proofing via fraud notices on: March 07, 2013, 12:45:29 PM
Mike, I obviously failed to explain it properly. Whatever headers and coinbases are presented to an SPV client, there is a rule  stating that at block 100 000 there should be strictly  5 000 000 BTC or less in circulation. So, a chain of headers which sums above that should be considered invalid.

If I have the first 4 blocks with the following coinbases: 10 BTC, 20 BTC, 30 BTC, 40 BTC - how many BTC are in circulation - 100 or 40 or something in between? Did "my" block chain rules just generate 10 more BTC each block, or did it only generate 10 BTC per block, but all of these were used as fees in every block? Without looking at transactions you can't tell.

Currently it CAN be possible that there is a block mined with a few million BTC in it's coinbase that is valid, if at once everyone with loaded addresses decides to pay these out to miners. Still only 25 out of these millions of fees are actually "new", the rest is from fees.

The only impossible values would be everything larger than (all_coins_mined_so_far + reward_for_current_block), maybe one can also factor in coins held by oneself (not that this makes it any easier to show anything). Everything else is possible, recently someone did mess with handmade transactions probably and ended up paying 94 BTC in fees which is a huge value in current USD prices. Before that there were also (accidentially/willingly) fees paid that ended up multiple times larger than the then current block reward.
2839  Local / Off-Topic (Deutsch) / Re: Super Lustiges Video über die Gleichschaltung der Medien, nur 1,5 Minuten! on: March 07, 2013, 12:26:44 PM
Schon mal Presseberichte von Presseagenturen + dann 5 größere Zeitungen gelesen? Sobald es nicht um Titelstories geht, wird da sowieso nur copy-paste betrieben.
2840  Local / Anfänger und Hilfe / Re: Hohe Transaktionsgebühr und Zwangsgebühr mit Client? on: March 07, 2013, 12:23:52 PM
Oder mische ich da Äpfel mit Birnen?

Ja - die 120 Confirmations sind für Miner relevant, wenn sie Bitcoins aus dem "Nichts" erhalten. Die dürfen sie erst nach 100 Blöcken in einer Transaktion verwenden. im offiziellen Client sind noch 20 Extrablöcke eingeschoben.

Dein Problem ist, dass deine Coins erst vor Kurzem verschoben wurden. Die Standardregeln, die die meisten Miner befolgen besagen, dass es zu bevorzugen ist, wenn man nach langer Zeit eine Transaktion ausführt. Zusätzlich wird dann noch geschaut wie groß die Transaktion ist und wieviel Fee dafür ausgelobt wurde. Der schlechteste Fall wäre also eine große Transaktion ohne Fee die aus gerade erst bewegten Bitcoins besteht.

Eine ~30 BTC Transaktion aus alten Coins von mir ging z.B. gestern problemlos in 0 komma nix gratis durch - würde ich die Coins aber jetzt gleich wieder verschieben, müsste ich wohl etwas warten.

Was passiert, wenn die Transaktion nicht klappt, warum auch immer? Werden mir die BTC irgendwann wieder "gutgeschrieben"? Wenn ja, wann und wie?

Jein, das ist ein Problem, das hoffentlich bald angegangen wird. Wenn du eine Transaktion in's Netzwerk rausposaunst, merkt die sich jeder Node bis sie in einem Block auftaucht (war ja bisher selten ein Problem...). Dadurch wird jede Transaktion die du mit den gleichen Coins danach (eventuell mit mehr Fee) erstellst als Double Spend angesehen und nicht weitergeleitet. Im Moment wird daran gearbeitet, dass z.B. nach ein paar Stunden/Tagen/Wochen(?) die Clients Transaktionen wieder vergessen und daher eine neue Transaktion möglich wäre. Will man also unbedingt nochmal die gleiche Transaktion senden, müsste der eigene Client also alle X Zeiteinheiten die Transaktion nochmal veröffentlichen.

In deinem Fall würde ich einfach 1-2 Tage warten, wenn du nicht gerade nur 2 Satoshi gesendet hast. Momentan ist eben sehr viel an Transaktionen im Netz weil irgendwie alle kaufen und verkaufen wollen...
Pages: « 1 ... 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 [142] 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 ... 269 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!