Bitcoin Forum
May 04, 2024, 12:32:25 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 »
1  Bitcoin / Development & Technical Discussion / Re: Segwit and the fork on: June 21, 2017, 08:18:09 PM
I'm sure some people will say that SegWit/BU must be activated hard way even with risks chain split, community split, price crash or other else.
I also think that we might have to think that option, especially if tx fee become very high, there's altcoin which have at least 50% of bitcoin market cap or when the community tired with drama.
I wouldn't mine too much, as I recently wanted to pay something rather small in Bitcoin and was discouraged by the insane fees and I really think something must be done about this, or some altcoin will take over at some point.
But an advance notice would be nice: I have some bitcoins in trading platforms, and I'd prefer them to be in my wallet if and when a split happens...
2  Bitcoin / Development & Technical Discussion / Re: Segwit and the fork on: June 20, 2017, 06:13:14 AM
On August 1st there will be user induced soft fork. So your Bitcoin will split into two parts maybe somehow.
Are we sure it won't happen earlier though?
Here I read "Activate the New York Consensus SegWit2 by July 31", does it mean the fork will happen on July 31 or that it can happen way earlier, considering SegWit2 already has 75% of blocks in the last 24h?
3  Economy / Exchanges / Re: What happened to Poloniex? on: May 14, 2017, 07:31:00 PM
Yes same here, I've had nothing returned for 19hrs to-date, but I'm not sweating about it at the moment.
I've actually just received a return moments ago Smiley
4  Economy / Exchanges / Re: What happened to Poloniex? on: May 14, 2017, 08:56:26 AM
Anyone else has bitcoins on loan there that still haven't been returned although they should have? (talking about a few hours late, so far)
5  Bitcoin / Hardware / Re: Bitmain's Released Antminer S9, World's First 16nm Miner Ready to Order on: August 19, 2016, 11:27:13 AM
Is it possible to modify the clock frequency of the S9? (I'd be interested in underclocking it)

yes you can.
Ah, silly me it's in the manual indeed:
https://www.bitmaintech.com/files/download/AntMiner%20S9%20Installation%20Guide.pdf

However they only indicate 550MHz / 600MHz / 650MHz. Are those the only options or could I enter, say, 333 MHz ?
6  Bitcoin / Hardware / Re: Bitmain's Released Antminer S9, World's First 16nm Miner Ready to Order on: August 19, 2016, 11:07:28 AM
Is it possible to modify the clock frequency of the S9? (I'd be interested in underclocking it)
7  Bitcoin / Development & Technical Discussion / Re: Bitcoin - endless pending transaction on: March 02, 2016, 09:47:35 AM
I also have a small mysterious pending transaction that does not seem to exist on the blockchain, since upgrading.
I just upgraded I had the same issue with an accidental double-spend I made a while back. Somehow the client created the transaction I wanted to do twice, one went through and the other was marked as "error" in my transaction list... until this update which marked it as pending. Rescanning did the trick for me too.
8  Bitcoin / Pools / Re: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool on: January 20, 2016, 10:03:30 AM
Do you think a regularly-updated VM image would help promote pickup ?

I'm thinking something pre-configured (with the exception of the bitcoin wallet and payment address which will be created once the VM starts)

I don't think it's necessary to go this far. Some more details in the step-by-step instructions, so that they work without assuming the user's setup is 100% default would be enough.
For instance, the instructions on http://p2pool.in/ might work for a user with a default setup (data folder for Bitcoin Core not modified) and who doesn't care about not knowing where the mined BTCs will arrive, but it's not enough for a user who moved around their data folder or wants to specify at the pool level the address where to receive BTCs. Also, it's not the case for me but maybe instructions to use a custom port (+/-IP) for Bitcoin RPC would be useful too.
9  Bitcoin / Pools / Re: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool on: January 20, 2016, 09:27:24 AM
run_p2pool.exe me youwish -a yourbitcoinaddress

EDIT: lack of concentration
Thanks, the logs looked better this way (tries to connect with the proper rpcuser, at least)... but still failed.
I ended up running
Code:
run_p2pool.exe --bitcoind-config-path "C:\thisway\to\bitcoin.conf" -a myrichwalletiwish
which finally worked
10  Bitcoin / Pools / Re: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool on: January 20, 2016, 08:52:08 AM
I think the reason so few people use it is because, years after the first release, it's still so complicated to set up.
I did configure Bitcoin Core to run that RPC server, here's bitcoin.conf:
Code:
server=1
rpcuser='me'
rpcpassword='youwish'
Then tried to run run_p2pool.exe, but could find no option to configure the rpcuser there. And of course it failed.

In the log I noticed:
Code:
Testing bitcoind RPC connection to 'http://127.0.0.1:8332/' with username ''
So I went back and set rpcuser='' in bitcoin.conf
And I ran p2pool again this way:
Code:
run_p2pool.exe -a myrichwalletiwish youwish
And still it didn't work. So I went back to a normal pool, because I have other things to do today.........
11  Bitcoin / Development & Technical Discussion / Re: Voting for block size increase proposals on: September 16, 2015, 05:46:48 PM
Thanks, I got it now. I got confused because your interface at coinarchy.com doesn't allow copy/pasting the signed text without clicking some buttons first.  Grin
I hope many people vote: even if the decision isn't necessarily decided straight from the poll, that would at least help to have an overview of what the community prefers.
12  Bitcoin / Development & Technical Discussion / Re: Coalition For 8MB on: September 16, 2015, 01:34:17 PM
After giving it a second thought, I think that "accelerated programmed 2-4-8" you mentioned might be the best way moving forward.
[...]
Smaller static limit (like 2MB) would necessitate having this discussion again fairly soon. In the constant debate about the issue we may begin melting the idea of the limit and instead achieve a diametrically opposite result (no limit at all).

All things considered, the solution space has been reduced to a single static limit of 8MB with a gentle yet quick enough schedule to achieve it. QED Smiley
In my experience, whenever you give away space and resources, they end up being fully consumed pretty fast even if things used to work with a small fraction of said space and resources before. Bitcoin works nice even with the current limit: I can still send fee-less transactions and they get processed usually in a few hours. Increasing to 2MB should be good enough for a while. I fear giving 8MB straight away would encourage people to just use up all that space immediately. A good rhythm could be to increase to 2MB, then when it seems not enough again, increase by 1 more MB, etc, etc. And hopefully before it gets totally out of hand we'll have a better way to handle the blockchain than trying to fit 5TB into the users' SSDs....
13  Bitcoin / Development & Technical Discussion / Re: Voting for block size increase proposals on: September 16, 2015, 01:22:07 PM
I suggest the following message syntax for voting anywhere in the internet for any BIP published on https://github.com/bitcoin/bips

The syntax is:
Code:
#BITCOINVOTE {vote version} {bitcoin address} {+|-|=}{BIP id} {+|-|=}{BIP id} ...
{signature}

For example:
Code:
#BITCOINVOTE 201508251200 12WRTDrnLy7FMHj8b4kNWPJgnDfseTK6cX =BIP100 +BIP101 -BIP102
H1TmFhlXT8vPnbWsLWDPs2qbWRWA1htZIuCd/Avts/OzaVsWfWcIzfOCqO9w/FmnQEkjve8UU4kZtEtoIN1CpEg=

[...]
Current results

BIP101  +2600.00 / -122.87
BIP100  +22.87 / -0.00
BIP102  +0.00 / -121.00
BIP103  +0.00 / -121.00
BIP106  +0.00 / -2600.00
Don't know if it's because I'm particularly clueless, but where should that signed message be posted? I see there are already some results so there must be a way, only it seems well hidden....
14  Economy / Investor-based games / Re: BTC-Flow.com ★ Business Ponzi Game ★ 300%+ Return ★ Invest BTC ★ Referral on: February 20, 2015, 09:55:07 PM
withdrawal why minimum 0,01 btc? wtf, dude?!
Penny whore complaining about free bits. Awesome.
No I think the problem is much more serious: I've been racing against the payout threshold since I registered (first no minimum, then I believe 0.00005000, then 0.001, now 0.01). I assume whenever I'll get close enough to 0.01 it will raise again. Feels like free users never get to catch the carrot while this lasts...
15  Economy / Micro Earnings / Re: Anonymous Ads v2 - earn ɃɃ with your site OR use ɃɃ to advertise! on: March 01, 2014, 10:11:55 AM
I vote for minimum withdrawal 0.0001 BTC! Its great news
Seriously? 0.0001 BTC? Bloody dust....
On a side note, AGES ago (like, before the launch of v2), I suggested that all payouts to a same address (for people with several units with the same address) be merged. Well, this still doesn't exist, and after 3 months without payment I just received 3 payouts at the same time, one ~0.01 BTC and 2 others ~0.0001 BTC. Why not merge those instead of spamming our wallets? (yes, 3 transactions in 3 months isn't exactly spam, however, while 3 transactions of ~0.004 BTC each at one per month would be acceptable because we get funds security in exchange for the increased amount of smaller transactions, nothing for 3 months then suddenly 3 transactions at the same time isn't)

For me the ideal system would be like:
- merge all payouts to the same address (seriously... you can program geotargetting and quite advanced, great campaign options, but not a trivial payout aggregation?)
- minimum payout 0.01 BTC or once per month if >= 0.001 (+/- option to set this to once a week if >=0.0001 because some impatient idiots seem to be ready to pay 50% tx fees to spend their earnings - 0.0001 BTC is worth like 6 cents, FFS)
- no more than one payout per 24h except if >0.10 BTC
16  Economy / Service Discussion / Re: MTGOX Withdrawal expectation on: April 19, 2013, 04:30:35 PM
I understand where are you coming from, but let's say you selling me a stolen car.
To be fair, I don't care, how you going to do it, which way you going to come to the deal, all I am interested if that you say I will get you a stolen car in 2 months time to stick to the promised date.

I would like to emphasize that I would not have any problem with the whole transaction if they would say the payouts for EUR is 14 day max. (because we have difficulties getting the money out or whatever.)
My issue was that there is no explanation provided why it is taking 2 days to deposit, but 14 to withdraw.

But hey. I can live with it. Wink
Oh. I quite agree about those outrageous delays (5 days for my latest deposit, hurray...). Plus the weird fees (I deposited several times the same amount, from the same bank, fees were never the same...... once there was even no fee at all). With performances like this I'm not sure they deserve the whopping 0.6% fee on all trades...
17  Economy / Service Discussion / Re: MTGOX Withdrawal expectation on: April 18, 2013, 10:39:20 AM
Actually I have to say that I have my money now, so no issue there, But we have to remember, that BTC is dodgy, nobody regulates it, nobody regulates the exchanges, the payouts, anything.
So this is the liability we have to take with it.
Yes and no. I think I trust MtGox more than their bank. Sure, they are (very) late in processing the payments, but I feel like the main liability is in their bank more than in them. That's quite subjective though, but they're the market leader and they practice fairly profitable fees, so I don't think it would be their interest to go rogue while business is already working so well. Their bank, on the other hand, is an easy target for the authorities who would like to "regulate" Bitcoin.
18  Economy / Service Discussion / Re: MTGOX Withdrawal expectation on: April 18, 2013, 06:57:20 AM
What I hate, is that the processing is no more than 3-5 days when you send money to your Gox account. They say that they have to "process" the transfers.
That's already much too long, if you ask me. Sent a deposit recently to both MtGox and Bitstamp at the same time. Bitstamp was credited within 36 hours. Gox is still waiting, that's 4 days now... Maybe they give higher priority to larger transactions...
19  Economy / Trading Discussion / Re: Why Bitcoin crashed on: April 12, 2013, 06:09:03 AM
You can call it a "correction"....or a "table" or a "chair" or a "puppy dog" if you really want to, but that doesn't help with communicating with the rest of the world that considers a 75% drop in value in one day to be a CRASH....LOL

And it doesn't matter if it goes to $300 by the end of the year, it still crashed the last couple of days... at least according to 99.9999% of the people out there.  You have a right to believe otherwise if you want though (and redefine common terms).
Well, compare the value with what it was a month before and let's see where the crash is. Maybe it crashed for day-traders, but for people who use BTC in the long run, it didn't.

This one is more damaging I think. Mtgox taking the market hostage, not cool.
20  Economy / Trading Discussion / Re: For me MtGox is Dead, where shoud I adquire Bitcoins? on: April 11, 2013, 09:51:49 PM
I guess there's also http://bitcoin-otc.com/ , although I'm not really a big fan: many people here ask the mtgox price + some percentage for some reason, while IMO it should at worst be the same price, since it has no fees... Once there was even a guy who was like begging to sell about $15 worth of BTC, and when getting into the details he asked for a fee (additional to the PayPal fee). WTF, he's the asking party yet he wants to make profit. That's how ****ed up BTC-OTC seems to me. Haven't been there in a long while though. I still like how OpenPGP-ish it is, though.
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!