justusranvier
Legendary
Offline
Activity: 1400
Merit: 1013
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 05, 2015, 07:51:53 PM |
|
Somebody is buying a lot of bitcoins today.
|
|
|
|
molecular
Donator
Legendary
Offline
Activity: 2772
Merit: 1019
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 05, 2015, 08:09:36 PM |
|
Somebody is buying a lot of bitcoins today.
I think it's at least 2 guys.
|
PGP key molecular F9B70769 fingerprint 9CDD C0D3 20F8 279F 6BE0 3F39 FC49 2362 F9B7 0769
|
|
|
cypherdoc (OP)
Legendary
Offline
Activity: 1764
Merit: 1002
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 05, 2015, 10:30:27 PM |
|
I have a feeling that fiber (eu) and equities are going to rally hard on a grexit... Makes sense cause we still haven't hit our long term target and makes sense from a market perspective too.
i don't think so: ![](https://ip.bitcointalk.org/?u=https%3A%2F%2Fi.imgur.com%2F0D70fJ4.png&t=665&c=aX2cjNYpbfH6KA)
|
|
|
|
|
cypherdoc (OP)
Legendary
Offline
Activity: 1764
Merit: 1002
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 05, 2015, 11:49:07 PM |
|
I have a feeling that fiber (eu) and equities are going to rally hard on a grexit... Makes sense cause we still haven't hit our long term target and makes sense from a market perspective too.
i don't think so: ![](https://ip.bitcointalk.org/?u=https%3A%2F%2Fi.imgur.com%2F0D70fJ4.png&t=665&c=aX2cjNYpbfH6KA) in case you hadn't noticed; we saw all sorts of these types of gap downs back in 2008. absolutely no chance to get out.
|
|
|
|
thezerg
Legendary
Offline
Activity: 1246
Merit: 1010
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 05, 2015, 11:54:05 PM |
|
Very dangerous. ECB could respond by claiming all Y series notes not legal tender. Of course greece could presumably print other serial numbers easily. And it could invoke the nuclear option where all greek overseas bank accounts are frozen and ultimately confiscated. Where is qoute about double txn validation? Should be unnecessary...
|
|
|
|
cypherdoc (OP)
Legendary
Offline
Activity: 1764
Merit: 1002
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 06, 2015, 12:15:39 AM |
|
Very dangerous. ECB could respond by claiming all Y series notes not legal tender. Of course greece could presumably print other serial numbers easily. And it could invoke the nuclear option where all greek overseas bank accounts are frozen and ultimately confiscated. Where is qoute about double txn validation? Should be unnecessary... but Euros are fungible, are they not?
|
|
|
|
thezerg
Legendary
Offline
Activity: 1246
Merit: 1010
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 06, 2015, 02:02:35 AM |
|
Very dangerous. ECB could respond by claiming all Y series notes not legal tender. Of course greece could presumably print other serial numbers easily. And it could invoke the nuclear option where all greek overseas bank accounts are frozen and ultimately confiscated. Where is qoute about double txn validation? Should be unnecessary... but Euros are fungible, are they not? They aren't exactly the same so there's a tiny possibility to break fungibility. Any serial # beginning with a Y was printed by the Greek central bank... other countries could give their citizens 1 week (say) to exchange any Y notes that made it across the border for equivalent value. You'd show up at any bank (say) with photo ID and the bills. Of course the press in Greece could probably be modified to change serial numbers pretty easily...
|
|
|
|
laurentmt
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 06, 2015, 02:39:22 AM |
|
miners will pare down block sizes for maximum verification times and propagation times.
I agree that it could be a positive outcome but I "prefer" my option for 2 reasons: - The theoretical reason: there's no solution faster than no validation - The practical reason: from the recent fork, we can see that some (many ?) mining pools prefer no validation than paring down block sizes (e.g. F2Pool mines small or big blocks).
|
|
|
|
cypherdoc (OP)
Legendary
Offline
Activity: 1764
Merit: 1002
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 06, 2015, 03:03:36 AM |
|
miners will pare down block sizes for maximum verification times and propagation times.
I agree that it could be a positive outcome but I "prefer" my option for 2 reasons: - The theoretical reason: there's no solution faster than no validation - The practical reason: from the recent fork, we can see that some (many ?) mining pools prefer no validation than paring down block sizes (e.g. F2Pool mines small or big blocks). what's interesting is that we've never seen it done to the degree it is now. we had the Mystery Miner a few years ago but he stopped it pretty quick. also, despite many upgrades added to the protocol previously, we've never had a fork as a result of SPV mining before either. what's different this time is the consistently full blocks and the fact that Wang Chun told us they create SPV blocks in response to large blocks as a defense. it seems they consider full blocks large blocks so the excessive SPV mining created last nights fork in light of BIP66 and the upgrade to 0.10.x. so in that sense, the 1MB cap is the direct cause of what is happening.
|
|
|
|
|
TPTB_need_war
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 06, 2015, 04:13:55 AM |
|
Somebody is buying a lot of bitcoins today.
I think it's at least 2 guys. Or maybe death and taxes.
|
|
|
|
gmaxwell
Staff
Legendary
Offline
Activity: 4242
Merit: 8653
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 06, 2015, 04:40:08 AM Last edit: July 06, 2015, 04:58:44 AM by gmaxwell |
|
ok, we've all been lead to believe up to now that validation of tx's had to occur twice by full nodes. first, upon receipt. second, upon receipt of the block. this was crucial to the FUD scare tactic of decrementing [...] what am i missing?
Where I expicitly pointed out to you in many places, in excruciating detail, that this was not at all the case?? https://www.reddit.com/r/Bitcoin/comments/39tgno/letting_miners_vote_on_the_maximum_block_size_is/cs6rek5?context=3 You seemed so happy to argue with it before, has your memory vanished now that you don't think it would be convient for you? what's interesting is that we've never seen it done to the degree it is now. we had the Mystery Miner a few years ago but he stopped it pretty quick. also, despite many upgrades added to the protocol previously, we've never had a fork as a result of SPV mining before either. what's different this time is the consistently full blocks and the fact that Wang Chun told us they create SPV blocks in response to large blocks as a defense. it seems they consider full blocks large blocks so the excessive SPV mining created last nights fork in light of BIP66 and the upgrade to 0.10.x. so in that sense, the 1MB cap is the direct cause of what is happening.
The incohearence in some of these posts is so foaming so thick that it's oozing out and making the floor slick; careful-- you might slip and mess up your future as "the LeBron James of the Bitcoin world" (as your attorney decribed you (18:30), under oath, to a federal judge as part of litigation related to your possession of 3000 BTC taken primarly from members of this forum.). As miners have created larger blocks F2Pool expirenced high orphaning (>4% according to them); they responded by adding software to mine without transfering or verifying blocks to avoid delays related to transfering and processing block data. Contrary to your claim-- the blocksize limit stems the bleeding here. Their issue is that large blocks take more time to transfer/handle and that they're falling behind as a result. Making blocks _bigger_ would not help this problem, it would do the _opposite_. If a miner wanted to avoid any processing of transaction backlog they'd simply set their minimum fee high and they'd never even mempool the large backlog. Reasonable minds can differ on the relative importance of difference considerations, but when you're falling all over yourself to describe evidence against your position as support of it-- redefining F2pools crystal clear and plain descption of "large blocks" as their source of problems with the technically inexplicable "full" that you think supports your position, it really burns up whatever credibility you had left. That you can get away with it in this thread without a loud wall of "WTF" just shows what a strange echochamber it has become.
|
|
|
|
lebing
Legendary
Offline
Activity: 1288
Merit: 1000
Enabling the maximal migration
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 06, 2015, 04:44:27 AM |
|
|
Bro, do you even blockchain? -E Voorhees
|
|
|
Peter R
Legendary
Offline
Activity: 1162
Merit: 1007
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 06, 2015, 04:49:23 AM |
|
what's interesting is that we've never seen it done to the degree it is now. we had the Mystery Miner a few years ago but he stopped it pretty quick. also, despite many upgrades added to the protocol previously, we've never had a fork as a result of SPV mining before either. what's different this time is the consistently full blocks and the fact that Wang Chun told us they create SPV blocks in response to large blocks as a defense. it seems they consider full blocks large blocks so the excessive SPV mining created last nights fork in light of BIP66 and the upgrade to 0.10.x. so in that sense, the 1MB cap is the direct cause of what is happening.
I'm trying to understand your thinking on this matter. It makes perfect sense to me that we'd see an increase in empty blocks as the average block size rises. It seems you think the frequency of empty blocks would also actually decrease if we raised the limit (assuming the rate of transactions stayed the same). Is this an accurate assessment of what you're saying? Can you explain again why you think that?
|
|
|
|
Peter R
Legendary
Offline
Activity: 1162
Merit: 1007
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 06, 2015, 05:58:24 AM |
|
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. ![](https://ip.bitcointalk.org/?u=https%3A%2F%2Fi.imgur.com%2FwVi1q2L.png&t=665&c=_ykkZiWfROcQyg)
|
|
|
|
BlindMayorBitcorn
Legendary
Offline
Activity: 1260
Merit: 1116
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 06, 2015, 06:01:36 AM |
|
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. ![](https://ip.bitcointalk.org/?u=https%3A%2F%2Fi.imgur.com%2FwVi1q2L.png&t=665&c=_ykkZiWfROcQyg) +1 The principle of charity should always guide us.
|
Forgive my petulance and oft-times, I fear, ill-founded criticisms, and forgive me that I have, by this time, made your eyes and head ache with my long letter. But I cannot forgo hastily the pleasure and pride of thus conversing with you.
|
|
|
gmaxwell
Staff
Legendary
Offline
Activity: 4242
Merit: 8653
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 06, 2015, 06:32:13 AM Last edit: July 06, 2015, 06:50:38 AM by gmaxwell |
|
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).
|
|
|
|
TPTB_need_war
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 06, 2015, 07:17:55 AM |
|
That you can get away with it in this thread without a loud wall of "WTF" just shows what a strange echochamber it has become.
Oh, there was plenty of WTF when I read his last post, and some prior to that when he was trying to make a similar argument, but it's pretty clear that he's made up his mind and no amount of WTFing is going to change it. +63
|
|
|
|
TPTB_need_war
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 06, 2015, 07:46:30 AM |
|
Questions: Why couldn't RBF be improved so that same inputs must always pay to the same outputs when txn is replaced, except that any increases in the output values (not change in output address allowed) for increasing the fee must be matched by increase inputs? Thus the buyer can no longer steal value from the merchant which already delivered the goods. Wouldn't that resolve the complaint against RBF?
And wouldn't that then remove my argument that fixed block size limit is incompatible with 0-conf txns? (my argument was first-seen must be overruled by fee per KB when block size is a scarce resource).
Ah I realized my error. The transaction could be forever replaced. Okay instead, how about designating another UXTO address that can be exclusively drawn from? Ah but that would mean only the buyer can RBF which is not fair if the seller is the one harmed (otherwise seller could steal value from buyer).
|
|
|
|
|