|
If you didn't do anything wrong and have a clear conscience then logistically you should have no problem doing it again, right? If you did nothing wrong then why not do it again?
|
|
|
|
I don't see how this would be anti-freedom of speech. You can have an alt to post 'controversial' optinions or sell something if you don't want it associated with your other account, but there's no good reason why you would need multiple accounts to sell the exact same thing other than to spam advertise which is exactly his intent.
Say you have one account that you are selling widgets on, and you have an opinion regarding some issue/topic unrelated to widgets. You then make what turns out to be a controversial statement about this topic, and this statement is so controversial that some people don't want to trade with you anymore -- you still trade honestly, and still sell a quality product. You might then want to create an alt account to well widgets that is not associated with this controversial statement/opinion, however if your first account stops selling widgets at the same time your alt account starts selling them, then your alt might stick out like a sore thumb as being the same as you. If you were not allowed to continue selling widgets on your first account while your alt account is also selling widgets, then you might refrain from making statements in the first place. He doesn't have any excuses. Never known a user like him. Interesting. I wonder if he will be back. I am very proud to only operate a single account.  No you don't lol. This from a proven liar?  Name another account I operate, fool. |
|
|
|
The miners who engage in "SPV" mining will only mine on top of an unvalidated block for as long as it takes them to validate the block. These miners are relying on the valid economic assumption that it is not economical to build/broadcast an invalid block, and it will cost a troll miner much more to broadcast an invalid block than it would cost the rest of the network to build upon an invalid block for only as long as it takes to determine that said block is invalid. It would cost a troll miner roughly 13.5-14BTC to broadcast an invalid block, while it would cost 90% of the network collectively between ~.6BTC-~.62BTC to build on top of that block for the amount of time it takes to figure out it is invalid.
Not necessarily. As I mentioned earlier, an invalid block can be invalid in many ways. It is possible that a miner could make an invalid block which has a massive payout, such as changing the block subsidy to 1250000000000 BTC for that block. Even though the consensus rule is that coinbases need to have 100+ confirmations before they can be spent, this is an invalid block, so consensus rules go out the window. They can make a block which has that huge reward and make and include a transaction which spends that reward to an exchange address thus once they get their invalid block considered valid, they can cash out and make a ton of money to recover their costs. I was speaking strictly in terms of how SPV mining works today, under today's rules. OP - You are describing something very similar to EC (emergent consensus). It should be important to point out that only certain consensus rules are subject to EC in your proposal, otherwise the miners will be able to make *all* the rules, which is probably not something that is desirable.
Has OP stipulated that his "temporarily invalid" block thing is only applicable to certain consensus rules? He has not mentioned that explicitly thus far in this conversation, and it was not mentioned in the OP when I first responded to it. No, he has not, however without EC being applicable to only certain rules, the OP's proposal would have too many technical flaws to even be considered. I would also point out that not all nodes' clocks are on the exact same time (when converted to GMT), so it would be difficult to determine if a transaction has in fact been in a miner's mempool for at least 15 seconds prior to broadcasting a block that confirmed said transaction, so I don't think it would be possible for a node that had received a transaction at the exact same time as the miner to validate the miner had the transaction in it's mempool for at least 15 seconds. Also, as achow101 pointed out (somewhat), if a node receives a transaction 5 seconds prior to receiving a block that includes said transaction, they believe said block is invalid -- this is however resolved by your EC clause.
But waiting for the EC clause to take effect takes time, and this case is a usability issue. Suppose you received a transaction, and that transaction is included in a block. But you perceive that block as invalid because some other transaction in that block was received less than 15 seconds before you received the block, so you mark it as invalid. This is can make Bitcoin less easy to use as some users won't know that their transaction has actually confirmed since the wallet considers the block it was confirmed in to be invalid until ~30 minutes after the confirmation. In fact, a miner could perpetually prevent the EC clause from taking effect for a specific node by always broadcasting an old transaction (i.e. one that was discarded by being older than 1 hour, as was mentioned previously) shortly before broadcasting the block including it. You could do this an effectively take nodes offline for a while. Yes, in the case of the OP's proposal, to use EC would result in chaos because nodes would be broadcasting potentially conflicting transactions, and more importantly, miners would be building on top of potentially several blockchains, which would lead to frequent reorgs. You could even have multiple reorgs within a reorg. I would be more comfortable with a consensus rule change so that transactions must have a tx fee rate above a certain amount (with no exceptions >.<), and EC in regards to block size only. The reason for this is because there is a higher chance there would be a "business" reason to create a larger block (eg the miners are clearing a spam attack backlog, or a backlog that results as a result of some other temporary reason), than to create a block that violates transaction ordering rules. I also suspect that the miners would mostly be on the same page about a pending "large" block, so they would not try to orphan said block, and there would not be many reorgs because of large blocks as opposed to the large number of reorgs that would result from the OP's proposal. |
|
|
|
You are also assuming that all miners are fully validating every single block before they build on top of it. Unfortunately, we know for a fact that this is absolutely not the case. Many miners are SPV mining; they will begin mining on top of a block before it is fully validated. With SPV mining, it is very possible that miners will end up mining on top of an invalid block and thus extending the chain for that block and find enough blocks so that its is valid.
The miners who engage in "SPV" mining will only mine on top of an unvalidated block for as long as it takes them to validate the block. These miners are relying on the valid economic assumption that it is not economical to build/broadcast an invalid block, and it will cost a troll miner much more to broadcast an invalid block than it would cost the rest of the network to build upon an invalid block for only as long as it takes to determine that said block is invalid. It would cost a troll miner roughly 13.5-14 BTC to broadcast an invalid block, while it would cost 90% of the network collectively between ~.6 BTC-~.62 BTC to build on top of that block for the amount of time it takes to figure out it is invalid. The result of this is greater security as this will reduce the orphan rate.
OP - You are describing something very similar to EC (emergent consensus). It should be important to point out that only certain consensus rules are subject to EC in your proposal, otherwise the miners will be able to make *all* the rules, which is probably not something that is desirable. I would also point out that not all nodes' clocks are on the exact same time (when converted to GMT), so it would be difficult to determine if a transaction has in fact been in a miner's mempool for at least 15 seconds prior to broadcasting a block that confirmed said transaction, so I don't think it would be possible for a node that had received a transaction at the exact same time as the miner to validate the miner had the transaction in it's mempool for at least 15 seconds. Also, as achow101 pointed out (somewhat), if a node receives a transaction 5 seconds prior to receiving a block that includes said transaction, they believe said block is invalid -- this is however resolved by your EC clause. Another problem is that if someone broadcasts a transaction that gets to miner "A" located in China, and a conflicting transaction that gets to miner "B" located in New York, US, then exactly one of those transactions will get rejected by nodes. This will possibly result in a miner creating a block that gets rejected by the rest of the network, and a potentially long orphan race, both of which is undesirable. The winning chain would be determined by EC after the fact. I think that EC would probably be better for things like long term changes to demand for block space, and the potential for a one-time large block to account for a temporary increase in the need to confirm many transactions. I don't think that EC is appropriate for the minute-to-minute decision regarding which transactions should get included in specific blocks because miners will too frequently not be on the same page. |
|
|
|
the effective block size, part of segwit, was a compromise meant to appease the big blockers. ironically enough this is the part that most big blockers have the most issues with.
Some people feel that discounting the signatures on SW transactions was to make using LN more economical as the on-chain portion of LN transactions (eg creating and settling LN channels) will be very signature heavy. 2in 2 out... not that heavy With LN, in order to open a channel, a minimum of two inputs will need to be signed, however LN gives incentives to open many channels, which means that when channels are closed, users will have many outputs they will need to spend, so a more likely minimum after LN has been in use for a while is 4 signed inputs. In order to close a LN channel, users will need to sign a 2-of-2 multisig address to move the BTC to an intermediary address, which is also 2-of-2 multisig, and would need to sign subsequent transaction to move BTC to an address they control. This is 2 signatures minimum to open (which will likely grow to 4), and 4 signatures to close a LN channel. the effective block size, part of segwit, was a compromise meant to appease the big blockers. ironically enough this is the part that most big blockers have the most issues with.
Some people feel that discounting the signatures on SW transactions was to make using LN more economical as the on-chain portion of LN transactions (eg creating and settling LN channels) will be very signature heavy. ya i think so too, the official reasoning core gives seems fishy... I feel it is their way of picking winners and losers, by calling a HardFork a Soft Fork, and changing the consensus rules. |
|
|
|
|
He PM'ed me yesterday saying that he needed 1.5 btc to get to a party that way 'tomorrow' (now today) at which he would get paid 2,000 euro for attending (?) and would use those funds to pay me back. He said that if for some reason he would not be able to pay me back with that 2,000 euro, he would pay me back via funds received on the 4th.
So I guess he no longer needs the loan because the time has passed that he was going to use the proceeds by.
|
|
|
|
Is there a written rule somewhere that people cannot sell the same item via multiple accounts? Or is this something that is more along the lines of a mod's interpretation of the rules?
I don't think there is one that explicitly says You cannot use alts to sell the same thing so you can take it as my interpretation if you wish, but it directly contravenes the one thread per person and one bump every 24 hours rules. It can certainly be added to the rules, but this is exactly why BadBear was against posting them in the first place because people then just try to evade them on technicalities. OP knows you can only have one thread per person per same item/service. He knows you can only bump once per 24 hours, hence why he uses multiple accounts and dozens of others to bump them. It's a direct attempt to evade rules and spam the forum. He was told about this numerous times, on numerous accounts and had numerous bans yet he ignored them every single time and continues to do so. I am not familiar with a 'one thread per person' rule....maybe you are referring to the rule that similar marketplace items should be consolidated into a single thread. If you are selling the same thing via multiple accounts *AND* are bumping each accounts' respective threads every day, then you are, at a minimum rubbing up against the one bump per 24 hours rule. I guess my concern about mandating that you can only sell the same item via one account is that it gives incentives to not take unpopular stances on issues, which is anti-freedom of speech. Although selling the same item via 6 or 10 accounts is somewhat 'spammy'. However, if someone is selling the same thing via that many accounts, I think there is a decent chance they are breaking other rules anyway. For clarification, I don't disagree with the OP's ban, assuming that what you say about him is true (or mostly true, if he is able to poke a small hole in what you say). Also, considering that he received warnings via PM from moderator(s), even if the rule violations he was warned about were not actually against the rules (I would not say this is the case), his appropriate course of action would have been to either reply to the PM to get the moderator to agree that no rule was broken (or escalate to a mod with a higher authority to get a higher authority to agree that no rule was broken), or he should have opened a thread in meta for discussion, with a resulting consensus among those that matter that no rule was broken. I am very proud to only operate a single account. No you don't lol. |
|
|
|
Using alt accounts to sell the same thing
I don't think this is against the rules. Yes it is. You can't skirt the 'one thread' rule by having half a dozen accounts to sell the exact same thing. It's pure spam, not to mention using dozens more accounts to spam bump his multiple threads every day and also ban evade whenever he was banned on an account. Is there a written rule somewhere that people cannot sell the same item via multiple accounts? Or is this something that is more along the lines of a mod's interpretation of the rules? I agree that using alt accounts to bump your own threads (especially well in excess of once per 24 hours) should be frowned upon (I can see value to answering your own question provided that the question and answer happen very close to each-other -- and this does not happen frequently). Obviously ban evasion is not allowed, but that is a very different rule. |
|
|
|
Using alt accounts to sell the same thing
I don't think this is against the rules. |
|
|
|
It seems different now, unless they managed to break Blocktrail:  They are still signaling for BU, with an EC of 25 MB blocks The coinbase of block 459872 can be decoded to: [...]EB25/AD23/8M[...] I assume that blocktrail is probably looking for "EB1" which signals BU with an EC of 1MB blocks. |
|
|
|
the effective block size, part of segwit, was a compromise meant to appease the big blockers. ironically enough this is the part that most big blockers have the most issues with.
Some people feel that discounting the signatures on SW transactions was to make using LN more economical as the on-chain portion of LN transactions (eg creating and settling LN channels) will be very signature heavy. |
|
|
|
oh this pointless.
lets just fix TX malleability and incress blocks to 2 MB
What is the harm of malleability? The only time when users would possibly be affected is when an unconfirmed output is spent in a subsequent transaction. Almost all (if not all) Bitcoin related business that have transaction volumes that can reasonably be described as substantial are able to not get tricked by malleability. malleability Is an annoyance at worst IMO. most of us agree LN is worth some R&D so ya go ahead and fix the annoyance... If the primary reason for SW is LN, then first of all blockstream should be more transparent about this. More importantly, it is the miners who are supposed to collect the TX fees in Bitcoin, not any 2nd layer solution. Also I am not so sure how good of an idea it is to be changing the Bitcoin protocol in order to pick winners and losers. |
|
|
|
More importantly, Loaded is doing this publicly to make a statement of support for Core and in condemnation of BU.
This is a lie. Loaded has said that he does not have faith in the BU devs, and in the past he has supported large blocks. He has also reserved the right to back out of the deal if the BU devs were to improve upon themselves. There is no deal to "back out of" if Roger doesn't get his act together and prove he can afford to absorb Loaded's BTU dumps. It's almost time to start posting pictures of giant chickens.  I don't think there is a question if Ver can cover a deal of this size. The last I read, it was loaded that has stopped responding. |
|
|
|
It seems that for F2Pool the best solution is Segwit, they have already stated many times that they will signal for it eventually.
I have no inside information nor do I have a reference to this, as it is speculation. I think that f2pool (and likely other smaller pools that have not signaled any proposal) will signal for whatever proposal that first gets some hashrate percentage above 50%, and as more pools signal for this proposal, other pools will be under additional pressure to signal for this proposal. I would say that the time from 51% to activation will be very short for whatever scaling solution gets implemented. |
|
|
|
oh this pointless.
lets just fix TX malleability and incress blocks to 2 MB
What is the harm of malleability? The only time when users would possibly be affected is when an unconfirmed output is spent in a subsequent transaction. Almost all (if not all) Bitcoin related business that have transaction volumes that can reasonably be described as substantial are able to not get tricked by malleability. malleability Is an annoyance at worst IMO. |
|
|
|
More importantly, Loaded is doing this publicly to make a statement of support for Core and in condemnation of BU.
This is a lie. Loaded has said that he does not have faith in the BU devs, and in the past he has supported large blocks. He has also reserved the right to back out of the deal if the BU devs were to improve upon themselves. |
|
|
|
I think Synereo is behind the attack (mentioned now in profile as some sort of coin thingy), for I just exposed their CEO in a multi-million-dollar scam tied to Charlie Shrem, my old bud. It sadden me to do it at the time, but the truth is the truth.  The AI which assigns these icons knows all. You must really be a Synereo shill in disguise. I'm shocked! This is more than enough proof for a conviction in the court of bitcointalk. I don't think we even need any more discussion about this. Bruno is clearly a Synero shill. |
|
|
|
|
In the past, theymos' April fools jokes have turned into actual new features.
Maybe we will be able to pick our own actual badges in the future.
It looks like theymos has a larger variation of titles this time around.
|
|
|
|
|
Show Posts
