Alright, I'll try to enable at least some of its functionality in the near future. (The trouble is that action=.xml has a whole bunch of options, and I know that some combinations of options end up resulting in minutes of computation. I need to figure it out.)
Note that I only sample that page every 10 minutes with exactly these options: https://bitcointalk.org/index.php?action=.xml;sa=recent;limit=255If there is another way to achieve something similar (a largish number of recent posts) I might look into it as well. |
|
|
|
Thank you very much for your work Bruno. Also thanks to Rassah and whoever else donated time to make this work. BTC address sent by PM (for what it's worth). Greetings to all donators, that were good times!  |
|
|
|
Anyone got a list of wallets that they have built using this system?
I have built Bitcoin and Namecoin. |
|
|
|
So, I ran into this problem, as well, and had to manually extract to work around it: Hi, I have this error: QT5 base [5.3.2]
error: zipfile probably corrupt (segmentation violation)
Fatal error! Errorlevel: 3
Press any key to continue . . . Can't figured out how to procede. All .zip files works..  Any suggest? Then I ran into the following older problem, with the openssl build silently exiting, as in: openssl... Operating system:i686-whatever-mingw *then silently exits* (meaning, the ./config starts, then crashes before "Configuring mingw") I had to manually run ./config and make via console for OpenSSL and then ran into the same silent exiting issue with the rest of the dependencies in build_dep.sh, so I had to manually run it for each of those dependencies, too. I have my fingers crossed that the rest will work. I'm more curious as to why these problems are occurring for people. Edit: Nope, got all the way to 4_run_build_daemon_and_qt, and get mingw32-make.exe has stopped working. EasyWinBuilder still ain't easy. EDIT:
running openssl ./config and make via mingw console seems to work fine. Not sure what the deal is with running via the .bat under windows command prompt instead...
I commented out the openssl compile from the .sh and am now continuing with the rest of the process.
The sed commands are throwing a permission denied error, but look to have successfully updated what they were supposed to anyways.
Thanks for this tip, I had to do the same. Thanks for the feedback. Are you sure you got the right versions of mingw? I will take another look at this with bitcoin 0.12 |
|
|
|
The point here is to validate ownership of names, not restrict the total number of names or in the system to an arbitrary upper limit, right?
If so, would it be possible to tie in the difficulty of the proof-of-work to be based on the number of new name requests seen in the past two weeks? That is, the more requests, the easier the difficulty of hashing a block, and the more quickly blocks are generated? POW would also obviously have to be tied into the amount of processing power being thrown at the network as well.
The way it is implemented there is the currency in between. btw: Help needed testing this Namecoin id/ pgp keyserver: https://forum.namecoin.info/viewtopic.php?f=9&t=2476btw2: The rebased client is humming along nicely. There is an external rpc GUI frontend for name operations with the new client available ( nameGUI, includes experimental secure name trading). Even the manage name tabs might come back to the new client. btw3: There is a roadmap now (work in progress) that shows some of things that are currently going on: https://github.com/namecoin/meta/blob/master/roadmap.md |
|
|
|
In this case, where they know the previous block is valid b/c they mined it, why wouldn't they simply mine the next with tx's in it? the reason these spv miners do what they do is b/c they don't want to waste time validating another pools just received block, which is not the case in this situation since it's their own.
It is both as can be seen when 2 blocks back to back come from an SPV pool and the 2nd block has zero txns. The reason is they've not gone to the effort to make the bitcoind validation process fast in their own nodes and they don't want to wait for bitcoind to validate the block (it takes time) before starting on their next block. For solo.ckpool.org and kano.is we run a customised bitcoind which speeds up the validation process dramatically, making this delay negligible. Maybe your speed ups could go into the official client? |
|
|
|
This article sounds a bit biased. E.g. it says: retailers will be able to detect unconfirmed RBF transactions and reject them
But there is no need to "reject", you just don't process these transactions until you have some confirmations. Users that "opt-in" on RBF might have to wait longer in some situations. I still wonder how this is supposed to be handled on the sender user interface - it seems very difficult to explain the implications to a normal user ("click here so your transaction is less likely to get stuck in the network but more likely to be delayed on the recipient side"?) FSS-RBF certainly is a better solution from a user perspective even if it is less elegant protocol wise. Maybe it will also be added at some point. Or the awesome "Delayed-RBF" solution in the OP  edit: btw is it only me that considers the use case for RBF of "Paying multiple recipients in succession" pretty irrelevant? Currently this is simply done by batching transactions so the practical cost savings will be minimal. |
|
|
|
The latest attempt to add RBF to Bitcoin Core might cause unexpected delays in user experience by vendors waiting for (sender controlled opt-in) RBF. Would it be possible to modify RBF so that the transaction replacement is delayed? E.g. disregard replacement tx if the original tx has been in the mempool for less than six blocks. This way zero conf tx should not be affected, still stuck transactions could be fixed after some waiting time. background: https://www.reddit.com/r/Bitcoin/comments/3ul1kb/peter_todds_rbf_replacebyfee_goes_against_one_of/ |
|
|
|
|
Updated for Bitcoin Core 0.11.2
|
|
|
|
|
backend seems to be stuck.
This would be very helpful in countering the isis address fud (9554btc).
|
|
|
|
I have unpacked all the files and put them in /lib. Can you tell me what part I have to comment out? Tnx..
in unpack_dep.sh you need to uncomment one line: #unzip -o $DOWNLOAD/qtbase-opensource-src-$QTVERSION.zip -d $QTBASEPATH > /dev/null For things to still work you need to do the unpack manually: extract qtbase-opensource-src-$QTVERSION.zip to the $QTBASEPATH (by default "Qt"). To test you can then directly run "2b_run_unpack_dep.bat" and "3d_build_qt5.bat" |
|
|
|
Tried, seme error Can you unpack the file manually? if not it's really broken. otherwise you can comment out the automatic extraction in easywinbuilder and manually do whatever you comment out. |
|
|
|
Hi, I have this error: QT5 base [5.3.2]
error: zipfile probably corrupt (segmentation violation)
Fatal error! Errorlevel: 3
Press any key to continue . . . Can't figured out how to procede. All .zip files works.. Any suggest? Hmm. You could try to manually unpack the file. |
|
|
|
The bounty fund will pay out [...] for completed work proposed in this thread that furthers the goal of making improved transaction privacy a practical reality for Bitcoin users.
Would this suite Joinmarket? https://bitcointalk.org/index.php?topic=919116Was the work proposed in this thread? I guess only gmaxwell knows the answer to this question. In my eyes Joinmarket is going further than what has been suggested in this thread as it adds the incentive necessary for CoinJoin to actually go somewhere. |
|
|
|
In order to further incentivize work in this space there is now a multisignature escrow bounty fund: 3M8XGFBKwkf7miBzpkU3x2DoWwAVrD1mhk (yes, Bitcoin addresses can also start with a 3)This is a two-of-three multisignature escrow with myself, Theymos, and Pieter Wuille as signers. To release any coin sent to this address at least two of these people must sign the transaction. The bounty fund will pay out as funds are available according to the signers best judgment for completed work proposed in this thread that furthers the goal of making improved transaction privacy a practical reality for Bitcoin users. Please feel free to contribute to the above address to support work on this infrastructure. Multisig address construction details: Key from Theymos:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Here is a public key of mine, usable for the CoinJoin bounty fund:
02d5f2b9c68b22006161dfe58a78b37dc2b577e8bb4e4522940830264eb3b3a38b
-----BEGIN PGP SIGNATURE-----
iF4EAREIAAYFAlISs5MACgkQxlVWk9q1kednkgD/WvE3F1hSoKHIr+y7q3O6xbGp
FM+P/lVbi/nZugrlNKABALMhYih2Ov80OS1PLMX9UpONn2eE2Xu+ZkxZ2SkQFfCU
=lFI0
-----END PGP SIGNATURE-----
Key from Gmaxwell:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Here is a public key of mine, usable for the CoinJoin bounty fund:
027b48575c15712867a8a1e6c9f52f510946130bbdf3b1e2feb344b8b68232ffb1
-----BEGIN PGP SIGNATURE-----
iEYEARECAAYFAlIbCV4ACgkQrIWTYrBBO/ooAgCdG9twTEFH5q+5Pip9qDOGsoww
a7YAoLfVP4CBaxk5mnpMXVHpQXqgVwxL
=k1JR
-----END PGP SIGNATURE-----
Key from Pieter:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Here is a public key of mine, usable for the CoinJoin bounty fund:
0292782efcb08d621c360d055f407c8e75ffbbd06f6b7009c1432ca9eaa6732592
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQGcBAEBCAAGBQJSpLf6AAoJEI9lMlXIeZLgtRkL/3ufWgLyhTKM9T30JqA0a/Xh
5KUMD0csuxTMYraVOy9x7tRVZh+fETt4Y3clhErZj8g6VraC5ku+4pyHxtFztWor
N6QadkAvwuCAqmBxbAmb7hTq41eXjptzwqyUWh/z6YecBKeRIxIi/8LGqX/+gODd
GlKj66Ex27wgp9gJp/1Ot+hrTmmasxXAEjXYJTKr4LjJeajH/HJJQeCI6jTy4fdm
TsplX7rUgzhdZQ60malyn1MCmtdXRviWyWuAvKgpIaEMaZsFCSMfvNzUtKHiMv3n
HPxe9OAv1V2rdwU9oa7gxHLSvF7BER1XpWcA0UKTeD1w2/vzPZj3exDDHT8A35Ro
nhK6cJPYTdnzXLavpFqRD85R1G9W3rl4IzqfflXwWB2rRByyLROvrMfVG8iLMYP0
JcaB+8kttzqTa0vBiaosCvSbFZAfw2seyXxxF5anH4Q0ueMJKglLp6rE/51s1bQa
Hz6rsSAAdvx/OSCitKp1+JMzSKA/SwNMRUy4VqKQ4g==
=70Dh
-----END PGP SIGNATURE-----
2-of-3 Address construction:
$ bitcoind createmultisig 2 '["02d5f2b9c68b22006161dfe58a78b37dc2b577e8bb4e4522940830264eb3b3a38b","027b48575c15712867a8a1e6c9f52f510946130bbdf3b1e2feb344b8b68232ffb1","0292782efcb08d621c360d055f407c8e75ffbbd06f6b7009c1432ca9eaa6732592"]'
{
"address" : "3M8XGFBKwkf7miBzpkU3x2DoWwAVrD1mhk",
"redeemScript" : "522102d5f2b9c68b22006161dfe58a78b37dc2b577e8bb4e4522940830264eb3b3a38b21027b48575c15712867a8a1e6c9f52f510946130bbdf3b1e2feb344b8b68232ffb1210292782efcb08d621c360d055f407c8e75ffbbd06f6b7009c1432ca9eaa673259253ae"
}
Would this suite Joinmarket? https://bitcointalk.org/index.php?topic=919116 |
|
|
|
Finally got to fix the difficulty chart including the retarget time and next difficulty estimate. |
|
|
|
|
Show Posts
