Bitcoin Forum
December 05, 2019, 09:45:37 PM *
News: Latest Bitcoin Core release: 0.19.0.1 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 [42] 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 ... 158 »
821  Economy / Scam Accusations / Re: Payment Not Delivered by "R-" for Work Rendered on: January 15, 2013, 02:18:37 AM
I will contact Maged to help me through the process.
Wow, this issue is so old that I've even disabled notifications for this topic (hence my late response). That being said, I did not receive any communication from R- recently, so I don't know what's happening with this.

But as for an "agreement" to pay me back. You can pay me the amount of bitcoins that you owe me to - 1GbMFKHHSyP8x4AwN4xRE1iRYgnCapv8HM-  22.8 left to pay..
With that kind of attitude you'd be lucky to get anything more back. R- has already defaulted on this, so it'd be to your benefit to just get as much out of this as you can. One idea of what you can do is to send him an offer that gives him until a set date to pay you back at a discount, but on the condition that if he fails to do so he'll owe you even more than he currently does. Give him a limited amount of time to accept this offer. As a show of good-faith, it would be nice to at least make an offer like this once.

Of course, if you and R- come to an agreement, we would be happy to remove R-'s scammer tag.
822  Economy / Gambling / Re: One thread per site ONLY on: January 10, 2013, 09:21:46 PM
Thanks. I'm trying to follow the spirit of the rule. I trust you guys will let me know if I ever cross a line anywhere.
Absolutely.

FWIW I promise not to ever run stupid redundant spammy bonuses and whatnot in new threads, I don't have any reason to post about it if it's not something new to the site.
Heh, thanks!
823  Other / Off-topic / Re: Tonight, I will die on: January 10, 2013, 08:32:47 PM
I have a question: What are the legalities here supposed I would give the guy any pointers?
Legalities aside, it could very well result in a ban from this forum. We take suicide threads very seriously and will actively remove any post that even considers suicide a viable option for the person who is contemplating it. Often, these types of posts will be deleted less than 10 seconds after they are posted.
824  Economy / Gambling / Re: One thread per site ONLY on: January 10, 2013, 08:20:02 PM
So when we create an entirely new type of bonus, or new games, then that's new and noteworthy and deserves a new thread.
I agree. I see nothing wrong with these threads. You need to remember why this policy was put into place more than you need to actually follow it to the letter.
825  Bitcoin / Bitcoin Discussion / Re: [Resolved] 111 BTC AS FEES (don't do raw tx's when you're tired) on: January 10, 2013, 05:50:36 AM
My questions are:

1. If the miner was found and refused to return the money, would he/she be labelled as scammer?
I would say no.

2. In this case, do those PPLNS users have the responsibility to return the extra earning?
They can for the sake of good will, but they wouldn't be responsible to do so.

3. If I mistakenly sent money to a donation address of someone, is he/she obliged to return to me?
No, because it was a donation.

In the BitcoinStore case, a scammer tag was never given, so I can't say for sure what would have happened there, but even with that there was a huge difference between that issue and the bulanula issue.

With bulanula, the overage was sent as part of a business transaction that was both already expected and negotiated prior to the transaction. Because of that, it was absolutely clear that a typo had been made when the amount that was sent was 10x what was expected. In addition, the sender was able to prove that they were the same person who negotiated the transaction.

With BitcoinStore, the additional transaction came later after the original agreement was settled. Because of this, there is no clear indicator that the amount was a typo, since no balance had been owed for over 22 hours. At that point, the receiver very well might have used the address for another purpose since nothing more was expected to arrive regarding the negotiated transaction. One such purpose may have been as a donation address. And that's where this story gets even weaker, because this was actually an address that BitcoinStore gave to someone else to pay to, meaning that they have no easy way to prove that they own the address and that what they said actually may have happened.
826  Other / Meta / Re: What is the Written Declaration of Received Documents ? on: January 10, 2013, 05:31:27 AM
It could be anything...

That being said, because it's essentially a pre-announcement, I think that it shouldn't belong there until the company is revealed.
827  Other / Meta / Re: Sales of accounts and invites to invite-only sites on: January 05, 2013, 04:57:30 AM
Putting legalities aside, how do you expect someone to acquire accounts in bulk unless they are hacking or automating site registrations en mass (site abuse)?
I think you just answered your own question: we would allow people to sell accounts that were registered through automation. Whether or not we ban that is a completely different debate.
828  Economy / Digital goods / Re: Cheap Tracker invites : Fuxor,scenehd,ptp,tt,waffles,bitme,bitmetv,tl,scc,gft. on: January 05, 2013, 02:27:08 AM
you do know that selling invites are not allowed, right?
As long as the accounts aren't hacked/stolen, it's just fine to sell them here. Of course, keep in mind that this most likely violates the sites' ToS, but that's the buyer's responsibility.
829  Other / Beginners & Help / Re: The ten minutes between blocks on: January 04, 2013, 11:12:42 PM
Each block has a pointer to the previous block, though, so how could this attack work?  After you pay me in the block with timestamp X, you could forge another block with timestamp X-5 in which the money went somewhere else, but a traversal of the blockchain from the block with timestamp X would show that your new forged block was not in the chain, right?

What am I missing?  I am speculating that it has something to do with chain forks and orphan blocks....
I think I get what you're saying. You're saying that because everyone already saw a certain block, it's impossible to forge a new one. However, it can easily be the case that because of network latency between peers, different node won't be in the same state at the same time. It is possible for an attacker to tell two different nodes about different versions of the same block and they won't hear of the other conflicting block until later. As DeathAndTaxes explained, this conflict of state is eventually resolved through proof-of-work.

Additionally, because nodes go online and offline in the network as they please, any system that depends on what was heard first without some way to resolve conflicts would totally collapse even if you had some way to reduce latency between all peers to zero.
830  Other / Beginners & Help / Re: Whitelist Requests (Want out of here?) on: January 04, 2013, 10:19:07 PM
Finally caught back up...

ianchudson: OK
w00ty: OK
Walter Rothbard: OK
mvj: OK
jcc: OK
WalrusBaller: OK
SpottedMarley: OK
smellymoo: OK
BitcoinByte: OK
bbqsamich: OK
dparrish: OK
831  Bitcoin / Development & Technical Discussion / Re: The Long Wait for Block Chain Download... on: January 04, 2013, 05:41:28 AM
Where can I read a summary of proposed solutions? I had an idea where a special block is created that contains the balance of all accounts and the next block in the chain (for old clients to maintain compatability) and that together forms the genesis of a new blockchain. It wouldn't affect old clients because old clients could choose to begin with either data source or people could just upgrade. I can't see how that idea is faulty (it probably is) but I wanted to read a summary of it and other ideas.. since it's surely been proposed before.
Of all of these types of suggestions, this is the most promising:
Ultimate blockchain compression w/ trust-free lite nodes
You'll have plenty of reading to do with just that, trust me.
832  Bitcoin / Bitcoin Technical Support / Re: No Fee-transactions take longer - Myth?? on: January 03, 2013, 10:12:28 PM
It seems that it doesnt matter and quite to the contrary even impede your chances of quick confirmations if you include a fee into your transaction.

Thoughts?
Before trying to conclude anything from this graph, you need to remember why fees were or were not paid. A strong majority of the transactions were likely made by clients that either require or highly suggest that you pay a fee only when the transaction would otherwise take a long time.

A proper analysis would show time in terms of blocks and would use only their own pairs of transactions that have the same/similar priority when their isn't a fee where one of the pair is submitted with a fee and the other isn't.
833  Bitcoin / Bitcoin Discussion / Re: Analysis of hashrate-based double-spending on: January 03, 2013, 10:01:53 PM
DAG stands for Directed Acyclic Graph. The PoS article you linked to mentions this once, not going into detail. I think it refers to the structure of the block relations. The blockchain currently forms a tree, where different branches are not reconcilable, with one having to be eventually forfeighted. I guess the proposal is to make it possible for branches to join back. I don't know of any such proposals though.
Thanks. It's probably the blocktree thing then.
This is indeed what a DAG is and I think we're thinking about the same proposal. I might try linking to it sometime.
I guess this is Maged proposal, isn't it? https://bitcointalk.org/index.php?topic=57647.msg686497#msg686497
That's the one. I haven't spent time thinking about it in a while, AFAIR it's not completely fleshed out yet, but I think these ideas are the key to preventing a majority attack that rejects all transactions.
The few major issues I've come to realize with that proposal are:
1) It will most likely require cementing at some level so that miners don't "save up" their mined blocks to guarantee themselves a block in the main chain that won't be kicked out by someone else by chance.
2) On a similar note, Finney attacks are guaranteed to be successful, unless some form of block discouraging is used. This wouldn't be that big of a deal if the main chain gets extended every few seconds, though.
3) Any currently-backwards-compatible change that only requires a majority of the miners to upgrade to go into effect would require a hard fork if this were used. This might not be that much of a problem once the Bitcoin network is more mature.

Speaking of #3, that directly relates to that whole contract thing theymos brought up recently: it would truly become impossible to make lost coins unspendable if ECDSA is ever broken, so that would have to be considered too.

Anyway, that's the update on that.
834  Other / Beginners & Help / Re: Aggressive Moderation on: January 03, 2013, 08:18:28 PM
If posts don't match the original topic of the thread, please report them. We might not do anything about occasional short distractions (1-2 posts) that don't result in people losing the focus of the topic, but we will generally take care of them if they go beyond that. Either way, though, report the posts.
835  Other / Beginners & Help / Re: Blockchain.info wallet encryption on: January 03, 2013, 07:48:18 PM
Now if the idea behind 2FA is that just a password is not enough security, it seems that having backups emailed to me partially defeats the purpose of 2FA in the first place, since the 2FA will do nothing for someone that may intercept a copy of the encrypted wallet file.
Well, if you assume that the email isn't intercepted in-transit (which is a safe assumption for the vast majority of attackers), then the emailed backup is protected by your Blockchain.info password plus whatever security mechanisms you have to use to access the email account. For example, you could also protect the email account that the backups are sent to with 2FA.
836  Other / Archival / Re: Warning, ALL BFL PRE-ORDERS ARE NON REFUNDABLE - CONFIRMED BY INABA on: December 12, 2012, 04:26:23 AM
So, you're stating that what an officially appointed public representative states for a company is not legally binding?  As far as I'm aware they are not random employees and the forums have been designated as Official word from BFL by BFL staff and not Inaba..

Sure, they're *currently* giving refunds. But as stated by Josh, the official policy stands, and is CYA, so they can stop refunding orders at any time they feel like it.
...at a penalty of $16000 per order + whatever the local consumer protection laws say. Their official policy is meaningless. They'd be stupid to actually follow it.
837  Other / Beginners & Help / Re: Whitelist Requests (Want out of here?) on: December 12, 2012, 04:09:34 AM
Man I thought I'd be out of here by now. I'd really like to post in some of the discussions in the economics section. Mod-please have mercy on me.
You seem to lack the bitcoin-specific economics knowledge for me to do that, sorry. That's just fine! But we want people to be prepared to submit informed comments once they are able to post on the main board. I recommend doing some more reading so that you can get in your 4 hours.

Could I be whitelisted?I want to sell my gtx 670.

here is my rating on bitcoin-otc   http://bitcoin-otc.com/viewratingdetail.php?nick=tidus3&sign=ANY&type=RECV


thanks!
Could you sign something with your OTC key that verifies that your bitcointalk.org account is controlled by the same person who controls that key?

Please unlock this business account. Thanks  Smiley
Could we get some more information? A website plus maybe a hidden page that verifies your identity here would be appreciated.
838  Bitcoin / Bitcoin Discussion / Re: Analysis of hashrate-based double-spending on: December 12, 2012, 03:28:53 AM
In the .pdf, things start to look bad for honest side once you asumed attacker pre-mined one block. How can he do that?
An attacker could choose to hold off the tranaction(s) they are sending to the merchant(s) until they find a block that double-spends those transactions. Then, they send off those transactions with a good fee and hope to god that they are included in the next block, otherwise it would be as if the merchant got the benefit of waiting an extra block. However, unless you only started mining after the transactions made it into a block (which would be stupid, since you'd start a block behind), it is better to premine and hope that the transactions make it into the next block than it is to start mining when the transactions are sent since the transactions could still make it into the next block, except you might not have one mined yet, yourself.

And why not pre-mine more than just one block?
Because then you risk wastefully reverting more blocks than you need to because your transaction(s) didn't get into the first block on the honest side of the fork, decreasing your chance of success.
839  Bitcoin / Bitcoin Discussion / Re: [COMMUNITY] Taaki, never tell anyone you are involved with Bitcoin ever again. on: December 06, 2012, 03:15:03 AM
Dear God this is terrible. Seriously, if any of you are ever in the position where you'll be presenting about bitcoin, at the very minimum you MUST read this:
https://en.bitcoin.it/wiki/Public_relations
840  Economy / Service Announcements / Re: [ANN] Deleting old PAYB.TC links from 2011 on: December 05, 2012, 06:00:34 AM
Any links that Google has would be accessed all the time, because that's what bots do. So, this will most likely not effect any published links.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 [42] 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 ... 158 »
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!