Bitcoin Forum
May 26, 2024, 11:58:56 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  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 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 ... 162 »
641  Alternate cryptocurrencies / Altcoin Discussion / Re: LTC on MTGOX on: April 02, 2013, 04:23:37 PM
#mtgox topic since yesterday :

Quote
Mt.Gox 24/7 IRC support channel | don t ask to ask, just ask | offtopic goes to ##mtgox-chat | tickers and trades on #mtgox-RT and #bitcoin-RT | LTC support coming this month

Duplicate post.

Scroll up and read the thread before posting Smiley

642  Bitcoin / Press / Re: 2013-04-02 Quartz, How to Short Bitcoins If You Really Must on: April 02, 2013, 04:16:50 PM
"If there ever is a way of breaking up a Bitcoin into smaller fractions..."  I guess one ten billionth isn't tiny enough for some people  Cheesy

Already replied to author with corrections Smiley
643  Bitcoin / Development & Technical Discussion / Re: The minimum transfer fee is not trivial anymore on: April 02, 2013, 03:08:29 PM
Nothing stops a pool from running a subscription-only bitcoind instance via which users can submit any transaction they want directly.

Certainly.  Eligius will send non-standard transactions that include a certain set-by-Eligius fee.  Because non-standard transactions are not relayed, you must submit such transactions directly to Eligius.

I wish more miners would offer services like this.

644  Bitcoin / Development & Technical Discussion / Re: The minimum transfer fee is not trivial anymore on: April 02, 2013, 02:55:11 PM
It is obscene that minimum tx fees are fixed BTC/KiB recommendations. This must be determined by individual miners! Miners must decide for themselves how much tx fees they accept. Miners need to be competing with each other on this. That was the original idea of Bitcoin. This will solve the problems of variable Bitcoin exchange prices by itself!
Miners can already do this. Most of them just haven't chosen to do so yet.

Yes and no.  Miners select which transactions appear in a block...  but clients choose which transactions to relay to other peers.  Most clients will not even relay spam transactions (for obvious reasons... they are spam).

645  Bitcoin / Development & Technical Discussion / Re: The minimum transfer fee is not trivial anymore on: April 02, 2013, 02:53:54 PM
In light of the rapid increase in value of BTC in other currencies, we’re gonna have to look at the fees and how to scale up the network to deal with smaller transactions. Right now, the standard 0.0005 BTC fee is about $0.05. It’s not that big of a deal yet, but it makes sending anything less than a dollar (0.01 BTC) somewhat expensive. And that’s before accounting for higher transaction volume

It is widely agreed that the default fees need to be adjusted.

However, standard disclaimer:  bitcoin is not, and never will be, a micro-payment or micro-transaction network.

Quote
Perhaps the solution can also be a de-centralized sub-network that works similarly as BTC that deal with smaller transactions and only charge the standard fee when pulling out?

Yes, this is called "off-chain transactions" and it is a very good, very realistic solution.  No matter how much bitcoins scale up, there will always a market for micro-payments and micro-transactions.  It is predicted that micro-payment services, bots and networks will appear to handle this use case.

646  Bitcoin / Development & Technical Discussion / Re: The minimum transfer fee is not trivial anymore on: April 02, 2013, 02:51:10 PM
Wouldn't it be even better to stop using fees as anti-DoS?
Why can't we detect DoS by simply measuring the amount of data a peer is sending? If it goes beyond X KB/s, we stop storing and relaying transactions coming from this peer, eventually we disconnect from it and temporarily ban its IP locally. X could be configurable, in case there's a strong need to change the defaults without a release.

Because we are a decentralized network Smiley  You can instead connect to 20,000 peers, and send one tiny spam through each.

Requiring some minimal cost to send a transaction, even if 1 satoshi, is a very elegant solution to spam.

However, as many others have noted, having a fixed fee schedule is too rigid, too inflexible.

647  Bitcoin / Pools / Re: [400GH/s] p2pool: Decentralized, DoS-resistant, Hop-Proof pool on: April 02, 2013, 02:47:18 PM
It sounds like forrestv is instead in favor of alternate means to extend the effective work interval through merging of parallel chains.  Various theoretical designs were discussed.

We may end up making a fork or a frankenbuild of p2pool to fix things for testing. I don't see why in the end it would need to fork for everyone, but it would be a hard fork and everyone would need to upgrade to a version where everyone is on the same share chain.

It ultimately seems like 10 seconds is just too short, given Internet propagation, current Avalon hashrate, and the up to 1.5-second delay it can take for work to be returned from Avalons (high latency).  Thus, I argue for around 30 seconds, which would imply a hard fork at some point.
648  Bitcoin / Bitcoin Discussion / Re: Upcoming network event: block v2 lock-in on: April 02, 2013, 04:26:17 AM
Can someone explain me how block v2 is an improvement?



Prevents duplicate transaction id's from being creating, and assists in block verification, by putting block height into the special "coinbase" transaction #0 found in every block.  See BIP 34: https://en.bitcoin.it/wiki/BIP_0034

649  Bitcoin / Pools / Re: [400GH/s] p2pool: Decentralized, DoS-resistant, Hop-Proof pool on: April 02, 2013, 02:14:06 AM
Yes I think you've found the "problem" The issue is, the asics NEED a higher difficulty, or they are going to kill the smaller miners in p2pool.

Yes, this was established the day the first Avalon arrived Smiley

Quote
I also think as difficulty greatly increases, we are going to need a longer long-poll time as well. maybe 20 or 30 seconds.

On IRC, an ASIC-only p2pool share chain idea was floated, with a higher difficulty by default and a longer time between shares.

650  Bitcoin / Development & Technical Discussion / Re: [ANN] BitEN - bitcoin erlang node on: April 01, 2013, 05:53:08 PM
UDP is an example of the tremendous misalignment of incentives between "core dev" and commercial use.

UDP has the potential to deliver blocks and transactions more rapidly throughout the network.  The former benefits miners, and the latter benefits all bitcoin users.

651  Bitcoin / Development & Technical Discussion / Re: Funding of network security with infinite block sizes on: April 01, 2013, 05:50:47 PM
Idea: why not increase the hash difficulty for larger blocks? So if a miner wants to pass the 1MB threshold, require an extra zero bit on the hash. There's a big disincentive to include lots of tx dust.

Hmm, so a block with twice the difficulty can have twice the size?  In effect, this allows the block rate increase faster than once every 10 minutes, by combining multiple headers into a single header.

If you have 1MB of transactions worth 10BTC and another 1MB worth 5BTC (since they have lower tx fees), then it isn't worth combining them.  A double difficulty block would give you 50% the odds of winning, but you only win 15BTC if you win.

That actually effectively illustrates part of the difficulty in creating a solution:  our economic reasoning will be clouded for many years by the block subsidy, which will probably dwarf the transaction fees for years to come.  Efficiencies which must exist in the self-supporting, fee-only future are unseen at this time.
652  Bitcoin / Development & Technical Discussion / Re: Funding of network security with infinite block sizes on: April 01, 2013, 03:54:39 PM
Infinite block sizes.
653  Bitcoin / Development & Technical Discussion / Re: Funding of network security with infinite block sizes on: April 01, 2013, 03:36:50 PM
In general it sounds like an unworkable scheme.  There is definitely no consensus on the block size issue at all.
654  Bitcoin / Bitcoin Technical Support / Re: Pushpool - Tech Support on: April 01, 2013, 03:35:56 PM
Given renewed interest, it is strongly tempting to jump in and fix the major misfeatures:
  • getwork proxying (should be getblocktemplate for high speeds)
  • internal work generation
  • stratum protocol support
  • separate database threads
655  Bitcoin / Development & Technical Discussion / Re: [ANN] BitEN - bitcoin erlang node on: April 01, 2013, 02:21:03 AM
Seems to me Bitcoin's biggest problem at the moment is that there is only one implementation.

Incorrect.  There are several implementations.

Quote
It seems that there is absolutely no desire by the core dev team to ever have more than one client,

Incorrect.  Gavin actively encourages alternative implementations, and I've written two alternate implementations.  At least one was linked earlier in this thread.

656  Bitcoin / Development & Technical Discussion / Re: Initial blockchain download on: March 31, 2013, 06:22:21 PM
I can see that, yes.  However in my case I certainly wasn't CPU bound, and I certainly wasn't network bound.  I can only conclude I was bound by the rate at which the 5 or 8 nodes I was connected to were willing to pass me the blocks.

Most likely you are bound by the poor peer selection.

Initial blockchain download occurs from one peer at a time.  If that peer is slow, then your entire blockchain download is slow.

Yes, it's stupid and yes it needs fixing (patches welcome).

The blockchain torrent is a stopgap fix, that works around the find-a-good-peer issue.

657  Bitcoin / Press / Re: 2013-03-28 Yahoo.com New Online Currency Soars in Value on: March 29, 2013, 01:22:20 AM
Read the byline.  It's from CNBC.
658  Bitcoin / Bitcoin Discussion / Re: BitcoinFoundation - PR person ? on: March 28, 2013, 11:20:58 PM
Why is this thread locked ?

https://bitcointalk.org/index.php?topic=113400.1180

I think Bitcoin Foundation needs a PR person. Developers in general suck at PR, they're to narrow minded and too tech focused to understand the needs of ordinary users and the ordinary public.

(This is no attack on the devs, which are doing an excellent job - it's just a realization of how reality is, and what we should do)

I don't think it's an attack....  I happen to agree completely.

659  Bitcoin / Project Development / Re: [ANNOUNCE] Bitmessage - P2P Messaging system based partially on Bitcoin on: March 28, 2013, 04:29:09 AM
Website visits spiked up by more than an order of magnitude due to some online articles.. and a also single comment on a Slashdot article about FBI spying. I had to take my BM address off of the homepage because I was getting a message about every 2 minutes.. mostly in Russian.

Better get multiple streams working.  And maybe a test network...

660  Bitcoin / Legal / Re: I just got off the phone with FinCEN on: March 27, 2013, 11:53:31 PM
Does anyone even know if registering with fincen is even that much of a hassle? There are no fees or anything. Do you even need to collect info for smaller transactions?

There are no fees at the federal level, but you must have a "compliance officer" (who is not you) and many other rules that, if skipped, can land you in jail.
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 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 ... 162 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!