Bitcoin Forum
August 14, 2022, 07:49:16 PM *
News: Latest Bitcoin Core release: 23.0 [Torrent]
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 »
1  Other / Meta / Why doesn't bitcointalk have an SPF or DKIM? on: April 28, 2021, 04:33:33 AM
Why doesn't bitcointalk have an SPF or DKIM?

Theres no TXT records at all for (mail is sent from

root@sebastian-desktop:/var/www# dig TXT

; <<>> DiG 9.16.1-Ubuntu <<>> TXT
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35392
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

; EDNS: version: 0, flags:; udp: 4096
;         IN      TXT

;; AUTHORITY SECTION:        3600    IN      SOA 2036516717 10000 2400 604800 3600

;; Query time: 35 msec
;; WHEN: ons apr 28 06:35:06 CEST 2021
;; MSG SIZE  rcvd: 111


The main domain ( do have a SPF, but for it to be applied to omail, it has to be copied over to, OR have a wildcard (* IN TXT 300 "v=spf1 ip4: -all")
2  Other / Beginners & Help / Trying to understand how fee works... But its kinda weird. on: April 27, 2021, 01:06:30 PM
I made this transaction:
662f7e90b1e3d6f55c06388c07b62e15c6ab672c936372b64e8748c22d3923fb (game purchase on indiegala)

And it had a really hard time getting into a block even tough paying like 0.0004 in fee. Sites listed it like miners didn't want this transaction.

Then I did this transaction:
f3cb81d3a01f03b4e3b473fd3d264d0661d31f9081ca8ec6c544fee08b4ef853 (purchase of 100€ Steam gift card on bitrefill)

and this time, even when paying LESS in fee - 0.00032649 - it got pretty quick into a block and some sites listed it as a preferable transaction for miners.

What causes this?
It seems that 1000 satoshis / kB is the standard, but miners aren't following that what I understand, because the fee's I paid on both transactions were pretty high, and still the first block had trouble getting across.

How do miners calculate which fee to "require"?
3  Other / Meta / Please ban this IP: (IP is hacking bitcointalk accounts) on: July 28, 2018, 09:53:04 AM
Apparently this IP is going around and hacking BitCoinTalk accounts by bruteforcing/hacking/guessing the password:

Have got some weird Ubex advertisment everytime I log in now...

Here is an copy of the email:
4  Bitcoin / Development & Technical Discussion / txfee based on diffculty? on: December 22, 2017, 08:13:10 AM
As you might know, the surge and drop of bitcoin in the latest Days, and the volatility, is mainly because the txfee. Its just not resonable to pay like 20 USD to send a bitcoin transaction just because the value is so high.

txfee is a tool mostly to prevent malicious users from inserting garbage in the blockchain, thus you could have a txfee that stays roughtly constant (in value) over time, regardless of the value of the bitcoin.

Since the value is loosely pinned to the difficulty (higher difficulty = higher value), what about a txfee that is based on the inverse of difficulty?
Basically, a required txfee that is based on the inverse of the highest difficulty observed the latest 6 blocks, and clients will use a txfee that is calculated based on the inverse of the lowest of these 6 blocks.
This will gurantee that the txfee used in a transaction is always higher than required, and that the txfee follows the value (txfee drops when value become higher).

This also gives a opportunity to mine old blocks when value are rising (as old txfee's are more valueable as they are higher), and mine new blocks when value is dropping (as these have higher txfee)
5  Other / Meta / Messages delivered wrong? on: October 16, 2017, 02:36:04 AM
I just got a message in my inbox, that was supposedly meant for a user called "litecoinstake", from "ssetian007".
What happened here? Why did that message end up in my inbox?
6  Bitcoin / Development & Technical Discussion / Bitcoin and the Ransomware problem? on: November 30, 2016, 02:11:00 AM
What can be done to the ransomware problem?
I think Bitcoin is the seed that grown into the ransomware problem. What can be done to protect users?

My tought was some sort of list of "dishonest" adresses, like what have been discussed with stolen money, but that would not work in this case due to the possibility to create one adress per victim, as opposed to bitcoin theft where there is a few adresses involved where the money was stolen from (the victim).

Any ideas how bitcoin could be adapted to make it "toxic" to ransomware authors, while not burning legit users?

My second tought was some "Vote To Refund" scheme, applying to any transaction, but the problem would be that people could spread false screenshots of ransomware just to get free services/products.
Go brainstorm about ideas on how to prevent ransomware on bitcoin's end.
7  Bitcoin / Development & Technical Discussion / Is it possible to generate public keys using public info and other public info? on: August 23, 2015, 07:23:31 PM
Imagine this:
I have a EC keypar Ks and Kp. (secret and public).

Now I have a system with access card for customers. I want them to be able to refill the cards. Each card contains a number, lets say "1013853254", which is denoted "n".

By publishing Kp, a customer should be able to combine Kp and n, in such a way he gains a public key Kp(1013853254).
If a customer sends Money to the associated adress of this public key Kp(1013853254), then the funds
should be spendable by combining Ks with n in such a way I gain Ks(1013853254).

How is this possible with lets say EC primitives?
8  Bitcoin / Development & Technical Discussion / How will XT be good with regards to the packet frame? on: August 23, 2015, 05:55:10 PM
I read about this XT addition, and wonder: Is it really a good idea?

A normal Ethernet frame do have a MTU of 1526, and with headers and other overhead, the resulting frame will be roughtly 1500 bytes large. Subtracting the IP header from this, which is normally 20 bytes, but lets be harsh and overdo a Little bit, and substract 30 bytes. Then we have 1470 bytes left.
Now lets add 1 MB of transactions: 446 bytes.
Also add the block header and block hashes and signatures, and you will scrape off a bit of that too.

Imagine then sandwiching this in a VPN or anything, and you understand why XT is a bad idea because a block will no longer fit into a single packet, and the packet needs to be fragmented.

Wouldn't it better to hardfork the chain to have a faster bliock distribution rate, lets say instead of 10 minutes you hash a block each minute. Then you get the same increased transaction capacity, but with still each block fitting into a single packet. I dont Think there is a risk of softfork due to a netsplit because I have never Heard about a link that takes more than 1 minute to distribute a packet.
9  Other / Meta / Is this mail from legit? on: May 26, 2015, 01:28:40 AM
Is this mail legit?
It has no DKIM signature, a invalid PGP signature and a valid SPF signature.

The host I received it from, does not seem to be asscoiated with bitcointalk either:

C:\Users\Sebastian>nslookup -type=PTR
Address:  2001:470:28:1c:1::1

Icke-auktoritärt svar:     name =

Checking the SPF:
C:\Users\Sebastian>nslookup -type=TXT
Address:  2001:470:28:1c:1::1

Icke-auktoritärt svar: text =
        "v=spf1 mx a -all"
WEEEEEEEEEEW..... Allowing all hosts in the amazon Simple Email Services seems to be a Little bit overly permissible. I don't know if they have any safeguards against fraudulent mail...

Return-Path: <>
X-Original-To: <hidden>
Delivered-To: <hidden>
Received: from server-desktop (localhost [])
   by (Postfix) with ESMTP id 12FFF4C0291
   for <hidden>; Mon, 25 May 2015 22:23:27 +0200 (CEST)
Subject: Bitcoin Forum: Password change required [Invalid signature]
X-AntiPhishing-IP: [BEGIN][][END]
Authentication-Results: unknown-host; dkim=none reason="no signature";
   dkim-adsp=none (unprotected policy); dkim-atps=neutral
Received: from ( [])
   by (Postfix) with ESMTP id F0F814C0291
   for <hidden>; Mon, 25 May 2015 22:23:25 +0200 (CEST)
Received: by (Postfix, from userid 0)
   id AE9AACF1439; Mon, 25 May 2015 20:19:46 +0000 (GMT)
Date: Mon, 25 May 2015 20:19:46 +0000
To: <hidden>
Message-ID: <>
User-Agent: Heirloom mailx 12.5 7/5/10
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Djigzo-Info-PGP-Encoding: PGP/INLINE
X-Djigzo-Info-PGP-Signer-KeyID: C6555693DAB591E7
X-Djigzo-Info-PGP-Signature-Valid: False
X-Djigzo-Info-PGP-Signature-Failure: Signer's key with key ID C6555693DAB591E7
 not found.
X-SPF-Signature: pass ( is authorized to use '' in 'mfrom' identity (mechanism 'a' matched)) receiver=server-desktop; identity=mailfrom; envelope-from=""; client-ip=

You are receiving this message because your email address is associated
with an account on I regret to have to inform you that
some information about your account was obtained by an attacker who
successfully compromised the server. The following
information about your account was likely leaked:
 - Email address
 - Password hash
 - Last-used IP address and registration IP address
 - Secret question and a basic (not brute-force-resistant) hash of your
 secret answer
 - Various settings

You should immediately change your forum password and delete or change
your secret question. To do this, log into the forum, click "profile",
and then go to "account related settings".

If you used the same password on as on other sites, then
you should also immediately change your password on those other sites.
Also, if you had a secret question set, then you should assume that the
attacker now knows the answer to your secret question.

Your password was salted and hashed using sha256crypt with 7500 rounds.
This will slow down anyone trying to recover your password, but it will
not completely prevent it unless your password was extremely strong.

While nothing can ever be ruled out in these sorts of situations, I do
not believe that the attacker was able to collect any forum personal

I apologize for the inconvenience and for any trouble that this may cause.

10  Bitcoin / Development & Technical Discussion / IDEA: Using U2F tokens as secure wallets on: November 23, 2014, 09:18:31 AM
I looked at the U2F specification, and found out that its using secp256r1 EC as their inner cryptography.
I dont know if this is compatible for bitcoin, but I actually got a idea:

Since U2F tokens work in Three different ways:
1: Either storing a EC private key onboard, exporting a public key, and a key identifier.
2: Or, creating a EC private key onboard, wrapping it with a device-specific key, and exports the public key, and encrypted private key.
3: Or, using a nonce to create a EC private key onboard, using a MAC with a device-specific key, and then exporting the public key and the nonce.

After this, authentication is done by signing a challenge along with other parameters, with the EC private key.

Even if theres lots of "useless" parameters inside the signed response, I got a idea, where you carefully create a transaction such as you can extract a "challenge" out of this, send it to the U2F token, and what you get back, is a completely signed transaction that you can transmit to the blockchain.
This MIGHT include generating special adresses using "Vanitygen", (that ends in like touch=1 or such) or actually wasting small amounts of Money (that is destroyed) to send these coins to invalid adresses, but so it match the response format of a U2F token.

To register U2F keys to the bitcoin network, it could be contructed by sending the data returned by the U2F token, in a transaction to be embedded in the blockchain. This would also waste Money, but by sending a minimum transaction, it would only be a couple of cents. A U2F-bitcoin-client then only needs to download the blockchain to be able to recover the wallet.
Since U2F keys are effectively Anonymous, you would need a way to identify which wallet is "yours".

This could be done by simply you provide a public "username" string, that you use along with the U2F key to load your wallet. The wallet would simply be embedded in the blockchain.

Abuse (for example spamming U2F registrations with identical usernames as other users, which means a U2F-bitcoin client has to try them all) is prevented simply because you have to waste Money to register a U2F key. Also by making U2F registrations indistingushable from normal transactions (for example by hashing the username), it would be hard for abusers to find these transactions.

This would mean you could get secure key storage for bitcoin for just about 20$.

If anyone would want to experiment with U2F tokens and bitcoin, here is a token:

Any toughts?
11  Bitcoin / Development & Technical Discussion / [SECURITY] DoS Vulnerability on: April 02, 2014, 08:47:34 PM
Found this DoS Vulnerability. Since its already in the wild on a Swedish forum, here comes:
(Thread in Swedish).

But here comes explaination:

What the OP in the Flashback thread says, its a DoS vulnerability in that Bitcoin allows you to create arbitary transactions containing arbitary data. So what he does, was to search Anti-virus definitions after sequences that is common in BTC network (0x76 0xA9 0x14) - OP_DUP OP_HASH160 length=20bytes.
When he finds this, he then takes the next 20 bytes of that antivirus definition, and convert this to a valid Bitcoin Adress.

He then sends some coins to this adress.

The result: The blockchain will contain occurences of 23 bytes that will match a Anti-Virus definition.
If the def matches a small virus and also the antivirus uses heuristics, then the antivirus will react violently on the blockchain.

He have already done a list of 442 adresses that each is a found entry in a antivirus def database for a specific AV vendor.
He says that if he does a list of all these adresses for all vendors and then make sure each adress get some payment, then EVERY AV vendor will react on the blockchain, which will cause shutdown and erasure of the whole blockchain (because every node's antivirus will erase the BTC chain) and the Death of bitcoin is immient.

Force client to encode the transaction in some unpredictable way that the client cannot Control over, or have the miner to "blind" the transaction with a blinding factor, that then requires a node to cooperate with a miner to successfully execute a attack.
Also the enconding/blinding can also be based on previous block and/or nonce to further make the attack even more difficult.
The encoding factor/blinding factor is of course embedded in the transaction so anyone on the network can "unfold" the transaction and read it in cleartext.

But this also requires that transaction handling does not store raw transaction data in RAM, instead this must be stored in some obfuscated way too. (and of course the obfuscation itself must not trigger AVs)

This prevents the client from making transactions that intentionally will trigger other node's antivirus solutions.
12  Bitcoin / Development & Technical Discussion / Idea: Reject payment system on: March 25, 2014, 09:07:59 AM
Got a new idea, that would actually build on the current bitcoin network, but still allow users to reject payments. (Not forcefully, but informative).

Simple put: A person who want to send payment, to a adress, simply first, broadcasts a message with amount and adress, asking if receiver want to accept this payment
When receiver see it, it will simply say yes or no to that payment, signed with receiver's private key.
If receiver says yes, then bitcoin client will send the payment, if receiver says no, a message in bitcoin client (or if its a casino or similiar - the server side client will forward this to the end user) that tells that the receiver won't accept bitcoins for this adress.

The bitcoin client will simply respect this.
If no one replies to the message in 1 hour, the message will become stale and not relayed.
Reply to the message will also stay in the network for max 1 hour.

This will NOT prevent anyone from "forcing Money into someones wallet" by simply not asking politely.
Anyone can still send payments into a wallet without asking.

Rather, its more a informative decision, to prevent anyone from accidentially sending in bitcoins in "spent" one-time use bitcoin adresses (for example tied with a already-paid order), or have bitcoin casinos avoid sending Money into sender adresses from web wallets (that wont "accept" incoming Money and such Money will be lost) - because if both casino and webwallet follows this standard, then casino will ask the sender adress if they are willing to take a payment, web wallet says no because they can't tie the Money to a user, and casino then displays on the web page: "Hey, we are unable to send you your payout to the adress which sent in the bet, please specify a bitcoin adress that can receive Money: "

In other Words, such a change can be implemented like the "reject" messages update, where old clients will not ask and ignore other client's messages, and new clients will ask and reply to other client's messages.

Servers that accept payments will simply implement the receiver checking on their own, tying it with order system or similiar.
GUI end user clients can implement this receiver checking by having a checkbox next to a user's own adress telling "Accept payments into this adress", where checked = the client will sign "yes" to anyone asking about that adress, and unchecked = the client will sign "no" to anyone asking about that adress.
13  Economy / Economics / Whats happening with bitcoin price? on: February 18, 2014, 07:17:22 PM
Bitcoin price switch up and down from 2X and 1X the current price.
What actually happening?

The intervall between the spikes are only a couple of hours. And diff Changes shouldn't be able to change so much without at least waiting weeks?
14  Other / Meta / Bitcoin forum crash IE10 on: March 30, 2013, 03:04:51 PM
Randomly, when browsing bitcoin forum, it crash IE 10 with this dialog:

Message: "Internet Explorer has stopped working. Windows is searching for a solution on the problem".
After a while, the page reloads and say

"A problem with the website made Internet Explorer to reload the tab".

Maybe some admin could fix this website problem?

Version: latest - 10.0.9200.16521
15  Bitcoin / Bitcoin Discussion / I dont understand Contracts Example 1 on wiki on: May 23, 2012, 07:25:18 AM
I don't understand the Example 1 here:

What would prevent a spammer from getting the money back? Since if the site says he will not allow a early closure of contract, still the contract will expire after (in the example) 6 months of time and the spammer/abusive user will get the coins back...

Basically, we want that the website cannot earn from the contract (if not the user agree to it), and the user will lose from abusiveness, and that theres some automatic "failsafe" in case the website shut down.

** -- Idea Exchange -- **

So basically, for this scheme to work, the website would need some sort of "kill switch" that will spend the coins to a adress which can be proven it does not exist any private key to (or a verifiable charity), which does not require the user's signature. Eg, the contract need to be able to end up in four different states:

1: User & website agree to: Coins coming back to user.
2: User & website agree to: Contract is renewed.
3: Only website needs to agree: Coins are "killed" (or pushed to charity).
4: Contract expires, none need to agree: Coins coming back to user.

(the fifth state - coins go to website - is not useful in this case and is left out).

So lets take some examples:
1: User wants to end the account early. Then the contract is ended early by both the user & website and coins returned.
2: User wants to continue his account. Then the contract is renewed.
3: User is abusive. The website pushes the "kill" button causing the coins to be unspendable. Theres no incentive for the website to push the "kill" button if the user is not abusive, since the website will not earn anything from pushing the "kill" button.
4: The website shut down. Since the "kill" button was not pressed, the contract will automatically expire and user gets his coins back.

But how could such a "kill switch" be implemented in bitcoin terms? The kill switch must be pushable without the user agreeing to it, and both the website and user need to be sure the adress in question ends up nowhere (or a verifiable charity).
16  Bitcoin / Development & Technical Discussion / Taint checker list on: March 05, 2012, 05:33:44 AM
I got a suggestion to remedy the "stolen coin problem".

Make like a list in the bitcoin client, that you can freely fill and delete with bitcoin adresses.
This list could be linked to a file on your harddrive that autoupdates the list. (so you could automagically update the taint list by removing or adding entires by writing to a file on your harddrive, like taintlist.txt , so you can update it with a scheduled task or cron script at regular intervals, or have a "report stolen coin" feature on your webshop that populates the receiving end on your webshop taintlist.txt with the adress in question)

Everytime a payment is received, bitcoin checks the whole trace (blockchain) for the whole chain of the coin until it reach the coinbase.
If a adress on your list is found, the payment is rejected by sending it back to the sender in complete, without involving any change, thus it does not taint your adress.
Also, any event that would indicate that you received payment, would not fire. (so any webshop script would still wait for payment).
If this becomes too computationally intensive for the clients, the taint list could have some sort of "depth" option that allows the taint list owner to set how deep it will check for taints, and -1 would then mean "to the coinbase".
The depth could be set per address tainted, so you can select a depth depending on how "dangerous" the address in question is. (but it will always search deep as the address on taint list with highest depth).
So adding addresses with a depth of 0 would make these addresses blacklisted, so money coming direct from these adresses are sent back, but not if they passed a untainted address before reaching you.
depth=3 would mean the latest 4 adresses the coin passed may not match the entry in taint list.

Note that this is a feature that everyone would be free to use or not use. Keeping the list blank would make the bitcoin client behave as usual.
This does not change the network at all, since it would be the users themselves that elect to download taint lists and populate their lists with. Simply, the taint lists is "I DONT want to receive ANY coins that have been touched these adresses:"

Then MtGox and other people, such as companies that get their funds stolen, can publish lists of coins they will groan upon, and then ordinary bitcoin users could download these lists and populate their taint lists with. MtGox and such can select to keep "stolen" money for the purpose of recovering it to original owner, by not using taintlist feature at all, thus accepting all payments.

The taint list could simply have so you can even "add" a list to the list, and "remove" a list from the list.
"add" a list to the list, would simply add all adresses in the selected text file, checking for duplicates, to the taint list, keeping any records already in taint list.
"remove" a list from the list, would simply remove all entires found in taint list, that match all entires in a selected text file. (This is good if a trusted web site says these coins have been recovered).

Also "addtaint <address> <depth>" and "removetaint <address>" could be added as RPC calls.

Also a new event could be added, like "checktaint <receiveaddress>" that will return you with a list for your backend system that someone attempted to send you tainted coins that matched <taintedaddress> on your taint list, and coming from <senderaddress>, that was sent back.

If you own a private key that correspond to a adress on your taint list, the client will never use those coins as inputs. All coins contained in that adress would be consideded tainted. The balance would show the balance excluding coins in any tainted adress, and those adresses will be highlighted in some way in taintlist, so you can easly remove these adresses from your taint list.
Same would apply if you own any tainted coins, but only those coins would be tainted, not the whole adress you own that the coins belong into. (and the adress that "triggered" tainting of the coins you already own would get highlighted in your taintlist with another color)

Taintlist would simply be for ordinary people to not get stolen coins into their account and then get their account locked at MtGox and such.
17  Bitcoin / Bitcoin Discussion / The bitcoin wiki crash the browser on: November 24, 2011, 12:58:53 AM
I dont know if wiki discussion belong here but I could not find a better forum so I post it here.
Mod is free to move it into right place.

And to the topic. The picture says more than tousands of words, and this appear ONLY if I click a link or visit bitcoin wiki , regardless of the URL to the bitcoin wiki, if I visit it in a NEW FRESH browser window.

Looks like something on the wiki is REALLY badly coded.

Browser version: 8.0.6001.18702

ENGLISH version of the message:

18  Bitcoin / Development & Technical Discussion / Using bitcoin for trusted timestamping? on: November 23, 2011, 10:02:38 PM
What about using bitcoin for trusted timestamping?

Found out this:

Apparently, anything can be used as private key (like SHA("haha") as private key, and then a public key can be generated out of this).

Then, if I take a document, lets say a legal document, some important server logs, bookkeeping records in a company, or anything else that needs a trusted timestamp. Then I take SHA() of the document.
Then I use the result of SHA() as private key (appending zeroes if its too short, and truncating if too long), generate a adress and publickey out of this, transfer X number of BTC (high enough to avoid any transaction fees), to this adress.

Then I use the SHA() private key to transfer the funds back.

After this, I publish the timestamped document along with a link to blockexplorer to verify it.

Now I have created a record in the blockchain, that, anyone having access to the document in question, can check the timestamp in this way:
SHA() of the document in question. Then create public key out of this private key, then make a adress out of this. Check with blockchain which are the *earliest* entry of this adress. The timestamp of that entry is the timestamp of the document in question.

Since the address is empty since we transferred the funds back, theres no funds to be able to withdraw from someone that has the document in question and can generate the private key.

How accurate is bitcoin timestamps and how can they be manipulated?
(either by the one timestamping the document, in effort to defraud someone with a future/history marked document, or some external adversary in order to gain any fraud convience, like manipulating timestamp so a important document seems to be issued after a identy theft credit block is ordered on a specific social security number in order to invalidate the document?)
19  Other / Politics & Society / Bitcoin gets public attention - News article about bitcoin on: July 26, 2011, 12:47:41 AM
Today in the newpaper, there was a article about bitcoins, and how its used for drug trading and swedish goverment has plans on making the currency illegal.

It might be of interest for bitcoiners, but I don't know where to place the thread, move if neccessary.
Here is a link to the article:
20  Bitcoin / Development & Technical Discussion / Bitcoin secure chargebacks (with votes)? on: March 23, 2011, 11:58:00 PM
I have a little idea, I really don't know if this would be a good idea, but just discuss it.

The scheme would work like this:

You can elect to create either a standard non-reversible transaction, or you could create a secure reversible transaction.

A secure reversible transaction works in that way that you attach a note in the transaction, with a brief description of whats expected for return in the transaction, and all data that is needed to verify (this must be in english). The receiver of the bitcoins has to reply to this description to be able to claim the coins. The receiver should then reply in english, and have to supply evidence of having delivered what being asked.

For example a tracking URL to a freight company that makes it possible to track physical goods, a screenshot of transferred funds via paypal, or other evidence that is relevant for the case.

All of this could be described in a help file and a small how-to on how to verify transactions once a user selects to partipicate in secure votes (see later)

The recipient can also reject the transaction, immediately refunding the funds and not publishing any secure transaction over the network, which also refunds the 10 BTC fee minus lets say a rejected secure transaction fee of 1 BTC.

If the recipient ACCEPTS a transaction and affix evidence, the sender can select to ignore this, and then funds are released after a number of blocks (that correspond to 48 hours or something like that), or the sender can "protest" a transaction, for example if the recipient of the transaction tries to SCAM the sender.
If the sender ignores a transaction, the 10 BTC fee goes to the first whoever that calculates the block that releases this transaction.

Now "secure" transactions should have a huge fee (like 10 BTC or something like that). Now to the interesting part:

The bitcoin client should have a option "partipicate in secure transfer votes". If this is enabled, the user gets a popup OR some type of message in a inbox in the client as soon as a "secure transfer" appears on the network.
What all bitcoin users who have enabled "partipicate in secure transfer votes" does now, is to review the transaction as supposed from the sender of the bitcoins, and review the evidence published by the receiver of the transaction.

The user then votes that the transaction should either be chargebacked, or votes that the transaction should let go to the receiver. What the bitcoin client does now, is calculating blocks containing 1 YES or NO vote each containing the transaction, with "Proof Of Work"s and embeds this in the block chain. These blocks are always accepted once the required difficulty are set. (This means, more CPU power = more votes)

When the vote are over, the bitcoin network calculates number of votes for chargeback, and number of votes to release the coins and the majority wins. If theres a draw, the client will also include one extra block which are nearest after the vote expiration time.

The user can then configure how many percent of their total CPU capacity that should go to mining and how much should go to voting.

Now to the time part.
The user could have a specific time to accept/reject a secure transaction. This could be measured in blocks and could be 7 days or something like that and on timeout the transaction is REJECTed. When the user has accepted a transaction, there could be a specific time for voting, lets say 24 hours or something like that. When the vote is over, its tallied and then the network executes the specific action.
The sender could have 48 hours (2 days) to protest a transaction, before its immediately released without vote.

Now to where these 10 BTC in transaction fee should go where: When a vote is over, 10 BTC is divided along all votes that contributed to a specific "good" answer so the adress which casted a specific vote gets (1/X)*10 BTC where X is the total number of Y votes, where Y is the majority vote.

So lets say in a very small bitcoin network with 6 nodes, it works like this:

A = sender
B = receiver
C = random user who have elected for voting
D = random user who have elected for voting
E = random user who have elected for voting
F = random user who have NOT elected for voting.

A sends a "secure transfer" to B with 110 BTC containing a note like this: "100 BTC for a nokia 3310 + 10BTC shipping".

B have 2 choices. If B now REJECTS the transaction, its refunded to "A" minus a 1BTC fee to whoever calculates the block of refund.
If B now ACCEPT the transaction, and affixes a evidence, like this: "Yes, have sent the nokia 3310 now. Here is the tracking: http://www.large-freight-company.invalid/track.php?id=78563495495630247259"

A now gets the transaction in return. The A can now check if he deems the evidence legit, then he just does nothing (or immidiately releases funds) and the coins will be released to the sender, 10 BTC goes to whoever calculates the release block first. Or A can think "this looks like fraud" and click on PROTEST.

On PROTEST, this happens:
The bitcoin system now sends out the transaction for voting and affixes it a coutdown of 24 hours.
Now user C, D and E will get a message in the bitcoin client (in some form of inbox) or a popup with the vote. F does not get anything since he has not elected for voting.

The user C, D and E now checks the evidence and makes a decision if he deems the evidence legit.

Lets say C and D votes for the transaction to go to B, and E votes for the transaction to go to A.

The C and D client will now generate blocks containing "B votes" and push to the network, and E will generate blocks contatining "A votes" and push to the network.
In the end run, 100 blocks containing B votes goes out, and 25 blocks containing A votes goes out. B also gets the transaction. (eg the coins are released and NOT chargebacked)
C calculates 75 B votes, and D calculated 25 B votes.
Now C gets 10 BTC / 100, * 75 = 7,5 BTC in his account for his votes.
And D gets 10 BTC / 100, * 25 = 2,5 BTC in his account for his votes.
E does not get anything since he "voted wrong", which means the network rewards users for voting "right".

The network rejects any votes that are for expired polls or does not contain enough PoW.

This would give a new opportinity to earn BTC, and also helping the network to prevent scams, in this way allowing the network to decide about secure chargebacks.

The voting by "noobs" (which would mostly contain erronous votes) would get outclassed by those having large mining banks which could set their mining banks to only send out votes.

Also to prevent "noobs" from voting incorrectly, there could even be a fee for each vote sent out on 0,01 BTC. That fee you *always* get back along with the reward if you vote right (right as in voting like the majority). If you vote wrong (wrong as in voting like the minority), your 0,01 BTC fee will be lost and put in the pot that is divided along all winning votes. That would make a strong incentive to vote right.

Any thoughts?
Pages: [1] 2 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!