Bitcoin Forum
June 27, 2017, 05:41:13 AM *
News: Latest stable version of Bitcoin Core: 0.14.2  [Torrent].
 
  Home Help Search Donate Login Register  
  Show Posts
Pages: « 1 2 3 4 5 6 [7] 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 ... 460 »
121  Bitcoin / Development & Technical Discussion / Re: Beware bitZino shuffling algorithm leaves much to be desired... on: February 18, 2015, 06:40:47 AM
Quote
MT rand is truly bad at generating security-sensitive randomness.
- https://news.ycombinator.com/item?id=9058074

Is this a problem for bitZino users?
122  Bitcoin / Bitcoin Discussion / Re: Bitcoin 20MB Fork on: February 12, 2015, 09:59:17 AM
As soon as I hear about A2, or maybe A3, I'll drop my B1 block because it's no longer on the longest chain.  From my point of view it's exactly like having a block orphaned for any other reason.

What if "Client B" were to reject any block that was 1MB or below, and only created blocks larger than 1MB (starting with some future block number).  Then regardless of "Client A"'s hashing power, those blocks will not be valid as far as Client B is concerned.

Sure the chains will quickly diverge (as there will be UTXOs with taint from new post-fork coins in Client A that will be rejected on Client B, and coins tainted in Client B are rejected by Client A).  If Client B only gets a really small amount of hashing capacity it won't be seen as being secure enough to persuade users to hop over to Client B.  But with a 20MB max blocksize, just 2% of the hashing capacity is still enough to absorb existing daily Bitcoin transaction load.  So does having just 2% mean this Client B dies, ... or does it just mean that we have an altcoin that was launched with initial distribution going to every person (or wallet) holding Bitcoin at the point the fork started?
123  Bitcoin / Bitcoin Discussion / Re: Bitcoin 20MB Fork on: February 11, 2015, 06:00:46 PM
Would there be much harm to the existing bitcoin ecosystem if someone released the gavincoin patch today?  (e.g. takes Bitcoin client such as v0.9.2 and simply changes the max to 20MB (or anything above 1MB), sets block nVersion=4, and maybe uses some other network port number).

I would like to see this as it will help us quickly learn the lesson about post-fork fungibility.

Why would anyone mine using this client (or join a pool using it)?   Well, because there is demand for gavincoins.  Why is there demand?  Post-fork there will be two chains.  All 13.8 million bitcoins pre-fork are spendable on the gavincoin side as well but if the transaction includes any amount of a gavincoin coinbase the transaction will be rejected on the Bitcoin side.

Initially many of those holding bitcoins (myself included) will want to buy a tiny bit of gavincoin to have some to be able to taint their bitcoins that will then be spent using the gavincoin client.  Even if the value of these tainted coins is a pretty trivial amount I probably will still want to sell them for whatever I can get since spending them doesn't impact my ability to use those same coins for spending on the Bitcoin side -- as that side knows nothing about the spend transaction from the gavincoin side (for those transactions that include any amount of gavincoin coinbase).

Because there is this initial demand for these gavincoins it won't take long for an exchange to pop up that offers BTC/GAV trading.  (If you still aren't convinced that a market exists, simply look at the orderbooks with  buy orders for all those shitcoins).

All then that is needed is a pool to mine using the gavincoin client which attracts at least ~6,650 Th/s (roughly $2.8M worth of the latest ASIC hardware) to cause the gavincoin side to get three blocks per day (the current Bitcoin transaction load is roughly 60MB per day so that daily load could be included in three blocks of 20MB each).   Also if this gavincoin client is using a different network port number someone would need to re-broadcast the bitcoin transactions onto the gavincoin fork (and maybe vice-versa so that all transactions that can confirm on both sides of the fork are broadcast on both sides.)

So let's say this gavincoin client comes out today and within a few days the first block on the gavincoin side is mined.    There should be no risk to the Bitcoin side of the fork as far as I can see --  at least not initially.  Now the gavincoin side ... that wlll have so little hashing capacity so those exchanges accepting gavincoin payments need to consider that a 51% attack against that side of the fork is certainly possible [Edit: after difficulty adjusts down on the gavincoin side a few times].

Then watch and see what happens.   Maybe both sides co-exist permanently, who knows.

[Edit: There is however the risk of a transaction that gets made with the intention of it being a gavincoin transaction but then it gets misconstructed where it includes only valid Bitcoins.  Since that transaction wouldn't have any gavincoin taint it will confirm on the Bitcoin side.  That gives the recipient the valuable bitcoins instead of the low-valued gavincoins.]

[Update: Also, the gavincoins generated are not spendable until they have 100 confirmations -- so that'ld take a month at only 3 blocks / day before a single "tainting" transaction could occur.]

[Update 2: A catalyst for the fork would be needed.  For that the Gavincoin patch could set a future block number as where the fork will begin and beginning with that block only blocks with nVersion=4 would be valid.]

[Various minor edits for clarity and readability.]
124  Bitcoin / Project Development / Re: Bringing Bitcoin to the world-competing with Western Union on: February 11, 2015, 11:30:48 AM
Some more remittance-related Bitcoin news:

Kenya's http://BitPesa.co gets another $1.1 million investment allowing them to expand to serving Uganda and Tanzania: http://blogs.wsj.com/moneybeat/2015/02/09/bitbeat-kenyas-bitpesa-raises-1-1-million-expands-operations/

Last bank enabling remittances from the U.S. to Somalia forced to discontinue that service: http://www.monbiot.com/2015/02/10/unremitting-pain

125  Bitcoin / Bitcoin Discussion / Re: Bitcoin 20MB Fork on: February 09, 2015, 08:22:26 AM
Without a fork, does tumbling become prohibitively expensive?
126  Bitcoin / Bitcoin Discussion / Re: Bitcoin 20MB Fork on: February 08, 2015, 10:35:14 AM
Every increase in fees means more utxo's fit the definition of "dust" in that spending them would require more fees than they are worth.  And fees will definitely increase.  [...]

a lot of the present holders [...] will likely find that they have a lot of unspendable outputs at some point.

And if I am using Bitcoin-Qt client, it isn't exactly in a hurry to spend these funds any time soon as its aim is to minimize fees, not spend the microtransactions before they become no longer economically spendable.

So regardless of whether or not you want to see a fork, it won't occur soon.  Anyone with a wallet holding transactions of small amounts (and that includes most anyone who uses Bitcoin regularly) would be wise to begin consolidating now while transaction fees are still cheap.
127  Bitcoin / Bitcoin Discussion / Re: Bitcoin 20MB Fork on: February 07, 2015, 09:05:45 PM
If there is no hardfork, will even UTXOs with just 0.001 bitcoins (one millibit) become economically unspendable?

Let's say with blocks filling we have fees rising to about 0.001 per 1K of data (on average).   So with that you have fees totaling about 1 bitcoin per block.  That's about 144 bitcoins per day.  (in addition to the block reward subsidy of 3,600 bitcoins per day).   So even with fees of 0.001 per 1K miners are still earning less than 4% of total revenue from fees, with the rest of their income being the block reward subsidy.

But here's here I'm seeing the problem.  With space becoming scarce, the fees make a whole lot of UTXOs economically unspendable.  A 1K transaction might be something like six inputs and two outputs.  So with a fee of 0.001 means the marginal cost for each UTXO input is about 0.0001  (roughly 300 bytes for the trx and two outputs, and ~120 bytes for each input [Edit: rough guess, but in the ballpark I believe]).  That means the fee at  0.001 per 1K costs about 10% for each UTXO of one millibit.

This wasn't something that concerned me previously because fees had only been dropping over time.  If fees on those UTXOs were costly then you simply don't spend them and you could wait for the next drop in fees.  With blocks filling causing rising fees (to 0.001 bitcoin per 1K size) then the penalty for retaining UTXOs of one millibit or less can be 10% (or more!).

And that's only with the required fees rising 0.001 bitcoin per 1K.   What if it rises to 0.01 bitcoin per 1K size.  Now your marginal cost for each UTXO input is about 0.001 which means each and every UTXO of 0.001 or less has become completely worthless (i.e., it costs as much in fees to spend as it is worth).

The argument against Bitcoin value rising being a problem was that with divisibility we could just transact in smaller and smaller amounts.   We even saw a push to start using the term "bits" (0.000001 bitcoin).  But if any UTXO not significantly above 0.001 bitcoin becomes economically unspendable then "divisibility to 8 decimals" as being something that solves the deflationary problem is no longer rational counterargument.

I don't know what is worse -- monetary inflation causing a 4% devaluation per-year, or each year rising fees causing 4% of the funds in your wallet to become unspendable.
128  Bitcoin / Bitcoin Discussion / Re: Permanently keeping the 1MB (anti-spam) restriction is a great idea ... on: February 05, 2015, 11:57:00 AM
If I lose direct access to the blockchain then I am forced to hand over all my wealth (not just enough funds to cover trivial purchases) to a third party.

That's probably the best argument I've seen.  I think of how today I have many paper wallets, mobile wallets, and hosted (shared) E-Wallet services (i.e., custodial services) where I had a balance of a few millibits or less in them and won't (or can't) withdraw because the Bitcoin network transaction fee is prohibitive for that small amount of bitcoin.    Now as fees rise due to scarcity of empty space in blocks then I'll essentially have permanently abandoned those wallets with the small values (i.e., those funds become economically unspendable, ... worthless!).

I suppose for the paper wallets and mobile wallets where I have the private key I could combine them into a single transaction without incurring a higher fee, but that's possible only today because there's still some low-cost space left and the fee required doesn't rise linearly when the size of the transaction rises.   Without a fork then eventually we are essentially paying a fee for each additionally byte and the resul will likely be that millions of UTXOs with small amounts (e.g., sub-millibit -- less than 0.001 bitcoins) will become worthless.   Hey now,  that's some real money we're talking about discarding!  [Anyone care to crunch the numbers -- what is the sum total of bitcoins that exists in UTXOs under one millibit?)  

It makes me think back ... First they came for the dust, and I didn't speak out because I didn't play SatoshiDICE.    When this day comes (when the 1MB cap is reached, and no-hard fork), maybe a millibit becomes the new dust!   And then let's say the fee required rises even more, maybe UTXOs under 0.01 even become economically unspendable.    That becomes a real problem for most of us!

So what to do?
I'ld like a Bitcoin that can scale and grow with transaction demand.  I'ld also like my car to get 150 MPG.  The latter can't happen simply because a gallon of gasoline doesn't have the energy needed for an internal combustion engine to propel today's car for 150 miles.  Now I'm not entirely convinced the former can happen either.  That's because a hard fork that doesn't have the consent of the Economic Majority ( http://en.bitcoin.it/wiki/Economic_majority ) will fail.

Let's go through the first hours of the hard-fork.  Let's say it happens at block 400,000 (a lttle over a year from now).  Everything was in place -- miners with the right nVersion indicating consent was well above the threshold (e.g., 80% of last 1,000 blocks had nVersion=4).     But ..., I'm not willing to believe that exchanges, merchants, merchant processors, etc. are going to themselves take on the full risk of double spending that would occur if the hard fork eventually fails (maybe a day or three later even).   The only way to prevent the double spending that would result would be to require that a transaction confirms on the block chains on both sides of the fork.  So these entities are going to watch both sides. Well, a transaction that has any taint from a coin generated on the side with the larger block size rule change (I hate calling them "gavincoins", but for the purpose of this argument that name is short and everyone here knows what it means) will not confirm on the other side of the fork where the 1MB limit is still followed.

So the market instantly realizes this difference between a Bitcoin and a GavinCoin.  So the value of a GavinCoin will drop relative to a Bitcoin.   Miners can't convert or spend these newly mined coins nearly anywhere, so all you have is buying from speculators.   Now those mining on the side which still recognizes the 1MB max limit are still mining blocks (albeit at a much slower rate because of the dramatic loss of hashing capacity) and some market for those newly mined coins exists -- again, thanks to speculators.    Things can flip quick.  Maybe a day goes by and all of a sudden a large amount of hashing capacity switches back to the 1MB max side due to the dropping exchange rate of GavinCoin, and it becomes quite possible (if not probable) that the 1MB limit will be with us for some time longer.

The exchanges and merchants that played both sides (i.e., required confirmations on both sides of the fork) lost nothing as either way they have confirmed transactions on what is eventually the sole winner.   If the hard fork fails then the losers are those who had E-Wallets (custodial accounts) and found their pre-fork bitcoins were spent and they only end up with tainted GavinCoins that can now never be spent (at least not anywhere near parity with a bitcoin).   Likely most every custodial service (e.g., exchanges, hosted/shared eWallets, etc.) that didn't require confirmations on both sides of the fork ends up bankrupt as a result of getting dumped on with GavinCoins while allowing withdrawals of untainted bitcoins.

I just don't see how a hard-fork succeeds.   There is risk of accepting GavinCoins.  There is no risk (excluding exchange rate risk) of putting your own pre-fork coins into storage for a (long) while and not letting them become tainted GavinCoins (as they can still be spent a year, two or ten later).

[Edited: A couple small readability changes.]
129  Bitcoin / Bitcoin Discussion / Re: Permanently keeping the 1MB (anti-spam) restriction is a great idea ... on: February 05, 2015, 11:56:29 AM
On edit: fixed some typos.

Possibly one more ...
"Have you ever thought about the fact that you send a bank wire yourself."
Did you mean to instead write "that you can't send a bank wire yourself."?
130  Economy / Services / Re: Monbux's FREE Escrow Services | Non-IPO's: FREE | IPO's: 2% | Security Upgrade on: February 03, 2015, 07:59:51 AM
I have just completed a transaction (sold domains) in which monbux performed the escrow.  The were no complications and when the buyer instructed that the escrowed funds be released they were, so this was a good trading experience.
131  Economy / Trading Discussion / Re: Help with good bussiness ideas for cool domain names. on: January 28, 2015, 02:24:58 AM
I wish I own bitcoinpurse.com:)

Now's your chance ... make an offer! [Update: Sold]
   
[WTS] Premium Bitcoin Domains
 - http://bitcointalk.org/index.php?topic=848915.0
132  Bitcoin / Development & Technical Discussion / Re: Block size on: January 25, 2015, 05:49:23 PM
that consciousness is going to make the decisions, from now on.

Well, more specifically, it is the "economic majority" that decides.  This is the merchants and invest that buy the mined coins from the miners.   If they are willing to pay equal value for the coins generated in blocks mined using the changed protocol (with the larger block size) then the change happens.     If they aren't willing to buy those coins, then miners find a better deal (higher price) by sticking with protocol as it existed prior to the change.

When this happens (and I believe it probably will) it's going to be a nailbiter.  Will miners who had been running the code with the protocol changes (proven by including a new version number in the block header) get skittish if there is nobody will to pay full price for their mined coins (i.e., coins mined once the hard fork occurs)?  Since it is a possibility, they likely will be prepared to revert to the old code on-demand.

I wrote more on this possibility here:
 - http://bitcointalk.org/index.php?topic=919629.msg10118626#msg10118626
133  Economy / Service Announcements / Re: [ANN] LocalBitcoins.com - a location-based bitcoin to cash marketplace on: January 17, 2015, 02:55:10 PM
Why 5 minutes. If they throttle the payout to every 10s, they could still get some transactions at times while no or just one transaction at other times. For a business of that scale it would just make sense.

They already charge the user for the withdrawal.   Therefore, it wouldn't be fair to the user to have to wait for delivery because the service wants to earn a little profit on the fees by batching them up.   I doubt they'ld have more than one withdrawal per minute, but I don't know their volume levels so I could be wrong.

I just did a transaction minutes ago and do not recall a huge delay. The transaction was exclusively made for me though.

Same here ... my "send bitcoin" transaction had already hit the blockchain when I checked just a matter of seconds later.
134  Economy / Service Announcements / Re: [ANN] LocalBitcoins.com - a location-based bitcoin to cash marketplace on: January 14, 2015, 12:52:31 PM
Recently, I processed a withdrawl from localbitcoins.
Here is the txid for it: https://blockchain.info/tx/3f63d57d8590aef8983052308661b40f926654f19ece48f0a6554c8c0e4bed83
One of the receiving addresses is mine.

I remember withdrawals from LocalBitcoins being pretty instantaneous.  If they were batching them (combining multiple withdrawals together) then it would not be instantaneous (e.g., maybe one trx every 5 minutes).   



So does localbitcoins charge a transaction fees from everyone separately?

The fees stated in the FAQ are reasonable (0.0001 to 0.0004 bitcoins). https://localbitcoins.com/fees
135  Alternate cryptocurrencies / Altcoin Discussion / Re: Why did Roger Ver invest in Ripple? on: January 14, 2015, 09:31:02 AM
I don't really see it as a competitor to Bitcoin,

Ripple provides a unique form of gateways from Bitcoin to fiat and other assets.  Thus it is complementary to Bitcoin.   Now I suppose you could argue that XRPs compete against Bitcoin in that those investments might have gone towards Bitcoin instead (i.e., displacement) but that's a pretty weak argument -- they might have gone to gold, silver, NASDAQ, etc.,  too.

Disclaimer: Holds no XRPs and haven't since I sold the freebie handout ones given out to all BitcoinTalk users.
136  Other / Off-topic / Re: Sorry, y'all: Game Over. I'm about to buy all the bitcoin. on: January 13, 2015, 02:34:36 PM
Stlll going .... now mtgoox.com

Previous scams (in chronological order) likely by the same scammer:

 - EasZPay.com
 - MtGax.com
 - MtGix.com
 - i4Dollars.com
 - BTKoin.com
 - BitcoinTalks.com
 - VirWex.com
 - bitcoin.appee.com
 - silkroadtor.com
 - mtgox.us
 - bitswing.com
 - bitcoinarr.com
 - emocoe.com

Please report this scammer for phishing:

 - http://www.google.com/safebrowsing/report_phish/?url=http://mtgoox.com
137  Bitcoin / Bitcoin Discussion / Re: Fork off on: January 12, 2015, 12:51:16 PM
The fork will not happen without miners' explicitly signaling consensus by updating the version number in the blocks they create.

But a miner can rollback to running a node that does not implement the hard-fork in just seconds, should there be any doubt that the hard fork might not succeed.  So just like in March 2013 when v0.8 blocks were ahead by a wide margin that didn't mean that side would ultimately continue as the longest chain.

Firstly it assumes that miners are driven to much by economics and to little by politics than is probably true.  I'm sure that most of the miners who count these days have every likelihoods of looking out days or weeks into the future and taking a monetary hit for a future enduring reward.

If that were true, p2Pool would be among the top 3.
138  Bitcoin / Bitcoin Discussion / Re: Fork off on: January 11, 2015, 11:08:43 PM
I have a few Qs...

1. Even If all miners accept the fork, can it sustain unless majority of nodes do not update themselves ?

On the technical side, you only need enough nodes using the software that implements the hard-fork to ensure that post-fork blocks get propagated.  But even if *nearly* all miners accept the fork, even if you only had something like 10% still hashing without the changes implemented you'ld still get a block every two hours -- frequently enough to include most high-value and high-fee transactions.   [Edit: (i.e., sustainable for anyone using a node without the hard-fork changes).]

2. If all miners do not accept the fork, then there will probably be 2 blockchains for some time. At that period of time, wont all coins be spendable twice on 2 different chain ?

Yes, that's why it will be so dangerous to accept payments from anyone that includes coins tainted with post-fork coinbases.    I personallly will not have a single millibit remaining on any exchange or e-wallet at the time of the fork if there is any hint of dissent like this.  I will only accept payment transactions that confirm on both sides, ... which can only happen if the transaction had no UTXOs tainted with post-fork coinbases.   Maybe after a week or two and there's essentially nobody remaining mining the original side of the fork will I be willing to accept post-fork coins.
139  Bitcoin / Bitcoin Discussion / Re: Fork off on: January 11, 2015, 10:37:09 PM
Control of Bitcoin rests in the hands of miners when you're talking about a chain fork.

And miners are essentially paid employees/contractors.

The Economic Majority is who the miners work for: http://en.bitcoin.it/wiki/Economic_majority

Now what isn't being appreciated is exactly how risky it is to miners to adopt changes that have the potential to put them mining on the wrong side of a fork.

Let's say you run an exchange (e.g., BitStamp), hosted (shared) E-Wallet (e.g., Coinapult), or merchant processor (e.g., BitPay).    If you start accepting bitcoins from miners (which become spendable after 100 confirmations) then you are taking on the entire risk of loss if the proposed fork fails to maintain the lead.   So maybe to protect against that risk you reject any deposits or purchases that include coins that are tainted from post-fork coinbases.  That immediately kills fungibility.  The miners won't want to take on the full risk themselves and begin to dump their newly mined post-fork coins at a discount.  Pretty soon the unchanged side of the blockchain fork gains hashing power and begins to snowball.  The writing is then on the wall.  Maybe 24 or 48 hours later, the proposed fork that initially had "wide support" is no longer the longest chain.

Now when that happens you have havoc wreaked because certainly this was an outcome that some fraudsters were hoping for and the two sides look nothing alike -- with many, many coins spent differently between the two sides of the fork.

I'm not saying I wouldn't like to see a bigger blocksize.  I'm just pointing out that a hard fork will require a huge collective leap of faith -- and even this sole promise of dissent might be sufficient to torpedo that forking effort.
140  Bitcoin / Bitcoin Discussion / Re: Bitstamp hack. A real life test of anonymity in Bitcoin on: January 11, 2015, 06:26:41 PM
There isn't even any proof that Bitstamp was ever hacked.

Exactly.  If we were to start treating these coins different from any others (e.g., by blacklisting them) then that provides an opening for all kinds of abuses (by those who might falsely claim "hack!" in an attempt to get the funds back or drive some other outcome.)
Pages: « 1 2 3 4 5 6 [7] 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 ... 460 »
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!