-snip- OK MultiBit HD hat jetzt die neue Wechselgeldadresse. Aber angenommen, ich erstelle mir eine neue Brieftasche mit MultiBit HD und überweise an die erste Adresse dieser neuen Brieftasche 1 BTC. Nun bezahle ich damit nacheinander 8 mal jeweils für 0,1 BTC verschiedene Dinge. Dann wird zwar das jeweilige Wechselgeld an eine jeweils individuelle neue Adresse meiner Brieftasche zurücküberwiesen, aber jeweils auch wieder von dieser letzten Wechselgeld-Adresse die nächste Überweisung getätigt, oder ?
Ja Dann kann man die Kette doch einfach nachvollziehen, oder?
Von außen ist aber nicht klar das es sich um eine Wechselgeldadresse handelt. Die ist nicht anders als andere Adressen. Es könnte ebenso sein das Du 0,9 übweisst und 0,1 als Wechselgeld bekommst. Veranschaulichung: Initial: 1,0 BTC auf a Überweisung 0,1 BTC von a nach b, Wechselgeld 0,9 BTC nach x Überweisung 0,1 von x nach c, Wechselgeld 0,8 BTC nach y Überweisung 0,1 von y nach d, Wechselgeld 0,7 BTC nach z etc. (der Einfachheit halber seien die Transaktionsgebühren hier unberücksichtigt) Oder ist diese Kette nicht so einfach nachzuvollziehen?
Diese TX [1] hat zwei Ein- und zwei Ausgänge. Welche davon ist Wechselgeld und woran erkennst Du das? Ich verstehe das Problem zu schlecht um das gut einzuschätzen zu können, aber es scheint dabei um eine fehlerhafte Implementierung zu gehen, kein generelles Problem von Bitcoin. #504 wird hier [2] als gefixed beschrieben. #510 scheint nur ein mögliches Problem zu beschreiben. Ich vermute, es ist auch bei der individuellen Wechselgeld-Adresse empfehlenswert, wenn man auf Privatspäre achten möchte, dass man jede Sendung erstmal noch durch das blockchain.info SharedCoin jagt...
Wenn Du Dir generell sorgen um solche Probleme machst, solltest Du einen Fullnode wie bitcoin core oder besser armory nutzen. Da dort alle Blöcke ankommen und verarbeitet werden, werden die genannten Probleme gar nicht erst auftauchen. Selbst Headers First (nächster Patch) sollte daran nichts ändern, da keine Header bevorzugt werden die eigene TX beinhalten. Zumindest ist das mein stand. Es macht aber auch keinen Sinn das zu implementieren. [1] https://www.blocktrail.com/BTC/tx/03dc05bb3bf70dc1e009b4170bde55b84b8b75810fac074fac037e87ac5452db[2] https://code.google.com/p/bitcoinj/issues/detail?id=502
|
|
|
Its hard to understand what you think your private key is. The way multibit handles private keys [1] is that it creates a file for each private key, which will only have said key in it. There is also the main wallet file which usually contains all your private keys. If you restore from the main wallet file it should include all newly generated private keys. If you restore from a key backup file it will not. [1] https://multibit.org/en/help/v0.5/help_fileDescriptions.html
|
|
|
Well I'm convinced.
Just shut the site[1] down, till this is resolved. For humanity! [1] gmail ofc
|
|
|
1) The suggestion to run your own SMPT server/domain is plain ridiculous. If you do the encryption on your own computer (as you should, if you want security), then it doesn't matter where the server is and who owns it. It will see only encrypted messages anyway.
... and metadata. It actually makes sense to choose a provider that at least tries to protect your privacy for a number of reasons. #1 While no company can deny a judicial requested they should instist on one. #2 Freemailproviders in general generate data on their own because thats their bussiness model. Thus it makes sense to pay for the service which gives your provider less incentive to profile you and sell it via the marketing department. #3 not everyone you contact might use encryption #4 while any mailprovider should use SSL, e.g. GMX did not for ages. So, as I said, if you don't care about compatibility with PGP users, just use Thunderbird+Enigmail+GnuPG and any e-mail carrier. I know that it will work with Yahoo! Mail. Maybe it will work with GMail, too - I just never tried configuring Thunderbird to use GMail.
GnuPG (same as PGP) is independent of the provider you use. They might not support it on their website, but one should not do encryption on a remote server anyway. 2) Where the server resides is irrelevant. The Swiss cave in to US pressure and broke even their own bank secrecy laws - do you seriously think that a Swiss-based company will refuse to execute a man-in-the-middle attack (like Hushmail did) if the magic word "terrorism" is mentioned by men in suits? If you want security, choose a solution that does not require you to trust the server - not one that relies on the server being in a "trustworthy country". If you do your own encryption, it doesn't matter if the server is based in the USA or elsewhere. The worst the US authorities can do is cut your e-mail service.
While you are correct that the location may not be relevant in certain cases, for actual law enforcement (not those creating a surveilance state hunting "torrorists") juristiction does matter. Besides OP specifically asked for providers outside the US. Encryption can not be provided by a remote server in a meaningfull way. What are you talking about here? 8) Posteo is some German-language crap without even an English user interface. My knowledge of German is limited but it seems to be yet another "trust me" service.
I like that you think something is crap when you dont understand a word about it, makes you look like a very intelligent person. On a more serious note, I actually thought they had an english UI by now.
|
|
|
Freemail = you are the product. GMX is no better than gmail in that regard. Focus on small providers like mykolab [1] (take bitcoin, located in switzerland) or posteo [2] (based in germany, do not require any data, you can pay cash if you wanted to). [1] https://mykolab.com/[2] https://posteo.de/
|
|
|
I actually laughed when I saw that fee. What exactly are you trying to do here? Child pays for parent with high fee? Edit: more like grand child pays for granpa. Just remove the 1st TX from your wallet and create a new one with fee. ![Roll Eyes](https://bitcointalk.org/Smileys/default/rolleyes.gif)
|
|
|
Maybe Admins should add an explanation to the bans, that it is forbidden to evade a ban with another account and that it would result in a permanent ban, for all related accounts. Even if it´s natch, as you can see, most people are not really that smart. Last autumn was the beginning of an eternal september for this forum. ![Cry](https://bitcointalk.org/Smileys/default/cry.gif) The rules are easy to find as long as you look for them and considering that a short term ban is a form of warning OP can just search now and be fine.
|
|
|
Use the datatorrent! Seriously, use it. Most of the time people have problems syncing its because they are connected to a slow node thats used for syncing. Its faster to just get the torrent and do the rest with good nodes. I have a list, but I cant access it atm, but if you look around tech support threads that deal with slow sync you will find it.
|
|
|
i got banned on my other account for fourteen days, today makes fourteen but im still banned on the account
So this is your way of telling the admins that you evaded your ban? its megan fox but it doesnt work
|
|
|
I hear everyone talking about Bitcoin 2.0 but when it will be out?
Its a buzzword for certain alt coins that use the blockchain. Similar to web 2.0 or industry 4.0 there is not a single product or software its refering to
|
|
|
you americans and your bits, now megabits...
|
|
|
I guess the only way here is to look at the blockchain. Can't think of other way. Perhaps ask the customer to bear a higher tx fee so that it gets picked up faster and then refund the customer for paying the extra fee. But that would certainly end up a hassle. Plus it doesn't sound practical.
Technically the transaction won't be in the blockchain until the first confirmation. I guess services like Bitpay monitor unconfirmed transactions across various nodes and have a heuristic algorithm to figure out when an unconfirmed transaction is safe to accept. and a higher than usual fee will not result in miners finding a block faster. Most of the time you pay a fee your TX will be in the next block. Sometimes when there are almost 4k TX waiting [1] for a confirmation you might have to wait 3-4 blocks. [1] as seen a few hours ago (~1830 on this picture https://i.imgur.com/kvH4ODO.png )
|
|
|
I dont know anything about curl but your rawtx is broken... createrawtransaction "[ {\"vout\":1,\"txid\":\"0bfa637d84586fc0acee31409fed3f771c78458bad195eb6f2d16ff5d4eaef07\"}, {\"vout\":0,"txid":\"0ec54adfbd8d83f10c5ffb9429431129cf0f6f9ffb096f3c255458032ece5280\"} ]", "{\"DGV3v6MWakbBzmir9gDNnaU8yV7KGPUTi4\":0.19}"
results in Error: Error parsing JSON:[ {"vout":1,"txid":"0bfa637d84586fc0acee31409fed3f771c78458bad195eb6f2d16ff5d4eaef07"}, {"vout":0,txid:"0ec54adfbd8d83f10c5ffb9429431129cf0f6f9ffb096f3c255458032ece5280"} ], while createrawtransaction "[ {\"txid\":\"0bfa637d84586fc0acee31409fed3f771c78458bad195eb6f2d16ff5d4eaef07\",\"vout\":1}, {\"txid\":\"0ec54adfbd8d83f10c5ffb9429431129cf0f6f9ffb096f3c255458032ece5280\",\"vout\":0} ]" "{\"DGV3v6MWakbBzmir9gDNnaU8yV7KGPUTi4\":0.19}"
results in 21:05:31 Invalid Bitcoin address: DGV3v6MWakbBzmir9gDNnaU8yV7KGPUTi4 (code -5)
which is to be expected since I though this was about bitcoin -_- Hope it helps anyway.
|
|
|
If you have to use bc.i make sure you can see every input and output [1] other explorers [2] do this by default. You spend it the same as before, but this one has 31 outputs. To help you further I made a TX that is spend all 31 inputs, has 2 outputs and is paying a fee. Should be correct. createrawtransaction "[ {\"txid\":\"257299777e0c082c0f9f6b79e2f724a39491eb40d572bf433b1385bd2f7351d7\",\"vout\":0}, {\"txid\":\"257299777e0c082c0f9f6b79e2f724a39491eb40d572bf433b1385bd2f7351d7\",\"vout\":1}, {\"txid\":\"257299777e0c082c0f9f6b79e2f724a39491eb40d572bf433b1385bd2f7351d7\",\"vout\":2}, {\"txid\":\"257299777e0c082c0f9f6b79e2f724a39491eb40d572bf433b1385bd2f7351d7\",\"vout\":3}, {\"txid\":\"257299777e0c082c0f9f6b79e2f724a39491eb40d572bf433b1385bd2f7351d7\",\"vout\":4}, {\"txid\":\"257299777e0c082c0f9f6b79e2f724a39491eb40d572bf433b1385bd2f7351d7\",\"vout\":5}, {\"txid\":\"257299777e0c082c0f9f6b79e2f724a39491eb40d572bf433b1385bd2f7351d7\",\"vout\":6}, {\"txid\":\"257299777e0c082c0f9f6b79e2f724a39491eb40d572bf433b1385bd2f7351d7\",\"vout\":7}, {\"txid\":\"257299777e0c082c0f9f6b79e2f724a39491eb40d572bf433b1385bd2f7351d7\",\"vout\":8}, {\"txid\":\"257299777e0c082c0f9f6b79e2f724a39491eb40d572bf433b1385bd2f7351d7\",\"vout\":9}, {\"txid\":\"257299777e0c082c0f9f6b79e2f724a39491eb40d572bf433b1385bd2f7351d7\",\"vout\":10}, {\"txid\":\"257299777e0c082c0f9f6b79e2f724a39491eb40d572bf433b1385bd2f7351d7\",\"vout\":11}, {\"txid\":\"257299777e0c082c0f9f6b79e2f724a39491eb40d572bf433b1385bd2f7351d7\",\"vout\":12}, {\"txid\":\"257299777e0c082c0f9f6b79e2f724a39491eb40d572bf433b1385bd2f7351d7\",\"vout\":13}, {\"txid\":\"257299777e0c082c0f9f6b79e2f724a39491eb40d572bf433b1385bd2f7351d7\",\"vout\":14}, {\"txid\":\"257299777e0c082c0f9f6b79e2f724a39491eb40d572bf433b1385bd2f7351d7\",\"vout\":15}, {\"txid\":\"257299777e0c082c0f9f6b79e2f724a39491eb40d572bf433b1385bd2f7351d7\",\"vout\":16}, {\"txid\":\"257299777e0c082c0f9f6b79e2f724a39491eb40d572bf433b1385bd2f7351d7\",\"vout\":17}, {\"txid\":\"257299777e0c082c0f9f6b79e2f724a39491eb40d572bf433b1385bd2f7351d7\",\"vout\":18}, {\"txid\":\"257299777e0c082c0f9f6b79e2f724a39491eb40d572bf433b1385bd2f7351d7\",\"vout\":19}, {\"txid\":\"257299777e0c082c0f9f6b79e2f724a39491eb40d572bf433b1385bd2f7351d7\",\"vout\":20}, {\"txid\":\"257299777e0c082c0f9f6b79e2f724a39491eb40d572bf433b1385bd2f7351d7\",\"vout\":21}, {\"txid\":\"257299777e0c082c0f9f6b79e2f724a39491eb40d572bf433b1385bd2f7351d7\",\"vout\":22}, {\"txid\":\"257299777e0c082c0f9f6b79e2f724a39491eb40d572bf433b1385bd2f7351d7\",\"vout\":23}, {\"txid\":\"257299777e0c082c0f9f6b79e2f724a39491eb40d572bf433b1385bd2f7351d7\",\"vout\":24}, {\"txid\":\"257299777e0c082c0f9f6b79e2f724a39491eb40d572bf433b1385bd2f7351d7\",\"vout\":25}, {\"txid\":\"257299777e0c082c0f9f6b79e2f724a39491eb40d572bf433b1385bd2f7351d7\",\"vout\":26}, {\"txid\":\"257299777e0c082c0f9f6b79e2f724a39491eb40d572bf433b1385bd2f7351d7\",\"vout\":27}, {\"txid\":\"257299777e0c082c0f9f6b79e2f724a39491eb40d572bf433b1385bd2f7351d7\",\"vout\":28}, {\"txid\":\"257299777e0c082c0f9f6b79e2f724a39491eb40d572bf433b1385bd2f7351d7\",\"vout\":29}, {\"txid\":\"257299777e0c082c0f9f6b79e2f724a39491eb40d572bf433b1385bd2f7351d7\",\"vout\":30} ]" "{\"12oqrN2uXD9TVyeToSYKySZzm3N3qbyUhR\":0.0041,\"18WgDVuiGY4A4mB8YEmVggEfSmFUUKxDcJ\":0.0045}"
decoderawtransaction 010000001fd751732fbd85133b43bf72d540eb9194a324f7e2796b9f0f2c080c7e779972250000000000ffffffffd751732fbd85133b43bf72d540eb9194a324f7e2796b9f0f2c080c7e779972250100000000ffffffffd751732fbd85133b43bf72d540eb9194a324f7e2796b9f0f2c080c7e779972250200000000ffffffffd751732fbd85133b43bf72d540eb9194a324f7e2796b9f0f2c080c7e779972250300000000ffffffffd751732fbd85133b43bf72d540eb9194a324f7e2796b9f0f2c080c7e779972250400000000ffffffffd751732fbd85133b43bf72d540eb9194a324f7e2796b9f0f2c080c7e779972250500000000ffffffffd751732fbd85133b43bf72d540eb9194a324f7e2796b9f0f2c080c7e779972250600000000ffffffffd751732fbd85133b43bf72d540eb9194a324f7e2796b9f0f2c080c7e779972250700000000ffffffffd751732fbd85133b43bf72d540eb9194a324f7e2796b9f0f2c080c7e779972250800000000ffffffffd751732fbd85133b43bf72d540eb9194a324f7e2796b9f0f2c080c7e779972250900000000ffffffffd751732fbd85133b43bf72d540eb9194a324f7e2796b9f0f2c080c7e779972250a00000000ffffffffd751732fbd85133b43bf72d540eb9194a324f7e2796b9f0f2c080c7e779972250b00000000ffffffffd751732fbd85133b43bf72d540eb9194a324f7e2796b9f0f2c080c7e779972250c00000000ffffffffd751732fbd85133b43bf72d540eb9194a324f7e2796b9f0f2c080c7e779972250d00000000ffffffffd751732fbd85133b43bf72d540eb9194a324f7e2796b9f0f2c080c7e779972250e00000000ffffffffd751732fbd85133b43bf72d540eb9194a324f7e2796b9f0f2c080c7e779972250f00000000ffffffffd751732fbd85133b43bf72d540eb9194a324f7e2796b9f0f2c080c7e779972251000000000ffffffffd751732fbd85133b43bf72d540eb9194a324f7e2796b9f0f2c080c7e779972251100000000ffffffffd751732fbd85133b43bf72d540eb9194a324f7e2796b9f0f2c080c7e779972251200000000ffffffffd751732fbd85133b43bf72d540eb9194a324f7e2796b9f0f2c080c7e779972251300000000ffffffffd751732fbd85133b43bf72d540eb9194a324f7e2796b9f0f2c080c7e779972251400000000ffffffffd751732fbd85133b43bf72d540eb9194a324f7e2796b9f0f2c080c7e779972251500000000ffffffffd751732fbd85133b43bf72d540eb9194a324f7e2796b9f0f2c080c7e779972251600000000ffffffffd751732fbd85133b43bf72d540eb9194a324f7e2796b9f0f2c080c7e779972251700000000ffffffffd751732fbd85133b43bf72d540eb9194a324f7e2796b9f0f2c080c7e779972251800000000ffffffffd751732fbd85133b43bf72d540eb9194a324f7e2796b9f0f2c080c7e779972251900000000ffffffffd751732fbd85133b43bf72d540eb9194a324f7e2796b9f0f2c080c7e779972251a00000000ffffffffd751732fbd85133b43bf72d540eb9194a324f7e2796b9f0f2c080c7e779972251b00000000ffffffffd751732fbd85133b43bf72d540eb9194a324f7e2796b9f0f2c080c7e779972251c00000000ffffffffd751732fbd85133b43bf72d540eb9194a324f7e2796b9f0f2c080c7e779972251d00000000ffffffffd751732fbd85133b43bf72d540eb9194a324f7e2796b9f0f2c080c7e779972251e00000000ffffffff0290410600000000001976a91413d409f255dc40c9ead65b6a1937afd6866efabc88acd0dd0600000000001976a9145265adc735c0024eb1acb53155fa11013f1c57ec88ac00000000
CAUTION! one of the output addresses has a private key I control. Edit: Size of the TX is estimated [3] to be ~5.6 KByte, but the fee is 0.0008 because none of the inputs is confirmed yet. It might help push the TX through. No actually it is that high because I am bad at calculating in my head. [1] https://blockchain.info/tx/257299777e0c082c0f9f6b79e2f724a39491eb40d572bf433b1385bd2f7351d7?show_adv=true[2] https://www.blocktrail.com/BTC/tx/257299777e0c082c0f9f6b79e2f724a39491eb40d572bf433b1385bd2f7351d7[3] https://bitcoin.stackexchange.com/questions/1195/how-to-calculate-transaction-size-before-sending
|
|
|
signrawtransaction 01000000012007ba139a8cb5a1a3fe34bdbb621d2fe90aa10a560c1a1ff8ece1fcd489c7b801000000001976a9141d0b7c5540cfa07fd7eda5238396ab7573c2705788acffffffff0120480100000000001976a9141d0b7c5540cfa07fd7eda5238396ab7573c2705788ac0000000001000000 This should get you the right tx. I changed your amount too... you were about to send yourself 0.0001 BTC and give a 0.00084 BTC miner's tip (remember: any BTC from the input not allocated to an output is the miner's fee) TX decode failed (code -22) Also {"1BkAKAEAK4q5P2FAjhACJeku2JnnuWTDe6 ":0.00940000} I was about to send 0.0094 to myself and give 0 as a fee. createrawtransaction "[ {\"txid\":\"b8c789d4fce1ecf81f1a0c560aa10ae92f1d62bbbd34fea3a1b58c9a13ba0720\",\"vout\":1} ]" "{\"13eaMbuZYdwwyDjv9DH2kP2HKCJMrNdHwH\":0.00094}"
It helps if you use linebreaks when creating the TX. That way you can spot mistakes easier. The code above results in: 01000000012007ba139a8cb5a1a3fe34bdbb621d2fe90aa10a560c1a1ff8ece1fcd489c7b80100000000ffffffff01306f0100000000001976a9141d0b7c5540cfa07fd7eda5238396ab7573c2705788ac00000000 decoderawtransaction 01000000012007ba139a8cb5a1a3fe34bdbb621d2fe90aa10a560c1a1ff8ece1fcd489c7b80100000000ffffffff01306f0100000000001976a9141d0b7c5540cfa07fd7eda5238396ab7573c2705788ac00000000 results in: { "txid" : "27e986fbe3030adf4722da2a5493b7b71de0a9911daef721a647e43115a57c65", "version" : 1, "locktime" : 0, "vin" : [ { "txid" : "b8c789d4fce1ecf81f1a0c560aa10ae92f1d62bbbd34fea3a1b58c9a13ba0720", "vout" : 1, "scriptSig" : { "asm" : "", "hex" : "" }, "sequence" : 4294967295 } ], "vout" : [ { "value" : 0.00094000, "n" : 0, "scriptPubKey" : { "asm" : "OP_DUP OP_HASH160 1d0b7c5540cfa07fd7eda5238396ab7573c27057 OP_EQUALVERIFY OP_CHECKSIG", "hex" : "76a9141d0b7c5540cfa07fd7eda5238396ab7573c2705788ac", "reqSigs" : 1, "type" : "pubkeyhash", "addresses" : [ "13eaMbuZYdwwyDjv9DH2kP2HKCJMrNdHwH" ] } } ] }
I doubt this TX will ever get confirmed without a fee. There are allready ~3k TX with low priority and no fee in the mempool.
|
|
|
I love bitcoin and have a loaded wallet on my smartphone ready to spend, but it doesn't make any economic sense to spend it. For example I bought a new headset today in UK and was quoted £55.97 for it. The bitcoin price at the checkout was 0.2539 BTC. If I spent the BTC and replenished I would have been charged 58.91 for it (+5%), and localbitcoins best offer was £59.40 (+6%) I paid by debit card, despite me loving the tech, I'm not going to pay a 5-6% tax on every purchase using bitcoin. ![Sad](https://bitcointalk.org/Smileys/default/sad.gif) Now is not the time to spend, now is the time to buy coins you can spend when the price is higher.
|
|
|
-snip- Thanks ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) although I would say that I already know a good amount about Bitcoin. I was just curious as to how the transaction process was "sped-up" for business. I've already confirmed what I thought. IMHO - and this is just technical analysis - a company accepting bitcoins should have at least one full node to see the transaction after it was broadcasted. The more nodes the easier it is to determine if the transaction has propagated throughout network or only to the companies node. If the transaction is well known within the network it is reasonable safe to assume that the majority of the miners know about the transaction and will confirm it within the next block as long as the fee is high enough. This can not prevent a carefully planned doublespend attack, but as I am told business owners take more risks when accepting cash as an employee might not be able to determine a fake bill. Should the transaction have no/low fee and/or its priority is low the goods/serivce/coffee etc. could be delayed until the transaction has 1 confirmation. That's the beauty of it, they don't. And this factor drives different exchanges to work on specific tech to outsmart one another.
What? Care to elaborate? What does this have to do with exchanges? What "specific tech" to "outsmart" others?
|
|
|
Yep, definitly bc.i having problems again. The last longish time between blocks was ~12 hours ago. ![](https://ip.bitcointalk.org/?u=https%3A%2F%2Fi.imgur.com%2FyuIQbnT.png&t=663&c=ZMd6q5j1KvMsow)
|
|
|
Cheers, image is showing up now.
Its a pick, for mining, because the confirmations require mined blocks. Is that Multibit HD? Gotta try that ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif)
|
|
|
|