I'm of the opinion that the forum shouldn't have to adapt to the signature campaigns, it should be the signature campaigns adapting to the forum. If we're at the point where it's bad enough that we have to actually write custom code to make signature campaigns tolerable, then we should just crack down on them entirely.

Note - I don't consider the signature restrictions that were implemented on ranks a long time ago to meet the above criteria as you don't have to be getting paid to have annoying advertisements in your signature. Also note that "crack down" doesn't necessarily mean "ban".

Probably reported about 50 posts in the last few days in my crusade to clean up my favorite forum section Only had 1 of those marked bad so far and to be fair my report was pretty flimsy on that one. My plan is to keep reporting and reporting and reporting until people finally get the message and post threads in their intended sections, but who knows if they ever will

I've decided to withdraw my support for this flag and lock the thread. I think Lauda's arguments are reasonable here and I'm not the kind of person who won't admit that my case isn't strong enough.

You're expecting people to trust you a lot here mate. Asking people to freely trust you with their exchange credentials is no different to you asking them to trust you with a private key or give them a loan - it's the same level of risk for them. Not particularly helped by the fact that you have no history on this forum.

Also, I've requested this be moved to Service Announcements or Trading Discussion. Threads like these shouldn't be in Project Development - you literally admit yourself in the original post that development is finished.

Small update - after a silly amount of configuration required to get my RPi Zero able to receive an internet connection over micro-USB, and an even sillier amount of configuration required to get all my packages running, I've got the Python bit package running successfully. Pretty tight for storage right now - all in all I'm using 1.8GB of my 2GB microSD card that's being used as secondary storage for it!

(obviously when this wallet is 'ready' for use, the RPi will be wiped completely and only the completed software will be placed on it, and it won't be connected to the internet anymore)

All I've done so far after that is confirmed that private key generation works and that you can get an address from it:



But I'm ready to make actual progress on this project now so stay tuned

You're charging almost 0.0003 BTC per post there mate (assuming you post your 'maximum') - I don't think you're going to have any chance of getting that, especially considering you got banned from the Cryptotalk campaign for spam/burstposting - you might want to lower your rates a little bit. Trying to get more than what you were getting before probably won't fly.

This is an idea I've mulled around in my head for a while. There can often be petty disagreements on this forum regarding loans, trades, etc, and it normally comes down to the fact that a proper contract was never used. So here is my sample contract for reducing the likelihood that lender and lendee get in a disagreement, negative trust gets exchanged, 500 threads get made accusing each other of being a scammer, and so on and so forth.

I'd recommend signing all important loan correspondence with either a known PGP key or a Bitcoin address that you have previously staked on the forum. Both parties should insist on this to ensure a compromised account has a lower chance of causing loss of monies.

My Bitcointalk username is {lender_name}. The current date is {current_date}. This is a contract governing a loan to be granted to {lendee_name} by myself.

The loan will be for the amount of {loan_amount}. Interest will be charged at {interest}% daily/weekly/monthly. Interest will be added onto the remaining loan balance at {calc_time} every {calc_specified_day}. In the case of the lendee falling behind, the balance remaining on the loan will be capped at {cap_amount}.

The minimum repayment on this loan will be {min_repayment}, to be paid by {repay_time} every {repay_specified_day}.

The following collateral will be given to the lender by the lendee before the loan payment is made: {collateral}

The loan payment will be made to this address controlled by the lendee: {lendee_address}
Loan repayments will be made to this address controlled by the lender: {lender_address}

The terms of this contract can only change if agreed by both parties. Messages affirming an agreement to this contract must be signed by {auth_method}.

Blanks to fill in -



Yes - I know it's a bit 'complex' - but a written contract like this will help to cover almost all bases in case something goes wrong. A written contract like this makes it trivially easy to handle disputes, scam accusations, settlements and so on and so forth.

If anyone has any feedback for what could be added, just let me know.

Updated this sticky a little bit for 2019. I've changed what I define as a 'new user' to anyone who is Member or below now rather than Jr. Member or below. You can get Member in less than three months and I don't want people to think that suddenly 2.5 months of being on the forums makes someone less likely to scam. Full Member requires a little more time investment.

Obviously you should still not loan without collateral whenever possible. Personally the only loans I'd ever do without collateral are relatively small ones (definitely less than 0.005 BTC) to Hero Members/Legendary with a history of good trust. That's just how I operate.

What? That’s not what I suggested at all, this suggestion takes away power from DT1 by making it so multiple DT1 members are needed to add people to DT2...not sure what’s you’re on mate but I don’t think you’ve read my post at all.

I thought I got it right? The people trusted (Depth 2) by the people trusted (Depth 1) by the people you trust (Depth 0).

I keep my depth at 2 because I do like having a fairly large network, but I do also go through and remove those who I feel mis-use the trust system as-and-when I see them. I do wish that we had a trickle-down feature though, just so that a single rogue agent in your trust network who you've missed can't damage things too much. I'm also considering the fact that I'm willing to bet a large portion of this forum is using Depth 2 settings.

This was an idea that I posted on the thread [Proposal] Implement DT1 algorithm for DT2 members in response an idea by LoyceV that each user in DT2 should have at least two inclusions from people in DT1. I've thought about it some more since then and I think that this is an idea I'm prepared to advocate for the whole trust system to use.

The idea is that, alongside your trust depth setting (1-4, default 2), you would have a trickle-down factor setting (1-?, default 2) or any better name that someone can come up with. The idea is that, to be trusted at Depth x in your trust network, a user should be trusted by a number of users in Depth x-1 in your network equal to your chosen trickle-down factor.

I think that a system like this should be implemented evenly across the system to reduce complexity - it should be implemented the same for users in your trust network that descend from your custom trust list or DT.

Depth 0 (duh) and 1 would be completely immune from this trickle-down factor, meaning that DT1 would be unaffected, and you would still trust those on your trust list and those they trust directly as normal. The change would only come in at Depth 2 - so those on DT2 (which IMO has too much power - and I say this as a lowly DT2 myself ) would now need to be trusted by two DT1s, and those on Depth 2 in your custom list (so those people trusted by the people trusted by the people you trust!) would now need to be trusted twice by those on Depth 1 in your custom list. I think this is quite nice actually as it stops your trust network from expanding too massively, and makes it less susceptible to abuse.

Obviously, to stop this system from affecting what you see, you could simply change your trickle-down factor setting to 1 and go back to how it is now. Similarly, if you want to put a high burden on those at deep depths in your list to 'prove themselves worthy', you can turn your trickle-down factor up. I think this would do a good job of putting more accountability in DT2 and letting people be more relaxed about having larger custom trust lists.

Let me know what you guys think, cheers.

I think you'd get a lot of interest in this. I can think of four servers which used Bitcoin and were pretty popular - BitVegas (casino in Minecraft, was stupidly popular), MinecraftCC (for a very long time gave people BTC for breaking/placing blocks and had a very good Bitcoin economy), BitQuest, and The Bit Mines. Three of those are down now unfortunately. I believe MinecraftCC is still up but the BTC system is long gone. They had good lives though.

I think you'd need to tone down your expectations for what people would pay to get in though. I still think someone running a properly licensed casino in Minecraft like BitVegas did would find it a very, very profitable experience - but if you want to do UHC go and run with that

How is this peer-to-peer? By definition if you're having a centralized authority which controls one of the escrow keys, it's not really peer-to-peer. I assume you'd be using a 2-of-3 multisig setup with the website stepping in if there is a disagreement in order to provide the 2nd key to release the funds, there isn't really any other way you could do it.

It's a fine idea, but I don't think you're the first to come up with "ebay with multisig escrow built-in".

'Verified by me' - that's completely meaningless. If you're going to make accusations, you need to back them up with cold hard evidence, or you'll never be taken seriously. Not particularly a road that you want to go down - I don't leave negative trust for stupid posts but there are plenty of people on DT1/DT2 nowadays who do...

Very nice project, it's almost deceiving in how simple it makes private keys look - people have already asked if it's easy to brute force keys because of it, I feel that they don't understand how many combinations of 256 bits you can get!

I would appreciate it if you put a warning in telling people explicitly to use it offline, especially as you encourage people to put in their own private keys to 'visualize' it in your application. Obviously anyone doing that would be crazy to do it online, but there are a lot of newbies in this community nowadays...

I think that's a reasonable enough idea then. Rather than having it just apply to DT2, maybe add in an option to change the minimum number of trusts required for someone a depth below to appear on your trust list, and set the default to 2 - so by default you would trust 2 depths below your trust list, and for someone to appear a depth lower on your trust list they need to be trusted by two people a depth higher. Could be called 'trickle-down factor' or something similar.

I have less of a problem with DefaultTrust right now however than I do with trust ratings being used for disagreements and petty things. There are a few people on DT1/2 who use negative trust against people just because they spouted some opinions they didn't like, and pad their reasoning with some words about how "this makes them untrustworthy". It's very blatant mis-use of the system IMO.

I can get around the main site fine but opening my messages just now was excessively slow. I'm not noticing any slowness anywhere else on the forum though, so it could easily be a hiccup and not really represent any real issues. Or perhaps we're just imagining it and this is completely normal nowadays :')

So you're storing every single trade that happens on every exchange for every cryptocurrency pair? That sounds like it's going to take a fairly rapidly increasing amount of storage. Perhaps a better idea would be to store the prices and volumes for each day, and then store only the trades which are flagged as a wash trade - that allows you to calculate the real volume values without having to store every single transaction.

There is nothing wrong with how DefaultTrust works at the moment in my opinion. The fact that DT1 is now accountable means that someone who is adding members to DT2 who should not be added can be veto'ed out of DT1 by users with sufficient merit. I think that system works completely fine.

Thanks for mentioning DefaultTrust though, it reminded me to go through and fix up my trust list

re: what o_e_l_e_o said: I like that idea but that would massively shrink the size of DT2. I guess that's not necessarily a bad thing?

So this is basically a wealth checker like Mint but for cryptocurrency? Looks nice enough on mobile though I do agree the 8-bit theme isn’t amazing as a default. It’s a good idea - do you plan to add ‘premium’ features as you develop it further?