@sAt0sHiFanClub, I don't know your definition of a transaction, but if we take the Lightning Network as an example, it does increase transaction throughput without neccessarily increasing the blocksize limit. Large blocks is not the only way of increasing throughput.
Your going off on a tangent now. LN is paperware at the moment. Lets stick to bitcoin for now, eh? |
|
|
|
I don't see why you have to redefine what bitcoin is to increase transaction throughput.  That's quite a straw man here, I didn't say that, please don't overgeneralize.  Lets not split hairs. You said 1GB blocks require a redefine of bitcoin. Larger blocks have more tx's. Blocks are fixed in time. More tx's/constant time = higher tx rate. That's exactly an informal fallacy. Larger blocks mean more txs, BUT more txs don't necessarily mean larger blocks. You are equalizing them. Whaaat? Bitcoin is engineered to generate a block once every ~10 minutes. That is set in stone. So of course more transactions mean larger blocks - unless you are shrinking the transaction size What you said makes no logical sense. I have said 1GB blocks require a redefine of bitcoin. I haven't said you have to redefine what bitcoin is to increase transaction throughput. But you have weakened/replaced my argument to make it easier to refute -- straw man.
The tx throughput can vary, the rate of block creation is fixed. We can have as many transactions as users generate, but we still have the same number of blocks. edit: Maybe we are getting hung up on the 1Gb thing. Same holds true for 2Mb, 4Mb ..... 32Mb blocks. Above 32Mb, you need to change how bitcoin sends messages, but thats academic to this discussion. |
|
|
|
I'm having trouble following this.
"But one of the central pillars of smallblockism is that having larger blocks will result in increased orphan rates as the larger blocks take longer to propagate across the network. But Matts relay network, if applied to bitcoin as a whole rather than a select cadre of approved players, could deliver a performance increase that would obviate that argument."
Doesn't the entire block need to be sent somewhere (at least from a miner to one of the nodes in the relay network)?
A block is a (header + n(tx)) The vast majority of the transactions should already be in the nodes mempool, so why do they have to be sent a second time? Obviously due to the nature of the network, not all nodes will have the exact same set of tx'x, but any missing ones can be requested. Also, the relay keeps track of what tx's have been sent. This is one of the long time conundrums of bitcoin - the redundant resending of transactions. You get a series of 10 byte ids instead of ~250b transactions. Ok assuming the miner only sends a condensed version of the block with pointers to the relay network, the relay network still has to broadcast the full block then to other nodes, correct? Correct - while the relay backbone remains a separate network, then yes. (but not over the relay network - they get propagated over the vanilla p2p as far as i know) But I can imagine a case where it could be extended to a wider network. |
|
|
|
I don't see why you have to redefine what bitcoin is to increase transaction throughput. That's quite a straw man here, I didn't say that, please don't overgeneralize. Lets not split hairs. You said 1GB blocks require a redefine of bitcoin. Larger blocks have more tx's. Blocks are fixed in time. More tx's/constant time = higher tx rate. I think we are conflating 2 different aspects of the same issue. The orphan rate is a direct function of the complexity and scale of the p2p network, and the volume of data in each discrete unit. (blocks) There is currently a ~2% orphan rate which miners ( in their interest) would like to see reduced. So we [Matts relay network] do that by relaying only the information they need. They already have the tx's in the mempool, so all they need is the merkle root to confirm that the tx's they include match the MR in the block. Any tx's they dont have, they ask peers for. Its not compression, but it has the same effect as compression - redundant data is not resent. All fine and dandy. Once again, this all is based on a weak assumption that miners are cooperative -- in the worst case scenarion we are falling back on the regular propagation protocol. While the Matt's RN doesn't have any major downsides per se, it's effectively downplaying the issue at hand -- that in the worst case scenario the information to be transmitted scales linearly with block sizes. While it appears we can easily increase blocksizes thanks to Matt's RN, it's becoming worse in case of uncooperative behavior. But one of the central pillars of smallblockism is that having larger blocks will result in increased orphan rates as the larger blocks take longer to propagate across the network. But Matts relay network, if applied to bitcoin as a whole rather than a select cadre of approved players, could deliver a performance increase that would obviate that argument. I'd like to know how exactly Matt's RN would obviate it. It would mask it, yes, but it's not a magic bullet. As it is, its just a step in the right direction, but I'm also saying that it is an idea that can be developed and deployed across the network in general. But, yeah, i don't think its a magic bullet, but it is certainly an indicator that positive thought exists in Bitcoin, and solutions to its inherent problems can be found. |
|
|
|
I'm having trouble following this.
"But one of the central pillars of smallblockism is that having larger blocks will result in increased orphan rates as the larger blocks take longer to propagate across the network. But Matts relay network, if applied to bitcoin as a whole rather than a select cadre of approved players, could deliver a performance increase that would obviate that argument."
Doesn't the entire block need to be sent somewhere (at least from a miner to one of the nodes in the relay network)?
A block is a (header + n(tx)) The vast majority of the transactions should already be in the nodes mempool, so why do they have to be sent a second time? Obviously due to the nature of the network, not all nodes will have the exact same set of tx'x, but any missing ones can be requested. Also, the relay keeps track of what tx's have been sent. This is one of the long time conundrums of bitcoin - the redundant resending of transactions. You get a series of 10 byte ids instead of ~250b transactions. |
|
|
|
Or you can explain it to me. I've nearly 15 years experience in writing network correlators and rating engines for the mobile teleco industry, so there is little you can teach me on HF data propagation that i don't know. Explain what? That the network can't handle 1GB blocks without completely redefining what Bitcoin is? What Matt Corallo's relay network does is trying to lower orphan rates for miners. It has nothing to do with increasing network throughput (tx rate), only lowers the amount of data to be transmitted with a block. After all, full nodes will still have to download full transaction data. Moreover, it depends on two unreliable assumptions: 1) participating miners are cooperative, i.e. only/mostly include txs that other miners have in their mempools. 2) that participants' mempools are highly synchronized. The latter is especially speculative when we try to project it onto the whole network. If we could make sure mempools are synchronized, we wouldn't need to have blockchain in the first place. But nodes' relay/mempool acception policy is highly customizable. E.g. during the recent stress test, many users had to increase their fee acception thresholds so that their nodes are stable. That means very different mempools for users. I don't see why you have to redefine what bitcoin is to increase transaction throughput. I think we are conflating 2 different aspects of the same issue. The orphan rate is a direct function of the complexity and scale of the p2p network, and the volume of data in each discrete unit. (blocks) There is currently a ~2% orphan rate which miners ( in their interest) would like to see reduced. So we [Matts relay network] do that by relaying only the information they need. They already have the tx's in the mempool, so all they need is the merkle root to confirm that the tx's they include match the MR in the block. Any tx's they dont have, they ask peers for. Its not compression, but it has the same effect as compression - redundant data is not resent. All fine and dandy. But one of the central pillars of smallblockism is that having larger blocks will result in increased orphan rates as the larger blocks take longer to propagate across the network. But Matts relay network, if applied to bitcoin as a whole rather than a select cadre of approved players, could deliver a performance increase that would obviate that argument. tl;dr Matts RN could have benfits both for the miners orphan concerns and the tx throughput ( more tx\s per block) |
|
|
|
Matt Corallo just pointed out at the conference that propagation has little to do w/ bandwidth connectivity but general tcp packet loss which can occurs regardless of your connectivity.
I know there is some posts on the dev list referencing this. Don't ask me to explain in details this is a bit beyond me technically
You mean tcp re-transmission rates? Thats a function of network congestion ( assuming we can ignore radio interference, etc.), which is kinda related to your 'connectivity'. And round we go go again. tcp doesn't loose packets, it drops them when it cannot forward them as quickly as it receives them. This is everything to do with the quality of your connection, not the protocol. |
|
|
|
nice to see XT nodes drop to
6.99% 6.89% (30 minute later lol)
Honestly, you should not be even looking at the node count at all. It does not matter if they have 10, 20 or 500% of the nodes. This does not change anything, and without the support of the miners XT can not happen. 7. /Bitcoin XT:0.11.0B/ (145) 2.5%
So, 6.89 + 2.5 = 9.39%
Still not 10.5%
It will probably keep on declining unless someone starts deceiving the count again. As was demonstrated, the node count can be easily manipulated and thus should be completely disregarded. Stealth mode in XT has made node count irrelevant. |
|
|
|
Seeing you posts, Adam, I'm really excited by your apparent lack of understanding of the technical side of Bitcoin. I figured, maybe you could consider refraining from posting nonsense, and educate yourself first?
Because I see no point arguing with you, when you can't grasp some relatively simple technical ideas.
Quit with the lame "Its beneath me to explain" angle. If you have an issue, state it, and support your contention with a relevant tech reference. Or you can explain it to me. I've nearly 15 years experience in writing network correlators and rating engines for the mobile teleco industry, so there is little you can teach me on HF data propagation that i don't know. |
|
|
|
Many consumers have exclaimed they will leave Bitcoin to go to an altcoin which suits their "needs" if they don't get their way in Bitcoin being perverted into a system to compete with Visa. What they don't realize is the consequences they will face if they choose this option. full article: http://qntra.net/2015/09/consumers-begin-revolting-bitcoin-is-not-visa/And what are the consequences? Please don't tell me you are questioning the edicts of our favorite Romanian gypsy?  |
|
|
|
I thought you were dead  I was happy  Getting a little more difficult to troll after theymos made sure your sock puppets couldn't share with us your library of gay men enjoying themselves heh Tough shit, Troll. |
|
|
|
|
Regarding Peter's reply above - he does realise that the tx eviction is only on a particular node - that same transaction will likely remain on all other nodes. So why should it be rebroadcast? Additionally, this is only going to be a factor when the mempool is full - by then the majority of tx's sitting there ( as they didnt pay a fee or not enough) are going to be spam, so the likelihood is that it will be a spam tx that will get evicted. Legitimate tx's will get processed quickly and are unlikely to ever be in the 'relegation zone'.
On the other hand, Peter's deterministic route means that if your transaction is unlucky enough to be the one to be dropped, then it it is dead on all nodes. Game over for you, unless you spot it ( ha!) and re-submit it. Thats a really lousy solution.
|
|
|
|
More seriously..
Bitcoin's value proposition [..... more trilema/MP gypsy crap...]
You need to have the IQ of an amoeba to put any value in that shit. |
|
|
|
They do not exist and violate in several jurisdictions the Anti-Money-Laundering (AML)-regulations as well as anti-terrorism-laws. So most probably, it will not be any "police" who will try to nail them down, but financial market authorities.
Anti terrorism? Hmmm. I dont think any one outside bitcoin really gives a shit about this to be honest. |
|
|
|
I'll sit the rest of this mess out. I think Coinwallet will still face charges, because they can't credibly claim they have no responsibility for what is happening. It's like dumping bushel baskets of coins out on a busy road and trying to claim that the resulting carnage and mayhem is not their fault, just the fault of all the pedestrians and drivers involved.
Its nothing like that. I'm afraid the mess was your own doing. Coinwallet merely published the data - the decision to import those keys was entirely your own. It takes a reasonably sound technical knowledge to do so successfully, so you cant plead ignorance. |
|
|
|
Seriously folks, do not contaminate your normal wallet with this, use a throwaway. If you receive Bitcoin from this you're basically spam attacking your own wallet.
So what you are saying is.. 1. I tried to do this.. 2. I dont understand it enough to get it working. 3. Now, anyone else who tries is BAD, coz its spam.. What a f*cking tosser. |
|
|
|
so, as i see it; if multiple user have the same private key and they try to make a transaction to another wallet - the one whose transactions are mined first, gets it? the first one will be the one who splits it in the smallest transactions; but in the end transaction costs will be higher than the transaction amount?
it's a mess - huge waste of time I dont know - it worth observing peoples behaviour at the very least. Unless you are manually hacking transactions together to get a decent single output I dont think you will make anything out of this. If you are too granular then fee's will eat it all up. I managed to cobble a few tx's with ~70 inputs each, but with a decent fee to ensure it got through ( early ones took 2 hours to appear in a block, some a lot longer) it wasn't worth the effort of writing the script. Still, I've learned some cool 'hidden features' in bitcoind. That, and my php's gone to shot. |
|
|
|
For the record, I also wasn't accusing you of being someone who would've hid Jews from the Nazis during the war. ROFLMAO Im still smiling at that one too. It would be funnier still if hdfuck actually understood it. |
|
|
|
post the public address of the key or it didnt happen.
I don't usually care about random people that do not believe me, but here you are:   There is at least 1 more person that has imported this address and is trying to take the coins. I've figured out a way that works, but without a bot or something this will be painful. Everything can't be sent out because the TX would be 7949454 bytes big (this results in a error in Core for me). Dont use bitcoinqt. Use bitcoind, write a script ( i used php) that cycles through the outputs (via rpc) to create inputs for rawtransaction and sendtransaction them to the rpc port. You can chain a load of them that way in rapid succession. you are still bottlenecked by waiting for the keys.... |
|
|
|
|
Show Posts
