Bitcoin Forum
June 22, 2021, 07:55:19 PM *
News: Latest Bitcoin Core release: 0.21.1 [Torrent]
  Home Help Search Login Register More  
  Show Posts
Pages: [1]
1  Bitcoin / Mining / Miners support for hardfork in Coinbase? on: January 21, 2016, 11:08:55 AM
I was thinking about a way to clarify current heated and politicized blocksize debate. Simple statements about different levels of support encoded in coinbase would be helpful and would allow predictable conditions for various agents in Bitcoin ecosystem.
During BIP100 / 101 (XT), pools signed their coinbase "BIP100" if they preferred it. At the XT announcement, many block makers said they'd support XT but *never* made an XT compatible block.

Would something like this be possible today? There are of course lists about which pool support what branch (Bitcoin Classic, maxblocksize increase, Bitcoin Core, Roadmap, ...). But such lists are biased depending on the source, policies develop and statements from various representatives are fuzzy and sometimes contradictory.

We have several large pools, but despite this the mining is not centralized, because these pools are composed of large number of individual miners. Clear policy expressed in coinbase would be guide for these small miners where to (re)direct their mining power according to their opinions.

Base of my proposal (which is open to comments and suggestions) is this:
- four levels of support (active/passive/opposed) (+//-)
- Main branches as simple strings (Core, Classic, Unlimited, Roadmap, 1MB, 2MB, 4MB, 2-4-6, BIP10x).
- Strings signed by some simplified way, if possible

For example:
- String: "*Core+,Roadmap+,Classic,4MB-*" means:
  • Active support for Core and Roadmap (Our poll will generate blocks according to Core&Roadmap specification)
  • Passive support for Classic (We will not generate blocks according to Classic specification. However, we will build on them.)
  • Opposition to 4MB (We will never generate 4MB blocks and we will actively orphan such blocks - that is consider them invalid and inconsequential. No matter where this proposal comes from (included in Core, included in Classic) and which Developers support it.)
- String: "*Core,Roadmap(RBF)-,Classic+,4MB*" means:
  • Passive support for Core (We will consider <1MB blocks as valid)
  • Opposition to RBF (We will orphan/ignore blocks containing any RBF transactions as specified by Roadmap)
  • Active support for Classic (We will happily and preferentially generate 2MB blocks according to Classic specification. We will build on them.)
  • Passive support for 4MB (We will not generate 4MB blocks, but we will not ignore such blocks - We will reluctantly bulid on them.)

Of course strings can be more detailed (*SegWitCore-,SegWitClassic+,>1MB+,>8MB(until2018)-*). Interpretation would be matter of external actors (I think someone would probably create webpage for this.] But all interpretations would allow fallback to verifiable data for everyone.

As to the signing... I placed strings between two * symbols for a reason. I think this is the way they should be in coinbase followed by some simple signature. Reason for this: Any pool can pose as another pool (eg. BitFury can put "Slush" string in coinbase, Slush can put "Eligius" there etc.) and by this way fake statement of someone else. Simple privkey/pubkey pair where privkey signs *string* between ** and pubkey published on pools webpage/stated by trustworthy source/pool operator can solve this. Statements can also be signed by Bitcoin address publicly stated by pool in advance. But the signature should be short enough?! I do not have specific idea how to do this.

It would be nice if every pool would state several different (even contradictory) policies and open different addresses/ports for its hashers to "vote" on them a dynamically change their votes. Data analysis people would love this! But of course pool operators can express their policies by limiting the choice or not signalizing at all.

So...what do you think?
2  Bitcoin / Development & Technical Discussion / SegWit question on: January 19, 2016, 07:05:25 PM
I have read BIPs 141-144 about Segregate witness and I have a question about validity of SegWit "witnessed" tx for old (non-upgraded) nodes.
Non-upgraded nodes, however, will not see nor validate the witness data and will consider all witness programs as anyone-can-spend scripts.

So they consider such transactions as valid. But what if someone constructs SegWit-like tx (but without valid SegWit script/witness program). Non-upgraded node (eg. merchant selling goods) would see and accept such transaction as valid (and send goods to customer). But the majority of upgraded network would refuse such tx.
Is there any workaround (besides upgrading node to include segwit and besides waiting for several confirmations for all anyone-can-spend scripts)?
3  Bitcoin / Bitcoin Discussion / List of wallets, exchanges, pools and services NOT supporting hardfork ? on: January 19, 2016, 06:18:55 PM
I would like to ask for and rally information about Bitcoin interfaces, merchants and services who do not and will not (in near future) support hardfork of Bitcoin protocol.
Simply put: I mean online wallets, mining pools, SPV-Clients, exchanges, payment processors, etc. who currently support Roadmap as planed by Bitcon Core and do not support proposals by Bitcoin Classic (nor BitcoinXT, Bitcoin Unimited) to increase max block size by hardfork, (exclude RBF, change PoW mechanism...).
Meaning they will consider >1MB blocks invalid and transactions within such blocks as inconsequential. Meaning they will not produce such transactions and blocks.
I would like to divert my mining power and transfer my bitcoins to such services before Bitcoin Wars roundly erupt.

Please do not post just your speculation and/or wishful thinking about who supports what. Please refrain from judging and arguing which path for Bitcoin is "right" or "wrong" or what is "needed and necessary".
If you post information, include source and date of that information if possible. Keep in mind, that not opposing Bitcoin Core does not automatically mean (commitment to) rejecting 2MB hardforked blocks and resisting majority of miners. On the other hand, supporting Bitcoin Classic does not automatically mean enforcing it against dissenters and deliberate generation/preference of such blocks. So, for example, if exchange or online wallet favors 2MB blocks, but respects and guarantees that it will send you withdrawal in <1MB block (in a chain of transactions with no ancestor in 2MB block) if you wish so in the future, include it with this information.
Likewise, If mining pool transparently allows using different ports to commit mining power to strictly 1 MB branch then include this info.
4  Economy / Service Discussion / blocked my IP ? on: December 22, 2013, 11:46:02 AM
Hallo. Yesterday I did some more extensive requests to block explorer at by visualizing transactions. (Trying to map path of some hacked/stolen bitcoins in Czech republic last month.) However, it was all manual requests, although the branching path of transactions was quite complicated graph with many vertexes and edges.

Then suddenly it stopped working an I get message by Cloudflare: "Error 1006 Access denied" with the explenation: "The owner of this website ( has banned your IP address ()." I did nothing at first, hoping the ban will expire i few minutes or hours, but it is still in effect.
Have this happen to any of you? Will it "expire"? or shall I write to asking for details?
5  Economy / Service Discussion / Bitstamp requiring verification for BTC withdrawal? on: November 22, 2013, 06:25:50 PM
I have some bitcoins on Bitstamp. Maybe I missed something, but since when do you need verified account (hi-res scan of ID card, proof of residency, etc.) for Bitcoin withdrawals (and also for deposits)?
I remember that withdrawal of fiat needed verification, but not the deposit of fiat (you disclose your account number this way anyway). And requirement of such strict verification for bitcoin transfers (both ways) seems very unusual to me. Is this for real or is this just some temporary "error"?
6  Economy / Web Wallets / Now problems? on: April 12, 2013, 11:02:41 PM
I am getting strange error at block explorer. When I check some address or tx, result is: "Got error 157 'Unknown error code' from NDBCLUSTER".
Is it just me or do you have the same problem checking transactions?


Everything seems to be working now.

Edit: You can check your balances here:
Edit2: It seems that wallet is inaccessible as well. Embarrassed . I suggest no panic at this point as there is no evidence of anything lost.
Edit3: mintybit: "anyone can get hacked...  I would recomend that people NOT try to login to their wallets during this outtage because if some hacker has got control of the server, he could be trying to harvest your passwords in order to unencrypt your wallet, so just wait it out or make a new wallet and test with that one till it's working again..."
Darkpunk: "Their RPC server is down. I'm sure they will be back up in a few hours."
7  Other / Beginners & Help / Correction in block reward (bitcoin wiki FAQ) unnoticed? on: March 20, 2013, 09:54:06 PM
Hallo there.
Maybe this is not the right place to say this, but I have to start somewhere :-].
In there are carefully corrected previous values 50 BTC to actual 25 BTC. However, in the last section (Security) there is "...Each correct guess yields, at present, fifty Bitcoins, and as Bitcoins are presently...".
As FAQ section is definitely some kind of showcase for the Bitcoin, especially for newbies, it should be corrected. Maybe the string "fifty" should be coaxed similarly to the "50" value also elsewhere and everywhere in the wiki.

I have been studying&using Bitcoin for some time and today returned to basics (preparing to dive into original Satoshi paper), so I stumbled upon this.
Pages: [1]
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!