Hey ,i just needed funds urgently and i withdrew 1 day ago and it still say "to be processed"
i got a message that the funds has to be processed from COLD wallet ? i saw that alex was online 9 hours ago and i would like to ask him if this is what he does when a user needs coins urgently ? i have already mailed him ..
You created withdraw request 2015-09-13 16:17:54, it was processed: 2015-09-13 19:31:13. Which is around 3H. And I haven't got any emails from you. Regards, Alex. Hey, do you plan to re-open the sig campaign in near future ?
|
|
|
where can i watch the video replay
It was on youtube but it was later removed (along with the other talks for that session). The videos for all the other sessions have now been posted so this is the only missing session. Was there any talk about the BIPs, especially BIP 105 & BIP 106 in the whole session ?
|
|
|
BIP106: BIP 106: Dynamically Controlled Bitcoin Block Size Max Cap https://github.com/bitcoin/bips/commit/2e0d3412546e28da19c8ab6cc0056fc05542acac+===Proposal 1 : Depending only on previous block size calculation=== + + If more than 50% of block's size, found in the first 2000 of the last difficulty period, is more than 90% MaxBlockSize + Double MaxBlockSize + Else if more than 90% of block's size, found in the first 2000 of the last difficulty period, is less than 50% MaxBlockSize + Half MaxBlockSize + Else + Keep the same MaxBlockSize This appears to be the most dynamic and acceptable solution so far. I wish, you add it in the poll as well as in the OP with a short description.
|
|
|
The idea appears to be somewhat close to BIP 106.
|
|
|
Although he might not have much stake in Bitcoin I believe his opinion can be interesting for one or the other. https://np.reddit.com/r/ethereum/comments/380q61/i_know_this_may_not_directly_be_ethereum_related/crrofl6Hmm. I've been reading Thomas Sowell's Knowledge and Decisions and A Conflict of Visions lately, and his works have impressed upon me how decisions that are made by "ivory tower intellectuals" can often be problematic, as they deal with abstract symbols and are far away from the actual substance of the problems at hand and have little personal incentive to correct their thought patterns (the specific bias at hand is often, but not always, scope insensitivity), and I'm seeing some parallels to that here. If you look at the kinds of people that have opinions on this issue either way, you notice that the kinds of people in favor are businesses that are directly involved in serving thousands of actual customers, whereas those against are largely those with some kind of ideological interest. On the other hand, of course, you could argue that businesses just want to make a profit and don't give a crap about decentralization, and so a weaker blockchain actually benefits them because it lets them build more centralized add-on services on top (the description that Coinbase gave me when I interviewed them for bitcoin magazine back in 2013 was that they want to be "like Gmail on top of SMTP"). In this particular case, I am inclined to side with the businesses more, simply because mining is so centralized already that full node count is not going to be the weakest link in the system at least for another 1-2 orders of magnitude.
If you divorce the decision from its current political context and ask me "what is the optimal block size for a payments blockchain", then I would say exactly what I've done for ethereum: target a limit equal to 1.5x the exponential moving average of the current block size (with perhaps 0.1% replacement per block). Hence my judgement would be to ignore the short-term contingencies and go that way here as well.
On the third hand, yet another perspective is that given the existence of other more powerful blockchain technologies and the fact that even better ones will continue being developed, bitcoin's best chance right now may well be to keep its block size limited and target the niche of digital gold. If that is what Bitcoin users want, then they should keep the limit, and perhaps even decrease it. But if Bitcoin users want to be a payment system, then up it must go.
The bold part in his statement seems to be mostly implemented in BIP 106.
|
|
|
Payment has been made. The admin was really busy and could not send it sooner. Sorry for the delay Payment ID: 3baea50b4bc41686febd03963736ced75bc0951819c83ee2a8f4836502830e41
This thread will be updated if anything regarding the signature campaign changes
+1 Payment received. Thank you for organizing such a great campaign. Hope it re-opens. All the best.
|
|
|
Slots are available for all eligible ranks (Full Member and above).
Please let me know if I can join this campaign... Name: RocketSingh Posts: 842 (including this one) Activity: 504 Position: Hero Member Bitcoin address: 1Dk4Si2w8StdGVsMW7AYMchTf99NKdVec8 Profile link: https://bitcointalk.org/index.php?action=profile;u=316641
|
|
|
UPDATE: www.BitDice.me Signature Campaign will be paused for now. This means the current period(05.09.2015) will be paid for so no need to worry but the campaign will not continue into the new period. The campaign might re-open again in the future. This is one of the best campaign I have ever joined. I joined as a Full Member and now a Hero Member. I'll be wearing this sig for some time even after the campaign is over. Wishing all the best to BitDice.
|
|
|
Looking at the population of India, If bitcoins gets positive feedback even from the half of the population from Indians, I believe it would a win - win situation for the bitcoin community.
Half of the population of India can not sign their name and you expect them to support bitcoin. Good luck to day dreaming.
|
|
|
BIP 1xx is leading over BIP 101!!! That's incredible p.s. ah I know those sock-puppet theories... every BIP backer have them.
|
|
|
I have a suggestion and a question.
Suggestion: Get the text field and button center aligned under subscribe to our newsletter.
Question: Why Zebpay is not accessible from desktop ?
|
|
|
I would insist on implementing a decay function for the sake of spam control and to prevent gaming the system.
Assuming all your suggestions are implemented by OP, will Armory publicly come out in support of this proposal ? I am having a feeling that without support from any major player BIPs are just meaningless. Moreover, if the proposal is not from a core dev, it would get a hard time in getting even a BIP no.
|
|
|
Deflationary nature ? Ask those who bought @ 1000
|
|
|
Bitcoin is not like linux, which can have different flavor. It is a medium of exchange and a medium of exchange requires trust. If bitcoin splits, that would severely hamper that trust.
That is simply not true in my case. What is 'hampering trust' in my mind is the 'Free Shit Nation' gaggle of hangers-on who demand free transactions that are subsidized by others because that is how life has always worked for them. I would love to wave them goodbye and wish them the best on their bloatchain fork then be able to move forward building a rock solid and truly distributed foundation which would have a multitude of uses. Including, ironically, many opportunities for the 'Free Shit Minions' to get exactly what they are after. Seems you support the bidding of Tx fee to subsidize miners while block subsidy goes down. In that case, Proposal 2 of BIP 1xx might interest you. Personally, I am undecided about this. Because one of the reason many people got attracted towards bitcoin was very cheap or almost no transfer cost. For those who thinks the same may like Proposal 1 of BIP 1xx.
|
|
|
its not a bad idea to have different implementations of bitcoin competing, i think the alt coins do just that, and splitting bitcoin over this tiny detail is going to do lot more harm then good.
Bitcoin is not like linux, which can have different flavor. It is a medium of exchange and a medium of exchange requires trust. If bitcoin splits, that would severely hamper that trust.
|
|
|
I prefer what i've called "BIP 104" in the french section : BIP 104why dont you talk to gmaxwell and get a real bip-number assigned? anything else is just confusing. Have you submitted this to gmaxwell yet for bip number assignment? If you did, what was his response?
I did. On August 18, 2015 he said that normal procedure is to allow some time for discussion on the list and asked me to post the draft text as well. I did not have the draft text ready by then. As you'll see the draft ( https://github.com/UpalChakraborty/bips/blob/master/BIP-DynamicMaxBlockSize.mediawiki) was made on August 24, 2015. So, after posting the draft text, I contacted him again for BIP no. Since then, I have not heard of him.
|
|
|
what do you think could blockstream gain with that move / BIP 100? also it was "just a" recommendation and jeff is not working for blockstream. @ArticMine yes. but more than 1.04 MB in 2020 like someone proposed They'd most likely try to push BIP 103 in scalingbitcoin. BIP 100 is their last resort to honor the 21m they have taken. That is why they are not allowing any other BIP to come into picture.
|
|
|
Difficulty is unpredictable as well
But it just affect the business of the miners and not anyone else. The block size instead change fees and confirmation time. Both directly influence deeply the day by day decisions of the Businesses on the Bitcoin network. Difficulty does not affect fees, but definitely affect confirmation time. Every 2016 blocks it re-adjust itself to keep the average to 10 minutes. This is similar to what proposed in this proposal to adjust maximum block size cap.
|
|
|
As I sait elsewhere, BIP100 is bad for the market, because it add unpredictability, by giving votes to the miners.
The market needs fixed rules that it must know years before.
The majority of the businesses will just move elsewhere.
Exactly. Unpredictability is a very bad feature for a coin. Difficulty is unpredictable as well. That is not the problem. The problem is miners (effectively pool operators) are getting super power in block size decision, irrespective of Tx volume in mempool, which represents market demand. BIP100 doesn't sit well with me, seems to grant far too much power to miners. Would much rather see this proposal instead. It's adaptive, so the blocksize can increase or decrease as required, based on what the network is actually using. Exactly. My vote goes for this proposal as well. But, it seems core devs are intentionally ignoring it to provide any BIP no.
|
|
|
i guess you are right, it cant pass 32 MB.
Not only that. It gives all voting right to pool operators. End users have no right to exercise. Size of mempool needs to be considered. My vote goes for this proposal.
|
|
|
|