Bitcoin Forum
June 27, 2022, 06:17:15 AM *
News: Latest Bitcoin Core release: 23.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 3 »
1  Bitcoin / Armory / Damaged wallet on: January 06, 2017, 01:56:51 PM
I have a problem with a wallet.

It all began when I sent a transaction and when I clicked on it on the transaction list I got the "The transaction you requested be displayed does not exist in Armory's database" alert.

The problem persisted after a rebuild and a rescan.

I then tried to change the comment of the transaction as it seemed the wrong comment was displayed. The wallet completely disappeared from "Available Wallets".  I fixed it with "Fix Damaged Wallet" and it reappeared but the offending transaction still "does not exist in Armory's database. " Every time I try to change a comment on this wallet it disappears and I have to fix it.

Recovery.log has been sent via private message.

I'm worried this can be the start of a bigger problem with that wallet - please advise.

UPDATE: I realized that on  "Wallet Properties" no addresses were displayed for this wallet. On "addresses used" it said no addresses were used (which is wrong) but the total computed addresses seem right. I computed 100 extra addresses and now the wallet is "scanning" - I will updated when the scan is finished. I'm using Armory 0.94.1
2  Economy / Games and rounds / 1000 BTC Giveaway - what might be happening. on: August 03, 2016, 04:38:13 PM
1) The coins come from a 2013 address, not linked at all with Bitfinex. SOURCE
2) That address is very probably linked with the inputs.io scam/hack. SOURCE
3) The person who declared the giveaway will post an address himself and send the money to that address
4) He will then be able to claim he got the money from a giveaway and not from hacking/scamming

EDIT: in case it's not clear I'm speculating on what's happening in this post.
3  Bitcoin / Bitcoin Discussion / Bitcoin is now stronger than ever. on: July 20, 2016, 11:09:48 PM
I will just leave this here:

Genesis block, Bitcoin: The Times 03/Jan/2009 Chancellor on brink of second bailout for banks

Block 1920000, Ethereum: Financial Times 20/Jul/2016 Ethereum bailout complete.
4  Local / Español (Spanish) / Treinta detenidos en una operación en centros de "minería" de bitcoin on: May 25, 2016, 09:33:57 AM
A las 11:30 darán más info:

http://www.elmundo.es/espana/2016/05/25/57455d5de5fdea4a3a8b45f8.html

http://www.levante-emv.com/sucesos/2016/05/25/detenidos-valencia-macrorredada-descifrar-codigos/1422769.html

http://www.farodevigo.es/sociedad/2016/05/25/golpe-policial-mineria-bitcoin-espana/1467412.html

http://www.abc.es/sociedad/abci-treinta-detenidos-gran-operacion-centros-mineria-bitcoin-201605251023_noticia.html

De El Mundo:

Quote
Treinta personas han sido detenidas en siete provincias, entre ellas Madrid, en una de las mayores intervenciones de Europa en centros de la denominada "minería" de la moneda virtual bitcoin, en el marco de una investigación sobre distribución ilícita de contenidos de televisión de pago.

La Policía Nacional informa en un comunicado de estos arrestos, llevados a cabo en la operación conjunta con la Agencia Tributaria y que ha contado en su fase final con la colaboración de Europol y Eurojust.

Las detenciones han tenido lugar en Córdoba, Málaga, Valencia, Barcelona, Madrid, Palma de Mallorca y Lugo.

La "minería" de bitcoin consiste en descifrar, con equipos informáticos especializados, códigos que permitan legitimar y asegurar la seguridad de transacciones con esta moneda virtual.

Los responsables de la investigación de la Comisaría General de Policía Judicial, de la Agencia Tributaria y el jefe de la Unidad de Crimen Organizado de Europol ofrecerán detalles de la operación a los medios de comunicación en el complejo policial de Canillas de Madrid a las once y media de la mañana de hoy.
5  Bitcoin / Wallet software / Offline storage: Alternative to Armory on: March 20, 2016, 06:48:14 PM
Now that Alan has stopped working on Armory, what wallet do you use for offline storage?
6  Bitcoin / Development & Technical Discussion / Bitcoin-QT bypassing Tor on: April 20, 2015, 10:59:13 AM
I'm running Bitcoin Core 0.10.0 and while I have it configured to run through Tor only its been a few weeks that the client tries to bypass Tor and connect directly to 100.64.68.8 or other IP addresses in the same subnet.

My reverse firewall is blocking it, but it seems very strange to me that the client tries to bypass Tor, that looks like a privacy/security problem.

Anyone has seen the same behavior?
7  Economy / Service Discussion / Investigation: The missing MtGox bitcoins on: April 19, 2015, 08:36:28 AM
Full article: http://blog.wizsec.jp/2015/04/the-missing-mtgox-bitcoins.html

Excerpts:

Quote
A large amount of stolen MtGox bitcoins appear to have been sold off at MtGox and other exchange markets, which would have somewhat pushed the bitcoin price down. However, since the coins were moved relatively slowly over time, and this was back before the bitcoin price exploded, the net monetary effect on the market may well have been pretty limited.

While a decent chunk of MtGox deposits were in a sense "fake" after all (that is, made using stolen funds), the net result for the creditors remains fairly unchanged; if the thieves deposited stolen coins onto MtGox, sold them for cash and then withdrew that money, we're still left with creditors who bought those coins for real money in good faith.

Notably, the fact that the coins were real, stolen and at significant risk of already having been spent would seem to further dim any hopes for creditors of recovering any more bitcoins. Realistically, we are left to hope the payout percentage might improve as invalid and illegitimate claims could potentially be filtered out.





8  Economy / Service Discussion / Random 0.0005 payment apparently linked with Factom on: March 31, 2015, 10:22:46 PM
I've just received dust from an address that seems to be linked with Factom.

The transaction: https://blockchain.info/tx/a1b0b0019961b7906d8982416693d5868505aa8b38f5cc13028499a5ac555c85

The dust-sender (12HDgJEGdf3Wqr3ha5iUL2r8RcPa7BnBj2) was funded by 1FactomGnNFTsTVx8jiGjcLKDpyL65GDsH.

Another IP discovery attempt? Is Factom somehow involved?

EDIT: solved
9  Bitcoin / Development & Technical Discussion / Bit-thereum on: June 09, 2014, 06:20:59 PM
Gavin just posted an interesting post on his blog about implemeting ethereum-like features on top of the Bitcoin blockchain.

It seems like a logical step, but Gavin tells us that in order to make it, we should replace "verified by the entire network" with "verified by a set of semi-trusted 'oracles'."

How big of a trade off would that be? It seems to me that reaching the minimum amount of trust inherently possible in each type of contract is absolutely necessary.

Here goes the full post by Gavin (source: http://gavintech.blogspot.de/2014/06/bit-thereum.html)

Quote
I've been thinking about ethereum a bit recently. Parts of it are pretty interesting.

Some of it seems like needless re-engineering (like creating a new proof-of-work or a new currency). And in general, I suspect they're trying to do too much-- "complexity is the enemy of security"-- and will end up either radically reducing the scope of what they're trying to do or will get tired of playing whack-a-mole with security and DoS vulnerabilities.

But I might be wrong; maybe I'm just an old, cynical curmudgeon who has played a lot of whack-a-mole with security and DoS vulnerabilities.

Anyway, one of the ideas in ethereum I do find interesting is a contract that has funds associated with it, arbitrary code and state. Verified by the network instead of a central authority. And with transactions as a pseudo-anonymous way of triggering evaluation of the contract, paying funds held in escrow with the contract, and updating its state.

So... could we take that interesting idea and map it onto Bitcoin? Could somebody create "Bit-thereum" on top of Bitcoin as it exists today?

The answer is "yes," if we're willing to replace "verified by the entire network" with "verified by a set of semi-trusted 'oracles'."

That's cheating, though, isn't it? We're not entirely decentralized if we are trusting eleven contract-verifying-services not to collude (or all get hacked) to violate conditions encoded in some contract(s).

It is cheating a bit... but all of the really interesting complex contracts I can think of require data from outside the blockchain. Like the BTC/USD exchange rate on some future date (for blockchain-enforced futures contracts).

ethereum doesn't have some magic solution to the "data outside the blockchain" issue: as their whitepaper says, "a trusted source is still needed to provide the price ticker."  And there is already at least one startup working on a solution to the "data outside the Bitcoin blockchain" problem (Reality Keys).

Moving from one trusted source to M-of-N semi-trusted sources would be an improvement.

So I'll start there, and imagine that there are semi-trusted 'oracles' that compete to be the most reliable and trustworthy verifiers of contracts. People involved in contracts choose N of them, and then require that contract conditions be validated by one or more of them before the contract pays out. Pick more than one so no single oracle can steal the contract's funds, but less than N in case some of them go out of business or just aren't around to validate contracts when it is time for the contract to pay out.

These oracles need an agreed-upon, machine-readable contract language, but that shouldn't be hard. There are lots of interesting design decisions on what information contract scripts have access to (and lots of not-so-interesting-to-me design decisions on the language itself; is it stack-based, register-based, high-level, low-level bytecode, etc etc etc). Copying most of the ethereum contract language design (and maybe re-using lots of their code) might be a good way to go.

Maybe off-blockchain data would fetched from the web via URI. The tricky bit would be how to handle error conditions like "This contract is about average temperature in Aruba according to the World Bank, but the World Bank is no longer publishing that information."

They also need a way to store some value in escrow, associated with the contract, so that M-of-N of them must agree to any release of funds. Bitcoin multi-signature transactions could be used for that:

1. Whoever is involved in the contract gives the contract code to each of the N oracles and gets back N public keys.
2. The oracles would store the contract code and the private key, and should be willing to give out the public key to anybody who knows the contract code.
3. Anybody can then add funds to the contract by sending bitcoins into the M-of-N multisig made up of the public keys. And maybe associate some data with the escrowed funds by hashing it and include a prune-able OP_RETURN output with the hash.

So far, nothing tricky either on the Bitcoin side or the oracle's side. But what happens when it is time for the oracles to evaluate the contract and disburse some or all of the funds? What triggers the oracles to evaluate the contract (and update any state associated with the contract), and who creates and broadcasts the disburse-funds-from-escrow transaction?

Those are interesting design decisions. I'd probably have whoever is getting paid be responsible for creating the disbursement transaction, contacting M of N oracles to get signatures and then broadcast the transaction. When I say "whoever" I really mean some contract software running either in the cloud or on somebody's machine.

When to update the state associated with a contract is another interesting design decision. My intuition is a contract's state should be tied to Bitcoin transaction confirmations and the state of the transaction outputs being spent. So a contract could be in several states at once if one or more of its inputs are double-spends. Once blockchain confirmations choose one side of the double-spend or another the state of the contract would also be resolved.

I imagine the contract code would have access to all of the unspent transaction outputs (and associated OP_RETURN data, plus metadata like how many confirmations they have, which block they appeared in, maybe their merkle branch...) plus the disbursement transaction outputs. Another interesting design decision is how to handle unconfirmed transaction outputs; I suspect that letting contracts respend zero-confirmation outputs, combined with a promise from the oracles that they will never sign the same output twice might be incredibly powerful and allow all sorts of interesting applications.

Oracles could be vulnerable to denial-of-service attacks-- e.g. an attacker requesting an endless number of public keys for contracts they have no intention of fulfilling. Or an attacker requesting an endless number of contract evaluations (and signatures).

To solve the first problem, oracles could require a small up-front payment to establish a contract. And to solve the second, oracles could require that any escrow disbursement also include a small payment (they would simply refuse to sign any escrow disbursement transaction that did not include a payment to their public key). All that makes economic sense, and gives oracle operators a clear business model.

Leveraging Bitcoin transactions for the escrow/funding parts of the problem protects oracles from a whole other set of possible denial-of-service attacks; for example, "penny-flooding" a contract to make it very CPU-expensive for the oracle to evaluate would cost the attacker a significant amount of Bitcoin transaction fees.

Oracles might also put limits in their terms of service to fend off potential attackers, and collaborate to confiscate escrowed funds if an attacker created a very expensive-to-validate contract.: "Any contract that uses more than one CPU-microsecond to validate may be terminated with the funds disbursed in equal amounts to the N validating oracles."  They would maintain their reputations by publishing all of the information about the rogue contract.

But... but... doesn't it have to be more complicated than that? New Bitcoin Script opcodes? Contract code in the blockchain? A merged-mined chain or new colored coin or something?

I don't think so. Bitcoin already provides a global currency and distributed ledger-- there is no need to re-invent those wheels. Combining real-world information with Bitcoin is where things start to get really interesting.
10  Bitcoin / Development & Technical Discussion / Can Bitcoin Core be compromised by Heartbleed - are private keys exposed? - How? on: April 09, 2014, 10:51:24 AM
Some questions about Heartbleed and Bitcoin Core:

  • Could somebody describe how the attack would work if somebody had been using Bitcoin Core 0.9.0 and clicked on a "bitcoin:" link?
  • Could the private keys be compromised even if I generated the "bitcoin:" link myself and clicked it just to see how the new payment function worked?
  • In that case, how the private keys would have been exposed? Because of a MITM? How would it work?
  • Would the wallet be considered compromised if I clicked on a "bitcoin:" link but didn't go through the payment, and thus I did not sign any transaction?

I just cannot wrap my head around it yet.
11  Bitcoin / Bitcoin Discussion / MtGox database leak: why you should always mix your coins. on: March 10, 2014, 09:27:18 AM
After the Gox dabatase leak the names and home addresses of pretty much everybody involved in BTC are now public, at least among the criminal community.

Those singing the song that goes "I don't mix my coins because I have nothing to hide" are either:

a) totally brainwashed/incredibly naive
b) just stupid.

Even if you mined the vast majority of your coins and used an exchange just to cash out a minor part of your holdings, your total BTC balance can be discovered by trivial blockchain analysis, following the links with just one deposit/withdrawal address.

Morale of the story: Everybody should ALWAYS mix their coins and use Tor for BTC related activities. Information is power. Never give it away.

EDIT FOR CLARIFICATION:

Bitcoin is pseudoanonymous: as soon as someone links one of your addresses to you (because you made a payment to him, or because a database of a service such as Gox is leaked) then he can learn your total BTC balance - or at least the total BTC balance of the wallet to which that address belongs - with trivial blockchain analysis.

By mixing your coins you make that task much more difficult, and thus you eliminate yourself from the list of easy targets in a situation as per the Gox database leak.

Said with other words: by not mixing your coins you are revealing your whole balance to the recipient of every transaction you make... And that is an important privacy breach.
12  Economy / Service Discussion / The mysterious MtGox buyer on: February 25, 2014, 03:09:31 PM
It's clear that somebody wants us to believe that MtGox is being bought by a third party. The facts:

1) Somebody has leaked the following document: http://es.scribd.com/doc/209050732/MtGox-Situation-Crisis-Strategy-Draft

No explicit mention to Gox being sold, but a lot of explicit mentions to re-branding, etc.

Very unlikely to be an internal doc (at least as it is), but some of the info might not be completely false. Five minutes after the "leak" of this document MtGox website disappeared and trading was halted. Previously to that all the feed of their tweeter account was deleted. Just yesterday "gox.com" was registered apparently by Mark Karpeles himself, and now redirects to mtgox.com. Everything seems to support the "leaked document" discourse.

2) Somebody inside MtGox wants us to believe it will be sold/acquired imminently. The below comment can be read on mtgox.com HTML code, and the one who placed it knows very well that comment would have been seen by everybody and thus "leaked" to the masses:

Quote
<html>
   <head>
      <title>MtGox.com</title>
   </head>
   <body>
      <!-- put announce for mtgox acq here -->
   </body>
</html>

3) Karpeles just replied to a Reuters reporter, implying Gox was about to be sold. The question was: "is MtGox dead"? The literal answer: "We should have an official announcement ready soon-ish. We are currently at a turning point for the business. I can't tell much more for now as this also involves other parties."

Source: http://www.reuters.com/article/2014/02/25/us-bitcoin-mtgox-ceo-idUSBREA1O12T20140225

Summing up: somebody wants us to believe Gox will be bought by someone, very soon.

Who do you believe is so crazy to buy such a destroyed brand? My personal view right now is that nobody sane would pay for Gox - there has been no time for a due diligence and it looks unlikely somebody would throw money to Gox during this shitstorm, this a simple re-branding and a make-up action is much more likely in my opinion.

Anyhow, there's too little info to be sure of anything yet.

What do you think? Who could be the mysterious buyer? Speculate.
13  Economy / Speculation / Buying - market reacting very maturely to the malleability issue on: February 12, 2014, 09:40:40 AM
The market is reacting VERY maturely to a "major" issue: despite of devs trying to downplay the transaction malleability thing, the hard cold fact is that this limitation is being exploited right now to launch a DoS attack to the network which is slowing down (if not outright halting) the bitcoin economy. I've been sending coins to quite a few services for testing purposes (Bitstamp, Dgex, etc.) and all of my transfers were "mutated" and thus the coins were sent to the correct destination but they weren't credited to the corresponding accounts. Most transactions are delayed and big players such as Bitstamp, Gox or Coinbase are having problems tracking correctly the transactions.

Still BTC is trading well above $600 everywhere but Gox. This is a sign of strength in my book. Be prepared to buy, guys, because the network will come out MUCH stronger after this issue is solved.

(cross-posted in the Wall Observer).
14  Bitcoin / Development & Technical Discussion / Somebody is having fun with transaction malleability on: February 11, 2014, 12:14:27 AM
Am I the only one watching on blockchain.info as dozens of "double spend attempts" are being broadcasted?

Like this one: https://blockchain.info/en/tx/48b81b933bff28080ad7eb80236d5a2c001559a5b9ef8b0f3eb6c95649e1666f
15  Economy / Auctions / 4 KnC Jupiters +/- 550GH/s stable, IN HAND - IMMEDIATE DELIVERY on: November 07, 2013, 09:34:11 PM
This is an auction for 4 KnC Jupiter, hashing stable at +/- 550GH/s. Info:

  • located in the EU
  • will be shipped just after the auction ends with UPS Express Saver service. That means next day delivery for most EU, and 48 hours delivery for the rest of the world
  • any kind of ownership proofs will be sent through PM at buyers request
  • full escrow is possible with JohnK., to be organized and paid by the buyer
  • minimum increment per bid: 1 BTC
  • reserve price: 26 BTC + shipping
  • starting bid: 10 BTC + shipping
  • auction ends on Monday, 11th November at 11:00 UTC

How to bid?

Post your bids in this thread. Prices must be stated in BTC per Jupiter. You must state the max number of Jupiters you want (eg: 3@35).

So if someone bids for 4 Jupiters @ 40 BTC and this is the highest bid, then he'll get all 4 Jupiters. If the two highest bids are 4 Jupiters @ 40 BTC and 1 Jupiter @ 45 BTC, then the first person will get 3 Jupiters and the second person will get 1 Jupiter.

A previous successful action of one of my Jupiters: https://bitcointalk.org/index.php?topic=314656.0

Happy bidding.
16  Economy / Auctions / 4 KnC Jupiters +/- 525GH/s stable, IN HAND - IMMEDIATE DELIVERY (fast auction) on: October 26, 2013, 08:53:12 AM
This is an auction for 4 KnC Jupiter, hashing stable at +/- 525GH/s. Info:

  • located in the EU
  • will be shipped just after the auction ends with UPS Express Saver service. That means next day delivery for most EU, and 48 hours delivery for the rest of the world
  • any kind of ownership proofs will be sent through PM at buyers request
  • full escrow is possible with JohnK., to be organized and paid by the buyer
  • minimum increment per bid: 1 BTC
  • reserve price: 35 BTC + shipping
  • auction ends on Monday, 28th October at 15:00 UTC (timer below)

How to bid?

Post your bids in this thread. Prices must be stated in BTC per Jupiter. You must state the max number of Jupiters you want (eg: 3@35).

So if someone bids for 4 Jupiters @ 40 BTC and this is the highest bid, then he'll get all 4 Jupiters. If the two highest bids are 4 Jupiters @ 40 BTC and 1 Jupiter @ 45 BTC, then the first person will get 4 Jupiters and the second person will get 1 Jupiter.

A previous successful action of one of my Jupiters: https://bitcointalk.org/index.php?topic=314656.0

Happy bidding.

Timer removed. End time: 2013-10-28+15:00:00UTC
17  Bitcoin / Bitcoin Technical Support / HELP! Bitcoin-QT crashed during a transaction and now my BTC are in the limbo on: October 23, 2013, 01:58:32 PM
I sent a transaction which had many inputs, and that usually takes a few seconds in which Bitcoin-Qt is stuck "thinking", but after a while it continues to work and the transaction goes through - not this time!

I just installed OS X 10.9, and my computer is very sluggish. I sent a transaction with many inputs and after a few seconds Bitcoin-QT crashed and shut down. When I reopen it, I see that the BTC are now "gone", they do not show up anymore in my balance., and the transaction is unconfirmed even if many blocks have been found since I broadcasted it.

I've checked the transaction ID on blockchain.info and it "does not exist", and I'm monitoring the receiving address and there is no unconfirmed transaction...

What I think is that the transaction was not successfully broadcasted, but my local Bitcoin-QT thinks it was, so it doesn't show the right balance... Any idea on how I can fix that? Its urgent!

Thanks in advance for any help.

 
18  Local / España / Vendo KnC Jupiter hasheando estable a +550GH/s, DISPONIBILIDAD IMMEDIATA on: October 22, 2013, 08:31:52 AM
Dispongo de varios Jupiter que pueden ser entregados de inmediato, condiciones:

  • Están en España
  • Funcionando estables a +/- 550GH/s
  • Disponibles para recogida en persona o con envío por UPS (Express Saver) u otro servicio a cargo y elección del comprador
  • El minero será enviado el mismo día si la compra se realiza antes de las 15h
  • Todo tipo de pruebas (estadísticas del pool, fotos, vídeos, prueba de compra, etc.) están a disposición del comprador por PM
  • Es posible utilizar escrow con JohnK. por el 100% de la transacción - organización del escrow y pago de los gastos a cargo del comprador
  • El precio es de 32 BTC incluyendo fuente de alimentación (Aerocool StrikeX 1100W 80Plus Gold) y SAI
  • Si no se desea fuente de alimentación y SAI, y la entrega es en mano o el envío a cargo del comprador, el precio es de 30 BTC
  • Precio negociable para compras de 2 o más unidades



19  Economy / Computer hardware / [WTS] Jupiter units +525GH/s stable IN HAND - IMMEDIATE SHIPPING on: October 21, 2013, 07:59:05 PM
Multiple Jupiter units available for sale, details:

  • located in the EU
  • will be shipped on the same day if purchased before 15:00 CET
  • Shipping through UPS Express Saver service by default. That means next day delivery for most EU, and 48 hours delivery for the rest of the world
  • Any kind of ownership proofs will be sent through PM at buyers request
  • Full escrow is possible with JohnK., to be organized and paid by the buyer
  • Price is 50BTC per unit including PSU (Aerocool StrikeX 1100W 80Plus Gold) and UPS
  • Price is 45BTC per unit NOT including PSU and UPS (shipping to be paid by buyer in this case)
  • Negotiable discounts possible for bulk purchases

EDIT 22-10-2013: price updated.



20  Economy / Auctions / KnC Jupiter 525GH/s stable, IN HAND - IMMEDIATE DELIVERY (fast auction) on: October 20, 2013, 08:25:39 AM
This is an auction for a KnC Jupiter, hashing stable at 525GH/s. Info:

  • located in the EU
  • will be shipped on Monday (tomorrow) just after the auction ends with UPS Express Saver service. That means next day (Tuesday) delivery for most EU, and 48 hours delivery (Wednesday) for the rest of the world
  • any kind of ownership proofs will be sent through PM at buyers request
  • full escrow is possible with JohnK., to be organized and paid by the buyer
  • starting bid is 40 BTC
  • if final price is lower than 45 BTC, shipping (aprox. 3.5 BTC) to be paid by the buyer; if final price is higher than 45 BTC, shipping to be paid by me
  • auction ends on Monday, 21st October at 14:00 CET (timer below)

This is a test auction to discover market price; more Jupiters might be available in the future or at buyers request.

Happy bidding.

Timer removed. End time: 2013-10-21+14:00:00CET


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!