if we are doing a hardfork anyway would lightening transactions help alleviate some of the spam attacks by creating instant transactions through locktime/multisig? Thus those that are attacked because they cant get their tx through for days can use lightening tx?
LN would be opt- in I suppose, so if an attacker want to hit the block chain directly there's no way to block him, the Bitcoin network is open afterall. You could put in place mechanisms/incentives to dissuade those attacks, but they have to be at the protocol level I think (increase the dust fee threshold, remove tx priority based on coinbase age, ...). |
|
|
|
@sickpig:
Maybe a scheme could be worked out where XT and QT would each have their own set of core dev consensus, with only a partial overlap of core devs between the two?
It could be a solution If all the parties involved are able to get a "consensus" around this plan. No pun intended. I'm not good at making estimates but I'd not giving an high success probability to this solution. I could be wrong, though. |
|
|
|
It shouldn't need years of engineering studies to understand that there's no real technical discussion going on between the various sub-camps in the developer's camp.
So your take is that devs are going full "political" rather than technical? (serious question) If yes, what's the way to unlock this impasse? Given the deadlock, I honestly start to think it might be good to do a 'divorce'. As in, we actually agree to disagree, and all see that there are fundamentally incompatible opinions with regards to the direction of Bitcoin. But we can keep it friendly. This might be less damage/cost than having a hardfork battle solving it in January 2016. That way we can avoid the fighting and truly let the market work out the rest. We divide up the common assets of the web sites, code repos etc. between Bitcoin/QT and Bitcoin/XT. Make it clear that Bitcoin is now two Bitcoins, and that the user has to decide. QT and XT simply seem like two people who shouldn't be married. Better have a clean divorce than endless fighting. Thoughts? If XT hadn't been a MIke Hearn's creature I would have said 100% yes. My gut feeling and few facts that I gather along the way (mainly red-listing, but also having decreased dust fee request https://github.com/bitcoin/bitcoin/pull/3305), make me think that way. But all in all yes, by definition to resolve a deadlock you need to change the policy that have regulated the process since. I'm still hoping that the situation will be solved without the need of a "schism", though. Mind you I think that more implementations of the bitcoin protocol (modulo the consensus rules that has to be enforced by the same library for all the clients) is an healthy thing to have, but that's not the case unfortunately. |
|
|
|
It shouldn't need years of engineering studies to understand that there's no real technical discussion going on between the various sub-camps in the developer's camp.
So your take is that devs are going full "political" rather than technical? (serious question) If yes, what's the way to unlock this impasse? |
|
|
|
Who ever have put in place this DoS is extremely persistent: Unconf Txs: 30202
Fees: 1.04549825 BTC
Mempoll Size: 73600.9267578125 (KB)
|
|
|
|
Jeff Garzik has just posted 2 pull requests for bitcoin core on github: https://github.com/bitcoin/bitcoin/pull/6405Remove TX priority and free transaction area from mempool, block creator.https://github.com/bitcoin/bitcoin/pull/6402 Floating network relay fee increase, if memory pool grows too large.the latter will introduce, if merged, "a relay fee that adjusts to floods which cause the memory pool to grow too large". It seems that core devs start becoming aware of the lack of of economic incentives for services provided by full nodes. |
|
|
|
Rusty's rocking, really. http://rusty.ozlabs.org/?p=515"Bitcoin Core CPU Usage With Larger Blocks"http://rusty.ozlabs.org/?p=522The Megatransaction: Why Does It Take 25 Seconds?from the latter: This problem is far worse if blocks were 8MB: an 8MB transaction with 22,500 inputs and 3.95MB of outputs takes over 11 minutes to hash.
If you can mine one of those, you can keep competitors off your heels forever, and own the bitcoin network… Well, probably not. But there'd
be a lot of emergency patching, forking and screaming…
(emph is mine) |
|
|
|
Bitcoin sits at a strange intersection of computer science, mathematics, economics and sociology, and we can all probably learn a bit from each other. Communication is hard, especially across disciplines.
Thats quite fair and true. As an aside, today's 3 block invalid chain reorg included a 'v3' block on the invalid fork which contained a lot of transactions. Which may suggest someone is SPV mining while including transactions (something I'd pointed out was possible previously). If I may ask, what were the pools involved in this reorg? found the list: https://en.bitcoin.it/wiki/July_2015_Forks#Invalid_Block_Hashesthose are the one related to July 5th reorg (from 21:50 to 23:40): - 000000000000000003ae1223f4926ec86100885cfe1484dc52fd67e042a19b12 mined by MegaBigPower (255 non-coinbase transactions)
- 00000000000000000063f97f292fb559773437fb3558c474efec6053a7b0d5a2 mined by an unknown miner (0 non-coinbase transactions)
- 000000000000000012dbd422d7bf1c4b55982c37b390d4613dcee00d31741c6a mined by an unknown miner (1,597 non-coinbase transactions)
|
|
|
|
Bitcoin sits at a strange intersection of computer science, mathematics, economics and sociology, and we can all probably learn a bit from each other. Communication is hard, especially across disciplines.
Thats quite fair and true. As an aside, today's 3 block invalid chain reorg included a 'v3' block on the invalid fork which contained a lot of transactions. Which may suggest someone is SPV mining while including transactions (something I'd pointed out was possible previously). If I may ask, what were the pools involved in this reorg? |
|
|
|
interesting, isn't it? We will continue do SPV mining despite the incident, and I think so will AntPool and BTC China.
Another very good reason people should not mine on Chinese pools. This is EXTREMELY bad for the Bitcoin network. |
|
|
|
The fork is now resolved. Six blocks were orphaned resulting in a loss of ~100 BTC to F2Pool. Rather good incentive for F2Pool to update their software for proper BIP66 support so this doesn't happen again! since BIP66 has been activated only after 95% of the last 2k blocks was v3 blocks, it means f2pool already has produced BIP66 blocks before the incident, in fact last time I checked f2pool had ~20% of the total hashing power. so by definition f2pool was BIP66 compliant before the fork. the problem is that a lot of miners are "SPV mining", among them: f2pool and antpool This is not quite true. It's important we understand exactly what happened to prevent people from spinning this incident to strengthen their blocksize limit position. Here's what happened: - BTC Nuggets mined block #363,731. It was not BIP66 compliant. - F2Pool began mining on this block before they had validated its contents (SPV mining). - F2Pool should have orphaned block #363,731 as soon as they realized it was invalid. - However, F2Pool kept mining on this invalid block. - F2Pool hit a lucky streak and mined two more blocks (#363,732 and #363,733), pulling this invalid chain further ahead. - AntPool seemed to act similarly, and mined block #363,734 ontop of the invalid chain. - F2Pool quickly mined two more blocks on this chain (6 confs). - Finally, the rest of the network "pulled ahead" (the valid chain became longer) and F2Pool and AntPool finally orphaned their invalid chain.  The incident was not caused by SPV mining for the few moments it takes to validate the latest block. It was caused by F2Pool (and AntPool) never getting around to actually validating the blocks. sure you're right. they kept SPV mining for six blocks in a row, and if you ask me they would had continued if the network didn't pulled ahead. this means that their patched btc core was/is able to produce valid blocks, but didn' t validated any prev block whatsoever. this SPV mining habit has to fixed, otherwise we risk to have this kind of incident every time a softfork is activated by mining vote. another think to focus on is the number of full nodes that had discarded those 6 invalid blblocks i.e. the percentage of btc core with version >= 0.10.0 |
|
|
|
The fork is now resolved. Six blocks were orphaned resulting in a loss of ~100 BTC to F2Pool. Rather good incentive for F2Pool to update their software for proper BIP66 support so this doesn't happen again! since BIP66 has been activated only after 95% of the last 2k blocks was v3 blocks, it means f2pool already has produced BIP66 blocks before the incident, in fact last time I checked f2pool had ~20% of the total hashing power. so by definition f2pool was BIP66 compliant before the fork. the problem is that a lot of miners are "SPV mining", among them: f2pool and antpool |
|
|
|
Rather good incentive for F2Pool to update their software for proper BIP66 support so this doesn't happen again! Maybe it's a good time to start talking about enabling fraud proofs that would allow SPV clients to reject invalid blocks. This. The problem is that miners, or at least a large part of them, SPV mining i.e. they mine on top of previous block without performing full validation on it. In this case even if you were mining along with the lastest version of Bitcoin core you would have been vulnerable. |
|
|
|
The PSA that marcus_of_agustus did in looking into the pseudo-fork of XT a while ago was quite interesting to someone who is technical and familiar with constructing software and I, for one, thank him for the effort.
It would be good to have a pointer to this work, I'm very interested in. I did a quick manual scan of his posts and ran across this: https://bitcointalk.org/index.php?topic=1081412.msg11546556#msg11546556Normally one is pretty careful to fork in a particular way in a revision control system as they tend to have methods for analyzing 3-way diffs and such. Typically that is what one wants in order to understand the code more easily. The converse is true as well. I think MofA did a post on this thread also and mentioned that one of the bug fixe roll-backs was the re-addition of pkg.m4 or some such. m4 is a fairly powerful macro package widely used in software construction tools. (autoconf uses m4 macros to construct a portable shell script normally named 'configure'.) This one apperently influence how code under construction finds libraries for inclusion or use. Typically when code is compiled, much of it tends to come from external libraries. This can be done with various kinds of linking. Unless one is paying close attention, it is possible to be linking against libraries that one doesn't even know exist on a system. In a general sense this is a very common cause of some of the worst security failures over the years. One of the most pernicious aspects of such a failure is that the source code can be entirely clean and innocent but compiled in might be some bad code that one didn't even know existed. The danger is, presumably, why pkg.m4 was removed from core. thanks for the link and the analysis. I was aware that XT wasn't a proper fork and even of the m4 re-addition (*). I was hoping for something more detailed, though. Especially because XT is not a git fork and so it's not so easy to track changes. (*) About the latter I have always wondered how they are able to produce reproducible builds when you they have to link binary to external dyn libraries |
|
|
|
The PSA that marcus_of_agustus did in looking into the pseudo-fork of XT a while ago was quite interesting to someone who is technical and familiar with constructing software and I, for one, thank him for the effort.
It would be good to have a pointer to this work, I'm very interested in. |
|
|
|
so b/c a book size tx is non-std, the only way to get it into a block is for a miner to self mine it into his own block. and, in today's situation, if a pool miner operator is caught doing that on a regular basis, his constituent hashing miners would leave him en masse.
therefore, this isn't a problem long run.
I'd say that 100k is quite big and valid. anyway I'll take a look at the "Infamous" book tx to see who mined it. |
|
|
|
that said I was wondering if another thing we could do is limiting max tx size. Did you rember that no more than a one or two months ago Peter Todd said that chain someone put an entire book on the blockchain?
maybe not an absolute limit but a progressive fee per kb... just a thougth.
can you explain the technicalities of that attack? was it only possible b/c of p2sh? also, did it only involve a non standard tx? if so, isn't that only something that a miner could include into a block he self generates? and why haven't we seen widespread usage of that attack if it's so effective that we have to worry about it? nothing special actually, borrowing from here http://bitcoin.stackexchange.com/a/25292There is a maximum standard transaction size since Bitcoin 0.8.2 of 100k per transaction.
There are a number of other limits that influence the validation and propagation of a transaction though. Specifically:
A block is limited to 20000 signature verifications.
The block itself can't be larger than 1Mb.
The standard Bitcoin client (Bitcoin Core / bitcoind) will refuse to relay transactions flagged as dust.
Enough fee should be included (0.0001 BTC/kb)
emph on standard is mine. not standard != invalid. so there's not a direct limit to tx max size. I'm not expert enough to get all the details, though. if memory serves in ptodd's git hub repo there's a python script that let you leverage those weak limits to fill the block chain with data (a lot of), maybe it even try to minimize the fee amount. that said what I'm proposing is to increase the fee per KB progressively. e.g. the first 100 KB will cost you X satoshi each, from 100 to 200 X*2 etc etc you could use whatever's monotonic increasing function you see fit. but maybe I'm too naive and this is wishful thinking, maybe as soon as the block space will become more scarce the market will take care of the problem automatically |
|
|
|
dammit. here we go again upon just checking. unconf tx's over 7000:  any chances of an on going stress test ? i doubt it as yesterday's scheduled test didn't conform to it's stated plan. and really, does it matter? how can you tell in most circumstances unless spam tx's are coming from a single address? and if the tx's are paying the regular fees, which they are, who cares? the miners will make hay and be more profitable. actually, i do care b/c that means ordinary users that might square the network effect (Metcalfe) wanting in from places like Greece might not be able to get in. yes, the 1MB'ers will say that they're just coming in thru places like Coinbase, which they are, but i'd counter argue that in the medium to long run Coinbase has to buy supply from the mainchain to keep their reserves high. so it does feed through. I agree, I've asked only because I know you're active on reddit, that usually is a better source for this kind of events. that said I was wondering if another thing we could do is limiting max tx size. Did you rember that no more than a one or two months ago Peter Todd said that chain someone put an entire book on the blockchain? maybe not an absolute limit but a progressive fee per kb... just a thougth. |
|
|
|
dammit. here we go again upon just checking. unconf tx's over 7000: any chances of an on going stress test ? |
|
|
|
"this Rusty guy" is https://en.m.wikipedia.org/wiki/Rusty_Russellto make a long story short he wrote Linux kernel packets filtering system ipchains/iptables (aka Linux firewall), lguest virtualization system (ancestor of docker/lxc) and contribute to samba/cifs (a way to let Linux and ms win talk together), just to name a few. edit: fix misattribution about samba/cifs projecf no, i know who he is. i like his independent spirit. just want to be sure  he's even still maintaining some linux's kernel subsystems: LGUEST
M: Rusty Russell <rusty@rustcorp.com.au>
L: lguest@lists.ozlabs.org
W: http://lguest.ozlabs.org/
S: Odd Fixes
...
MODULE SUPPORT
M: Rusty Russell <rusty@rustcorp.com.au>
S: Maintained
...
PARAVIRT_OPS INTERFACE
...
M: Rusty Russell <rusty@rustcorp.com.au>
L: virtualization@lists.linux-foundation.org
S: Supported
maybe the above lists is a little bit out of date (as quite frequently happens with doc and meta info files contained in the linux's kernel tree), but this pull request regard another subsystem (pinctrl) and it is as recent as today: http://www.spinics.net/lists/kernel/msg2022752.htmlimpressive. |
|
|
|
|
Show Posts
