 Show Posts
|
|
Pages: [1] 2 »
|
Man alive... This is painful to watch. I hope at least one of these coins survives all this nonsense.
Why? If they die from something as simple as this, they should not exist. You can't take down bitcoin with a DDOS attack. I'm not concerned with the DDOS from a technical standpoint, and actually, they're good in a way, since they force devs to up the ante a bit. Rather, these childish wars as whole between competing coins don't paint a pretty picture for merchants who just want to do good, clean business. Imagine China and India duking it out, bombing each others' mints, and burning their banks to the ground. Who's currency do you want to use? Neither? You want to stick with USD?? What's wrong with you? lol |
|
|
|
|
Man alive... This is painful to watch. I hope at least one of these coins survives all this nonsense.
|
|
|
|
|
Ohh, I should also say that, if done right, these pamphlets could be put in comment boxes at a lot of businesses. Just leave a little space in the design for the customer to write a personal note about how much more loyal they'd feel if the business began accepting Bitcoin.
|
|
|
|
How many people are willing to walk up to Random Joe Merchant and ask if he'll accept Bitcoin for something? Not too many, I'll bet. And if you're a merchant, Bitcoin seems quite the investment, doesn't it? So, even if you knew about Bitcoin, even if a customer was brave enough to take the time to try to talk you into it, you might not consider it worth the effort. Let's help alleviate this on both ends by making a Merchant starter package, of sorts, and posting it at the top of places like http://en.bitcoin.it/wiki/Trade. Here's the idea: - Paper pamphlets to be handed out to mom-n-pop shops containing:
- An overview of what Bitcoin is, why it's as legal as bartering with sheep, and why merchants should love it.
- Links to "Bitcoin Accepted Here" signs and buttons available through some place like http://www.cafepress.com/.
- Links to online wallet services.
- A QR code generator built into Bitcoin clients. It would encode a private key, the value associated with the private key, an identity for looking up associated reputation information, and that identity's signature.
- Android and iPhone apps for merchants dealing with the above QR codes.
- Secure and reputable wallet websites that the mobile apps would talk to. Those websites might also help merchants track customer reputation histories for the QR code phase of Bitcoin's existence (NFC devices require too much of an investment, for now).
The last three items would make it trivial for merchants to start transacting with Bitcoin. Also, I know many of these resources already exist in some form. I'm just saying, IMHO, they haven't been put together well, yet. Thoughts? |
|
|
|
Unfortunately, I am not familiar with the code at all, just the theory, so I can't meaningfully comment on the above, but I think now would be a great time to implement whatever's required to get PreAuths working. Bitcoin's in a bit of a slump, and, to quote the other thread: To get an idea of how powerful this is, with this kind of scheme you could include a payment on every packet going over the internet, or all kinds of extreme micro-payments.
|
|
|
|
$995 buyout? Can I have some of that stuff you've been smokin'?
 I'm curious who wants it more... gamers or miners. I'm betting on the former, since it's not a business investment, to them. Well, maybe it is ... *shrugs* |
|
|
|
|
Nobody else? Is the idea not worth developing?
|
|
|
|
Your entire premise is that old keys/users are more trusted. It is dangerous to assume this.
Right now, we extract trust from a majority vote. I'm just saying this could be another source to extract additional trust. Yes, I haven't ironed out all of the details. Let's iron them out. (And thanks for helping with this, btw). An attacker with much less than 50% of the computing power could outrun the legitimate chain on the simple merit that he owns (or illegitimately gain access to) an old enough key...
To deal with this, keys could be registered (see below) and this registration could have a limited lifespan, and could be expired by anyone possessing a copy (if the legitimate owner retains a backup, he could send an expiration notice to the network, despite the attacker having a copy). It would also further reduce the pseudo-anonymity of Bitcoin by correlating all blocks owned by one person by looking at which key signed them.
No, because keys registered as trust keys would have a limited lifespan, and should be expired/replaced on an on-going basis. 50%+1 attacks would likely be hit-and-runs. We probably only need the keys' registration to last a week to improve resiliency. And it would unfairly advantage early-adopters with old keys
Not necessarily. We could require the key to be registered as a trust key at the time of block generation, in which case, during this feature's bootstrapping, everyone would have the default level of trust. Keys cannot be retroactively registered. Thanks again. I hope something useful comes out of this discussion. |
|
|
|
|
Oops, missed that.
Anyway, bootstrapping seems simple; just sign the block with the new key. That becomes your oldest block key. That means you are very young, and have only the default level of trust.
|
|
|
|
Key pairs are not associated to a generation time. They are created at will and are independent of anything else.
But they are associated with a first transaction (which has a date). Plus, I'm not talking about any old key pair: Correct me if I'm wrong, but if you have a miner that mines 50 BTC, you receive those 50 BTC by generating a new key pair, and broadcasting your block solution and the public key to the network. The network then associates 50 BTC with that public key. Therefore, your key pair is associated with that generation, and thus, the time the generation transaction occurred. |
|
|
|
I apologize in advance if this has been discussed already, but my search skills can be pretty terrible. Wouldn't it be possible to partially fix the 50%+1 issue by having clients weigh how much they trust the source of new (and maybe even old) blocks? Basically, every time you generate 50 BTC, you get a new key pair with it, right? This key pair is associated with a generation time. If, when miners generate new blocks, they also demonstrate possession of their oldest key pair by signing something with it, we could decide to trust them more, since they've been around longer. This isn't perfect, but it'd at least up the requirements for prospective attackers. Note: This is half-baked, so please go easy on me.  I've no idea, for example, if it's too much of a burden on the network (particularly lightweight clients who don't have the full blockchain) to verify age like this. |
|
|
|
I believe that what you describe is nearly identical to what is proposed by hashcoin in this thread using nLockTime. Two parties establish two transactions, one from A to B for X BTC and one for the same amount from B to A using the outputs of the first transaction. The second transaction has a lock time in the future. Both tx are broadcast. If no one does anything, the locktime reaches maturity and it looks like a round-trip of X BTC between the two parties with no balances having changed. But, when A wants to give B money, he provides him a signed Tx2 replacement that is for X minus payment amount. Party B can, at any time, broadcast this replacement to reduce the change paid back to A. Any time A wants to give more money to B, they just send another signed Tx2 with even less change back to themself. When locktime is approaching, party B broadcasts the replacement Tx, and the network sees A transfer X BTC to B, and B transfer X-minus-balance to A. Since the original non-locked transaction entered the blockchain days before, all these transactions are guaranteed to be final and confirmed instantly, because the original two transactions were already confirmed by the network, just the amounts are changing. P.S. -- nLockTime is currently disabled in the network right now, but there is a push to have it implemented, partly based on this proposal by hashcoin -- it "solves" all the problems you mentioned in your original post -- replacement Tx's are transferred off-network, accepted instantly, and don't pollute the blockchain This. Thank you!! I was unaware the idea already existed under another name, and could not find it using any search term guesses. |
|
|
|
You seem to have mistyped seconds. And I don't understand why 10 seconds is too high; a debit card swipe takes that long. No; I'm pretty sure it still takes at least a few minutes for verification. I'm not talking about the time it takes for it to show up. But also, even 10 seconds is much too long for the nanotransactions I mentioned. Basically, a website using an IOU-based subscription service needs the transaction to be confirmed before it even sends the response to a user's browser, since it needs to decide whether and how to display various kinds of information, including ads. |
|
|
|
|
FYI - after further discussion on the SC forums, someone mentioned a better name might be "preauths" rather than "tabs," since you're basically preauthorizing the redemption of any IOUs, so the person redeeming them knows instantly that they're good.
|
|
|
|
Would you guys pretty please let me out of here? I have lots of good ideas I'd love to share! Like this one... https://bitcointalk.org/index.php?topic=38044.msg467198Although, someone later suggested to me that the concept was best referred to as "Preauths," not Tabs. Anyway, I have been following Bitcoin since last summer, and have a Masters in CS. My contributions would be of value. Kthx. Edit: Also, could someone move the above topic to the Technical Discussion board? Thanks again! |
|
|
|
|
Man, if I could get out of noob jail, I'd have a solution to enhance the "trust no one"-ness of Bitcoin.
|
|
|
|
Noob jail seems very unimaginative and unbecoming of the community surrounding such a novel technology. Nevertheless, I'll post my quota, and have already setup an auto-refresh to get my 4 hours logged in.  |
|
|
|
Hi, my name's dibbs, and I promise I'm not a spammer.  |
|
|
|
|
