Bitcoin Forum
July 24, 2024, 07:47:09 PM *
News: Help 1Dq create 15th anniversary forum artwork.
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 [2] 3 »
21  Bitcoin / Development & Technical Discussion / Re: Two separate outputs to the same address in one transaction? on: March 08, 2013, 04:31:39 PM
Like someone said you can maybe use the raw transactions API to create one of such transactions. But be careful... Already 2 times someone paid 100 BTC on fees using such raw transactions.

Warning duly noted! I'm not planning to create raw transactions, myself, as I've read at least two posts in the past two days about accidental fee payments. I'm more interested conceptually about whether it's possible with a new client, since it could help further streamline the idea I'm brainstorming for a web-based alternative to bitcoin-otc. (Two outputs to the same address in one transaction could eliminate the need for an "open" and a "close" signal to appear in separate transactions, thereby potentially reducing fees.)

Maybe someone here will want to teach you, or you may read up on it here: https://en.bitcoin.it/wiki/Raw_Transactions

Thanks for the link.
22  Bitcoin / Development & Technical Discussion / Re: Two separate outputs to the same address in one transaction? on: March 08, 2013, 04:06:12 PM
Not possible. The Bitcoin client will not send it and give you an error.
All the outputs need to be different addresses.
I do not see, that this would be a requirement on the protocol level.

Well, may not be a requirement at the protocol level, but if you use sendmany, be it trough Bitcoin-qt or bitcoind, it will throw a error if you insert the same address more than 1 time.

Does this mean it would be possible, if you wrote your own client, to construct a 2-outputs-to-the-same-address transaction?

Two McFlys, with the SAME GUN!!

LOL
23  Bitcoin / Project Development / Re: Working on an idea for simple web-based alternative to bitcoin-otc web of trust on: March 08, 2013, 07:28:00 AM
I updated the website with v0.02 of the pitch. Based on CIYAM Open's and dscotese's feedback, the system now requires fewer transactions for scoring, reduces potential fees, and eliminates the need for the one-off "scorecard" address described in v0.01. I also added some initial FAQs (not comprehensive, but it's a start) based on a lot of gweedo's questions and comments.

Thanks for your help so far. I'm hoping to keep improving. I think next I'll write down my thoughts on the specifics of how the outputs might be structured. (Specifically, I'm thinking about what numbers to use to indicate the opening transaction so AudenX knows which of the two score numbers represents the scoring scale and which represents the final score.)
24  Bitcoin / Development & Technical Discussion / Re: Two separate outputs to the same address in one transaction? on: March 08, 2013, 05:01:44 AM
Not possible. The Bitcoin client will not send it and give you an error.
All the outputs need to be different addresses.

Thank you!
25  Bitcoin / Development & Technical Discussion / Two separate outputs to the same address in one transaction? on: March 08, 2013, 04:36:21 AM
Is it possible (or considered good/bad form) to have two separate outputs in a Bitcoin transaction that go to the same Bitcoin address?

If it is possible, are there any negative ramifications for the user, the blockchain, etc.?

Thanks.
26  Bitcoin / Project Development / Re: Working on an idea for simple web-based alternative to bitcoin-otc web of trust on: March 06, 2013, 09:31:50 PM
This system is so fail, now your making it so hard for people to get trust unless they trade to addresses you deemed trustworthy [...]

Just to be clear, "addresses you deemed trustworthy" means addresses the user deems trustworthy — not addresses that any centralized entity decided are trustworthy. Deciding how to interpret the data generated using the AudenX pattern is a choice each user gets to make for herself.

And, as I mentioned above, there is always this chicken-and-the-egg problem when you're first starting out, regardless of the network. When you're starting a business, you have to attract that first client somehow, then leverage that client's experience into referrals. When you start your career, you have to land that first job, then use that work history to land future jobs. Any trading network that's worth joining — that has trustworthy trading partners in it — should require some effort on the part of the new user who wants to participate.

so you described two different systems can you choose one.

The system I'm describing requires two parts, though, and each needs the other in order to be useful. 1.) Users need data about mutually-agreed-upon transactions that actually occurred, and 2.) users also need a way to interpret that data to help them decide whether to trade with someone. The "signaling" concept deals with 1, and the "trust algorithm" concept deals with 2.

write a clear specification and repost it.

Right, that's the goal. And this thread is for collecting feedback and ideas that will help make that specification clearer and better.
27  Bitcoin / Project Development / Re: Working on an idea for simple web-based alternative to bitcoin-otc web of trust on: March 06, 2013, 08:43:08 PM
your not even attempting to stop scammers take a week build up rep with a few addresses.

It's up to you to decide if it's worth taking a risk on another user with a 1-week history, especially if that new users hasn't done any verified trades with anyone you trust. So while the signaling pattern itself doesn't stop fraud, your chosen trust algorithm can stop fraud, if that algorithm is chosen intelligently.

This is what I mean when I use the phrase "trust algorithm": it's the criteria you choose to interpret the scoring data on the blockchain. Choosing those criteria wisely — choosing a good trust algorithm — is what makes the system useful to any individual user. Designing intelligent algorithms can be done by users, or by third parties focused on studying the blockchain more methodically.

Also you keep saying trying to diminish scam as your history of a transaction grows, that doesn't work, we need a system, that blocks fraud users, from gain any rep and your systems habors that fraud which can't be rolled to any other address the scammer can use. I think you need to re-think this, otherwise it will fail.

Perhaps I'm not using a clear enough example. A scammer could spend a decade creating "fake" trust scores between thousands of "fake" identities so that the scammer might seem at first glance to have a lot of trustworthiness. But if I'm looking at that scammer's address through the lens of my trust algorithm and see that zero of that scammer's transactions have been with users that I know and trust, and no users that are 2nd- or 3rd-degree trading partners with people I know and trust, then that's enough information that I could easily choose not to do business with that person. I could even decide that I won't do business with another user unless 10%, 15%, 90% of their transactions have been with people I already trust. That's the power of the social graph.

This is why I don't propose even trying to lock scammers out of participating in the system. I'm describing an open system for rating satisfaction with transactions that anyone is free to use in whatever way they see fit. The power of the system is that each user can decide how to interpret the rating data for the purpose of guiding their own transaction decisions.
28  Bitcoin / Project Development / Re: Working on an idea for simple web-based alternative to bitcoin-otc web of trust on: March 06, 2013, 08:13:39 PM

I'm not trying to create a system that's impossible to game

Right there you have already lost so many people cause we need a system you can't game. I think it is back to the drawing board.


Maybe we have a philosophical difference here.

The way I see it, trusting someone inherently requires taking a risk, because even a perfect and complete representation of a party's behavior in previous transactions can never ensure that they will behave the same way in the future.

Even with your hypothetical trust-rating system that's impossible to game, a person who has always behaved honorably in the past can choose to forfeit their reputation by scamming someone. So even if such a system were possible to build, even if that system were perfect from an identity-verification standpoint, it could never eliminate all fraud.

All human interaction entails risk. If humans had waited for a 100% foolproof method to ensure that they'd never get hurt in their interactions with other humans, there would have been no human interaction to date. Instead, humans take the risk of interacting, and the smart humans decide which interactions are worth the risk using a number of indicators that help to predict another person's future behavior.

Therefore, it seems to me that an easy-to-use system that helps build trust, even if it's imperfect, will still be a useful tool for parties who want to conduct honest trade.

I reiterate my point here that my goal is to create a system where the incentive to scam diminishes as your history of honest transactions grows. It's like the hypothesis in Satoshi's white paper about what happens in the event that someone accumulates > 51% hashing power: at that point, the incentive to behave honorably and keep the market functioning would, for someone acting in their financial self-interest, be higher than the potential gain from defrauding the Bitcoin community and driving users away in fear.
29  Bitcoin / Project Development / Re: Working on an idea for simple web-based alternative to bitcoin-otc web of trust on: March 06, 2013, 06:40:01 PM
A couple things, I am paying you for trust. Why?

Fair question.

I'm not sure if your phrase "paying you for trust" means that "Alice is paying AudenX for trust" or "Alice is paying Bob for trust". Perhaps you mean both. Either way, the idea is not that people are paying "for trust", but rather to incorporate data into normal blockchain transactions that adds a layer of meaning that indicates trust/satisfaction. The amounts involved in this signaling can be trivially small — far smaller than what would constitute meaningful payment amounts — and you could even incorporate the signal into some part of the transaction that isn't an output value.

The idea is not to create a way for someone to "buy" credibility. Credible trust would have to be built up over the course of many transactions. You can't just pay 1,000 BTC to AudenX to get an awesome trust score.

What the difference in me making a thread on here saying "Alice and Bob had a smooth transaction".

The difference between using the blockchain and you making a forum thread that says "Alice and Bob had a smooth transaction" is that we can verify that transactions on the blockchain actually occurred between Alice and Bob's addresses, and (most likely, unless their wallets were compromised) that those transactions were voluntarily entered into by Alice and Bob.

You could of course watch the Blockchain for transactions that match the AudenX pattern and then report them on a forum thread, but the transactions would actually have to be created by Alice and Bob before you could report them on the thread.

I can't rate someone in the negative that isn't good, now I just had a transaction which I lost money and now I have to send you something to rate this person kinda like salt on the wounds.

No, this is incorrect. There are lots of ways we could choose to signal negative experiences. For example, if we standardized around a system where "scoring" values were 1 Satoshi at the low end and 20 Satoshis on the high end, a final rating of 1 from Alice to Bob could indicate that Alice is totally dissatisfied with the transaction.

However, the scale that I was suggesting in my original posting would allow participants to arbitrarily choose the number that means "satisfied". Alice could initiate a transaction with a baseline score of 13, and if she decided to award Bob a final score of 14, that would be like saying "satisfied + 7%" — basically meaning Bob went above and beyond the call of duty. Or she could award a score of 1 to Bob, which basically means he was awful.

I think I've read somewhere that you can have output amounts that are 0, so if that's actually possible I guess Alice could use 0 as a value to indicate that she was totally scammed.

In any event, regardless of the rating scale used, if you pick a standard way to interpret the numbers, then you can have a rating system that's as granular as you want, with both positive and negative ratings possible.

What about a scammer, how does he not make many profiles on your site to boost up his rating? I mean spending .01 to boost up ratings and sending 50btcs around to make your system think there is transactions happening?

There is nothing to stop a scammer from creating many Bitcoin addresses and using them to build up the appearance of trustworthiness. This is true on bitcoin-otc as well.

Also, just to be clear, you wouldn't be creating "profiles on my site". The "identity" of someone on AudenX is simply a Bitcoin address. You could generate that address however you like.

Similar to bitcoin-otc, you can see that the AudenX scoring system would allow you to create your own sort of personal "trust algorithm" based on your trading network, so that you value apparent trustworthiness in a stranger more highly if they've already received a trust score from someone you trust. The social graph matters. You could choose to ignore the apparent trustworthiness of someone unless they meet a high standard — like maybe they have to have 100 or more satisfactorily concluded transactions with people you already trust before you do business with them. In the future, users might not even want to build their own algorithms for calculating trustworthiness — they could just rely on third-party algorithms created by companies that study the blockchain.

There's of course the chicken-and-the-egg problem of how a new person in the network gets started building trust. Just as in real life, though, you trust someone with a little bit to begin with, and then more over time, rather than trusting a stranger with $1,000,000 of your money right off the bat. This could mean that new people get their first scores by trading with friends, or people whose real-life identities they already know.

I'm not trying to create a system that's impossible to game, and I'm not interested in trying to create a bulletproof identity-verification system. The goal is to create a system where the cumulative value of your trustworthiness is greater than the incentive to scam. Basically, if you spent a year building a history of trustworthiness, there would be a monetary incentive to continue your good behavior, because you have a bigger pool of trading partners interested in trading with you. It's the same reason people strive to keep a high credit score.

I am sorry but if this the best trustworthy approach then I would stick with GPG keys and bitcoin-otc.

I don't see any problem with that. If you're comfortable with bitcoin-otc, you like using it, and you like your trading partners in it, then you're all set. But as CIYAM Open notes, and I think many people would agree, there are really a lot of potential users of Bitcoin for whom using IRC and GPG keys would be a major barrier to entry. Getting a bitcoin wallet and learning to use it is, for people unfamiliar with IRC and GPG keys, much more accessible. And a wallet is all you'd need to get started using AudenX.
30  Bitcoin / Project Development / Re: Working on an idea for simple web-based alternative to bitcoin-otc web of trust on: March 06, 2013, 08:55:15 AM
For this to work best I would recommend that it be documented in an open way so that hopefully down the track other rating sites will use the same implementation (rather than ending up with multiple incompatible ones).

Agreed!

[ ... ] the website's success will be in simply and hopefully powerfully being able to let you "view" a buyer/seller without having to understand the low-level stuff (although important for that to be available for other sites to display also so you can be assured that the website isn't misreporting).

Also agreed. A near-ish term aspiration for me would be to build something like blockchain.info for viewing trustworthiness of BTC addresses.

Being able to "filter" out buyers/sellers based upon their obscurity (for example) would be a nice feature for the website to contain.

Guess I'd better start tracking feature requests Smiley
31  Bitcoin / Project Development / Re: Working on an idea for simple web-based alternative to bitcoin-otc web of trust on: March 06, 2013, 08:23:24 AM
Some further ideas: https://bitcointalk.org/index.php?action=printpage;topic=87339.0

(a bit more complex but would provide a much more powerful system)


Looks like we're sharing a brain wave! Thanks for posting; it's encouraging to see that others are thinking along these lines.

"Alice-to-Bob-Close" signal (piggybacked on Alice's payment to the grocery store):

INPUT: 1AliceAudenXIdentityAddress
OUTPUT1: 1GroceryStorePayment (0.75 BTC)
OUTPUT2: 1BobAudenXIdentityAddress (0.000115 BTC) <-- 115% satisfied
OUTPUT3: 1AudenXAddressOfRecord (0.00001 BTC)

"Bob-to-Alice-Close" signal (piggybacked on top of Bob's dinner date tab):

INPUT: 1BobAudenXIdentityAddress
OUTPUT1: 1DinnerAndAMovieDate (1.10 BTC)
OUTPUT2: 1AliceAudenXIdentityAddress (0.000090 BTC) <-- 90% satisfied
OUTPUT3: 1AudenXAddressOfRecord (0.00001 BTC)

What do you think?
[ ... ] I don't think you need the Open Transaction output that Bob put on his Wordpress payment. It's up to Alice, when she gets the socks, to register that Bob did a good job, and only if Bob lets her know that his address is registered at AudenX. [...] 

And of course, AudenX would tell people "If you're not satisfied with a vendor, you can register that publicly by adding two outputs to any transaction, one for 0.00000XXY (AudenX has 3-digit codes for all kinds of Customer Service ScrewUps) to 1AudenXAddressOfRecord, and the other for 0.00000YYY (The "IDENTIFIER" 3-digit code) to 1ThatVendorsAudenXAddress.

This comment makes me realize that I've been thinking about symbolizing "trustworthiness" in a slightly different way from bitcoin-otc web of trust.

Rather than allowing users to simply assign a trustworthiness score to other users whenever they please, I'm imagining a system where users' satisfaction scores are only counted when the parties have actually done business together.

The reason I think it's good to require a reciprocal "open" signal from Bob is that this lets AudenX know that Bob has agreed to whatever transaction Alice is trying to initiate. Alice can't just spam Bob with positive or negative scores if he hasn't agreed to do business with her.

My desire here is for AudenX "trustworthiness" to reflect a party's performance in actual, mutually-agreed-upon trades. If I'm truly interested in doing business with Bob, I think "reputation" that's based on unidirectional scores (e.g. iPhone app reviews, reddit upvotes) isn't as useful as knowing the satisfaction of another person who entered into a mutually-agreed-upon trade with Bob.

Requiring reciprocal scoring also helps extend the concept of trustworthiness beyond the seller: not only do sellers have to demonstrate that they're good to do business with, but buyers need to play nice, too. (E.g. If you're a seller, you might want to steer clear of that jerk buyer who always leaves 0% reviews, both to save yourself the headache and to protect your own trustworthiness score from trolls.) This creates an incentive for parties to work together to keep overall satisfaction high, rather than putting all the power in the hand of the buyer-reviewer.

Reciprocal "open" and "close" signals also seemed important to me, so that AudenX can calculate an identity's "completion rate" for trades, and so that users are motivated to finish their business and rate each other in a timely way.
32  Bitcoin / Project Development / Re: Working on an idea for simple web-based alternative to bitcoin-otc web of trust on: March 06, 2013, 07:02:22 AM
Can you just post the idea here, cause your website is completely down, for me.

Edit 7-March-2013: Website now reflects most recent pitch. Version 0.01 pitch archived here.

===

Sure! The website currently contains simply my v0.01 marketing pitch for the idea. dscotese's feedback above has already got me revising for the v0.02 pitch Smiley

Here's the original pitch:

Show off your trustworthiness with AudenX.

AudenX watches the Bitcoin blockchain for a simple pattern of small Bitcoin transfers that signals two parties' satisfaction with a transaction. Cumulatively, AudenX trades can be used to gauge a party's trustworthiness.

How does it work?

Step 1

Well, Alice, first you must grab a partner. That guy Bob who wanted to sell you a pair of alpaca socks for 1 Bitcoin? Yeah, he'll do just fine.

Each of you will need your own Bitcoin address to serve as your AudenX identity for your transaction. Make sure to keep the private key for your AudenX identity secure, because you'll want to keep using this identity to build the public record of your trustworthiness.2

Step 2

Create a new "scorecard" for your transaction.

Your scorecard is a new Bitcoin address, meaning an address that's never appeared on the blockchain before. Use any Bitcoin address generator or wallet that you like to create this address. The only requirement is that you, Bob, or both of you together must be able to make payments from the scorecard address.

Step 3

Pick a number, any number. (Well, any non-zero, non-negative number.)

Say you picked the number 10. Now 10 will represent the score for a completely satisfactory transaction experience.

To initiate the transaction, you and Bob each send 10 Satoshis (or 10 microBitcoins, or any order of magnitude you like — just keep it relatively small) to your scorecard address.

Once both transfers are complete, send the total scorecard balance (20 Satoshis, in this case) to AudenX3. That's a signal to AudenX that Alice and Bob have just started a transaction, and as an added bonus the transfer helps fund future development of services for the AudenX community.

Step 4

Make your trade! Sling those socks, and pay that coin. You can conduct your trade however you want, and you don't need to use your AudenX identity addresses to send or receive payments related to the trade.

Step 5

Rate your trade. Were you satisfied 100%? Then send another 10 Satoshis to your scorecard. Was Bob satisfied? Then he sends another 10 Satoshis to the scorecard address. Once both transfers are complete, send the balance (20 Satoshis) to AudenX. That's a signal to us that Alice and Bob finished a transaction, and that transaction scored 20 out of 20. Way to go, you two!

And you're done!
 
33  Bitcoin / Project Development / Re: Working on an idea for simple web-based alternative to bitcoin-otc web of trust on: March 06, 2013, 06:07:28 AM
If and when miners start relying on transaction fees much more than block rewards, these transactions won't get confirmed as easily as they are now.  So I'm thinking of another idea that doesn't require them.

I was also worrying about confirmation fees, but you came up with a smarter idea to address that than I did. I had simply been imagining a future scenario where the value of building your trust record is worth paying the incremental miner fees to "register" each transaction using the AudenX pattern, but that might be too optimistic if confirmation fees become significant.

Instead of making two new transactions to reflect the beginning of and subsequent satisfaction with a transaction X, put that information into an input in the next transaction N from an address known to belong to the same user who paid BTC in transaction X.

That seems like a step in the right direction. Not sure if this is exactly what you are describing, but after reading your response I started thinking the signaling pattern could be modified as follows. In addition to reducing cumulative confirmation fees, it eliminates the need for a "scorecard" address:

Alice (1AliceAudenXIdentityAddress) agrees to pay 1 BTC to Bob (1BobAudenXIdentityAddress) for a pair of alpaca socks. Both parties want the transaction to be reflected on their AudenX (1AudenXAddressOfRecord) trust histories.

Alice kicks off the AudenX process by creating a Bitcoin transaction. Let's call this transaction the "Alice-to-Bob-Open" signal.

INPUT: 1AliceAudenXIdentityAddress
OUTPUT1: 1BobPaymentAddress (1 BTC)
OUTPUT2: 1BobAudenXIdentityAddress (0.0001 BTC)
OUTPUT3: 1AudenXAddressOfRecord (0.00001 BTC)

Bob confirms that he's participating in this AudenX process by creating a Bitcoin transaction in response. Since he doesn't owe Alice any Bitcoin, he piggybacks his AudenX signal on top of a payment he owes to Wordpress. Let's call this transaction the "Bob-to-Alice-Open" signal.

INPUT: 1BobAudenXIdentityAddress
OUTPUT1: 1WordpressPaymentAddress (0.5 BTC)
OUTPUT2: 1AliceAudenXIdentityAddress (0.0001 BTC)
OUTPUT3: 1AudenXAddressOfRecord (0.00001 BTC)

AudenX, having received two payments, examines the associated transactions and can recognize the signals Alice-to-Bob-Open and Bob-to-Alice-Open. AudenX ignores any transaction outputs that don't fit the signaling pattern. Now AudenX knows that Alice and Bob have started a transaction. (Until AudenX sees the closing signals from Alice and Bob, the AudenX pattern is incomplete. Incomplete patterns can reflect negatively on an AudenX identity's trustworthiness, because it indicates that two parties haven't resolved their transaction, which might indicate a dispute, or the inability of one or both parties to signal correctly.)

When Alice and Bob complete their alpaca-socks-for-Bitcoin trade, they can indicate their satisfaction with the trade as being equal to, less than, or greater than the baseline score (which they each set at 0.0001 BTC in this example). Say Alice is 110% satisfied with the socks she's received, but Bob's a bit annoyed that Alice took so long to respond to his email requesting her shipping address, so he's just 90% satisfied.

To save on confirmation fees, the parties wait to send their final AudenX satisfaction scores until their next Bitcoin transaction. Then they create transactions like these:

"Alice-to-Bob-Close" signal (piggybacked on Alice's payment to the grocery store):

INPUT: 1AliceAudenXIdentityAddress
OUTPUT1: 1GroceryStorePayment (0.75 BTC)
OUTPUT2: 1BobAudenXIdentityAddress (0.000115 BTC) <-- 115% satisfied
OUTPUT3: 1AudenXAddressOfRecord (0.00001 BTC)

"Bob-to-Alice-Close" signal (piggybacked on top of Bob's dinner date tab):

INPUT: 1BobAudenXIdentityAddress
OUTPUT1: 1DinnerAndAMovieDate (1.10 BTC)
OUTPUT2: 1AliceAudenXIdentityAddress (0.000090 BTC) <-- 90% satisfied
OUTPUT3: 1AudenXAddressOfRecord (0.00001 BTC)

What do you think?
34  Bitcoin / Project Development / Working on an idea for simple web-based alternative to bitcoin-otc web of trust on: March 05, 2013, 05:33:52 PM
Hi there.

I'm brainstorming the minimum viable product for an alternative to bitcoin-otc. My current idea is summed up here on my website. I'd love for you more experienced members of the Bitcoin community to tear apart the idea so I can make it better. Comments welcome.

Thanks!

===

Edits:

7-Mar-2013: Updated pitch. Archived v0.01 pitch, replaced with v0.02 pitch.
35  Bitcoin / Bitcoin Discussion / Re: News in multisignature support? on: March 05, 2013, 03:28:27 PM
What do you want it for?

I'm brainstorming a simple web-based alternative to the web-of-trust trading possible with bitcoin-otc, and I thought it would be nice to provide instructions or even web-based tool to help initiate 2-of-2 or n-of-m multisignature transactions. But it's not a showstopper, so I'll move forward hoping to add it in the future.

If you're thinking of hardware wallets for virus protection, there is some progress being made on that ...

Well, hot diggity! That's cool. I'll add that to my list of things to watch for.

I wouldn't say NO progress is being made, but there has been a long detour because we need a secure way of telling you WHO you are paying to make multisignature work securely. Otherwise we could have the most nifty, secure multisig system in the world that fails because you THINK you're paying 1kqHKEYYC8CQPxyV53nCju4Lk2ufpQqA2 but a crafty attacker makes you pay them at 1kqHLFyZDBDoPDYwSEtjv5CWka42uGqA2 instead.

Okay, that makes sense. (Although I'm sure as I keep learning more about Bitcoin, I'll realize that I totally didn't understand it right the first time Smiley )

So I've been spending most of my time implementing "the payment protocol." I'll write more in a Foundation blog post on Friday.

Payment protocol messages will be part of the information that will be sent between devices or people to make multisig transactions work.

Excellent! Bookmarked the blog and looking forward to reading your post.

Thank you, gentlemen.
36  Bitcoin / Bitcoin Discussion / News in multisignature support? on: March 05, 2013, 01:43:43 AM
I've been searching for news (hopefully more recent than this) about how to create multisignature transactions. Are there currently any GUI-based ways to create multisignature transactions? This page on Blockchain.info looked promising, but it appears that this feature has been taken away.

Alternatively, are there any active developer discussions happening outside this forum relating to multisignature support?

Thanks for any leads!
37  Economy / Economics / Re: Bitcoin , deflation and slashdot on: March 01, 2013, 06:15:46 AM
Great topic! Thanks for posting.

Yes, I see a lot of Bitcoin skeptics and detractors online who don't seem to understand the divisibility of Bitcoin. Maybe this is a naming issue — the idea of a "coin" is pretty firmly ingrained in peoples' experience as an indivisible physical unit, with a penny (or international equivalent) being the smallest unit. So some Bitcoin commentators end up thinking mistakenly that 1 BTC valued at $33 means someone would have to round all Bitcoin transaction prices to the nearest $33. Whoops! Hopefully these commentators will encounter some kind Bitcoin advocate willing to educate them Smiley

Per the deflation issue: There are different (sometimes conflicting) definitions of deflation, and lots of different economic circumstances that can cause deflation, so it's hard for much meaningful conversation to happen without very precise definitions of terms. I am no economist, but as an armchair Austrian school enthusiast, I've found Murray Rothbard's discussions of deflation to cut through the vitriolic noise on the subject.

A helpful article on deflation from Mises.org excerpts some of Rothbard's thoughts here (the whole article is worth reading, though!):

Quote
Just as inflation is generally popular for its narcotic effect, deflation is always highly unpopular for the opposite reason. The contraction of money is visible; the benefits to those whose buying prices fall first and who lose money last remain hidden. And the illusory accounting losses of deflation make businesses believe that their losses are greater, or profits smaller, than they actually are, and this will aggravate business pessimism.

It is true that deflation takes from one group and gives to another, as does inflation. Yet not only does credit contraction speed recovery and counteract the distortions of the boom, but it also, in a broad sense, takes away from the original coercive gainers and benefits the original coerced losers. While this will certainly not be true in every case, in the broad sense much the same groups will benefit and lose, but in reverse order from that of the redistributive effects of credit expansion. Fixed-income groups, widows and orphans, will gain, and businesses and owners of original factors previously reaping gains from inflation will lose. The longer the inflation has continued, of course, the less the same individuals will be compensated.

Some may object that deflation "causes" unemployment. However, as we have seen above, deflation can lead to continuing unemployment only if the government or the unions keep wage rates above the discounted marginal value products of labor. If wage rates are allowed to fall freely, no continuing unemployment will occur.
38  Bitcoin / Bitcoin Discussion / Re: [Voting] Bitcoin Slogan / Tagline on: March 01, 2013, 03:10:53 AM
I don't get it. Is it a modification of something popular?   Is it a play of words: cryptography/many people??

A 2011 forum discussion covers some of the layers of meaning. I'm probably not adding anything to the discussion, but here are the layers of meaning in my mind, and I like them all:

  • So, "strength in numbers" is a commonly used phrase in English, and although I'm no Latin scholar, the fact that the Latin phrase shows up in a bunch on Google search results suggests to me that it's a pretty old expression. Kudos to the wonderfully terse Romans. If they said it, it must be true.
  • Cryptography's utility is due to mathematics, so we can consider the "strength" of cryptography to be due to "numbers" (okay, that's a little simplistic for a crypto definition, but simplicity and double entendre are what's nice about the slogan).
  • A currency's utility is partly due to the number of people who accept it, so we can consider the currency's "strength" to be due to "numbers" of users.
  • Bitcoin's utility is based on both the strength of cryptography and the size of the user base, so its "strength" is due to "numbers" both ways.

My only change to the slogan would be to write it as "Strength in Num฿ers".
39  Other / Beginners & Help / Re: Whitelist Requests (Want out of here?) on: February 25, 2013, 06:44:17 AM
I'm a software user experience and visual designer with a great deal of interest in sound money, alternative currencies, and Bitcoin.

I'd like to participate in forum discussions about how trust and reputation can be addressed in the bitcoin trading ecosystem, either with future additions to bitcoin or by developing an alt-chain designed to support trust-based or reputation-based trade.

Hope that's enough to be whitelisted! If not, PM me and let me know what else I can do to convince you.

Thanks.
40  Other / Beginners & Help / Re: Official Newbie BitInstant Support Thread (Active Customer Support) on: February 25, 2013, 06:35:45 AM
Just thought I'd post my retroactive review of BitInstant here.

Although nearly-free direct transfer from Dwolla to MtGox would have been my preferred method of transferring USD into an exchange, I decided to eat the 2% fee from Bitinstant to transfer funds from my Dwolla account to the Bitstamp exchange so that I could get started buying Bitcoin while waiting the 10+ days for my identity verification to happen on MtGox (yeah, new account approvals got really slow while the price was climbing from $18 to $28).

Every single time I transferred from Dwolla to Bitstamp using Bitinstant, I got the "Dwolla verification failed — unable to locate" error that numerous posters above have mentioned. Every single time, I emailed support@bitinstant.com. Every single time, Rachel at customer support replied within 2-4 hours of start-of-business-day (Pacific time) and manually processed the transaction.

Because of the relatively prompt (during business hours) email support, this process still turned out to be better than any of the alternatives I considered, but it was still frustrating. I'm left wondering ...

Has anyone had a successful Dwolla-to-(whatever) transfer process using Bitinstant, which didn't require manual processing of some kind? Is this location/verification issue a Dwolla problem, a Bitinstant problem, or both?
Pages: « 1 [2] 3 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!