Bitcoin Forum
May 24, 2024, 04:46:00 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 2 3 4 5 6 7 8 9 10 [11] 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 »
201  Bitcoin / Bitcoin Discussion / Re: One of the oldest addresses spends to Dorian on: March 12, 2014, 01:44:00 PM
Looking at it closer it actually looks like forwarding "donations" it got during the last year.

The address was not in real use since 2011-06-28.

I personally think that this is rather against the theory that Dorian would be satoshi. Creating such an obvious trail for a small amount does not make sense for someone conscious of privacy.
202  Alternate cryptocurrencies / Altcoin Discussion / Re: I like ripple more than bitcoin on: March 12, 2014, 01:30:21 PM
I can see corporations esp. banks will learn to love Ripple as it allows them to play their old "trust me" cards.
203  Bitcoin / Bitcoin Discussion / Re: One of the oldest addresses spends to Dorian on: March 12, 2014, 01:15:25 PM
Yes. And this from 2009

https://blockchain.info/tx/6f7cf9580f1c2dfb3c4d5d043cdbb128c640e3f20161245aa7372e9666168516
204  Bitcoin / Bitcoin Discussion / One of the oldest addresses spends to Dorian on: March 12, 2014, 01:09:25 PM
The Bitcoin address 12higDjoCCNXSA95xZMWUdPvXNmkAduhWv was first used on January 16, 2009 where it received two 50 BTC coinbases sent on March 7, 2014 to the 1Dorian address.
205  Bitcoin / Bitcoin Discussion / Re: Do we really need a "Bitcoin Foundation"? on: March 10, 2014, 09:05:15 AM
We don't need leaders, but is there a possible way to fund developers appropriately?

Crowd funding is the solution for that not a centralized committee.
206  Bitcoin / Bitcoin Discussion / Re: Do we really need a "Bitcoin Foundation"? on: March 10, 2014, 09:01:40 AM
We do not need them. It is them who do not understand what Bitcoin is who are desperately seeking some "authority" in the field to talk to.
207  Bitcoin / Bitcoin Discussion / Re: When does it become fraud? The ethics of bitcoin mining and zero-confirm TXs on: March 06, 2014, 08:32:45 PM
Let me pour a bit more oil to the fire:

What if one broadcasts a double spend of a confirmed transaction with a fee that provides enough incentive not to mine on top of the chain but to fork it just before the confirmation?

Is it ok to accept the bribe?

Does the miner know the intention of the broadcaster?

No. The miner has only publicly available information accessible to all other miner: that is the block chain and a double spend attempt on the network.

Then I would say there is nothing wrong with attempting to grab these coins. There is also nothing wrong with the rest of the network ignoring your fork should they choose.

I agree. Just emphasized with the question, that order is not even final with a confirmations it is just more and more likely to be final... There are no good and bad motives in absence of extra information.
208  Bitcoin / Bitcoin Discussion / Re: When does it become fraud? The ethics of bitcoin mining and zero-confirm TXs on: March 06, 2014, 08:22:51 PM
Let me pour a bit more oil to the fire:

What if one broadcasts a double spend of a confirmed transaction with a fee that provides enough incentive not to mine on top of the chain but to fork it just before the confirmation?

Is it ok to accept the bribe?

Does the miner know the intention of the broadcaster?

No. The miner has only publicly available information accessible to all other miner: that is the block chain and a double spend attempt on the network.
209  Bitcoin / Bitcoin Discussion / Re: When does it become fraud? The ethics of bitcoin mining and zero-confirm TXs on: March 06, 2014, 08:11:56 PM
Let me pour a bit more oil to the fire:

What if one broadcasts a double spend of a confirmed transaction with a fee that provides enough incentive not to mine on top of the chain but to fork it just before the confirmation?

Is it ok to accept the bribe?
210  Bitcoin / Development & Technical Discussion / Re: ANN: Announcing code availability of the bitsofproof supernode on: March 06, 2014, 07:28:05 AM
I respect and appreciate where your VCs are coming from, but look at it this way: I am a potential customer. I, as the operator of xyz company, am fully aware of the risks involved in searching for implementations outside the core code. One small mistake can lead to disastrous effects (see: gox).

I want to trust you and your platform, but I can't wholeheartedly. Without being able to audit your code I don't know if you haven't made a mistake in your implementation. And there is nothing you could really do to convince me otherwise without open sourcing it. You lost me as a customer, unfortunately.

The open source business model did not generate sufficient cash flow for expansion through support contracts.

We have some profitable projects like https://bullionbitcoin.com, http://bopshop.bitsofproof.com and http://www.bitcointrezor.com/news/2014-02-10-mytrezor-bop-bitcoin-server and a few undisclosed that proved the value of the software, that I could trade in for meaningful expansion See: http://www.iconcapitalsa.com/posts/8-icon-capital-reserve-s-a-acquires-leading-digital-currency-developer-bits-of-proof-zrt

I gave source code access to current customer and I evaluate every new piece of code we write if it is appropriate to open source it. Older versions and lots of useful functions are generally accessible open source even now.

BOPs development focus is now to create a software stack capable of issuing, trading, auditing digital assets. I am sure that we will open source huge portions of that and that others will be licensed with source code access.

211  Bitcoin / Bitcoin Discussion / Re: When does it become fraud? The ethics of bitcoin mining and zero-confirm TXs on: March 06, 2014, 06:45:39 AM
I thought this was some kind of riddle, so I racked my brain trying to come up with a situation where I felt double spending would be legitimate.  I couldn't think of anything.

A double spend could also be a legitimate attempt of correction for excessive fee, wrong address or whatever previous software or human error.

The problem lies with the assumption the miner could know better. You simply can not assume that, and then call the miner a fraudster depending on your view of order. Transactions do not have a timestamp of their own, network propagation is random.

kjj summed it up nicely: https://bitcointalk.org/index.php?topic=500345.msg5540800#msg5540800
212  Bitcoin / Development & Technical Discussion / Re: When will nodes forward doublespends based on fee? on: March 05, 2014, 08:24:04 PM
Another way to get more comfort at local trade is to observe network propagation. The merchant can connect to a high number of nodes and observe if all of them echo the "right" transaction.

But observing propagation does not protect from a fraudster with a big miner buddy and is vulnerable to network isolation/siblings attack.

I think as the network matures merchants and their software will learn to combine evidences to a degree of trust. At the end nothing beats what is on the block chain, so for certainty one has to be patient.
213  Bitcoin / Development & Technical Discussion / Re: When will nodes forward doublespends based on fee? on: March 05, 2014, 08:00:44 PM
Consider two different scenarios:

a) A fraudulent customer pays for a product and broadcasts a double spend with higher fee.
b) A poorly written wallet sends a transaction with excessive fee, the developer notices and attempts to double spend it with a lower fee variant.

A miner receives any of the above transactions through relay nodes in random order. Which one should he chose to remain honorable?
214  Bitcoin / Development & Technical Discussion / Re: When will nodes forward doublespends based on fee? on: March 05, 2014, 07:50:09 PM
I do not think one can call a miner fraudulent if prefers a transaction with higher fee/kb above a lower variant. It is their freedom to mine whatever transactions they choose to.

A miner also has the freedom to walk out on the street and kick some random guy in the nuts.

Bitcoin defines the order of transactions as they are in a valid block on the trunk with most work on it. There is no higher order truth or moral.

A miner does not need to have the information which of conflicting but otherwise valid transactions is the "right" one, therefore free to chose. It is the sender who commits/attempts the fraud by creating two valid but conflicting transactions. The miner is just a paid time stamping service, not the police or judge.
 
215  Bitcoin / Development & Technical Discussion / Re: When will nodes forward doublespends based on fee? on: March 05, 2014, 05:38:55 PM
I do not think one can call a miner fraudulent if prefers a transaction with higher fee/kb above a lower variant. It is their freedom to mine whatever transactions they choose to.

The relay nodes are also free to relay or reject whatever they like. It is however beneficial to the network as a whole if relay nodes do not replace transactions with their double spend of a higher fee.

Nowadays relay nodes are quite homogenous and do not replace transactions, therefore unconfirmed double-spends are usually not making to the miner, this could however change. I guess merchants will feel the pain if so, and adapt.

 
216  Bitcoin / Development & Technical Discussion / Re: When will nodes forward doublespends based on fee? on: March 05, 2014, 06:08:05 AM
Simply knocking out unconfirmed tx from memory pool by another higher fee variant would enable the payor to cancel any payment before included in a block - by double spending to own account. This is a no-go.

I also think that block inclusion would better be simple fee/size order and that memory pool should expire somewhat faster than current 3 days.
217  Bitcoin / Development & Technical Discussion / Re: Bitcoin disk space scalability problem, is it really a problem? on: March 05, 2014, 05:49:31 AM
The restrictions are there for a good reason, to encourage learning before teaching.

The problem you are about to tackle is hard. I recommend this thread to get an insight of its complexity.

https://bitcointalk.org/index.php?topic=88208.0
218  Bitcoin / Development & Technical Discussion / Re: Do you know the Bitcoin wallet code? [btc] 0.2 for 1 hour of your time on: March 05, 2014, 05:34:20 AM

let me give a lesson for free, by giving you a comparable strong proof of funds:
https://blockchain.info/address/1FfmbHfnpaZjKFvyi1okTjJJusN455paPH
219  Bitcoin / Development & Technical Discussion / Re: Request for Comments on Audit Protocol on: March 03, 2014, 08:49:06 AM
The protocol as suggested does not prove that one has access to the funds, only that one had at some time point.

The data signed should include something that can not be known in advance. e.g. the highest block hash at the time point of the signature.

Even then: I can sign something and then one second later remove all coins. So the only thing people then know is that funds are lost. What one really wants is an account with limited outputs. Basically a fund like structure.

Obviously a proof of holdings is pointless if funds are no longer on that key. Such document can not substitute what the block chain says, only supplement it.

Holding funds on multi-signature P2SH addresses (as e.g. https://bullionbitcoin.com does) enables the individual proof of controlling keys without bringing them together at a single storage.

220  Bitcoin / Development & Technical Discussion / Re: Speculation: How to lose significant funds through malleability on: March 03, 2014, 08:36:37 AM
You surely would be able to recover them from your previous backups, right? .. Right??

If someone falls for the wrong assumption that keys of spent coins are worthless, then would also think that it is sufficient to back up keys that control current holdings. Some funds could be recovered using backups, provided malleability did not strike in-between them.
Pages: « 1 2 3 4 5 6 7 8 9 10 [11] 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!