Re: Linking transactions from historical blockchain/Getting full transaction values

Hi Andreas, Thanks for the information! At this point, I guess the solution will be write some code manually that will connect transaction inputs and outputs together to calculate those fields, which hopefully shouldn't be super painful. Sidd On Wednesday, March 22, 2017 at 5:42:21 PM UTC-4,

Re: Any plans how to deal with a potential BU fork?

His BIP is at https://github.com/luke-jr/bips/blob/bip-sizefp/bip-sizefp.mediawiki He posted a link to it on the bitcoin-dev mailing list. Matt On March 22, 2017 2:09:13 PM PDT, Manfred Karrer wrote: >Do you have a link to that discussion? > >Am Mittwoch, 22. März

Re: Linking transactions from historical blockchain/Getting full transaction values

Welcome to bitcoinj! The input values and the fee is only known for transactions that were created by bitcoinj's Wallet (which you're likely not using anyway). For incoming transactions there values are missing, it's a known limitation of the Bitcoin protocol. Yes, MemoryBlockStore only stores

Re: Any plans how to deal with a potential BU fork?

When you talk about minority chain we should take in consideration that this might change over time. So todays winning chain might be the loser of tomorrow and so on. Might be pretty messy with re-orgs and double spends... Also I would not count with what some people expect that the minority

Re: Any plans how to deal with a potential BU fork?

Do you have a link to that discussion? Am Mittwoch, 22. März 2017 14:49:15 UTC-5 schrieb Matt Corallo: > > Luke made a good observation this morning that you can do (somewhat) > compact fraud proofs of blocks > 1MB because of the structure of SHA256 > (you can provide a midstate + the last few

Re: Question: Transaction version and Bitcoin Core 14

Thanks for the clarification! Am Mittwoch, 22. März 2017 09:35:05 UTC-5 schrieb Andreas Schildbach: > > As far as I understood the problem, transaction versions are not part of > the consensus. So they can be any value and for confirmed transactions > it doesn't make a difference. However, in

Re: Any plans how to deal with a potential BU fork?

Luke made a good observation this morning that you can do (somewhat) compact fraud proofs of blocks > 1MB because of the structure of SHA256 (you can provide a midstate + the last few bytes of the tx and have a proof of each txn's length). Having a tor-based (or even public, if it must be) service

Re: Question: Transaction version and Bitcoin Core 14

As far as I understood the problem, transaction versions are not part of the consensus. So they can be any value and for confirmed transactions it doesn't make a difference. However, in order to get the transaction hash right, we persist the transaction version along with everything else. Bitcoin

Re: Any plans how to deal with a potential BU fork?

A whitelist of nodes for me sounds highly conflicting with the decentralized nature of bitcoin. Also what if nodes switch their software? Not that unlikely in case they notice that their minority chain is dying. On Wednesday, March 22, 2017 at 1:28:09 PM UTC+1, Jameson Lopp wrote: > > > > On

Question: Transaction version and Bitcoin Core 14

I just saw that I get an UnreadableWalletException when I use Bitcoin Core 14 for creating blocks (regtest) and have a transaction in my wallet which is in that block. I found that https://github.com/bitcoinj/bitcoinj/commit/be09b620626681c9e51a211ee314a34cb7958a12 fixed an serialization

Re: Any plans how to deal with a potential BU fork?

On Wed, Mar 22, 2017 at 1:55 AM, Manfred Karrer wrote: > A Bitcoin core node will not mine a transaction originated in a >1 MB > block (not sure if it would relay it). BitcoinJ has no validation of that > consensus rule, so it would accept a tx from a BTU block. I think